ID:63644さん

大手生命保険会社の業務システム開発において、プロジェクトリーダーとして開発チームのタスク配分、優先順位・進捗・納期管理、設計方針の検討を担当。 メンバーの実装支援に加え、顧客・設計チーム・協力会社との調整や開発プロセスの改善を推進しました。

PoCから正式開発へ移行したプロジェクトで、仕様やドメイン知識が十分に整理されていない中でも、チームが必要な機能を適切な品質とスケジュールで実装できる状態を作ることが責務でした。 特に重視したのは、メンバーが不明点を抱えたまま実装を進めるのではなく、何が分かっていて、何が分かっていないのかを明確にし、適切な関係者と解決できる状態です。 開発側と顧客側の双方が課題や判断根拠を共有し、技術的な制約と業務上の要件を踏まえて、実装範囲や優先順位を決定できるチームを目指しました。

### 1. 開発が停滞する原因を、進捗ではなく情報共有の問題として捉えた **【課題】** スピードを重視したPoCから正式開発へ移行したものの、保険商品に関するドメイン知識が不足しており、設計書の作成と実装も並行して進んでいました。 仕様の不明点や考慮漏れの調査、再テストに工数がかかる一方、保険会社と複数の開発会社・BPの間では情報が分断され、スプリントが遅延する理由を十分に共有できていませんでした。 **【判断・取り組み】** 約3か月にわたり改善策を模索する中、保険会社のオフィスで開催されたスクラムサミットに参加。発注側も開発プロセスに課題を抱え、改善方法を模索していることを知りました。 そこで、個別の進捗確認を増やすよりも、関係者全員が課題を共有し、改善策を検討できる仕組みが必要だと考えました。 保険会社・開発チーム・BPを巻き込んだレトロスペクティブを提案し、導入を推進しました。 当初は議論ができず、具体的な改善策につながりにくかったため、AIによる課題の要約やブレイクアウトルームを取り入れるなど、進行方法も継続的に見直しました。 **【成果】** 従来は「なぜ開発が間に合わないのか」を顧客に理解してもらいにくい状況でしたが、仕様の不確実性やドメイン知識の不足、再テストに必要な工数を具体的に共有できるようになりました。 遅延という結果だけでなく、原因とリカバリ案を関係者で検討できるようになり、顧客との認識合わせが円滑になりました。 ### 2. 納期直前のAPI仕様問題に対し、実装範囲の判断を主導 **【課題】** 保険商品の判定処理に利用する外部ベンダーのAPI公開が納期直前となり、十分な検証時間を確保できない問題が発生しました。 入力パラメータと返却値の関係が明確ではなく、保険特有の判定条件も複雑だったため、APIを打鍵しながら一つずつ要件を確認する方法では、必要な開発を期限内に進めることが難しい状況でした。 **【判断・取り組み】** 実装を担当するメンバー2名に対し、打ち合わせ前に以下の情報を整理するよう依頼しました。 - **現在の実装状況：** どの条件分岐が実装済みで、どのような動作になっているか - **判明している仕様：** APIのパラメータと、把握できている判定条件 - **未解決の論点：** どのパラメータ・条件から業務上の判断が必要になるか そのうえで、私から顧客のドメインエキスパートに状況を説明し、4名で仕様を整理する場を提案・設定しました。 事前に技術的な論点を整理していたため、協議では単にAPIの動作を確認するのではなく、各判定条件が**どの業務工程で、どの商品に対して必要になるのか**を確認できました。 **【成果】** 協議の結果、一部の判定は後続工程でしか確定できず、また別の判定は今後開発する商品にしか必要ないことが判明しました。 これにより、当初想定していたすべての判定条件を一律に実装するのではなく、現時点で対象となる商品に必要な条件を明確にできました。 顧客に対しても、単に「開発が遅れている」と説明するのではなく、**現在の商品に必要な実装は完了しており、残る条件は後続工程・将来の商品に関わるものだと根拠を持って説明**できました。 ### 3. この経験で実践したマネジメント 今回の経験では、自分一人で仕様を解明したのではなく、実装を理解するメンバーと業務を理解する顧客が、それぞれの知識を持ち寄って判断できる状態を作ることに注力しました。 進捗管理だけにとどまらず、課題の整理、役割分担、関係者との合意形成を通じて、チームが必要な実装に集中できるようにしたことが、私自身のマネジメント経験です。

