「ゴール」が曖昧

プロジェクトマネジメントに限った話ではなく、ビジネスすべてに対して言えることなんですけど、ここではあえてプロジェクトマネジメントに焦点をあてておきたいと思います。

で。
プロジェクトマネジメントが原因で失敗してしまう理由の代名詞ですね。

　「どんな方向性で進めていきたいのか」
　「何のために行うのか」
　「何が実現されれば良いのか」

そして

　「何を以って、完了（成功）となるのか」

が曖昧なままにプロジェクトが進められるパターンです。プロジェクト活動の元となる注文や契約ではゴールがしっかりと定められているはずなのに、プロジェクトの中ではそれが共有されない…そんな現場は多いと思います。

まぁ、経営戦略でもまったく同じことが言えるので、「マネジメント（管理、経営、運営、etc.…）」の領域の問題なのでしょう。

この「ゴール」とはそれ自体が多少曖昧に定義されていても、成功するプロジェクトはあると思います。ですが、それでも失敗確率は格段に跳ね上がります。それはなぜか？

チーム内で「ベクトル（要する力の量と向き）」が定まらないからです。

　・ゴールの方向がわからない
　・ゴールまでどんなペース配分にすればいいかわからない
　・ゴールにたどり着く重みがわからない

マネージャーだけがよくわかってないのはまだ何とかなります。お客さまが既存顧客で、お互い長い付き合いになっていれば、メンバーの方が詳しかったりもしますから。

ですが、マネージャーがベクトルを指し示さず、ベクトルを理解していない状態となっていると、当然ながらメンバーも理解ができないのが普通です。もしも、新規顧客だったり、メンバーの大半がまだお客さまの特性を理解していなかったりした場合に、ベクトルが定まらずにスタートすると

　・ゴールとは真逆の方向に進み始めるメンバーが出る
　・メンバーごとに自由なペース配分となって、足並みがそろわない
　・ゴールにたどり着くと言う強い意志が共有できない

と言った事態が引き起こされます。少なくともメンバーのまじめさや責任感の違いによって、一人ひとりが不安を覚え、バラバラな足並みになり、混乱と焦燥だけが募っていくプロジェクトになっているかと思います。

それでも、後半で「大量の（サービス）残業」「罵声と怒号」「バラバラの品質」などを我慢すれば、なんとか納期内に、なんとか予算内に収めることはできるかもしれません。ですが、それはプロジェクトの成功とは呼ばないのです。

直接的な影響が見えにくい問題ですが、この「ゴール」の有無は間違いなくプロジェクト負担の増減に直結します。

プロジェクトの「ゴール」とは、一般的には

　目標

と言われています。PMBOKなどでは「目標」のほかに、「目的」「方針」なんて言葉が出てきますね。

　目標とは、「最後にどのような状態になっているのか」
　目的とは、「なぜ、そうする必要があるのか」
　方針とは、「どういったルールや想い、目指す方向で進めたいのか」

だと思ってください。特に「方針」と「目標」は多くの人が混同しがちですが時系列にすると

　①方針（方向性）が定まり
　②目的を明確にし
　③方針と目的に沿った、目標を立てる

という流れになるものですので、①と③は明確に異なります。①に従って③を明らかにするのです。うーん…①が大分類（大雑把なもの）、③が中分類（やや詳細化したもの）と思えばいいでしょうか。

ちなみに、この③をさらに詳細化（具体化）して、実行できる形に落とし込んだものこそ『計画（小分類）』になります。

　方針に従って、実現可能な目標を立て（ゴールを決め）、
　目標に到達するために、具体的な計画を立案する

これがプロジェクトマネジメントにおいて、まず取り掛かるべき絶対条件です。『戦略』と言ってもいいでしょう。

仕様の変化に対応する方法

そもそも、規模が大きくなればなるほどプロジェクト序盤で「仕様」や「要件」が定まっていないのが、ＩＴプロジェクトの常であるにもかかわらず、「ゴールが曖昧」なことがプロジェクトの失敗要因の最たるものとされると、

　「じゃあ、仕様や要件の曖昧な案件は請けなければいいのか？」
　「それで会社の経営が成立すると思ってるのか？」

と言う揚げ足取りが聞こえてきそうですが、ご安心ください。その程度のツッコミで揺らぐほど希薄な根拠でいっているわけではありません。

