情報システム開発の「失敗」に関する研究を紹介します。

中身は以下の論文の要約になります。

情報システム開発プロジェクトの失敗に関する文献のレビューと批評： 情報システム開発プロジェクトの苦悩を探求するための議論
Review and critique of the information systems development project failure literature: An argument for exploring information systems development project distress

基本的なスタンス

情報システムの開発はなぜ失敗するのか？

この問いの応えるべく、ITベンダーの社内だけでなく、公益団体やジャーナリスト、およびアカデミックな世界でも議論されてきました。こちらの論文にあげられた過去の文献のリサーチ結果におれば1980年代から議論の積み重ねがあるようです。

とはいえ、世界的に見ていまだに70%以上のシステム開発が「失敗」という烙印を押されていることから、アカデミックの世界における研究もあまり現実世界には役に立っていないのではないか、という懸念があります。

はたして、研究の結果実際はこれぞという「原因」が体系化されて示されており、実務の場にいるわれわれが不勉強であるためにいつまでも「失敗」が続いているのか、それともそもそも実務に役立つ形でまだ解決策が示されていないのか？

本論文は後者の立場をとっています。

そもそも「なぜ失敗するのか？」という問いの立て方た自体に問題があり、この問いに答えようとする限り、実務における問題解決につなげるための知見を得るには限界がある、という主張です。

まず、筆者らは世界中の321本の情報システム開発プロジェクトの失敗に関する論文を調査し、以下の３種類に分類しています。（日本における研究も含まれています。）

従来の研究

①合理主義的なアプローチ

プロジェクト遂行の結果を「成功」「失敗」のような形で最終状態を想定し、経営・組織・人・技術など様々な要因がこの「失敗」（または成功）と因果関係があると想定しています。
この考えは理想的なプロジェクトマネジメントをするならばこうあるべきだ、という一般的なモデルを想定し、「原因」と「結果」の間の因果関係を明らかにしようとします。また、最終的にはそれぞれのプロジェクトが成功するかどうかを「予測」するようなモデルやシステムを作ろうとします。
すべてを合理的に説明できるはずだ、という信念・態度が裏にあります。

例えば、
「タイムラインの過小評価」
「要件とスコープの定義の甘さ」
「プロジェクトのリスク分析の不十分さ」
「リスク 分析に関する誤った仮定」
「ビジネスニーズの曖昧さとビジョンの不明確さ」
といったものが問題とされています
これらはプロジェクトマネジメントと要件定義の領域の問題で、既視感の高い問題群です。

②プロセスに着目するアプローチ

プロジェクト遂行の結果を「成功」「失敗」のような形で最終状態を想定しつつも、経営・組織・人・技術などの要素がお互いに織り成す「相互作用」に着目し、そこに何かしら客観的に見出せる「欠陥」がパターンとして生じているにも関わらず、それに気づかず適切なタイミングで対処されないことが「失敗」の原因だと考えます。

つまり、理想的なプロジェクト管理規定があっても、スキルがマッチしたメンバーがいても、経営陣から理解のあるサポートがあったとしても、それでプロジェクトの成功が約束されるということはなく、あくまでも個別の事例で生じるプロジェクト特有の「欠陥」が各要素間の相互作用にあることに気づかず、それに対して社内政治が適切に機能しなければ、失敗にいたる、という考えです。

例えば、
「プロセスの問題を技術の問題と解釈してしまう」
「プロジェクトの戦略的な方向性の誤り」
「要求事項と実施事項の不一致」
「問題を認識することの失敗」
「既存のビジネスプロセスと 情報システム開発プロジェクトの間の構成上の適合性の弱さ」
「 失敗した行動方針へのコミットメントと継続的なリソースの投入」
「失敗と欠陥の誤解」
「 プロジェクトの特性とプロジェクト管理手法の不適合」
といったものが失敗の原因になります。

③ナラティブを重視するアプローチ

プロジェクト遂行の結果として語られる「成功」や「失敗」はそもそも固定的なものではなく、それを語る人の主観がかなり入っているため、その人のどの時点で(when)どのような立場でどのような基準で(how)、なぜ（why)そう「成功」または「失敗」と主張したのかを細かく観察していくアプローチです。当然同じ組織の内のメンバーであっても、人によって「成功」「失敗」の判断が変わるし、同じ一人の人物のなかでも時や立場が変われば「成功」とも「失敗」とも言える状態がでてきます。

言われてみれば確かにそうかもしれませんが、このアプローチの場合、個別具体的な事例における解像度はあがるものの、将来実務で使える知見を提供することが難しくなります。

以上の３つが過去の研究の基本的なスタンスであると整理しながら、本論文の著者たちは３つの研究がいずれも「失敗」という最終的な状態にこだわりすぎだと主張しています。

合理主義的アプローチではそれが最も顕著で、例えばQCDを満たさなければ「失敗」という形で定義して、あとは何が原因の特定に邁進します。プロセス重視のアプローチでは多少は「プロセス」に目を向けて、相互関係の中にある「欠陥」を発見しようとしますが、それでも「失敗」は不可逆的なものとして想定しています。ナラティブを重視するアプローチは、「失敗」と「成功」が解釈によって変わりうるものだという洞察を与えてくれるものの、何かしらの最終状態を想定し、その原因を個々人の解釈を明らかにしていく点では、まだまだ最終状態を意識しているともいえます。

著者らのアプローチ

では本論文の著者たちどういうアプローチをとるか？

