インタビュー：Standish GroupのJim Johnson

Jim Johnsonは、ITプロジェクトの有効性に関する調査と分析を提供する世界的に有名な企業であるStandish Groupの創設者および取締役会の会長です。 「なぜプロジェクトが失敗するのか」という研究と、システムのコストと可用性に関するその他の研究のおかげで、まず第一に広く知られています。 さらに、仮想フォーカスグループやユースケース分析などの最新の研究技術の先駆者でもあります。



間違いなく、 Standish Groupの最大の名声は、フォーカスグループ、詳細な調査、上級管理職とのインタビューを使用した50,000件を超える完成したITプロジェクトの研究で構成される12年間の資料を収集したThe CHAOS Chroniclesの研究から来ました。 この調査の目的は、ソフトウェアアプリケーション開発プロジェクト間の障害の程度、障害の決定的な要因、およびそのようなリスクを軽減する方法を記録することです。 1994年、Standish GroupはCHAOSの研究に関する最初のレポートを発表しました。このレポートでは、完了しなかったプロジェクトに数十億ドルを費やしたという事実が記録されました。 それ以来、このレポートはこの業界の文脈で最も頻繁に引用されています。



休暇中にしばらく過ごして、ジム・ジョンソンは今週、この研究がどのように行われたか、そして研究結果の文脈におけるアジャイル手法の役割について話しました。 また、ソフトウェア製造のベテランであるAcxsys CorporationのエグゼクティブバイスプレジデントであるGordon Divittが加わりました。彼は、創業以来CHAOS Universityイベントに参加しています。



最初のCHAOSレポートがどのように編集されたか教えてください。



JJ ：私たちはかなり長い間研究を行ってきたので、彼についても少し教えてください。



私たちの最初の研究対象はサブソフトウェアの販売でした-その後、ベルギーのIBMグループを約100人率でリードしましたが、これらの販売を正しく追跡できませんでした。 ツールキットを販売するとき、いくつかの使用契約が期待できると言いたいです。 しかし、私たちが期待していたものが見えなかったため、そのような契約が締結されなかった理由について人々にインタビューしなければなりませんでした。 彼らは自分のプロジェクトは完了しないだろうと答えた。 当時、データによると、キャンセルされたプロジェクトの割合は約40％でした。 人々が話したのは本当の問題でした。



そのため、フォーカスグループなどを実施し始めました。 フィードバックを取得して、対処方法を把握します。 サンプルの信頼性を検証するために調査とテストを実施し、さまざまな規模のさまざまな業界や企業を代表するサンプルを受け取るまで修正および改善しました。



CHAOSサンプルは、アプリケーション開発のコンテキストで一般的に代表的だと思いますか？



JJ ：はい。



この場合、たとえば小さなソフトウェアメーカーが含まれますか？



JJ ：いえ、 違います。 次のカテゴリで構成されています：州または商業組織のみ-ディストリビューター、サプライヤー、またはコンサルタントなし。 そのため、サンプルではMicrosoftは表されていません。 また、ゴードンの会社のように、まれな例外を除き、売上高が1,000万ドルを超える組織もあります。



GD ：CHAOS大学のイベントへの参加は小規模企業に限定されているように見えますか？



JJ ：はい、私たちには本当に大きな顧客がいます。 しかし同時に、人々にインタビューするときは、偏見を避け、業界全体をカバーしようとします。 クライアントにインタビューするだけでなく、アンケートに記入するために人に支払います。これは完全に個別に行われます。 あなたは教会と国家がどのように（笑）理解しているか。



アンケートに記入するために人々に支払いますか？



JJ ：そうですね、彼らはフォーカスグループに来て、私たちは時間を払います。 アンケートに記入した場合、手数料を支払うか、何らかの贈り物をします。 これはすでにこの業界を研究する上での伝統です。 これにより、偏りのない回答に基づいたクリーンな結果が得られます。 支払わない場合は、何らかの形で研究の結果に影響を与えるためにバイアスがかかります。 また、支払いは意見を中立に保つのに役立ちます。 しかし、多くは慈善料金の約4分の1を寄付しています。州で働く人々の大部分は、いかなる場合でもお金を取りません。



はい、アナリストが希望する場合は先例を使用しますが、この情報を広告目的または独自のレポートに使用することはできません。



私たちが受け取る情報の主な品質-特定の会社からの境界-すべてが常にグループ化され、完全に機密であり、名前を示していません。 そうしないと、データを受信できません。



GD ：これは会社の財産です。



JJ ：はい、正確です。私たちは投票を公開しません。



人口統計調査の結果はサイトに投稿されます。 しかし、私には、何かが欠けているように思われます。つまり、ベースとして企業を選択する原則です。 開発の失敗に特に焦点を当てているので、特定の種類の失敗を抱えている企業を探していますか？ IT業界の平均よりも故障率が高い企業を選択していますか？ それとも彼らはあなたに向きを変えますか？ または、要するに、あなたのサンプルは一般的に失敗した開発の代表ですか？