ではどうすればいいのか？
答えは簡単です。

　それでも、上手くコントロールできる進め方を提示する

だけです。考え方の基本はウォーターフォールであってもアジャイルであっても変わりません。アジャイル型の開発モデルでも、仕様の変更規模が大きければ、進め方を根底から見直さなければならなくなるのは一緒です。

そんなときは、たとえばこんな感じで提案してみてはどうでしょう。

　「大きく３つのご提案があるのですが、
　　１つは、要件や仕様が明確になっているところだけを
　　まずはゴールとして契約対象とする方法です。
　　この場合であれば、仕様や要件が定まり次第、別発注と言う形で
　　ご検討させていただきます。

　　（メリットとデメリットを説明する）

　　一方で、リソース的あるいは時間制約的な調整が困難な場合は、
　　一度納めた後に段階提供で対応させていただくことも可能です。

　　（メリットとデメリットを説明する）

　　もちろん、将来的な拡張を考慮して設計しておきますので、
　　必要以上のオーバーヘッドを要しない仕組みを取らせていただき
　　かかるコストを最低限に抑えるよう進めさせていただきます。

　　最後に、３つめとして要件定義工程を厚くすることで、
　　先に全体像を決定する方法です。
　　これなら仕様が大きくブレない限り、
　　御社の予算計画が大きくずれることもありません。
　　ただし、要件定義工程完了時点で当初計画値と
　　大幅に乖離している可能性もありますので、
　　SES(準委任)契約と請負契約の組合せとさせていただくことになります。

　　具体的には、要件の大半が定まり、
　　予算化の目途がつく要件定義工程を「SES契約」で。
　　要件定義完了時にあわせて再見積もりを行いますので、
　　その内容を精査していただき、改めて「請負契約」でご発注いただく
　　…というものです。

　　（メリットとデメリットを説明する）

　　もちろん、そこで相みつを取っていただいても構いません。
　　予算取りに少々手間がかかってしまいますが、ＩＴ投資と言う面では、
　　御社にとって最もリスクの低い方法になるかと思います。
　　いかがでしょうか。」

と、私ならば言います。これ以外の選択肢は、リスクが増すだけなので覚悟がない人にはおススメできません。

そのうえで、プロジェクトのゴールをどこに定めるのかを明確にしていきます。

上の３つのアプローチを見ても、注文の単位…つまりは契約の分け方や、その先への継続の仕方を考慮に入れると、一つひとつの契約単位で閉じるプロジェクトのゴールがどうあるべきかが変わってくることがわかると思います。

①注文１と注文２を並行で進める

この場合、それぞれのクリティカルパスを明確にして、注文１のスケジュールに注文２が間に合うように調整したうえで、注文１の要件も注文２の要件もすべて満たしている必要があるプロジェクト形式です。

注文２のプロジェクトメンバーは途中から参画するため、注文１の経緯や背景を知らない場合が多く、情報齟齬が起きやすいと言うリスクがあります。

また、注文１を全体のベースラインとするため、注文１のスケジュールに悪影響を与えるような進行は認められません。結果、注文２側は短納期プロジェクトとなるため、ちょっとした手戻りが全体に波及する可能性も高く、ある意味で、最もリスクの高いプロジェクトとも言えます。

けれども、お客さまにとってカットオーバー（システム稼働日）が絶対厳守となっている場合（たとえば…公に告知してしまっているとか、ハードやミドルの保守サポートが切れてしまう等）、この手法を取らざる得ないこともあり、ただ

　納品すればいい
　バグが無ければいい

と言う話では収まらないことが往々にして起きかねません。他の方法と比較しても、より強く求められるものとして

　スケジュールの遵守
　カットオーバー直後の混乱防止

などもプロジェクトとして憂慮しておかなければならない重要なゴールになります。

②注文１から切り離して、注文２を直列に結ぶ場合

起きやすいのは、

　法改正の適用などで、対応期日が明確になっているが、
　ギリギリになってから仕様の変更が発生してしまった

と言ったケースです。対策するにしても、現実的にスケジュールに詰め込むのが困難な場合、よほどクリティカルな機能でもない限り、現プロジェクト（フェーズ１）が完了し、法改正適用期日を遵守したうえで、改造プロジェクト（フェーズ２などと言って）を別途立ち上げるわけです。

