【システム開発プロジェクト炎上診断】　～　②計画編

なぜシステム開発プロジェクトは炎上するのか？
第二回は、杜撰な計画です。
プロジェクト開始前あるいは開始直後に決める計画が杜撰だと、遅延が何かもわからないまま、気が付いた時には取返しが難しい状態になります。
「そもそも計画に無理があった」と苦労したプロジェクトの反省会で必ず上がる理由でもある計画は、炎上の大きな要因です。
プロジェクトの最も代表的な管理項目に進捗管理がありますが、進捗管理を進み具合と捉えることは正しくありません。管理すべきは、単なる進みではなくて、計画に対する進みです。つまり計画が正しい前提で、管理することに意味があるのです。逆に言うと計画が間違っていたら、いくら厳格にしっかり進捗管理をしたところで成功はありません。
今回は、システム開発プロジェクトが炎上する大きな要因となる計画について、解説していきます。

１．プロジェクト計画書は形骸化

システム開発プロジェクトの開始前には、必ずプロジェクト計画書を作ります。
プロジェクトの一次請けとなる開発ベンダーは、毎回一から計画書を作ることの効率の悪さを嫌って雛形と記入要綱を用意していますが、誰でも漏れなく短時間で作れることの狙いとは裏腹に、十分に考えられずに計画書が作成されてしまう状況を生み出しています。
役割が不明確な汎用的な体制図、工程を並べただけのざっくりスケジュール、使いまわしの管理プロセスなど過去のコピーが横行しているのが実態で、もはや計画書は形骸化してしまっていることが多いです。酷い場合には、過去に誰かが作成したプロジェクト計画書をほぼそのまま使って、今回のプロジェクトで変わる部分だけを何も考えずに書き換えて作成していることすらあります。
作るシステムによって必要な工程も違えば、体制によって品質管理プロセスも変わるし、クライアントの役割によってレビューや検討リードタイムも変わり、本来それらは計画書に反映されなければなりません。
効率性を重視して過去の計画書を使いまわして計画を策定することはとても危険です。計画書が鏡となってプロジェクトを管理をしていくため、計画が出鱈目であれば管理も意味を成しません。

２．計画の中で一番重要なのはスケジュール

システム開発のプロジェクト計画書に記載するコンテンツは、主に下記ですが、この中で一番重要なのは何でしょうか。
　・プロジェクトの目的とゴール
　・スコープ
　・スケジュール
　・推進体制
　・管理プロセス
　・会議体
　・リスクと対策
　・直近の進め方
　・役割分担
どれも重要ですが、この中で最も大切なのはスケジュールです。
スケジュールは、作業内容、開発体制、クライアントの役割と作業リードタイム、品質管理プロセス、承認の会議体などを全て盛り込んで作り上げるものであり、納期を定めることや各工程のマイルストンを置くだけでは意味がありません。
てんこ盛りで作成した結果、納期に収まらないことはあります。その場合は、納期に収めるための工夫が必要で、その工夫は提案時点では差別化のポイントとなりつつも、多少無理をしていることにもなるためリスクでもあります。計画書にリスクとして記載するかは状況によりますが、少なくともプロジェクトマネージャーと開発マネジメントは、何をどう無理したかをリスクとして認識しておくことは重要です。
このように、計画書の各コンテンツは、スケジュールに盛り込まれるか、スケジュールを作成した結果として書かれるものであるため、スケジュールは計画書ひいてはプロジェクトのコアなのです。

３．WBSはシミュレーション

スケジュールの中でも最も詳細に具体的に作るのがWBSです。
WBSはシステム開発におけるシミュレーションです。スポーツでいえば試合前のイメトレ、受験でいえば模擬試験、このような本番を想定したシミュレーションは準備の中でも特に重要です。こういう場合にどうするか、こういう指示を出したらどんな結果が返ってくるか、こんな成果物を提示したらどんなフィードバックがあるか、想像の1000本ノックを行いながら作るのがWBSです。
何も考えずに汎用的なタスクを並べただけのWBSはまったく使い物になりません。
想像したから、想定があるから、想像と違った局面に出くわした時に想定外と認識でき、計画の軌道修正ができるのです。
この想定と想定外の積み重ねが知識となって能力を高め、この先、緻密で考え抜かれたプロジェクト計画やWBSを作成できるようになるのです。
想定がなければ想定外にも気が付けませんし、計画策定能力も上がりません。

４．危険度がわかるスケジュールのポイント４つ

スケジュールを確認すれば、プロジェクトの危険度はわかります。確認するポイントは4つあります。

