アプリ開発チームは、職種名をそろえただけでは機能しません。
要件、画面、コード、品質、公開、運用の成果物ごとに、作る人、承認する人、相談される人を決める必要があります。
少人数では一人が複数役を兼ねてもよい一方、作成と承認まで同じ人だけで閉じない仕組みを作ってください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 役割 | 主な成果物 | 最終判断 |
|---|---|---|
| プロダクト責任者 | 目的、優先順位、対象外 | 何をいつ届けるか |
| UX、UI | 利用者調査、動線、画面 | 利用者が理解できるか |
| 開発 | 設計、コード、ビルド | 技術的に実現、保守できるか |
| 品質 | テスト計画、結果、不具合評価 | 公開リスクを許容できるか |
| 運用 | 監視、問い合わせ、復旧 | 公開後に維持できるか |
| セキュリティ | 脅威、権限、対応手順 | 重要リスクへ対処できるか |
職種ではなく成果物の所有者を決める
「開発者が担当」のような広い割り当てでは、API仕様、署名鍵、ストア申請について誰が決めるか分かりません。
成果物ごとに作成者と承認者を一人ずつ明確にします。
| 成果物 | 作成の中心 | 承認の中心 | 必ず相談する相手 |
|---|---|---|---|
| 初回範囲 | プロダクト責任者 | 事業責任者 | 開発、運用 |
| 主要動線 | UX、UI | プロダクト責任者 | 利用者、開発 |
| API、データ設計 | 開発 | 技術責任者 | セキュリティ、運用 |
| リリース判定 | 品質 | プロダクト責任者 | 開発、運用 |
| 障害対応 | 運用 | 運用責任者 | 開発、広報 |
利用者を理解する仕事も一職種だけへ任せません。
デジタル庁の利用者中心ガイドブック実践編を参考に、観察、仮説、試作、評価へプロダクト、デザイン、開発が参加します。
安全性の責任も診断会社へ外出しできません。
NIST Secure Software Development Frameworkは、安全な開発の準備から成果物保護、脆弱性対応までを組織的な活動として扱っています。
チームの役割分担を六段階で作る
人の空き時間から担当を決めず、必要な判断と成果物から体制を組みます。
- 初回リリースの目的と主要成果物を並べる
- 各成果物の作成者、承認者、相談先、共有先を決める
- 一人だけが持つ知識、鍵、外部アカウントを洗い出す
- レビュー、テスト、公開、障害対応の代替担当を置く
- 会議、文書、チャット、緊急連絡の使い分けを決める
- 一週間試し、滞留した判断と引き継げない作業を直す
上流工程は、発注者や企画担当だけの領域ではありません。
技術的な難所、運用制約、テスト方法を早く出すため、開発と品質担当も要件定義へ参加します。
レビュー担当者には、承認と変更要求を行う権限を持たせてください。
GitHubのPull Requestレビュー資料を使うと、コメント、承認、変更要求を差分へ関連付けられます。
三人チームの実作業時間を見積もる計算例
次の数字は、三人いるから一日24時間進むわけではないことを示す仮定です。
一人8時間のうち、会議1時間、レビュー1時間、問い合わせ対応1時間を使うと仮定しましょう。
一人の集中作業は8－3で5時間です。
三人では5時間×3人で15時間となり、名目24時間との差は9時間です。
| 項目 | 一人 | 三人 |
|---|---|---|
| 勤務時間 | 8時間 | 24時間 |
| 連携作業 | 3時間 | 9時間 |
| 集中作業 | 5時間 | 15時間 |
連携時間を無駄とみなしてゼロへすると、設計の食い違い、レビュー待ち、手戻りが増えるでしょう。
見積もりでは会議とレビューを消さず、目的と参加者を絞って必要時間として計上してください。
意思決定と進捗確認の会議を分ける
毎日の短い確認では、完了したこと、次に行うこと、阻害要因を共有します。
要件の優先順位や公開延期などの意思決定は、必要な選択肢と影響を準備した別の場で行います。
全員がすべての会議へ出る必要はありません。
決定記録には、決めたこと、理由、却下案、決定者、見直し条件を残し、欠席者が後から追えるようにします。
主ブランチを完了基準にするなら、GitHubの保護ブランチ資料を使ってレビュー数や状態チェックを設定し、担当者の自己申告だけで完了にしません。
公開後の当番とエスカレーションを開発中に決める
公開後の障害は、開発者が気付いたときだけ対応する体制にしません。
監視通知の受け手、一次確認、機能停止の判断者、利用者への連絡、復旧後の記録を決めます。
Google SREのアラート資料が示すように、人への緊急通知は直ちに対応が必要な状態へ絞ります。
通知を受けた人が実行できる確認手順と権限を持つことが重要です。
一人しか本番へ入れない、署名鍵を持つ人が不在、外部サービスの契約者が退職という単一障害点を洗い出します。
重要アカウントは組織で管理し、代替担当者が手順書だけで公開と復旧を試せるか確認してください。
振り返りでは個人を責めず、情報不足、承認待ち、権限不足、監視不足という仕組みの問題を直します。
改善タスクにも所有者と期限を付け、議事録だけで終わらせません。
アプリ開発チームでよくある質問
小規模なら一人で全役割を兼ねてもよいですか？
兼任はできますが、要件、実装、テスト、公開、運用という観点を消さないことが重要です。
重要なコードや公開判断だけでも外部レビューや別担当の再現確認を入れ、鍵と知識を一人へ閉じ込めないでください。
プロジェクトマネージャーがすべて決めますか？
日程と調整を担えても、事業優先度、技術設計、安全性、公開可否にはそれぞれの責任者が必要です。
決定内容ごとに作成者、承認者、相談先を明示します。
コードレビューは誰が行いますか？
変更箇所の技術と業務ルールを理解でき、作成者とは別の視点を持つ人が行います。
具体的な承認と変更要求の扱いはGitHubの公式レビュー資料で確認できます。
成果物の所有者と代替担当がいるチームを作る
強いチームは人数が多い組織ではなく、必要な判断が滞らず、重要な仕事を別の人へ引き継げる体制です。
作成と承認、通常作業と緊急対応を分け、決定記録と再現手順を残します。
- 役割分担の単位は職種名ではなく要件、設計、品質、公開、運用の成果物
- 各成果物に必要な作成者、承認者、相談先、共有先
- チーム工数から消さない会議、レビュー、問い合わせ、引き継ぎ時間
- 公開後に備える監視受け手、一次確認、停止判断、連絡、代替担当
運用へ引き渡す成果物を具体化するには、アプリ公開後の更新、障害対応、改善で当番と定常作業を一つずつ定義できます。