各府省向け文書管理システム開発において、参画約1か月後に4名チームのPLに抜擢されました。 メンバー3名の役割分担、進捗・品質管理、成果物レビュー、技術支援を担当。加えて、勉強会の企画、開発・レビュー手順の標準化、他拠点との業務調整を推進しました。

参画当初は、メンバーの役割分担や開発ルールが十分に整理されておらず、個人の能力や判断に依存して業務を進めている状態でした。 また、ドメイン知識のある1名を除き、私を含む3名はほぼ同時期に参画しており、チーム全体で業務理解を深める必要がありました。 PLとして求められたのは、単に進捗を管理することではなく、**メンバーの強みを活かした役割分担、知識共有、品質管理の仕組みを整備し、チームとして安定して開発できる状態を作ること**でした。 そのため、自チームだけで業務を抱え込まず、他拠点とも連携して課題を解決できる体制づくりを目指しました。

### 1. 開発体制が整っていない4名チームの立て直し **【課題】** 各府省向け文書管理システム開発に参画して約1か月後、4名チームのPLを任されました。 ドメイン知識が豊富な1名を除き、私を含む3名はほぼ同時期に参画しており、業務理解が十分ではありませんでした。 また、メンバーごとに技術力や得意分野、業務への取り組み方が異なる一方、役割分担や開発ルールが十分に整理されておらず、チームとして効率的に開発を進めにくい状況でした。 **【判断・取り組み】** まず、メンバーそれぞれの強みと課題を把握し、一律に業務を割り振るのではなく、互いの能力を補完できる体制づくりに取り組みました。 - **実装力のあるメンバー：** ドメイン知識を持つメンバーとペアで開発し、業務仕様と実装方法を相互に補完 - **ドメイン知識の豊富なメンバー：** 商品・業務仕様の理解を活かし、実装担当者との認識合わせを担う - **実装に支援が必要なメンバー：** テスト業務を中心に担当し、システムを操作することで業務理解を深める機会を設ける さらに、役割分担だけでは各自の知識が属人化すると考え、定期的な勉強会を企画しました。 ドメインに詳しいメンバーには業務仕様を、実装が得意なメンバーには設計意図や実装方法を説明してもらい、各自の専門性をチーム内で共有できるようにしました。 ### 2. 開発品質を個人任せにしないための標準化 **【課題】** 既存システムはオフショアで開発されており、仕様書やコードコメントが不足していました。また、マジックナンバーや意味の分かりにくい識別子が多数存在し、既存の実装を踏襲することで可読性や保守性の課題が繰り返されていました。 レビューにも統一された確認基準がなく、個人の経験に依存する状態でした。 **【判断・取り組み】** 個別のコード修正やレビュー指摘だけでは根本的な改善につながらないと考え、共通の開発ルールを整備しました。 - **業務用語・命名辞書：** Excelを用いて、日本語の業務用語から対応する関数名・変数名を取得できる仕組みを作成 - **PRセルフチェックテンプレート：** 命名辞書の利用やレビュー前の確認項目を明文化し、開発者自身がチェックできる手順を導入 これにより、個人の判断に依存していた命名やレビュー前確認について、チームで共通利用できる基準を整備しました。 ### 3. チームの枠を越えた業務調整 日常的にメンバーの作業状況を観察し、作業が停滞している兆候を早期に把握するよう努めました。 自チームだけでは対応が難しい場合は、豊田オフィスなど他拠点と調整し、業務分担や支援を依頼しました。 また、自身も進捗や担当範囲が不明確なチームの状況整理に入り、**自チーム単体ではなく、プロジェクト全体で開発を進められること**を重視しました。 ### 4. 成果 参画から約1か月でPLを任された当初は、メンバーの役割分担や開発ルールが十分に整っておらず、各自の経験や判断に依存する状態でした。 そこで、メンバーの強みを組み合わせた役割分担、定期的な勉強会による知識共有、命名辞書やPRセルフチェックテンプレートによる開発標準化を段階的に推進しました。 その結果、実装を担当していたメンバーが他チームの開発にも参画するなど、チーム内に閉じない役割分担が生まれました。また、自身も他拠点の進捗整理や業務調整を担い、プロジェクト全体で開発を進められるよう働きかけました。 **こうしたチーム運営の改善を進めながら、約1年間のウォーターフォール開発における担当工程を完了しました。** その後、年度の切り替わりに伴い、生命保険会社の業務システム開発案件へ異動しました。