アジャイルチームの開発マネジメント実践：リリース、協働、成長

2026 年 9 月の時点で、私を除くチームメンバーは 9 人で、開発 7 人、IT 2 人です。開発にはフルスタック、Flutter によるモバイル開発、テスト、Agent、運用の担当があり、フルスタックのインターンもいます。経験も、関心も、関わる案件も一様ではありません。

同時に複数の製品を進めています。業務フローを整える人、決済や認可を実装する人、Agent を構築する人、デプロイや品質を支える人がいます。各自の作業は進められても、API の依存、業務の理解、公開条件は一緒に確認する必要があります。

責任者が一人ずつ進捗を尋ねる方法への依存を減らし、成果、停滞、優先順位を共通に理解できるようにしたいと考えています。同時に、新人の学習と個人の対話にも場を用意します。そのため、要求の絞り込み、案件の調整、内部のイテレーション、成果物管理、評価目標、育成を、それぞれに適した手順でつなげています。

この記事では要求分析、実際の会議、評価計画、開発規約、指導の経験をもとに、各取り組みの進め方と問題に応じた調整を説明します。レビューのテンプレート、合意した設計、実際の開発成果は、それぞれ区別して考える必要があります。

1. 案件の調整：進捗、着手条件、公開条件を明確にする

案件会議で業務担当者に確認したいことと、内部の実装上の意見の違いは、必ずしも同じではありません。担当業務への個人的な気持ちも、全員の前で説明してもらう内容とは限りません。

そのため、役割の異なる場を設けています。

対象と成果物はそれぞれ異なります。同じ進捗を複数の場で読み上げるようになったら、事前に読める情報と、対話が必要な内容を見直す必要があります。

各段階で答える問いを決める

LAIFE AI の案件では、三種類の会議を設計しています。週次会議の記録は継続的な進行を示し、要求とリリースのレビューテンプレートは各段階で確認する内容を定めています。

案件会議では、フェーズ目標、今週の完了、リスクと停滞、要求変更、決定事項、会後の Action を記録します。プロダクト、開発、アルゴリズムまたは Agent、テストの担当がそれぞれ報告しますが、目的は全員の作業を列挙することではありません。製品が目標へ進んでいるかを確認することです。

要求レビューのテンプレートは「着手できるか」を軸にしています。目的、対象、解決することとしないこと、今回の範囲、利用者と異常時の流れ、データと API、AI の入出力、受け入れ基準、依存、リスク、見積もりの確認を求めます。補足事項と着手可否の欄を設け、重要な情報が不足していれば補足後に再レビューできる形です。

リリースレビューのテンプレートは「公開できるか」を軸にしています。公開する範囲と延期する範囲を分け、フロントエンド、バックエンド、アルゴリズムまたは AI、テスト、本番設定、DB 変更、旧バージョンとの互換性、顧客への通知を確認します。アルゴリズムの稼働、出力の検証、主要経路の回帰はそれぞれ確認すべき事項です。最後に公開の可否と条件を記録します。

この設計は、進捗、着手に必要な情報、公開の根拠を分けます。テンプレートは共通の確認範囲を示しますが、実行と課題のフォローは具体的な記録で確かめる必要があります。

実際の記録では、プロダクト、バックエンドと Web、モバイル、アルゴリズム、テストの進捗を分け、コンプライアンス、移行、モデルのフォールバック、負荷試験、P0/P1 の不具合、判断事項も別に残します。議事録を長くすることが目的ではなく、各役割が見るべき情報を明確にし、未完了の Action が次回に応答されるようにするためです。

業務調査から初期リリースの範囲へ：診療所案件の要求整理

LaTipSoh 診療所管理システムの要求分析は、具体的な事例です。受付、予約、診察、検査報告、健康介入計画、商品セット、紹介元の管理などが関わります。各担当の機能要望から直接開発を始めると、初期リリースが診療、CRM、EC、紹介手数料の精算を組み合わせたシステムに膨らみかねません。

