見出し画像

CHAOS Report2022 要約・意訳-よいプロダクトを生み出すためのヒント

これはなに

グローバルな調査機関The Standish Groupによるソフトウェア開発に関する調査レポートCHAOS Report2022 Editionの要約とその内容の考察をまとめます。


こんなひとにおすすめ

  • ソフトウェア開発/プロダクト開発のプロジェクトに従事するひと

  • プロジェクトを成功に導き、よりよいプロダクトを生み出したいとおもっているひと

  • CHAOS Reportに興味はあるけれど、長大な英語レポートを読解する暇がない

CHAOS Reportとはなにか

  • 調査機関The Standish Groupが発行するソフトウェア業界のプロジェクトに関するレポート

  • CHAOS=“Comprehensive Human Appraisal for Originating Software” ソフトウェア開発における統合的人的評価

  • ソフトウェア開発の成功率をさまざまな指標から評価している

  • アジャイルなど新しい開発手法の根拠データとして書籍やコンサルタントに頻繁に引用される •調査機関The Standish Groupが発行するソフトウェア業界のプロジェクトに関するレポート

購入はこちらから:https://standishgroup.myshopify.com/

要約

Factors of Success: 成功の主要因

プロジェクトが失敗するのは多くの場合、意思決定レイテンシが影響をしている。
意思決定が遅いか、またはそれが苦手な組織のプロジェクトは失敗しやすい。

慎重すぎて遅い意思決定ほど、あとから覆りやすく結果的によりたくさんのコストを生み出してしまう。
このような傾向はプロジェクトに関わる関係者やチームにも不安や不信感などネガティブな反応をひきおこし、貢献を得られなくなる。

Definition of Success : 成功の定義

プロジェクトの成功の評価基準も時代とともに変わってきている。
旧来の計測では予算、期日、スコープが主な評価基準であったが、これはプロジェクトマネジメントの成功を評価するのに向いている

昨今では、プロジェクトの成功を評価するために、予算、期日、そして顧客満足を主要な評価基準として計測している。2022年版のCHAOS Reportで表現される成功とはこちらの基準で評価されている

昨今のソフトウェア開発をとりまく環境は変化が早く、プロジェクト計画当初に定めたスコープも不確実なものになりやすい
仮にそれを”計画通り”にリリースできたとしても、期待していたリターンや顧客への貢献ができるとは限らない。

Resolution of types of Project: プロジェクトタイプ別の結果

プロジェクトは大きく、複雑になるほど難しいものになる
そして、いずれのサイズのプロジェクトであっても旧来のウォーターフォールではなくアジャイルを採用したプロジェクトのほうが成功確率は高くなる。
また、地域別ではAsiaが最も成功確率が低い。

Myth and Illusions: 否定された過去の定説

Standish Groupの長年の調査結果から、現在では支持できなくなった定説がある

否定された定説1:熟練のプロジェクトマネージャーがプロジェクトを成功させる
プロジェクトマネージャーの熟練度はプロジェクトの成功確率に作用しているとはいえない。
プロジェクトマネジメントとしての正しさに固執して官僚主義的になるのではなく、素早くリスクをとった意思決定を行えるようにすることが重要である

否定された定説2:プロジェクト・ポートフォリオマネジメントツールがプロジェクトの成功には必要
このような管理ツールは官僚主義的な管理コストを増やし、意思決定スピードを遅くしてしまうおそれがある。
大切なのは、重要なことのみを数えることであり、ツールはプロジェクトのスピードを上げるために適切に利用する方が良い

否定された定説3:すべてのプロジェクトは明確なビジネス目標をもつべき
小規模なプロジェクトは、実験的なものであるため事業戦略との密接な結びつきは必ずしもプロジェクトの成功に影響を与えるものではない。

否定された定説4:不完全な要件がプロジェクトを失敗させる
初期段階で完全な要件を目指すこと。
ソフトウェア開発ではむしろそれが害になる。スコープが肥大し、苦労してその機能を実装しても結果的に利用されないことが多い。
望ましいのは、扱いやすい必要最小限のサイズであって、不完全であっても後からの変化に柔軟であること。

The Good Sponsor, Team and Place: よいスポンサー、よいチーム、そしてよい環境

