《在日本工作的常用日语》

目次 (Japanese)

はじめに

第1章 立ち上げ、計画書作成の場面

1-1 中国でプロジェクトを立ち上げる、現地でコアメンバーとの打ち合わせ

1-1-① 自己紹介をする

1-1-② プロジェクトの目的と目標について話し合う

1-1-③ プロジェクト憲章について話し合う

1-1-④ コアメンバーの期待役割について合意を得ることについて話し合う

1-2 プロジェクト計画書を作成する

1-2-① 要求仕様書について話し合う

1-2-② 顧客の真のニーズを確認する重要性について話し合う

1-2-③ プロジェクトのステークホルダーについて話し合う

1-2-④ 前提条件、制約条件について話し合う

1-3 プロジェクト計画書を作成する

1-3-① 要件定義書を作成しステークホルダーとの合意について話し合う

1-3-② 要件定義書から設計作業について話し合う

1-3-③ ＷＢＳを作成の要点について話し合う

1-3-④ ＷＢＳからワークパッケージの確定について話し合う

1-4 プロジェクト計画書を作成する

1-4-① WBSからＰＤＭを使って作業手順設定の要点について話し合う

1-4-② ＷＢＳ，ＰＤＭ、ＷＰから作業工数を算出について話し合う

1-4-③ 作業工程を基にスケジュール表を作成について話し合う

1-4-④ 作業に必要な要員の確保について話し合う

第2章 進捗管理と変更対応の場面

2-1 キックオフミーティングを開催する

2-1-① プロジェクトメンバーを集めることについて話し合う

2-1-② プロジェクトの目的、目標について話し合う

2-1-③ プロジェクト組織体制、機能について話し合う

2-1-④ 会議体、進捗報告の方式について話し合う

2-2 進捗報告

2-2-① 計画と実際とのギャップ報告について話し合う

2-2-② 作業が遅れている状況（事実）について話し合う

2-2-③ 作業が遅れている原因について話し合う

2-2-④ 作業遅れを回復する施策について話し合う

2-2-⑤ 必要な支援策について話し合う

2-3 変更管理

2-3-① 変更要求管理の基本について話し合う

2-3-② 変更要求内容について話し合う

2-3-③ 変更要求が工程に及ぼす影響について話し合う

2-3-④ 変更要求の受諾可否および付帯する条件について話し合う

2-4 発生した問題への対応

2-4-① プロジェクトの前提条件が変更したことについて話し合う

2-4-② プロジェクトの制約条件が変更したことについて話し合う

2-4-③ プロジェクトメンバーが途中離脱したことについて話し合う

2-4-④ 技術的な問題が発生したことについて話し合う

第3章 各種マネジメント実務の場面

3-1 クオリティマネジメント

3-1-① 品質保証の基本戦略について話し合う

3-1-② 品質目標について話し合う

3-1-③ 保証、保障、補償の意味について話し合う

3-1-④ 品質保証はプロセス管理が大切であることを話し合う

3-2 コミュニケーションマネジメント

3-2-① コミュニケーションの重要性について話し合う

3-2-② コミュニケーションの構造について話し合う

3-2-③ ディスカッションスキルについて話し合う

3-2-④ ネゴシエーションスキルについて話し合う

3-2-⑤ 主要なステークホルダーとのコミュニケーションについて話し合う

3-3 リスクマネジメント

3-3-① リスクマネジメントの概要について話し合う

3-3-② リスクリスト作成について話し合う

3-3-③ リスクの影響と発生頻度、確率について話し合う

3-3-④ リスク情報を共有することの重要性について話し合う

3-3-⑤ リスクの対応の基本について話し合う

3-4 チームビルディング

3-4-① チームビルディング（組織編制）について話し合う

3-4-② メンバーの特性、能力について話し合う

3-4-③ コンフリクトへの対応のあり方について話し合う

3-4-④ チームのモチベーションについて話し合う

第4章 成果の納入と終結の場面

4-1 プロジェクトの成果を納入する

4-1-① テスト結果について話し合う

4-1-② 発見した問題点について話し合う

4-1-③ 問題点の対応と対策について話し合う

4-1-④ 検収受入準備の要点について話し合う

4-2 プロジェクトの終結準備

4-2-① プロジェクト終結にともなう手続きについて話し合う

4-2-② 完成図書の準備について話し合う

4-2-③ 協力会社との業務契約終了について話し合う

4-2-④ 残された課題への対応について話し合う

4-3 プロジェクト完了レビュー

4-3-① プロジェクト立ち上げ、計画フェーズのレビューについて話し合う

4-3-② プロジェクト実行フェーズのレビューについて話し合う

4-3-③ プロジェクト変更管理のレビューについて話し合う

4-3-④ プロジェクト終結フェーズのレビューについて話し合う

4-4 教訓を整理する

4-4-① 各フェーズで発生した問題について話し合う

4-4-② 各フェーズで発生した問題への解決策について話し合う

4-4-③ 各フェーズで発生した問題への対応で得た教訓について話し合う

4-4-④ 収録した教訓の展開方法について話し合う

4-5 プロジェクト成果のまとめ

4-5-① プロジェクトの目的と目標への達成度について話し合う

4-5-② ＱＣＤの計画と実績の評価について話し合う

4-5-③ ステークホルダーの評価と満足度について話し合う

4-5-④ ビジネスとしての成果と評価について話し合う

はじめに　（再版にさいして）

　現在、日本と中国の間では企業活動は製造業を中心としたモノづくり分野だけでなく、ソフトウエアの開発、商業、サービス業など、広範な分野で進展しています。ＩＴシステム分野においてもソフトウエアプログラムの開発に始まり、多様な業務分野で協業関係が進展しています。

　2000年代に入り日本企業のオフショア開発のニーズが高まるにつれて両国の人々がビジネスで交流する機会が飛躍的に拡大してきました。

　通常、どの国の企業においても多くの人々が関わる仕事では、円滑なコミュニケーションが重要な要素ですが、そのあり方は仕事の成果にも大きく影響します。コミュニケーションの目的は人と人への情報の伝達と、気持ちの伝達を円滑にすることですが、往々にしてコミュニケーションの拙さが、望まない結果をもたらしています。

　とりわけ、ＩＴシステムのソフトウエア開発では、モノづくりとは違って視認性の複雑さがあり、コミュニケーションのミスを誘発しやすい環境ともいえます。仕事におけるコミュニケーションの原点は介在するドキュメントと使用する言語にあります。同じ言語を使用するプロジェクト組織であってもコミュニケーションのミスによる失敗の事例は数多くあります。特に言語を異にする人たちが参画するプロジェクトなどでは、相互に言葉の使い方、会話力の習熟が良好なコミュニケーションの基本ともいえます。

　本書では、電子機器製品の開発を巡る日常的な出来事を会話として設定しています。日本語、中国語を母国語とする開発者、技術者が、プロジェクトの各フェーズで発生する様々な課題をメンバー同士の中でコミュニケーションを深めながら解決し、終結に向かうストーリーですが、プロジェクトではよくある普遍的な事例に模して構成しています。

　本書は、コミュニケーションにおける大きな要素である言語について、相互に理解が深まることを願って試みたものです。本書をご購入いただいた読者の皆様方へのささやかな一助となることを願っています。最後に本書の中国語翻訳と発刊にご尽力いただきましたＴBK株式会社副社長の楊嘉麗氏に心から感謝申し上げます。

第1章　立ち上げ、計画書作成の場面

1-1 中国でプロジェクトを立ち上げる、現地でコアメンバーとの打ち合わせ

1-1-① 自己紹介をする：

（会話の前提）
日本人の前田一郎さんは家庭電機機器製造企業の新商品開発部門に勤務しています。今度、新商品開発プロジェクトのプロジェクトマネジャーとして中国の広東省東莞の現地製造協力会社企業に出張しました。プロジェクトを立ち上げるために現地プロジェクトのコアメンバーに予定している責任者の楊国棟さんとはじめて会合することになりました。
会合の目的は、プロジェクト発足の主旨を伝え、プロジェクトの前提条件、制約条件など主要な事項について情報を共有することとプロジェクトのコアメンバーの選定が狙いです。

前田：楊さん、おはようございます。わたくしは、前田一朗と申します。初めてお会いしますがどうぞよろしくお願いします。

楊　：わたくしが楊国棟です。こちらこそどうぞよろしくお願いします。ところで前田さんは中国には何度目ですか？

前田：今回で３度目です。観光で一度北京に行ったことがあります。もう一度は上海に１か月ほどビジネスで来たことがあります。

楊　：そうでしたか。では、少しは中国の文化に触れておられますね。

前田：いや、それほどでもありません。これから学ぶことがたくさんあります。

楊　：実は私も日本には三度行きました。前田さんと同じで一度は観光であとは仕事の打ち合わせでした。

前田：そうでしたか、お互いに三度の経験ですね。お会いすることができて光栄です。今度のプロジェクトも上手くいきそうな気がします。

楊　：わたくしもその様な気がします。力を合わせてプロジェクトを是非成功させましょう。

前田：力強い言葉を頂き、勇気が湧いてきました。間違いなく成功すると思います。では、早速ですが、新商品開発プロジェクトの概要の説明とプロジェクトの中核になるコアメンバーの人選について話を進めていきたいのですがよろしいでしょうか？

楊　：問題ありません。その２点について話を進めていきましょう。

1-1-② プロジェクトの目的と目標について話し合う：

（会話の前提）
プロジェクト立ち上げの準備段階として現地の担当責任者の楊氏に、新商品開発プロジェクトの目的と目標について情報を共有し、成功させることの意義について共感を持てるようにすることが狙いです。

前田：今回の新商品開発プロジェクトは、当社の事業戦略の主要な計画の一つです。この新商品は、当社と御社の事業進展にとって重要な影響力をもたらすものと考えています。

楊　：そのようですね。もう少し内容についてお聞かせください。

前田：わかりました。業界の情報では、この新商品の開発は他の企業でも力を入れていると聞きます。したがって、商品をリリースするタイミングが極めて重要になります。

楊　：そうですね。良い商品でも遅れて市場に出しては機会を失いますね。

前田：そのとおりです。このプロジェクトはＱ：品質、Ｃ：コストはもちろんですが開発納期を遅らせないようにすることが特に重要になります。

楊　：おっしゃっている意味は良くわかります。

前田：ご理解いただいてありがとうございます。では、プロジェクトで納期遅延を発生させないために特に注意することについてお話します。

楊　：是非、お聞かせください。

前田：私は日本でも多くのプロジェクトを成功させる経験してきました。もちろん、失敗したこともあります。その成功、失敗のプロジェクトの教訓として、プロジェクトに関係するステークホルダー（利害関係者）とのコミュニケーションのあり方が大きいと言えます。

楊　：それは、私も同感です。私も失敗プロジェクトの教訓として、プロジェクトメンバー間のコミュニケーション不足が問題を起こした経験があります。

前田：私も同じ経験をしたことがあります。プロジェクトで問題が発生した場合、現場、現状、現実で捉えることが大切です。そして誰にどのように伝え、迅速な対応が要求されます。

楊　：その通りですね。

前田：しかし、プロジェクトの失敗要因の多くは、問題が起きても適切なコミュニケーションができていないのです。頭では報告・連絡・相談は必要と理解していても、内容的には不十分なことがあります。

楊　：それは、発生した問題がプロジェクトの成功に及ぼす影響を意識できていないということなのでしょうか。つまり、プロジェクトを成功させるためには、プロジェクトの目的と目標をしっかりと共有しておくということですね。

前田：その通りです。メンバーがお互いにプロジェクトの目的と目標を理解した上でのコミュニケーションが重要ということです。

楊　：まず基本はプロジェクトの目的、目標を理解することが重要であることは良くわかりました。

前田：ご賛同いただきましたことに感謝します。ありがとうございました。メンバーの皆さんにはキックオフミーティングで入念にお話しすることにしましょう。楊さんにご協力お願します。

楊　：もちろんです。私も協力します。

1-1-③ プロジェクト憲章について話し合う：

（会話の前提）
前田さんはコアメンバーの楊さんと他の2人のメンバーとでプロジェクト企画書（プロジェクト憲章）の内容を確認することになりました。プロジェクト企画書には、プロジェクト発足に必要な主要決定事項が盛り込まれ、前田さんをプロジェクトマネジャーに任命することも記載されています。プロジェクトの名称はコードネームが使われることになりました。

前田：みなさん、おはようございます。今日の会議はＯＭ４２Ｐのプロジェク企画書の内容について理解を深め、情報を共有することです。また、今回の会議には、新たにコアメンバーに選出された劉さんと、張さんが参加しています。簡単に自己紹介をおねがいします。

劉　：今回のプロジェクトのコアメンバーに選ばれた劉です。コアメンバーに選ばれたことを誇りに思います。どうぞよろしくお願いします。

張　：私も劉さんと同様ですが、コアメンバーに選ばれたことをうれしく思います。プロジェクトの成功を目指して頑張りたいと思います。どうぞよろしくお願いします。

前田：こちらこそ、どうぞよろしくお願いします。では早速ですが、配布したプロジェクト企画文書に沿って進めましょう。では、内容を項目順に読んで行きます。途中で分かり難いところや疑問点がありましたら、随時質問をしてください。

楊　：提案があります。記載項目を各項目ずつ4人で順番に読む方法はいかがでしょうか？　読むことで理解も促進させると思いますが。

劉　：賛成です。その方法のほうが認識の共有が上手くいくと思います。

張　：私も賛成です。私はコアメンバーの仕事は初めてなので情報をしっかり共有したいと思います。

前田：みなさんの積極的な提案を感謝します。わかりました。その方法で進めましょう。では、最初に私が読みます。次に楊さん、劉さん、張さんの順番で進めましょう。先ず、最初にこのプロジェクトの名称について説明します。プロジェクトのコードネームは新しい星を産み出すオリオン座Ｍ４２番星雲になぞらえて命名しています。オリオンＭ４２プロジェクトと決定し、略してＯＭ４２Ｐとしています。

張　：なるほど、新商品を産み出すプロジェクトという意味ですね。

前田：オリオンは新しい商品開発を願っての命名ですが、ギリシア神話でのオリオンは美男の狩人で、狩猟の女神アルテミスが嫉妬し、蠍を仕掛けて命を奪います。哀れに思ったゼウスがオリオンを天に召して星座になったという神話です。

楊　：前田さんは、ギリシア神話にも詳しいのですね。

前田：いや、それほどでもないですが天体には興味を持っています。オリオンを襲ったサソリは現代に例えれば競合会社の新商品かもしれませんね。

劉　：蠍に負けないように新商品プロジェクトを成功させたいですね。

前田：そうですね。それには我々が一致団結して取り組むのが成功の第一歩でしょうね。では、次の項目を楊さんにお願いします。

楊　：はい、わかりました。では、進めます。

1-1-④ コアメンバーの期待役割について合意を得ることについて話し合う：

（会話の前提）
前回の会議でプロジェクト企画書の記載内容について情報の共有化をすませた前田さんは、次のステップとしてプロジェクト計画書作成に取り組むことになりました。その前にコアメンバーがそれぞれの分野のリーダーとしての期待役割を明確にし、合意することが必要です。

前田：みなさんおはようございます。週末はどのように過ごされましたか？体調はいいですか？

楊　：私は久しぶりに家族と郊外の公園に行きました。子供たちも大喜びでしたよ。

前田：それは良かったですね。劉さんはいかがでしたか？

劉　：土曜日はゆっくりと読書をしていました。日曜日は家内と近くのデパートに買い物にいきました。もっとも、私は見るだけでしたが。

前田：なるほど。奥様のおつきあいも大変ですね。ご苦労様でした。張さんはいかが過ごされました？

張　：私は日頃できていない部屋の掃除と洗濯に大忙しでした。日曜日は彼女と映画を見に行き、夕食を一緒にしました。新しい料理店を見つけたのですがとても美味しかったです。

前田：みなさんそれぞれに充実したお休みだったようで何よりです。今日の打ち合わせは、プロジェクトでの皆さんの担当を決めることです。皆さんのご経験と、要望、そして私が期待していることを合わせて合意したいと考えています。

楊　：私はハードウエアの開発経験が多くあります。是非、それを活かした分野を担当したいと思います。

前田：劉さんはどのような意見をお持ちですか？

劉　：私は電気回路系の開発経験が多く、特に電子回路設計と開発には自信があります。

前田：張さんはいかがですか？

張　：私はソフトウエアプログラムの設計と開発が得意です。できればその分野の仕事を任せていただければと思います。

前田：わかりました。皆さんのご意見と得意を活かした分野を担当していただきたいと思います。次のような案を提示します。楊さんの担当分野はハードウエア開発の責任者です。劉さんは電子回路開発の責任者として、張さんはソフトウエア開発の責任者として決めたいと思います。これについて何かご異議はありますか？

楊　：いえ。異議はありません。喜んでお受けします。

劉　：私も異議はありません。喜んでお受けします。

張　：私も異議はありません。経験が活かせそうで嬉しいです。

前田：では、このプロジェクトのマネジメント体制は私がプロジェクトマネジャーで全体を統括責任者として担当します。先に提示案に基づき各開発分野責任者に皆さんをプロジェクトリーダーとして決定します。皆さん方の積極的なご意見をいただき合意できたことに感謝します。

1-2 プロジェクト計画書を作成する

1-2-① 要求仕様書について話し合う：

（会話の前提）
プロジェクトマネジャーの前田さんは、商品企画部で作成された要求仕様書の内容を検討することにしました。検討メンバーはコアメンバーです。 新商品はＰＣに接続して使用する低価格カラーレーザープリンターです。省エネルギー、節電は前提として、小型、軽量、機能アップ、性能アップを目指しています。

前田：要求仕様書に記載されている内容について理解を深めたいと思います。まずはハードウエア開発に要求されているところから始めます。楊さん、ハードウエア設計担当責任者の観点からご意見をお願いします。

楊　：軽量化という点では、現製品に比較すると３０％程度の軽量化が要求されています。これは、筐体の材質の変更が必要不可欠ですね。

前田：そうですね。新しい材質による筐体の設計が必要です。このことでの問題点や課題にはどのようなことが考えられますか？

楊　：材質の選択には問題はないと思いますが、製造段階での加工技術、生産装置の変更も必要になります。

前田：なるほど。そのほかに問題はありますか？

楊　：材質変更による材料費の上昇を見ておく必要があります。そのほかには省エネルギーの要求に対しては、軸受け、回転部分の摩擦を極小化するために高精度なベアリング部品を採用する必要があります。もう一つは耐久性のことも考慮しながら筐体構成部品のプラスチック成型部品を導入することです。

前田：わかりました。重要な変更事項ですね。では、次に電子回路設計についてはどのような問題がありますか？

劉　：要求仕様書には電気・電子回路に関する要求仕様は、節電、省エネルギーの視点から、消費電力を現製品に比較して３０％性能向上と記載されています。

前田：具体的にはどのような部分が改善対象とお考えですか？

劉　：消費電力性能アップが必要と考えるところは、立ち上げウオームアップ時間、待機電力、トナー融着の温度熱源、これらの立ち上り時間を短縮し、且つ安定的な稼働を保証する電気回路の設計、高性能な電気部品、電子部品の開発と選択が必要かと考えます。

前田：開発にはかなり、困難が伴うと思いますが、新商品への期待も高いので可能性を最大限に追求してください。

劉　：もちろんです。ＱＣＤのバランスも考慮して検討したいと思います。

前田：具体的な計画作成段階でさらに検討を深めたいと思います。では、次にソフトウエア開発について議論を進めましょう。張さんのご意見をお願いします。

張　：プリンターソフトウエア開発には、基本的には二つの要素があります。機器の稼働に関係する制御系のソフトウエアと利用者の利便性に関するアプリケーションソフトウエアがあります。

前田：そうですね。今回の商品では、機能アップと記載されていますが、どの部分の機能アップがポイントになりますか？

張　：私の判断では、さまざまな利用者のニーズを円滑に実現できるメニュー選択方式の改善が有効だと考えています。

前田：具体的などのようなことでしょうか？

張　：たとえば、プリント時に指示をするメニュー画面です。現状ではチェックする順番が定型化されており、メニュー画面に束縛されます。慣れない利用者は、「間違えるといけない」心理的に負担がかかっていますが、この点を改善すれば使いやすい商品としての競争力も大幅にアップすると考えます。

前田：それは、大いに期待したいところですね。是非、プロジェクト計画書にも反映してください。

1-2-② 顧客の真のニーズを確認する重要性について話し合う：

（会話の前提）
このプロジェクト事例は、社内プロジェクトの例ですが、顧客から要求仕様が示された場合に置き換えて会話を進めます。要求仕様書に記載された内容を鵜呑みして対応することは、真の顧客ニーズに対応したことにならず、後で問題の要因となることが多くあります。真のニーズを確認する会話の進め方について話し合います。

前田：顧客の要求仕様事項について話し合ってきましたが、気がかりなところについて皆さんの意見をお聞きしたいのですがいかがですか？

楊　：今回の仕様書には小型、軽量、省エネ、節電、性能、機能のアップと盛沢山ですが、本当に重視したいのはどこでしょうかね。

劉　：消費電力の削減とありますが、動力機能との関係で難しい関係にあります。

前田：そうですね。そうした課題はいくつかあると思います。顧客に確認したいことを整理して、要求仕様をまとめた顧客担当者、責任者にヒアリング/インタビューすることにしましょう。

劉　：是非、そうしたいですが、どうしても発注者対受注者という関係で、ニーズを聞かざるを得なくなることが心配ですが。

前田：劉さん、心配なようですね。でも、大丈夫です。その要求が、本当に必要なことであれば我々はそれに応える必要がありますが、そうではなく過剰要求や、見当違いのこともあるのです。

劉　：それは言われる通りですが、ストレートに言えなくて・・・

前田：簡単な方法ですが、質問する方法があります。

劉　：どのような質問方法ですか？

前田：懸念事項である項目について、具体的に聞くことです。聞き方としては、①「この機能は何のために必要ですか？」、②「この機能の目的はどういう理由ですか？」③「この機能は本当に必要な機能ですか？」と聞いてみることです。

劉　：上手くいきますかねえ？

前田：質問はその内容を正しく伝えるということもありますが、質問者の聞き方、姿勢、態度ということも微妙に影響します。

劉　：そうでしょうね。私はその微妙なところが苦手です。

前田：そうですね。コミュニケーション力の問題ですが、いかなるコミュニケーションにも、真摯さがもっとも重要なのです。劉さんの顧客に応えたいという真摯な態度があれば大丈夫です。

劉　：そうですね。臆せずに本音でお聞きしたいと思います。

張　：私もその点が気がかりだったのです。特にソフトウエアは成果物が物ではなく視認性が悪いために苦労しているところなのです。

前田：そうですね。そこの難しさは良く理解できます。しかし、基本的にはハードウエアの要求仕様事項への対応と同じです。それぞれの要求事項が「本当に必要な理由はなにか？」、「なぜ必要なのか？」を真摯に聴き取ることです。そのことで合意ができれば問題は解消します。

劉　：わかりました。それで取り組んでみます。

張　：わたくしも懸念事項を整理して取り組んでみます。

前田：私も支援します。要求仕様事項に疑義の無いようにして次に進めましょう。

1-2-③ プロジェクトのステークホルダーについて話し合う：

（会話の前提）
今回のプロジェクトの企画は、日本にある本社の商品企画部門でなされたものです。開発、設計、生産の工程を中国にある１００％出資の事業所で行います。プロジェクトの主要なステークホルダーの特定と分析について話し合います。ステークホルダーの特定と分析はプロジェクトに有効なコミュニケーションマネジメント計画作成の視点から重要な要素です。

前田：今回のプロジェクトに関係する主要なステークホルダー（利害関係者を明らかにしておきたいと思います。

張　：私の担当領域以外のステークホルダーについても明確にするとのことですか？

前田：そうです。その理由はプロジェクトの全体でステークホルダーに関する情報を共有しておく必要があるからです。

劉　：主要なステークホルダーとはプロジェクト企画書に記載されている範囲ですか？

前田：プロジェクト企画書に記載されている関係者は当然のこととして、プロジェクトの成功に重要な影響を及ぼすと考えられる関係者です。

楊　：ステークホルダーの特定と分析をしておくことが、プロジェクト運営上で重要な要素になるということですね。

前田：その通りです。

張　：どのようにしてステークホルダーの特定をするのですか？

前田：分かりやすいところからやるようにしましょう。最初にプロジェクト企画書に記載されている事項のステークホルダーを特定し、その次に筐体チーム、電気・電子回路チーム、組込ソフトウエア開発チームに関係するステークホルダーを特定しましょう。

楊　：以前に担当したプロジェクトでもステークホルダー分析をきちんとしていたことがコミュニケーションに大変役立ちました。

前田：それは良い経験をしましたね。わたしの行ったステークホルダー特定の方法ですが、プロジェクトに関わる関係者を表す視座図を作成しました。視座図とはそのプロジェクトに関わる人の立場のことです。

劉　：視座図ですか？初めて聞きました。

前田：難しい方法ではありません。メンバーでステークホルダーを書き出していくことです。抽出した関係者を関係性の近いグループにまとめ、視座図チャートに記入し、抜け漏れがないかチェックし作り上げていく方法です。

図1．プロジェクトのステークホルダー　視座図

劉　：なるほど。早速やってみたくなりました。

前田：ちょっと待ってください。ステークホルダーの特定と分析にはもう一つ工夫が必要です。

劉　：それはどのようなことですか？

前田：それは、視点図と価値観分析です。

劉　：視点図？視点は知っている言葉ですが、視点図とは初めて聞く言葉です。先の視座図チャートとはどう違うのですか？

前田：視点図はあることがらに対して重視していることを言います。言い換えれば着眼点ともいいます。

劉　：なるほど、それとステークホルダー分析とどのような関係にあるのですか？

前田：良い質問です。ステークホルダーとは利害関係者とも言いますが、その立場によって、着眼点が異なります。その人の立場とその人の立場に立ったものの見方をすることで、その人の価値観つまりその人が重視していることが分かります。

劉　：なるほど。ステークホルダー分析といっても漠然ととらえていましたが視座と視点を重ねるとその人の価値観が明確になりますね。

前田：ステークホルダーの価値観がわかれば、コミュニケーションのポイントも的外れにならないのです。

劉　：良くわかりました。この方法で進めてみます。

前田：わからないことがありましたらいつでも聞いてください。

1-2-④ 前提条件、制約条件について話し合う：

（会話の前提）
前田さんはプロジェクトマネジメントの重要事項である前提条件と制約条件に関する情報の共有化を図ることにしました。プロジェクトの企画時に設定した条件もプロジェクト環境の変化によって変更せざるをえないことがあります。 当初企画時の条件をよく理解しておくことで、変更せざるを得ない場合でもその影響度を的確に判断できます。

前田：みなさんおはようございます。これからプロジェクト企画書に記載されている前提条件と制約条件について情報を共有したいと思います。

楊　：いずれもプロジェクトマネジメントの重要な事項ですね。

前田：そうですね。特に制約条件はプロジェクトが成功したか、否かの判断基準になります。制約条件が不明確だとプロジェクトをマネジメントすることができなくなります。

