きっかけ

仕事で担当していたアプリ開発のプロジェクトに複数炎上要素のある案件が含まれており、3ヶ月ほど火消し要員してました。
無事に火消しが終わって興味があったので独自にプロジェクトの分析をしてお客様にレポートを提出してきました。守秘義務があるため内容は全てお見せできませんが、一部を抜粋して共有させていただきます。

プロジェクトが「炎上する」とは？

1745件に上るシステム導入/刷新プロジェクトのうち、約半数の47.2％が「失敗」

色々と調査してみたのですが調査ソースや調査チームによってプロジェクトの成功率が違ってましたので2018年というところと、ITプロジェクトということで上記記事を参考にさせていただきました。
記事によっては3割しか成功しない、83.3%が失敗するなどと書かれていました。参考にさせてもらった記事の「失敗が47.2％」というのはだいたいそんなものだと思います。

【プロジェクトの炎上定義】
・高稼働が続く、スケジュールが遅延する
・ゴールが見えない
・人員が辞めていく、お金がかかる
・社会的信用を失う

プロジェクトが炎上するということは時間・お金・人的リソースに影響があることだと考えることができますが、人によって言うこと違ってたり、ふわっとしていたので分析の定義として使用することができませんでした。
また突然爆発するようなことはなく、徐々に問題が顕在化し身動きが取り辛くなってしまう状態を「炎上状態」と指し示すのではないかと思います。

よって調査と分析にはプロジェクトを炎上させないためにはではなく、プロジェクトを成功に導くにはという考え方を用いました。
炎上に対して共通定義が見つかれば炎上防止策が出てくるかもしれませんが、今回はプロジェクトを成功に導くにはという観点から分析をした結果の共有です。

調査分析対象プロジェクトと使用した観点

分析対象としたプロジェクト
対象は７プロジェクトで、全てスマートフォンアプリ開発のプロジェクトでした。メンバー数は５〜３０名ほどの小規模〜中規模プロジェクトで、期間は全て3ヶ月〜6ヶ月の短期〜中期でした。
うち炎上状態にあったとされていたのが２プロジェクトで、炎上になりかけていたのが２プロジェクトでした。その他３プロジェクトは大きな問題が発生しおりませんでした。
4/7に問題が生じていたので「失敗が47.2％」は実態と遠くない数字かと思います。


分析に使用した観点
分析した観点は以下の４つの視点です。

対外的観点
A：お客様への信用・信頼度に影響を与えるか
B：社会への信用度へ影響を与えるか
内部的観点
C：人的リソースへ影響を与えるか
D：無形資産リソースへ影響を与えるか

対外的な観点ではお客様から再注文貰えるか、２度と利用しないと言われないか、周辺企業とのパートナーシップや法律や道徳に反してないかなどを分析しました。
内部的な観点では人的リソースへのコミュニケーションロス、モチベーション低下、離職などを招いてないか、ナレッジ蓄積やスキル向上への影響を分析しました。

この記事の元になった調査レポートはお客様の悩みを解消するために作ったものなので「人が離職する」という問題に偏っていることもあります。
人を採用するのにも時間やお金はかかりますし、せっかく入社してくれた方々が疲弊し退職されるのは精神的にグッとくるものがあります。
どこの会社でもプロジェクトや仕事はありますが、そのプロジェクトを

調査結果１、プロジェクトにはゴールが複数存在している

ITプロジェクトにおいてプロダクトオーナーやPMなどのマネジメント層からするとプロジェクトのゴールはイケてる成果物を作ることです。
では今日のタスクを終わらさないと他の人に迷惑をかけてしまうと考えているデザイナーやエンジニア、テスターからするとどうでしょうか？
正直今日のタスクを終わらせるのが精一杯で、マネジメント層と同じようにプロジェクトのゴールまで考えることができない場合が多いのが実態です。

こんな感じでプロジェクトメンバーの役割によってゴールの認識にズレが生じ始めます。その後はプロジェクトのスケジュールが進むにつれて「そんな指示してない」「認識が違ってました」に発展していくわけです。
認識齟齬が発生した両者に悪意なんかはありませんし、両者は間違いなくプロジェクトに必要なメンバーですので、どちらが偉いとかもありません。
更にこの状況でどちら側に責任が〜、などとやっても状況の改善はしませんし、時間を割くだけ無駄です。

デザイナーやエンジニア、テスターにとって必要なのは今日の作業のゴールであって、プロジェクトのゴールは遠くの山のように見えているのです。
役割によって見えている場所が違うので当然です。

これを防ぐためには今日のゴール、今週のゴール、プロジェクトのゴールの粒度で複数のゴールが存在することを受け入れましょう。

今日のゴールは1日の作業量が多すぎないか、少なすぎないかという判断にPMと作業者の双方で使用することができます。
今週のゴールはチームが同じ方向に向かっていけているかという判断にチーム全員が使用することができます。
これによってPMと作業者の認識齟齬が発生しにくくなる環境を手に入れることもでき、望まれた作業を実施することができるため作業者のモチベーション低下要因を減らすこともできます。

PM同士の報告会などでもプロジェクトの進捗状況よりも、今週のゴールが存在しているか存在していないかを確認するようにしましょう。
第３者がチェックして問題のあるゴールであれば、当該プロジェクトは炎上に近いと言えます。

調査結果２、見積に命かけないと、後になって命取られる

プロジェクトのキックオフ前に概算見積を作成することは必須です。
この概算見積が実は厄介な存在だということを意識している人がとても少なかったので啓蒙の意味を込めても記したいと思います。

