「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト
「曖昧性とのたたかい」という本をご存知でしょうか？日立製作所で、みどりの窓口などの開発に携わった名内氏が、自身のプロジェクトマネジメントの経験をまとめた名著で、プロジェクトマネージャーなら必読の一冊です。アジャイルやリーンというモダンな開発手法が確立されていないなかで、大型のシステム開発をする厳しさは想像に難しくありません。また、その厳しさがタイトルによく現れていると思います。
システム開発に関わるプロマネに必須のチェックリスト
「曖昧性とのたたかい」は疑うことのない名著ですが、SE出身の著者ということもあってか、システム設計への言及などその内容は多岐にわたります。そこで純粋なプロジェクトマネジメントの要素に主眼を置いて、自分に刺さったところを「契約フェーズ」「設計フェーズ」「実装フェーズ」に分けてリストアップしてみました。詳しくは本書の購入をお薦めしますが、概要を斜め読みしたい人は参考にどうぞ。
契約フェーズ
提案と交渉
ポイント
- 提案依頼書に要求仕様などの詳細が書かれていることはまずない
- 完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
- 曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
チェックリスト
- 仕様が膨張するものとして、予算増額の必要性があることを事前に伝える
- 顧客からの仕様変更要求に際しては、必要な対策日程の確保と対策費用を負担していただくことを契約に盛り込む
- 予算増額の論拠を用意しておく（当初見積もりの前提条件を明確にしておく）
- 時間の許す限り、顧客の要求を文書化する
- 仕様の膨張が濃厚であれば、開発段階を区切り、最初の段階だけを見積もらせてもらう
- 契約納期と絶対納期（顧客側で死守しなければならない期限）を把握しておく
- 契約納期には「仕様凍結後○ヶ月」のような条件をつけておく
- 検収条件を「条件Xのとき結果Y」のような明示的なものにするか、検収期間を有限にして検収テストは全て顧客に実施してもらう
- 見積もりは再見積もりが許される条件設定をしておく
- 要求仕様が曖昧すぎる場合は、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらう
設計フェーズ
要件定義
ポイント
- 受注が決定したら、全力を挙げて受注条件の明確化、再確認、システム仕様の早期確定に努めなければならない
- 基本的に契約金額内で仕様をまとめることが両者にとって大事なことであり、かつ両者の利益につながるのだという共通認識を確認し合って仕様の確定に臨む
チェックリスト
- 契約書のみならず（提案と交渉の時の）覚書や議事録も確認する
- 検収条件をよく読み、無理なく検収されるような検収条件になっていることを確認する
- 見積り条件や検収条件に不備があれば、今後どう正常化してゆくべきかを営業担当者とともに善後策、および顧客といかに交渉するか戦略を立てる
- 打合せに入る前に、まず見積り / 契約条件に盛り込んだ（受注者側の考えている）システム仕様をより具体的に文書化して提示する
- 詳細を説明した後、発注者からの「変更要求」を聞くようにするのが仕様の早期確定に有効であるばかりでなく、「仕様変更要求項目」の明確化にも役立つ
- システム全体の開発費用は仕様確定後に決めるという段階的契約方式をとる場合も、顧客側には予算の腹づもりがあるはずなので 、総予算を聞き出して、この予算枠内で仕様をまとめるように顧客をリードする
-
いつまでにシステム仕様を固めるか全体工程の中で顧客と合意し決める
-
もし発注者側の体制や統制力に問題がある場合には、幹部、営業と協力して、発注者幹部に善処してもらえるよう早めに申し入れる
- 業務仕様をどういう順序で確定していくかあらかじめ作戦を立てておく
- プロトタイプ方式を採用するときは、終結時限（仕様凍結時限）を明確に定め、いつまでもやり直しや修正が続かないようにする
- 何のためにシステムが必要とされ、何が一番重要なことなのかを全員が正しく理解する（真の目的を把握していれば、より合理的、より経済的な代案システムの提案も可能となり、システム機能の膨張の抑制につながる）
- 業務の正確な理解に努める（正確な理解とは、その業務の目的、やらなければどういう不都合が生じるのかということまで理解すること）
- 仕様追加がある場合は、要求しても無理だろうなどと考えず、粘り強く予算増額交渉をする
- 仕様が凍結したら、新たな仕様変更要求が出てくる前に、仕様変更案件管理、変更承認手続き、顧客による変更予算認可手続きなどの管理方式を顧客と共同で用意する
- 受注したら直ちに第三者を含めてプロジェクト推進作戦会議を開催し、多角的にリスク回避戦略を議論する
工程設計
ポイント
-
受注後、プロジェクトマネジャーがまずやらねばならないことは、工程の設計と目標原価の設定
-
プロジェクト工程計画とは、そのプロジェクトに挑むプロジェクトマネジャーの作戦計画であるから、まさにマネジャーの、そのプロジェクトに関するすべての知識と認識、今後発生しうる各種の事態に対する予測を含めた見解を表現したものとなる
-
人件費は、ざっと言えば投入工数のみで決まる。投入工数が予算以上に増えるのは工程（スケジュール）が遅延するか、開発量が膨れ上がるか、予想以上に品質が悪いかが主たる原因である。したがって、 コスト管理はとりも直さず、進捗管理、品質管理、仕様変更管理の問題に帰着する
チェックリスト
- 稼働日（=納期）に絶対不可欠な機能と、無理をすればあとからでも追加可能な機能に分ける
- やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計する
- PERT図の考えを取り入れ、前後関係、相互依存関係が明確になるようにする
- 重要な仕事にはその前に必ず準備作業（仕事の前の仕事）が必要であることを忘れないように
- 工程配分は過去のプロジェクト実績データを参考にすべきであるが、少なくとも3分の1の工程を設計工程に割り当て、手戻りのない設計を目指す
- あらかじめどういう手段で進捗を計るのか考えておく。特に各工程の終了条件を明確に決めておく必要がある（定量的進捗度の把握が大事であるが、質的な進捗度の把握については中身のレビューで補う）
- 計画時には悲観的に最悪事態を想定した準備を行い、実行時は楽観的に明るくプロジェクトを推進する
- 最悪の事態に陥った場合、納期延期を申し入れる日を秘かに決めておく
- 同時に納期までに完成が困難と予想されるときは逃げ道を考えておく（代替手段、部分稼働、従来システムとの並行運転など）
- 工程表が作成できたら顧客と打合せを実施する。このときには、特に仕様凍結日、提出書類の承認期限、顧客側で準備してもらう各種ドキュメントなどの準備期限について合意を得る
- プロジェクトで用意するドキュメント体系、およびその作成基準を定める
- よく使われる業務用語（ジャーゴン）については、素人の人にもわかるような用語集（グロッサリー）を用意し、プロジェクトのステークホルダー全員が共通の理解を持てるようにする
- 大規模プロジェクトの場合はプロジェクトマネジャーの補佐組織として、ライン設計部隊とは別のプロジェクト統括部隊を編成する
- 開発するシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクト共通基準、工程計画に関するプロジェクトマネジャーの考え方などを説明し、全員に理解してもらう（このような全員ミーティングは少なくともプロジェクトのスタート時、主要メンバーが揃って定期的進捗管理が始まったとき、全メンバーが揃ったときの3回は実施したほうがよい）
実装フェーズ
進捗管理
ポイント
- 進捗を定量的、客観的に捉えるとともに、質的な面、つまり設計の充実度、ドキュメントの記述レベル、その内容なども重視して、工程（あるいはスケジュール）の進捗を妨げる問題点の早期把握に努めなければならない
- 仕様変更はプロジェクトの円滑な遂行にはマイナスの影響を与えるが、仕様変更なしのプロジェクトは稀である。したがって、適切な仕様変更管理が必須になる
- プロジェクトの成否を決めるのは、プロジェクトメンバーの力であり、そのチームとしての組織力
チェックリスト
- 計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できること
- 進捗度の事前定義と全員への徹底
- プログラム開発においては、無理をしてでも進捗度を定量的に把握する（ページ数、画面数、帳票数、コーディング行数、メモリー量、項目数、定義数、チェックリスト消化数など）
- 責任追及より実態把握を重視。何の助言もなく厳しいだけの管理はかえって実態を隠蔽する危険性がある
- 仕様確定工程は絶対遅れさせないようする。不幸にして顧客の体制が整備されていなかったり、顧客の決定が遅れてきたときは、幹部や営業の協力を得て、顧客幹部に善処してもらえるよう申し入れる
- 進捗把握は担当者から報告された内容だけに頼ってはならない。自分の目で、現場現物を確認する
- 定量的進捗度と同じぐらい重要なのがレビューを活用した質的な進捗度の把握・評価
- レビューは部厚い仕様書ができ上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんレビューの質あるいは難易度を高めてゆく
- レビュアーの誰かが大幅な変更ややり直しの必要性を訴えるような場合、プロジェクトマネジャーは一番悲観的な意見を採択し、設計のやり直しを決断したほうがよい
- ある担当者の開発部分の品質が時間が経っても一向に改善しないとき、その担当を更迭して一からやり直すのは勇気がいるが、思い切ってやり直しをしたほうが良い結果を生む
- 要員不足だからといって、能力の劣る要員による応援はかえって混乱を招く
- 工程表を書き直していると、工程が遅れてきた実態がわからなくなり危機感も薄くなる。工程表の書き直しは極力やめるべき（やむを得ず書き直して納期を先に延ばす場合は、思い切って実態を正直に反映したものにする）
- 進捗状況がかんばしくないときは早めに営業担当者にその旨漏らしておく
- 混乱したら思い切って開發を止めて、マネージャーの頭の中に実態が正しく認識されるまで徹底的に実態把握に努めるべき
仕様変更管理
ポイント
- 顧客と開發側双方が仕様凍結を宣言できたあとでさえ、さらなる仕様変更が出てくることは実際には多い
- 「仕様変更は不可避」であることを覚悟し、仕様変更による工程の混乱や、収益悪化のリスクを回避するために、変更があってもミニマムな対応ですませる作戦と仕掛けをあらかじめ用意する
チェックリスト
- 仕様変更が続くということは単にベンダーだけの損失でなく、顧客にとってもリスクであり、損失であることを顧客によく理解してもらう
- 仕様変更要求が出た場合、窓口は一元化し、案件管理の手順を定め、変更決定時のソフトウェア/ハードウェア/ドキュメントなどの変更手続きもあらかじめきちんと決めておく
- バグの管理と仕様変更の管理ははっきり分け、別管理にしておく
- システム稼働開始前後数ヶ月の仕様変更は、稼働に不可欠の機能を除き、絶対禁止
組織管理
ポイント
-
プロジェクトメンバーに意欲を持って仕事を行わせるにはモラル（morale: 士気）管理が欠かせない
-
数十名、数百名に及ぶプロジェクトにおいては、メンバー間、チーム間、組織幹部や顧客との間の適切なコミュニケーションが大きな課題になる
チェックリスト
-
担当する仕事が本人や会社にとっても、社会にとっても、どれだけ重要でどんな意義を持っているかを全員にはっきり意識させる
-
チーム編成にあたっては単に技術力中心に考えるのでなく、メンバーのモラルにもできるだけ配慮する
-
プロジェクトメンバーが揃った時点で顧客のリーダーから、開発しようとしているシステムの目的やシステムの全貌、将来構想などを説明してもらう
-
プログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やす
-
プロジェクトメンバー全員を集め、各サブシステムの代表者が、自分たちが何をやって何に苦しんでいるのかを説明し合うプロジェクト説明会を開催する
-
担当させている作業が終わったら次に何をやるのかを早めに示しておく（次の仕事がないと思って、仕事をペースダウンさせてしまうメンバーが出てくるため）
-
あとからプロジェクトに入ってきたメンバーには、単に設計基準を手渡すだけでなく、どうしてそういう基準を作っているのかにまで言及した教育をする
-
大事な内容については別のルートからも確かめるなどのダブルチェックをする
-
大事な連絡や決定事項は文書化が必要
-
仕事の指示をするときは、やるべき仕事と、仕事の期限をはっきり設定することは当然として、何のためにその仕事をやる必要があるのか、仕事の目的を明示する
-
逆に上位者からおおまかな指示を受けた場合、自分と上位者の間には経験や問題意識の差があるのが普通であるから、自分の理解したイメージを自分の言葉で表現して上位者に質問する
-
良い報告はサボってもよいが、悪い報告はできるだけ早くする
-
マネジャーは嫌な報告でも喜んで聞いてやらなければならないし、なんらかの見返りも必要だ。適切なアドバイスが一番望ましいが、最低限激励だけでも良い
-
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違い
-
週報や月報は、プロジェクト終了後の反省会の資料にもなるので、大規模プロジェクトや難プロジェクトでは必ず書くようにする
-
部下やチームメンバーに週報、月報等の定期的報告を要求するなら、報告に対して、なんらかの返事やコメントを書くようにする
-
報告に必ず部下を同行する人がいるが、こういうことは極力やめたほうがよい（部下の貴重な時間が無駄であるし、自分一人でゆけば、自分のわかっていないところが明確になって勉強になる）
最後に
プロジェクトマネジメント、簡単な仕事ではありませんよね？プロジェクトでは不確実性、曖昧性が不可避であり、どうしてもドタバタっとしてしまう時が出てしまいます。そんな時は、自分ひとりの知識で戦うのではなく、「曖昧性とのたたかい」のような先駆者の残した知見を頼りに、立ち向かっていきたいものです。本書のなかには、テストや外注先との付き合い方などにも触れられていますので、興味のある人はぜひ手に取ってみてください。自分も経験が積み重なっていけば、現代のシステム開発に適した知見をまとめて本にしたいなとも思ったり。今日も一日がんばりましょう。