張　：3つの制約条件、品質（Ｑ：Quality）費用（Cost）納期（Delivery）という言葉で言われていますね。

前田：その通りです。プロジェクトの制約条件は、品質、費用、納期が相互関係にあることはご存じの通りです。それぞれの条件には目標となる数値が設定されています。

楊　：今回のプロジェクトでは新商品の要求仕様をすべてクリアすることが品質目標を達成することになりますね。

劉　：では、プロジェクト企画書に設定されたプロジェクト活動に関する費用（Ｃ：コスト）を計画した範囲内で抑えることも制約条件ですね。

前田：そうです。計画にそって過不足なく適正な使い方をしているかをマネジメントするということです。

張　：もう一つの制約条件は納期（Ｄ）ですが、これはプロジェクト企画書に設定されている、プロジェクト成果物を完成する期日、あるいは納品できる期日のことですね。

前田：そうです。その通りです。ここでは制約条件をよく理解することが重要と話し合っていますが、その理由は、３つの制約条件に関する計画値と実際の数値、つまり実績値との差異が要点になります。差異のプラスマイナスによってプロジェクトが順調に進捗しているか判断する基準になるからです。

楊　：そうですね。プロジェクトマネジメントの要点でもあるわけですね。

前田：たとえば、あるプロジェクトが計画の日程より作業が遅れた場合、遅れを取り返すために定時外勤務をする、また人員を増加するなどをします。そうすると、予定外、計画外に投入した人員のコストが超過する原因になります。

楊　：コストが超過すると利益性を圧迫することになり、計画した利益の確保も影響を受けますね。

前田：そうです。品質目標が達成できない場合でも、手直し、やり直しでコストも納期にも悪影響を与えます。したがってプロジェクトマネジメントでは３つの制約条件を順守することが求められるのです。

劉　：前提条件のところは、どのように考えますか？

前田：前提条件とはプロジェクトの目的、目標を設定した環境条件をいいます。たとえ ば、経営環境が急速に変化し、プロジェクトの目的が合わなくなった場合、ある いは新たな発明、発見、技術革新でプロジェクトの目的を見直さざるを得なくな った場合などがあります。

楊　：プロジェクト運営するうえでかなり大きな環境条件の変化が起きたという場合ですね。

前田：そうです。このような大きな環境予見の変化が起きた場合は、プロジェクト企画段階に遡行して判断が必要になります。したがってプロジェクトマネジメントの上位のプログラムマネジメント判断が必要になります。

劉　：良くわかりました。

1-3 要件定義書を作成しステークホルダーとの合意について話し合う

1-3-① 要件定義書を作成しステークホルダーとの合意について話し合う：

（会話の前提）
要件定義はプロジェクト計画書の基本事項は顧客あるいは上位企画部門の要求仕様書を受けて、その要求をどのように実現するかについて決定するプロセスです。プロジェクト成果に到達するための具体的施策を決める作業になります。したがって、プロジェクトのオーナー、発注責任者、商品、あるいはシステムを開発する開発部門の責任者、開発担当者の合意が必須です。

前田：要件定義はプロジェクト計画づくりのなかで重要な作業です。顧客の要求、要望をいかに反映するかということと、実現施策とのギャップがないかについて入念な検討が必要です。

楊　：実施策の入念な検討も重要なのはもちろんですが、無理な要求、要望に対してどのように納得してもらうかも大切ですね。

前田：そうです。ただ顧客の言ったことを受け入れるだけでは専門家としての仕事の価値がありませんね。

楊　：技術的に“できない”というだけでは納得してもらえないですね。

前田：そうです。できない理由を述べる場合には、他の方法も検討しつくした結果、“できない”と判断した理由を言わなければ納得してもらえないですね。

張　：しかし、技術的に問題のあることは“できない”ものは“できない“とはっきりいった方が良いと思いますが・・

前田：そこのところですね。大切なのは。張さんが発注者の立場だとどう考えますか？

張　：それは、要求仕様書通りに実現してほしいですね。

前田：そうでしょう。誰もが自分の要求を実現してくれることを期待しています。期待が実現できないとなれば不満を持つでしょう。

張　：しかし、それはやむを得ないのではないでしょうか。

前田：やむをえないということで納得するか、十分に納得するかに違いがあるでしょう。なぜできないかについてステークホルダーが前向きに合意できるような“手続き”が必要です。　　　

張　：手続きといいますと？

前田：それにはできない理由の背景を合理的な説明が必要です。その上に別の方法であればどのように実現できるかの策を示すことも重要です。

張　：そこまで必要ですか。

前田：もちろんです。ステークホルダー、つまり発注者は専門家である我々に信頼を寄せているのです。その信頼にこたえるには当然の手続きです。

張　：別の対策案には開発者側の合意も必要なわけですね。

前田：そうです。開発者側だけでなくプロジェクトに関わる主要なステークホルダーの合意があってプロジェクトは推進できるのです。

張　：要件定義書の段階でしっかりと合意していなければ後戻りや手直しの原因になるということですね。手続きを踏んだ合意の重要性は良く理解できました。

1-3-② 要件定義書から設計作業について話し合う：

（会話の前提）
要件定義書について合意されました。それぞれの担当分野ごとに設計作業に入ります。設計作業はコアメンバー以外の主要な担当者も参加します。前田さんは、設計メンバーに対してもプロジェクトの目的と、目標について情報を共有することになりました。

前田：みなさん、おはようございます。私はＯＭ４２プロジェクトのプロジェクトマネジャーの前田です。初めてお会いする方もいますが、どうぞよろしくお願いします。

全員：こちらこそどうぞよろしくお願いします。

前田：では、初めてなので簡単に自己紹介をお願いします。まず私から始めましょう。

＜相互の自己紹介内容は省略＞

前田：設計作業に入る前にいくつかのお願い事項があります。まず第１点は、要件定義書に記載されていることで分かり難いところがありましたら、自分で“勝手判断”しないで、必ずリーダーに確認してから進めてください。

担当Ａ：勝手判断とはどういう意味ですか？

前田：“勝手判断”とは自分で判断をするのは良いのですが、その判断が主観的になった状態を言います。したがって全体との方向や位置づけがずれてしまい易いのです。

担当Ａ：つまり、不確かなところは、過去の経験や自分なりの思惑で判断するなということですね。

前田：　そうですね。しかし、全てなんでも相談してリーダーに判断を仰ぐという受動的な姿勢とは違いますよ。

担当Ａ：良くわかりました。ほかに気を付けることはどのようなことですか？

前田：ほかに２点あります。第２点目は設計上新しい技術や材質を使う方がプロジェクト成果物の品質が高まる場合もあります。これはある種の要件定義の変更になりますから、関係者への連携をとって進めてください。プロジェクトではあらゆるフェーズでコミュニケーションが重要になります。

担当Ａ：了解しました。

前田：第３点目は、採用する技術は日進月歩で変化します。新しい技術や機材を採用したほうが良いと判断できる場合もあります。しかし、その場合でも安易に採用を決定すると思わぬリスクの要因になることがあります。

担当Ａ：どのような例がありますか？

前田：私の経験では、技術的、品質的には問題はありませんでしたが、供給体制に問題が発生したことがあります。安定した部品供給を受けられないことがありました。

担当Ａ：そういうこともあるのですね。新技術、新機材の採用にはリスクが伴うということですね。

前田：そうです。設計段階で組込まれたリスクは後工程に大きな問題となりますから慎重な取り組み姿勢が大切ということです。

担当Ａ：良くわかりました。

前田：では、他に質問もないようですから設計作業に取り組んでください。

1-3-③ ＷＢＳを作成の要点について話し合う：

（会話の前提）
WBS(ワーク・ブレークダウン・ストラクチャー)は要求仕様書、要件定義書からプロジェクト全体に関わる作業項目を明確にする作業です。WBSは経験豊かな者による作成が一般的です。経験の浅い担当者が作成すると必要な作業の見落としや偏った詳細化になりやすく注意が必要です。経験の浅い担当者もベテランの経験者による指導、支援によって経験を積むことができます。

前田：WBSの作成をしていただきますが、皆さんのそれぞれの担当分野で取り組んでください。

張　：以前に使ったWBSを参考にして作ると効率的ですね。

楊　：もちろんそうですが、容易に活用するだけでは問題ですね。

前田：楊さんの言う通りです。どのプロジェクトもWBSはすべて同じということではありません。新しいプロジェクトの特性によって追加や変更する作業項目が発生します。

張　：解りました。でもWBSつくりは結構たいへんな作業ですね。

前田：そうですね。しかし、WBSがきちんとできていないと後で困ることになるんです。

張　：手抜きしてはいけないということですね。

前田：失敗したプロジェクトの失敗要因にWBSの不備が大きく関係します。それとWBS階層の粒度を合わせることも大切ですね。

張　：:粒度といいますと？

楊　：WBS階層レベルの表現の粗さのことを言います。

劉　：WBSを実際に書いてみると解るよ。

楊　：WBSはトップダウンでツリー構造に作成します。ツリーの構造を企業の組織にたとえて説明しましょう。
第一階層は、経営幹部組織とします。
第二階層は事業部組織
第三階層は部門組織
第四階層は課組織
第五階層はチーム（班）組織という階層構造になります。

張　：今回のプロジェクトだとどのようになりますか？

前田：今回のプロジェクトでは最終成果物である「新ネットワーク・プリンターの開発」が第１階層になります。
第２階層がプロジェクトマネジメントを全体的に把握する管理の階層
第３階層がプロジェクト各フェーズのPDCAを管理する管理の階層
第４階層が各フェーズの中で分担する作業分野の階層
第５階層が作業分野を構成する作業の実行範囲を明確にした階層

張　：他に注意することはどのようなことですか？

前田：WBSづくりはトップダウンが原則です。大きな着眼点からそれを具現化するために必要な管理項目、作業項目を詳細化します。

張　：ボトムアップの方法との違いはどのようなことですか？

前田：いい質問ですね。ボトムアップは実行作業を抽出するには良いのですがプロジェクトを効率的に管理するという側面が弱くなります。

張　：なるほど。そのさじ加減が難しいようですね。

前田：そうですね。したがって書き上げたWBSは何度も見直して洗練することが大切になります。

張　：WBSの出来栄えがプロジェクトの成功に影響するという意味が良くわかりました。

前田：要点をご理解いただいてありがとう。是非、皆さんで良いWBS作成になることを期待しています。

1-3-④ ＷＢＳからワークパッケージの確定について話し合う：

（会話の前提）
何度かの見直しがあってＷＢＳがほぼ完成しました。ＰＭの前田さんは３人のプロジェクトリーダーとＷＢＳの内容に抜け漏れなどの不具合がないか最終確認をすることにしました。ＷＢＳの内容に抜け漏れがあると後工程の作業に大きな影響を与えます。逆に重複している場合は無駄が発生します。 最終確認を終了した段階で主要なステークホルダーの承認を得ておくことが大切です。主要なステークホルダーとはプロジェクトの企画者、承認した意思決定者、コストを負担する発注者、商品、システムを開発する関係者などです。ここでの合意承認をおろそかにすると後々に問題をおこす要因となります。

前田：ようやくＷＢＳが完成しましたが、みなさんのご努力に感謝します。きっとこの新製品開発プロジェクトは成功すると思います。

楊　：この後の作業としてＷＢＳの最下層である実行作業項目の担当者を決める必要がありますね。

前田：そうですね。その前にステークホルダーの合意承認をえることが必要ですね。

張　：その作業って、結構面倒ですね！

前田：面倒だけど、手を抜くわけにはいかないですね。みなさんが旅行に行く場合、旅行の内容を詳しく調べないでお金だけ支払いますか？

張　：それは念入りにチェックしますよ。行きたいところが組み込まれていなかったり、いいホテルに泊まれなかったりすると折角の旅行が台無しになりますからね。

前田：プロジェクトでも同じですよ。発注者の意図に外れた製品やシステムを作られても受け入られることはできませんね。

張　：そうすると、作り直しなどで、余分な費用や時間が必要になりますね。

前田：そうです。単に支払いが遅延するとかだけでなく、発注者にも大きな迷惑をかけることになります。発注者が外部の場合では損害賠償を支払うことにもなるのです。

楊　：金銭的な面だけでなく、企業としての信用を損ない次の商談に注文依頼がこなくなるという大きな問題に発展しかねないのです。

張　：前田さんはいままでにそのような例を経験したことはありますか？

前田：私自身はそのような大きな失敗の経験はありませんが、小さな失敗やクレームの経験はたくさんありますよ。

張　：大きな失敗をすると大変ですね。

前田：だからこそ、プロジェクトでは作業の進め方に慎重で気を配るのです。プロジェクトには、品質、コスト、納期、３つの制約条件があります。ＷＢＳの出来栄えが悪いとこのいずれの条件も守れなくなります。

張　：ＷＢＳをきちんと作ることが、プロジェクト成功の重要要因ということが良くわかりました。

1-4 作業手順設定と工数算出について話し合う

1-4-① WBSからＰＤＭを使って作業手順設定の要点について話し合う：

（会話の前提）
前田さんはプロジェクトコアメンバーと作業手順計画書について話し合うことになりました。作業手順を明確にするためにＰＤＭ（：Precedence Diagramming Method）：プレシデンス・ダイアグラム・メソッド）を使かいます。ＰＤＭについて初めての人もいるのでＰＤＭの概要について話し合います。

前田：ＷＢＳは実行計画の基本になることは前にもお話しましたが、今回は　　　実行作業のマスタースケジュールをつくるＰＤＭについてです。ＰＤＭ実行作業の優先順位、順番を決め、全体のタイムスケジュール、要員数の算出、コストの算出をするための手法です。

劉　：私はＰＤＭの使い方はよくわかりませんので教えてください。

張　：私も良くわかりません。

前田：楊さんはＰＤＭの使い方については良くご存知ですか？

楊　：良く知っているというほどではありませんが、使い方、目的は理解しています。

前田：では、楊さんからＰＤＭの使い方について教えていただきましょう。

楊　：みなさんは、ＰＤＭ以外の方式で、ＣＰＭ（Critical Path Method）クリティカル パス メソッド）という言葉を聞いたころがあるでしょう？

劉　：ＣＰＭもＰＤＭも言葉では知っています。

張　：私も大学で学んだので知っています。

楊　：見たことがあると説明しやすいですね。ＣＰＭは作業から作業を結ぶライン上に作業名を記述しますが、ＰＤＭでは四角い箱の中に作業名を記述します。

劉　：四角い箱のなかに作業名を記述するのですね。

楊　：それだけではありません。作業の依存関係も記述します。詳しくは参考図をご覧ください。

劉　：そういえば、友人がＰＭＢＯＫ®のＰＭＰ資格受験の時に出題されたと聞きました。箱の中に記載された数値から工数の算定をすると聞きました。

楊　：それともう一つ重要な使い方があります。クリティカルパスといってそれぞれの開発工程がもっとも時間がかかり、なお且つ、もっとも時間が短いルートを検出することです。つまりクリティカルパスを検出するということです。

張　：なんだか分かり難いですね。それがどういう意味があるのですか？

楊　：クリティカルパスとは、行程上でもっとも時間的ゆとりのない行程を言います。

劉　：クリティカルパスとはパス上の作業が遅れると全体も遅れるという意味ですね。

楊　：そうです。プロジェクトではクリティカルパスを検出し常に監視することが重要なのです。

張　：ＰＤＭの有効性と重要性は良くわかりました。すぐ活用したいですね。

前田：慣れないうちは戸惑うかもしれませんが、すぐに慣れますから今回のプロジェクト計画づくりでは是非チャレンジしてみましょう。

1-4-② ＷＢＳ，ＰＤＭ、ＷＰから作業工数を算出について話し合う：

（会話の前提）
前田さんは、プロジェクトのマスタースケジュールを作成するためにＰＤＭを使うことになり、コアメンバーの同意を得ました。ＰＤＭから作業工数の把握について話し合うことになりました。

前田：みなさんのご苦労のおかげでＰＤＭは完成しました。ここからは、各分担分野の作業工数を算出してください。

楊　：では私の担当分野はハードウエア開発なのでその範囲の作業工数をまとめます。

劉　：私の担当分野は電子回路開発です。

張　：私の担当分野はソフトウエア開発です。

前田：なにか質問はありませんか？

張　：作業工数は、作業の難易度によって工数が変わります。それと作業の内容によっては特定のＳＥにしかできないことがありますが、その場合はどのようにすればいいのですか？

前田：作業の難易度については、今までに蓄積された生産指数を参考にしてください。また、新しい技術を使う場合や、特定の技術を持った技術者に　　しかできない作業については、見積りした作業項目（ワークパッケージ）はどれか明確にしておく必要があります。

張　：わかりました。

前田：楊さん、劉さんはなにか質問はありますか？

楊　：いま張さんが質問したことに関連してですが、作業項目の特別に記述する場合はＷＢＳ辞書で明確にしておくべきと考えるのですが、それで良いのでしょうか？

前田：楊さん。私の説明を補足していただきありがとう。特に記述しておくべき事柄はＷＢＳ辞書に記述することが大切です。ＷＢＳ辞書は語句の意味を記述することではなく、その作業項目が関係する制約条件を記述しておくことです。

劉　：ＷＢＳ辞書の役割も大きいですね。

前田：ＷＢＳ辞書を充実しておくと、作業の見積り、要員の確保、作業を担当する人のミスや手戻りが少なくなり作業全体の品質も良くなります。

張　：ＷＢＳにすべての注意点を記述するには大変な労力が必要ですね。

前田：その通りですが、計画、準備段階に十分な労力を使うことが、結果的には労力を少なくすることができます。

楊　：私の経験ですが、成功したプロジェクトをレビューすると、計画段階にしっかり時間をかけていました。

前田：それは良い経験をしましたね。計画や準備を大切にするのはプロジェクトに限らずどのような仕事でも適用する仕事の進め方ですね。

張　：良くわかりました。今のお言葉は大変重要ですね。肝に銘じておきます。

前田：では、次に進みましょう。

1-4-③ 作業工程を基にスケジュール表を作成について話し合う：

（会話の前提）
前田さんがＰＭを担当するプロジェクトは、完成したＷＢＳを基にしてタイムスケジュールを作成することになりました。楊さん、劉さんはスケジュール表策定の経験がありますが、張さんはあまり経験がないようです。そこで、前田さんはスケジュール表の作り方についてコアメンバーと話し合うことにしました。

前田：ＷＢＳも完成したのでタイムスケジュール表の作成に取り掛かりたいと思います。タイムスケジュール表はプロジェクトの進捗管理をする重要な資料になります。

楊　：各担当分野のスケジュールとの結合が必要になりますね。

前田：そうですね。最終的には３つの開発分野（ハードウエア、電子回路、ソフトウエアの開発作業）のスケジュールを合成する必要があります。

張　：担当分野ごとのスケジュールで作成管理すれば良いのではないですか？

前田：各開発分野の進捗管理はそれで良いのですが、プロジェクト全体のタイムスケジュール管理や、要員調達の段取りに重要なのです。

張　：なるほど、そういうことですか。自分の担当分野だけを考えていましたが、プロジェクト全体のことを考えないといけないのですね。

前田：日本の言葉で部分最適、全体最適という言葉があります。ご存知ですか？

張　：なんとなくわかる気がしますが、どのようなときにその言葉を使うのか良くわかりません。

前田：ちょっと難しい言葉ですが、中国語でも同種の諺があるのではと思います。

張　：それは「部分的な視点には適合するのではなく、全体的な視点で適合していること」を意味するのでしょうか？

前田：すごい！正解ですね。さすが張さんお見事！です。

張　：前田さんにそこまで褒めていただくと「超（張）嬉しい！」です。

前田：張さんは言葉遊びもお得意のようですね。ついでに中国語ではこのような場合はどう表現するのか教えていただけませんか？

張　：いや、本当に恥ずかしながら、適切な中国語の言葉は知りません！

楊　：では、私のほうからお答えしましょう。このような場合は中国には「以偏概全」という四字熟語があります。

前田：それはどのような意味ですか？

楊　：一部をもって全体を論ずるべきではないという意味です。ちょっと否定的な意味の四字熟語ですが、意味は前田さんのおっしゃった意味とほぼ同じです。

前田：さすがベテランの楊さん！私の中国語の勉強になります。謝謝你的好意！

張　：前田さんの中国語会話力も凄いですよ。

前田：ところでＷＢＳからスケジュール表作成の目的や進め方も理解されたようですね。では、出来がりましたら皆さんと調整しましょう。みなさんよろしくお願いします。

1-4-④ 作業に必要な要員の確保について話し合う：

（会話の前提）
スケジュール計画が出来上がり、各作業に従事するプロジェクトメンバーをアサインし、必要に応じて外部の協力会社への要員派遣要請も行う段階になってきました。あらかじめメンバーを想定しながら進めてきましたが、この段階では明確にする必要があります。

前田：では、みなさんの各分担分野での必要な要員の特性と要員数を提示していただけませんか？

楊　：私の方では指定された書式に記入いたしました。これを皆さんにお配りしますのでご覧ください。

前田：他のメンバーの皆さんからもご提出いただきましたのでこれで検討を進めますがよろしいですか？

劉　：電子回路開発は装着される電子部品の性能、機能に大きく影響されます。できるだけ最新の技術を使った部品で回路設計をしたいと考えているのですが少し不安要素があります。

前田：そうですね。新しい技術の特性を理解している開発技術者が確保できるかというリスクもありますね。

劉　：私の感じているリスクはそのこともあります。

楊　：他に感じているリスクもありそうですね。

劉　：そうです。実は要件定義書に書かれていることを実現するには、既存の使いこなした技術、つまり涸れた技術というか経験のある技術を使う方が安心なのですが。

前田：確かに開発技術者としては悩みどころですね。安易に既存の技術を踏襲していると、商品力の強さを創出できませんね。

劉　：私の判断を悩ましているのはそのことです。多少リスクがあっても新しい価値の創造という積極的なアプローチを選択するか、あるいは安全をとるかということですね。

楊　：それと、新しい技術を習得した開発技術者の確保ということですね。

前田：劉さんの悩みは良くわかりました。楊さんの言われている新商品の価値創造の視点も重要です。

張　：このような場合はどちらか片方を重視すると、片方が満足できないということになりますね。

前田：プロジェクトではこうした選択の場面はよくあることです。張さんの言われることは英語ではトレードオフといい、日本語では二律背反といいます。

張　：その言葉は聞いたことがありますが、今回のような場合はどうすればいいのですか？

前田：現実には良く考えて、可能性を追求した結果で答えを出すことです。新しい技術を使うことにこだわり過ぎるのも本末転倒です。プロジェクトは限られた制約条件の中で目的を達成することが重要なのです。

劉　：わかりました。可能性を追求して判断をしたいと思います。もちろん要員調達の制限もありますからその範囲内で結論をできる早く出します。今日は、それ以外のところの要員について提出します。

前田：外部の協力企業から適切な要員を確保できるか、その可能性も判断の条件として考えると良いですね。

第2章　進捗管理と変更対応の場面

2-1 キックオフミーティングを開催する

2-1-① プロジェクトメンバーを集めることについて話し合う：

（会話の前提）
プロジェクトの計画フェーズも完了し、実際に開発活動のフェーズに入ることになりました。プロジェクトのメンバーが全員出席して顔合わせをする場がキックオフミーティングです。当然、初めて出席する人もいます。外部からの協力参加するメンバーもいます。大きなプロジェクトになると担当分野のチームリーダーのみの出席になることもありますが、できるだけ多くのメンバーの出席を得て意思統一を図ることがプロジェクト成功の重要成功要因（ＣＳＦ：クリティカル・サクセス・ファクター）の一つです。

前田：プロジェクト計画も完了しました。皆さんにはすでにお知らせしていたように大日程計画（マイルストーン）で二週間後の月曜日にキックオフミーティングを開催します。

楊　：主要なステークホルダーの方々の日程調整は済ませています。開発担当分野の主だったメンバーには１か月前に連絡しておきました。

前田：それはありがとう。ところで場所の確保もお願いしておきましたが問題なく確保できていますか。

楊　：大丈夫です。ご安心ください。それとキックオフミーティングに必要な機材なども予約確保しておきました。

前田：それはどうもありがとう。

劉　：キックオフに出席していただく主要なステークホルダーのリスト（案）も作成しましたので内容的なチェックをお願いします。

前田：劉さんに出席者リストの作成依頼をしましたが、納期に間に合わせていただきありがとう。

劉　：どういたしまして。お役にたてて良かったです。

前田：では、さっそくステークホルダーリスト（案）の見直しをしましょう。リスト以外にも出席必要な人が漏れていないか再確認しましょう。

張　：私の担当するソフトウエア開発で、協力していただく協力会社のマネジャーがリストに記載されていないので是非参加者名簿に入れてください。

前田：それは重要ですね。ほかに漏れているようなところはありませんか？

楊　：社内の関係部門のところはすべて網羅されていますからこれで大丈夫と思います。

前田：では、私の名前でキックオフミーティング開催通知文書を発行します。合わせて電子メール文書にても通知しておきます。

張　：欠席者にはどのように情報を共有しますか？

前田：今回のプロジェクト専用に情報共有サーバーを立ち上げます。欠席者にキックオフミーティングで発表、配布した資料を閲覧するように指示してください。

張　：わかりました。指示をします。

前田：それはミニマムですが、基本はキックオフミーティングに出席することですから、安易に欠席を認めないようにしてください。

張　：確認ですが、私たちＰＬは開発担当の関係者の範囲をフォローすればいいのですね。

前田：はい、それで良いです。御社の経営幹部の方やプロジェクト発注者の商品企画部門などの主要なステークホルダーには、ＰＭ事務アシスタントから連絡し、私がフォローします。

2-1-② プロジェクトの目的、目標について話し合う：

（会話の前提）
プロジェクトを成功させるにはプロジェクトに参加するメンバー全員が、プロジェクトの目的や目標をよく理解していることだと言われています。 前田さんとコアメンバーは、キックオフミーティングでプロジェクト企画書を基に説明をおこないます。プロジェクトメンバーが理解を深めるにはどうすれば良いかについて話し合うことにしました。

前田：このプロジェクトの計画づくりの前に、みなさんと目的、目標の重要性について話し合ったことを覚えていますか？

楊　：もちろん良く覚えていますよ。

張　：そういえば、そんなこともありましたね。

前田：おやおや、もうお忘れになりましたか（笑）

張　：すみません。このところ準備で忙しくって！

楊　：まあ、話し合ったことを覚えているようですから、まだ、安心ですよ。

前田：劉さんはどうですか？

劉　：プロジェクトの目的は、当社の事業戦略の主要な計画の一つで、新商品開発によって当社と御社の事業を進展することですね。

前田：その通りです。

張　：そういえば、思い出しました。

前田：では、もう少し思い出していただきましょう。このプロジェクトの目標はどのようなことでしたか？

張　：それは、えーっと・・・思い出しました。目標は新製品開発のＱＣＤを守り計画通りにプロジェクトを成功させることです。

前田：そうです。良く思い出されましたね。安心しました。

張　：目的や目標は常に意識していないと徐々にぼやけてしまいますね。

