DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

プロジェクト計画書の最初のほうに「プロジェクト制約条件・前提条件」とか、「前提・制約事項」という目次がよく登場しますよね。プロジェクト制約条件と並び、プロジェクト前提条件も、プロジェクト計画を立てる上でしっかりと押さえておく必要があります。（※１）

たまに制約条件と前提条件があたかも同じもののように扱われることを見かけますが、本来はまったく違うものです。今回は、システム開発プロジェクトの前提条件について考えます。

【　プロジェクト前提条件とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
前回のブログで示したように、プロジェクト制約条件はプロジェクトの実行に影響を及ぼす制限要素であり、何が何でも守るべきものです。では、プロジェクト前提条件はどんなものでしょうか？

まずは、一般的に「前提条件」とか「前提」という言葉が、どんな風に使われるか見てみましょう。

たとえば、「結婚前提のお付き合い」なんて使われ方がありますよね。この表現をもう少し詳しくすると、「まだ結婚していないが、将来的に結婚すると仮定して、いろいろな面で、より深く、より密接に、より真剣に、・・・お付き合いする」という感じでしょうか？

「より深く」というのがどんなことを意味するのか、結婚前提のお付き合いをしている二人の間でも明確な合意があるわけではないと思いますが、たとえば、共同生活（つまり同棲）を始めたり、お互いの両親を紹介したり、お互いに資金を出し合ってマンションなどの高額な買い物をしたりするようになることでしょうか。

そして、結婚前提のお付き合いに発展した後に、もし、その前提がくずれてしまったら！
そのときのお二人の精神的、経済的、その他もろもろのダメージはかなり大きなものとなるはずです。。。
オペラ好きの私としては、日本を舞台にしたプッチーニの有名なオペラ『蝶々夫人』を思い浮かべます。男女関係のもつれを描いたアメリカ映画『危険な情事』の中でも『蝶々夫人』は重要な役割を担います。（※２）

結婚前提のお付き合いの前提条件がくずれたときと同じように、システム開発プロジェクトの前提条件がくずれた場合のダメージも大きいですよね。

たとえば、コーディング工程開始までに１００人のJava技術者を集める前提でスケジュールを組んでいたのに、３０人しか集まらなかったとしたら！
代わりにCOBOLの技術者を７０人集めて１ヶ月間Javaのトレーニングを受けてもらって戦力化するなんて、そりゃいくらなんでも厳しいでしょ！

ちなみにPMBOKの用語集には、前提条件は次のように定義されています。（※３）

前提条件(Assumptions).　 計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実であるとみなした要因。

前提条件とは、実は不確実であることを確実とみなしたものを指すのです。そう、プロジェクトにおける不確実なものといえばリスクです！
プロジェクト計画を立てる上では、不確実なものに一定の推定値や仮定を置きながら計画を組み立てていくことになります。その推定値や仮定と実際が異なる可能性は、すなわち、プロジェクト計画に内在するリスクということになります。（※４）

したがって、プロジェクト計画を立てる上で置いた前提条件をもれなく洗い出して一覧化したものは、プロジェクトに内在するリスクの一覧とみなすこともできるのです。（※５）

「前提条件をきっちり洗い出せば、プロジェクトに内在するリスクを特定しやすくなるぞ！」

【　プロジェクト前提条件の例　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、プロジェクト計画を立てる上での前提条件の具体例をいくつか見ていきましょう。

１． 構築するシステムの開発規模
まず初期見積り時に算出された開発規模を出発点にして、プロジェクト計画を考えますよね。そもそも、初期見積り段階の開発規模はそれほどあてにならないし、これから要件定義を始める段階だとしたら、その開発規模はまだ実証されているわけではありません。そこで、たとえば初期見積りの開発規模に対して、実際の開発規模の増減は３割以内におさまるだろうと仮定したうえで計画を立てるので、これは前提条件ということになります。（※６）

２． 設計、開発、テストの生産性
システムの開発規模に対して標準生産性をもとに必要な工数を算出します。しかし、個々のプロジェクトで使用する技術や仕様の難易度なども異なるため、標準生産性通りに設計、開発、テストが進むとは限らないはずです。個々のプロジェクトの独自性を考慮して適用する生産性を補正したとしても、これからスタートするプロジェクトの設計、開発、テストの生産性は実証されているわけではないので、これも前提条件となります。