概算見積はプロジェクトを開始する前に作成するので実際に作業をする時とは環境や条件が変化しているケースが大半です。
ガチガチに契約で固められたウォーターフォール開発でもない限り、要件や仕様はほぼ間違いなく変更になります。
お客様都合で変更になることもありますが、実際に作業してみて発覚した事実から変更を申し入れるパターンもありますし、人的リソースに変更があった場合なども考えると、変化は必ずと言っていいほど発生するのです。
この将来的な変化や変更を見通せるのは神様ではない人間には不可能です。

さてこの問題が巻き起こす影響とはどんなことなのでしょうか。
それはプロジェクトが中盤や終盤に差し掛かった時に顕在化します。

【顕在化する問題たち】（2018年の現場の声）
・作業に思ったよりも時間がかかってしまい　→スケジュール遅延
・想定してない作業が増えた　→スケジュール遅延
・元々見積の時点でスケジュールきつめだった　→モチベ低下
・リスケ続きで作業メンバーの予定が立たない　→モチベ低下
・（要件/仕様決めの時に）やれるって言われた　→お客様との信頼度低下

参考のために作成した概算見積を信用しすぎてプロジェクトのスケジュールやWBSを引いた結果、実態と理想が乖離することに気づけなくなります。
お客様と合意を得ているため変更もできずにどんどん首が締まっていき、どうしようもない問題と化してしまうのが中盤〜終盤なのです。

これを防ぐためにはシンプルに作業する人が見積をするというルールを守ることです。

お客様に見積には期限が存在し、作業者や環境、プロジェクトの進行具合によって変化があるものだと正直に説明し理解してもらいましょう。
出来る限り要件定義段階から作業予定者が参画し、概算見積を作業予定者が作成するようにしましょう。
そして作業する前には必ず作業する人が見積をしましょう。

プロジェクトを成功に導くための鉄則として計画に全力を尽くすというものがあり、PMでも作業員でもちゃんと理解しているのです。
見積はスケジュールの要であり計画です。ここで手を抜くと後になってプロジェクトメンバー全員に影響を及ぼす問題となります。
プロジェクトの中で「適当でいいから数字を埋めて欲しい」なんて言葉が出ていたら要注意です。

なお見積もりする時の注意点はバッファをなるべく積まないようにすることです。バッファは予備であって実態ではありませんので、バッファでなんとかする癖は早めに直した方が良いです。
バッファを食いつぶした時に何も出来ず、お客様やPMから「もっと早く言って欲しかった」と言われてる人たちを何人も見てきました。
見積スキルも上達しませんのでバッファを活用するのは効果的ではありません。

調査結果３、プロジェクト運用に定期改善タスクがないので問題に悩まされるだけになってる

何にでも問題が発生することはありますし、問題が発生したとしても適切な対処ができれば良いと思います。しかしその対処の多くが暫定的、局所的になっていないでしょうか？

プロジェクトは1日や1週間じゃ終わりません。1ヶ月などの超短期プロジェクトじゃない限り3ヶ月以上もの時間をプロジェクトメンバーは同じゴールに向かって進みます。マラソンのように長い時間と距離を補給しながら進んでいくのです。

プロジェクトのスケジュールや運用計画を見ると定期的な改善のための時間が全く取られていないことが多々ありました。
これでは何が問題だったのか分析をするための時間がなく、恒常的に問題を発生させない環境を作り出すことが困難になってしまいます。
暫定対処しか問題解決の選択肢に残されておらず、サンドバッグのように個別の問題に打ちのめされて疲弊と消費を招いてしまうのです。

これを防ぐにはプロジェクトスケジュールに改善のための定期的な時間を設定することです。

プロジェクト計画に入れてお客様へも説明を行い理解をしてもらいます。
順調なプロジェクトでも改善することはたくさんありますし、参画しているのが優秀なメンバーであればあるほど改善タスクというものは提案されるものです。

具体的には改善の時間に集まってもらったメンバーに付箋紙とペンを渡して、改善すべき事項を書いてもらいます。
主催者は付箋紙に書いてもらったことをボードまとめます。
同じような内容であれば重ねますし、カテゴリ分けをしてメンバーが見てわかる改善の地図を作ります。そして優先順位をメンバー投票で決めます。
そして改善タスクはプロジェクト工数の中で実施し成果や経過をメンバーに共有します。

ポイントなのは必ずアウトプットすることです。
お客様へ提出するプロジェクトレポートでも良いですし、プロジェクトのことがまとめられているwikiのような場所でも良いですし、エンジニアの書いてるQiitaの記事でも良いです。

目的は問題に悩まされるだけの環境を作らないことだからです。
そしてこれはナレッジの蓄積にも繋がっていきます。
アウトプットしていることで単一のプロジェクトだけでなく、他のプロジェクトへもナレッジ共有することができるのでオススメです。

まとめ

提出した調査報告書ではもっと細かい内容まで分析報告していましたが、noteにまとめるとなると長くなりすぎてしまうので大まかな項目と汎用的に使用できる内容にしました。色々ご意見あるとは思いますがコメントなどで頂けると嬉しいです。

言葉にしてみてわかったのはプロジェクトが炎上しないようにというディフェンシブな考え方よりも、アクティブにプロジェクトを成功に導くためにはという考え方が個人的には好きだということに気づけました。
言葉遊びのように思えますが個人的には大事なことだと考えてます。

2019年も引き続き自分や弊社マンハッタンコードが関わるプロジェクトを、成功に導けるよう行動していきたいと思います。