ひょっとすると、この形式がエンジニアにとって一番楽かもしれませんが、プロジェクトリスクはそれなりにあります。

１つは、注文１で実装するべきだった機能や処理を一旦切り出してしまっている関係上、注文１の予算が減額される可能性です。途中まで進めていた分などの実績コストなどもあるため、普段からコストの進捗が管理できていないと、「何を」「どれだけ」減額するのかで揉めることがあります。

もう１つは、切り出した機能がないまま注文１の分を納品したところで、本当に業務上必要な機能が揃っているのか？と言う点です。必須機能が実装されていなければ、お客さまは結局「注文２」が納品されるまで、利用できずに待たされることになります。が、これは請負契約としては原則ＮＧです。

お客さまが求めるゴールとしては、

　注文１のスケジュールは厳守であること
　注文１の分だけでも、業務が限定的とはいえ遂行できること
　注文２の分を追加した際に、それまでの業務に影響が出ないこと

が求められることになるでしょう。

③SES契約と請負契約を複合させる

お客さまの会社内で予算編成上、大きく予算を確保されている場合、たまに①や②を選択するお客さまもいますが、きちんとメリット／デメリットを説明した場合、③を選択されるお客さまが多いのではないでしょうか。

たとえば、

　「全体で５億の予算を確保したけど、１億分しか仕様が決まっていない。
　　でも、最終的には５億の範疇でおさまる範囲で、すべてを実装したい」

と言うようなケースです。その場合、まずは１億で契約し、あとは並行で仕様検討を行いながらスケジュール調整して、別契約で追加予算の中から発注してもらう…と言うようなケースにしたり、あえて１年以内に押し込めようとせず、年度ごとに優先度の高いニーズを聞きながら、数年、数契約で完成させていくような方法をとることもあります。

この契約形式では、年度内に完了する計画に対して年度を跨ぐと予算編成のし直しになってしまうため、色々と仕様が増え、１年以内に収まらない…と言ったケースは嫌がられますが、元々大きな規模のシステム開発であれば数年単位の中長期計画になっていることも多いため、この辺りで支障となることはあまりありません。

まぁ、そもそもお客さまの担当窓口と言っても、せいぜい相手も課長か部長クラスの方です。「これ以上予算がない」と言っても、それは課や部の予算であって、会社の予算ではありません。本当の本当に必要な経費であれば、稟議によって捻出すればいいのです。

しかし、一般的に"予算稟議"と言うのは忌避すべきものです。

予算計画は年度の初めに立てるもので、それを大幅に変更して稟議するということは、そもそも「計画性のない人」と言うレッテルを社内で貼られてしまい、出世等に響く可能性があるからです。役職があがればあがるほど、計画精度が向上しなければなりません。

ですから、お客さまの課長や部長も、自分の人生（社内評価）がかかっているため、そうやすやすと「稟議すればいいや」とは思ってくれません。けれども、先ほど『説明責任』と言ったように、ちゃんと必要経費として説明し、お客さまにとって「なるほど、確かにそれは必要だな」と説得できるだけの根拠があれば、役員など上層部にも説明しやすくなるため、決して頑なになることもありません。

ただし、こうした"お金"にまつわる交渉を行う時は、常に背後にいる"決裁権"を持つ人を視野に入れて交渉しましょう。説得するのは目の前の担当者ではなく、その背後にいる決裁者です。

端的に言えば

　お客さまの決裁者を説得できる根拠と、
　まともに納得できる文章を用意してあげれば、
　担当者は頑なにならず、早々に上に掛け合ってくれる

ということです。

様々なプロジェクトゴールがあることを理解する

他の形式で進めるとしても、それぞれプロジェクトゴールには「納品」「不良０件」などの他にもかならず何かしら要求されているものがあります。それらを明確にせず、プロジェクト終了時にお客さまが不満だらけになっているのでは意味がありません。

仮にゴールを明確にしないまま無理な状態で受注したところで、失敗プロジェクトになってしまっては、自分たちもお客さまも幸せになれません。

お客さまが納得されない場合には、そうしなかった場合のリスクとデメリットをとくとくと説明しなければなりません。説明責任（アカウンタビリティ）を果たすのは、契約前の交渉時におけるビジネス上の義務です。

