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

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

前回はプロジェクトが膨張したときの対処として、予算追加やリリース日延伸も含めたプロジェクト全体計画の見直しが理にかなっているということを考察しました。

しかし、スタート時に設定された予算やリリース日が、「何が何でも守るべき」、いわば、プロジェクトの制約条件とみなされることで、全体計画の見直しタイミングが遅れ、かえって泥沼に陥ることが結構起きているのではないでしょうか。

今回は、システム開発プロジェクトの制約条件について考えます。

【　プロジェクト制約条件とプロジェクト目標　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
そもそもプロジェクト制約条件っていったい何でしょうか？制約条件というからには、何らかの理由によりプロジェクトが制約されるのでしょうから、やはり「何が何でも守る」必要があることなのでしょう。

また、プロジェクト計画時に設定した、予算（コスト）、リリース日（スケジュール）、スコープ、および、品質などのプロジェクト目標も、そのプロジェクトを実行するうえで、「何が何でも達成」すべきものと考えられます。

プロジェクトの制約条件もプロジェクト目標も、どちらも「何が何でも守る」対象であることは同じように思えます。でも、『制約条件』と『目標』というのは、やっぱり言葉を使い分けているだけあって、まったく同じものでは無いような気もします。

こういう時はPMBOKの定義を確認してみますか。（※１）

制約条件　プロジェクトまたはプロセスの実行に影響を及ぼす制限要素。プロジェクト・スコープ記述書に深く関係する制約条件は、プロジェクトの実行に影響するプロジェクト・スコープと関連づけられた、特定の内部的または外部的な制約や制限を列挙し記述する。例としては、顧客または母体組織によって発行された既定の予算、指定日、あるいはスケジュール・マイルストーンなどがある。合意に基づいてプロジェクトが実施される際の契約上の条項は、通常、制約条件となる。制約条件に関する情報は、プロジェクト・スコープ記述書またはそれとは別のログに記載される場合がある。

この定義を読むと、なんとなく、プロジェクト実行において守る必要のある事項の全てを制約条件と呼び、その中に予算やリリース日などのプロジェクト目標も含まれるということのように読み取れます。

しかし、たとえば「コストと品質はトレードオフの関係にある」と言われたり、「リリース日を厳守するためにスコープを削減する」という話も良く聞くので、プロジェクト目標の全てを「何が何でも守る」べき制約条件というのは、言い過ぎのように思われます。

どちらかというと、プロジェクト目標はあくまでも目標（達成を目指すもの）にすぎず、「プロジェクト目標のうちのいくつかが、プロジェクト制約条件（何が何でも守るもの）となっていることもある」というぐらいに整理するのがしっくりくると私は思います。

【　顧客または母体組織から指定される制約条件とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、PMBOKの定義によると、「顧客または母体組織によって発行された既定の予算、指定日、あるいはスケジュール・マイルストーンなど」がプロジェクトの制約条件になるとのことです。システム開発を委託された受注側の立場からすると、発注側から指定されたコストやスケジュールを制約条件としてとらえるのは確かに自然です。

発注側から提示されたＲＦＰ（提案依頼書）に予算やリリース日が指定されていた場合は、これを制約条件として固定的に考え、その中で実現できるスコープや進め方を提案することになります。しかし、ＲＦＰ（提案依頼書）に記載されたスコープをもとに見積りを行った結果、どうしても指定の予算やリリース日では実現が難しいという状況になった場合、どのような提案を出すことになるのでしょうか？ここが受注側としての提案戦略のポイントとなります。（※２）

＜見積りが指定された予算やリリース日に収まらない場合の提案戦略＞

案１　指定された予算やリリース日を優先して、スコープを削った形で提案する

案２　スコープを全て実現することを優先して、必要なコストとスケジュールを提示する

案３　指定された予算やリリース日で、スコープを全て実現する提案を行う（実現性は低い）

案２の提案は、実直ですが発注側には受け入れられないように思われます。

案３の提案をしてきたベンダーを選定した場合には、デスマーチ化が決定的です。

案１の提案を選んだ場合でも、システム化の目的を損なわずにスコープを削るための検討や調整に時間がかかるため、スケジュールがさらに圧迫されることになり、これもデスマーチ化するリスクは高いと思われます。

ということは、発注側がＲＦＰ（提案依頼書）を発行する段階で、実現性のある予算やリリース日を設定しておかないと、デスマーチ化のリスクが大きくなるということになります。ＲＦＰ（提案依頼書）がシステム企画段階のアウトプットであると考えると、やはり、システム企画段階での検討の深さが、後続のシステム開発プロジェクトの成否を大きく左右することは明白です。

【　数字はひとり歩きすると思え！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、顧客や母体組織の中で、どのようにして予算やスケジュールが決まったのでしょうか？顧客や母体組織から指定された予算やスケジュールは、「何が何でも守る」べきプロジェクト制約条件として扱われることになる重要なものです。いくつかの具体例をあげてみましょう。

＜スケジュール制約のもととなる条件の例＞
１．消費税率改定など法律の施行日
２．新システムを利用した新しいサービスの提供開始日
３．旧システムで利用しているハード、ソフトのサポート期限が切れる日

＜コスト制約のもととなる条件の例＞
４．新システムのリリースで予測される効果金額（費用対効果の損益分岐点）
５．当年度に利用可能なシステム開発予算残額

ここまでにあげた例では、具体的な期日や金額が明確で、それを守らなければならない根拠も明確であり、確かにプロジェクト制約条件の根拠になり得るでしょう。

しかし、実際のところ、プロジェクトの予算やリリース日が、それほど明確な根拠もなく設定されることも意外に多いのでは無いでしょうか？たとえば、次のような例もあるかもしれません。

＜それほど根拠も無く設定される条件の例＞

１．他社の類似システムの開発にかかったコスト、スケジュール
（システムの中身やプロジェクト経緯を気にせず最終結果だけ流用）

２．母体組織の中で声の大きなステークフォルダーによる鶴の一声
（切りの良い数字やそのステークフォルダーの誕生日など）

３．発注候補ベンダーの営業担当との雑談で聞き出したコスト、スケジュール
（ざっくりした前提条件つきで、開発部門との調整なしに口にした数字）

発注側としては、システム開発にかかる費用感やスケジュール感について、あまり土地勘があるわけでも無く、かといって、開発ベンダーの見積りを鵜呑みにするのも不安に感じるので、誰かがうっかり口にした予算とリリース日が心の片隅残ってしまうことがあるかもしれません。

そして、一度具体的な数字や期日として口にされた予算やリリース日は、巡り巡って、プロジェクトのキックオフを迎えるころには、「何が何でも守るべき」絶対的制約条件として受注側にインプットされ、デスマーチ化の根源になってしまうこともあり得ます。よく言われるように、「数字はひとり歩きする」のです。

したがって、特にベンダー側からコスト感やスケジュール感を安易に口にするのは、くれぐれも注意する必要があるのです。いくら前提条件をつけても、超概算だとか形容詞をつけたとしても、一度口に出した数字は、装飾物が全て取り払われた状態でひとり歩きしてしまうかもしれないことを肝に銘じるべきです！

「プロジェクト制約条件の根拠をしっかり確かめてから、プロジェクトをスタートしよう！」

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

工藤武久

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

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

※２　ＲＦＰ（提案依頼書）については、当ブログの以下の回参照。
【第２８回】ＲＦＰに隠された暗号を読み解け！