Skip to main content

チーム概要

AppProjectプロジェクトのチーム構成と各ロールの役割・期待について説明します。

チーム体制の全体像​

この体制は「PMの成長を軸に、開発現場を自律化しながら、上位層が方向性と品質を保証する」構造を意図しています。

  • POが事業価値とユーザー体験を定義し、
  • PMがそれを実現するためにチームを動かし、
  • PMOがそのプロセスを支え、
  • Scrum Mastersがチームの心理的・実務的な流れを整え、
  • CEOが最終的に事業判断を下す。

ロール別の役割と期待​

PO（プロダクトオーナー）​

AppProjectプロダクトの品質と方向性を担保する中心的存在

ユーザー体験・ブランド整合性・ビジネス的価値を総合的に判断し、プロダクトとしての「何をつくるか」を決める責任者です。

主な責任​

  • プロダクトの方向性と品質両面を考慮しつつ、バックログ/新規要件に対する優先順位をつけ最終的にCEOへの合意を取る
  • 現状のプロダクト品質や進捗状態に関するCEOへの説明責任をもつ

期待される役割​

これらの役割を担い、クライアントと同等であるCEOに対してプロダクト開発に関わるすべての物事に対して「責任を持つ」。ただし、実務を担うのはPMを主軸に置いた開発チームであることを期待し、その期待に合うレベルでワークするように監視する。

改めてこのロールに期待されるのは、技術的な現実性と事業的な理想を橋渡しする力であり、開発チームが迷わず進めるような明確な「判断」と「意図の共有」。

CEO（Client）​

事業責任者として、ビジネス上の方向性と投資判断の最終決定者

このプロダクトの成長性・ブランド価値・事業的な整合を見極め、POからの報告や提案をもとに経営視点で意思決定を行います。

主な責任​

  • 重要な機能や戦略的方向転換など「ビジネスインパクトの高い意思決定」に対してレビュー・承認を行う
  • 現場への直接的な関与は限定しつつも、プロダクトの事業的な意味づけを与える

チームに対しては「このプロダクトをなぜ続けるのか」という事業的な意味づけを与える存在であり、判断の最終責任を持つ。

PM（プロジェクトマネージャー）​

スプリント運営と開発推進の中心として、チームの実行をリードする現場責任者

主な責任​

  • タスク管理・進捗可視化・課題の早期発見と対応を担い、PMOのサポートを仰ぎ連携しながら、開発メンバーの稼働を維持し、出力を最大にすることに貢献してスプリントを完遂させる
  • チーム外との調整 / POへの報告・相談や、開発チーム全体がスムーズに活動できるようにScrumイベントを円滑に行う責務もある

期待される役割​

これらを達成するためにPO、PMO、Scrum Mastersに適宜サポートをもらい開発プロジェクト自体を推進する。

チームとの信頼関係を築きながら、「計画→実行→振り返り→改善」のサイクルを主体的に回しつつ安定した開発アウトプットを維持する責任を持つ。

PMO（プロジェクトマネジメントオフィス）​

PMOとして、PMの管理的な活動のサポートとその知見共有を含めた育成を担う。

主な役割は、プロジェクトの運営品質を保ちながら、成長できる環境を整えることです。

主な責任​

  • 進捗・リスク・タスク管理の基盤を整備し、必要に応じて上位層/チーム外との調整のサポートをする
  • 開発組織やチーム間の整合、スクラム運営の改善、ドキュメント整備といった、間接的に品質管理に寄与する活動も行う

Scrum Masters​

チームが健全に機能し続けるための潤滑油

ファシリテーション・心理的安全性の確保・チームモチベーション維持を中心に、PMが運営するスプリントを円滑に進めるためのサポートを行います。

期待される役割​

期待されるのは「人とプロセスの両面からチームの健全性を守ること」

  • 課題や対立が生じた際には中立的な立場で対話を促す
  • 開発効率を上げるための仕組みづくり（レトロスペクティブ、デイリー改善）を主導
  • チームとPM/PO間のコミュニケーションを仲介し、必要に応じてPMOへエスカレーション

開発チームの構成​

Dev（開発者）​

機能の実装、テスト、デプロイを担当

主な責任​

  • スプリントで計画されたイシューの実装
  • コードレビューとテストの実施
  • 技術的な実現可能性の検討
  • デプロイと動作確認

スキルセット​

  • フロントエンド開発（React Native、TypeScript）
  • バックエンド開発（API設計、データベース）
  • インフラストラクチャ（AWS、CI/CD）
  • モバイル開発の知識

Designer​

UI/UXデザインとデザイン仕様の整理を担当

主な責任​

  • UI/UXデザインの作成
  • デザイン仕様の整理とドキュメント化
  • プロトタイプの作成
  • デザインシステムの維持
  • ユーザーリサーチとフィードバックの収集

QA（品質保証）​

DevとDesignerをまたがり、品質保証とテスト戦略を担当

主な責任​

  • テスト計画の策定とテストケースの設計
  • 手動テストと自動テストの実行
  • バグの発見と詳細な報告
  • 品質メトリクスの追跡
  • デザインと実装の整合性確認

コミュニケーションフロー​

ケース1: イシュー/PBIの要件が不明確な場合​

宛先: PM (cc: Division Lead)

理由:

  • スプリント開始時のPBI整理が甘い可能性
  • 考慮できていなかったことが検知された

伝え方:

  • どのPBIにおいて（箇所を明確にして）Xxxはどんな挙動/イメージですか？
  • 想定がある場合は自身の想定を伝える（相手の回答をYes/Noベースにできる）

ケース2: デザインベースのUI/機能実装で要件理解が不透明な場合​

宛先:

  • Pattern1: デザイン担当者 (cc: PO, PM)
    • 担当がわかる場合は可能な限り当事者間で解決
  • Pattern2: PM (cc: PO)
    • 宛先がわからない場合

ケース3: PBIの実装難易度上ドロップしたい/優先度調整したい場合​

宛先: PM (cc: PO)

理由:

  • PMが判断をするのが基本
  • 最終的にPOに委ねるため、懸念アラートをccでPOにも共有

補足​

コミュニケーションで解決する場合のユースケースをピックアップしているが、全てにおいてスポット発生でのコミュニケーションで解決するのでなく、重要度や手戻りリスクも考慮しつつDaily Scrumでの共有も活用すること。