はじめに
約1年半かけて大規模な4システムを並行開発しました。役割としてはチームリーダーでしたが、その時にやったことを簡単にまとめます。
※並行開発といっても、スケジュール感の実態は各システムの開発開始と終了が被っている形です。
概要
- アーキテクチャ：4システムとも同じアーキテクチャ
- チームの人数：10人～15人
- 開発フェーズ：設計～実装～UT（要件定義までは完了している）
- メンバー特性：要件定義を行ったメンバーは1～2人
- その他：システム毎に担当するメンバーを割り振る（多くても1人2システム担当）
やったこと
チームの中で必要となる役割を明確にしておく
10人～15人に対してリーダー1人の体制はとてもじゃないですが回りません。
そのため、各システム毎にサブリーダー的な役割を定義し裁量を渡し、判断に困った時だけ相談してもらう、という形をとることでリーダーがいなくても自然と回るような形を目指しました。
これは割とうまく回ったと思っていて、自分がいなければ何も進まない、ということはあまりありませんでした。
まずは1システム作りきり振り返る
ベースとなるアーキテクチャは決まっていたので、それを実装に落とし込んでとりあえず1システム作りきることを目指しました。
ここではかなり紆余曲折がありましたが、最初なのでそれは仕方ないことだったのかなと思います。
大事なのは1システム作りきったあとは、振り返りをしっかり行いその時の反省点をもとに次に作るシステムがより円滑に進むよう改善することです。
次に作るシステムはファストトラッキングして実装がよりスムーズに進む段取りを
要件定義が終わっていても、設計、実装段階で要件、仕様を確認するケースは多々あります。最初の3システムは、実装中に要件、仕様を確認しなければならないケースが多々あり、そのための確認コスト（コミュニケーションコスト）やそれに付随する仕様変更対応でかなりのコストがかかりました。
そのため、4システム目はファストトラッキングで、要件定義ドキュメントを読み込み、要件、仕様の曖昧な所を洗い出し、実装の本格着手が始まる前に全て整理しておくことを実践しました。そのおかげで、他の3システムに比べて設計、実装段階でのコミュニケーションコストが圧倒的に下がり、開発終了までのスピードがかなり早かったと思います（そもそも4システム目で初めてその改善をすること自体が遅いのですが）。
他には、設定ファイルやメッセージ系のファイル、共通部品系はポーティングして使い回しが可能だったため、そのあたりの整備を最初に行うことで、後から合流してくるメンバーは自身の担当機能のみに注力できるような形を作る、といったことを実践しました。
3か月ごとの要員計画
実装と並行して、（完成している機能から順に）結合テストもテストチームによって進められていました（フェーズが重なっていることはいったん置いておきます）。こうした背景から、実装以外に障害対応担当者の割り振り、障害対応といったタスクも発生しました。また、担当しているシステムの実装が終わったら次のシステムの実装を、、、といった具合に、メンバーが流動的に動けるような体制を取る必要がありました（そうしないとカオスな状況になるためです）。そのため、3か月ごとに要員計画を行い、誰がどのタイミングで何をやっているかを、明確にし共有することでチーム内のカオスな状況を防ぐことを目指しました。
さいごに
こういったシステム開発のリーダー経験はほとんどありませんでしたが、個人的には以下が結構重要なのでは？と感じることができました。
- 流動性が求められるものほど流動性をより高めるために、やらなければならないこと、担当者、対応期間、を整理し常に問題があった時の対応方法を考えておく
- ファストトラッキングで何をやるかでその後の良し悪しが変わってくるので、タスクは慎重に検討する
以上です。