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

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

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


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

　今回は**スケジュールが大幅に遅延**を問題として設定します。そして、1段階目の「なぜ？」を問いかけた結果、5つの小問題が出てきたので下図に書きました。今回は赤枠で囲った3つを掘り下げます。
 <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1159798/edd03998-76e0-475a-9f66-2f9d1095c71f.png" width=60%>


###### ①作業のやり直しが多い
スケジュールが遅延していった原因の1つは、まず**作業のやり直しが多い点**です。このPJにもルールがいくつかあり、それらを守りましょう！ということなのですが...端的に言って**PJルールはほとんど守られていない**状況でした。そのため担当者に作業をやり直してもらっていました。もし各作業ごとにPJルールを守っていればやり直しは発生せず、担当者も私もWin-Winになります。なぜPJルールを守らない（守れない）かを掘り下げた結果が下図になります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1159798/c21f03a5-4021-4aa1-8ea0-50660e1763de.png" width=100%>

**★前提★**
PJには以下の４つの前提があります。
- 「システム設計が最優先」という価値観
- PJメンバ（特に設計）は多忙
- PJメンバは、社員、パートナー企業社員、他社（海外）社員 etc.
- PJには複数の文書が存在する

**★原因★**
大きくわけて、PJルールを守る側とPJルールを作る側に原因があると考えています。

:::note alert
PJルールを守る側（担当者）の作業負担が大きい
- 複数の文書の中から、PJルールの記載箇所を探し出す必要がある 
- あいまいなPJルールは、誰かに相談しないと対応ができない
:::
こんなに手間がかかるのなら、担当者がめんどくさいからルールを守らなくてもいいか :sweat:...と考えるのも当然のことです。

:::note alert
PJルールを作る側（PMO）のルール策定・管理が不十分
- どのような状況で使われるかを意識して作成していない
- PJルールのあいまいさが明らかになっても、すぐに回答・周知しない
:::
　同じ会社の人間からなる小規模PJの場合は、同じ研修やルールの中で仕事をしているため**暗黙の了解**が機能します。しかし、今回は様々な会社の人が数多く参画しているため暗黙の了解はほとんど機能しないと思ってよいです。だからこそPJルールを細かく書く必要性が出てきます。
　もしPJルールにある程度の自由度を持たせたいから意図してあいまいに書いているならば、迅速に疑問へ回答する体制を構築してほしいところです。
 
　複数ある文書はプロジェクトマネジメントをまとめたもので、全体像を把握することに向いています。そのため、個別の要素を知りたい人にとっては使いにくい文書といえます。

**★対策★**
PJルールが守られるようにできることは、以下2点の工夫ができそうです。

:::note info
PJルールを守るための負担を減らす
- 具体的かつシンプルなPJルール集を作る
- PJルールを自動的にチェックするツールを使用する
:::

極限まで負担を減らしたPJルール集を作れば、担当者が「PJルールを理解していないから、作業やり直しが発生する」事態を解決できそうです。
さらに、人ではなくツールによるチェックができればさらに時短になります。私が参画していた炎上PJでは、ドキュメントを格納しているシステムの管理者権限があれば自動チェック用のルールを作成・実行できそうな雰囲気がありましたね。



###### ②予定通りに作業が進まなかった
　次のスケジュールが遅延した原因は、他社（海外）との共同作業がうまくいかなかったために**作業が予定通りに進まなかった**点です。そりゃ、予定通りに進まないから遅延するのだろうという話なのですが...掘り下げた点を下図に示します。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1159798/183c9adb-dc42-47f3-bde0-77bb2e9c1f29.png" width=100%>

**★前提★**
前提は以下の3つあります。
- 定例会議は英語で実施し、必要に応じてチームメンバが翻訳する
- 混乱を防止するため、議事録を共有（相談＆タスク管理用）
- 海外チームの大まかな休暇は共有（大型連休）

**★原因★**
原因としては、やはりお互いの文化・価値観の違いを正しく認識してお互いが歩み寄れていなかった...といえます。私は海外で働いた経験がないため、経験がある人に話を伺っていました。でも実際に一緒に働いた経験しないと、正直ズレを認識できなくて厳しいなと思いました。

:::note alert
文化・価値観の違いを認識し、お互いが歩み寄れなかった
- 仕事は大事だけど、期日のために休暇を削ることはない
- 依頼事項の意義に納得しないと、作業をしない
:::

**★対策★**
具体的に「これをしたらうまくいく！」というものはないのですが...

:::note info
お互いに心地よく仕事をできる方法を探る
- キックオフミーティングで、PJ方向性の共有、問題発生時のエスカレーション基準や方法、顔合わせ、責任範囲 etc. を話し合う
- PJ進行中は、お互いにフィードバックをもらう
:::
自分が当たり前だと思っていることも、ほかの人には当たり前じゃないということに気づかされました :sunglasses:

知人に話を伺ったところ...以下の経験を共有してくれました。
- トラブルが発生したため、顧客が窓口に列を作って待っている...知人（日本人）は残業して対応しているのに、海外の従業員は「時間だから帰るわ」といい本当に帰る。
- ビジネス上の言った言わない問題を回避するために、議事録を当日中に作成して合意（サイン）をもらう。ホワイトボードを使って議論していれば、ホワイトボードにサインしてもらって写真を撮り、後で共有する。
- 知人（日本人）が「コンプラだから無理」といっても相手が引き下がらなかったので、「コンプラとは何か？」「会社のポリシー、それを踏まえてどう捉えているか？」「それを行うとどのような悪影響が発生するか？」等、前提から事細かに説明して納得してもらった。

いろいろあるんですね、驚きです :open_mouth: 


###### ③PJ制約による現場負担が大きい
最後の原因は、**PJ制約による現場負担が大きい**です。
残念ながら、こちらは情報が少ないため、全然分析できていません:sob:
とりあえず、今まで通り図を貼り付けます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1159798/e8486305-36f7-46bb-bce1-c4c165c0c5b6.png" width=100%>

「あのPJ制約がなくなれば、うまくいくのになぁ」と現場が感じているものがあります。しかし、その制約は（顧客の意向ではなく）**完全に会社の上層部の意向**なので排除することができません。
上層部は「他社（海外）と共同でシステムを開発し、顧客に提供＆運用した:triumph:」という実績が欲しい...むしろこの実績を作るためにこのPJがあるのでは...と思ったりします :thinking:まあ、私は下っ端なのでこの辺の事情は一切入ってきません。
PJ制約は排除できないので、なんとか制約がある中で試行錯誤しているのですが...結果としてPJは混乱しているので、顧客はどう思っているんだろうな～と心配です。


## まとめ
大規模PJって色々魔物 :smiling_imp: :skull: が潜んでいるよなと思いました。
関係者が多いとコミュニケーションコストが爆増するので、炎上PJだからといって人員を追加してもさらに:boom::fire:炎上&混乱:fire::boom:するだけですし...
人数が多すぎて、いろいろ大変なんだろうな。
残りの2つの分析は、**高みの"炎上プロジェクト"見物(2/2)** として記事を作ります。

※非常に意地が悪いタイトルを設定しました。「高みの見物」とは「直接的に関係がないため、物事の経過を興味本位で傍観すること」です。