まず複数回の要求ヒアリング、院内の受付 SOP、業務側が想定する流れから主要プロセスを整理し、未確定事項を確認リストにしました。対話が進むたびに、決定したことと未決事項、それらがプロトタイプ、権限、データ、日程に与える影響を記録しました。

機能を広げる前に業務の境界を決める

初期リリースの範囲は、顧客向け WeChat ミニプログラムと内部管理画面に絞りました。パートナー専用画面、RFM による自動分類、自動フォロー、会員ポイント、AI による診療記録入力、報告書の自動解析は延期し、必要に応じて拡張の余地を残します。

紹介手数料の精算は典型的な判断でした。顧客の流入元、帰属するパートナー、注文の支払いとサービス利用の状態は必要ですが、初期段階で自動手数料分配、出金、資金分割まで担う必要はありません。システムは精算根拠と手数料の参考データを記録し、最終精算は既存の経理業務で行うことにしました。現在の業務を支えつつ、資金処理の責任範囲を明確にできます。

検査報告の扱いも変化しました。当初は検査値を一項目ずつ手入力する案がありましたが、後の合意では報告ファイルのアップロード、状態、メタデータを優先しました。検査値の明細、OCR・AI 解析、人による確認は将来の拡張とします。担当者の作業、画面、開発範囲に影響するため、関連する合意も一緒に更新する必要があります。

役割ごとの要望を具体的なルールにする

役割一覧だけでは参加者しか分かりません。実装に必要なのは、誰が何を閲覧・変更でき、操作後にどの記録を残すかです。メニュー構造、役割と権限のマトリクス、機能要求一覧へ整理し、データ範囲と操作を組み合わせて境界を定めました。

例えば、営業・マーケティング担当は予約の作成、自分の見込み客と担当顧客の閲覧ができますが、関係のない院内運営や財務情報にはアクセスできません。健康相談担当による予約変更には受付または管理者の確認が必要です。現場で接客する人が変わっても、顧客の当初の帰属は上書きしません。これらは API 認可、項目の更新、操作履歴に直接関わります。

勤務予定と診療記録にも制約があります。予約は公開済みの予定から選び、現段階では自動割り当てを行いません。アーカイブ済みの予定は変更できず、署名・公開後の診療記録の修正には版と操作履歴を残します。状態と操作条件を明確にすることで、プロトタイプの背後にある業務ルールも具体化できます。

要求の結論を設計と日程の入力にする

共通機能についても判断します。アカウント、基本的なユーザー情報、ファイル、SMS、電子署名は既存システムの能力を優先して再利用し、業務データへのアクセス範囲を明確にします。サーバー、ミニプログラムの認証、ドメインなどの費用も検討しました。優先度の高い別案件に問題が発生した場合には、現在の日程も再調整する必要があります。

要求分析ではメニュー構造、権限マトリクス、機能一覧、プロトタイプの確認記録を作成し、その後のテーブル構造、状態遷移、API、開発日程への入力としました。この経験が示すのは、対話を重ねて実行できる合意を作る過程です。実際の利用に適合するかは、開発、テスト、試験運用を通して確かめる必要があります。

バックエンドとアルゴリズムをまたぐ問題：移行したメッセージが AI に使われない

過去データの移行テストで、以前の会話で利用者が伝えた情報を、新版の AI が回答に正しく使わない現象がありました。案件定例に持ち込み、バックエンドとアルゴリズムの担当が共同で確認する課題としました。

調査記録では、知識利用の対象を示すフラグがバックエンドの移行で欠落していたことが確認されています。メッセージの移行と、その情報がアルゴリズムの利用経路に入ることは、個別に検証する必要がありました。データが存在するだけでは、再質問への回答が正しいかまでは分かりません。

記録に残した次の作業は二つです。本番移行時にフラグの欠落を修正し、フラグを補えば正常に利用できるかをアルゴリズム側に確認することです。一方は移行ロジック、もう一方はデータ利用の約束と条件を扱い、それぞれが自分の作業を完了と見なして終わることを避けます。