前田：そこが重要なのですよ。誰でも目先の忙しさに目を奪われてついつい目的や目標を見失い易くなるのです。

楊　：私も同じような経験はあります。

前田：人間はすべてをずっと覚えているわけではありません。局面、局面によって必要な記憶をたぐりよせれば良いのです。

張　：ただし、うろ覚えの情報記憶ではだめですよね。

前田：そういう意味では常に想い出せるようにする工夫が必要です。

張　：思い出す工夫とはどのようにするのですか？

前田：一つだけの方法ではなく、いくつかの方法があります。一つ目は、今度のキックオフミーティングでは、最初に私からプロジェクトの概要と目的、目標について詳しく説明します。二つ目は、プロジェクト共有サーバーにも目的と目標をわかりやすく記載した文書をファイルしておきます。三つ目は、各開発室の目立ちやすいところに、大きな用紙で掲示します。いわゆる「見える化」ですね。四つ目は、みなさんにお願いしなければなりません。それは、皆さんがマネジメントする開発チームのなかで、時に触れ折に触れメンバーの認識を確認することです。これを地道に繰り返せば誰も忘れることはなくなります。

張　：つまりメンバーとのコミュニケーションが重要ということですね。

前田：そうです。アドホックなコミュニケーションも効果的ですが、定例の会議体などにおいても意識的なコミュニケーションが必要ということですね。

2-1-③ プロジェクト組織体制、機能について話し合う：

（会話の前提）
前田さんは３人のコアメンバーとプロジェクトの実行フェーズに向けて 組織体制、機能について確認の話し合いをすることになりました。 今回の組織体制はプロジェクト全体の責任者（ＰＭ）として前田さん、東莞の開発部門には、筐体構造設計開発製造の担当責任者（ＰＬ）に楊さん、電気電子回路設計開発製造（ＰＬ）の責任者に劉さん、プリンター制御ソフトウエア開発製造の担当責任者としています。それぞれの開発チームには外部の協力企業のメンバーもプロジェクト組織に構成されます。プロジェクト活動に関係する定常組織機能からもメンバーが参加します。代表的な機能として、要員調達、部品、機材の購買調達機能、品質管理機能、契約、特許など法務機能、実行中に、開発仕様の追加変更について意思決定する変更管理機能、プロジェクトへの支援、監査を行うＰＭＯ機能などがあります。

前田：今回のプロジェクトの組織体制と機能について、皆さんと私の認識に差異がないことを確認しておきましょう。

楊　：そうですね。お互いの認識が食い違っていると後で問題が起きた時に困りますからね。

前田：そうですね。同じ文書を読み説明を聞いても、人間の受け止め方、理解のあり方に差異が生じるのも事実ですね。

劉　：だからこそ認識を合わせておくことが重要ということですね。

前田：プロジェクトのなかで、開発や製造といった実務では比較的認識の差異が少ないのですが、プロジェクトを支える側面の機能については主観的に、自分たちの都合の良い理解をしがちになります。

楊　：確かにそういう場面は良くありますね。たとえばＰＭＯの機能に対しても、なぜもっとタイムリーに支援してくれないのかという不満を漏らす人がいますね。

劉　：他にもありますね。部品の調達が思うようにならないとか、派遣要員との契約が遅れて現場の必要なタイミングにあわないという不満の声を聞きます。

前田：そうした不満が多発すれば、プロジェクトの目的、目標に向かって協業する気持ちを阻害することになります。結果的にプロジェクトの成果にも悪影響をもたらすことになります。

張　：ではどういうことが必要なのですか？

前田：これは前にも話し合いましたが、人はどんな人でも、自分なりの価値観をもっています。

張　：価値観という言葉は知っていますが、それがプロジェクト活動にどのように影響するのですか？

前田：価値観とは、それぞれの人の考え方で、自分の生き方の基準となるものです。言い換えると自分がもっとも大切にしているものの見方、考え方なのです。

張　：それとここで組織体制、機能を再認識することとどのような関係がありますか？

前田：そうですね。どういう関係があるか要点を説明しましょう。重要なことは、それぞれの組織体制、機能に携わる人たちの役割、目的目標がなにかをよく理解することです。

張　：それですと私も十分理解しているつもりですが・・・

前田：大切なのはその人の立場に立って考えることです。表面的には誰でもその人の立場や役割を理解しているのですが、自分の身をその人の立場に置き換えて価値観はなにか考えてみることです。

張　：そこまでは考えたことはありませんでした。

前田：プロジェクト組織はいろんな機能で成り立っています。ある意味で人間の体と同じようなのです。足の小指一本が痛くても体全体が上手く動かないことと同じなのです。

張　：なるほど、そこまで考えてこそ組織も機能も力を発揮できるのですね。

2-1-④ 会議体、進捗報告の方式について話し合う：

（会話の前提）
前田さんはプロジェクトの各種の会議体と進捗報告についてコアメンバーと話し合うことにした。決定したことはキックオフミーティングでメンバーに説明することにしている。内容的にはプロジェクトの主だった会議体の目的と意義、その出席メンバーについて話し合う予定です。また、プロジェクト活動の進捗状況報告のあり方についても話し合うことにした。

前田：再来週の金曜日にキックオフミーティングを開催しますが、プロジェクトメンバーに、プロジェクトの各種の会議体とその目的について、また各階層の進捗報告のルールについて周知しておきたいと思います。この打ち合わせでは、その内容をコアメンバーの皆さんと再確認したいと思います。

張　：各開発チームの小グループの活動報告もその範囲ですか？

前田：そうです。すべての活動報告も統一された方式、ルールを適用します。

張　：すると活動報告体系によって行われるということですね。

前田：そうです。

張　：各チームの担当業務によって報告の間隔は異なると思いますが、すべて統一するということですか？

前田：各チームの進捗報告は、作業計画に基づいて行うことが原則です。もちろん個々の作業日程、作業内容によってすべて同じではありません。

張　：しかし、プロジェクト全体の報告会への関係もありますから、どこかでまとめておく必要があるということですね。

前田：そうです。みなさんから私のほうへの進捗報告をしていただく日程は計画で定例的に行います。　

張　：分かりました。私が担当するソフトウエアの開発に関する報告は私が掌握して報告いたします。

前田：プロジェクト全体の会議は隔週金曜日に行います。それに整合して報告していただくことになります。

張　：プロジェクト全体会議は隔週の金曜日の何時からですか？

前田：みんさんの都合に合わせたいと思いますが、劉さん、楊さんはいかがですか？

劉　：私は午前中が良いかと考えます。

楊　：私も午前中が良いと思います。理由は全体会議の結果を午後にはメンバー伝え、月曜日からのアクションに反映できます。

前田：そうですね。そのためにはみなさんは隔週の金曜日に報告が間に合うように、各サブチームの進捗会議を行っていただければと思います。

張　：わかりました。

前田：定例の進捗会議では、問題点とトピックスを要領よく簡潔に行いたいと思います。大きな問題や課題が緊急事態発生した場合には定例会議を待つのではなく臨時に検討会議を招集します。みなさんからも臨時の検討会が必要と判断した場合はご連絡ください。

前田：また、主要なステークホルダーへの進捗報告は私が主体となって報告を行いますが、みなさんも会議体メンバーとして出席をしていただく設定です。

2-2 進捗報告

2-2-① 計画と実際とのギャップ報告について話し合う：

（会話の前提）
前田さんは進捗報告のあり方について話し合うことにしました。進捗報告はプロジェクト作業の進捗状況を定期的に報告することになっていますが、正しくない報告がなされることが発生します。その原因は、進捗状況が人の見方によって異なる場合や判断の基準が曖昧になっている場合に発生します。ここでは、コアメンバーと判断基準について確認をすることにしました。

前田：みなさんは、プロジェクトの進捗報告が実態とずれていたという経験はもっていますか？

楊　：あります。あります。報告を受けて順調に進んでいると安心していたら実はそうでなかったという虚偽の報告を受けていたことがありました。

前田：それは大変でしたね。実は私にもそういう経験がありますよ。

楊　：前田ＰＭにもその経験がお持ちだったとは。

前田：誰でも、多少のことはあるのではないでしょうか？劉さんや張さんは、いかがですか？

劉　：私にもありますね。どうもおかしいなと思って現場の作業遂行結果を確認したらどうも違うなということがありました。

張　：私もあります。もっとも、私の場合は報告を受けた側でなく、報告をした側でした。

前田：張さんは正直な人ですね。大なり小なりそうした経験はみんなあると思います。しかし、プロジェクトマネジメントの精度を上げるにはこうしたことを改める必要があります。

張　：そうですね。進んでいたはずの作業が遅れていたのではマネジメント上の大きな問題になりますね。

前田：そこで、そうしたことが起きないように皆さんと一緒にルールや基準を確認しておきたいのです。

楊　：それは良いですね。

劉　：どのようなことをルール化するのですか？

前田：まず、進捗状況の報告は着手した作業の捉え方を統一しておきましょう。統一基準として、作業に着手した時点で進捗率をどう計上するかの取り決めが必要です。

楊　：そうですね。サブチームや個人で計上の基準は統一しておくことは重要ですね。

前田：今まではどのようにされていましたか？

楊　：作業に着手した時点で計画作業の２０％を計上し、完了した時点で残りの８０％を計上していました。

劉　：私のところでは、着手時点では５０％、完了時点で残りの５０％を計上していました。

張　：私のところでは、着手時点では０％と計上し、完了した時点で１００％計上していました。

前田：ありがとう。皆さんのご意見を参考にしながら、統一ルールを決定しましょう。

楊　：それぞれ一長一短がありますが、いずれでも決めればそれに遵守したいと思います。

劉・張：私もそれで結構です。

前田：では、進捗数値の見かけ上の振れ幅が少ない平均的な５０％ルールで統一しましょう。

2-2-② 作業が遅れている状況（事実）について話し合う：

（会話の前提）
前田さんは定例のプロジェクト進捗会議でソフトウエア開発チームの作業が 遅れているという報告を受けました。計画した作業のうち、どの作業が遅れているのか詳しく状況を確認することにしました。

前田：みなさんご報告ありがとうございました。先ほどの報告の中で張さんが担当するソフトウエア開発チームの進捗が遅れているという報告がありました。他の担当分野はオンスケジュールで進捗しているようなのでソフトウエア開発チームの状況をお聞きしたいと思います。

楊　：そうですね。それが良いかと思います。

張　：では、私の方からもう少し詳しく状況を説明します。いま遅れているのはプリンターに接続するさまざまなＰＣからプリント要求に対するコントロールプログラムの開発作業です。

前田：なるほど。プリンターソフトウエアとしては重要なところですね。

張　：はい、この部分は外部の協力会社のＳＥに参加して共同で開発しているところです。

前田：ソフトウエア開発の全体計画との関係で余裕はどの程度ありますか？

張　：当初計画では２０日間の日程を見込んでいましたが、現状は計画の半分程度の進捗です。

前田：そうですか。その開発にはかかる工数の内、計画では、社内の開発者は２名が参加し、協力会社の技術者が４名と予定されていますが、それは計画通りに進んでいるのですか？

張　：実は、協力会社の技術者は当初予定通り４名なのですが、技術スキルが少し不足しているらしいのです。

前田：それは、どうしてそのように思われたのですか？あなたが実態を確認されたのですか？

張　：はい、社内メンバーから相談があり、開発作業の進め方や開発した内容を確認した結果、そう判断しました。

前田：なるほど。そういうことですか。協力会社側の責任者とはどのような話をしていますか？

張　：協力会社の責任者には、遅れている状況を伝え、スキルの確かな人材に変更してほしいと伝えましたが、早急にスキルの高い要員を選抜するので少し待ってほしいとのことです。

前田：そうですか。もう少し待つというのはどの程度の期間のことですか？

張　：来週の前半には大丈夫ということです。

前田：それで、計画遅れを取り戻せるということですか？

張　：はい、他の作業との関係でバッファ（余裕）があるので何とか数日の遅れで回復できると思います。

前田：わかりました。最大で３日間の遅れになるということですね。協力会社との交渉で必要であれば私も同席しますから遠慮せずに申し出てください。

張　：分かりました。頑張って計画の遅れを取り戻したいと思います。

2-2-③ 作業が遅れている原因について話し合う：

（会話の前提）
前田さんは次の進捗会議で、張さんからその後の進捗報告を受けました。 前回の報告では、協力会社からスキルの高い技術者を派遣して遅れを取り戻すとのことでした。確かに新たに開発技術者が参加しましたが、開発作業の遅れはあまり進捗していないようです。前田さんは他にも開発を遅らせている要因があるのではと見ています。そこで、進捗報告会の終了後、ソフトウエア開発責任者の張さんと原因について話し合うことにしました。

前田：張さん、早速ですが開発状況について、困っていることや、お気づきのことがありましたらなんでも結構ですからお話していただけませんか？

張　：そうですね。ご心配をおかけして申し訳ありません。協力会社の派遣技術者のスキルレベルに問題があったことは前回の報告会でお話しましたが、それだけではないように思えてきました。

前田：ほう、そうですか。どのようなことが気がかりなのですか？

張　：今回、新たに参加されている開発技術者は、ベテランで確かに開発経験もありますが、通信ネットワークに関するところはあまり経験がなさそうなのです。

前田：なるほど。それは困りますね。

張　：要求仕様書や要件定義書にかかれていることを理解するために時間がかかっているようなのです。それと、今までに進めてきた開発部分との関係を理解するにも予想以上に時間がかかっているようです。他のメンバー（社内の開発技術者）からも事前に説明を行い大丈夫との判断をしていたのですが・・・

前田：張さんもご存じだと思いますが、他人の開発したプログラムを引き継いで開発するには、それなりの時間が必要になりますね。

張　：確かにその通りなのですが・・・

前田：張さん、開発納期にはまだ少し時間がありますね。作業の納期内完了は重要ですが、ここは、慌てず、手続きを踏んできちんと開発目的と目標について理解を深める必要がありますね。

張　：そうですね。少し性急に成果を求めすぎていたかもしれません。もし、自分がその開発技術者の立場になれば、情報も目的も理解しないで直ぐ開発に取り掛かれと言われても無理かもしれませんね。

前田：張さん、そこですよ。大事なポイントは。どのような仕事でも、人は強制されてもなかなか自発的に動けないものです。ましてや、ソフトウエアプログラムの開発という作業は頭の中で論理性を追求しながら取り組む仕事です。

張　：良くわかりました。プロジェクトでもいかにメンバーが動きやすい環境を作るか、マネジメントの立場にある人間の責任だと思います。

前田：ほかにも仕事の生産性を阻害する要因はあるかと思いますが、人間関係における阻害要因が成果に大きな影響をもたらすと言えます。これからも様々な阻害要因が出てくると思いますが、張さんだけでなく私も先頭に立って力を合わせて取り組みたいと思います。

2-2-④ 作業遅れを回復する施策について話し合う：

（会話の前提）
前田さんは張さんからソフトウエア開発の作業が計画より遅れていると報告を受けました。張さんは開発の遅れの原因は協力会社から参加している技術者のスキルを問題にしているようですが、自らのマネジメントが性急すぎたとの反省もあるようです。そこで遅れを取り戻すためにどのような対策が必要か前田ＰＭと話し合い、アドバイスをもらうことになりました。

前田：張さん、遅れの状況については良くわかりました。また、その原因も大体わかりましたが、もうすこし原因を絞り込んで、今後の対策を話し合うことにしませんか？

張　：そうですね。そうしていただくと私も安心です。

前田：このような経験は以前にありましたか？

張　：はい、全く同じではありませんが、似たようなことはありました。

前田：その時はどのような原因でしたか？

張　：その時は、とにかく納期が迫っていたので上司にお願いして開発要員を増員してもらいました。

前田：なるほど。それで作業の遅れは取り戻せましたか？

張　：はい、なんとか納期までに完了することができホッとしました。

前田：繰り返すようですが、作業遅れの原因はどのようなことでしたか？

張　：やはり、開発者個別の問題ですが、開発の手戻りや、手直しが多く、スキル的に問題があったように思います。

前田：いま、個別の問題といいましたが、具体的にはどのように対応されましたか？

張　：遅れている開発技術者の担当作業量を減らし、新たに投入した開発技術者に振り分けました。

前田：なるほど。負荷分散したということですね。

張　：そうです。

前田：それで納期には間に合ったということでよかったのですが、追加した人員コストが増加しプロジェクトのコスト的な面では計画より超過したということですね。

張　：その通りです。

前田：そして、もう一つ気になることがありますが、作業量を減らした開発技術者はその後どうなりましたでしょうか？

張　：やはり自分の力がないということで、少し落ち込んでしまいました。

前田：そうでしたか。なかなか現実的には時間的制約もあって難しいのですが開発技術者の気持ちも大切にしないといけないということですね。

張　：私も反省したのはそのことでした。納期にばかり観点がいき、個人のプライドとかモチベーションにまで心配りができていなかったように思います。

前田：そこですね。大切なところです。プロジェクトは、マネジャーの力だけで成功できるものではないのです。長期的にはメンバー一人ひとりのモチベーションが大切です。対策のメリット、デメリットも良く吟味しておこなう必要がありますね。

張　：そうですね。今回もそこを良く考えた対策案をとりたいと思います。

2-2-⑤ 必要な支援策について話し合う：

（会話の前提）
張さんの担当するソフトウエア開発の作業に遅れがあることが明確になりました。前田さんと張さんは、作業項目の遅れているワークパケージを精査して新たな要員を投入することにしました。目的はプロジェクトの計画通りの完了することですが、現在作業を担当している開発技術者からの意見も良く聴き、作業の配分を検討することにしました。

前田：張さん、作業項目のうち、遅れている作業も明確になりましたね。ＰＭＯの王さんも呼んでいます。今後の支援策について煮詰めていきたいと思います。

張　：遅れている作業の内容ですが、ネットワーク通信に関係するところを重点的に支援策を打てば問題解決に大きく前進します。

前田：今作業を担当しているＡさんの意見はいかがですか？

Ａ　：いろいろとご心配をおかけして申し訳ありません。私の意見ですが、いま張さんが言われたところが、作業遅れの大きなところです。このワークパッケージにご支援いただくと大変助かります。

前田：このワークパッケージへの作業着手はいつから始めるといいですか？

Ａ　：そうですね。全体との作業のつながりもありますので、来週の後半に着手できれば大丈夫と思います。

前田：必要な要員について具体的なスキル要件は明確になっていますか？

張　：はい、Ａさんとも相談したのですが、当部のメンバーではないのですが、今、別の商品開発プロジェクトでやはりネットワーク通信の関係を担当されているＢさんが最適なのですが。

前田：ＰＭＯの王さんはどうですか？このＢさんのスケジュール状況はわかりますか？

王　：確かにＢさんは、ネットワーク通信技術開発のベテランで優秀開発技術者で最適だと思いますが、担当しているプロジェクトの状況だとすぐには支援に回せないでしょう。

前田：そうですか。それは難しいですね。Ｂさんに匹敵する人は他にいますか。

王　：そうですね。ちょっとお待ちください。スキルズインベントリーシステムとプロジェクトデータベースシステムで検索してみましょう。

王　：ああ、おられますね。Ｂさんのレベル匹敵する開発技術者が。なまえはＣさんといいますが、ネットワーク通信デバイス開発部にいます。Ｃさんは、現時点ではどこのプロジェクトにも所属していないようですね。

前田：張さんとＡさん、私の方からＣさんの上司に支援以来の話を進めます。お二人は、支援いただく作業内容を具体的にしておいてください。王さん、ＰＭＯへの支援依頼文書は私の方で作成しますので、支援にともなう準備を整えてください。

王　：わかりました。早速準備に取り掛かります。

張　：私たちの方も早速準備にとりかかります。いろいろとお世話をおかけしますがよろしくお願いします。

Ａ　：ありがとうございます。これで私も安心して開発作業に取り組むことができます。

2-3 変更管理

2-3-① 変更要求管理の基本について話し合う：

（会話の前提）
プロジェクトでは、当初予定していた仕様に変更が必要となる場合があります。前田さんはコアメンバーの楊さん等と変更のルール・手続きについて話し合うことにしました。プロジェクトでの仕様変更は推進活動に大きな影響を与えます。安易な変更要求を処理することのないようにルール・手続きを明確にしておくことが大切です。

前田：みなさんはいままで仕様変更の変更要求で苦労されたことがあると思いますが、どのような経験がありますか？

楊　：私の経験は、設計段階になってからも仕様の変更要求が次次と発生し、変更の情報が関係者に正確に伝わらず混乱したことがあります。

前田：それは、変更情報伝達の問題ということでしたか？

楊　：いえ、それだけではありません。変更要求の発生源、（要求者）、変更要求の目的などが明確でなかったこともあります。

前田：他の皆さんはどのような経験がありますか？

劉　：私の場合は変更要求を受け入れるか否かが決定されていないのに、現場で作業を進めていたことがあります。

前田：なるほど、変更管理の問題ということですね。張さんはどのような経験がありますか？

張　：私の場合は、ソフトウエア開発ですが、変更によって作業工数が大幅に増加したにもかかわらず、開発納期は変更以前と同じという無理な要求でした。

前田：なるほど。それは困った問題ですね。変更管理の仕組みというよりも変更を受諾・承認したときの条件の変更を考慮していないか無視したということになりますね。

張　：そうですね。開発担当現場の意見を良く聴かずに変更の決断をしたことが原因だと思いますね。

前田：なるほど。みなさんからお聞きしことからもわかるように、変更要求の扱いを正しく行わないとプロジェクトの進捗に大きな影響を与えることが理解できたと思います。

楊　：そうですね。変更管理の仕組みとそれを運用するルールが重要だと思います。

前田：そのとおりですね。今回のプロジェクトでは変更管理の仕組みとルール、組織体制も明確にしておきたいと思います。

楊　：プロジェクトでは変更要求があることは当然であると思います。しかしその取扱いを間違えるとプロジェクト成功どころか失敗の大きな要因になります。

前田：皆さんの貴重な経験を無にしないためにも、ＰＭＯやＱＡ部のサポートも得ながらしっかりとした変更管理を扱う組織（変更管理委員会）を確立し、プロジェクトを進めていきます。

2-3-② 変更要求内容について話し合う：

（会話の前提）
前田さんは、商品企画部より新たに出された変更要求申請の内容について重要な意思決定が必要と判断しました。変更要求の内容は電力消費量を当初仕様より２０％削減したいとの要求案です。プリンター機器の消費電力の主要なところは、インクを用紙に熱融着装置機構です。電力消費を抑えるためには融着の温度を下げることが主要な手段となります。しかし、融着温度を低下するとインクの不完全融着や融着プロセスのスピードを上げることができなくなります。電力消費とプリント品質、プリント速度との関係でトレードオフが発生します。意思決定をするために電気系担当ＰＬの劉さんと話し合うことにしました。

前田：今回の変更要求は商品の販売にも大きな影響のある内容ですが、まず最初に電気電子回路の設計担当責任者である劉さんのご意見をお聞きしたいのです。

劉　：そうですね。率直に申し上げて、今から設計変更をすると、プロジェクトのスケジュールにも大きな影響がでてきますね。

前田：ある程度のスケジュールに影響を出るのはやむをえないでしょう。その前に、技術的な見通しとしては可能性はありますか？

劉　：もちろん、技術的な可能性はあります。但し、さまざまな要素が関連してくるので簡単ではありません。

前田：特に気がかりなところはどのようなことですか？

劉　：私が予測している一番気がかりなところは、インクの融着プロセスですね。消費電力を抑えるにはこの部分がもっとも大きなところです。

前田：なるほど。私もそれは十分に理解できます。

劉　：前田ＰＭもご存じのように、融着プロセスは、プリンターの品質にも大きな影響を持っています。プリントされた印刷が融着不足であると、大きな品質問題になります。

前田：そうですね。劉さんには、いい対策案はありますか？印刷品質と、消費電力どちらもこれからの新商品には不可欠なようですが、これを達成しないと商品の販売への悪影響も考えられます。

劉　：それは、私も十分承知しているのですが、これから設計変更から取り組むと少なくとも１か月近くのロスになりますね。設計技術者の追加も必要になってきます。

前田：わかりました。設計技術者はどのくらいのレベルの人が何人必要ですか？

劉　：そうですね。現在までの設計してきた他の部分の設計変更に１名、新規設計に取り組む技術者が１名、合わせて２名は必要ですね。

前田：分かりました、そのほかに必要なことはありますか？

劉　：融着プロセスに関連して、印刷インクの成分である高分子のポリマーの特性にも影響が考えられますので、この分野に詳しい科学系技術者との共同で開発実験が必要になると思います。

前田：わかりました。それは生産工場部門の責任者と相談し、人材の支援を要請します。

劉　：ありがとうございます。しかし、現時点では、まだ大きな枠組みで捉えているので、今後さらに支援していただく事項が発生する可能性があります。そのこともご了承いただければ変更要求に取り組めると考えます。

前田：分かりました。そのようなことが発生するようであれば、その時点で対応します。

劉　：それでは、さっそくチームに戻り、メンバーに変更要求事項について伝えます。

前田：忙しいところ、大変なことをお願いしますが、是非、いい新商品で作りに力を結集してください。よろしくお願いします。

2-3-③ 変更要求が工程に及ぼす影響について話し合う：

（会話の前提）
前田さんは、新商品の消費電力抑制の変更要求を受諾について検討を進めています。 その検討の結果、設計変更をすることになりました。当初のプロジェクトスケジュール計画にできるだけ順守することを前提にしていますが、機構開発工程、ソフトウエア開発工程への影響も考えられます。そこで、各担当責任者と変更の影響について話し合うことにしました。

前田：昨日、劉さんと話し合った消費電力の抑制の変更要求の件ですが、約１ヶ月程度の追加変更作業は必要とのことでした。これには２名の設計者を増員が可能になりました。今日は、他の担当分野ＰＬの方から開発工程への影響について意見をお聞きしたいと思います。

劉　：プリンターの消費電力の大きな要素は、印刷インクの融着工程が大きいことは良くご存じだと思いますが、他のプロセスでも使用する電力消費　を抑制していただけると大変ありがたいのです。

前田：そうですね。設計にも余裕ができますからね。

張　：否定的なことを言って申し訳ないのですが、私のところはソフトウエアプログラム開発が主体ですから消費電力の抑制にはあまりお役にたてないのではと考えているのですが・・

劉　：たしかに、ソフトウエア開発のところでの電力消費の抑制は期待できないようですね。

楊　：それは、そうですね。しかし、電気・電子回路やソフトウエアをローディングする電子部品には選択の余地があるのではないでしょうか？

張　：確かにそれはありますね。ディスクの読み取り装置や、ディスプレイパネルの液晶部品や指示ランプなども微力ですが電力を消費しますね。

楊　：私の担当する機構部分にも改善の余地はあると思います。例えばプリント用紙を走行させる駆動モーターの電気特性や、歯車、ベアリングなどの軽量化、摩擦係数の低い材質を選ぶことなどがありますね。

前田：みなさん、積極的な意見、アイデアをたくさん言ってくれてありがとう。まだほかにも電力消費量の抑制対策はあるのではないかと思います。

