プロジェクト成功の5要素:DX視点で読む「意思決定遅延理論」2
1985年に結成されたThe Standish Groupは、アメリカのボストンにあるIT関連の調査組織です。前回の記事では、意思決定に無駄な時間を掛けることが、コストだけでなく、プロジェクトが失敗する確率まで上昇させてしまうリスクを説明しました。前回に続いて、このグループ(以下、SGと表記)が提唱している「意思決定遅延理論」を、DXの視点から読み解いてみましょう。
SGは、プロジェクトマネージメントの「グループリフレクション」を専門としています。これは、組織やチームが持つ知識や感情、理解を活用して、ITプロジェクトを改善することです。調査結果のデータベース「CHAOS (The Comprehensive Human Appraisal for Originating Software)」は、「ソフトウェア開発のための総合的な人的評価」です。『ソフトウェア開発プロジェクトの失敗や課題の根本的な原因は、意思決定の遅さにある』という刺激的な理論を元に、プロジェクトを成功させるためには何が必要かを見てみます。
出典:CHAOS Report Series Decision Latency Theory : It Is All About the Interval – Jim Johnson, Dreamer, The Standish Group
(以下のグラフは、出典を参考にLeapLeaper編集部で作成)
▼The Standish Groupについて|The Standish Group公式サイト
https://www.standishgroup.com
プロジェクト成功のための5つの要素
SGのレポートでは、プロジェクトが成功するためには、次の5つの要素が重要だと指摘されています。順番に見ていきましょう。
- コンパクトなプロジェクトの規模
- プロダクトオーナーやスポンサーのスキル
- アジャイルなプロセス
- チームとしてのスキル
- 技術だけでなく感情面でも成熟
1.コンパクトなプロジェクトの規模
SGの研究では、プロジェクトの適切な規模が、その成功を左右する重要な要素のひとつだと示されています。プロジェクトの規模はマネージメントでき、小さく留めることができます。スコープが限定されるからこそ、メンバーお互いの顔が見え、意思決定の遅延が短くできます。一つの基準として、最大6人のメンバー、半年の期間が示されています。
大規模なプロジェクトも複数の小さなプロジェクトに分割することで、納期を短くし、価値を早めに確認でき、顧客やユーザーの満足度を高められます。規模を大きくしたり、期間を長くする必要があるプロジェクトは限定的です。
プロジェクト規模別の解決策
規模 | 成功 | 改善の余地あり | 失敗 |
巨大 | 4% | 53% | 43% |
大 | 12% | 59% | 29% |
中 | 18% | 59% | 23% |
やや小 | 25% | 62% | 13% |
小 | 57% | 35% | 8% |
2.プロダクトオーナーやプロジェクトスポンサーのスキル
従来、SGでプロジェクトの成功に最も重要だと考えられてきたのが、事業の責任を持つ企業の取締役会など、管理職に近い人物の資質です。今はこれが「意思決定までの時間の短縮」に置き換えられています。
プロダクトオーナーやプロジェクトスポンサーの役割は、ビジョンの提示と適切な人材の確保、プロジェクトを統制するガバナンス、そして価値とメリットの提供です。また、成功の基準設定、変更などリスクへの対処、資金調達、マネージャーのサポートなど、多岐に渡ります。
これらの立場の人は、プロジェクトの成否を左右する最重要人物であることは変わりありません。そのスキルは、プロジェクトの規模が大きく複雑であればあるほど、成功・失敗の差を広げます。にも関わらず、スキルは簡単に身につけられる訳ではないので、優秀な資質を身につけてチームと良好な関係を築いていくことは簡単ではありません。
スポンサーのスキルによる解決
スキルのレベル | 成功 | 改善の余地あり | 失敗 |
スキル高 | 48% | 42% | 10% |
スキルアリ | 32% | 57% | 11% |
スキル中 | 21% | 52% | 27% |
スキル低 | 18% | 51% | 31% |
3.アジャイルなプロセス
SGのレポートでは、プロジェクトのパフォーマンス研究が始まった20年前には何百もあった手法は、今では大きくアジャイルと非アジャイルという2つのカテゴリーに分かれ、前者が約4分の1を占めています。非アジャイルプロジェクトのうち、ウォーターフォール型は約30%で、この数字は年々下がっています。
アジャイル(迅速)なプロセスでは、チームが重要な役割を果たします。多くのチームは、自律型・自己管理型で機能し、意思決定プロセスをチーム内で完結させられます。そのためには、チームには一定以上の高いスキルを持つことが求められます。
人気のアジャイル手法として「スクラム」という方法論があります。スクラムとは、少人数のチームです。共通の目的や目標を共有し、メンバー同士を支え合いながら、責任を果たします。プロジェクトは「スプリント」という1~4週間程度の小さな単位に分割されます。プロダクトオーナーがスプリントの目標を設定し、定期的な短いミーティングで進捗を報告し合います。具体的な作業に反映させ、顧客やユーザーからのフィードバックを分析します。
全プロジェクトを対象に、アジャイル対非アジャイルを規模別に分けると、以下のようなことが分かりました。大規模なアジャイルプロジェクトは、非アジャイルプロジェクトの2倍の割合で成功し、失敗は半分以下に抑えられます。中規模ではそれほどいい結果は出ていませんが、小規模では非アジャイルがアジャイルと拮抗しています。
小規模なプロジェクトが良好な結果を示すのは、前述の内容とも一致します。チームの共同作業がスムーズに進めば、意思決定のスピードが上がり、結果的に生産性が向上します。ほぼ自動的に、意思決定が行われるようになります。
方法論別の解決策
プロジェクトの規模 | 手法 | 成功 | 改善の余地あり | 失敗 |
全て | アジャイル | 42% | 50% | 8% |
非アジャイル | 26% | 53% | 21% | |
大規模 | アジャイル | 18% | 66% | 16% |
非アジャイル | 9% | 56% | 35% | |
中規模 | アジャイル | 31% | 59% | 10% |
非アジャイル | 19% | 61% | 20% | |
小規模 | アジャイル | 59% | 37% | 4% |
非アジャイル | 56% | 34% | 10% |
4.チームとしてのスキル
プロジェクトを成功させるための重要な要素は、チームのスキルがプロジェクトにマッチしていることです。プロジェクトではさまざまな作業が必要になるため、メンバーにはさまざまなプロとしての能力が求められます。
例えば、データベースを構築したり、ユーザーインターフェイスを設計するのであれば、当然、それらを実現できるスキルを持った人材が必須です。適切な人材がいない場合、内部で育成するのであれば教育コストと時間が掛かります。外部の人材をメンバーに加える場合も、委託費用やコミュニケーションがネックとなるでしょう。
メンバー全員が該当するスキルを持っている必要はなく、チームとして必要かつ十分なスキルを持っていることが不可欠です。どのようなチームでも、そのスキルがタスクに適合していなければ、苦労することになります。熟練したチームであれば、プロジェクトは成功に向かってスムーズに進みます。未熟なチームでは、外部よりも先に内部で問題が発生します。
5.技術だけでなく感情面でも成熟
最後は、チームが技術面だけでなく、感情面でも成熟していることです。プロジェクトが失敗する原因の多くが、人の性格特性や行動に関係する社会的な基礎力である、一般に「ソフトスキル」と呼ばれる人間の行動にあります。感情面で成熟しているチームは、うまく連携し、高い生産性を発揮できます。
複数を掛け合わせるほど強化される
前述の5つの要素は、どれか一つがあればいいわけではなく、複数を掛け合わせることで、プロジェクトが成功する確率は高まります。例えば、メンバーがそれぞれ高い技術力を持つことは当然として、成果主義に走らずお互いにサポートし合ったり切磋琢磨することで、一体感が生まれます。アジャイルにトライ&エラーを繰り返すことで、チームとしてゴールを達成できます。そのためには、プロダクトオーナーやプロジェクトスポンサーの環境作りが不可欠です。
技術力と感情面のスキルの組み合わせによる効果
DXには、意志決定をスピードアップさせることが不可欠
2022年後半から、MidjourneyやStable Diffusion、ChatGPTなど、いろいろなコンテンツ半自動生成するジェネレーティブAIが爆発的に普及しています。これは、スマートフォンもしくはインターネット登場と同レベルの、強烈なインパクトになるとも言われています。ビジネス環境を取り巻く変化は、ますます高速化・複雑化しています。
DXは、ITやソフトウェア開発に詳しいだけでは実現できません。自社のビジネスを十分理解していることはもちろん、マネージメントやコラボレーションなども不可欠です。何より、良好なカスタマーエクスペリエンス(CX)の提供によって、競争上の優位性を獲得できるか、自社のDXの真価が問われます。だからこそ、「意志決定遅延理論」で指摘されたような時間の先延ばしで、コストとリスクを増やしている場合ではありません。
ソフトウェア開発やプレゼンテーション資料で、単に機能や情報を増やすのは比較的簡単です。しかし、減らすのは容易ではありません。なぜなら、必要なのは機能や情報ではなく、哲学だからです。迅速に意志決定することと、拙速かつ無謀な判断とは似て非なる行為です。判断のスピードだけを上げてその場凌ぎを続けても、何れリソースは尽きてしまいます。自分の組織やチームにとって、時間を奪っている不要なことは何か?本当に必要なことは何か?意志決定のスピードを上げる方法はないか?DXの成功にとって、これは避けられない重要な要素の一つです。