JJ ：深刻なset折を研究の先例と考えることができます。有益なset折を探しています。 しかし、調査のデータとしてではありません。 失敗したプロジェクトはリクエストしません。 私たちの最初の研究は、おそらくそれに対する答えが非常に弱いという事実のために、最も広いサンプルに基づく大規模な分布でした（編集：1994年の研究では、8000以上のアプリケーション開発プロジェクトが発表されました）。



次に、SURFデータベースを使用して参加するように人々を招待します。特定の入力基準があります。



参加者は：

• 特定のプロジェクト情報にアクセスできる
• 特定のアプリケーションを使用する
• 特定のプラットフォームを使用します。

現在、データベースには約3,000人のアクティブな参加者がいます。 あなたは彼らが特定の問題を抱えていることに基づいて彼ら自身が志願したかどうかを尋ねます-しかし、私はそうは言いません。 彼らはデータに精通することができるので、彼らは参加していると思います-そして私たちは参加者だけにそれらを提供します。 しかし、偏った関心があるとは思いません...つまり、私たちは常にすべてを見直し、調整しています。



正解？ どんな意味で？



JJ ：間違っているように見える場合、またはわからない場合は、呼び出して、何かを明確にするか除外するためにデータを調べます。 必要な信頼性があること。 データベースを埋めるだけでなく、明確なデータが必要です。





2004年のカオス研究結果：プロジェクトの分布

複雑-53％、成功-29％、失敗-18％。



ご存じのように、ロバートグラスがどのようにCHAOSの結果に疑問を投げかけたかについてのレビューを書きました。 それまで誰かがあなたの番号に疑問を呈していますか？



JJ ：違います。 ほとんどの場合、「数字は楽観的すぎます」と言われます。人々はほとんど驚いています。 結果のキャンセルまたは不使用が原因で失敗したプロジェクトの割合（18％）に対する彼らの反応は非常に論理的です-彼らはこの現象の理由を理解しています：誰もが成功を達成し、最初にフィニッシュラインに到達しようとすると、一部の量はすぐに来てください。



業界で最も一般的なシナリオは、予算を超え、期限を守らず、計画された機能を提供しないことです。 ほとんどの人はこうコメントしています：「私は、すべてが時間通りに行われる単一のプロジェクトを知りません。」



世界の多くの都市での調査結果を発表しました。 それらはインターネットで見つけることができます。 そして、あなたは私たちの方法論を理解するために天才である必要はありません-それはすべてに知られています。



GD ：そして、協力から疑念に戻る人は誰もいません。人々は研究に依存しており、12年間イベントや調査に参加しています。 彼らはいつも戻ってきて、それは何かを言います。

このプロセスは常にCHAOSで行われているように、完全に透明であることは間違いありません。StandishGroupのオープン性を確認できます。 そしてさらに重要なことに、私の意見では、クライアントによる結果の受け入れを確認できます。これは、グループとの長期的な協力と参加によって確認されます。 「デンマーク王国で何かが間違っていた」場合、それはずっと前に表面に現れていたでしょう。



あなたは、人々は複雑なプロジェクトと失敗を混乱させる傾向があること、そして私自身がこのように罪を犯していることを一度言及しました、そしてあなたはそう考えることを勧めません。 このテーマについて少し話していただけますか？



JJ ：多くの人がこれら2つの概念を混同していると思います-複雑で失敗しました。 これは間違いです。 実際には、価値のあるプロジェクトと価値のないプロジェクトが1つのヒープにまとめられます。 私は価値のレベルの位置からプロジェクトを検討します。 新しいシステムはより多くの利益をもたらす可能性があるため、100万ドルを超えるプロジェクトはより価値があるかもしれません。 一方、複雑なプロジェクトでは、多くのお金が無駄になります。 私たちは、プロジェクトの失敗をプロジェクト管理の失敗から分離しようとしていますが、それはまだ価値があります。 このトピックは今私にとって非常に興味深いものであり、まさに新しい研究で明らかになったものです。



「成功」があり、これは一度に3つのパラメーターに矛盾しますが、プロジェクトはまだ成功していて重要です。 私たちは常に「客観的な人はこのプロジェクトをどのように説明しますか？」私たちは誰にも不利益を与えたくありません...しかし、プロジェクトが完了したが閉じられなかった場合、それは複雑で失敗ではありません。 ここで明確な線を引くのは簡単ではありません。



実際、プロジェクトは時間の経過とともに大きく変化するため、たとえば初期規模と最終規模に関する信頼できる情報を入手することは困難ですか？



JJ ：複雑なプロジェクトと成功したプロジェクトの違いを確立するために多くの努力をしました。 そして、彼らは時々再保険されます：彼らは失敗を避けるためにプロジェクト予算を増やします-私たちもこれに注意を払わなければなりません。







10の成功要因

1.ユーザーエンゲージメント

2.上級管理職のサポート

3.明確なビジネス目標

4.スケールの最適化

5.ワークフローの柔軟性

6.プロジェクトマネージャーの経験

7.財務管理

8.経験豊富なスタッフ