案件会議で実現したいのは、このように役割をまたぐ異常を検証可能な問いに分け、誰の応答が必要かを明確にすることです。当時の記録は原因の確認と追加検証の予定までで、最終的な検証完了は記録されていません。

2. 内部のイテレーション：動く成果から翌週の優先順位へ

会議の 30 分前に、その週の完了内容と翌週の Top3 タスクを記入してもらいます。会議で共有する記録になり、後からも参照できます。同じ内容の週報を別に書く負担をできるだけ減らすためです。

進行は、成果デモ、ボード確認、短い振り返り、翌週の計画の順です。まず実際の結果を見てから、状態と次の段取りを話したいと考えています。

デモで理解の違いを早く見つける

画面を共有し、完了して実行可能なコードや製品を見せ、その場で質問とフィードバックを受けます。

機能が期待に合うかは、実際の流れをたどって初めて分かることがあります。画面が開くだけでは利用者が目的を果たせるとは限りません。API が成功しても、異常時の状態、権限の境界、その後の操作が妥当とは限りません。

デモは、内部のアイデア交換に共通の対象を与えます。テスト担当は利用経路から、ほかの開発者はモジュールをまたぐ影響から質問できます。私は設計のずれを確認し、判断の理由を説明できます。具体的な成果があると、機能への共通理解を作りやすくなります。

揃えたいのは業務目標、制約、受け入れ基準です。実装方法には異なる意見があってよく、異議を述べる余地も必要です。

ボードは短く確認し、複雑な話は別に行う

デモの後はボードを確認し、タスクの状態、停滞、必要な支援やリソースを見ます。

関係者が二、三人だけなら、全員の場で実装を掘り下げません。何が止まり、何に影響し、誰が必要かを共有してから、別の場で続けます。依存関係はチームに伝えつつ、関係の薄い議論に全員の時間を使わないためです。

ボードの状態は実際の成果と対応する必要もあります。「開発中」「テスト待ち」「完了」の意味が人によって違えば、頻繁にカードを動かしても進捗は分かりません。動くデモとテストのフィードバックが、状態を判断する具体的な根拠になります。

振り返りと計画は簡潔にする

振り返りには KISS を使います。Keep、Improve、Start、Stop として、続けること、改善すること、始めること、やめることを話します。

重視するのは、次に試せる調整につながるかです。依存が遅れて分かったなら、タスク分解に問題があったのか、必要な参加者が欠けていたのか。「コミュニケーションを強化する」と毎週繰り返すだけでは、十分な助けになりません。

最後に翌週の目標と各自の Top3 を確認します。優先順位を示しつつ、具体的な作業への分解は本人に委ねます。新人ガイドでも、大きな単位で仕事を渡し、開発者が自分で分解する方針を示しています。目標は明確に、実施には判断の余地を残したいからです。

Top3 は全業務量の一覧ではありません。テスト、運用、IT 支援には、突発障害や相談による割り込みがあります。その投入も見える必要があります。優先順位が変わったら以前の約束も見直し、仕事だけ増やして旧計画をそのまま維持しないようにする必要があります。

成果を記録し、リスクも残す

記録では、今週の成果を製品ごとに、翌週の Top3 をメンバーごとに整理します。前者は製品の変化を、後者は次の担当を理解する助けになります。

表現はリリースノートに近づけたいと考えています。モジュール、できること、結果を書きます。「決済 API を調べた」より「注文モジュールに決済コールバックと状態遷移を実装した」のほうが、ほかの人にも進展が伝わります。

一方、探索自体が仕事の場合もあります。結果重視だからといって、検証中の案を実装済みの機能として書いてはいけません。何を候補から外し、何を検証し、何が未確定かを説明できます。

小さな不具合や通常の操作性改善はまとめ、細部で会議が埋まるのを避けます。ただし、データの正しさ、安全性、安定性、リリース計画に関わる問題は個別に示す必要があります。集約は情報を理解しやすくするためであり、リスクを隠すためではありません。

3. 開発成果の受け渡し：社内ビルドと成果物管理

マージしたコードは、その後のデプロイに使える成果物にする必要があります。ソース管理、継続的インテグレーション、成果物管理を社内に構築し、日常の開発を共通の自動化された流れに乗せています。

