炎上プロジェクトに途中参加したことはあるでしょうか？
プロジェクトメンバーとして増員メンバーとして声がかかり、炎上プロジェクトの支援にはいった経験がある人も少なくないと思います。
そういった際にどう立ち回ればよいかについて解説します。
私自身はこれまで４度、炎上プロジェクトに支援メンバーとして途中参加したことがあります。その経験から、今回はプロジェクトメンバーとして参画した時に心がけるべきことを紹介します。
プロジェクトマネージャーなどリーダーポジションで参画する場合とはまた違う振る舞いが求められるため、ぜひ最後までご覧ください。
プロジェクトに途中参加する時に心がけること
炎上プロジェクトに途中参加した際にプロジェクトマネージャーやチームリーダなどの管理者から求められることは「早く立ち上がってほしい」ということです。
どんなに優秀なエンジニアであっても途中参加したその日から戦力になることはありえません。プロジェクトの全体像を理解し、システム概要を理解し、プロジェクトの特性を理解し、プロジェクトメンバーのことを知って初めて戦力になります。
プロジェクトマネージャーは途中参加した要員がどれくらい戦力になっているかを監視していくため、「この人は戦力になっているか、生産性が出ているか」と評価されます。
では、早く立ち上がるためにはどうすればよいかを中心に解説します。
特に今回は詳細設計、製造工程、単体テスト工程といった広く開発工程と言われる工程に途中参加した場合を想定したいと思います。
論理DB設計を理解する
まず１つ目は、論理DB設計を理解するということです。
プロジェクトメンバーに求められることは、一日でも早く開発中のシステムの全体像を理解することです。そのためは、論理データベースモデルを理解すること有効です。
論理データベースモデルはシステムの静的ビジネスルールを表しているともいうことができ、論理データベースモデルを理解することで開発中のシステムの全体像を理解することができます。
全体像を理解するということであれば概念データモデルも有効です。しかし、炎上プロジェクトはだいたい概念データモデルがないことも多いです。また、概念データモデルだけでは、実際の開発作業（製造、単体テスト）をするには情報が足りません。
受注と受注明細、商品マスタや取引先マスタといった各種データベースがどのような関係になっているかを理解します。静的ビジネスルールを理解することが出来れば、自ずとビジネスロジック（機能）の理解も進みます。なぜなら、静的ビジネスルールを保つためにビジネスロジックは組まれているためです。
そのために、論理データベースモデルの理解を優先し、それと合わせれビジネスロジックの理解も進めると非常に理解が進むと思います。
聞ける人を見つける
２つ目は聞ける人を探すことです。
冒頭にも触れた通り、どんなに優秀であってもその日から戦力になることはありません。したがって、プロジェクトに参画したその人から早速プロジェクトの情報を収集する必要があります。
その際、既に作成されているドキュメントを読むことは勿論必要です。
しかし、炎上しているプロジェクトの場合、だいたい作成されているドキュメントの品質が低いことが多いです。（ドキュメント品質が高ければそもそも炎上しません。）
そのため、炎上プロジェクトのドキュメントには、書かれていない情報がたくさんあると言ってよいでしょう。例えば、既に仕様変更がされた内容がそのまま残っていたり、もう使わなくなった機能がまだそのまま残っていたりなど、最新の状態になっていないことが多いです。
また、ドキュメントを読むだけではキャッチアップに時間がかかってしまいます。
そこで、聞ける人を探してその人に頼ってください。
決して中心メンバーでなくても問題ありません。聞きやすい人を探し、ある程度の情報を抑えている人であればまずは問題ありません。そのあと、徐々に中心メンバーに接近すればよいです。
ただし、注意点としては、闇雲に質問してはいけません。質問する際は、仮説思考で自分の意見をもったうえで質問するようにしましょう。質問の仕方、仮説思考についてはこちらの本にも記載されている通り、社会人としての基本ですので、実践していきましょう。
気づいたことは声に出す
3つ目は、気づいたことを声に出すことです。
徐々に慣れてきたら、気づいたことはチームリーダやプロジェクトマネージャーに伝えるようにしてください。炎上プロジェクトに途中参加した立場だからこそ見える景色があります。資料の矛盾点、仕様バグなどです。
これには２つの効果があります。
１つ目の効果は、途中参加したことによる成果を見えることです。冒頭にも触れた通り、プロジェクトマネージャーは途中参加した要員の生産性など成果を監視しています。そのため、途中参加した立場であってもプロジェクトに対して貢献できていることを示すことが非常に重要です。
２つ目の効果は、自分から声を上げることで更に情報が集まってくることです。受動的に与えられた仕事をこなすのではなく、自ら疑問を持ち、その疑問の解消に向けて能動的に動くことで、単なる疑問から様々な情報を得ることができます。また、その中で新たな人脈も広がり、更に質問がしやすい環境を作ることができます。
ただし、注意点として、押し売りは厳禁です。「前のプロジェクトではこうやってた」といったようにあたかも今のプロジェクトを否定するような動きはよくありません。反感を買うだけです。プロジェクトマネージャーなど管理メンバーとして途中参加した場合に限ってはその裁量の中で従来のやり方を変えることもできますが、それでも非常に慎重さが求められます。そのため、プロジェクトメンバーであればあくまで謙虚に声をあげることが重要です。
番外編：日記を書く
最後に番外編です。
早く立ち上がるために必要というわけではありませんが、炎上プロジェクトに参加したら日記を書くことをお勧めします。
炎上プロジェクトに途中参加するということはいいチャンスです。炎上プロジェクトでしか経験することができないことがたくさんあります。ある意味、途中参加ということは炎上している状態について責任を感じなくて済みます。そのため、今回の経験している炎上プロジェクトを反面教師にして、平時のプロジェクトに戻った際に、炎上しないためにはどうしたらよいかのヒントにすることができます。
炎上プロジェクトには炎上プロジェクトなりの原因、例えば、ドキュメント品質が悪い、指揮命令系統が悪い、アーキテクチャが悪いなど、挙げればきりがありません。そういった原因を学ぶことができます。勿論それだけではなく、炎上プロジェクトを経験することで自分がどこまでのストレス耐性があるかも経験することができます。限界まで働くことは人生の中で１度や２度あってもよいと思います。
こうした経験を日記に留めておくことはいつか自分のために必ずなると思いますので、日記を書くことを強くおすすめしたいと思います。
最後に
炎上プロジェクトに参加した時は”チャンス”だと思ってみてください。大変なこと、苦しいことの方が多いと思いますが、そういう時こそ成長するいい機会です。
ぜひ頑張ってみてください。
マネジメント目線で炎上プロジェクトに参加するという方はぜひこちらの本がおすすめです。
マネジメントだけではなく、メンバー目線でも学びが多いのでお手に取ってみると良いと思います。
コメント