高みの"炎上プロジェクト"見物(2/2)

はじめに

※本記事は、高みの"炎上プロジェクト"見物(1/2)の後編になります。
この度、炎上プロジェクト(以降、PJと表記)から離脱することが決定しました。PJ内の雰囲気はギスギスしていて、正直居心地が悪かったです。
　私はPJの中の（比較的）炎上していないチームを担当していたため、残業はそれほどありませんでした。しかし他チームは夜間や休日にも仕事をしていたために、（しっかりと休むことができず）体調不良者やメンタル不調者が出ていました。
　私にとっては直接経験する初めての炎上PJでしたので、今まで見聞きしたことを整理して対策を考えることで、今後の社会人生活に役立てたいと思います。

なぜ炎上したか

開発スケジュールが大幅遅延のため、大幅なリスケジュールを実施中。
なぜなぜ分析を用いて、自分なりにその原因を探っていきます。
※私は下っ端なので、一部の情報しか入ってきていません。

なぜなぜ分析

　なぜなぜ分析とは、問題となった事象に対して「なぜ？」を5回問いかけることで、真の原因を導き出す手法です。

　今回はスケジュールが大幅に遅延を問題として設定します。そして、1段階目の「なぜ？」を問いかけた結果、5つの小問題が出てきたので下図に書きました。今回は赤枠で囲った2つを掘り下げます。

※前半の３つ(①作業のやり直しが多い、②作業が予定通りに進まなかった、③PJ制約による現場負担が大きい)は、高みの"炎上プロジェクト"見物(1/2)に書いています。

④PJ内の有識者が少ない

　スケジュールが遅延していった原因の４つめは、PJ内の有識者が少ない点です。有識者ばかりであれば知識の不足による疑問点はなく、方向性さえ定めれば設計がサクサク進むはずです。PJ内にも有識者は少なからずいるため、設計の要所要所で有識者に教えてもらったり、確認するといった工夫次第でなんとかなりそう...と思いますよね。なぜ、うまくいかなかったのかを掘り下げた結果が下図になります。

★前提★
PJには以下の前提があります。

• PJメンバは、様々な分野からかき集められた（＝PJの業界に詳しくない人も多い）

★原因★
　システム開発には様々な知識が必要になると思うのですが、大きく分けて顧客の業界特有のドメイン知識とシステム開発のスキル（知識と経験） の不足に原因があると考えています。

顧客の業界特有のドメイン知識不足

• 業界の知識（概要、仕組み、法制度　etc.）
• システム運用者の知見

　業界の基本知識は「システムが必要となった背景・目的、システムの大まかな仕組み」のことで、こちらには書籍やWebサイト等から情報収集が可能です。そして、それらの情報は新人研修用の資料にまとめられており、30分程度で把握できます。また、PJ内勉強会も開催されているため、そこからも必要なルールを補うことができます。
　しかし、そこから先の（設計担当者自身が担当する）個別機能の詳細化・具体化に課題があります。PJと類似したシステム開発を行っているため知見はある（はず）ですが、当時の設計担当者やもともと顧客の業界にいた転職組から情報を引き出し、さらにそれらを文書化してPJ全員が参照できるようにすることがうまくできていません。

システム開発のスキル不足

• 設計を円滑に進めるためのコミュニケーション能力
• 汎用的な設計開発のスキル

★設計を円滑に進めるためのコミュニケーション能力
　各機能ごとにチームリーダーが配置され、リーダーは自チームの設計に集中し、期限を守ることを最優先事項として考えています。しかし、リーダーは設計業務に加え、部下のフォロー、上層部・PMへの報告、他社の設計チームとの連携など、多くの業務を抱えており、非常に多忙です。本来なら他の機能を担当するリーダーとも連携が必要ですが、後回しになりがちです。
　つまり、やるべきことばかりが増え、業務の簡略化や効率化の仕組みがないため、チームリーダーの負担が大きくなっています。

★汎用的な設計開発のスキル★
　会社の文化としてOJT(On the Job Training:実業務を通じて教育すること)を大事にしています。しかし本PJはチームリーダー自身も業務が多忙で、一人ひとりに時間をかけて丁寧に教える余裕がなく、OJTが十分に機能する状況ではありません。また、リーダーが持つ知識や経験は、たたき上げで身につけたもので体系的に整理されておらず、効果的に教えるのが難しいです。

★対策★
リーダーの適正には技術型（テックリード）、マネジメント型、二刀流がいます。チームやPJとして適材適所で役割分担をすれば、効率は確実に向上するはずです。

弊社はJTCのため、管理する人が評価されます。（できるとは言っていない）

• マネジメント型の適性を持つリーダーは、技術面ができなくても「仕方ないよね、できる人にまかせよう」という雰囲気となり、得意なマネジメントに注力できます。
• 技術型の適性を持つリーダーは、技術面では活躍できるのですが、マネジメントを誰かに任せようとすると「何のための管理職なの」となり、苦手であっても評価のためにやらざるを得ない状況です。非常に苦労しているように見えます。
• 二刀流の適性を持つリーダーは仕事ができる人として、仕事がどんどん流れ込んできます。