著者たちは、プロジェクトの「成功」とか「失敗」といった過去の組織・人が決めた「結果」（最終状態）とそれを避けるための一般的または個別の知見を追い求めて活用しようとしても、実務では役に立たない可能性が高いと考えています。

それよりも、今現在問題に直面している人が、情報システム開発に特有の苦悩（心配事、精神的苦痛）に着目し、それを一つずつ解決していくことができる知見を提供する必要があるとしています。これはプロジェクトマネジメントの本質に関わるところで、早期に問題を発見し対処し続けることができれば、プロジェクト全体の不確実性は減り成功の可能性があがりり、問題に対する対処ができないままずるずるいくと、失敗というラベルが貼られてしまう、という主張であり、確かに絶対に欠かせない視点だと思います

では、解決の切れ味をあげていくためにはどうすればいいか？

まずは「早期警告のサイン」が少しずつ浮かび上がってくる中で、それを適切に察知する必要があります。
「体制上の問題」
「文化や言語、用語の使用法の違いによる誤解」
「矛盾した情報」「不十分な情報」
「ミスコミュニケーション」
「直感」

そしてこのような警告サインに気づいた後、それを自ら「問題」として構築し、当事者間で解決するのか、上司や顧客・パートナーなど会社を超えて解決するのかを判断する必要があります。

結局この「問題発見力」「問題構築能力」がうまくいくかどうかに、その後の対応がすべて左右されてしまうため、ここで著者らは「センスメイキング理論」を導入してテコ入れします。

（もちろん、警告サインに気づけるかどうかも重要ですが、この点は個々人の性格特性にも左右されるところだと思います。大らかな人はそもそも警告サインに気づかない可能性もあります。その場合は、警告サインに気づける人がいない、という「問題」を誰かが設定する必要があります。）

従来の研究ではこのよくある「苦悩」の解決のための意思決定プロセスの最適解は何か、という視点が欠けていたため、この点に関する知見の提供は今後の実証研究の積み重ねが必要だとされています。

センスメイキング理論の詳細はよくわからないので、深く立ち入りませんが、基本的には「組織全体での多義的な解釈の足並みを揃え、対象とする事象の意味について組織のメンバー、周囲のステークホルダーが「腹落ちする＝納得する」ストーリーを導き出し、集約していくプロセス」を確立しようとしているのだと思います。（参照）

問題発見の視点として、プロジェクトメンバーの個人レベル、プロジェクトのマネジメントレベル、プロジェクト外のレベルでそれぞれ以下のような問いを立てて実証研究をしていく必要があるとしています。

＜個人レベル＞

• 個々のチームメンバーは、プロジェクトの目的、スコープ、構造、方法論、成果物、期限をどのように理解し、交渉するのか？

• チーム内の個人的なセンスメイキングプロセスは、どのように、またなぜ異なるのか。

• 分散し、過労になりがちなチームメンバーは、どのように相互作用し、協力し、タスクや期限を調整するのか？

• プロジェクトチーム内のコンフリクトや不協和の指標は何であり、どのように識別し、監視し、管理することができるのか？

• プロジェクトチームは、チーム内や分散したチーム間での不協和やセンスメイキングの破綻にどのように対処し、解決しているのか？

• また、何が集団的なセンスメイキング、協働、調整を妨げ、何が刺激するのか？

＜マネジメントレベル＞（プロジェクトの内と外の双方に関わるレベル）

• さまざまな利害関係者は、情報システム開発プロジェクトの目的、資金、スケジュール、期限について、どのように交渉し、意見の相違を解決しているのか？

• 適切でない資金や非現実的な期限は、プロジェクトのパフォーマンスや苦境にどのような影響を与えるのか？

• プロジェクトチームの内部と外部で、情報システム開発プロジェクトに対する認識やセンスメイキングはどのように、またなぜ異なるのか。

＜プロジェクト外のレベル＞

• 硬直的なガバナンス構造と柔軟なガバナンス構造は、情報システム開発プロジェクトのパフォーマンスと苦境にどのような影響を与えるか？

• ITガバナンス構造は、どのように情報システム開発プロジェクトを「コントロール」し、影響を与えるのか？

• 逆に、情報システム開発プロジェクトはどのようにITガバナンス構造を実現し、それに挑戦するのか？

• どのような価値観や規範やルールが、一方では IT ガバナンス構造を、他方では情報システム開発 プロジェクトを支えているのか？

• これらの価値観、規範、ルールが情報システム開発プロジェクトに組み込まれたものと不一致である場合、どのような影響があるのだろうか？

• 情報システム開発プロジェクトに組み込まれている価値観、規範、ルールと不一致がある場合には、どのような影響があるのだろうか？

• IT 部門の文化と組織文化の違いは、どのように生まれ、情報システム開発 プロジェクトに影響を与えるのか？

• 価値観、規範、文化の不一致に生産的に対処するために、どのようなアプローチ、プロセス、介入策が用いられるのか？

感想

私はプロジェクトマネージャーとしては未熟なレベルであるため、最後に掲げられた問いに対しては全く答えられませんでした。パッと仮説を出すこともできないです。他方で、今までにお会いしたことのあるプロジェクトマネージャーの中に、あの人なら答えられそうだなというイメージもできました。これらの問いに答えるには、周りの人の思考過程が手に取るようにわかるまで、相手の立場に立って考え続けなければならないという印象です。そのためには相手の置かれている専門領域に対するある程度の理解は不可欠です。そして、プロジェクトマネージャーという役割は今後まだまだ発展していく余地があると感じました。