開発が終わると、コードを社内運用の GitLab にプッシュします。ブランチのマージ手続きで AI コードレビューが自動実行され、マージ完了後に社内の TeamCity がビルドパイプラインを実行し、生成した成果物を Nexus リポジトリへ送ります。

開発完了 → GitLab へプッシュ → マージ手続きで AI レビュー
         → マージ完了 → TeamCity でビルド → Nexus 成果物リポジトリ

社内管理の対象には、Docker イメージ、npm パッケージ、Maven の依存関係と成果物、フロントエンドの Dist ビルド成果物、OSS オブジェクトストレージも含まれます。それぞれに適したリポジトリやストレージを使い、Nexus は成果物管理、OSS はオブジェクト保存を担います。ここでいう社内運用とは、開発者個人の PC だけに保存することではなく、企業の内部環境で運用することです。

コード、ビルド、成果物のつながりが明確になり、手作業のパッケージ作成やファイル受け渡しへの依存を減らせます。新人も最初のマージリクエストから同じ経路をたどり、自分の変更が成果物になる流れを理解できます。

AI レビューは補助的な確認です。詳しく調べるべき点を見つける助けになりますが、業務ルール、権限の境界、変更の影響は開発者が判断します。ビルド成功もテストやリリースレビューの代わりにはなりません。反復的な処理はツールが実行し、公開の条件を満たすかは各確認段階で判断します。

4. 評価と目標：成果、品質、協働を見えるようにする

定例とボードは、目の前の優先事項を決める助けになります。四半期目標では、限られた人員をどの案件へ配分し、どのような結果を評価し、各役割が何を担うかを説明する必要があります。

評価計画では部門の案件目標を個人へ分解し、重点、重み、主要な成果、優先順位で期待を記述しています。重みは評価に占める比重、優先順位はリソースが競合した際の判断を表します。決済や安定性の業務は、通常の投入が少なくても、問題発生時には優先対応が必要になり得ます。

役割に応じて貢献を定義し、再利用できる知識も評価する

開発目標は機能、API、データ構造、結合確認に加え、公開品質と保守も含みます。テストは主要経路、異常系、受け入れ記録、不具合の振り返りを重視します。運用と IT は公開、ロールバック、監視、権限、資産、利用者支援などを担います。共通の成果に向かいつつ、評価の根拠はそれぞれの責任に対応させます。

将来の開発を支える仕事にも位置を与えています。入社期には業務の流れ、API とデータ構造の文書化、自己テスト、レビューを目標に含めます。指導担当にはインターンの課題分解、コード確認、重要な問題の記録を含めます。他者の仕事を助け、後の保守負担を減らすことも評価すべき投入です。

機能の利用可否はデモと受け入れ、結合の完了は異常系と課題記録、指導は課題とコードへのフィードバックなど、確認できる材料に結びつけたいと考えています。文書数は最低限の目安になりますが、役立っているかには具体的な判断が必要です。

外部依存と要求変更も合意に含める

成果の一部は業務担当、ハードウェア、別チームに依存し、個人では完全に制御できません。計画には要求変更後の範囲調整を残し、ハードウェア連携が停滞した場合の代替受け入れ条件も設けています。合意した条件のもとで Mock 環境による流れの検証を完了すれば、その課題の達成根拠とできます。

Mock 検証には限界があり、実機の互換性や異常時の動作は後の結合確認が必要です。評価では、本人が完了した責任、整っていない外部条件、残る作業を分け、依存先を待っているだけで未達成と見なさないようにする必要があります。

指標の定義と行動への影響を見直す

現在の計画には完了率、応答率、不具合の重大度、カバレッジなどがあります。ただし割合を書くだけでは十分ではありません。分母に含める課題、基準となる要求の版、観測期間、確認者の定義を揃え、重みと評価段階も正式合意前に点検する必要があります。