プロジェクトの成功確率を高めるためには、よいスポンサー、よいチーム、そしてよい環境が必要である。

より早く、よい意思決定ができるスポンサー、チームは感情的に成熟していて、それはよい環境によって育まれ、維持される。

よいスポンサーとはなにか

スポンサーとはプロジェクトに命を吹き込む唯一の存在である。
よいスポンサーは、素早く意思決定をする能力に長けているだけではなく、適切なタイミングで適切なひとを集め、動機づけ、権限を渡して任せることができる。
「いま本当に大切なこと」を判断し、チーム対して過剰な介入ではなく、プロジェクトを進めるために必要なことを提供できる。

よいスポンサーとなるための原則は次のようなものがある。

10 Principles for a Good Sponsor
引用:CHAOS Report2022 /The Standish Group

よいチームとはなにか

チームとは、プロジェクトを主体的に進め価値貢献に繋がるプロダクトを生み出す小集団である。
よいチームは、相互に影響力を発揮して自律的に高めあうことができる。
専門的な問題解決能力を備えているだけではなく、常に前向きで共感能力と自制心を兼ね備えており、感情的に成熟した高度なコミュニケーションによって、対立も解消させることができる。

よいチームとなるための原則は次のようなものがある。

10 Principles for a Good Team
引用:CHAOS Report2022 /The Standish Group

よい環境とはなにか

環境とは、スポンサーとチームが働く場所。スポンサーとチームをサポートし、影響を与える人々、プロセスやルールである。

よい環境は、意思決定の遅延を抑止し、過剰な慎重さや管理よりも素早い意思決定を奨励する文化、プロセス、システムまたは教育がある。

ステークホルダーの意向を伺うよりも、プロダクトを実際に利用するユーザーを巻き込んだ反復的な検証から学習することができて、プロジェクト進行を妨げるような力に対処することができる。

よい環境となるための原則には次のようなものがある。

10 Principles for a Good Place
引用:CHAOS Report2022 /The Standish Group


ここまで読んでいただいて、ありがとうございます。
この内容は、あくまでも全260ページの内容から、私の個人の独断でピックアップして意訳したものです。
興味を持たれたかたはぜひ、原典をあたってみてください。

考察:わたしたちはなにをすべきか

 この要約で述べられている内容は、日頃プロダクトマネジメントや、いわゆる「アジャイル」を学び、触れているかたにとってはあまり目新しいことではないかもしれません。

ですが、知っていることと実現できるということには大きな違いがありますし、さらに言えば、それを誰かに伝え、協働する組織を変革していくことはとても難しいことだと思います。

このような調査の定量的なレポートは、組織や働き方を変えようとするアクションをする上で説得力を補完する根拠データとはなり得ますが、それを引用するだけで十分ではありません。

誰もが、じぶんが「官僚主義的」「慎重すぎる意思決定」または「過剰な介入」をしているなどとは考えてはいませんし、自覚することも難しいでしょう。

「なんとなく、アジャイルのほうが良いらしい」という印象は持たれても、それが実際何であるのか?どのように動けばいいのか?そこで求められる期待や責任を誰もが果たせるのか?ということはまた別の話です。

そこで、鍵になるのはレポートで述べられている「感情的な成熟」ではないでしょうか。

 自分がスポンサーであってもチームメンバーであっても、まず内省的になり自らのわかっていること、わかっていないこと。そしてわかっているつもりだけどわかっていないかもしれないことに意識を向けるというところが最初のステップ。

その次には、官僚主義的、機械的になにかを評価、管理しようとするのではなく、自発的に自分たちのプロジェクトが成功であったと言えるのか?自分の意思決定は適切適時であったのか?と他の誰よりも批判的な目線を自分に向けられるようになることが次の段階のように考えます。(といっても後ろむきではなく前向きに)

これを行うためには、ひとが内面的に抱える根源的な欲求や保身、不安を理解して向き合ってそれを乗り越えるようなコミュニケーションの設計が必要になります。

理解し、理解されるため、「対話」を深めていくことが無知を知り、感情的な成熟を目指すための鍵であるように考えています。

ぜひ、感想や別の意訳をなされた方がいればお寄せいただければ幸いです。

おしまい


この記事が気に入ったらサポートをしてみませんか?