「バッファ込み」の工数がスケジュール遅延の原因：システム開発プロジェクトの現場から（15）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

　こんにちは。アクセンチュア・テクノロジー・ソリューションズ（ATS）の新楽です。

　最初に立てたスケジュールどおりにプロジェクトが進行せず、だんだんと遅れていく……。そんな経験はありませんか？

　今回は、すでに稼働しているシステムへの機能（サブシステム）追加開発プロジェクトでの経験を基に、プロジェクトのスケジュール管理の難しさについてお話しします。

初めてのプロジェクト憲章

　このプロジェクトの規模は約100人／月で、与えられた期間は約6カ月。正直、スケジュールはタイトでした。もっとも新規開発ではなく、すでに稼働しているシステムの追加開発ですので、アーキテクチャもアプリケーションも本番環境で稼働していました。まったくの新規開発プロジェクトと比較すると、スケジュールにインパクトを与えるような不確定要素は圧倒的に少ないはずでした。

　体制は、アクセンチュア側（ATS含む）が4人と、協力会社のメンバーが最大で15人。主に要件定義から設計までをアクセンチュアが実施し、開発以降を協力会社のメンバーが行うという形でした。

　プロジェクトの立ち上げに際して、私は必要なタスクの洗い出し、各メンバーの役割の決定および周知、全体のスケジュールと各マイルストーンの設定を行いました。そして、初めてプロジェクト（チーム）憲章というものを作成しました。

　ご存じの方も多いかもしれませんが、プロジェクト憲章とは、プロジェクトの目的、各メンバーの役割や行動指針などをまとめたものです。

　今回この憲章を作成した理由は、大きく以下の2点です。

1. 短期開発ということもあり、常に全員が同じ方向を向き、ゴールやマイルストーンを見失わないようにしたかった
2. 追加開発で既知の事項が多いことによる油断、チャレンジ要素がないように思えることによるモチベーションの低下・マンネリ化が懸念されたため、このプロジェクトに参加することでどのようなスキルを身に付けられるのか、挑戦的な要素がどこにあるのかを明確にしておきたかった

　最初にプロジェクト憲章を作成すると、プロジェクトのミッションや各メンバーの役割を1つの文書としてまとめることができるので、非常に有用だとあらためて思いました。プロジェクトやチームの立ち上げの際には作成してみることをお勧めします（ちなみにプロジェクト憲章はアクセンチュアの開発方法論の中で成果物として定義され、CMMIでも必須とされています）。

　こうしてプロジェクトは比較的順調な立ち上がりを見せました。個人的にはこの憲章を作ったからだ……と思いたいところです。

お客さまと仕様詰めの打ち合わせができない？

　が、スタート早々、プロジェクトを進めるうえで困難となり得る重大な制約が出現しました。お客さまが非常に多忙な方で、打ち合わせの時間を集中的に取ることが難しいというのです。

　開発対象の機能は、それなりの本数ありました。期間も短いため、可能な限り早く要件を確定させる必要がありました。しかし、要件定義や基本設計（いわゆる外部設計）は自分たちだけで完了させることはできません。工数はある程度コントロールすることができますが、お客さまとの打ち合わせ時間が取れないのでは、リードタイムを短縮することができません……。『人月の神話』（フレデリック・P・ブルックスJr著、ピアソンエデュケーション）で読んだ、「人と月は交換できない」ということをあらためて痛感した瞬間でした。

　そこで、苦肉の策（？）として、機能・優先順位・規模を考慮し、案件を大きく5つに分類しました。お客さまとのミーティングの日程は、事前に調整可能な範囲で決めてしまいました。そして、そのミーティングの日程に合わせて各分類の要件確定〜設計・仕様凍結までのスケジュールを立てることにしました（当初の基本計画は変更せずに）。開発以降のスケジュールも、すべてお客さまとのミーティングの日程に合わせました。

　お客さまとのミーティングで全体の期間を決めるということは、ミーティングでの決定が遅れると、その分スケジュールが遅延するということです。ですから、事前準備や確認すべきポイントの抽出は入念に行い、1回1回のミーティングを無駄なく漏れなく実施することに注力しました。

　ボトルネックを徹底的に有効活用し、すべての工程をボトルネックに従属させる……。これは、もしかするとTOCを実践しているということでしょうか。

　この思い切った手のおかげで、プロジェクトは開発・単体テストくらいまではさほど問題なく進んでいきました。しかし、最初の分類の結合テストを開始したころから、徐々に遅れが出始めました。遅延理由の代表的なものは、「イレギュラーケースに対応できていなかった」「想定する必要がないケースのテストを実施していた」などです。