事故ゼロ、資金損失ゼロは品質への期待を表します。個人評価では原因の帰属、主体的な発見、速やかな報告、対応の過程も考え、リスクを早く共有できるようにする必要があります。前倒しの納品も品質と見積もりの妥当性を併せて判断し、余裕の大きな見積もりで高評価を得る動機を生まないようにします。

この計画も実施後のフィードバックで調整する必要があります。目標表は奨励したい仕事を示しますが、公平さと協働への効果は、実際の対話、根拠、メンバーの声から判断します。

5. メンバーの成長：入社、学習、個人の対話

新人ガイドで協働の方法を参照可能にする

口頭説明だけでは、新しく入った人が全体を理解するのは難しくなります。新人ガイドには、業務とアーキテクチャの全景、ツール、技術選定、コミット規約、ブランチ運用、定例、勉強会をまとめています。

最初の週には具体的な目標を置きます。アカウントと環境を整え、開発規約を知り、ローカルでプロジェクトを動かし、初めての機能または不具合タスクを受け取り、標準的なマージリクエストまで経験してもらいます。

目的は実際のリリース経路を早く一巡することです。コードの場所、問題の記録場所、変更の提出方法、マージ後に環境へ届く流れを知るほうが、ツール名を覚えるより役立ちます。

その中には開発規約もあります。Conventional Commits、開発・本番ブランチをマージリクエストと CI/CD でつなぐ流れが、個人の実装とチームのリリースの間に共通の約束を与えます。

新人やインターンには、開発規約への適応、学習、コード品質を重視し、短期の節目で参加を支えます。業務上の責任とともに、支援と期待もその人の段階に合わせる必要があります。

勉強会では説明と質疑を両方重視する

理論と実践を常に同じ速度で伸ばすのは難しいものです。忙しい時期には、機能を作れるようになっても仕組みを理解する時間が足りなくなります。新人は授業の概念を知っていても、実際のコードに結びつけられないことがあります。

そこで、コンピューターシステムの理解と技術説明の訓練を目的に、週一回の勉強会を設けました。当初は中国のソフトウェア資格試験における上級システムアーキテクトのカリキュラムを軸に、章、回、授業へ分け、計算機構成、OS、ネットワーク、DB、要求工学、ソフトウェアプロセスなどを扱いました。

2026 年 8 月には内容要件を変え、技術テーマを柔軟に選べるようにしました。フレームワーク、ミドルウェア、AI、テスト、DevOps、安全性、新技術などを扱えますが、題目は具体的にします。実際の案件や既習の基礎との接続も勧めています。

「データベース」では広すぎますが、「一つのリクエストを端から端まで追う遅延調査」なら問題と範囲が明確です。大規模モデルの進化や Harness Engineering も取り上げ、体系的な学習を現在の仕事と結びつけています。

発表前に準備する

現在は水曜の終業までにスライド初稿を共有し、木曜に事前レビューと修正、金曜午前に一時間の会を開きます。約 40 分が説明、20 分が質疑です。

スライドは 8 ページ程度で、構造図、フロー、事例、本人の解釈を含め、長文の詰め込みを避けます。参加者も最低一つ質問を用意し、考えながら聞くようにします。

準備とレビューで、テーマが広すぎる、概念間に飛躍がある、事例が主張を裏づけていない、といった点を先に見つけられます。本番では具体的な内容への質問を深められます。

AI は補助に使い、理解は本人が担う

AI の利用は認めていますが、発表者は内容を理解する必要があります。技術をソフトウェア全体の中に位置づけ、解決する問題、向く場面と向かない場面、案件での使い方やよくある問題を説明してほしいと考えています。

「10 分間の質問にも答えられる」は理解の深さへの期待です。質疑は発表者を困らせる試験にすべきではありません。不明確な点を見つけ、全員でさらに考えるためのものです。

AI で情報取得とコード生成は容易になりました。それでも、システムの原理、業務の状況、設計品質への判断には経験が必要です。その蓄積のために、安定した場を設けたいと考えています。

1on1 では個人の声を聞く

全体会議ではタスクと成果は見えても、一人ひとりの本当の考えまでは分からないことがあります。そこで隔週で約 30 分ずつ個別に話し、仕事への考えを聞いています。