① スケジュールの種類
別記事【WBSがあるのに遅延する．．．なぜか？】にも記載している通り、スケジュールには最低でも3種類必要です。WBSは直近の工程分だけでも良いですが、用途に応じて3種類のスケジュールがあるかが重要です。その上で、各スケジュールの関連付けが出来ていることが大切です。

② 調査タスクと検討リードタイム
スケジュールを作成しようと思っても、調査してみないとどれくらいの期間が必要で、その後にどんな作業が発生するか分からないことはあります。調査結果によって変わるということはスケジュールリスクとなるため、調査タスクと後続タスクには、リスクありとか調査結果によって変動などと明確に記載してスケジュールに入れておくことが大切です。
調査タスクがなければ、全て想定できているタスクということになります。

また、要件定義や基本設計では、クライアントの検討作業が発生します。期限を設けなければスケジュールは引けませんし、納期を守ることもできません。この検討リードタイムがスケジュール上に確保してあることが重要です。考慮されていなければ工数的には大丈夫でも期間的に破綻してしまいます。

③ スコーピング
要件や仕様を決めた後で見積りをしたら予算を超過してしまったということはよくあります。予算を前提に考える場合、いったん見積りを見てから要件や仕様の絞り込みを行いたいとクライアントは言うため、要件定義や基本設計が大方終わった後に見積り作業が入り、その後に絞り込みを行います。
スコーピングと言われるこの絞り込む作業は、ユーザーとの攻防戦を強いられる可能性が高く、また、いくつものオプションを考える必要もあり、最終的な合意形成までにそれなりの期間を要します。このスコーピングの期間がスケジュールに設定されていないと、次工程への着手が遅れるか、不確定な状況でなだれ込むため手戻りが発生する可能性が高いです。

④ 依存関係
設計が終わってから開発に入る、開発後にテストを行うことは当たり前です。例えば、IFプログラムの開発後に、それを流用してデータ移行プログラムを作成する、総合テストの環境構築を移行プログラムと移行手順を使って行うなど領域間の依存関係が定義されていることが重要です。
またクリティカルパスは、最も細かいWBS上に定義するべきで、その上で概要スケジュールのどのタスクがクリティカルパスか明示することが大切です。

⑤要件定義の成果物
最も想定することが難しく、また納期に合わせて成果物を調整しやすい工程が要件定義です。そのため要件定義は、甘くなりやすく、後続工程へのしわ寄せが起こりやすいです。
要件定義の成果物は、その後の工程を占う意味でもとても大切ですが、要件定義で何を決めるのか？という問いにスパっと答えられる人はあまりいません。「要件です」「成果物は要件定義書です」と答える人は危険です。
厳密には、要件定義には業務要件定義とシステム化要件定義の2つがあり、どちらも最低限必要なのは要件一覧です。加えて、業務要件定義では業務フロー、システム化要件定義ではシステム機能一覧が必ず必要です。
この成果物が要件定義タスクに定義されていなければ、危険と思って間違いありません。

５．WBSで管理するのは進捗だけ

進捗管理では、見積に基づく計画と実態との乖離を把握することが重要です。計画以上に実績工数が発生すれば、それは見積工数内では収まらないということになり、このまま進むとどれくらいコスト超過するかの見通しを立てることが必要となります。
WBSを元にした進捗管理には、コスト管理の諸元となる情報も含まれますが、WBSで見積工数と実績工数を管理しようとすると管理が複雑になり大変です。コスト管理は、日報やリソースプランで行うなどスケジュールとは切り離して管理する方が良いです。
WBSに多くの管理要素を盛り込んだ結果、管理不能に陥っているプロジェクトがよくあります。

■炎上診断チェックリスト（②計画）

②－1．スケジュール種類
・4種類のスケジュールが用意されているか（1年未満の場合は3種類）
・各スケジュールが関係付けされているか
・WBSに進捗以外の管理要素(コストなど)が盛り込まれていないか
②－2．調査・検討・調整タスク
・ユーザーが検討するリードタイムは設定されているか
・調査しないと明確にならない場合の調査タスクが設定されているか
・調査結果によってその後のタスクが変動するリスクについてクライアントと合意できているか
②－3．スコーピング
・スコーピングの役割がクライアントと握れているか
・要件定義、基本設計の最後にスコーピングの期間が設定されているか
②－4．依存関係とクリティカルパス
・概要スケジュールでタスクの依存関係が設定されているか
・概要スケジュールでクリティカルパスが明記されているか
②－5．上流工程の合意事項
・業務要件定義の成果物に業務フローが定義されたタスクがあるか
・システム化要件定義の成果物にシステム機能一覧が定義されたタスクがあるか
・要件定義の成果物についてユーザーと工程着手前に握っているか、工程後に承認・合意しているか