楊　：そうですね。まだまだ出てきそうですね。

前田：提案ですが、もう少しブレーンストーミング的に対策案を絞り出してみませんか？そして、技術的な可能性とプロジェクトのＱＣＤ目標に照らし合わせて費用対効率・効果の高い項目を選択してはどうでしょうか？

楊　：それがいいですね。そのうえでＷＢＳ（ワーク・ブレークダウン・ストラクチュアー）に反映する必要があります。

劉　：私も賛成です。当然ですがＷＢＳの変更からスケジュール計画、ＰＤＭ（プレシデンス・ダイアグラム・メソッド）への反映、開発コストへの反映、納期の見直しにも影響しますね。

張　：いろいろと変更によって影響を受けますが、顧客に喜ばれる良い品質の商品づくりには、私も大いに賛成です。協力します。

前田：では、もう少し検討をしてみましょう。度々集まるのも大変なので、あと１時間程度で対策案をまとめましょう。その状況を見て正式に変更要求を受諾することにします。

2-3-④ 変更要求の受諾可否および付帯する条件について話し合う：

（会話の前提）
前田さんは、商品企画部より提出された変更要求事項についてプロジェクトのコアメンバーと検討を進め、変更要求事項を受諾する方向付けをしました。　 前田さんは、競争力の強い商品を開発することには異論はありませんが、プロジェクトオーナーである、商品企画部に対し、変更に付帯するさまざまな条件を提示し、承認を得ることがプロジェクトを成功に導くためのＰＭの責任と捉えています。

前田：コアメンバーの皆さんにご相談することがあります。先の電力消費量の２０％抑制というテーマに対して、各担当分野から抑制策案、改善策案を多数出していただきました。この中から有力な案を採用することでプロジェクト目標を達成できると判断しています。

楊　：私も皆さんから出された、抑制策案、改善策案を実行すると成功するのでは感じました。

張　：私は、プロジェクト成功のための条件として、これらの有効な施策を実現する確証が必要だと考えています。やる気だけではなく、後ろ盾となる支援条件を整えることが重要と思います。

前田：流石、張さん。私もその通りだと考えています。裏付けがなくやる気だけでは無理ですね。今日の会議の目的は、実はこの付帯条件のことで皆さんからのご意見をお聞きしたいというわけです。

張　：そうだったのですか、相変わらずの性急さで面目ありません。

前田：いやいや、あなたの言われることはもっともなことです。そんなに恐縮しないでください。ところで、劉さんからは以前に条件として設計要員の増員がありました。他のコアメンバーの方からも対策案実施に関する支援要求事項を出してください。

劉　：私は２名の設計要員の増員をお願いしましたが、試作に関する費用を追加予算に含めてほしいです。

前田：試作費用ですね。分かりました。金額はどのくらいか試算されていると思いますが、あとで書面で報告してください。

劉　：もう一つ、大きな支援依頼事項があります。開発後に行う実機のテストの要員を確保していただきたいことです。これは、直接開発要員としてではなく、品質保証部のなかで対応していただければと考えています。

前田：そうですね、それも重要な付帯条件ですね。新商品のなかでも、従来から実績のある既存技術へのテスト対応と同じではなく、新技術へのテスト対応として特別に取り組んでほしいということですね。

劉　：そうです。よろしくお願いします。

前田：楊さんの担当分野ではいかがですか？

楊　：私の担当するところはプリンター全体の筐体や構造を担当しますが、もともとの要求仕様条件に従来商品より３０％の小型・軽量化が条件でした。従って要員の増員などは不要です。

前田：わかりました。要員以外ではどのようなことが必要になりますか？

楊　：さらに消費電力３０％ダウンを実現するためには、筐体を構成する部品、部材のさらなる軽量化には原材料のコストアップも伴うので、材料原価計算に反映しておく必要があります。

前田：そうですね。購買計画、生産計画、生産管理にも影響しますね。関係部門にも協力要請をしておきます。この他にもありましたらお話ください。明日には、変更要求受諾承認の文書を発行します。追加事項がありましたら明日の午前中までにご連絡ください。

2-4 発生した問題への対応

2-4-① プロジェクトの前提条件が変更したことについて話し合う：

（会話の前提）
前田さんは、小型・軽量化したカラーレーザー・プリンター新商品開発プロジェクトマネジャーとして、極めて困難な課題に直面しました。商品企画部からの連絡で、プロジェクト予算の２０％削減を提示されたのです。当初計画から変更要求にともなうプロジェクト予算の増額を条件に合意していましたが、経営環境の見通しから減額をプログラムマネジメント会議で決定したとのこと。商品企画部では、開発納期は当初の予定通りでと言ってきています。これではプロジェクトの運営に多大な影響が出ることは必然です。前田さんは、ＰＭとしてなんらかの打開策を打つ必要があるようです。

前田：緊急に会議招集しましが、コアメンバーの皆さんに伝えたいことがあります。実は商品企画部長から緊急の打診がありました。明日のプログラムマネジメント会議で当プロジェクトの予算削減が決定されるとのことです。

楊　：それは大変なことですね。プロジェクトの前提条件が変わるということですね。

前田：そうです。現予算計画より２０％の削減計画だと聞いています。

劉　：先日、変更要求があり、受諾の条件として出したことがすべて取り消しにされたということですか？

前田：いや、必ずしもどこを削減せよという指定ではないので、全体として２０％の削減策を検討してほしいというメッセージですね。

張　：しかし、当プロジェクトは経営の重要な戦略的商品の開発と言われていたのです。これでは当初のプロジェクトの目的からして外れているのではないですか？

楊　：あなたの言いたいことはもっともなことですが、プログラムマネジメント委員会としても、経営全体から判断してやむをえないと判断している」のでは思いますよ。

張　：楊さんは“物分かりが良い”ですが、私は素直に納得できませんね。前田さん、プログラムマネジメント会議で強く反論していただけないですか？これでは私もモチベーションが上がりませんね。

前田：張さんの気持ちは、私も個人的な気持ちは理解できますが、企業経営の観点から考えないといけないのです。これは、我々のプロジェクトだけでなく、全社的な課題にどう対応するかということなのです。

劉　：今までのプロジェクトでも、このように前提条件が変わることがありました。確かに原則的には、前提条件が変更なのでプロジェクト計画から見直しが必要と言えますが、みんなの創意と工夫で乗り切ることができれば、それが最も成功への近道ではないかと私は思うのです。

張　：最も経験の少ない私が反発意見を述べてしまいましたが、これはメンバーの気持ちでもあるのです。

前田：張さんのメンバーの気持ちを重視した意見も重要だと思います。しかし、困難な事態に対して、できないと反発するだけでなく、どうすればできるかということを考えることも大切なことです。

張　：そうですね。プロジェクトメンバーを指導する立場では、そのことも考えないとＰＬとして力不足ですね。

前田：いやいや、力不足ということはないです。張さんのメンバーの気持ちを思いやることもＰＬとして重要なことです。さて、張さんの気持ちも十分に理解できたところで、楊さん、劉さんの意見や経験も参考にして、みんなで課題解決に取り組みましょうか。

2-4-② プロジェクトの制約条件が変更したことについて話し合う：

（会話の前提）
前田さんがＰＭを担当するプロジェクトでは、プログラムマネジメント会議の決定でプロジェクト運営予算の２０％削減を指示されています。コスト削減の変更で、他の制約条件も影響を受けます。お客様に魅力ある商品としての品質を落とすことは致命的です。さらに事業戦略的な観点から、新商品リリースの時期を遅らせることも大きな影響をもたらします。ＰＭとして品質、コスト、納期（開発完了期限）ともに厳しいなかでの対応を迫られています。

前田：先日の会議で前提条件が変更になることについて話し合いました。今日は前提条件の変更に関連して、プロジェクト制約条件への影響を最小限にすることについて話し合います。

張　：連日の厳しい課題への話し合いですね。今日は否定的にならず前向きな意見を述べたいと思います。

劉　：おや、張さんどうしたのですか？いつもの張さんと雰囲気が違いますね？

張　：先日の会議で、いつも自分の立場でしか発言できていないことがよくわかりました。

劉　：張さんは、今までの行動様式を反省したというわけですか？

張　：劉さんは、私が反省したことに問題あるということですか？

前田：まあまあ、そんなに張さんを責めないでおきましょう。それよりも、制約条件について議論を進めることが大切です。

劉　：ハハハ、冗談ですよ。珍しく張さんが素直なので少しからかっただけです。

前田：では、早速ですが制約条件への影響について議論を始めましょう。

楊　：私が最も心配しているのは、品質への影響です。

前田：それは私も同感です。コスト削減で品質目標未達となることは、プロジェクトの目的にもそぐわないものです。

楊　：筐体の軽量化には、構成する材質によって影響を受けます。それ以外にも機構部品の軽量化も材質の要因が大きいのです。これらの材料の選択には、重量だけでなく、強度、耐久度、耐摩耗性、加工性と多様な品質特性によって購入コストも変動します。

前田：そうですね。コスト削減と適正な材料の選択はトレードオフの関係にありますね。

楊　：そうですね、単純にコスト削減を追求するだけでは、目標の小型・軽量化は達成できないですね。

前田：私はそこに問題解決の糸口があるように思うのです。困難な問題に直面してこそ新たなアイデアが生まれると思うのです。

楊　：困難に向き合うことが創造を産み出すということですか。

前田：創造には技術スキル的な要素だけでなく、“考え抜く”というプロセスが必要なのでしょうね。

楊　：つまり、ブレークスルーしなくてはいけないということですね。そう簡単ではありませんが、前向きにブレークスルー策にチャレンジすることにしましょう。

前田：そうですね。今までも様々な困難な課題を乗り越えてきた楊さんに期待しています。支援が必要な場合はいつでも私に相談してください。

楊　：よろしくお願いします。

前田：次に、劉さんの担当分野である電気・電子系統については、コーヒーブレークの後で話し合いましょう。

劉　：はい、よろしくお願いします。

2-4-③ プロジェクトメンバーが途中離脱したことについて話し合う：

（会話の前提）
プロジェクトの進捗会議の中で、ソフトウエア開発の張さんから、緊急問題の報告がありました。問題点の内容はソフトウエア開発チームのＡさんが体調を崩し緊急入院しました。Ａさんの担当分野は通信ネットワーク制御に関するプログラムの開発です。この分野は高いスキルを必要とします。 ＰＭの前田さんはＰＬの張さんと対応策について話し合うことにしました。

前田：先ほどの会議でご報告いただいた、Ａさんの件ですが、まずＡさんの病状はどのような状況ですか？

張　：はい、現在は痛みもなく、症状も安定しています。病気の原因究明のため、各種の検査を行なうそうです。今後の対応については医者と相談して決めるそうです。

前田：そうですか。まずは一安心というところですね。状況をみて、私もお見舞いに行くことにします。

張　：お忙しいのに、いろいろとご心配をおかけして申し訳ありません。

前田：いやいや。仲間のことですから当然ですよ。ところで、いまのお話だとＡさんの復帰は当分見込めないようですね。

張　：そうですね。仮に手術が不要であったとしても、退院後の療養も必要なようですから、このプロジェクト期間中の復帰は無理ではないかなと判断しています。

前田：主要な開発メンバーだけに大きな痛手ですね。Ａさんには十分療養していただくこととして、Ａさんの担当していた仕事をどのようにするか考えましょう。張さんはなにか対応策をお考えですか？ありましたら、そのお考えをお話いただきたいのですが。

張　：前田さんもご存じのように、Ａさんはこのプロジェクト開始の時に専門技術グループに要請し参加しています。もともと、貴重な技術者なのでＡさんの仕事を継続するにしても、適切な人材がいるか不安ですね。

前田：張さんの心配していることは良くわかります。この分野の開発が遅れるとプロジェクト全体にどの程度影響するかも把握する必要がありますね。

張　：Ａさんの担当する開発作業項目をＷＢＳとＰＤＭで調べてみました。この文書が調査結果です。

前田：なるほど。まったく余裕がないわけではないが、１０日間程度の余裕では、Ａさんの復帰に期待することは無理ですね。

張　：そうですね。ここは他の部門に応援をお願いして乗り切るしかないと思います。

前田：そうですね。仮に新しい応援要員を確保できたとしても、資料の読み込みや他の開発メンバーとの調整で２，３日は見ておく必要がありますね。

張　：そうです。Ａさんが緊急入院する前に、私と他の開発メンバーに残した引き継ぎの要点をまとめた文書もあります。

前田：さすが責任感の強いＡさんですね。その資料があると応援者の作業も大いに助かるのではないでしょうか。

張　：Ａさんは体調が悪いのに、無理をして頑張ってくれていたのですね。もう少し早めに私が気付くべきでした。

前田：いや、張さんも自分の体調には気を付けてくださいね。では、私は早速、ＰＭＯと専門技術部のマネジャーと話をして、早急に応援要員を確保します。張さんは安心してお待ちください。

2-4-④ 技術的な問題が発生したことについて話し合う：

（会話の前提）
電力消費の抑制でプリンターのトナー（高分子紛体ポリマーインク）融着に取り組んでいた劉さんのチームでは、技術的障壁で苦戦していました。現状ではプリンターのインク融着の品質が安定しないことがわかりました。融着機能の熱源が低いためだということが分かっているのですが、熱源の温度を上げると消費電力が目標値を越えてしまいます。別の方法として用紙の走行速度を抑え融着時間を増やすということも考えられますが、プリンターの印刷速度が低下し既存のプリンターと同等レベルで新商品としての小型化、軽量化、高機能化、高性能化という点で目標を達成することができないのです。問題の報告を受けたＰＭの前田さんは、劉さんや関係する技術者を招集し対策を話あうことにしました。

前田：電気・電子回路設計担当の劉さんから報告を受けましたが、トナーの融着に関して技術的な問題に直面しています。みなさんからのご意見をお聞きし、問題解決に向けて話し合いたいと思います。

劉　：会話の前提で前田さんがお話されたように、難しい問題に直面しています。皆さんのご経験をヒントに打開策につなげたいと考えています。是非ご協力お願いします。

楊　：前に開発したプリンターでも同じような問題がありました。事情は少し異なりますが参考になるかもしれません。

劉　：それはどのようなことでしたか？

楊　：それは、特殊な用紙にプリントするプリンターでしたが、高速度プリンターとして、プリントプロセスの速度を早くしたためにトナーの融着が不安定になったことがあります。

劉　：なるほど。それでどのように解決されたのですか？

楊　：その時は、融着機能の温度を高めるように部品を変更しました。

劉　：すると、それで問題は解決したのですね。

楊　：確かにトナーの融着は安定化し、プリント速度も目標値を達成できました。しかし、融着機能の温度を高めたことによって、機内温度が高まり他の電気系統、電子部品への影響が出てきたのです。

劉　：そうだったのですか。それはまた別の問題を引き起こしたのですね。

楊　：そうです。当初はいい解決策だと安心していたのですが、技術的な問題は、全体のバランスをみて対策を打つことが大切ということが良くわかった例でした。

劉　：ところで、根本的な問題解決の方はどうなったのですか？

楊　：この時は、我々の開発では限界だということでトナーを開発している企業の開発研究者にお願いして、低融着温度でも可能なトナーの開発をお願いして難関を処理することができました。

劉　：なるほど。今回も同じような解決策があるということですね。

楊　：可能性はあると思いますが、これはトナー製造企業の研究開発者の意見を伺った方が良いと思います。以前の時より技術的には進歩していますから問題解決の糸口があるかもしれませんね。

劉　：流石！楊さん。ご意見ありがとうございました。なんだか解決に向けて明かりが見えたように思います。

前田：楊さんの経験が参考になりましたね。私の方は早速、購買部門を通してトナー製造企業の責任者の方に相談をしましょう。良い解決方法が見つかると嬉しいですね。

劉　：前田さん、是非、交渉よろしくお願いします。

前田：分かりました。早速取り組んでみましょう。

第3章　各種マネジメント実務の場面

3-1 クオリティマネジメント

3-1-① 品質保証の基本戦略について話し合う：

（会話の前提）
プロジェクト成果物の品質は最終的には、顧客の評価によって決まります。 前田さんは品質保証の基本的な考え方について、プロジェクトのコアメンバーと相互に理解を深めるために話し合うことにしました。 全社品質保証方針は、ＩＳＯ９０００を取得しており、それに準拠して品質方針を展開しています。

前田：プロジェクトの目的は小型、軽量で、ネットワーク仕様のカラーレーザープリンターを開発し、プリンター事業の柱とすることは、皆さんも理解されているとおもいます。

楊　：そのことについては、プロジェクト立上げの段階で目的、目標の確認の話し合いをしていますから良く理解しています。

前田：そうでしたね。今日はそれを前提にして話を進めたいと思います。劉さん、張さんもそれでよろしいですか？

劉　：はい、それで結構です。

張　：私もそれで結構です。

前田：では、話を先に進めます。品質保証の基本戦略は企業活動にとって極めて重要な要素です。魅力的な商品を提供する意思があっても、実態が伴わないと顧客ニーズに適合したとは言えないのです。

張　：それは、よく理解できます。良い商品だと思い買ったが、すぐ故障するようでは顧客はがっかりしますね。

劉　：がっかりさせるだけでなく、事故などにつながると大きな問題になることもあります。

前田：そうですね。現在ではＰＬ法（Product Liability:製造者責任）などで厳しく責任を追及されることが世界の潮流です。企業として利益追求のために製品の安全性や、品質に対して結果責任を問われるということですね。

張　：そういえば、電源トランスが損傷して、火災の原因になったという事故が問題視されたことがありましたね。

劉　：問題の現象は、電気回路の焼損ということでしたが、それが状況によっては、大きな事故につながるということですね。

前田：品質保証の重要性を、分かりやすい例で話していただきましたが、その通りです。こうした問題の要因はたくさんあると言えます。しかし、真の原因は、ちょっとした判断のミスや、作業のミスが引き起こしていることがよくあります。

張　：人間のやることですから、どこかにミスが出るのはやむを得ないのではないでしょうか？

楊　：確かに人間のやることにはミスや見落としはつきものですが、だからといって“仕方がない”では品質保証はなりたちませんね。

前田：張さんの言うことは本音ですが、楊さんの言われるのは企業が取るべき品質保証の基本姿勢です。本質的なの話がでたところで、もう少し話を進めましょう。品質保証は製品の欠陥にどう対応するかだけではなく、どうすれば欠陥のない魅力的な商品を提供できるか、商品づくりの、企画、開発、製造という上流から顧客に提供し価値実現を保証する全工程に対しての、基本的な考え方を明確にするということなのです。

張　：うーん、私は故障をなくするための規則というように一面的にとらえていましたが、奥が深いですね。もう少し詳しく知りたいですね。

前田：そうですね。今回のプロジェクトで実践しながら勉強していきましょう。

3-1-② 品質目標について話し合う：

（会話の前提）
前田さんは、全社の品質保証方針の話し合いから発展して、品質保証の勉強会を継続しています。今回はプロジェクトで開発する商品の品質目標を明確にすることを狙いとしています。話し合うメンバーは商品の各開発分野を担当するＰＬです。

前田：今回のプロジェクトで開発する商品の品質目標について理解を深めていきたいと思います。

張　：すこし気になった言葉があります。質問してもよろしいですか？

前田：どうぞ、ご遠慮なく質問してください。どういうことですか？

張　：前田ＰＭは、プロジェクトで開発する「商品」といわれますが、「製品」という言葉との違いには何か意味があるのですか？

前田：張さん、なかなかいい質問ですね。これからお話しすることは、実は言葉の意味に敏感であることが重要なのです。

張　：なんだか面映ゆいですね。

前田：大辞林という辞書には、「製品とは販売するために作られた品物、ある原料から作られた品物」とあります。「商品とは売るための品物、販売を目的とする財およびサービス」とあります。

張　：言葉の意味に大きな違いはなさそうですが。

前田：そうですね。この言葉には、物づくりや商売の歴史も関係しているようですね。今回の私たちが担当するプロジェクトは新型のプリンターを開発することが目的ですね。

張　：それは、よく理解しているつもりですが。

前田：そうですね。良く理解されていると思います。企業としては開発製造するだけでは目的を達成したことになりません。

張　：つまり、ものを作るだけでなく顧客に価値を提供できなければ、商品ではないということですね。

前田：ははは、ずいぶん理解が早いですね。張さんの言ったように、顧客が購入し、その価値を享受して、その代価を私達の仕事の収益となり、その収益でさらに顧客のニーズにこたえていくということですね。

張　：なるほど、製品とはものそのものであって、商品とは物にサービスなどさまざまな付加価値をも付け加わっているということですね。

前田：そうです。おっしゃる通りです。流石ソフトウエア開発のベテランですね。実はソフトウエアも商品ですが、物のように存在を見ることができませんね。

張　：そうですね。私たちの仕事は可視化しにくい、つまり視認性の難しさがありますね。

前田：話は発展し、ソフトウエアの視認性の話になりましたが、これも重要なことですね。話を元に戻すと、私達の作っているものは、単に物づくりではなく、顧客の要望に応えることのできる“商品”としての価値のあるモノづくりということができますね。私はそのことを意識して“商品”という言葉を使っています。

張　：なるほど。奥が深いですね。ところで今回は品質目標の話でしたが、この後はどうなりますか？

前田：ははは、少し横道にそれましたが、品質目標という点では大いに関係しますから安心してください。

張　：ああ、よかったです。

前田：今回のまとめとして、要約しましょう。張さんの担当するソフトウエアの開発も含め、品質の目標とは自分たちの作る側だけでの目標であってはならないのです。顧客側の立場に立って品質目標を考えてほしいのです。

3-1-③ 保証、保障、補償の意味について話し合う：

（会話の前提）
品質保証方針は企業経営の重要な要素です。プロジェクト活動も全社の品質保証方針に沿ってマネジメントすることが重要です。品質保証活動を正しく理解し、遂行するには関連する用語を正しく理解することです。前田さんはプロジェクト成果の品質目標を達成するためにコアメンバーと品質保証の基本となる３つの言葉を正しく理解するための話し合いをすることにしました。

前田：保証、保障、補償という言葉は、ベテランのみなさんもおられるので重複するかもしれませんが、確認と復習という位置づけで話し合いをしましょう。

張　：私は保証、保障、補償の意味を正確に理解できていないので、お教えください。

前田：わかりました。私の経験も交えてお話しましょう。その前に、３つの言葉について、みなさんがどのように理解されているかお聞きしたいと思います。どなたからでも結構ですが、・・・楊さんいかがですか？

楊　：それでは、私が理解していることをお話します。まず保証という意味ですが、商品では、その「商品が効用を発揮して価値を生み出すことを証明」するという意味に捉えています。

前田：流石！楊さん。その通りですね。いくら形が整っていても価値を産み出さないのでは顧客は困りますね。保証とは「この商品は価値を生み出す」ということを約束するということですね。

劉　：その約束を文書化したものが保証書というわけですね。

前田：そうです。その通りです。カタログや説明書に記載したことが約束事になります。では、次の言葉である保障という意味は？・・・劉さんいかがですか？

劉　：保証と保障の違いですね。なんとなく同じような意味だと思っていましたが、確かに文字が違いますよね。ええーっと、なにが違うのかですかねえ。・・・苦し紛れですが、たとえばこういう意味でしょうか？保障とは故障だとか、なにかあった場合、それを元通りにしてもらえるとか・・・そういう制度とか、約束ではないでしょうか？

前田：苦しそうでしたが、ほぼ正解ですね。保障とは保証したことが発揮できるようにするための、約束事です。例えば自動車が事故などでエンジンが故障することもあります。そうした場合に自動車保険で修理し、元通り動くようにできますね。このような不慮の事故、故障に対して、性能、機能を復旧し、自動車としての価値を発揮するための約束事を保障といいます。

劉　：その約束事を明確にした文書が保障契約書ということですね。保証とは意味がかなり違いますね。良くわかりました。

前田：それでは3つ目の補償という言葉について、お聞きしましょう。張さん、いかがですか？

張　：だんだん難しくなってきそうですね。補償という言葉の意味は、商品になんらかの品質的問題が発生した場合に、その事によって受けた損害に対して弁償するということだと思いますが、それで良いのでしょうか？

前田：正解です。さすが張さん、大したものです！

張　：いや、それほどでもないです！でも、正解でほっとしました。

前田：すこし付け加えると、保証には証明することが大切で、当事者がその証明された項目で納得して売買契約がなされるということ。保障はそのうえで事故発生等に備えて契約することをいいます。その結果で補償のあり方がきまります。

張　：なるほど、それぞれ単独での言葉の意味ではなく相互に関係があるということですね。良くわかりました。

3-1-④ 品質保証はプロセス管理が大切であることを話し合う：

（会話の前提）
前田さんは、プロジェクトのコアメンバーと品質保証のあり方に、戦略としての位置づけ、品質目標のありかた、言葉の定義について理解を進めてきました。効果的な品質保証活動は、問題の発生に対する処理を厳格にすることではなく、問題が生じないように事前の管理のあり方が大切です。そこで、前田さんは、プロジェクトにおけるクオリティマネジメント（品質保証管理活動）を、あり方を話し合うことにしました。

前田：皆さんと話し合い、品質保証活動にも、理解も深めることができました。引き続いて、プロジェクトで効果的な品質管理活動を行うマネジメントのあり方について話し合いたいと思います。

張　：プロジェクトと定常業務の活動ではマネジメントに違いがあるのですか？

前田：良い質問ですね。それでは、皆さんのお考えをお聞きしましょうか。張さんは、どのように理解されていますか？

張　：私は、プロジェクトでは時間が制限されてとても忙しいので、管理のポイントを絞ってやるしかないと思います。定常業務組織での品質管理は時間的にもゆとりがあるのでやり易いのではと羨ましいですね。

劉　：プロジェクトの品質保証のために管理をきちんと行うのは大変です。やはり要領よく管理する工夫が必要だと思います。

前田：なるほど。時間的にゆとりがないと管理の時間もとりにくいということですね。楊さんはどのようにお考えですか？

楊　：正直に言いますが、私も張さん、劉さんと同じように考えています。

前田：現実はその通りだと思いますが、そのために管理の工夫が必要だということですね。

張　：どのような工夫が必要なのでしょうか？

前田：そうですね。プロジェクト組織での品質保証活動も、定常業務での品質保証活動も計画し、実行するところは基本的には同じです。定常組織に比較してプロジェクト組織で違うところは、参加するＰＭ，リーダー、メンバーに流動性があることです。

劉　：確かに、そのところは大きく違いますね。

前田：もちろん、プロジェクトの背景によって異なり、プロジェクト組織のすべてがそうだということではありませんが、一般的には流動性が高いでしょうね。

劉　：その流動性の高いことが課題なのですね。

前田：そうですね。組織に参加するＰＭ，リーダー、メンバーが変わると、考え方や、行動のあり方も変わりますね。

楊　：それにプロジェクトの品質保証活動も他のマネジメント事項も同様なのですが品質保証活動に対する価値観も違いますね。

前田：そうですね。したがって参加メンバーとの意識合わせが重要になってきます。今回の話し合いもそのために行っています。