仕事の困難、担当への感じ方、挑戦したい方向、必要な支援などを話せる時間だと考えています。何を話すかには本人の意向を反映する余地が必要です。

もう一度進捗確認をするだけでは、全体会議以外の情報は得にくくなります。責任者も異なる意見を聞き、対応が必要な事項を実際の仕事の配分に持ち帰る姿勢が必要です。

6. 高校生の指導では、開発の方法を取り組める小さな段階に分ける

企業の開発チームに加えて、高校生による健康をテーマにしたゲーム「逆熵引擎」のプロジェクトも指導しています。コーディングと共同開発の経験が少ないため、理解できる製品の流れから始め、少しずつ実装につなげる必要があります。

ゲームのアイデアを話し合う段階から MVP へと範囲を絞り、ショップ、ソーシャル機能、複雑な AI 機能などは後の検討に回しています。利用者の流れと操作できるプロトタイプを整理し、ユーザー、キャラクター、タスク、報酬などを初期のデータ設計につなげます。レビューでは、報酬をどう受け取り何に使うか、いつ進捗を保存するか、画面を閉じた後どこへ戻るかを問い、画面の背後にある業務ルールを考えてもらいます。

学生から「まず作ってから直したい」という意見が出たときには、事前設計の程度も説明しました。最初から細部を決め切る必要はありませんが、分担を決められる程度のフロー、オブジェクト、項目の草案は必要です。設計は実装に合わせて修正でき、最初の合意は担当範囲と調整が必要な変更を理解する助けになります。

AI を使う開発では、小さな課題を通して要求の説明、生成、実行、フィードバックを経験してもらいます。使ったプロンプト、期待と違った点、その後の修正を説明してもらうことも重視しています。次の課題はデータテーブルの草案と GitLab での共同作業練習で、ツールの利用を実際の開発へつなげていきます。

私自身も指導を調整する必要があります。設計や開発の概念を一度に説明しすぎると、初学者の理解を超えてしまいます。学生の構成案が複雑になりすぎたときは、私が MVP の基本構成を整理し、目の前の課題に沿って説明する形に変えました。同時に、本人が完成させ、説明し、修正できる部分を残し、私がすべての答えを与え続ける状態を避ける必要があります。

この記録の時点では、プロトタイプの修正と開発準備を進めている段階です。次はデータ設計の草案と共同作業の練習を行い、動く機能の検証へ進む予定です。

7. 取り組みのコストと効果を見直し続ける

案件定例、内部定例、勉強会、1on1 を合わせると、かなりの時間を使います。個々の形式に理由があるだけでは、全体として有効だとは言えません。

会議間で重複がないか、デモに具体的なフィードバックがあるか、振り返りから変更が生まれるか、学習が実際の問題につながるか、集中作業の時間が残るかを見続ける必要があります。少数の人にしか関係しない技術議論を全員で行っていないかも確認します。

人数が増えると 1on1 の固定日程も増えるため、問題の発見と本人の支援に役立っているかを確認します。社内の基盤は手作業を減らす一方、可用性、権限、更新、バックアップ、容量の管理責任を伴います。これらも投入するコストに含める必要があります。

要求確認と評価にもコストがあります。開発を支える明確さと、フィードバックで修正できる余地を両立させる必要があります。指標は貢献の対話を助けるものであり、数値の収集と説明が新たな負担にならないようにします。範囲、依存、優先順位が変わったら、計画と評価の根拠も更新する必要があります。

今ある記録から、協働の方法と具体的な問題のフォローは分かりますが、納期、不具合、個人の能力の変化までは数値化できません。実際の成果、問題解決、本人たちのフィードバックから判断していきます。学生のプロジェクトでも、動く機能、共同作業、本人の説明を通じて学びを確認する必要があります。

残したいのは、成果、停滞、優先順位、個人の考えが見えるようになる取り組みです。同じ時間を繰り返し消費するだけで仕事を支えなくなった仕組みは、それ自体が振り返りで改善し、時にはやめる対象になるべきです。