アジャイル開発の領域が広がっても、発注者が抱えるリスクは減らない
少し前の記事ですが、「さらばQCDプロマネ」というものを見かけました。
https://tech.nikkeibp.co.jp/it/atclact/active/17/031600254/?i_cid=nbpitpa_sied_actrank&act04?i_cid=nbpitpa_sied_actrank&act04
発注者の多様なビジネス要件の変化に対応するために、スプリント・スクラムなどのアジャイル開発手法を工夫している事例が紹介されています。
この事例自体は参考になるところも沢山あります。ただし、落とし穴も一杯あります。
どの事例も、「発注者側と受注者側が、性善説を前提にベストエフォートのアウトプットを常に行う」ということが隠れた前提になっているのです。
言い換えると、アジャイルではゴールを曖昧にしやすい、誤魔化しやすいという、受注者から見たある意味でのメリットがあるんですね。
請負契約と比べて、準委任契約が完成責任（というか、アウトプットする責任）をほぼ負わなくてよい契約形態であるから、ラクであるのと似ていて、「出来るところまでやって、後はその時考えよう」という取引が成立しやすいという特徴があるので、ラクをしようと思えばやりようは幾らでもある、という手法でもあります。
成果物をちゃんと作らない分、プロジェクトの進め方が（悪く言えば）行き当たりばったりな分、他のベンダーに変更できないようにする罠は幾らでも仕掛けようと思えばできますしね。
意地悪な言い方をすると、さらばQCD、といって、Q（つまりゴールのアウトプットの明確な定義）を曖昧に出来るのなら、そりゃラクです。
あ、ちなみに繰り返しになりますが、記事で紹介している事例は素晴らしいと思ってますよ。あくまで、そういうことが出来る手法、つまり、発注者側がかなり気を付けなければならないプロジェクト上・契約上のリスクが多い、という話です。
プロジェクトマネジメントのバイブルはプロジェクトの成功に直接寄与しない
QCDプロマネと言えば、今やプロジェクトマネジメントの標準的に見なされているPMOKが改訂されたようです。
https://tech.nikkeibp.co.jp/it/atcl/column/17/091900386/092000001/?n_cid=nbpitp_mled_itp
「PMBOK大幅改訂、スキル転換を迫られるプロマネ」という記事です。PMBOKはQCDだけでなく、プロジェクトマネジメントに必要な10の知識エリアを定義したものですが、アジャイル開発やビジネスの視点を取り入れて大幅に改訂した、とのことです。
これを学べばプロジェクトを成功に導ける、と思うところですが、PMBOKはフレーム（知識体系）だけで、肝心の中身をどうマネジメントするかは個人の資質に依存しています。
IT系の資格を取っただけでは実践で使えないのと似ているところがあるかも知れません。
方法論（メソドロジー）と方法（メソッド）は違う、ということです。実際の細かい中身・担当する人間のスキルが重要、というのは、昔から変わっていません。
弊社では、「プロジェクトマネジメントや開発手法は、プロジェクトの成功に大きく影響しない」という考え方を採るに至っています。
なぜそう考えるのか、では何が成功にとって重要なのか、について、概要をご紹介したいと思います。
プロジェクトは、樹海からの脱出のようなもの
複雑な（難易度の高い）プロジェクトは、“樹海から脱出するようなもの”と弊社では考えています。
どう進むか（手法）、どう現状を把握するか（マネジメント）でなく、どういうルート/進み方で脱出するかという構想そのものが、成否を決めます。
要は、どっちに進むかという、最初の一歩が本質で、そこから先の要素は副次的なもの、ということです。
進む方向を間違えたら、その後どれだけ頑張っても迷走は確実です。いずれ出口に繋がるルートに出てきますが、それまでの遠回りした損害は大きなものになります。
（ちなみにこの遠回りのコストこそが、プロジェクトのコストを高くしている主たる要因です。安くしたければ安い事業者を使うのではなく、正しいルートを選択することが、本質的なコスト削減・リスクコントロールになります。）
「間違えた方向に突撃して、何かしら動くモノが出来るんだから、それなりの意味はあるんじゃないの？」と聞かれた場合には、そうですね、とその人の心情をおもんぱかって返事をしていますが・・・実際には違います。
方向を間違えた場合、プロジェクトそのものが未完に終わることは稀ですが、QCDのどれかを犠牲にしてカットオーバーすることになります。（一般的にはQ:機能、ですよね）
本来できるはずだった業務やビジネスを逸失した利益や、ビジネス要件を満たさない/合わないシステムによって将来追加負担しなければならないメンテナンス/改修コストを考えた場合には、トータルでは大幅な赤字は確定しているようなものです。
樹海脱出の最初の一歩・・・案件構想・プロジェクト設計
プロジェクトが開始するはるか前、発注者などのステークホルダーと最初に接触した時から、プロジェクト成功への取り組みは始まります。
- 経営層や現場とどのような関係で、
- ビジネスや業務のゴールをどのようにし、
- どんな技術やチームで、
- どのくらいの期間と費用で成功を得られるか、
- どのくらいのリスクの振れ幅をコントロールするか、
という、「案件の構想」を描きながら、コンタクトを深めていきます。
一般的には営業フェーズ、と呼んでいる会社も多いかもしれませんね。
スコープの定義、と同じと思う方もいるかもしれません。
ですが、どちらとも違います。
- 業務やビジネスのアイデアも出しながら、
- 経営者の期待効果や、現場の満足感を予測し、
- （相手から提示されなくとも）あるであろう要件を熟慮し、
- 自社が用意できる技術やリソース、コストやリスクを想定し、
- 何をどのように作っていけば業務やビジネスが実現できるかを考えながら、
これらを同時にこなしながら、案件の構想を固め、プロジェクトとして設計していく、「案件構想」「プロジェクト設計」が、プロジェクトの成功を左右します。
ですから、プロジェクトが開始してから参画するケース（実際には困ってから呼ばれることも多いですが）では、既に最初の一歩を踏み出して進み始めてしまっているため、軌道修正は事実上不可能です。
このようなケースでは、なるべく出血を避けるような、負けないための闘い、最短距離で出口に向かうルートに向きなおしてもらう活動に徹するしかありません。
まとめ
作りたいものを言ってくれれば作ります、という事業者も多いとは思いますが、それではどれだけ作っても発注者側とのギャップは埋まりません。
ビジネスの環境・技術・データの種類と量がますます複雑になっているこの時代に、発注者側が、正しい脱出ルートを判っている（もしくはそれを示す責任が発注者側にある）というやり方は通用しなくなっています。ゴールの無い行進を続けているようなものです。
ToBe/ゴール/要件などは、こちらから提示して最初の一歩の迷走を防ぐことこそが、今の時代のマネジメント/リスクコントロールであり、その鍵は案件構想力・プロジェクト設計力です。
開発手法やプロジェクトマネジメントは実施段階の要素の一つにすぎません。