技術型・二刀流のリーダーが生き残るためには、リーダーにしかできない仕事（設計方針の決定・技術的な課題の解決）に注力して、それ以外の仕事をできる限り外注する方向で動いた方がよいと考えます。

負担を減らすために、効率化を追求しよう

• ちょっとずつメンバーに任せていく
• 業務効率化・省力化ツールの積極的な活用
• 外部教育（研修、e-learning等）の積極的な活用

具体的には以下のような方法があります。

• レビュー : リーダーが「セルフチェック用のチェックシート」を作成し、担当者自身に単純な問題を取り除いてもらった後にレビューを行う。チェックリストをシンプルに保ち、もともとある機能やプラグイン、テンプレート、ショートカット等を最大限活用する（セキュリティに留意）。
• 進捗報告 ：チームメンバに報告を代行してもらう。または、チームの最新状況をチーム外からも把握できるように、ダッシュボード的なものを参照できるところに置いておく。
• 教育：リーダーがOJTの中で身に着けた知見のうちのいくつかは、e-learningや書籍等である程度カバーできる可能性があります。

coffee break

私の会社では、過去に大規模な炎上PJがありました。そのときは、とにかく事態を収束させるために業界知識がない人まで招集されたそうです。その炎上PJを乗り越えた経験者は「あのときは長時間残業ヤバかった！」と語る人が多く、同じ困難の乗り越えた仲間同士の結束は強そうです。

　しかし、「何が原因で問題が起きたのか」「どうすれば障害対応が楽になるのか」といった具体的な原因分析と改善策を私は聞いたことがありません。「その教訓をこのPJで生かすために、なにか資料としてまとめられていますか？」と聞いても資料が出てこなかったので、なんだかなぁと思います。（当時の経験者は現在の私のような下っ端で、過去の炎上PJの全体像が見えなかったのかもしれません...）

⑤大幅に作業項目が増加した

スケジュールが遅延していった最後の原因は、大幅に作業項目が増加した点です。そりゃ作業が大幅に増えれば、スケジュールにバッファを設定していたとしてもすぐに使い切って遅延しますよね...という話です。なぜそこまで誤差が発生してしまったのかを掘り下げた結果が下図になります。

★前提★
なし

★原因★
　作業項目とその作業にかかる工数について、予定と実績が大きくずれてしまった原因は、作業工数を適当に設定しているからだと考えています。

作業工数を適当に設定する

• 実物を確認＆タスクを分解＆作業時間の見積もりをしていない
• 現場には間に合わせるための覚悟ができている

　PJでは、他社と自社の文化の違いによって設計書の粒度が異なっていたにもかかわらず、詳細を確認せずに「設計書があるから問題ない」と判断しました。その結果、作業量を適当に設定し、実際に進めてみると想定以上の作業が必要になり、スケジュールが破綻しました。
　そもそも、スケジュールは締め切りから逆算して立てられています。各種作業の工数を見積もり、その合計値を踏まえてスケジュールを設定しているわけではありません。チームメンバは「具体的にどれほど厳しい状況か」は把握できていませんが、感覚的にヤバいことは認識できています。結果として、「早朝出勤や深夜残業、休日出勤をすれば、さすがに期限に間に合うだろう」という悲観的な楽観主義が生まれ、工数を正確に見積もる意識があまりないようです。

★対策★
事前にどれくらいヤバいのかが認識できていなければ、人員を補充したり、顧客と交渉したり...事前に何かしらの対策を打つことができます。

システム開発でも３現主義の考え方を使う

• 他社の設計書を確認し、期待する設計書との差を認識する
• どのような作業が必要かを洗い出し、タスクとして分解する
• 今までの経験からそのタスクにかかる時間を見積もる

3現主義とは、「実際に現場で現物を確認し、現実を認識した上で問題解決を図る」考え方です。時間の見積もりについては、日ごろから自分の作業ペースを記録しておく必要があります。

まとめ

　優秀な人であれば、自分に入ってくる情報が限られていても、いろんな人を巻き込んで、全員にとってWin-Winになるように行動できるのだろうなと思います。残念ながら、私は優秀な人ではないので、あまりＰＪに貢献できませんでした。今回のPJの反省点を生かして、別のPJではうまく立ち回ろうと思います。
　例えば、PJルールを整備してよと依頼されたら、「新入社員でも理解できるか？」というあいまいな視点ではなく、「プログラムが書けるか？」の視点で作成＆レビューするとか。（新入社員も優秀な人が多いので、察することができるんですよね。）
　他には、相手に作業を依頼するときは（くどいかもしれないけど）前提であったり、目的を踏まえて、作業内容を説明するとか。いつも自分はどんな作業をしていて、どれくらい時間がかかっているのか。同じ結果を出すためにもっと楽できる方法はないかとか。
　社会人になってからのほうが、よく勉強している気がします。(笑)