張　：なるほど。そういうことだったのですね。前田ＰＭは話し合いが好きだなあと思っていたのですが、これもマネジメントの一環なのですね。

前田：それもありますが、品質保証活動のＰＤＣＡを明確にしておくことが目的なのですよ。

張　：ＰＤＣＡは管理のサイクルと言われていますね。最初のＰつまり計画がしっかりしていないと、後で問題が起きるということですね。

前田：そうです。さらに問題の発生を防ぐために、行動の状況をよく観察し異常を発見する仕組みが大切です。つまり最終的な結果を見て対応するのではなく、途中の経過、プロセスをチェックして対応をすることが大切ということですね。

張　：良く理解できました。

3-2 コミュニケーションマネジメント

3-2-① コミュニケーションの重要性について話し合う：

（会話の前提）
プロジェクトのように時間的にゆとりの少ない組織活動では、参加する人々におけるコミュニケーションのあり方が、組織運営に大きく影響します。前田さんはプロジェクトにおけるコミュニケーションの重要性は十分に認識しています。今回の新しいプロジェクトでは初めて参加する人も多くいるようなのでコアメンバーとコミュニケーションのあり方について話し合うことにしました。

前田：みなさん、おはようございます。昨日の日曜日はとても良い天気でしたが、どのように過ごされましたか？

楊　：私は久しぶりに妻と郊外の植物公園に行きました。妻の大好きな薔薇の花がとてもきれいで妻はご機嫌でした。

前田：それは、よかったですね。奥様の好みを把握していたのですね。家庭でのコミュニケーションも良いということですね。

楊　：いえ、それほどでもありませんが、よく会話の中に薔薇の話がありましたので、たぶん薔薇が好きなのだろうと思っていました。

前田：劉さんはいかがでしたか。どこかに出かけましたか？

劉　：私は新しくできたデパートに妻と行きました。妻の洋服選びで私は大変疲れましたよ。

前田：それは、それは。お疲れ様でした。私も同じ経験をしていますよ。張さんはいかがでしたか？

張　：私は妻と美術館に行き、現代絵画展を観てきました。

前田：そうでしたか。奥様も絵画はお好きなのですか？

張　：はい、絵画の分野とは少し違いますが、大変好きなようです。

前田：みなさん、家族とのコミュニケーションは良好のようですね。プロジェクトでも皆さんのように良いコミュニケーションで進めたいですね。ところで、皆さんはこれまでのプロジェクト活動でコミュニケーションのことで困った経験はありませんか？

楊　：コミュニケーションのミスから大きな失敗になったことがありますね。

前田：そうですか。どのようなことが原因だったのですか？

楊　：私の伝え方が悪かったのですが、聞いたメンバーも自分の過去の経験から判断してしまったことが原因でした。

劉　：私にも同じような経験があります。伝えたつもりが伝わっていなかったということがあります。

前田：プロジェクトなどの時間的に制限の多い活動では、特にコミュニケーションを正確に行うことが大切です。情報としては相手が聞いただけでなく、コミュニケーションの目的を「理解している、納得している」ということを確認することが大切です。

楊　：その通りですね。つい忙しさに紛れて、確認を怠ると問題が起きます。

前田：さすが、楊さんは良く本質をご存知ですね。プロジェクトのコミュニケーションで大切なことはもう一つあります。それは、伝える内容を相手が心で受け止められるように相手の状況や価値観も意識してコミュニケーションすることが大切ですね。

張　：コミュニケーションの重要性が良くわかりました。私には難しそうなところもありますが、諸先輩をお手本にして頑張りたいと思います。

3-2-② コミュニケーションの構造について話し合う：

（会話の前提）
コミュニケーションには、日常生活で必要な基盤的スキルと仕事の中で必要とする専門的スキルに大別されます。当然のことながら基盤スキルが未成熟であれば専門的スキルも未成熟になります。前田さんはプロジェクトの中でコミュニケーションが極めて重要との認識を持っています。特に必要とされる専門的スキルについてコアメンバーと話し合うことにしました。

前田：コミュニケーションとは、いかに上手に話をするかということに理解されている場合が多いようです。もちろん、上手に話をできることも重要ですが、相手の状況をよく見て話あうということが大切です。

張　：前の話し合いでは、そのようにお聞きました。

前田：コミュニケーションの基本は相手の話を良く聴くということが最も大切なのです。コミュニケーションとは、いずれかが一方的に話すのでなく相互に交流するということが基本です。

張　：良く解りました。相手の話を良く聴くということですね。

前田：慣れてくると、ついおろそかになりやすいので、コミュニケーションの基本的スキルを再確認しました。次に専門的なコミュニケーションスキルの構造についてお話しましょう。

張　：コミュニケーションスキルを構造的に捉えるということですね。

前田：そうです。専門的コミュニケーションスキルを５つのスキルとして捉えます。適用するスキルは、①ヒアリング・インタビュースキルから始まり、次に②ディスカッションスキル、③ネゴシエーションスキル、④ドキュメンテーションスキル、⑤プレゼンテーションスキルの５つのスキルです。

張　：５つのスキルで構成されているのですか？とても複雑に感じますね。

前田：確かに一見複雑そうですが、皆さんが仕事の中で行っていることですね。コミュニケーションプロセスを意識的に見ると、このように５つに分けることができます。例えば、プロジェクトでソフトウエア開発が遅れるという問題が発生した事例で考えてみましょう。

張　：良くある例なので分かりやすいですね。

前田：問題が発生すると、関係者から状況をヒアリングします。開発技術者からも話を聞きます。どのようなことが、どこで、いつから、どの程度の問題が起きているか状況を正しく把握します。この正しくというところがヒアリングスキルの要点ですね。

張　：どのようなことが要点になりますか?

前田：そうですね。大きくまとめると要点は３つあります。１番目の要点は、話し手が話しやすい雰囲気つくりが必要です。そして、２番目の要点は、話を良く聴き、予断を混じえてはいけないということです。

張　：相手の話を聞きながら、自分の頭の中は別のことを考えてはいけないということですね。

前田：そういうことです。しかし、口でいうのは簡単ですが、実際の場面ではつい先を急いで、予断を混ぜて聞いてしまいがちになるのです。

張　：ヒアリングスキルだけでも奥が深いですね。

前田：そうですね。相手の話を良く聴くことは、コミュニケーションスキルの基本中の基本です。さらに必要な情報をうまく聞き出し、質問するスキルとしてインタビュースキルがあります。インタビュースキルもただ聞くだけではなく、聞くための準備が必要です。

張　：どのような準備が必要なのですか？

前田：質問したいことは、漠然としてではなく、なんのために質問するか、質問の目的も良く考えることが大切ですね。相手の価値観や行動様式も考えてヒアリングに取り組むための準備事項になります。

張　：インタビューも入念な準備が必要だということが良くわかりました。

3-2-③ ディスカッションスキルについて話し合う：

（会話の前提）
ディスカッションスキルとは、お互いの意見を確認し合う場面で必要なコミュニケーションスキルの一つです。プロジェクトにおける会議や話し合いでは、それぞれの立場から意見を出し合います。しかも、出席する人の立場が違うこともあり、当然、価値観や利害も異なります。ディスカッションスキルとは、こうした違いを踏まえて、目的、目標を達成するコミュニケーションスキルです。組織をリードする立場にある人は、ディスカッションスキルが重要という認識を持って会議や話し合いに臨むことが大切です。前田さんにコアメンバーからディスカッションスキルについてもっと知りたいとの話があり、ディスカッションスキルについて話し合うことにしました。

前田：専門的コミュニケーションスキルの２番はディスカッションスキルです。ディスカッションとは討論する、話し合うということですが、要点はお互いに意義の内容のある話し合いだったと言えることです。

楊　：確かに前田さんのおっしゃる通りなのですが、実際には上手くいかない時が多いのです。

劉　：実は私も同じです。どうすればいいディスカッションができるのでしょうか？

張　：先輩の方々もお困りなのですか？

前田：そうですか、みなさん全員がお困りなのですね。それは困りましたね。では、要点についてお話ししましょう。まず、ディスカッションスキルは５つの専門的コミュニケーションスキルの一部であるとの認識を持ってください。

張　：それだけですか？

前田：いや、まだ重要な要点はあります。これからお話します。ディスカッションに重要な要点は大きくは３つあります。その１番目はディスカッションの事前準備です。細かくいうと①目的を明確にする。②到達点の目標を明確にする。③話し合いの筋立てを考えることです。

張　：そうですが、日常の忙しい中では、なかなか準備する時間が取れないのです。

前田：そうでしょうね。しかし、忙しいという理由で、準備もなく会議や話し合いをしても上手くいかないのではありませんか？

張　：そうですね。そこが問題であり悩みですね。

前田：もちろん、忙しいときには忙しいなりの効率的な方法を取るべきです。準備しないよりは大きな違いがあると思います。少しの時間でもとる努力と工夫をされたらいかがでしょうか。

張　：分かりました。手抜きしては駄目ということですね。

前田：次の２番目の要点は、話し合いの進め方を考えてみることです。具体的には①どのテーマから話し合うか順番を設定する、②発言、意見を求める人を想定しておく、③話し合いの進め方をアジェンダとしてまとめておくことの３項目です。

張　：具体的でわかりやすいですね。

前田：３番目の要点は、話し合いの進め方です。事前に準備したことを活用することです。具体的な進め方としては①参加メンバーに会議の目的など主旨説明を入念にすることです。②特にはじめての参加する人には、話しやすい雰囲気を作り出すことです。そして③参加者は全員が発言、意見を言えるように配慮することです。

張　：なるほど。よくわかりました。

前田：まとめとしては、ヒアリング・インタビュースキルのところでも話しましたが、会議や話し合いに出席している人の行動様式や、価値観を把握していることも大事です。それと積極的傾聴（アクティブリスニング）を心がけることですね。

張　：お話になられたことに挑戦したいと思います。ありがとうございました。

3-2-④ ネゴシエーションスキルについて話し合う：

（会話の前提）
ディスカッションの目的は、意思統一または合意の形成ですが、必ずしも上手くいくとは限らないものです。その原因には双方の立場からくる利害の対立があります。こうした場合に双方の利害得失を調整する手続きが必要になります。この手続きを交渉（ネゴシエーション）と位置付けています。プロジェクト活動のなかでもネゴシエーションする場面は多く発生します。前田さんはネゴシエーションの要点についてコアメンバーと話し合うことにしました。

前田：プロジェクト活動の中では、ネゴシエーションをする場面が多くあると思います。みなさんのネゴシエーション経験をお聞きしたいと思います。

楊　：上手くいったこともありますが、なかなか合意できず苦労したことも多いですね。

張　：私の場合は、ネゴシエーションが必要な場合、上司と一緒に対応したが多いので自分が主体的に行ったことは少ないです。自分が主体的に行うとすれば難しいのではと感じています。

劉　：私も張さんと同じですが、最近は少し慣れてきたように思います。

前田：そうですか。私は「ネゴシエーションは苦手です」ということをよく聞きます。その理由は「相手側の言い成りにはなりたくないし、自分側の言い分を押し通すと相手側の心証を害し、ビジネスに悪影響がでるのではないかと、憂鬱になる」聞きますが、みなさんはどうでしょうか？

劉　：そうですね。わたくしもその様なことが気になる一人ですね。

前田：なぜ憂鬱になるのでしょうか。ここでは、その原因とネゴシエーションスキルの要点について話し合いましょう。大きくは２点あります。第１点は、立場によって損得の駆け引きをして自分の有利にと考えるからです。

張　：でも、それは当然ではないですか？その駆け引きが交渉ではないのですか？

前田：お互いに駆け引きでやりあっては、話の内容が厳しくなりますね。例えば「腹の探り合い」という言葉がありますが、お互いに「腹を割って」話し合うまでは相当の時間がかかります。特に初対面の人だと尚更です。

楊　：それまでの人間関係、信頼関係によっても左右されますね。

前田：第２点は、交渉では相手の立場、価値観より、自分の立場、価値観を優先すると人間関係、信頼関係は損なわれ交渉は難しくなります。

張　：難しいですね。どうすれば上手くいくのですか？

前田：まあまあ、そんなに急がないで！こうした問題を解決する交渉方法があります。それは、原則立脚型交渉ともいいますが、別の言いかたでは英語でWin-Win交渉方法ともいいます。原則立脚型とは、本来の交渉の目的が双方にとってどのような利得があるかをともに考え、いい解決方法を見出す方法です。明るく前向きな交渉方法だといえます。

張　：その方法で上手くいきますかねえ、少し軟弱な気がしますが。

前田：張さんがいわれたことは、相手に譲歩を矯正する方法ですね。その反対には、今回は、自分が譲歩するので、次は相手に譲歩を求めるという方法ですね。立場駆け引き型交渉の典型的な方法ですが、その結果、感情的なしこりが残るので憂鬱になるのです。

張　：そうですか、わかりました。しかし、そのためには準備が必要ですね。

前田：その通りです。張さん良いことを言われました。ディスカッションでもそうでしたが、事前の情報収集や分析なしでは交渉は上手くいかないのです。交渉も気合と度胸では失敗する公算が大きいでしょうね。

劉　：良くわかりました。交渉には状況の分析や情報も必要で、無計画では失敗するということですね。今までのやり方を反省して、原則立脚型の交渉で取り組みたいと思います。ありがとうございました。

3-2-⑤ 主要なステークホルダーとのコミュニケーションについて話し合う：

（会話の前提）
ネゴシエーションとは、日本語では交渉と言います。交渉は相互に利害関係が生じた場合、円満な解決つまり合意の形成にいたる話し合いをすることです。　　 例えばプロジェクトにおいて当初の予定していた要求仕様が追加変更の必要性が発生したとしましょう。一般的には新たな工数が追加されるため納期の延長、コストの増加が生じます。しかし、諸般の事情で既定の納期内とコストの抑制という発注者側の要望があった場合、受注者側では、そのまま素直に受け入れることはプロジェクト活動に大きく影響するために合意は形成されないでしょう。そこで前田さんは、商品企画部との話し合いでどのような条件であれば合意形成が可能になるかコアメンバーと交渉について話し合うことにしました。

前田：先日のプロジェクト報告会で、商品企画部から要求仕様について追加変更事項を受け入れてほしいとの要望がだされました。理由を聞くと、競合商品との優位性を強化するためには必要と判断できる内容でした。

張　：それはどの開発分野についての追加変更要望ですか？

楊　：まあまあ張さん！そんなに急がないで前田ＰＭの話をお聞きしましょう。

前田：みなさんが気がかりなことは尤もです。この時点でまた追加変更はスケジュールの組み直しにも考えなければなりません。今回の追加変更要求は、筐体の軽量化についてです。

張　：ソフトウエアのところではないのですね。よかったあ！

前田：張さんは安心されているようですね。でも影響ないことはないのですよ。

張　：えっつ！そうですか？　どのようなことがありますか？

楊　：筐体全体を軽量化するには構造だけではなく、部品の構造も、電気系統もさらには、動作をコントロールする制御ソフトにも影響を考えないといけないのです。

張　：そうですか。私のところには関係ないと思っていたのですがねえ。

劉　：ははは、それは、残念でしたね。

前田：張さん、そのくらいの楽天性があれば大丈夫ですね。ところで、この追加変更要求に対して皆さんのご意見をお聞きし、プロジェクトとして可能な条件を提示したいと考えています。

楊　：そうですね。筐体の軽量化については、この新商品には相当な対策を取り込んできましたが、更なる要求ということですね。もちろん可能性はありますが、素材のコスト高や生産作業工程でのコストも見込む必要があります。

劉　：筐体の軽量化となりますと電気部品、例えば駆動系のモーターなどの軽量化も取り組むことが考えられます。しかし、新たな部品となると製造メーカーとの関係もあり、部品コストや部品納入時期の調整が必要になります。

前田：わかりました。皆さんの創意工夫を最大限にお願いした対策を商品企画部には提示したいと思います。早速ですが、変更要求実現に向けたスケジュール、コストの見直し案を作ってください。

張　：その見直し案で商品企画部との交渉をするのですか？

前田：そうです。お互いに新商品開発という目的の実現に前提で話し合います。

張　：すこし、余裕を見た数字で交渉するようなことはしないのですか？

前田：交渉は双方の信頼関係が重要なのです。お互いに相手の様子を窺って駆け引き型の交渉は相互不信に陥りやすく合意形成が進まないのです。

楊　：いわゆるWin-Win型(ウィンーウイン型)交渉が重要ということですね。

前田：その通りです。相手に不誠実な駆け引き型の交渉や、力関係で相手に譲歩を強いるような交渉は結果的に失敗につながるといえます。

張　：そうですか？相手に譲歩を強いるのが上手な交渉だと思っていましたが大きな勘違いですね。本当の交渉のあり方が良くわかりました。

前田：張さんも機会があれば、是非、取り組んでみてください。

3-3 リスクマネジメント

3-3-① リスクマネジメントの概要について話し合う：

（会話の前提）
プロジェクト活動では必ず成功を阻害するリスク事象が発生します。プロジェクトマネジャーは多くの経験からリスクの発生を予測し、阻害要因への対応、対策をマネジメントする必要があります。リスクに対するマネジメントをリスクマネジメントといいます。リスクマネジメントはいくつかのステップで管理することです。前田さんはコアメンバーとリスクマネジメントの概要について話し合い、情報の共有を図ることにしました。

前田：今回のプロジェクトを是非成功させる気持ちは、皆さんと私も同じだと思います。しかし、プロジェクトでは思わぬことが発生し、成功を危うくすることが起こります。

楊　：そうですね。私にも失敗プロジェクトの経験がありますが、一寸したコミュニケーション不足から問題が大きくなったことがあります。

前田：そうですね。私にもいろいろと失敗の経験があります。楊さんの言われる一寸したことが大きな問題になったという経験ですね。

張　：ちょっとしたことってどのようなことだったのですか？差支えなければお話していただけませんか？

前田：もちろん差支えはないので、お話しますよ。それは、あるプロジェクトで新技術を使った開発を担当していたのですが、私は外部の協力会社の人と一緒にというか、教わる立場で参加していたのです。

張　：前田ＰＭの若かりし頃のお話ですね。

前田：まあそういうことですね。そこでの経験ですが、優秀と聞いていた外部の技術者が実はあまり経験がない人だったのです。私は信頼していたのですが、時々その技術者の独り言を聞いていたのです。「これは解らない」とか「ここは経験がない」とか。でも私は、「謙虚な人だ」と軽く受け止め、自分の担当する仕事をしていました。ところが、開発の中程になって、その技術者が出社しなくなったのです。

張　：なにかあったのですね。病気をしたとか？

前田：そうです。その技術者は開発に行き詰って心の負担が重くなりプロジェクトに参加できなくなったのです。

張　：するとだれか交代要員が必要になりますね。

前田：そうなのですが、実はその協力会社には新しい技術に熟知した技術者はいなかったのです。

張　：では、契約違反ですね。ペナルティですよね。

前田：もちろんそういうこともありますが、期待していた新技術による開発の見通しが立たず、開発スケジュールに大きな問題が生じたことです。

張　：それは大変なことでしたね。

前田：私が早期に開発技術者の言動に気づき、問題を察知し、上司に報告するなどすればよかったのですね。

張　：なるほど。自分以外へのことに関心が薄かったということですね。

前田：そういうことですね。このことから私は自分のことだけでなく周りにも関心を持つことにしました。プロジェクトではＰＭやコアメンバー以外のメンバーもプロジェクトへの関心を持ち、情報を共有することが重要と感じました。

楊　：私も同感です。

前田：リスクには、その影響度や発生頻度などいろいろな角度からの把握が大切です。そしてプロジェクトに参加するメンバーがどのようなリスクが想定されるのかリスクに関する感性を高めておくことが大切ですね。

張　：プロジェクトメンバー全員がリスクに無関心であることが大きなリスクということですね。

前田：さすが張さん、良いことを言いますね。その通りです。

3-3-② リスクリスト作成について話し合う：

（会話の前提）
プロジェクト方法論（ＰＭＢＯＫなど）にはリスクマネジメント計画の重要性に触れています。プロジェクトのリスクはプロジェクト発足背景や内容によって異なりますが、多くの経験によって典型的なリスクもあります。前田さんはコアメンバーとリスクリストの重要性について話し合うことにしました。リスクマネジメントの第一歩は問題事象が発生した都度に対応対策を検討するのではなく予め予測されることを整理しておくことが大事です。

前田：今回の会議は、プロジェクトで発生するリスクとその対応、対策について皆さんと話し合いたいと思います。

劉　：そうですね。それは極めて重要だと思います。以前に経験したプロジェクトでは、次々と問題が発生しそのたびに対応・対策を検討しなければならず大変苦労したことがあります。

楊　：もう一つ大事なことは、リスクに関する情報がプロジェクトメンバー全員に伝わっていないと、問題事象が発生しても見過ごすことが起きるのです。

張　：先輩のご意見の通りだと思いますが、経験が少ないとリスク項目を抽出する力が弱いと思うのですが、その場合はどうすればいいのですか？

楊　：確かに張さんはまだ若く経験は我々より少し少ないですね。しかし心配する必要はありません。今までのプロジェクトで発生したリスクを参考にしてそのリスクが今回のプロジェクトにも発生する可能性を検討すればいいのです。

張　：確かにそれは良い方法ですね。しかし、今までになかったリスクも発生する場合もあり得ますね。

劉　：それはあります。リスクリストを作る段階では想定しうる範囲でリスト化しますが、それで１００％網羅できるというわけではないのです。

楊　：張さんの心配なところもわかりますが、劉さんが言ったようにリスクを完璧に予測できるということではないのです。必ずと言っていいほど何か違った問題が発生することもあるのです。

張　：そうですか。ある程度は仕方がないと見切ることでしょうか？

楊　：まあ、それに近いですが適当に諦めるということではないのです。一人で考え込むのではなく、計画チームで多面的にリスクの可能性を検討しておくことが大切なのです。

劉　：検討し予測したリスク以外からも発生したとしても、発生の可能性を細かく検討しておけば、網の目が細かいのと同じに重大なリスクの発生を初期の段階で予知できるということですね。

張　：なんだか魚を取る網のような感じですね。

楊　：ははは、そういえばそのような感じですね。

張　：網の目が細かいとそのための負担も大きくなるのではないですか？

劉　：確かに細大漏らさずに、全部に同じような対応対策を取ろうとすると重たくなるでしょうね。リスクマネジメントだけに負荷をかけるわけにもいかないでしょうからね。

張　：リスクマネジメントも労力と効果のバランスをとるのが難しいのですね。

前田：皆さんのディスカッションを聞いているとリスクリストを作成すること必要性に関して異論はないようですね。張さんから労力と効果のバランスが難しいのではという意見も出されました。そろそろ次の課題に進めたいと思いますがよろしいでしょうか？

張　：はい、リスクリスト作成の意義は十分に理解できました。

前田：楊さん、劉さん、積極的な発言ありがとう。では次の課題に進めます。

3-3-③ リスクの影響と発生頻度、確率について話し合う：

（会話の前提）
前回のコアメンバーとの話し合いでリスクマネジメントの最初のステップとしてリスクリスト作成の合意が形成されました。前田さんは今回の話し合いはリスクマネジメントに費やす労力と効果との関係についてコアメンバーと話し合うことにしました。

前田：先のリスクリスト作成の話し合いで、張さんからリスクを網羅する網目を細かくすると重たくなるとの意見がありました。今回はそのことについて話し合いたいと思います。

張　：私の意見を取り上げていただいて恐縮です。でも期待もしています。

前田：張さん、ご心配なく。恐縮されることは全くありません。これはコアメンバーの間でリスクについての取り組み方を共有するステップです。いわば、プロジェクトのリスクマネジメントの手順なのです。

張　：わかりました。リラックスしてディスカッションに参加します。

前田：今回のプロジェクトでも皆さんから多くのリスク項目が出されています。　　　まずこれ等の項目を整理しましょう。

楊　：では、大項目には開発分野で分けることでどうでしょうか？

劉　：すると、筐体構造、電気制御系統、ソフトウエアとなりますね。

張　：では、中分類はどのようになりますか？

前田：必ずしも決まった分類方法はありませんが、開発プロセスのフェーズで分類することがわかりやすいと思います。

張　：さらに小さく分類する場合はどのような方法がありますか？

前田：小分類する場合は、人、もの、コスト、技術、機材などと要素別に分類する方法があります。例えば利用する外部ソフトウエアに関するリスクでも、購入金額、購入先、購入時期で分類することができます。

張　：分類氏が多くなり、だんだんと複雑になるのですね。

前田：そうですね。だからこそリスクリストを作成しておくことが重要になるのです。リスクリストを作成し、関係性が整理できた段階で、個々のリスク項目についてその発生の確率や影響度について予測します。

張　：予測はどのようにするのですか？

楊　：プロジェクトのリスクの予測は経験によるところが大きいですね。今までのプロジェクトで発生したリスクが今回のプロジェクトに当てはまるかどうか、過去のデータを参考に予測します。まったくの思い付きではなく、過去のデータを参考にすることで精度が高まります。

劉　：そうですね。私も過去の同種のプロジェクトの実績を参考にしています。リスクが発生しそうな状況は似通ったところがあるものです。

前田：影響度やの発生の確率はその後のリスクマネジメントに反映する必要があります。ただ予測しただけではあまり意味がありません。リスクの重要度を設定し、重要度のレベルに応じた対応、対策も検討することが必要になります。

張　：ますます大変ですね。

前田：大変と言えば大変ですが、プロジェクトが失敗したことを考えれば、当然やるべきことをやったことになるのです。

張　：なるほど。プロジェクト成功のために“やるべきこと”の一部なんですね。リスクマネジメントの重要性が良く理解できました。

前田：必ずしも予測通りになるとは言えませんが、実際に発生したときに慌てなくて済むのです。“備えあれば憂いなし“ということですね

3-3-④ リスク情報を共有することの重要性について話し合う：

（会話の前提）
リスクマネジメントに関する取組みがプロジェクト成功に重要な要素であることをコアメンバーも十分に理解することができました。しかし、プロジェクトに関わる利害関係者（ステークホルダー）がリスクに関する情報を共有できていなければ折角の準備も役立たずと言わざるを得ないのです。前田さんは主要なステークホルダーにはプロジェクト計画承認の会議で報告することにしています。プロジェクトメンバーには、プロジェクトキックオフミーティングや各開発担当分野の会議で入念に説明することにしています。

前田：今回のコアメンバーの皆さんにお集まり頂いたのは、皆さんのご協力によって作成したリスクマネジメント計画を徹底するための打ち合わせ会です。

張　：私は今回初めてですが、リスクマネジメント計画にかなり力を入れて取り組んだので満足しています。

前田：そうでしたね。張さんは積極的に意見を述べていましたね。皆さんの努力のおかげでしっかりとした計画書の作成ができました。

劉　：張さん！まだ安心するのは早いですよ。実際のプロジェクト活動はこれから始まるところですから気を緩めずにね！

張　：劉さんも厳しいですね。私はもう力一杯出し切りましたよ。

楊　：張さん、まだまだこれからですよ。劉さんが言うように気を緩めないでください。

