はじめに
何割のITプロジェクトが炎上するか知っていますか？
有名な話ですね、約7割です！
逆に言うとうまくいくプロジェクトは3割くらいしかないんですね。、！
生きていれば、気付いたらあるプロジェクトに入っていて
「さあ、開発してください」みたいなシーンが来ます。（多分）
中には、上手くいってるプロジェクトだけではなく課題を抱えているプロジェクトもあります。
そんなプロジェクトに入った時にまずやるべきことは何なのか、
どういう観点で動くとよいのかこの際なので書き殴ってみようと思います。
テック的なことはあまりなくポエムっぽい仕上がりなので、
気晴らしに読んで肥やしにしてください。
その1. プロジェクトの全体像を把握する
まずは全体像の把握が重要ですね。
何を作るのか、なぜ作るのか、どのようなスケジュールで進んでいるのかを理解しましょう。
（何が上手くいっていない課題なのかここで把握できると尚良し）
-
プロジェクトの目的、目標
→何を作るプロジェクトなのか -
システムの概要、構成
→どんな環境で動作するのか、
→だれが使うのか
→既存環境に組み込むのか、イチから整えるのか -
開発フェーズ、スケジュール
→リリースに必須となる要件は何なのか、リリース後にフェーズ分けして対応するものがあるのか、
→どの程度の遅れなのか（炎上している場合）
→外しちゃいけないマイルストーンはどのタイミングなのか -
チームメンバーの役割分担
→リリース要件を把握しているのは誰なのか？
→レビュワーって誰になるの？
→誰がマージできるん？
この辺を把握しておくことで、
そのチームの中でどんな貢献ができるのか見えてきます。
（場合によっては自分が一番リスクになり得ることもあるので早急に把握が重要）
その2. チームメンバーとコミュニケーションをとる
言わずもがな既存チームメンバーとのコミュニケーションは、めちゃ大事です。
ランチしてみるもいいですし、今何をしていて何が課題なのかラフに話してみるもいいです。
弊社の場合はランチ文化もあり、使わない手はないですね！
開発者しか認識していない課題が聞けたり、開発効率の改善ポイントが出てくればもう勝ちです。
バリュー出せるポイントがもう目の前にあるんですよ？
その課題を解決するだけで、開発効率を改善できて遅延も少なからず解消するきっかけになるはずです。
例）・開発branchの運用方法が複雑
→一度立ち止まってbranchの運用ルールを整えてみましょう。
→変にcherryPickして、テストサイト用の別ブランチにマージするとかやってないですか！？
その3. 既存コード・既存DB構造を理解する
これ、基礎中の基礎なんですけどめっちゃ大事です。
そもそも、
- どのタイミングで必要なデータが生まれるのか
- 誰がどんな操作をすることでステータス遷移していくのか
- どんな設計になっているのか(そもそも設計がない場合は設計提案もバリュー出せるかもですね)
- テストコードを確認（テストケースとして想定される内容から各メソッドの振る舞いがわかる）
→テストコードなんて書いてたら間に合わねえよっていう人はt-wadaさんのスライド読みましょうね
https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
とか一旦把握してから動き出す感じですね。
※ただここに時間かけすぎるのはナンセンスです。
（入った時にはもう遅延しているかもなので！要はバランスです。）
手を動かしてみるも選択肢の一つなんですが、
一度立ち止まってインプットしてから開発する方が結果効率が良かったりします。
その4. タスクを明確にする
誰が何をやるのか担当するタスクを明確にするのはみなさんやるでしょう。
- 何を
- いつまでに
- どのレベルまで完成させる必要があるのか
とかですね。
ただこれだけでゴールではなく、
共通認識をできあがるまでチームですりあわせるのが大事です。
進捗管理がしやすくなるだけでなく、依存関係にあるタスクに気づくポイントにもなります。
例）Aさんのこの実装が終わらないとBさんのタスクが進まない
→今の計画だと、リリースまでに必須要件のBさんのタスクが絶対間に合わないやん!!!!!
みたいな悲惨なことにならないようにチームで共通認識をもちましょう。
その5. 報告、連絡、相談を徹底する
報連相は、プロジェクトだけでなく仕事を円滑に進めるための基本ですし、誰でもやろうと思えばできることです。
（テクニック論は色々あるから自分に合うものを見つけるのが大事）
- 進捗状況を定期的に報告
- 問題が発生したらすぐに連絡・共有
- 不安点、不明点は相談
自分1人だけで解決策が見えない問題を何時間、何日も抱えても
解決する問題はほぼないはずです。
思い悩む時間があるなら、
他の人の知見を借りてでも解決するのが今求められていることです。
逆にプロジェクトメンバーから相談を受けたときでもそれは同じです。
その6. 積極的に質問する
わからないこと、 不明点は積極的に質問していくことが大事です。
背景を知らずに、開発しても見当違いのモノが出来てしまったり、致命的な負債になる可能性もあります。
どれだけ年次を重ねても、
どれだけ経験を積んでもそのプロジェクトにジョインしたあなたは、プロジェクト内では一番新人のはずです。
新人時代を思い出してください。
（先輩へ色々質問しながら四苦八苦して開発していた人の方が多いはずです）
その7. チームに貢献する
アサインされた、あなたに求められていることは何でしょうか。
開発遅延の解消？進捗管理？
いいえ、そのプロジェクトを無事ゴールさせることです。
でもそれは、一人では決してできません。
チームメンバーと協力することでしか解決しません。
当事者意識をもってプロジェクトと関わることで、きっとそのチームメンバーも協力してくれるはずです。
- 課題解決・課題抽出に協力（あなたの知見が絶対役に立つシーンがあるはず、！）
- チームメンバーのサポート（タスク配分の調整・要件確定）
その8. 楽しむ！
なんだかんだこれが一番大事！！！総じてこれ！！！
助っ人プロジェクトは、 大変なのは間違いないんですが自分の課題に気づけたり
新しい開発・ドメイン知識を学ぶことができる貴重な機会です。食わず嫌いせずはダメです。
- 前のめりに取り組んでみる
- 新しい課題を楽しむ
- 積極的にチャレンジする（やったことないことをやりまくるのはちょっとリスクも、、）
おわりに
カオスな状況を楽しみながらいろんな人と協力することで
普段生活しているだけだと気付けない視点や経験を得られて大きな成長に繋がるはずです。
良い形でフィニッシュできるよう、カオスを楽しみながら前進させるしかありません。
これはある先輩が言っていたんですが、終わらないプロジェクトはないです。（色々な意味で）
Let's enjoy the project!!!!