３． 必要なリソースが必要な時期に準備できること
たとえば、先ほどの例にように、コーディング工程開始までに１００人のJava技術者が準備されることなども前提条件です。プロジェクト計画を立てた時点で１００人のJava技術者を既に確保済みなんてことはあまり無いことで、要件定義や外部設計を進めながら、あちこち駆けずり回って、どうにか頭数をそろえるというのが実情でしょう。優秀な技術者はコストも高くつく場合があるので、コストとスキルセットのバランスを見ながら要員調達を行うので、プロジェクトマネージャーの方々はたいへん苦労することが多いと思います。

こんな風にして、プロジェクト計画を立てるときには、さまざまな不確実なことに対して、それぞれに前提条件を置きながら計画を組み立てます。いつも前提条件が満足した状態でプロジェクトが進行するなら、そんなに楽なことは無いですよね。たいていのプロジェクトでは前提条件がその通りに行かないために、その代替え手段を都度考えながら、なんとか、しのいでいくという感じではないでしょうか？

前提条件を置いた不確実なこと、すなわち、プロジェクト・リスクに対して、顕在化しないように予防策を打ったり、顕在化した場合に発生時対策を実施したり、くずれた前提条件を補正して、プロジェクト計画を見直しながらプロジェクトを推進していく。。。

まさに、これが現実のプロジェクトマネジメントの姿だと言えると思います。

【　ありえない前提条件　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
プロジェクト計画を立てる上で、まるで実現性が無いことを前提条件として置いていることは無いでしょうか？

前回ご紹介したような、スケジュールやコストについての絶対的な制約条件の中で、要求されたスコープの実現が厳しい場合などは、実現性のあるプロジェクト計画を立てることはとても困難です。そんなとき、苦しまぎれにありえない前提条件を置いて、無理やりスケジュールやコストの制約条件に収まるようなプロジェクト計画を作ってしまう危険があります。

たとえば、こんな前提条件など。。。

＜ありえない前提条件の例＞
１．新しい開発アプローチを採用することで、生産性は標準の３倍になる。
２．プロジェクト期間中、一切の仕様変更は発生しない。
３．全ての成果物は、初回のレビューで承認される。
４．プロジェクトメンバー全員のプロジェト期間中の稼働率は１００％以上。
５．ユーザーからの要求事項は、要件定義工程開始前に全て明確となっている。
６．いつでも必要なときに、最低限の追加コストで優秀な技術者を追加できる。
７．優秀な技術者を集めるので、単体テストを省略しても品質は確保される。
８．いざとなれば、簡単に開発スコープの削減ができる。
９．いざとなれば、プロジェクトメンバー全員が、連日の徹夜作業に応じてくれる。
１０．いざとなれば、誰かがスケジュール、コスト制約を調整してくれるはず。

もし、これらの前提条件がプロジェクト計画書に書かれていたとすれば、前提条件が間違っていたことが失敗の原因だったと、反省につなげることができるかもしれません。しかし、得てして「ありえない前提条件」は、ありえないことが分かっているだけに、文書化を避けられることになり、失敗の原因を把握できず、組織全体としてのプロジェクト成功確率を向上させることができない要因となることでしょう。くわばら、くわばら。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　当ブログの　【第１８回】計画が先か？リスクが先か？　でご紹介したプロジェクト計画書の目次サンプルでは、「１．プロジェクト目的・範囲」の次に「２．プロジェクト制約事項・前提事項」が登場します。

※２　・「蝶々夫人」『フリー百科事典　ウィキペディア日本語版』
2014年10月17日 (金) 14:32 utc http://ja.wikipedia.org/wiki/蝶々夫人
・「危険な情事」『フリー百科事典　ウィキペディア日本語版』
2013年5月14日 (火) 02:03 utc　http://ja.wikipedia.org/wiki/危険な情事

※３　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※４　プロジェクト・リスクに関しては、当ブログの以下の回も参照してください。
・【第１２回】プロジェクト・リスクとは何か？
・【第１３回】個別リスクとプロジェクト全体リスクという二つの視点

※５　前提条件からリスクを特定する技法もあります。出典は※３。

前提条件分析(Assumptions Analysis).　前提条件の正確さを調べるとともに、前提条件の不正確さ、不整合さ、不完全さによってプロジェクトにもたらされるリスクを特定する技法。

※６　プロジェクトの初期見積りに関しては、当ブログの以下の回も参照してください。
・【第２４回】プロジェクト初期見積りの不確かさ
・【第２５回】プロジェクト初期見積り考古学