張　：なんだか前田ＰＭが3人いるような気がしますね。

前田：ははは、それは困りましたね。冗談はさておき劉さん、楊さんと私も同じ気持ちです。

張　：リスク項目の優先順位も決まり、発生した場合の対応のあり方も決まっていますが、実際の活動の中で、リスクの兆候をどのように発見するかそこが難しいのではと感じています。

前田：そこが一つの要点です。ただ漫然とみているだけでは、リスクの兆候を見逃すことになります。それとプロジェクトリーダーだけで兆候を監視するだけでは細かなことを見逃すこともあります。

楊　：確かにプロジェクトリーダーだけでは、細かな兆候を見逃すこともありますね。

前田：小さなことが、後で大きな事故の要因になることはよくあることです。飛行機事故の原因でも小さな問題を見過ごしたために大事故にという例はよくあることですね。

張　：小さな兆候を見逃さないためにはどのようなことが重要ですか？

前田：大きくは三つの要点があります。一つはリスクマネジメント計画で重要視しているリスク事項の背景や発生した場合の影響度、兆候として予測していることなどの情報を詳しく伝え、各メンバーのリスクへの関心を高めておくことです。

張　：もう一つはどのようなことですか？

前田：もう一つは、自分の担当領域の仕事に関する関心はもちろんですが、自分の守備範囲を越えても、“変だな”とか“問題だな”と感じたことは、上司に報告するという積極性を発揮するようにリスクへの関心を高めておくことです。

張　：これは越権行為ではなく、チームワークということですね。

前田：その通りです。三つ目の要点は、その報告を受けたマネジャー、リーダーは即対応に移ることです。些細なことと後回しにしないで、即事実を確認することが大きな問題にしないで対処できるのです。

張　：良くわかりました。メンバーにはリスクマネジメントの意図を詳しく伝えるようにします。

3-3-⑤ リスクの対応の基本について話し合う：

（会話の前提）
リスクには大小、影響度、発生頻度、対策の難易度などさまざまな要素があります。リスクには、地震や、台風、天変地変のような対策の極めて難しいリスク事象もあります。すべてのリスクに対して一様の対応ではなく、リスクの内容によって対応のあり方を区分けする必要があります。前田さんは、その基本的な対応についてプロジェクトのコアメンバーと話し合うことにしました。

前田：今日、皆さんとお話ししたいことはリスクの基本的な対応についてです。リスクにはその存在が①明確に予知できるもの、②いつ発生するか明らかでないもの、③発生する確率は低いが影響の大きいもの、④発生の確率は高いが影響は小さいものなどに区分することができます。これを二元表で表現すると解りやすいですね。発生頻度の高い低い少を横軸に、影響度の大小（損失金額など）を縦軸にします。

劉　：なるほど。良いですね。では二元図表にしてみましょう。

図2．リスク対応の基本的考え方

劉　：このような「図表になりますがいかがですか？

前田：いいですね。解りやすいですね。では、劉さんに書いた図表で説明しましょう。この表にあるようにリスクを区分できるように４つの象限にします。そしてリスク項目を発生頻度、影響度で４つの象限に分類します。

張　：問題の大きなリスクと、そうでないリスクとが区分されましたね。これだと対応の優先順位もはっきりしますね。これで十分と思いますがいかがですか？

前田：実はリスク管理の要点はまだあるのですよ。冒頭にリスクには不可避のものもあるという話をしましたね。

張　：確かにそのようなお話は伺っていますが。

前田：もう少し突っ込んだリスク対応のあり方になるのですが、最初からリスクに対する対応態度を決めておくことがあります。

張　：それは優先順位を決めることとは違うのですか？

前田：少し対応の観点が違います。これから説明します。では、わかりやすい例で説明しましょう。張さんが商船会社の経営者としましょう。

張　：例え話の題材でもなんだか偉くなった気がしますね。

前田：そう、そういう立場で考えてください。大事な商品を海外に運ぶとした場合どのようなリスクを予測しますか？

張　：台風や津波で船が危険な目にあうことが考えられますね。他に海賊におそわれることもありますね。船員が病気になって船を動かせなくなることもありますね。

前田：台風が来るとわかっていればどうしますか？

張　：まず事前に気象情報がありますから、航行中だと荒天が治まるまで島影に退避します。出航前だと港で待機し出港を遅らせますね。

前田：それも一つの対応策ですね。他にどのような方法がありますか？

張　：他の対応方法ですか？・・・船を２隻に分散して出港するということもありますね。他にはえーっと、それから船に損害保険を掛けますね。それから大きな船だと少々の風は乗り切れるので保険は掛けますが予定通り出港しますね。

前田：張さんの意見で正解です。少し付け加えると、①問題そのものを避ける回避する対策を打つ。②リスクの影響を分散し軽減する対策を打つ。③リスクの被害を損害保険などで被害を転嫁する。④リスクが発生したとしても軽微と判断し、特に対策を講ぜず受容する。という４区分です。

張　：言葉の表現は少し違いますが大体合っていましたね。

前田：この４つをリスクの基本的対応と言います。「①回避、②軽減、③転嫁、④受容」と言います。リスク対策もすべて重たく対応するのではなく、その内容によって効率的な対応を選ぶということですね。

張　：４つの基本的対応はよく理解できました。

3-4 チームビルディング

3-4-① チームビルディング（組織編制）について話し合う：

（会話の前提）
プロジェクトの組織はプロジェクトの目的、目標、期間、規模、場所、とりまく環境によって異なります。それぞれの条件の中で最も適した組織を編成することがプロジェクトマネジャーに求められます。組織編制にはプロジェクトを企画した上位者、あるいは発注者スポンサーの協力なしでは難しいことがあります。プロジェクトの目的を達成するために必要な人材の選抜と適切な配置によって組織づくりがチームビルディングです。前田さんはプロジェクトチームの中心的役割を果たすコアメンバーとチームビルディングについて話し合いをしました。

前田：今日の会議では、プロジェクトチームの結成に必要なメンバーの人選と配置について話し合います。先日の会議で、皆さんにチーム体制案を検討をお願いしていましたが出来ていますか？

張　：私はソフトウエア開発のリーダーは初めてですが、自分なりに最適な案を考えてきました。

劉　：私は、何度か新商品開発プロジェクトで電気制御系のリーダーを担当していましたので、その時のプロジェクトレビュー資料を参考に案をまとめてきました。

楊　：私も劉さんと同様ですが、過去のプロジェクトのレビュー資料を参考に今回のプロジェクトの目的、目標、状況を踏まえて自分の意見をまとめてきました。

前田：皆さんの意見をお聞きしてディスカッションしましょう。そして最適なプロジェクトチーム結成に取り組みたいと思います。それでは張さんの案からはじめましょうか？

張　：では、早速ですが私の案からご説明します。分かり難い点、至らぬ点はどうぞご指摘をお願いします。

――――――――――案の説明―――――――――――

前田：内容はよくわかりました。ひとつ質問があります。ソフトウエア開発で新しい技術が必要なところですが、外部の協力会社から調達したいとのことですが、社内人材では確保できないのですか？

張　：残念ながら、このソフトウエア開発技術を使いこなす技術者はわが社にはいないのです。このプロジェクトの中で社内にも技術者の育成もするつもりで外部協力会社の技術者を調達したいと考えています。

前田：そうすると、通常の開発業務を委託する以外に教育指導も考えているということですね。

張　：そうです。その分契約単価は高くなりますが、今後のプロジェクトでも必要な人材育成も考えると効果的だと考えています。

前田：なるほど。そういう理由ですね、よくわかりました。もう一つ質問があります。調達先の技術者のスキルレベルですが適正なレベルであるとの確認はどのように考えていますか？

張　：それは、所属企業の責任者と話し合い、スキルレベルの証明書や新技術による開発実績も提示を求め。私が面接をした結果で判断する予定です。

前田：わかりました。正式に契約した後も進捗状況も含めてマネジメントをよろしくお願いします。他に張さんからなにかご意見はありますか？

張　：いえ、このことが一番留意していることで他にはありません。

前田：私からは、外部の技術者の方と、社内の技術者達とのコミュニケーションが良好にとれるチーム編成をお願いします。特に開発者間のミスコミュニケーションで問題が生じることのないように最適なチーム編成をお願いします。

張　：はい、よくわかりました。十分に留意してチーム編成します。

前田：では、次に電気制御系統の劉さんの案をお聞かせください。

3-4-② メンバーの特性、能力について話し合う：

（会話の前提）
組織は人によって構成されています。プロジェクト成功には参加する人材の能力に依拠するところが大と言えます。プロジェクトマネジャーやリーダーは、個々の人材の特性や能力をいかに発揮させるかがマネジャーの役割です。プロジェクトでも組織は多様な特性、能力、価値観を持つ人材を受容することが大切です。前田さんは強い組織作りのためには、コアメンバーとも共通の認識を持つ必要があると感じ話し合うことにしました。

前田：皆さん、これからチーム編成に取り組まれるところだと思います。 チームメンバーの選定、人選で気を配っているところはどのようなことですか？

楊　：前田さんも同感だと思いますが、人材確保に苦労しています。欲しい人材は忙しく、なかなかプロジェクトに確保できる余裕がないのです。

劉　：私も同じです。この人に是非参加してほしいと交渉しても他のプロジェクトとの関係で合意が得られないことが多いのです。

前田：そうですね。その点は私も同感ですね。なかなか思うように人材確保できないのが実態ですね。

劉　：それと、頭数だけではなく、必要な能力や必要なスキル分野となると難しいですね。

張　：私はやむを得ず外部の協力会社から派遣を求め確保しましたが、楊さん、劉さんのところでも検討されたらいかがでしょうか？

劉　：ご意見ありがとう。前のプロジェクトでも外部の協力会社にも参加してもらったこともありますが、現状はこちらのニーズに合致した人材がいない状態なのです。

前田：それは困りましたね。社内他部門には同等の人材の心当たりはありませんか？

劉　：ないことはないのですが・・

前田：その人では無理なのですか？

劉　：いや、能力的には問題ないのですが、自己主張が強く周りとの協調性が心配なのです。

前田：なるほど。その点が心配されているところなのですね。それで劉さんは実際にその人と話したことがありますか？

劉　：いや、今まで直接に話したことはありませんが、その部にいる同期の仲間から聞いた話です。スキルは抜群だそうですが、内部で紛争もよくある人だと聞いています。

前田：そうですか。一度あなたが会って話をして判断してはどうですか？

劉　：そうですね。先入観で判断してはいけませんね。

前田：人はそれぞれに個性もあり、固有の価値観をもっています。 プロジェクトの目的と目標を共有できる人であれば問題ないといえますね。むしろ個性的な価値観をもった人が組織で力を発揮する場合があります。

楊　：私も今までのプロジェクト経験からそのように感じています。

前田：私の方でも支援していきたいと思います。必要なことがありましたら遠慮なく言ってください。

劉　：早速、本人とも会ってみます。プロジェクトで彼の能力を大いに発揮してもらいたいです。

前田：そうですね。劉さんが会ってみて問題なければメンバーとして推薦してください。

3-4-③ コンフリクトへの対応のあり方について話し合う：

（会話の前提）
組織では人間関係の問題によって活動に支障をきたすことはよく知られています。組織はさまざまな人間によって構成されます。人それぞれのものの見方、価値観、所属している組織の文化等によって考え方も行動も異なります。多様な人間関係においてちょっとしたミスコミュニケーションで“コンフリクト” （衝突）が起きます。プロジェクト組織でもコンフリクトは発生します。前田さんは、こうしたコンフリクトへの基本的対応についてコアメンバーと話し合うことにしました。

前田：今後プロジェクトが計画フェーズから実行フェーズに移行すると、それぞれの開発活動に参加するメンバーが急速に増加します。メンバーの中には初めてプロジェクトに参加する人もいます。組織的な活動には人間関係の問題が少なからず発生します。

張　：それは私も経験しています。チームの中に分派的なチームができることがありました。

劉　：いい意味で競い合うのは良いのですが、拙い場合は必要な情報が伝わらなくなり、変更情報を知らずに作業を進めるなどがあります。

前田：意識的にコンフリクトを発生させているのではなく、コミュニケーションの拙さが原因にあることが多いようです。もちろん、メンバー同士のコミュニケーション不足だけではなく、マネジャー、リーダーとメンバーとの関係においても多くあります。

楊　：私はチームの中でコンフリクトがあると発見した場合は、即対応するように心がけています。

前田：コンフリクトへの基本的対応では、楊さんの言った即対応することは重要です。コンフリクト状態を続けていくと組織全体のモチベーションの悪化に影響していきます。

劉　：以前のプロジェクトでコンフリクトへの対応を迅速に取らなかったために問題がこじれ退職者までだしたことがあります。

前田：そのような問題になるまで適切な対応・対策を講じなかったことはプロジェクトマネジメントに大きな責任があるといえます。いかなるマネジメントにおいても“問題の先送り”は問題解決を拗らせます。

劉　：前田さんの言われる通りですね。

前田：コンフリクトへの対応は、迅速性が必要ですが、速いだけではなく、事実の確認も重要です。一部の意見、あるいは一方的な意見や情報だけで判断しないことです。

張　：私は今回のプロジェクトでは初めてリーダーを担当しますが、適切に対応できるかちょっと心配になってきました。

前田：そうですね。不安なときは私や先輩の楊さん、劉さんにも相談してください。先入観にとらわれず客観的な判断ができると思います。

楊　：私も最初の頃は、上司や先輩に相談したことがあります。遠慮しないで相談してください。過去に例もありますから参考になると思いますよ。

前田：このような助け合う関係の組織だとコンフリクトは起きないのです。次に考慮することは、あらかじめ個人の特性も考えてチームビルディングすることもコンフリクトの予防につながります。

張　：チームビルディングもスキルや能力だけではないのですね。

前田：そうです。日本には次のような諺があります。“船頭多くして船山に登る”リーダーつまり自己主張の強い人ばかり集めると、目的、目標の追求より手段の良し悪しで紛糾し、組織の方向性を誤るということです。

張　：うーん、どこかで聞いたような、見たような気がしますね。

前田：コンフリクトへの対応のあり方をもう一度整理しておきましょう。①兆候を発見した場合は先送りしないで即対応する。②兆候を短絡的にみないで事実を確認して判断する。③チームビルディングの段階で予防策を講じる。この３つを念頭にチームの動きに関心を持ち観察を怠たらないことです。

3-4-④ チームのモチベーションについて話し合う：

（会話の前提）
モチベーションは個人の心の中にあるものですが、モチベーションが低下すると個人だけでなく組織としてのパフォーマンスも低下します。また、モチベーションの低下した人が他の人のモチベーションまで影響を与えます。「このようなところ（組織・会社・チーム）にはいたくない！」という言葉を良く聴き ます。前田さんはモチベーションのことについてコアメンバーと理解を深めるために話し合いをすることにしました。

前田：皆さんはチームのモチベーションについてどのように考えていますか？ベテランの楊さんはどのようなご意見をおもちですか？

楊　：プロジェクトでもよくモチベーションが低いだとか、上がらないだとか自分でも言っています。しかし、どうして上がったり、下がったりするのか、良くわかりません。気持ちの問題が多く影響するのではと思っているのですが・・・

前田：珍しく楊さんの歯切れがよくないようですが・・劉さんはどのようなご意見ですか？

劉　：そうですね。自分の気の持ち方のような気がしますが。しかし、その切っ掛なることはありますね。例えば、会社でいえば上司に叱られると一気に落ち込みますし、褒められると一気にいい気分になってやる気が起きますね。家庭でも同じですが。

前田：張さんはどのようなご意見をお持ちですか？

張　：いや、ご意見というほどではないですが、やはり褒められると良い気分ですね。怒られると一気に落ち込みますね。どちらかというと私は煽てに乗って成長する方ですから（笑い）甘いですかね。

前田：いやいや、そうでもないですよ。モチベーションの重要な要素ですから。ところで、皆さん個人に置き換えて考えてください。目的や目標がなく成果の見えない仕事でのモチベーションはどうなりますか？

張　：私はまったくやる気が起きませんね。

前田：そうでしょうね。私も同じです。ここで良い言葉があります。みなさんご存知かと思うのですが“夫志気之帥也”これは約二千四百年も前に戦国時代中国の儒教家である孟子が言われたという言葉です。

張　：どこかで聞いたことはありますが。

前田：この言葉の意味は“志がやる気の素”という意味だそうです。現代ではやる気のことを英語で“モチベーション”と言い“動機付け”とも言います。

楊　：そうでしたか。先人は良いことを言っていますね。しかし、二千四百年経ても通じるといことは人間の本質はそんなに変わらないということでしょうか？

前田：そうですね。人間の本質はそう変わらないでしょうね。この志という言葉は英語でいうと“ビジョン”と言います。ビジョンすなわち先の見通し、到達すべき目的、目標、ということになります。私も見通しがなければ進めません、やる気もおきませんね。

張　：前田ＰＭも私と同じということですかねえ。

前田：プロジェクトでも全く同じです。個々の自分の仕事の役割、期待が明確になっていなければモチベーションは上がらないのです。たとえ叱咤激励し頑張れと尻を叩いて励ましても、長続きはしないのです。

張　：それは良くわかります。いやいややるのと自分からの意志でやるのは大違いですからね。

前田：そういうことですね。やる気は見通しがあって、目的、目標、成果が見えれば自ら起きるのです。他動・受動ではなく自動・能動が重要なのです。そのためにはリーダーはメンバー一人ひとりの仕事について丁寧に伝えることが重要なのです。

張　：モチベーションも奥が深いですね。よくわかりました。

第4章　成果の納入と終結の場面

4-1 プロジェクトの成果を納入する

4-1-① テスト結果について話し合う：

（会話の前提）
全ての開発工程も最終段階のテスト工程に入ります。新商品として市場に出荷する前に商品の機能、性能が仕様書通りになっているかの確認が重要です。商品の出荷に至るには信頼性、安全性、操作性など多くのテスト項目を経てなされます。前田さんは筐体構造、駆動系などのハードウエア開発、電気系統、制御系統の開発、ソフトウエアの開発それぞれのテストを終えた結果をもとにコアメンバーと話し合うことにしました。

前田：みなさん、試作機段階のテスト作業も無事終了しました。テスト担当チームの報告では、小さな問題はあったようですが、特に大きな問題はないと聞いています。大変お疲れ様でした。

楊　：開発直前に仕様の変更要求もありましたが、無事要求仕様通りに開発活動も終了することができました。メンバーの努力の成果だと思います。

前田：そのようですね。いずれも皆さんの努力の結果ですね。

張　：私の担当したソフトウエア開発ですが、少し問題が発見されました。ソフトウエア単体のテストでは問題が発見されなかったのですが、駆動制御回路に制御ソフトウエアを実装した段階でいくつかの問題がありました。

前田：なんらかの問題はどのような場合でも発生しますが、今回の問題は要求仕様書との整合性はとれていますか？

張　：制御ソフトウエアは要求仕様書に基づいて設計、開発していますので、整合性は問題の原因ではないと判断しています。

前田：すると、どのようなことが原因と判断していますか？

張　：単純なプログラムミスと判断しています。いわゆるバグというかプログラミングでの論理的矛盾に気が付かなかったといことだと思います。

前田：深刻な問題ではないということですね。わかりました。現在試作機段階のテストですが、次のステップの量産試作機のテストまでにプログラムの改善を完了するようにお願いします。

張　：大丈夫です。完了します。

前田：劉さんの担当分野では問題はなかったようですが、いかがでしたか？

劉　：電気系統、電子回路系統も問題なくテストを終了しました。

前田：先ほどのソフトウエア開発のところで若干の問題があり、張さんのところで改善の予定ですが、改善ソフトを実装した段階で再度テストを行う必要がありますか？

劉　：電子回路上では問題ないと思いますが、改めて結合テストを行う予定です。

楊　：私の担当する駆動系との関係で、ソフトウエア実装に合わせて動作確認をするために再度結合テストで確認します。

張　：皆さん、申し訳ありません。ソフトウエア不良のためにご迷惑をおかけします。

楊　：張さん、そんなに恐縮にしないでください。こうしたことはプロジェクトではよくあることですから、お互い様ですよ。

前田：試作機のテスト段階で問題を発見したわけですから良かったと思います。そのためのテストですからね。

張　：やさしいお言葉ありがとうございます。再テストまでにしっかりと改善して参加します。

前田：張さんから開発メンバーにも状況を伝え激励をしてください。よろしくお願いします。

4-1-② 発見した問題点について話し合う：

（会話の前提）
プロジェクトも開発フェーズが終了しました。試作機テストの段階で、小さな問題点は幾つかありましたがその後の対応ですべて問題は解消しました。社内の品質保証部門による最終的な検査を終了すると開発プロジェクトはほぼ最終段階に入ります。この後は製造担当部門による量産体制に入り開発プロジェクトは終結します。ところが品質保証部門からの指摘事項が幾つかあるとの報告を受けました。前田さんは早速コアメンバーを集め問題点について対応を話し合うことにしました。

前田：みなさんお忙しいところ緊急にお集まりいただいた理由は、品質保証部からの報告で、若干、問題の指摘を受けました。

張　：極めて重大な問題ですか？

前田：そうですね。放置しておくと重大な品質問題に発展する可能性があるということですね。実は、ストレステストの結果、機械の電源回路に過電流が流れコンデンサーや抵抗器が破損し、焼損の恐れがあるとのことです。そういう意味では製品安全の問題と言えます。

楊　：試作機のテスト段階では発見できなかったことですか？

劉　：過電流が流れる原因は分かったのでしょうか？

前田：原因までは掴めていません。過電流が流れるにはいくつかの要因があると思います。電源トランスそのものの問題、使用電力が集中し、過剰な電流が流れている可能性、駆動系の無理な力、摩擦などが過電流を引き起こしているなどが考えられます。

楊　：分かりました。早速品質結果に基づいて現状の調査、確認に入りたいと思います。

劉　：楊さん私も調査作業を進めます。

前田：ああ、そうしていただけますか？緊急に対応する必要がありますのでみなさん力を合わせて取り組んでください。

張　：私も何かお役にたちたいのですが、前田さんいかがでしょうか？

前田：そうですね。楊さんと、劉さんの調査した結果データの分析をお願いします。多面的なものの見方で問題を発見できるかもしれませんね。

張　：分かりました、ソフトウエア開発の方は完了し何人かの要員も手配できますので、さっそくチーム編成して対応します。

前田：それと張さんには過去のプロジェクトの結果データから参考になる資料を収集してください。

張　：お任せください。

前田：それと、楊さん、劉さんは品質保証のテスト担当者からの情報を確認し、テスト条件などもよく調べておいてください。どのような条件で問題が発生したか明確にしておく必要があります。

楊　：承知しました。テスト条件と問題の再現性について確認します。

前田：そうですね。問題の再現性が確認できると要因は絞り込みやすくなりますからね。では、私はこれから主要なステークホルダーに状況と今後の対応について報告をしておきます。

楊　：結果状況は、逐次報告いたします。

前田：そうですね。皆さんの健闘に期待しています。では、さっそくはじめましょうか。

4-1-③ 問題点の対応と対策について話し合う：

（会話の前提）
量産製造に入る前のテスト段階（量産試作テスト）で問題が発生しましたが、プロジェクトの総力を挙げた問題の要因分析に取り組んだ結果、問題の原因を突き止めることができました。それぞれの原因に対する対応と対策を検討する必要があります。前田さんはコアメンバーと問題点の対応と対策案について話し合うことにしました。

前田：皆さんのおかげで早期に問題の原因を突き止めることができました。本当におつかれさまでした。

楊　：問題現象として指摘のありました電源トランス部分か発煙したという事故に対し、関係の深いと思われる電気部品、電子回路部品、電子回路駆動部品、電源トランスなどをすべてチェックしました。

劉　：調査の結果、駆動系のモーターに過電流が流れ、そのために駆動系の電源回路のコンデンサーが定格電流容量を超過で損傷したのです。さらに電源回路が破損したために、電子回路部品も焼損したというが原因です。

前田：すると、駆動系モーターに過電流が流れたのが原因というわけですか？

楊　：いえ、原因は駆動系に必要以上の負荷がかかったことが原因です。

前田：すると駆動系の構造上にも問題があるということですか

楊　：そうですね。真の原因は、筐体の強度にありました。

前田：それは、筐体の軽量化で強度が不足したということに関係しますか？

楊　：全く関係ないことはありませんが、筐体を軽量化した際の設計にあると思います。

前田：すると今後の商品化計画に大きな影響があると考えていいですか？

楊　：いや、真の原因が明確になりましたから、効果的な対策も打てるので早期に問題は解消できると考えています。

前田：そうですか。それはよかった。ベテランの楊さんの自信あるお言葉ですからＰＭとしても安心しました。

張　：参考までにお聞きしたいのですが、そもそもの原因は筐体の軽量化で駆動系の機構を支える構造上に問題が発生したということですね。つまり荷重に耐えきれなかったということですか？

楊　：単純ではないのですが、駆動部品の荷重と振動が繰り返し、連続的な力となったために部品を支えるプレートが歪み、駆動回転に無理が掛かり駆動モーターに異常電流が流れ、電気部品を焼損したということですね。

張　：なるほどそういうことが真の原因だったのですね。

前田：ところで対策は比較的容易と聞きましたが、楊さんの対策案をお聞かせください。

楊　：そうですね。もっとも重要なポイントは振動と荷重に対応できるような駆動系部品を取り付けるプレートに制振部品を採用することと、プレートの形状に工夫を凝らし、荷重的にも耐えられる形状にします。

前田：その対策に必要な組立工数の負担はどの程度になりますか？

楊　：量産時の組立ラインに改良部品と入れ替えることで組立工数は当初工数の範囲内で可能です。

前田：すると改善部品の材料費、加工費の追加で対応可能ということですね。

楊　：そうですね。プロジェクト予備費の範囲内で問題はないと思います。

前田：皆さん、いろいろとご苦労様でした。これでプロジェクトも終結に向けて一歩前進ですね。お疲れ様でした。

4-1-④ 検収受入準備の要点について話し合う：

（会話の前提）
検収は一般的には外部から受注したプロジェクト成果物（ハードウエアやソフトウエア等を含む）を発注者に納入する場合に行う検査確認作業です。検収項目は、プロジェクト計画フェーズ合意した要求仕様項目が実現できているかの確認が基本です。前田さんは、プロジェクト成果物の検収承認を手際よく進めるために、コアメンバーと対応について話し合うことにしました。

前田：プロジェクトも終盤を迎え、各開発チームでも検収に備えて準備を進めていると思いますが、懸念事項あるいは問題点がありましたら報告してください。

楊　：最終的な品質テストでも指摘されていました問題点についても対策が完了し問題点はすべて解消しています。

劉　：総合的な機能テストでも問題なく機能しているとテストチームから報告を受けています。

張　：機能テスト、性能テスト、操作テストの結果が順調ということで、組み込んだソフトウエアやアプリケーションソフトも問題ないと判断しています。

前田：そうですか、すべて順調に進んでいると判断していいですね。商品企画部の検収はスケジュール通り行われると聞いています。

