とあるPJの立て直し: 設計について

　とあるプロジェクトの立て直しの記録に基づいて、プロジェクトマネジメントをテーマにシリーズで書き残したいと思います。今回は設計の課題について触れていきたいと思います。技術的な設計の側面とプロジェクトマネジメントの観点両面から考えます。

要旨

設計の状況

　本プロジェクトにおける設計の状況は以下のようなものでした。

　あなたがプロジェクトマネージャーやプロダクトオーナーである場合、設計そのものを担うことは稀かもしれません。しかし、「設計の必要性を理解」し活動として組み込むことは求められます。また、チームが「設計できる状態にあるかどうか」には、常に気を配る必要があります。

チームに必要な技能が足りているか

　設計のフェーズは大きくは、要求を機能として実現するための設計と、実際に実現するための設計である実装設計の二つに分けられます。それぞれで求められるスキルは異なります。

　実現したい内容によっても必要とされるスキルは異なります。サーバーを構築したことがない人にオンプレミスのサーバー設計は困難ですし、スタンドアローンなアプリ開発しか知らない人に大規模なアクセスのあるWebシステムの設計は困難です。

　まずはチームに設計に必要な技能が足りているかを確認しましょう。満たされていれば、きちんと設計の活動を行うことで立て直すことができます。もし足りない場合、チームに必要なスキルが不足していることをメンバーのせいにしても進みません。そうです。あなたのチームは「何ができて」「何を知らないか」を理解し、「不足しているものはなにか」を特定しなければいけません。

　プロダクト開発に限らず、スキルが欠如している状態でプロジェクトを遂行することの危険性は誰もが知るところでしょう。

増員か、育成か

　チームを組成する初期段階であれば、必要なスキルセットからメンバーを集めてチームを作ることができます。プロダクトが軌道に乗り始めて拡大する路線であれば増員もよいでしょう。しかし、採用や外注、派遣の活用はマッチングやタイミングの問題もあり、不確実性が高いです。

　そうしたときには、今いるチームメンバーが必要な技能を獲得すること、それができる組織体制であることが本質的な解決をもたらします。育成は常にプロジェクトの遂行とともにあります。

　また、今のチームが理想的なスキルセットであったとしても、プロダクトが成長していく中で求められるスキルは変化していきます。その乖離を見逃さないようにしましょう。ピーターの法則のように、適用できなくなるまで適用し続けることになります。

対策

　本プロジェクトでは、育成の観点を重視し、とにかく勉強会を開催しました。今いるメンバーに成長してもらうこと、できるようになってもらうことを期待して推進しました。具体的には設計をともに集まって行ったり、設計に関する勉強会を設けたり、コードレビューで設計の意義を話し合ったりしました。

永遠のものはない

　こうして成長したメンバーはチームからいなくなることも頭の片隅にはおいており、常に「ソフトウェア開発市場全体に貢献していく」つもりで人材を育成していました。エンゲージメントを高めて居続けてもらうことも大切ですが、メンバー一人一人のキャリアにとって何が最善かは一緒に考えるとよいでしょう。

　本PJが落ち着いてから後の話ですが、実際にチームを牽引していた主力のメンバーは別の会社、別のプロジェクトにて活躍しています。「転職を考えている」という段階から相談してもらえるよい関係性だったと思います。