プロジェクトマネージャーとしての炎上しない開発進行方法（前編）

皆さん、システム開発の進行って本当に難しいですよね。教科書に載っていることはしていても炎上するときはします。ではなぜ炎上するのか、炎上しないためにどのような心がけが必要なのかを記事にしてみたいと思います。

旭川医科大学とNTT東日本

まず下記記事はご存知でしょうか。

https://atmarkit.itmedia.co.jp/ait/articles/1710/23/news018.html

要約をすると下記の通りです。

1. 旭川医科大学のシステム開発をNTT東日本が請負契約にて受託
2. プロジェクト開始後、現場の医師から相次ぐ追加要望により、仕様凍結後のにもかかわらず、さらなる要望が続いた。
3.  新システムが予定納期までに納品されなかったため、旭川医科大学が契約を解除。
4. 旭川医科大学がNTT東日本に対し損害賠償を請求。
5. 札幌高裁は、旭川医科大学側の追加要望が原因で開発が遅延し、契約違反にあたると判断し、旭川医科大学に対し約14億円の支払いを命じる逆転判決を下しました。 

結果はNTT東日本側が勝ちましたが、いやはや恐ろしいですよね。

実は、このようなことがモチヤでも過去に起こったことがありました。

今後このようなことが起きないように、我々システム開発会社、プロジェクトマネージャーはどうしたら良いか、私見を元に話したいと思います。

案件炎上の理由考察

まず、旭川医大とNTT東日本の件に目を向けてみまと、下記の点で意識の疎通ができていなかったと予想しています。（あくまでも予想ですよ）

旭川医大：

数億円かけて開発するため、見積もり時には記載されていない要件を意見するも、要件が増えることにより請負金額が増えること、納期が延びることを理解していない。

NTT東日本：

要件が増えることにより、請負金額が増え、納期が延びると考えている。旭川医大側も請負金額が増え、納期が延びると思っている。

この意識の齟齬が、案件を炎上させたと予想をしています。

実はこれ、あるあるなんですよね。旭川医大側もシステム開発のプロではないので、要件が増えることにより請負金額が増え、納期が延びることは分かっていない。これをプロジェクトマネージャーが理解させる必要があります。

では、どのように案件を進行したら良かったのでしょうか。

案件が炎上しないために

案件が炎上する理由は概ね下記と考えています。

• 納期が（年単位で）延びる
• システムが破綻する（設計したアーキテクチャが破綻し、想定のレスポンスが出ないなど）

システム破綻についてはまたの機会に考えるものとし、今回は納期が延びる件について考えてみたいと思います。

モチヤで請け負わせていただくシステム開発は大体1,000万円 ～ 数億円規模の案件です。例えば5,000万円の案件を1年のスケジュールで開発を請け負ったとします。見積もり時の想定工数より、20%作業が上振れただけで、1,000万円の損失と、2か月半プロジェクトが遅延します。

当たり前ですが、見積もり時の想定工数より2倍の工数がかかれば、5,000万円の損失と、1年間プロジェクトが遅延します。

追加予算と納期（想定の2倍工数がかかる場合）

作業工数が当初（見積もり時）の想定よりも2倍かかりそうだ！と分かるのは案件の、中盤から後半に分かってきます（恐ろしいですね笑）

この時に、受託側のPMは、委託側のPMに、申し訳ないですが当初の想定よりも2倍工数がかかりそうで、納期も1年後ろ倒しになりそうですと伝えます。

そうすると委託側のPMは、だったらエンジニアの人数を2倍（お金は払う）にして納期を守って欲しいと言ってきます。

補足：お金は払うと簡単に書きましたが、委託側が相当な譲歩をしていただき、増額を決定いただいています。

ただ、エンジニアの人数を2倍にしたら、開発速度が2倍になるのでしょうか。
答えはNoです。

案件の遅延は、中盤から後半に分かります。中盤から後半にエンジニアが入ってきても、即戦力になりません。まずは全体の仕様把握、アーキテクチャ把握、他のエンジニアが記述したコードの理解からスタートします。理解をさせるためには、初期からいたエンジニアの力を借りる必要があります。

1か月～2か月かけて、途中から参加したエンジニアがコードを書けるようになってきたとしても、コード量が2倍になるため、コードレビューの確認者及び、単体のテストを実施するディレクターや、テスターの手も足りなくなります。

委託者（お客様）はエンジニアの人数を2倍にしたら、開発速度も2倍になることを期待しますが、実際にはそう簡単ではありません。

この事実を委託者に伝えてもなかなか理解いただけません。では、どうしたらこの事態を防げるのでしょうか。

案件受注前の見積もり

当たり前だろと思う方も多いと思いますが、精度の高い見積もりを初期の段階で行うことができれば案件は炎上しません。

ただ、案件受注前の見積もり段階で制度の高い見積もりを出すことは出来ません。お客様が作成をしたRFPだけでは見えない要件が、多く隠れているからです。規模が大きくなればなるほど、見えない要件は多数出てきます。

そのため、モチヤでは下記のことを行っています。

初期見積もり時：

お客様が作成をしたRFPを元に、実際エンジニアがコード開発を行う予想工数を算出します。そのコード開発の予想工数に対して、ドキュメント作成や、マニュアル、定例会、テストなどの工数を、これまでの開発を行ってきた実績を元に割合で算出します。（割合比率はこれまでの開発を元に平均を求めています）

（例）

• コード開発：1000時間（RFPより算出）
• ディレクション業務（要件定義、内部定例、課題管理、スケジュール調整など、コード開発の30%）：300時間
• ドキュメント作成（仕様書などの作成、コード開発の20%）：200時間
• マニュアル作成（操作マニュアル、コード開発の5%）：50時間
• 検証（単体テスト、総合テスト、コード開発の30%）：300時間

エンジニア作業工数：1000時間
管理工数：850時間

（実際お客様に見積もり根拠を提出する資料例）

エンジニア2名で作業を行うと、500時間/人となり、単純計算で3ヶ月と少しで開発が完了します。（実際には内部定例の参加などあるため、提案時には4か月程度で記載する）

コード開発の前後にキックオフや、要件定義、検証が入るため、約6か月程度の開発期間として提案を行うと思います。

この時に重要になるのが、お客様が作成をしたRFPを元に想定工数を計算しているということです。
もちろん要件が2倍になれば、価格も納期も2倍になります。

初期見積もり段階では、予想工数を元に見積もりをしています。実際に要件定義をしていないため、本当にこの金額と納期で納品できるか分かりません。

そのため委託者（お客様）には、下記のように伝えます。

全ての開発（要件定義、開発、検証、納品まで）は、準委任契約での受託でも良いか確認

OKの場合は、要件が増えればその分金額も増え、納期も増えることを説明する。

難しい場合

最初の数か月（開発規模による）、要件定義を準委任契約で実施し、要件定義が終わった段階で請け負い契約にて開発を進めて良いかを確認。

準委任契約と、請け負い契約のハイブリッド契約を実施します。

要件定義後に、再度開発の見積もりをしますので、それ以降の要件追加は別途見積もりとさせていただきますことを説明する。

このどちらかの対応を行うことで、契約上の炎上は防げると考えています。

案件スタート後の注意点

上記までで、契約上の炎上は防げると書きましたが、案件スタート後にも、まだまだ気にしなくてはいけないポイントがいくつかあります。

記事も長くなってきましたので、案件スタート後の注意点については「プロジェクトマネージャーとしてのプロジェクト進行方法（後編）」で説明させていただきます。