炎上案件の鎮め方

システム開発における炎上問題は、今や業界全体の課題となっています。プロジェクト管理やコミュニケーション不足、技術面での問題など、原因は様々です。

そこで今回は、これまで数百社のIT顧問をした経験から、炎上問題による影響やその対策について書いていこうと思います。

１．炎上がなぜ起きるのか？
２．炎上時に起きる最悪のデッドロック
３．炎上から抜け出す方法

それぞれ解説していきます。

１．炎上がなぜ起きるのか？

システム開発プロジェクトにおいて、プロジェクトが炎上する理由は大体以下の３点に集約されます。
(※もちろん他にも多々ありますが、私がご相談を受ける範囲では下記が多いのです）

・開発後期における要望爆発

→　画面が出来上がり、機能の開発も完成間近、というところで、あの機能が欲しい、この機能がないと使えない、と要望が噴出し、あれもこれも受けた結果、進捗が見えなくなって納期が分からなくなるパターン

・関係者の増大による技術負債の肥大化

→　自社のエンジニア、業務委託エンジニア、外注業者、開発コンサルタントなどなど、多数の関係者が増えてコードの統制が取れなくなり、この部分はAさんしかわかりません、、とリリースをしてもいないのにセクショナリズムが発生する。

・コミュニケーション不足や認識不足による要件の曖昧さや不明確さ

→　（言ってなかったけど）これは当たり前のように使える機能だと思っていた、と言われてまぁまぁ大きめの修正依頼が入りリリーススケジュールが瓦解する。

一度でもプロジェクトに携わったことがある方なら、ああ〜〜と心当たりがあるかと思います。

煎じ詰めれば、統制を取らずに場当たり的に開発プロジェクトを進めていく、ということが炎上を招く大きな要因なのかと思います。

とはいっても進めないとマズいプロジェクトだったので、、、と担当者からは弁明を聞くのですが、急いては事を仕損じる、とはよく言ったもので、焦って進めるくらいなら、準備に十分過ぎる位の時間をかけたほうが結果的に早く、安全に終わるケースのほうが多いのです。

なぜなら、一度炎上してしまったプロジェクトを正常化するのは非常に骨が折れるのです。

２．炎上時に起きる最悪のデッドロック

プロジェクトが炎上した際に、最も避けなければいけないことがあります。
それは、プロジェクトの歴史を知る人を外さないことです。
開発会社等に依頼をしているのであれば、これまでの議事録や仕様変更の流れなどをまとめてもらってください。

炎上している際には、これ以上任せるのが不安、という気持に駆られて案件の関係者を外したり、契約を打ち切るパターンが多いのですが、それは悪手中の悪手です。

なぜなのかというと、システムの歴史や現状が分からないと、手助けする人が現れても手の出しようが無いのです。

炎上している案件の立て直しに入る人は、すべからく五里霧中の状態です。

すなわち

「なにがどうなっているかわからない・・・・」が頭の中に渦巻いています。

そんな中で立て直しを命じられても

「出来るのだろうか・・？」

「できなかった時のためにリスクヘッジしておこう」

という心理が働き

「まずは全体像を把握するのに１〜２ヶ月ください、それで出来るかどうか判断します」

「現状調査費用として１００万円ください」

といったフィードバックが返ってきます。

これは、リスクを負わされたくないエンジニア側としての視点に経てば理解は出来るのですが、

一方で経営者としてみた場合、

「１日でも早く解決したいのに、治るかどうか分からないのに数ヶ月もかかって費用もかなり掛かる・・・辛い・・作り直すのも費用が・・」

となるわけです。

つまり、

何でも良いから早く解決して欲しいと期待する経営者

と

状況がわからない中でプレッシャーをかけられリスクヘッジをしたい現場

という最悪のデッドロックが発生するのです。

こうなると、何がどうなっているか分からないシステムだけが残り、誰も幸せにならないのです。

３．炎上から抜け出す方法

では、こういった場合どうしたらいいのでしょうか？

実はこれ、先程のデッドロックの原因からさかのぼっていけばいいのです。

１つ目「現場の心理的安全性を確保する」

まず、現場が安心して立て直しに専念出来るように、経営者が現場に向けて直接、免責内容を伝えて上げてください。

たとえば

「万が一、立て直せなくてもそれは経営側の責任として処理するので、みなさんが出来る限りのことをやってください」

といった感じに。これは、社内エンジニアであっても業務委託であっても外注先のシステム開発会社でも同じです。

正直、これをいうのにはかなり勇気がいることだとは思いますが、こうやってプレッシャーを取り除いて上げないことには、現場はリスクヘッジを考えざるを得ず、結果的に、プロジェクトの健全化 & 自分の身の保身、という２つの目的が混ざった結果、よりわけのわからないことになるのです。

２つ目「求めている状態を繰り返し伝える」

ひとたびプロジェクトが炎上すると、「早くなんとかしてくれ」とだけしか言わない方がいらっしゃいます。

少なくとも

何が、いつまでに、どの様になっていて欲しい

のかを明確化し、可能であればタスクリストとしてまとめて現場に伝えて上げると問題の優先度が分かるようになるので早期の健全化が見込めるようになります。

３つ目「時には、捨てる覚悟を持つ」

これは過去に実際にあったお話です。

とあるクライアントがモバイルアプリの開発を開発会社に依頼したところ実装完了として上がってきたものがログインすらできない品質だったことがありました。

さすがにログインはできない状態は問題だろう、ということでクレームを入れるも「テストは御社の仕事なので弊社では確認を致しません」と突っぱねられて途方に暮れる。。

作られたソースの問題を点を洗い出し、なんとか立て直そうとするもの、修正項目が多すぎて、クライアントの現場のメンバーがひたすらに疲弊してく、、というまさに地獄絵図でした。

この際に私がアドバイスしたのは

「既存のソースを全て捨てて、新しく作り直しましょう」

というものでした。

これを提案した理由としては、クライアント現場メンバーが問題点の洗い出しを行ったことにより、どんなプロダクトが欲しいかがより明確になっていた。テストを通じてどの機能がバグりやすく、どこがテストが大変なのか、を身を以て体験した経験から、最適な発注依頼が今なら出せるのではないかという感触を得ていたからでした。

結果的にソースを全て捨てて、開発会社を一新したところ、６ヶ月以上経っても完成しなかったシステムがなんと２ヶ月で形になりローンチまでこぎつけることができました。

お金をかけて作ったソースを１度も使わずに廃棄することは非常に抵抗がありますが、無理に使い続けてサンクコストを支払い続けるくらいであれば、もう無理、と思ったら延命させずにリスタートを切る、というも非常に有効な手段の一つです。

まとめ

炎上した案件を正常化するのは、新規でプロジェクトを立ち上げるのに比べて３〜１０倍の工数が必要なくらい大変なことだったりします。

これをやりきるには、現場の心理的安全性の確保、残す/捨てるの判断、対応優先度、関係各所への周知、などかなり広範囲に渡り動いてく必要があります。

しかも、炎上経験が初めてだったりすると何をどこまでやればいいのか、見通すのが難しいかと思います。

特に炎上していると経営者は「自分が全て取り仕切らねば」という思いに固執しがちなのですが、やはり会社の一番の強みは「組織」だと思います。

委ねるところは委ね、判断するべきところは判断する、緊急事態だからこそマネジメントの基本を守っていければ、と思います。

弊社Growthwellでは、エンジニア組織専門のコンサルティングサービスを行っております。

・エンジニアの退職者が多い

・エンジニア組織をどう作ったらいいか分からない

・作りたいプロダクトはあるが誰に相談したらいいか分からない

そういったお悩みがありましたら、お気軽にご相談ください。