たとえば、賃貸でも購入でも、物件を見る際に、価格だけ納得して購入した後に、

　実は、自殺者が多発した部屋でした
　実は、土地は元お墓でした
　実は、この近辺は犯罪率が高い

等、買った後に聞かされたらみなさんならどう感じるでしょうか。事前に聞かなかった方が悪いのかもしれません。販売側には説明義務はなかったのかもしれません。「聞かれたら、答えたかもしれないのに」と言われるかもしれません。

ですが、買い手の立場として、それで納得できるでしょうか。
「なんで、最初に説明してくれなかったんだ」と怒りませんか？
契約時の説明義務違反だと言って、訴えたりする人も出るかもしれません。

これと同じことです。

お客さまがＩＴのこと、ソフトウェア開発のことをどれだけ知っているのかわかりませんが、開発する私たちよりも知っているお客さま…と言うのは非常に稀です。

そのため、常に説明責任は私たちにありますし、それでも相手が納得しないのであれば、そのお話はなかったことにするか、あるいは別条件で成立する方法を模索するしかありません。

ですが、少なくとも私がマネージャーを務め、こうしたプロジェクトとして本当に求められているゴールがどこにあるべきなのかを互いに話し合って、ご理解いただけなかったお客さまは、ユーザーの中にもSIerの中にも殆どいませんでした（厳密には、ごく一部いました）。

こういった①～③のパターンごとにそれぞれの事情に応じたゴールを定め、対策を講じないと、プロジェクトに多くの影響が現れることになります。

たとえば、ゴールがないと最短ルートが見えずに非効率となりますし、プロジェクトのスコープを追加したいなどという要請があった場合の判断が難しいため、プロジェクト範囲拡大の要因となります。

もっと言えば、プロジェクトの成功度合い（求められる価値をプロジェクトで生み出せたのか）を正確に評価することもできませんし、ゴールの見えないマラソンを強要するようなものですから、メンバーにとってもプロジェクトで働くことの意味が薄れ、主体性や意欲の低下にも繋がります。

このパターンの厄介なところは、

　「ゴールが明確化されていないこと」と、
　「プロジェクトが上手くいかないこと」の因果関係が見えにくい

ことです。ボディブローのように徐々に蓄積されたダメージが、様々な問題の事象となって少しずつ顕在化してくるようなものです。

しかし、悲観する必要はありません。

逆に考えると、

　「ゴールさえしっかりしていれば、
　　プロジェクトが振り回されない強固な軸を作ることができる」

ということでもあります。リーダーやマネージャーのみなさんは、今進めているプロジェクトについて、

　・「生みだすべき価値とその達成条件」を明快・簡潔に説明できますか？
　・プロジェクト計画で言うところの「プロジェクトの終了条件」に
　　相当しますが、これを的確に、且つ抜け・漏れなく説明できますか？
　・「このプロジェクトは、これと、これができていればいいから。
　　それ以外は無視で。余計なことはしない。
　　必要なゴールに向かって最短距離で進もう」と明示できますか？

それはつまり契約によって締結されたプロジェクトの本質を考えることであり、それなりに時間も労力を要することではありますが、後々必ず効いてくるはずなのです。

それに、ゴールを設定すると、マイルストーンを確認する際に、常に実態と比較評価が可能になります。

　「ゴールに向かっているのか」
　「このままだとゴールに到達しなさそうか」

など、多くのことが適切に判断できるようになります。ゴールを置かなければそう言った比較評価は決してできません。だからマイルストーンにおいて正しい判断ができず、なんとなく「まぁ、大丈夫だろう」となってしまうのです。

余談

ちなみにオブジェクト指向ってご存じですか？

私はこの概念を、モノづくりの様々なところにちりばめます。オブジェクト指向の３大要素と言うと「カプセル化」「継承」「多態性」のことを指しますが、そんな専門的な話をされても、なかなかプログラミング以外の実践では活用できませんよね。

これら３つの要素技術を駆使することで得られる恩恵は、主に

　「再利用性」

です。
私はこれを最大限活用します。

たとえば、エンジニアにとっても一番わかりやすいところで

　機能をさらに素因数分解し、部品化する

なんてのはよくやる手法です。
ある画面から入力された情報をデータベースに登録し、次画面へ遷移する…なんて機能があった場合

