防火シャッターでも防げなかった？文化シャッターのシステム開発プロジェクト炎上の考察
グローバルシフト株式会社、代表の小川です。
2月13日のはてなブックマークの人気エントリーに、以下のような衝撃的な見出しが踊りました。
▼はてなブックマーク b.hatena.ne.jp
▼元記事
［特報］27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴 | 日経 xTECH（クロステック）
私たちが提供する、IT・WEBエンジニアのキャリア相談・転職支援サービス「TechLeadCareer」のtwitterアンケート企画「#エンジニア世論調査」でも、時を同じくしてシステム開発プロジェクトの状況についての調査を行っており、その調査結果でも今回の記事と同様に多くの開発現場でプロジェクトが炎上していることが推測される結果となりました。
上記の調査結果や、私が過去に体験した炎上プロジェクトの経験を併せながら、今回の記事に登場した文化シャッターのシステム開発プロジェクト炎上を考察してみたいと思います。
システム開発プロジェクトにおいて遅延・炎上は決して珍しくない
2003年10月〜2008年8月の間、私はIBMビジネスコンサルティングサービス株式会社(現日本IBM)という企業に所属していました。その間、参画した数件のシステム開発を伴うプロジェクトは、大半が大幅な遅延もしくは炎上と呼ばれるような手がつけられない状況に陥っていたと記憶しており、同期が配属された他のプロジェクトも似たり寄ったりでした。
また、私たちが実施したtwitterアンケート企画「#エンジニア世論調査」によると、「現在開発しているプロジェクトの状況は？」というテーマに対し、全体の約80%(全8,506回答中)が”遅延 or 炎上中”という回答が寄せられました。
【エンジニア世論調査】
— Tech Lead Career (@techlead_gs) 2018年2月7日
現在開発しているプロジェクトの状況は？
#エンジニア世論調査
さらには、日経コンピュータによるプロジェクト実態調査が2003年と2008年に実施されていますが、クライアント視点で失敗と評価されたプロジェクトは約70%という調査結果も出ています。
これらを見る限り、システム開発プロジェクトを行う際には、遅延・炎上が発生する事は決して珍しいことではない、という事が言えるのではないでしょうか。
なぜシステム開発プロジェクトは炎上するのか？
当然の事ながら、プロジェクト毎に開発内容や体制など前提条件がそれぞれ異なるため一概に論ずる事は難しいのですが、私の経験やブックマークのコメント欄で言及されていた内容を整理すると、以下の3つの内容に要約できるのではないかと思っています。
- 過剰なセールストークで決まる、安易な流行の採用
- ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題
- 欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ
それでは、それぞれの内容について詳しく考察を行っていきたい思います。
過剰なセールストークで決まる、安易な流行の採用
システム開発の営業・提案活動において、システム開発に関する経験・深い理解の無い営業担当者が行う、クライアントへの過剰なセールストークや技術的な裏付けの無いその場だけで決まった口約束は、その後の開発プロジェクトをスタート前から失敗に導くことになります。
今回の記事に「セールスフォース(SF)の導入にもかかわらず95％をカスタマイズ」「開始当初はアジャイル＋ウォーターフォール(WF)」といった内容が記載されています。
技術選定の背景やその目的が定かでないため一概には言えないのですが、「はやりのクラウドで開発したい(しましょう！)」「アジャイルやりたい(やるべきです！)」といった感じで、これまでの開発プロジェクトとの差別化を図ろうとした結果、話の流れの中で手段が目的にすり替わり、最終的にプロジェクトがキックオフされるに至ったのではないかと推測しています。
一方、大手の開発ベンダーであれば、社内に提案内容を精査するリスクマネジメント部門・機能があると思います。
当然リスクマネジメント部門は「95%をカスタマイズするならパッケージ・クラウドの意味がない」など、真っ当な指摘をされたことかと思いますが、大規模なシステム開発案件が少なくなってきている昨今、受注を確実なものにするため、様々なリスクヘッジ策を講じることを条件にGoサインを出してしまうのではないでしょうか。
残念ながら、リスクヘッジ策が適切に講じられることはほとんど無いに等しく、システム開発現場のエンジニアやクライアント担当者が疲弊し、最終的にプロジェクトは頓挫することになります。
ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題
ここで言う「企画(計画)」とは、プロジェクトの目的やゴール、対象システム(サービス)の内容と開発範囲、マスタースケジュールや各開発フェーズの定義、ステークホルダーの役割と責任、及びトレードオフを伴う意思決定事項の基本方針などが取り纏められたものを指します。また、ゆるふわな企画(計画)とは、要件定義を行う前の段階で「前述のような企画内容がシステム開発の要件定義を行うのに、十分なレベルで明確になっていない」という事を意味しています。
この「ゆるふわな企画(計画)」は、まずプロジェクトの序盤である要件定義フェーズで”要件バブル”を引き起こします。
プロジェクトの根幹となるしっかりとした企画(計画)が固まっていないため、要件定義を進めていく中で「あれもやりたい、これもやりたい」「こんなユーザーがいるかもしれない、こんな使い方も用意しなければ」と、無限に要件(の候補)が膨れ上がることになります。その結果、本来時間をかけて詰めるべき大事な要件に対して、十分な調査・検討時間をかけられず、要件定義が緩いまま次のフェーズへ進まざるを得なくなるのです。
今回の記事の中でも「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」がバグ発生の原因として挙げられています。この「要件定義フェーズの遅延」を生み出している大きな要因の一つが”要件バブル”であり、「企画(計画)」が不明確なままに要件定義フェーズを進めている事に他ならない、と私は考えています。
また「ゆるふわな企画(計画)」の影響は、要件定義フェーズにとどまりません。
”要件バブル”の影響で生み出された、”要件定義の不良債権”という名の様々な隠れた要件・仕様が、やっとたどり着いたプロジェクト終盤のユーザーテストであぶり出され、勢いよく一気に火を噴くことになるのです。
欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ
ここまでは、システム開発プロジェクト炎上の要因が、より上流の営業・企画(計画)策定フェーズから生み出され、プロジェクトの炎上にどのような影響を及ぼすのかを整理してきました。
しかし、システム開発プロジェクト炎上の最も大きな要因は、もっと根本的な別の要因にあるのではないかと私は感じています。それは、このトピックで言及する「欠落したベンダーのプロフェッショナリズム」と「不十分なクライアントのオーナーシップ」に他なりません。
「欠落したベンダーのプロフェッショナリズム」とは、前述した「過剰なセールストークで決まる、安易な流行の採用」と「ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題」において、開発ベンダーがプロフェッショナルとしての役割を十分に果たせていない、という現状を指しています。プロジェクトの目的に即していない技術の適用方法や開発アプローチの提案はもってのほかであり、仮にクライアントから不合理なソリューションの提案を求められたとしても、プロとしてメリット・デメリットを整理し、正しい意思決定をサポートすべきであると考えます。
では、システム開発プロジェクト炎上の要因は、全て開発ベンダーにあるのでしょうか？
私は決してそうは思いません。
過去、私が開発ベンダーサイドの人間としてシステム開発プロジェクトに参画していた時に、炎上プロジェクトに共通して感じるある違和感の存在に気付いた事があります。それは、クライアントサイドのプロジェクトメンバーの中に「自分達のシステムを作っている。絶対に成功させるんだ」という当事者意識を持ち、主体的にプロジェクトを進めているメンバーの比率が圧倒的に少ない、という事です。
もちろん、クライアント全てがそうと言うわけではないのですが、ここで言う「不十分なクライアントのオーナーシップ」とは、炎上プロジェクトには必ずと言って良いほど「主体的に意思決定できず、問題を先送りにする」方や「建設的に議論を進めずに、常に批判的な姿勢で悪戯に検討を長引かせる」方々の存在があり、クライアントのプロジェクト成功に対するコミットメントが不十分である、と言わざるを得ない状態を指しています。
今回の記事に対するブックマークコメントでも「クライアントの丸投げ体質」に関する言及や、「既存システムをそのまま新システムにリプレイスしようとしていたのでは？」といった、プロジェクトの目的自体が正しかったのかについての問題提起が見られました。クライアントサイドに十分な当事者意識・オーナーシップがあればこのような事態にならないのではないか、という意見には私も同感です。
どんなに課題を抱えたプロジェクトでも、ベンダー・クライアントのいずれかが責任を持って行動していれば、納期のリスケジュールやスコープの縮小、あるいはプロジェクト途中での開発ベンダーの変更など、開発プロジェクトが頓挫する前にできる対応は多々あると思います。
本件は恐らく、双方が課題を抱えたままプロジェクトを進め続けてしまったがために、修復不可能な状態まで大炎上してしまった、典型的な失敗プロジェクトであると推察されます。
どうすればシステム開発プロジェクトは炎上しないのか？
私たちグローバルシフトでは、所属するエンジニアの技術力向上・経験の蓄積を目的として、スタートアップやベンチャー企業の新規システム開発・システムリニューアル開発の案件を中心に、事業の一部としてシステム受託開発を行っています。
その際、私が過去に経験した炎上プロジェクトの要因分析から、各要因に対して以下のような考え方・取り組みでシステム開発プロジェクトを進めています。
「過剰なセールストークで決まる、安易な流行の採用」 への対策
私たちから、クライアント受けを狙った流行の技術・アプローチを、過剰なセールストークでお勧めすることはありません。
最近は「クラウド」「アジャイル」という流行りのキーワードをやりたいとご相談頂く事もあるのですが、プロジェクトの目的や開発内容の特性をヒアリングした上で、安易に適用すべきでない場合にはその理由と共にはっきりとお勧めしない旨をお伝えします。
確実にプロジェクト炎上リスクを高めるだけの場合には、開発のご依頼自体をお断りする事もありますし、クライアントが新しい技術・アプローチを適用したい理由がリーズナブルな場合には、しつこいと思われる程に想定されるリスクや影響をご説明した上で、両者合意の下で開発プロジェクトを進める事もあります。
何れにしても、提案を行うベンダーもそれを評価するクライアントも、耳障りの良さや目新しさに高い価値を置くのではなく、本質的なプロジェクト価値に目を向け、その実現可能性を最大限高めるアプローチを共に策定・合意できない限り、今後も本件のような不幸な開発プロジェクトは後を絶たないと思います。
「ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題」 への対策
「サービスを早くローンチし事業を推進したい」という本気の意気込みで、見積依頼をいただく事があります。経営者・事業責任者の意思は本物なのですが、企画(計画)に曖昧な部分が多く残っていたり、アイデアレベルという事も少なくありません。そのような場合私たちは、企画・構想策定支援のコンサルティング(2週間~1ヶ月)をご提案させて頂き、クライアントの想いやアイデアを明確な企画(計画)に一緒に落とし込んでいきます。
企画(計画)を一緒に策定する中で、システム・サービスの目的や機能の重要性・優先度の確認、トレードオフが発生した場合の優先するQCDの観点などについて合意形成を行うため、要件定義フェーズで”要件バブル”が発生しそうになっても、「これらの要件(候補)は重要性も低く、納期を優先させるためには初期リリースの範囲から外し、リリース後の検討にしましょう」といった形で、クライアントとの共通認識のもとに”要件バブル”を防ぐ事が出来るようになります。
また、要件の不良債権を後続フェーズに残さないため、プロジェクトの上流工程(企画や要件定義)であっても、可能な限り仕様の定義を具体的且つ明確に行うように心掛けています。この点は賛否両論あると思いますし、クライアントによっては実際に動かせるプログラムがないと、イメージが湧かず定義しづらいという声も実際にあります。
しかし、クライアント自身が開発を望んでいるシステムに対し、自分事として具体的なイメージを早期に持っていただく機会を作ることは、開発サイドとの認識齟齬や隠れた開発要件の炙りだしに有効であると私たちは考えており、クライアントの皆様には時折面倒に思われながらも、ご理解とご協力を頂いています。
「欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ」 への対策
自社のメンバーに要求する高いプロフェッショナリズムは当然のこととして、私たちはそれ以上にクライアントのオーナーシップや本気度、根拠に基づくリーズナブルな意思決定を許容されるタイプかどうかの見極めに重点をおいています。
極論・暴論にはなりますが、クライアントのオーナーシップが低かったり、根拠のないこだわりや気分による意思決定に固執されるタイプのクライアントの場合、プロジェクトの炎上・失敗リスクは飛躍的に高まります。そして、何よりも一緒に仕事を行うパートナーとして、このようなタイプのクライアントと仕事をする事以上に、自分達のモチベーションを下げる事が他に無いからです。
グローバルシフトは2015年の創業以来、幸いにも友人や知人、クライアントの皆様に恵まれ、全ての受託開発案件をご紹介・追加発注という形で継続的にいただいております。
また、過去にプロジェクトをご一緒したクライアントからは、さらにその友人・知人の会社をご紹介頂く事も多く「これほど信頼できる開発パートナーはこれまで会った事がない。ここに任せればスムーズにプロジェクトが進み、サービスをリリースできないという事はない」と、最高のご推薦文と共に繋げていただく事もありますが、このような評価が頂けているのも「システム開発炎上の要因に対し、課題が顕在化する前から一つ一つ丁寧に課題解決に取り組んでいるから」ではないかと考えています。
最後に
システム開発プロジェクトの炎上や失敗は、クライアント・ベンダーなど全てのステークホルダーにとって不幸な事であると思います。そして、プロジェクトがスタートを切る時点で、システム開発プロジェクトの炎上・失敗を望んでいるプロジェクトメンバーは、誰一人いないはずです。
今回の考察が少しでもシステム開発プロジェクト関係者の目に触れ、今後の開発プロジェクトにおいて少しでも遅延・炎上の解消に寄与すれば幸いです。
本件のプロジェクトメンバーの皆様、特に現場で日々残業・長時間労働を行い、なんとかプロジェクトを成功させようと身を粉にされたエンジニアの皆様、本当にお疲れ様でした。