楊　：あえて付け加えると、検収が順調に行くように考慮しておくことも必要かもしれません。

張　：それは、なぜですか？　テスト結果も問題なく特に考慮する必要がないのでは思いますが？

楊　：そうですね。一般的には問題ないと言えますが、念のためというか、より円滑に検収を進めるには、そのための準備を進めておくといいですね。

張　：楊さんの考慮が必要なところとはどのようなことですか？

楊　：商品企画部で検収を担当する人も様々な経験をしている人ばかりですが、今回の新商品のように、採用した新しい技術やシステムを評価するには、専門的な知識も必要になります。検収仕様書に記載された内容を検証するために補完する資料もあったほうが円滑に進むと考えています。

張　：なるほど、そういう意味での準備をしておくと万全ですね。私たちは検収が承認されないとプロジェクトの活動成果がみとめられないということですかね。

劉　：そういうことですね。検収を円滑に進めることは発注者の責任というのではなく、受注した私たちの責任でもあるわけですね。

前田：皆さんのプロジェクト成果物の検収に臨む積極的なものの見方、態度に私も感謝します。是非、この考え方を基本にして検収準備を進めたいと思います。

張　：検収への取り組みについてよく理解できました。楊さん、貴重なご意見ありがとうございました。

楊　：いえ、どういたしまして！

前田：今回のプロジェクトが順調に進んでいるのも、皆さんの前向きな考え方と、コアメンバーでなんでも話し合えるベターコミュニケーションの結果と言えます。

楊　：お褒め頂きありがとうございます。プロジェクトを発注してくれたステークホルダーの皆さんへの感謝の気持ちを忘れないようにしたいと思います。

張　：ますます勉強になります。良いプロジェクトに参画できたことを誇りに思います。

4-2 プロジェクトの終結準備

4-2-① プロジェクト終結にともなう手続きについて話し合う：

（会話の前提）
プロジェクトの最終フェーズである終結フェーズはプロジェクトマネジャーやリーダーなどプロジェクトを運営してきた人達にとって、立上げ、計画、実行のフェーズとは違った役割を果たすことを要求されます。終結フェーズには細々と処理すべき項目も多くあります。前田さんは、円滑なプロジェクトの終結を行うためにコアメンバーと話し合うことにしました。

前田：いよいよプロジェクトの終結フェーズに入りますが、終結フェーズでは今までの活動成果を納入するだけではなく、多くの事務処理手続きが課題です。

張　：私も今まで、ソフトウエア開発担当者の立場で、終結にともなう手続きはリーダーにお任せだったので詳しいことはよくわかりません。

前田：そうですね。張さんは今回ＰＬを担当するのは初めてなので多少の事前準備が必要ですね。

張　：分かりました。是非、ご指導ください。

楊　：張さん、わが社には様々なプロジェクトマネジメントに関する仕組みと資料が準備されているのでそれを参考にするといいですね。

張　：そうでした。わが社にはプロジェクト・マネジメント・メソドロジー（ＰＭ方法論）がありますね。

楊　：わが社の方法論には今までプロジェクトに携わってきた先輩達のノウハウが蓄積されています。

張　：ＰＭ方法論の存在は知っていますが、よく読んでいないので詳しい内容は知りません。

前田：プロジェクト終結時の要点を簡単に説明にします。要点は５つあります。①プロジェクト成果を発注者に受け入れられるように準備する。②プロジェクト活動に付帯する事務処理をする。③プロジェクト組織の終結に関する人事的な処理をする。④プロジェクトの最終的な評価の準備をする。⑤プロジェクトでの教訓を整理し展開できるようにする。などです。

張　：主な項目だけで５項目ですか、しかも様々な内容ですね。

前田：そうですよ。確かに多様なことに対処し、文書化してまとめる必要があるので労力はかかりますね。

張　：労力はやむを得ないと思いますが、対応、処理項目を見落とさないようにすることが大事ですね。

前田：そのためにＰＭ方法論の中には、終結時にともなう対応、処理項目がチェックリストとして準備されています。そのリストに従って進めるのが見落としをなくする要点ですね。

劉　：私もそのチェックリストを今でも活用していますよ。

楊　：それが一番いいほうでしょう。人間の記憶にたよるより、ドキュメント化されたチェックリストの方が確実ですね。

前田：プロジェクト終結の中で特に残しておきたいのは、プロジェクトの各フェーズを推進する中で得た教訓です。失敗したことや成功したことの経験がノウハウとなって次のプロジェクトに役立つのです。

張　：それはご尤もなことですが、教訓になるようなことを整理しておくのも手間がかかりませんか？

前田：面倒でも手間がかかっても、やるべきことなのです。教訓となることは最終フェーズになってから収録に取り組むのではなく、それまでのフェーズでも収録に取り組むことが重要です。

張　：プロジェクト計画の中に教訓の文書化（ドキュメンテーション）計画が必要ですね。

前田：そのとおりです。プロジェクトで失敗したこと、うまくいったことを後進に伝えてこそ先輩としての値打ちがあります。

4-2-② 完成図書の準備について話し合う：

（会話の前提）
プロジェクト活動の成果物には、建築、土木、橋梁など構造物、ネットワーク通信、製造機器システムなどを制御するソフトウエアなど、広範な成果物があります。これらのあらゆる成果物が完成し、発注者に納入する場合には、そのプロジェクトに関連したデータ、資料を最終報告書として公式に文書化します。完成図書を準備には計画的な取り組みが必要なため、前田さんはコアメンバーと話し合うことにしました。

前田：いよいよプロジェクトの成果物納入と合わせて、完成図書の準備にとりかかります。そのために各開発担当チームのリーダーの皆さんと情報を共有しておきたいと思います。

張　：いよいよプロジェクトも終盤ですね。もう少しでプロジェクトも完成します。

前田：もうひと頑張りですね。完成図書には重要な文書も多く抜け漏れのないようにしたいと思います。

張　：そうですね。私も以前のプロジェクトで、大慌てで間に合わせたことがあります。

前田：それは大変でしたね。慌てた文書には抜け漏れが多くなり、あとで問題が起きることが多いようです。

張　：そうでした。全くその通りです。納入先から重要なことを記載漏れしているとか、データの整合性がとれていないとか、いろいろと叱られましたよ。

楊　：わたしも同じような経験がありますね。

劉　：実は私も同じような経験がありますよ。それから気をつけて終盤で大慌てしないように準備を整えて取り組んでいます。

前田：皆さん、それぞれに苦労された経験があるのですね。そうすると今日の打ち合わせの意義も十分にご理解しておられると思います。

張　：はい、それはよく理解しています。

前田：完成図書は書式と項目が整えれば良いとうことではありません。ドキュメント品質という点も考慮されていることが重要です。

張　：ドキュメント品質といいますと、どのようなことですか？

前田：ドキュメントとは、正式な文書、あるいは証明する文書という意味があります。加えて読みやすい文書、分かりやすい文書、誤謬のない文書、きれいな文書ということもドキュメントの品質に含まれるでしょう。

張　：文書作成もいろいろな要素を考えないといけないのですね。

前田：そうですね。同じような内容を文書化するにしても、内容はもちろんのこと、文書構成を考えることも重要です。

張　：文書構成といいますと、文書の目次のことですか？

前田：そうですね。プロジェクト憲章、プロジェクト契約書、プロジェクト計画書、承認合意済みの要求仕様書、要件定義書、基本設計書、詳細設計書、それぞれの設計図、設計資料、ＷＢＳ，などなどたくさんありますが、それぞれの関係性を意識した章立てにするということですね。

張　：うーっつ！それは大変ですね。今まで自分の作業範囲のみで考えていましたが、これは大変ですね！

前田：張さん、大丈夫ですよ。まだ時間もあります。それと弊社にはプロジェクト完成図書についてもプロジェクト方法論の中でまとめ文書があります。それを参考にして構成をしてください。

張　：わかりました。それを早速参考にして取り組みます。

前田：楊さん、劉さんは経験もあり、釈迦に説法かと思いますが、完成図書の文書規定とチェックリストを参考に抜け漏れの内容にお願いします。

4-2-③ 協力会社との業務契約終了について話し合う：

（会話の前提）
プロジェクトが終結フェーズに入ると、当然のことながら開発、制作などの実行フェーズ活動は終了し、実行フェーズで外部の協力会社などに委託した開発作業も終了しているはずです。外部に委託した部分は、納入、受け入れテスト、検収が終了し、課題、懸念事項も解消した段階で業務契約も終了の手続きに取り組みます。前田さんは、コアメンバーと現状を把握するために話し合うことにしました。

前田：いよいよプロジェクトも終盤になってきました。メンバーの皆さんや外部の協力会社のご努力でプロジェクトも順調に進捗してきました。確認ですが終結にむけて各協力会社に委託した業務での懸念事項や残されている課題はありますか？

楊　：プリンター筐体、構造開発では特に残されている課題はありません。途中での設計変更でも、協力会社メンバーのチームには大変頑張っていただき感謝しています。

劉　：私の電気・電子回路開発チームも開発工程上の問題は特にありません。強いて言えば、量産フェーズで必要な電子回路部品の調達契約がまだ整っておりませんが、調達部の担当者からは少し遅れているが調達に影響はないと聞いています。

前田：契約締結の遅れの理由はどのようなことですか？

劉　：契約書の文面を見直したために少し遅れたそうですが、来週中には正式に締結できるそうです。

前田：そうですか。それだと大丈夫でしょう。各協力会社を選定された皆さんの選択も良かったのでしょう。もちろん皆さんのマネジメントも素晴らしかったということです。

楊　：お褒めいただき有難うございます。

前田：張さんのところは何か問題や懸念事項については如何ですか？

張　：ソフトウエア開発チームも特に問題はありません。協力会社チームで開発したソフトウエアの受入検査も問題なく完了しています。後は、完成図書に添付する文書、データ資料の作成に取り掛かってもらっています。

前田：わかりました。いずれの開発チームも問題はなさそうですね。付帯のドキュメント作成作業が完了すると各協力会社との業務契約も終了となります。業務契約終了にむけての準備を進めてください。

劉　：わかりました。部品調達契約の方も来週には締結すると思いますので開発業務契約を終了させる準備をします。

前田：契約終了と並行して、各協力会社への支払い状況の確認と支払いの手続きもお願いします。

劉　：わかりました。経理部門、契約部門と連携して進めます。

前田：ご協力いただいた協力会社との信頼関係を維持するためにきちんとした商取引が重要なのです。

張　：私もその点を留意して遅滞の無いように進めます。

前田：私もＰＭとして、皆さんから起案された手続きは、速やかに処理をいたしますのでよろしくお願いします。

4-2-④ 残された課題への対応について話し合う：

（会話の前提）
プロジェクトも終結に近づいてきました。プロジェクトの活動期間にもよりますが、プロジェクトに参加するメンバーの母体組織への復帰の手続きや、業績評価の手続き、褒章の手続きなど、人事組織上の残された課題があります。前田さんは円滑なプロジェクト終結と参加メンバーのモチベーションも考慮した終結にむけてコアメンバーと話し合うことにしました。

前田：プロジェクト終結に向けた取り組みお疲れ様です。前回は協力会社との関係を中心に状況確認の話し合いをしました。今回は社内組織、人事上の課題について相互確認したいと思います。

張　：人事上の課題とはプロジェクト期間中の業績評価ですか？

前田：もちろんそれもありますが、そのこと以外にも主要なことがあります。　　　　　幾つかあると思います。

張　：業績評価以外のことですか？

前田：例えば、本人が引き続き他のプロジェクトに再配置される場合や、元の母体組織に戻る場合などもありますし、今回のプロジェクトで新商品の販売支援組織に配置する場合もあります。また、今回のプロジェクトで残された課題への対応する組織に配置する場合もあります。

張　：そういえば、そういうこともありますね。

前田：いずれにしてもプロジェクトが解散し新たな仕事に就いていただくにはメンバーの方々へのモチベーションを考えて取り組む必要があります。

張　：きめ細かく考えていくと、いろいろとあるのですね。

前田：よく言われることなので、皆さんも十分ご存じのことだと思いますがプロジェクトの立ち上げ時の気分の高まりに比較して、終結時にはどうしてもテンションが下がります。

劉　：確かにそういうことはありますね。プロジェクト自体はまだ途中でも役割の終えたメンバーが次の仕事や、次のプロジェクトに移っていく場合もありますね。

前田：それ自体は仕事のためであり、やむを得ないのですが、フォローのためのコミュニケーションが不足していると残務のために残された人は、何となく取り残された気分になりモチベーションが下がるという事ですね。

張　：それは私も感じたことがありますね。開発したソフトウエアプログラムにバグが発見したことや、改善のための追加開発などが尾を引いて一部の開発者だけが後処理に残ったということがあります。

楊　：そうですね。私の若いときのことですが、プロジェクトの企画立案者で信頼していたキーマンであった人がプロジェクトの終結前に人事異動でプロジェクトから外れた時はモチベーションが下がりましたね。

張　：そのようなこともあったのですか？それはちょっとがっかりされたでしょうね。

前田：そういうこともありますね。チームワークも良く頑張って取り組んできたプロジェクトほど一体感の喪失感があるのですね。

楊　：前田ＰＭが言われたように、フォローのためのコミュニケーションが重要ですね。

前田：人事に関する扱いは、メンバー個々の価値観によっても受け止め方が異なるものです。したがって決して十把一絡げ（大雑把に）で対応をしないことですね。個々のケースによっても対応を考えて行なうことが必要です。

張　：分かりました。よく考えて取り組みたいと思います。

前田：困ったことがあるようでしたら、私に話を持ちかけてください。いつでもご相談に応じます。

4-3 プロジェクト完了レビュー

4-3-① プロジェクト立ち上げ、計画フェーズのレビューについて話し合う：

（会話の前提）
新商品ネットワーク・カラーレーザー・プリンターの開発プロジェクト［ＯＭ４２Ｐ］が計画通りに完了することになりました。このプロジェクトの立ち上げ時からＰＭとコアメンバー（ＰＬ：プロジェクトリーダー）という立場で取り組んできました。ＰＭの前田さんはプロジェクト終結に当たり完了レビュー書を作成するためにコアメンバーと資料を参考にしながら要点であったことを話し合うことにしました。

前田：プロジェクト完成図書の重要な位置づけになる完了レビュー書を作成に取り組みたいと思います。今までのプロジェクト会議やその他の打ち合わせ議事録などの資料を参考に振り返りをしたいと思います。

楊　：そうですね。まず立ち上げ時のところですが、新商品としての画期的な小型軽量、高性能という要求仕様書には驚きましたね。

前田：そうですか、私は楊さんと初めてプロジェクトチームを組むことになりましたが、随分自信たっぷりで頼もしいＰＬだと安心したことを覚えていますよ。

楊　：いやいや、それは見かけ倒しだったですね（笑）実は本当は、上手くできるか心配していたのです。

前田：そんなことはないですね。ご謙遜でしょう。結果的に上手く目標を達成できたじゃないですか。

楊　：確かにそうなのですが、途中でさらに軽量化という変更要求がでましたが、新商品としては最初の仕様は少し甘かったのでしょうね。

前田：そうですね。要求仕様書に従うことで、技術的な可能性を追求するという積極性が不足していたかもしれませんね。

楊　：そこは完了レビュー書にはどのように表現するか難しいところですが、要求仕様書を吟味のところで話し合いが不足していたかもしれませんね。

劉　：私も同感のところがありますが、ちょっと観点の違った反省もあります。実行フェーズ直前で仕様の変更が出ましたが。当初、軽量化対策は筐体と構造を担当する楊さんの範囲と軽く考えていました。

前田：確かにそうかもしれませんね。実は私も筐体の材質や構造を見直すことでできるのではと考えていました。

張　：私はソフトウエアプログラムの開発担当なので全く気にもしていませんでした。

劉　：変更要求が出たことで、電気部品、電子部品、電気配線系統の設計を見直し、かなり軽量化に貢献できたのですが、先ほどの楊さんのおっしゃった、技術的な改善への取り組み意識が不足していと反省しています。

前田：皆さんのご意見は貴重です。今後のプロジェクトでの取り組み姿勢にも反映できることだと考えています。

張　：諸先輩の素直で実直な反省に、私は感動しました。プロジェクトのリーダーとしてのあるべき姿を教えられたような気がします。

楊　：おやおや、張さん、随分殊勝な心がけですね。後が怖いね！

張　：いや、そんな気持ちではありませんよ。私はプロジェクトの開発チームのリーダーとして、初めて任務に就いたのですが、正直に言って、皆さんに依存する気持ちが強かったのですよ。しかし、いい経験を積むことがプロジェクトだったと感謝しています。

前田：まとめとしては、良いチームワークのプロジェクトだったと言えますね。反省としては、技術者は受身で仕事に取り組むのではなく、可能性をアクティブに追求するという事ですね。特に立上げ、計画時のフェーズでその意欲を発揮することですね。

4-3-② プロジェクト実行フェーズのレビューについて話し合う：

（会話の前提）
前田さんは、プロジェクト完成図書におけるプロジェクト実行フェーズのレビュー書を作成するために、コアメンバーと話し合うことにしました。実行フェーズはプロジェクトの中で、もっとも多くの開発工数と開発者数、それに伴う開発コストの掛かるところです。計画段階と違って実務に入るために、さまざまな問題が発生するフェーズです。プロジェクトの成功のためにマネジメント上で大きな負荷の掛かるフェーズでもあります。

前田：今回は実行フェーズで皆さんがお気づきのところについてお話し下さい。　　　もちろん、今までのプロジェクト進捗報告会議などで取り上げた問題もあると思いますが、よろしくお願いします。

楊　：では、初めに私の方から実行フェーズでの特に問題と感じたことを取り上げたいと思います。試作機テストの段階で筐体の構造上の問題を引き起こしたことが最も大きな問題でした。

前田：確かにあの時は、終盤に近い段階でしたから大変でしたね。

楊　：皆さんにもご迷惑をおかけしました。特に劉さんチームが開発した電気部品の焼損事故になり、大問題を起こしてしまいました。

劉　：その問題が発生したことで、電気部品、電子回路、電気配線の全体を見直すことになりました。

楊　：あの時は、劉さんの開発チームでも電源トランスの焼損という事で問題の原因ではないかとの見方もあり、ご迷惑をおかけしました。

劉　：確かに根本的な大きな問題だったので、新商品のリリースに間に合うかと心配しました。しかし、その見直しチェックの段階で、電気回路上で数か所の脆弱なところの発見につながったのは幸いでした。

楊　：そう言っていただくと、却って恐縮しますよ。こちらの問題が原因ですから。

劉　：結果論ですが、事故の未然防止という点で良かったのではないでしょうか。それがなければ後々にクレーム事故になったかもしれませんね。

前田：確かに“災害転じて福となす”という言葉がありますが、楊さん敢えてお尋ねしたいのですが、問題の原因は何だったのでしょうか？

楊　：これは当時のプロジェクト報告会議でも詳しく報告しています。プリンター筐体と構造の材質を変更し、軽量化した結果、駆動系の連続した振動に駆動部品を支えるサポートプレートが異常振動したことが真の要因つまり原因です。

前田：確かにそのように分析調査報告を受けています。

楊　：ここで、さらに追加して述べておきたいことがあります。よろしいでしょうか？

前田：もちろんです。是非お聞かせください。

楊　：当時の事故報告では問題の原因はプリンター筐体・構造の軽量化による強度低下としていますが、もう少し深く原因を追究した結果についてお話します。

劉　：私も関心があります。是非、お聞かせください。

楊　：問題は材質の軽量化や構造の変更ではありません。それは前提条件でした。強度的には採用した材質の品質仕様でも把握していました。問題は材質変更や、構造変更した設計の検証確認のあり方にあります。　　　ストレステストのレベルより低い負荷でのシミュレーションで大丈夫と判断したことが本当の原因ではないかと考えています。

前田：詳しいお話をしていただき有難う。楊さんの原因追及の姿勢は本当に立派です。これは今後の教訓の事例としても取り上げます。とても参考になるお話でした。

4-3-③ プロジェクト変更管理のレビューについて話し合う：

（会話の前提）
今回のプロジェクトでは市場戦略上、新商品の競争力を高めるために必要とされた変更要求項目がありました。それ以外にも技術的な観点から設計変更が必要となり、プロジェクトの判断で変更要求手続きを行ったものもあります。変更要求はプロジェクトに大きな影響を与える場合もあり慎重な判断が重要です。前田さんは、プロジェクトの中で行われてきた変更管理のあり方そのものについてコアメンバーと話し合うことにしました。

前田：このプロジェクトでも幾つかの要求仕様の変更が発生しています。変更はやむを得ない理由により発生するものですが、計画の見直しをするため、スケジュールに大きな影響をあたえます。コアメンバーのみなさんもご苦労だったと思います。

楊　：確かに最初の大きな変更時の対応は大変でしたね。技術的な再検討はもちろんですが、スケジュールもすべて変更でしたから。

前田：そうでしたね。機器の軽量化という変更要求でしたから機器全体の見直しになりました。

劉　：電気部品も少しでも軽くしたいとすべての見直しをしました。

楊　：プロジェクトで仕様の変更があると、技術的な可能性の検討と実現性の確認、そして設計、と作業内容の追加と変更のＷＢＳ（ワーク・ブレイクダウン・ストラクチャー）が発生します。

劉　：ＷＢＳは単にそのＷＢＳを追加するだけでなく、変更のために不要になるＷＢＳや変更の結果、追加されるＷＢＳもありますね。

楊　：そうですね。それらのＷＢＳの追加変更情報を関係する開発メンバーに周知徹底しないと重複作業や抜け漏れによるミスが発生するので慎重に対応することが求められるのです。

前田：変更で問題を発生することなく遂行できたのは、皆さんの用意周到な仕事の進め方であったと言えますが、特に工夫されたところはありましたか？

楊　：そうですね。特に工夫という事はありませんが着実に、確実に抜け漏れの無いようにというところでしょうか。強いて言えば、“あたりまえのことをあたりまえにやる”というところでしょうか。

前田：その言葉は、簡単で短いですが、それを実践することは難しいことです。しかし、あたりまえにやることが求められるのですね。

劉　：確かにその通りだと思います。私も楊さんと連携しながら変更対応をしてきました。

張　：変更対応ではＷＢＳだけを変更するわけにはいかず、作業工数の再見積り、作業の前後関係の段取り、優先順位付の見直し、納期との関係でスケジュールの再設定、開発に必要な要員の見直しと確保、コストの見直し等、計画工程のすべてにかかわってくるので、できるだけ途中の変更は認めてほしくないというのが実感です。

前田：張さんの言われることは他のコアメンバーの皆さんも同じだと思います。　　　ＰＭの私もできるだけ、当初計画で遂行できることを願っていますが、プロジェクトの目的や目標との関係で已む得ない場合もあります。

楊　：それは、当然のことですね。プロジェクトをやり易くするのが、プロジェクトの本質的な目的ではありませんから。戦略上や、発注部門の意志が優先されると考えています。

前田：プロジェクトの途中での変更を安易に受け入れるべきではありませんが、必要なものはきちんと受入の対応をするということでしょう。

楊　：変更管理はその影響をよく見極めること、各変更作業はもちろんのこと関係者への情報伝達を明確にしておくことが大切と考えています。

4-3-④ プロジェクト終結フェーズのレビューについて話し合う：

（会話の前提）
プロジェクトの終結フェーズでは、組織が活動の目的を成し遂げ、終息するときのマネジメントには多様な課題が残されています。実行フェーズ段階での残された開発課題の対応と処理、プロジェクト成果納入後の対応体制の準備と引継ぎ、外部の協力会社への契約終了の締結と費用の支払い処理、プロジェクトメンバーの処遇、教訓の整理と蓄積などがあります。前田さんは終結フェーズレビューのためにコアメンバーと話し合うことにしました。

前田：今回の話し合いはプロジェクト完了報告書に盛り込むことが狙いですが終結フェーズでの課題に取り組み方についてレビューしたいと思います。

張　：外部の協力会社との業務委託契約の終了や費用の支払いは早急に対応できたので問題はなかったかと思っています。

前田：そうでしたね。他の開発チームも対応処理がすべて完了しています。協力会社との信頼関係を損なうことのないように基本的なことはできていると思います。

劉　：私の担当分野では電気部品の購入契約の課題がありましたが、これも先週、完了したと調達部から連絡を受けています。

前田：了解しました。すると対外的な課題はすべて片付きましたね。

劉　：そうですね。対外的な課題はすべて処理できました。後は社内的なことですが、今回のプロジェクトではすべての開発チームがよく頑張りました。この頑張りに報いたいと考えているのですが・・

前田：実は今日皆さんに相談したいことの一つに、いまの提案があります。

張　：私もそうなればメンバーも喜ぶのではと考えていたところです。

前田：みなさんの働きについては、商品企画部から大いに称賛をいただいているところです。

楊　：それは嬉しいですね。我々も苦労した甲斐があったというものです。

前田：社内的な手続きもありますが、プロジェクトのステアリングコミッティ（：プロジェクトを支援する半公式な組織。運営委員会ともいう）からも賛同・合意されると思います。

張　：それは素晴らしいですね。メンバーのモチベーションにも良い影響を与えることができます。

前田：それは、それとして果報を待つことにしましょう。ところで終結フェーズでは各フェーズで残された教訓についてもまとめることが重要な課題です。

楊　：私の担当した開発チームでも、いくつかの教訓があったと思います。失敗したことも教訓の一つですからきっちりと整理して残そうと思っています。

劉　：成功したことよりも、失敗したことの方が奥深いように思います。成功するにはそれなりの基本をしっかりやることで条件が良ければなんとかなる場合が多いようです。

前田：確かにそういうことがありますね。しかし、基本をきちんとやることで成功したというのも教訓の一つです。

張　：いずれにしても教訓を残すことは我々の仕事の一部ですね。私も頑張って役に立つような教訓を残す努力します。

4-4 教訓を整理する

4-4-① 各フェーズで発生した問題について話し合う：

（会話の前提）
前田さんはプロジェクトの教訓を整理するために、各フェーズで発生した問題について情報を共有するためにコアメンバーと話し合うことにしました。 最初の立上げフェーズから、計画フェーズ、実行フェーズ、終結フェーズのなかで発生した問題の大小を問わず自由に話し合うことにしました。全体の整理ができた段階で教訓集として登録することにしています。

前田：今回の話し合いは、皆さんが教訓に残したいと思われた問題を出していただきたいと思います。

楊　：そうですね。私のところでは例の問題ですね。

張　：例の問題って、あの問題ですか？

楊　：そうやっぱりあの問題ですね。

劉　：なんですか！このやりとりは？

前田：私も知っているあの問題ですね。

張　：みなさん、ちょっと今日は変ですね。

楊　：では、まじめに話します。皆さんもご存じのストレステストで電源トランスの焼損事故ですね。軽量化という視点にとらわれて、信頼性、安全性をおろそかになったあの問題ですね。

劉　：確かにあれは反省することも多く、教訓にしたい内容ですね。

前田：他に取り上げたいことはどのようなことがありますか？

張　：ソフトウエア開発での失敗事例です。新商品のアプリケーション開発に外部の協力会社に開発業務委託しましたが、途中で作業遅れが発生したのです。

