はじめに
大学院の授業でアジャイル開発のコーチが数名ほど来てくださり、実際にチーム（4名）で開発を行う機会がありました。
そこで学んだ知識と実践経験を、「これからアジャイル開発を始めるチーム」が迷わずに進められる手順書としてまとめます。
Notionでも管理できるようにテンプレートを作成しました。
必要であれば使ってください
👉 開発プロジェクト管理
この記事では、特に以下を重視して書きます。
- 何から始めればよいか
- 各フェーズで「何を決めるべきか」
- レビューで「何を学ぶべきか」
この記事のゴールは以下の2点です。
- 読者が明日からアジャイル開発を進められる状態になること
- 「実務で通用するエンジニア」とはどんな人なのかを理解すること
ソフトウェア開発は「チームスポーツ」である
まず、なぜ開発手法やチームワークが重要なのか、その本質について触れます。
重要な考え方
ソフトウェア開発は「チームスポーツ」です。
一人で完結する仕事ではなく、他者と協力して価値を届ける活動です。
一人の天才より、チームの連携
現代の開発において、一人ですべての技術領域を網羅できる人はほとんど存在しません。多様なスキルを持った人材が集まり、協力することで初めてプロダクトが生まれます。
つまり、「事業や組織へ貢献する仕事を自分で見つけ、他者と協力しながら実践できること」こそが、実務で通用するスキルです。
開発に「完了」はない
機能実装は一度で終わりではありません。
- 新機能の追加
- バグの発見と修正
- ライブラリの更新
これらに対応し続けるためには、特定の誰かだけが詳しい状態ではなく、知識やスキルがチーム全体に共有されている状態が必要です。
全体像：開発とレビューのサイクル
アジャイル開発では、短期間で「開発」と「検証」を繰り返します。
（例：1週間で開発し、第三者にレビューしてもらうサイクル）
アジャイル開発の本質は「仮説検証の高速ループ」です。
サイクル：開発 → レビュー → 見直し（リプランニング） → 次の開発...
アジャイル開発の5ステップ
価値を届けるための開発は、以下のフェーズで進めます。
以下の5ステップは、順番に実行するチェックリストとして使ってください。
（この後、各ステップを具体例つきで解説します）
| # | フェーズ | 内容 | 実施すること |
|---|---|---|---|
| 1 | 仮説を立てる | ・誰のどんな困りごとを解決するか検討 ・検証したい目標・ゴールを立てる |
・ターゲットユーザー/ペルソナ設定 ・開発サイクルゴールの設定 |
| 2 | MVPを決める | ・検証に必要な「最小限の機能」を決める | ・カンバンボード作成（プランニング） |
| 3 | 実装する | ・MVPを作って、早くリリースする | ・開発（モブプログラミング等） ・進捗の見える化 |
| 4 | 測る | ・実際のユーザー行動を観察・計測する | ・ユーザーレビュー（バザール方式） |
| 5 | 継続 or ピボット | ・仮説が正しいかを学び、次の一手を考える | ・リプランニング ・振り返り（KPT等） |
開発準備（Environment & Tools）
「開発Ready」な状態にするために、以下のツールや環境を整えます。
1. 必須ツール
Git / GitHub: バージョン管理に必須です。
VS Code: コードエディタ（他でも可）。
Miro: 視覚的に共有できるホワイトボードツール。Googleドキュメントよりも直感的でおすすめです（Notionでも可）。
2. モブプログラミングの導入
開発に慣れていないチームには「モブプログラミング」がおすすめです。
全員で1つの画面を見ながらコーディングすることで、知識共有が自然に行われ、属人化を防げます。
参考：モブプログラミングとは（Qiita）
実践：開発サイクルの進め方
ここからは具体的な手順を解説します。
Step 1. ターゲットユーザーを決める
誰が、どんな困りごとを抱えているのかを明確にします。
-
ポイント：実在する人物（自分など）を設定する
- 架空の「ペルソナ」を設定すると、リアルな文脈や課題を見落としがちになります。
- 実在する人物であれば、レビュー時にリアルなフィードバックが得られ、チームの方向性がブレにくくなります。
【記述項目】
- プロフィール: チーム全員がその人をイメージできる程度に。
- 困っていること: いつ、どこで、どんな状況で困っているか具体的に。
- 理想の状態: その人にとって、どうなったら嬉しいか。
【具体例：ターゲットユーザー】
- プロフィール: 大学に通う自分。優柔不断で、昼休みになると何を食べようか毎日5分以上迷ってしまう。
- 困っていること: 選択肢が多すぎると決められず、結局いつもと同じコンビニ弁当になってしまい、「もっと美味しいものを食べたかった」と午後からの講義で後悔する。
- 理想の状態: 今の自分の「空腹度」や「予算」を直感的に選ぶだけで、今日行くべき店が1つだけ提示され、迷わず直行できる。
Step 2. エレベーターピッチを作る
プロダクトの全体像について、チーム全員で共通認識を持つために作成します。
【テンプレート】
- 目的：[潜在的なニーズ/課題] したい
- 対象：[対象顧客] 向けの、
- 製品：[プロダクト名] というプロダクトは、
- 分類：[プロダクトのカテゴリ] です。
- 価値：これは [重要な利益、対価に見合う説得力のある理由] ができ、(MUST)
- 違い：[代替手段の最右翼] とは違って、[差別化の決定的な特徴] が備わっている。
【具体例：エレベーターピッチ】
- 目的：[ランチの店選びで迷う時間をゼロに] したい
- 対象：[優柔不断な自分] 向けの、
- 製品：[今日のメシ選び] というプロダクトは、
- 分類：[即決型の飲食店レコメンドツール] です。
- 価値：これは [自分の過去の満足度と今の気分を掛け合わせ、『今日の正解』を1つだけ提示] することができ、
- 違い：[選択肢が多すぎる検索サイト] とは違って、
- 特徴：[迷う余地を与えない「1択」表示機能] が備わっている。
-
注意点:
- 「何を作るか」より「なぜ作るのか（プロダクトビジョン）」を意識します。
- これを書いた時点で、投資家や顧客に「価値がありそう！」と思わせられなければ、良いプロダクトになる可能性は低いです。
Step 3. 開発サイクルゴールの設定 & カンバン
今回のサイクルで「何を検証したいのか」を一つに絞って決めます。
カンバンの目的は、「今、チームが何に集中しているか」を全員で揃えることです。
【カンバンボードの運用】
- MVP（Minimum Viable Product）の選定: ユーザーの困りごとを解決する「最小限の機能」を洗い出します。
-
レーン分け:
TODO、Doing（進行中）、Done（完了）に分けます。 - 優先順位: 上にあるものほど優先度を高くします。
- 一点集中: モブプロなら、一番上のタスクだけを全員で取り組み、終わったら次へ進みます（仕掛かりを減らす）。
【具体例：カンバンボード】
| TODO（次にやること） | Doing（進行中） | Done（完了） |
|---|---|---|
| 1. 気分選択UIの作成（「ガッツリ」等の選択肢） | 3. リストから1件を選出するロジック | |
| 2. 店の詳細情報の表示（住所、営業時間など） | ||
| 4. 近隣の飲食店10件のデータ準備（検証用リスト） | ||
| 5. Googleマップとの連携機能 | ||
| 6. 過去の履歴保存機能 |
Step 4. ユーザーレビュー（検証）
実際に動くプロダクトをユーザー（または関係者）に使ってもらいます。
ポイント:
- インタビューだけでなく、「利用時のユーザー行動」を観察・計測すること。
- 自分たちでは発見できない「使いにくさ」や「想定外の行動」が見えてきます。
- 完璧でなくてOK。早期に仮説のズレを発見できることがメリットです。
Step 5. リプランニング（学習と転換）
レビュー結果をもとに、次の一手を決めます。
検証の目的は 「成功」ではなく「学び」 です。
「失敗」も「仮説が1つ減った」という立派な学びです。
【問いの例】
- 想定どおりの行動はあったか？
- 想定外の反応から何を学んだか？
仮説が外れていれば ピボット（方向転換） し、合っていれば 継続 を決断します。
難しかったこと・注意点
-
「作り込みすぎ」への誘惑:
MVP（最小限の機能）を決めても、つい「あれもこれも」と作りたくなってしまいます。しかし、使われない機能を作ることはムダです。「検証したいことは何か？」に立ち返ることが重要でした。 -
チームの認識合わせ:
言葉だけで話していると、全員が違う絵を思い浮かべていることが多々あります。Miroなどのボードや図を使って、視覚的に認識を揃える作業（エレベーターピッチ等）が非常に重要だと感じました。
最後に
実務で通用する人とは、単にコードが書ける人ではなく、「チームで価値を届けるために、プロセス自体を改善し続けられる人」だと学びました。
この記事が、これからチーム開発を始める方の一助になれば幸いです。
補助ツール一覧
- ドキュメント・共有: Google Drive, Google Docs
- 可視化・ボード: Miro (Notionでも可)
- コード管理: GitHub
- エディタ: VS Code