9.正式な方法論

10.標準ツールとインフラストラクチャ



プロジェクトの失敗に関するあなたの研究は、成功の秘secretを見つける試みですよね？ プロジェクトの成功要因のリストで、5番目が「ワークフローの柔軟性」であることに気付きました。 意味、アジャイルソフトウェア開発はどうですか？



JJ ：はい、そうです！ 私はアジャイルの大ファンです-私は90年代前半に反復作業を使用し、その後、迅速なリターンに関するCHAOSレポートがありました。 私たちは、製造プロセスにおけるアジャイルのための小さなプロジェクト、小さなチームを非常に応援しています。 ケントバックはチャオス大学で講義を行い、私は彼のセミナーで講演しました。 私は極端なプログラミングの真のファンです。 新しい本My Life Is a Failureでは、スクラム、RUP、XPについて説明しています。



GD ：アジャイル手法は、プロジェクトをより小さなサブプロジェクトに分解するのに役立ちました。 物事がうまくいかなくても、時間内に理解できます。 滝の方法に従って働いていた古いプロジェクトのように、穴に自分を埋めて、2年後にだけ悪いニュースを得るとき...



JJ ：秘密は段階的なものだと思います。 だから改善が見られると思います。 （注：Ed。以下は、Jim Johnsonが講義で使用し、2004年の研究から取った図です。）





比較：成功、失敗、困難。





1994〜2004年の追加費用の平均割合。





1994〜2004年の期限を逃した平均の割合。



大きな問題は、プロジェクトが「膨張」し、期限が切れ、予算が使い果たされ、不要な機能が開発されたことでした。 特に政府のプロジェクトで。 アジャイル方法論はここで本当に役立ちます-プロジェクトはほとんど成長していません。 彼らが言うように、「私はこれが必要です」、そして「以前は思っていたほど重要ではありません。」



G.D. ：はい、機能の優先順位付けは非常に役立ちます。常に「ビジネス上のメリットは何ですか？」 製品の非常に貴重な特性を決定し、リストの最後に残します。手が届かない場合、それはまったく必要ないことを意味します。



研究でアジャイルに関するデータを収集しましたか？



JJ ：はい、試しました。 これのいくつかを見せていただければ幸いです。 このような質問をアンケートに挿入しましたが、回答した人はほとんどいませんでした。明確なデータを入手することは困難です。 私たちは現在までのいくつかの研究で何かを達成しようとしました...今回は成功することを願っています。 数日以内に、2006年の調査を完了するために、私たちはSURFメンバーに最終的なアプローチを取ります。



アジャイルは新しい質問を提起するかもしれません。 適応計画のあるプロジェクトで計画規模に達したとき、あなたは現象と呼んでいますか？



JJ ：いい質問です。 Webex、Google、Amazon、eBayのような企業の場合、リリースではなく「ストリーミング」更新（「パイプライン」）があるため、言うのは非常に困難です。 「2週間で何をしたとしても、すべてが世界に行きます。」 ユーザーは小さな変更に直面するため、成功しています。 また、新しい変更を導入しても、それらは保護されます。多くのプロジェクトは、開発段階の完了後に失敗します。実装に進む必要があります。



ストリーミング更新？ ズームのような音。



JJ ：はい。 さまざまな規模で作業することは非常に有益です-作業が進行中であることを見ると、人々はより幸せになります。 人々は結果を見ることの進歩を見るのが好きで、アジャイルはそのすべての縮図です。



G.D. ：これらの企業にとって、ユーザーは若く、熱心で、簡単に適応できます。彼らは変化を好み、新しいことを試してみたいと思っています。 大手銀行はこのアプローチを容認していません。 だから私はこのプロセスを見ています-それはあまりにも失礼ではありませんか？



JJ ：すべての方法論がどのプロジェクトにも適用できるわけではありません。 多くの人にとってアジャイルは難しい文化です。



G.D. ：アジャイルで私が気に入っていることの1つは、あなたが何かをし、それを見て、ユーザーが「私はそれが好きです」、または「私はそれが好きではない、あなたはそれを変更できますか？」または「いいえ、それは正しい方法ではありません」ということです フィードバックが速く、ストリーム品質のデバッグがはるかに優れています。 「ウォーターフォール」アプローチを使用すると、プロジェクトを期待どおりに終了した場合でも、後でこれらすべての品質問題に対処できます。 アジャイルのテストとフィードバックにより、品質が向上します。



JJ ：アジャイルは非常に解放的だと人々は考えています。 彼らがよく見ると、「滝」やジェームス・マーティンが対処しなければならない何かにおいて、すべてが同じように困難であることがわかります。 過去10年間に改善がなかったと言うことは愚かです。 私たちは大きな進歩を遂げました。



さて、これが最後の質問になると約束しました。 最後の言葉はだれですか？



G.D. ：ご存知のように、ジムは彼のチーム全体と同様、著名な戦闘機です。 これは私が彼らと働くようにするものです。



ジム、私たちの会話に多くの時間を割いてくれてありがとう！