　・入力を受け付ける
　・入力された値の正当性をチェックする
　・データベースに格納できる形式に編集する
　・データベースに接続する
　・データベースに書き込む
　・データベースに書き込まれた内容を確定する
　・データベースを切断する
　・次画面へ遷移するために必要な情報を収集する
　・収集した情報を次画面に表示できる形式に編集する
　・次画面へ遷移する

…実際にはもっと細かくなりますが、たった１つのシンプルな機能でも、細かくその処理を分解していくと、色々なことをしているのがわかります。プログラムの最小単位を「関数」と言いますが、オブジェクト指向言語では「メソッド（ふるまい）」と言いますよね。

１つの関数を振る舞い…すなわち「動作するもの」と考え、オブジェクト指向のオブジェクトを「目的」と意訳した場合

　１目的＝１メソッド

となっていることが最もシンプルになりませんか？
そもそも、コーディング規約的にも、メソッド名のプリフィックス（接頭辞）は今どき、たいていが動詞ですよね？

　あるオブジェクトに対して「１つの動作を行う」

というメソッド名になっているはずです。

setName()      // 「名前」を「代入する」
getAddress()   // 「アドレス」を「取得する」

そうやって、処理を素因数分解して部品にし、またそれらを組み合わせれば、組み合わせ次第で色々な機能を実装できるようになります。これがオブジェクト指向の基本中の基本であり、そして究極です。

これを設計段階から、念入りにしておくと、多少仕様が変更されたところで、

　各部品間のインターフェースや外部リソースのアクセス内容に
　大きな変更が加わらない限り、他部品への影響はまったくない

と言ったメリットを持つようになります。そうすると、調査工数やテスト工数をゼロにできるか、あるいは圧倒的少量で済むようになるため、予算はもちろんのことながら、スケジュール的な逼迫にもほとんど影響を与えなくなります。

こうした概念は、オブジェクト指向言語（Java、C#、等）の開発経験を持つエンジニアであってもきちんと理解している人は少なく、なかなか全メンバー、全機能に適用することが困難なケースが多いかと思います。

ですが、全てへの適用が無理だったとしても、仕様難易度の高い機能や、仕様未確定部分が多い機能などを中心に、少々スキルの高いエンジニア向けに対応してもらっておくと、いざ（なかなか仕様が決まらない、コロコロと仕様が変わる）と言う時に、当初の計画に大幅な影響を与えずプロジェクト進行ができるようになります。

まぁ、私はそれを、お客さま…とりわけ大手SIerなどに対して交渉、説得し、すでに指定されている仕様書や設計書の様式まで変えさせて、中間成果物全体もオブジェクト指向化させたりします。

　「決まってないから進められない」

という部分を最小限にして、進められる部分を増やすことができますし、進められない規模を最小化すると言うことは、後で進めなければならないときの負担を最小化すると言うことにもなります。

また、それぞれの部品を最小単位にすることで、仮に仕様が決まっていない処理部品があったとしても、器だけ作って（中身がすっからかん）おけば、テスト用にスタブやドライバとして活用することも可能です。

昨今、「フルスクラッチなんて、もう時代遅れだわー」なんて声もチラホラ聞こえてきます。フレームワークの導入可否についてはとりあえず置いておくとして、海外パッケージなどを利用したり、プログラム自動生成系のアプリケーションを利用した開発も増えてきました。

それはそれで、フルスクラッチに比べると価格を極端に抑えることができますし、お客さまの最優先ニーズが「低価格化」というのであればいいと思います。ですが、その反面、既存フレームワークやパッケージを利用すると、ニッチなお客さまのニーズを満たしにくいという側面もあります（日系企業は特に、世の中のルールや規格より、自社の独自性を優先しがちだから、よく揉めます）。

時代の流れに沿ったものであればいいと思うのですが、そうすることによって、お客さまのニーズを最大限満たせないというのであれば、私はそれら既存フレームワークやパッケージに劣らないスクラッチ開発方法を模索してもいいのではないかと思っています（まぁ、集められるエンジニアの技術レベルが常に高い状態で揃っているわけではありませんので、絵に描いた餅かもしれませんが…、まぁ新人はともかく、プライドを持ち始め、自らをプロと名乗るミドルエンジニア以上ならば…）。