前田：そうでした。確かにありましたね。その時の対応事例ですね。

張　：そうです。当初派遣されてきた技術者のスキルが低いと判断し、協力会社の責任者に要員の再選抜をお願いしました。

前田：それでもあまり計画通りには進捗しなかったことでしたね。

張　：そうです。それでもあまり作業の遅れを取り戻せないので、強引に作業の進め方に関与してしまったことです。結果、協力会社の技術者のやる気を大きく削いでますます作業の進捗がすすまなくなりました。

前田：張さんは、その原因がどこにあると考えていたのですか？

張　：マネジメントの鉄則は、人のやる気即ちモチベーションを上げることですが、それとは反対の過干渉でやる気を低下させてしまったことですね。

前田：なるほど、それはマネジメントのありかたとして失敗の教訓ですね。その失敗の本質はどのように考えていますか？

張　：失敗の事実は明白ですが、なぜ失敗したかの本質を十分に分析できていない、つまり自分自身の反省すべきことがまだ不十分だと思っています。

前田：張さん、謙虚なのはいいのですが、あまり自虐的にならないほうが良いですね。ご自分では十分に気付いていると思いますが？

張　：そうですね。基本はやはり話を良く聴くというところでしょうか。相手の困っている内容を理解せずに強引に手を出し過ぎたという事ですね。

前田：そうですね。こうした人間関係の問題には、お互いにコミュニケーション力を身に付けるということではないでしょうか。

張　：わかりました。特にマンジメントする側の意識を変えることが教訓といえますね。その意味では重要な教訓ですね。

4-4-② 各フェーズで発生した問題への解決策について話し合う：

（会話の前提）
プロジェクトで発生する問題は、どのフェーズを問わず発生します。戦略上の問題、技術上の問題、組織編制の問題、要員確保の問題、要員のスキルの問題、前田さんは、こうした問題を含め問題解決への取り組み方で教訓に反映できるものを整理するためにコアメンバーと話し合うことにしました。

前田：今回のプロジェクトでも様々な問題がありました。特に後半のフェーズで発生した問題には深刻な内容のものもありました。問題は後半で発生　するほどリスクの影響度が大きくなる傾向があります。

楊　：確かにその傾向はありますね。

前田：もちろん前半の初期段階で発生した問題はリスクが小さいという事ではなく、プロジェクトの目的、目標を達成するうえで致命的なものもあります。

楊　：プロジェクトの後半で、スケジュール的にも余裕のない土壇場で発生した問題は、対応にも切迫感が募ります。これは私の実感です。

前田：こうした問題を解決してきたのですが、その問題解決のありかたで教訓になることがないか話し合いたいのです。

楊　：そうですね。問題が起きたことに拘るのではなく、その解決のあり方で教訓になることを話し合うことが狙いでしたね。

前田：そうです。そうです。自分が失敗したときは誰でも責任感で自らの行動を厳しく見つめすぎてしまいます。大事なことはなぜそうなったかについて後進の人の役に立たせることが大事なのです。

楊　：それほど自分自身には厳しくはないと思いますが、若干の拘りが残っていますね。それはさておき、教訓として見直してみたいと思います。

前田：是非そうしてください。劉さん、張さんも教訓としてどう残せばいいか忌憚なくご意見を述べてください。

楊　：あの問題をテストチームから報告を受けた時は、“そんなはずはない”と疑ってかかっていましたが、まずは事実の確認として、担当の開発技術者とテスト室に赴きました。

前田：事実を確認するは、問題解決の第一歩ですね。

張　：確か以前に現場・現実・現状という言葉を聞いたことがあります。

楊　：わたくしもその言葉がまず頭に浮かび、疑問を持ちながらも事実の確認に向かいました。

前田：そこが要点ですね。よくあるのは自分の責任でないことを証明するために問題よりも自分の正当化を確認する行動に入ることが多いのです。

張　：それはどのようなことですか？

前田：例えば、設計仕様の確認を先に行うなどに時間を費やし、問題より責任かの所在に気を奪われ、問題解決行動が遅れてしまうことです。

楊　：私もその気持ちは無かったわけではありませんが、少し理性的だったという事でしょうか。現場を見て、問題の要因は大体把握できました。直ちに技術者を集め、解決策案の検討に入りました。

前田：素早い行動でしたね。私も主要なステークホルダーには状況を報告し解決策に取り組んでいることを伝えました。

楊　：皆さんのご協力で、直ちに解決策が功を奏したのは不幸中の幸いでした。ここでの教訓は素早い行動もありましたが、開発関係者が事実を把握し情報を共有し、目的を明確にしたことだったと思います。そういう意味で日常的にもコミュニケーションが良いことが基本と言えます。

前田：コミュニケーションの重要性と、組織としての目的、目標を共有し、さらに価値観を理解しあえるということですね。もちろん、解決策案を創出できる専門家としての技術力は大前提です。

4-4-③ 各フェーズで発生した問題への対応で得た教訓について話し合う：

（会話の前提）
前回の話し合いの中に問題発生時の対応で、現場、現実、現状という言葉がありましたが、“三現主義”と言われています。プロジェクトに関わらず通常の業務においても同様の対応姿勢が重要です。今回の問題への対応のあり方で得た教訓をまとめるために前田さんはコアメンバーと話し合うことにしました。

前田：前の話し合いでは、楊さんの経験した問題への対応が中心でしたが、今回は他の人の経験もお聞きしたいと思います。

張　：私が対応した問題ですが、新規技術を採用したアプリケーションソフトの開発で、自社には適切な人材がいないので、外部の協力会社に開発業務委託したことで発生した問題でした。

前田：ところが協力会社の技術者4人の内１人のスキルが要求レベルを満たしていないということでしたね。

張　：そうでした。それで協力会社の責任者に対応を依頼したのですが、結果スキル要求レベルに見合う技術者の調達はできませんでした。しかし、他の技術者は優れていたので、未熟な技術者の担当領域は、他の優秀な技術者で補完することにして開発に取り掛かりました。

劉　：それだと当初の開発計画を見直すことになったのでは？

張　：そうです。当初予定より少し低下し、開発日程も超過しました。

劉　：そうすると開発コストも増加したという事ですね。

張　：わずかですが、超過しました。しかし、協力会社は当初の要求スペックに未達成ということで、超過分の費用は当初契約した料金金額で処理をすることに合意していました。

劉　：コストの問題はそうであったとしても、開発品質の問題はなかったのですか？

張　：開発品質には十分チェックをしていましたので問題はありませんでした。　　　コストや品質で大きな問題にはなりませんでしたが、大きなリスクとしての要素を持っていたと判断しています。

前田：ところで張さんがこの問題を教訓として残したいところはどういうところですか？

張　：教訓として残しておきたいところは、外部の協力会社とのやりとりで文書ではなく、口頭でやりとりして進めてきたことにリスクの原因があったと思います。

前田：そうですか。それはあとで問題を引き起こしやすい行為ですね。

張　：いまから判断すると、開発技術者の調達に苦労していたので、文書化することをおろそかにして、調達に走ったところがありました。

前田：契約部門や、調達部門との連携にも問題がありましたね。今回はたまたま問題がなく上手くいきましたが、今後はきちんと定められた規則に基づいた手続きをとることですね。

張　：そうです。そういう意味で今後のプロジェクトの中でも起こしやすい問題だと思いますので、教訓になるのではと取り上げました。

前田：十分“教訓”に値する事例だと思います。是非、今回の教訓事項としてプロジェクト完了レビュー書に取り上げたいと思います。

4-4-④ 収録した教訓の展開方法について話し合う：

（会話の前提）
今回のプロジェクトで幾つかの教訓となる事例を残すことができました。 教訓はどのフェーズにもあることですが、日常のプロジェクト活動のなかでは問題解決に注力することで記録し活用することがおざなり（：いい加減なという意味）になっている場合が多くあります。プロジェクトが成功するにも失敗するにも多くの教訓が残ります。前田さんは、こうした教訓が今後のプロジェクトにどのようにすれば活用できるかコアメンバーと話し合うことにしました。

前田：今回のプロジェクトでもいくつかの教訓を登録しました。登録にあたって皆さんのご協力に感謝します。

楊　：いえ、どういたしまして。それより内容を整理では前田さんから的確なアドバイスを頂き感謝しています。ありがとうございました。

前田：いえいえ、私の方こそどういたしまして。今日の話し合いは、この貴重な教訓をどのようにすれば役に立つか皆さんからアイデアを頂きたいと思ってお集まりいただきました。実際にプロジェクトに関わっているプロジェクトリーダーの方の意見は貴重です。

劉　：いままでもたくさんの教訓があったかと思うのですが、正直に申し上げますと、登録するだけで活かされていないと思います。

前田：張さんのご意見はいかがですか？

張　：私も劉さんと同じ意見です。以前に教訓登録集を見たのですが、肝心なところがはっきりしないので役に立たないと感じたことがあります。

楊　：そうですね。教訓を活用するという意識が希薄なように思いますね。

前田：なるほど、皆さんのご意見では、教訓が活用されていないことは、はっきりしましたね。では、そこでどうすれば良いか皆さんのアイデアをお聞きしたいのですが、いかでしょうか？

張　：えーっと、うーん、文句は言いましたがどうすれば良いですかねえ。

前田：ハハハ、ゆっくり考えてください。

劉　：教訓の展開は、やはりなにかそういう場が必要なのではないですか？

張　：プロジェクト完了レビュー会などで発表するのも良いのではないでしょうか？

劉　：しかし、レビュー会に参加するメンバーの数は限られていますね。参加しない限り知る機会がないというのでは現状と同じですし・・

楊　：教訓の内容をもっと多くのメンバーに知ってもらうには、一つの手段に限らず、各種の手段を繰り返すことで理解を深めます。

前田：そうですね。まずは完了レビュー会で発表するというのも一つですね。他にはどうでしょうか？

張　：やはり、社内イントラネットに収録し、プロジェクトメンバーあるいは関係者は閲覧できるようにする手もありますね。そして分かり難いところは質問メールできるとかも良いですね。

前田：それはいいね。ネットワークを活用しないとね。

楊　：もう一つは、技術者のプロジェクト方法論の教育のカリキュラムに取り組むということも効果的ではと思います。

劉　：教育と教訓を結びつけるということですね。それは良いですね。実際にロールプレイングなどで演習するのも良いかもしれませんね。

前田：とても魅力的なアイデアだと思います。教育部門にもインプットして実現できるように進めたいと思います。ご意見ありがとうございました。

4-5 プロジェクト成果のまとめ

4-5-① プロジェクトの目的と目標への達成度について話し合う：

（会話の前提）
新商品の開発プロジェクトも無事に完了しました。プロジェクトの目的であるネットワーク・カラーレーザー・プリンターは、量産体制に入り、市場導入を開始することになりました。前田さんはプロジェクト成果のレビューの場を通して、本源的なプロジェクトの意義をどう理解するか、コアメンバーのマネジメントスキルの高まりを期待して話し合うことにしました。

前田：今回のプロジェクトの目的は達成できたと判断しています。目的とした新製品の開発も無事に完了しました。

劉　：プロジェクトの目的を達成できたことは素晴らしいと思いますし、私達も開発に貢献できたのではと思っています。しかし、目標との関係ではどうだったのでしょうか？

前田：私が皆さんとお話ししたいところはそのことです。わが社ではこのプロジェクトで開発された新商品を、これからのグローバル事業戦略の中軸に位置づけしてと考えています。

張　：するとプロジェクトの目標という事ではどのような関係になりますか？

前田：今回のプロジェクトは新商品開発プロジェクトと位置付けていることは皆さんも十分にご理解していただいていますね。

張　：それは最初のプロジェクト立上げの時から理解しています。

前田：わが社がこのプロジェクトを立ち上げた背景から説明しますが、この新商品開発プロジェクトは、事業戦略の一つで、他の商品開発とも連動しています。

劉　：それは私も理解しています。私の同期の者は他の新商品開発プロジェクトに参加しています。

前田：わが社の事業戦略には、幾つかのプロジェクトを並行して進めていますが、新商品をグローバルな市場にどのように展開していくかというプロジェクトもあります。

楊　：それは、プロジェクトを統合的にマネジメントするプログラム会議で決定されていることですね。

前田：そうですね。プログラムマネジメントでは、事業戦略に必要な投資と選択を判断します。話が複雑になりましたが、今回の新商品開発プロジェクトに限定していえば目的と目標は達成されたといえます。

張　：前田さんのお考えでは、事業戦略上ではまだ成果目標はこれからだということをおっしゃりたいのですか？

前田：張さん、その通りです。まだこれからの状況を見て、この新商品が事業戦略上の成果があったかについて判断が必要という事です。

張　：確かにそれはそうですね。私たちとしては成功したと喜んでいたいのですが、まだ本当に成果が出ているわけではないのですね。

前田：決して皆さん方の努力した成果を軽視するという事ではないのです。真にプロジェクトの目的、目標の達成についても見据えた評価が必要だということですね。

楊　：前田さんが求められていることは。表層でものごとの判断をするのではなく、深層でものごとを評価するということでしょうか？

前田：そうですね。すこし生意気なことをいうようですが、これからのプロジェクトマネジメントをリードする指導者にとって、考え方の深さ、視野の広さということも重要なスキルと思います。

楊　：よく理解できました。小さな成功に安心せずに目標を高くもてという事にもつながりますね。

4-5-② ＱＣＤの計画と実績の評価について話し合う：

（会話の前提）
プロジェクト活動では、一つの指標だけでなく、幾つかの主要な目標を設定してマネジメントします。その中の大きな要素として、プロジェクト成果物の品質（Ｑ：クオリティ）、プロジェクトを運営するための費用（Ｃ：コスト）開発の最終スケジュール日程としての納期（Ｄ：デリバリー）があります。前田さんは、プロジェクト完了レビューに際して、プロジェクトのＱＣＤ計画と実績との関係についてコアメンバーと話し合うことにしました。

前田：皆さんと一緒に取り組んできたプロジェクトを評価するに際して、幾つかの指標と比較して評価をしたいと思います。

楊　：大きな指標としてはＱＣＤでの評価ですね。それぞれの内容について順番に進めましょうか？

前田：それでもいいですが、皆さんのお話がやり易い順番でも結構です。それと、プロジェクトを評価するには対象が二通りあります。それも含めてお話してください。

張　：評価対象が二つとはどのような意味ですか？

前田：プロジェクトの結果を評価することと、プロジェクトプロセスのあり方を評価する方法です。プロジェクトは当初計画した目標への到達度で評価することが一般的ですが、より正確な評価をするためにはプロジェクトプロセスも評価の対象にすることが大切です。

劉　：その方法だとプロジェクトの結果さえよければ良いという事ではなくプロジェクトの進め方の巧拙も評価するので、プロジェクトを全体的に評価することになりますね。

前田：その通りです。プロジェクトを進めてきた、施策効果の評価や、施策の進め方によっても、結果は大きく異なるはずです。ただ単に結果を求めて、“結果よければ全て良し”の評価は問題を過小評価にすることになりやすく、次への教訓として活用できないのです。

楊　：では、プロジェクトプロセスでの評価と結果的な評価に分けてＱＣＤのＱから順番におはなしします。まずＱ：品質に対する私の評価ですが、開発が進み終盤のテストで構造上の問題が発生しました。やはり、設計時のシミュレーションに問題があったと判断しています。結果的には構造の強化で対処し、最終的な品質は達成できました。

前田：今の楊さんのお話では、結果的には問題がなかったが、設計時のシミュレーションには問題があったということですが、なぜ、問題があったのかもう少し深掘してお話いただけませんか？

楊　：そうですね。軽量化策で材質を変更し“ねじれ強度”も変化していたにも関わらず、シミュレーションの方式は以前の材質と同様に設定していたために、筐体部品のねじれ幅を測定できなかったのです。

前田：なるほど、そのために問題の予測ができず、ストレステストまで問題を把握できなかったという事ですね。

楊　：そういうことになりますね。この問題の原因は確かにシミュレーションの設定を変えなかったということが作業的には問題の原因と言えますが開発マネジメントとして、材質変更によるリスクマネジメントが真の原因ではないかと判断しています。

前田：なるほど、真の原因は材質変更というリスク要因に対して対応策を考慮していなかったことですね。つまりリスクマネジメント不足ということですね。　

楊　：その通りだと思います。変更時の影響を幅広く考えなかった。つまり物の見方、視野の狭さを感じるものでした。

前田：しかし、その結果、貴重な教訓を得たのではないでしょうか。

4-5-③ ステークホルダーの評価と満足度について話し合う：

（会話の前提）
今回のプロジェクトも、終結フェーズにはいりプロジェクト完了図書の作成作業を進めています。その中にプロジェクトのステークホルダーの満足度について記載する事項があります。前田さんは、プロジェクトをリードしてきたコアメンバーとステークホルダーの評価と満足度について話し合うことにしました。

前田：今回の会議は、ステークホルダーの評価と満足度について話し合いたいと思います。話の進め方は特に決めていませんが、みなさんが話しやすい方法でいかがでしょうか？

劉　：特に複雑な話でもないのですが、ステークホルダーという言葉の範囲を限定しておいた方が良いのではないでしょうか？話し合う内容が分散しないと思います。

楊　：その意見に私も賛成です。今回のステークホルダーとはプロジェクトを起案した商品企画部の関係者、それに事業戦略としてプロジェクトの投資を決定したプログラム会議の関係者に限定すれば如何でしょうか？

前田：あと、重要なステークホルダーとして、新商品を販売する営業部門の関係者や海外への輸出を担当する部門の関係者の評価も入れたいですね。

張　：そうですね。他に入れたいのは、実際にお客様の現場で仕事するメンテナンス部門の関係者の評価も入れたいですね。

前田：それはいいですね。では、まずはこの範囲で始めましょうか。もちろん話の流れで追加項目もあるかもしれませんが。

劉　：プロジェクト会議で、今上げたステークホルダーのプロジェクトの成果に対する意見は集録されています。その中では特に悪い評価はなかったと記憶しています。

楊　：私もその議事録は目を通していますが、特に問題視している項目は無かったように思います。もっとも、ストレステストでの電源トランス焼損事故に対しては納期が遅れるのではと懸念したとありました。

劉　：商品企画部から出された要求仕様書はすべて対応できました。このプロジェクトに期待されていた、成果物の品質は満足していただけたと思っています。

前田：全体のコスト面での満足度ですが、若干のコストオーバーがあったので少し評価のポイントは下がっていますが、プロジェクトのコストマネジメントの範囲内で終結したので問題はないといえます。

張　：コストオーバーを招いたのは私の担当分野で作業の進捗が低下したことによるものです。

前田：ソフトウエア開発だけでなく、筐体、構造開発、電気回路、電子回路設計の作業も若干の遅れは生じましたが、スケジュール的には、作業計画の見直しと組み直しで、最小限の遅れで済ませることができました。

楊　：どのチームもチームワークで乗り切ったところが大きいと思います。

前田：このプロジェクトに対する主要なステークホルダーからの評価と満足度は高かったようです。そして、私自身はコアメンバーの皆さんと、実務で作業を進めていただいた、多くのメンバーの皆さんに対し、文書や言葉では表現しにくいのですが大いに満足しています。改めて感謝の気持ちを伝えたいと思います。

楊　：いえいえ、こちらこそ。プロジェクトを成功に導いていただいた前田さんに心から感謝しています。

劉　：私も楊さんと同じ気持ちです。ありがとうございました。

張　：みなさん、ちょっとまだ気が早いですよ。それはプロジェクトの最終レビュー後の打ち上げでの言葉でしょ？

前田：ははは、そうでした。私が話を横道にそらし余計なことをいいました。

張　：まあ、今までのご苦労に免じて許すとしましょう。

4-5-④ ビジネスとしての成果と評価について話し合う：

（会話の前提）
幾つかの困難を乗り越えて新商品開発ＯＭ４２プロジェクトも成功裏に完了しました。初めて中国でのプロジェクトをＰＭとして担当した前田さんは、有能はコアメンバーに恵まれたことがプロジェクト成功の最も大きな要因と考えています。また、コアメンバーの各リーダーも前田ＰＭからプロジェクトマネジメントにとって重要な多くのことを学ぶことができました。特にＰＭ方法論を基本にして“当たり前のことを当たり前に行う”ことの重要性をまなんだと言えます。前田さんは、今回のプロジェクトが今後のビジネスにとってどのような成果をもたらすか評価のあり方についてコアメンバーと話し合うことにしました。

前田：いよいよこのプロジェクトでのコアメンバーの皆さんとの話し合いの場としては最後に機会になります。今回の話し合いでは、プロジェクトの成功がどのように進展していくか、みなさんと話し合いたいと思います。

楊　：これが最後のコアメンバーミーティングですか、たくさんのことを話し合ってきましたが、あっというまですね。

劉　：今まで、プロジェクトをしかも、自分の担当する業務を達成することに全精力を注いできました。しかし、今回のプロジェクトでは、自分の目の周りのことだけでなく、プロジェクトの本源的な目的にも意識することを教えられました。

張　：私はＰＬとして初めて担当したのですが、皆さんのものの見方の広さに感心しました。開発技術者としての自信はあったのですが、プロジェクをこのような視点で見るという事は初めてでした。

前田：みなさんの率直な感想をお聞きできて大変良かったと思います。一般的ですが、プロジェクトをリードする場合、その場面でのことに注力しすぎて真の目的が遠くなってしまう傾向があります。

張　：確かに私の場合はその傾向が強かったように思います。

前田：これはプロジェクトと名前の付く仕事だけではありません。あらゆる仕事においてもいえることですね。

劉　：もう少し詳しくお聞かせください。

前田：わかりました。例えで話をしましょう。家を建てるプロジェクトでは、基礎工事、柱の構造、屋根造り、電気、水道、ガスなどの工事、内装工事などなど多くのメンバーに支えられて工事が進みます。　建築工事全体の進捗を管理するのが大工の棟梁です。つまりプロジェクトマネジャーですね。

張　：家づくりもプロジェクトなのですね。

前田：その通りです。ここで伝えたいことは、どんな家でも住むお客様がいるということです。プロジェクトマネジャーはこのお客様の立場にどれだけなれるかということです。

張　：でも、実際は、早く、安くとかの要求で手抜きをするとかの話をきいたことがありますが。

前田：もしそうだとすると、その大工さんや建築会社は信用されないでしょうね。建築業界の例でいえば、お客様がその家に永年住んで良かったという評価が究極の評価です。

楊　：その事例は私達の仕事の姿勢にも共通するということですね。

前田：私たちの仕事の成果が、利用されるお客様にどのような価値を提供できるかということですね。そのことを考えてプロジェクトに取り組むことが、ビジネスとして最も重要だと言えます。

楊　：よくわかりました。

前田：こうした仕事への取り組み方、仕事の目的、成功の意味について、皆さんだけではなく、より多くのメンバーと価値観を共有することがプロジェクトの成功とビジネスの成果につながっていくのです。これで私の伝えたいことは終わります。

楊　：前田さん、本当に長い間ＰＭとしてご指導いただき感謝しています。次に機会がありましたらまたプロジェクトで一緒に働きたいです。

劉　：私達もこのメンバーでまたプロジェクトを組めることを願っています。本当に長期間ご指導いただきありがとうございました。

読者への思い

　この本は着想の段階から数えると３年間近くの歳月が掛かりました。１年前から、本の作成に着手して、今年の7月に翻訳もようやく終了しました。

　この本の目的は、日中間のITプロジェクトの現場で、円滑なコミュニケーションを目指しておられる皆様にご活用していただくことを願っています。

　筆者がこの本を作りたいと思うようになったのは、私自身が日本と中国の間でＩＴプロジェクトの実務に関わる中で、双方の言語への理解と習熟がプロジェクトのコミュニケーションに極めて重要と感じたからでした。

　八十年代以来、日中間の経済合作に多くのビジネスモデルが形成されました。関連就業者も日々増しています。以前、少なくとも、中国においては一部国際交流や特殊の業務を従事する人たち以外、外国語が学校の中の教養科目だけです。しかし、今は、自由市場の業者も甲高い外国語で顧客と売買の交渉をする光景が日常茶飯事になりました。外国語が教室から出て、必要なコミュニケーション･ツールになりました。

　筆者の居るＩＴ業界には、ただ一部分ですが、中国の巨大な市場、日本国の多くの人材需要、両国間のコストのギャップ、多くの日本企業を中国に引き寄せて、貿易から、委託生産、サービス業などさまざまなビジネスが展開されて、一方、中国から多くの起業家、技術者、労働者が日本国に来て働いています。このようなビジネス移動と人材移動に伴って、日本語と中国語とも分かる専門人材に対する需要が膨大です。

　筆者の居るIT業界でもオフショア開発を行うためにこのような人材は不可欠な存在です。日中両側のシステム開発組織間のコミュニケーションギャップを埋める人材で、意思疎通や仕様伝達、作業管理の役割を果たしています。その期待役割はあたかも河を跨ぐ橋のようであり。職種の名称をＢＳＥ（Bridge System Engineer）とされています。

　今までにも多くのプロジェクトが国境を越えて行われてきましたが、ＢＳＥの方々の努力のお蔭であると言えます。その成果は発注側のコストが安くなっただけではなく、多量な国際的な技術人材も育成できました。理想は橋渡し役が多くなれば、橋が道路になりますが、しかし、妥当ではないかもしれないですがＢＳＥの副作用として、ＢＳＥに頼りすぎる現象もあります。もう一つ、深く感じたことが専門分野において、熟練の外国語を身につける難しさです。教養としての用語だけでは足りません。大学で日本語を専門に学んだ方が技術分野の訳者を務めませんし、無理して、翻訳したカタログやマニュアルは利用者が見て、わけが分からなくて、困った事例があります。

　この本は、そうした困った事例を少なくするためであり、プロジェクトに参加する日中双方の管理者やメンバーが、相手を正しく理解しあうことが重要との思いから書いています。ＢＳＥに頼りすぎず、自分の耳で相手の意思や気持ちを確かめ、自分の言葉で意思を正確に伝えることだと思います。

　そのためには、専門用語が分れば良いだけではありません。その用語はビジネスでどのように使われているか、ビジネスでその技術をどう進めているかは、言葉のノウハウが有ります。言葉は奥深い学問門だとしみじみと感じています。高等で国際的な専門人材に求められる外国語の能力は、一般教養用語、共通ビジネス用語、専門技術用語と、さらにはプロジェクトを管理する管理用語やコミュニケーション力を備えることです。

　筆者の知るところでもIT分野のオフショア案件が円滑に進まない例が少なくありません。そうした中で、プロジェクトのコミュニケーションがよりよく出来れば、多くのトラブルが消えるでしょう。この本はより多くのプロジェクトを成功させる思いを託して、皆様の活躍する現場で少しでもお役に立てば、光栄と思います。読者の皆様からの感想を聞かせていただくことが、さらに喜んでいただける作品を産み出す原動力になります。

　最後にこの本の原稿考案、作成していただいた久井信也氏に心より深くお礼を申し上げます。中国語版の訂正をしてくれた主人の王大群に衷心より大変感謝しています。