役割は組織の規模によって変わってくる。これは個人的な見解だが、おおよそ次にようになるのではないだろうか。
- 10人程度の開発組織：役割などはなく全員が何でも拾ってサポートし合いながら動く形
- 30人近くになると：プロダクトマネージャーやプロジェクトマネージャーといった担当者がいることで、業務がスムーズに進みやすくなる
- 50人を超えると：組織をまとめるマネージャーが複数人必要になってくる
- 100人規模になると：より専門的な役割が求められるようになる
ここでは50人から100人規模の組織を思い浮かべて、開発チーム内に次のような役割を想定する。
- プロダクトマネージャー
- デザイナー
- エンジニア
- プロジェクトマネージャー
これらの役割が存在するチームでどのように「開発チームがやること」を進めるのか、今度は役割を中心に見ていこう。
（1）プロダクトディスカバリー
プロダクトディスカバリーは、プロダクトマネージャーとデザイナーが中心になって進め、最終的な意思決定はプロダクトマネージャーが担う。
プロダクトマネージャーはプロダクトや事業領域の専門家としてディスカバリーを主導する。デザイナーはユーザーやデザインの専門家として、ユーザーインタビューや調査、プロトタイプの作成などをとおしてデザインを具体化していく。
プロダクトディスカバリーの段階でも、エンジニアの意見やサポートがあると効果的な場合が多い。たとえば、いくつか案があるときに実装の難しさを考慮したい場合や、実際のプロダクトに手を入れて動くプロトタイプで確認したい場合などだ。
そのため、エンジニアから代表で1名がディスカバリーに参加する。この後の方針に大きく影響を与える役割なので、チームのエンジニアを代表するスキルが必要だ。今のチームではどのメンバーもチームを代表するスキルを持っているため、案件ごとにリードエンジニアを決めている。
プロダクトマネージャーやデザイナーが何か相談したい場合には、いつでもそのエンジニアに声をかけていい、という仕組みにしている。この仕組みによって、プロダクトマネージャーやデザイナーは小さなことも気軽に相談できるし、他のエンジニアは目の前のイテレーションに集中できる。
このようにプロダクトディスカバリーは、プロダクトマネージャーを中心に、デザイナーやリードエンジニアの専門知識を活かしながら進める。
（2）設計
ディスカバリーが落ち着いてくると、リードエンジニアが中心となって要求仕様や画面のデザイン案をもとに設計へ取りかかる。設計の過程で新たな気付きがあれば、それをプロダクトマネージャーやデザイナーにフィードバックし、一緒に仕様やデザインをブラッシュアップしながら設計を進めていく。
リードエンジニアは日次で他のエンジニアに設計の状況を共有する。もし体調を崩してお休みになってしまっても、他のエンジニアがそのまま続きを進められる状態がいい。情報を共有することで他のエンジニアからフィードバックをもらい、それを設計に反映していく。
設計を進める中で1周目の実装をして技術的な不確実性を減らしておくのもリードエンジニアの大きな役割だ。また、その1周目の実装をプロダクトマネージャーやデザイナーに見せて、仕様面での認識もそろえていく。
このように、設計はリードエンジニアが中心となり、プロダクトマネージャーやデザイナーと一緒に仕様やデザインの細かな部分を決めながら開発準備を整えていく。この段階で仕様が8割程度、設計が6割程度できていれば十分である。
（3）開発（設計・実装・テスト・リリース）
設計が終わると開発に入る。ここが開発チームの中心だ。
リードエンジニアがすでに設計を共有してくれているので、エンジニア全員ですばやく実装をカタチにしていく。1周目の実装を参考にはするが、それをそのまま使うよりは、参考までにとどめておいて別途実装を進める形が多い。1周目では書かなかったが、2周目では自動テストを書きながら丁寧に本番レベルの実装を進める。
詳細な実装を進めていく中で、仕様やデザインに関して気になることが出てくる場合もまだあるので、プロダクトマネージャーやデザイナーは、エンジニアから呼ばれたらすぐに動けるようにしている。
エンジニアは、そのチームの担当する開発に対して、必要なスキルをチームとして満たしている必要がある。たとえば今の僕のチームだと、フロントエンドからバックエンドまで全体を1つのチームで見ている。そして、フロントエンドに強いメンバーがいたり、バックエンドに強いメンバーがいたりして全体がカバーされている。自分の得意分野以外の開発でも、そこが得意なメンバーのサポートを受けながら手を動かす。
自分たちでカバーできない部分に関しては、社内のスペシャリストにサポートしてもらう。全社的なアーキテクチャや、AWSの細かな部分、テストについては社内のスペシャリストたちにアドバイスをもらって開発を進めている。
実装が終わったら、プロダクトマネージャーは仕様視点での受け入れチェックを実施し、デザイナーはデザイン面での受け入れチェックを実施する。エンジニアは品質を保証するためのテストを実施する。
そのテスト項目は仕様を元に書き起こされているのでプロダクトマネージャーも内容をチェックしている。ときにはプロダクトマネージャーもテストに参加する。また、実装者以外の視点を入れるため、このテストの設計や実施は実装者以外のメンバーが中心となって進めるようにしている。
（4）運用
開発と並行して常に運用は動いている。定期的な運用タスクや日付の決まったタスクはプロジェクトマネージャーがタスク管理ツールなどに登録して、漏れないようにしておく。
問い合わせなどの窓口もプロジェクトマネージャーが担当する。受け取った問い合わせの詳細を確認して、プロダクトや仕様に関することであればプロダクトマネージャーに、技術的な調査などに関わることであればエンジニアにルーティングする。
即時の対応が不要で、次のイテレーションでも大丈夫な場合はデイリープランニングでそのことを共有して次のイテレーションのタスクとして置いておけばいい。
突発対応が頻繁に発生するようなプロダクトの場合は、そのイテレーションで運用を担当するエンジニアを決めておくと他のメンバーが開発に集中しやすい状態となる。ただ、その場合は情報の分断や負担の偏りに気を付ける必要がある。
ここでプロジェクトマネージャーが担当するのは、意思決定や問題の解決ではない。それはプロダクトマネージャーやエンジニアが担当する。たとえば、インシデントが発生した場合の意思決定はプロダクトマネージャーが担い、その調査やシステム的な対応はエンジニアが担当する。
プロジェクトマネージャーが担当するのは、情報を整理して適切なルーティングを行うことで、チームが今やるべきことに集中しやすい環境を整えることだ。そのためには、チーム内外の必要な場所に必要なタイミングで適切に情報を共有する必要がある。
（5）検証
リリースした機能の効果検証は、プロダクトマネージャーが中心になって、デザイナーと一緒に実施する。立てた仮説に対して、どのようにユーザーが反応しているかなどを数字でチェックする。また、ユーザーインタビューなどで実際の声を聞いたりもする。
ここで得た情報を元にして、次のディスカバリーへ進む。
TODO: 絵を描きたい