アジャイルとチーム開発

前の章で、1つの機能が世に出るまでの流れを見ました。 この章では、それをチームで、繰り返し回すための仕組みを扱います。

先に結論を書きます。この章で一番大事なのはスクラムの用語ではありません。 「詰まった時にいつ声を上げるか」です。 新人が評価を落とす原因の第1位は、技術力不足ではなく報告の遅れだからです。

なぜ計画通りに作れないのか

ソフトウェア開発では、見積もりが当たりません。これはあなたが未熟だからではなく、 作ってみるまで分からないことが多すぎるからです。

• 既存コードが想像より複雑だった
• 外部 API の仕様が書いてある通りではなかった
• 3件だけだと思っていたケースが実は12件あった
• ライブラリのバージョンが上がらず、依存が芋づる式に壊れた

家を建てるのと違い、ソフトウェアは同じものを二度作りません。 毎回が初めての作業なので、経験から時間を正確に読むことができません。

この「不確実性」をどう扱うかで、開発の進め方が変わります。

ウォーターフォールとアジャイル

ウォーターフォール
  要件定義 ─→ 設計 ─→ 実装 ─→ テスト ─→ リリース
  （最初に全部決めて、順番に作る。戻らない前提）

アジャイル
  ┌→ 計画 → 実装 → 確認 → 学ぶ ┐
  └───────────────────────────┘
  （小さく作って出し、学んだことを次に反映する。これを繰り返す）

スクラムの仕組み

アジャイルの進め方の中で、最も広く使われている型がスクラムです。 用語が多くて最初は戸惑いますが、それぞれに目的があります。目的だけ覚えてください。

登場人物

「何を作るか」は PO、「どう作るか」は開発チーム、という分担が基本です。 実装方法を PO が指定してくる場合、それは越境なので相談していい部分です。

繰り返しの単位: スプリント

1〜2週間の固定期間です。この単位で計画し、作り、振り返ります。

月                                          金
├─ スプリント開始 ────────────────────── 終了 ─┤
│                                              │
├ プランニング                       レビュー ─┤
│                                  レトロ ─────┤
└─ 毎朝デイリー ───────────────────────────────┘

4つの会議とその目的

昨日: 検索APIの実装を進めた
今日: 続きをやる
困っていること: Spanner のクエリが想定より遅く、原因が分かっていない

バックログ

やることリストです。2種類あります。

• プロダクトバックログ — やりたいこと全部。優先順位つき。PO が並べ替える
• スプリントバックログ — そのスプリントでやると決めたぶん

ユーザーストーリーと受け入れ条件

チケットは、こういう形式で書かれることがあります。

[ユーザーとして] 商品を探している購入者は
[〜したい]      商品名を正確に知らなくても目的の商品を見つけたい
[なぜなら]      商品名の表記が出品者ごとにばらばらだから

「誰の、どんな困りごとを解決するのか」 を先に書く形式です。 これがあると、実装で迷った時に「購入者が探しやすいのはどっちか」で判断できます。

受け入れ条件

そして、何ができたら完成なのかを具体的に書きます。

- 商品名の部分一致で検索できる
- 説明文にキーワードが含まれる商品も結果に出る
- 検索結果は関連度順に並ぶ
- 該当0件のときは「見つかりませんでした」と表示する
- 検索の応答は 200ms 以内

見積もり

なぜ「時間」で見積もらないのか

多くのチームでは、時間ではなくストーリーポイントという相対値を使います。

この作業は、あの作業（3ポイント）と比べてどれくらい？
  → 同じくらい大変 → 3
  → 倍くらい大変   → 5 か 8

理由は2つです。

1. 人によって作業時間が違う（ベテランなら1時間、新人なら1日）。 でも「難しさ」は同じくらいに見える
2. 時間で言うと約束に聞こえる。「8時間です」と言うと、8時間で終わらないと嘘になる

数字はフィボナッチ数列（1, 2, 3, 5, 8, 13）を使うことが多いです。 大きくなるほど不確実性が増すので、細かい区別に意味がなくなるからです。

見積もりは外れる。それは問題ではない

外れること自体は誰も責めません。 全員が「外れるもの」と分かっています。

問題になるのはこれです。

外れたことを、締め切り直前まで言わないこと

詰まった時にどうするか

この章で最も伝えたい部分です。

30分ルール

30分考えて進まなければ、人に聞いてください。

これは第0章でも書きましたが、繰り返す価値があります。 なぜなら、新人はほぼ全員これができないからです。

「こんなことも分からないのかと思われたくない」 「自分で解決するのが仕事だと思う」 「先輩は忙しそうだから」

気持ちは分かります。でも、チームから見た計算は逆です。

聞くことは、チームのコストを下げる行為です。

時系列で見る

【悪い例】
Day 1  詰まる。「もう少し考えれば分かるはず」
Day 2  まだ分からない。「今さら聞きづらい」
Day 3  分からない。デイリーでも「順調です」と言ってしまう
Day 4  スプリントレビュー前日。「実はできていません」
       → チームは代替案を検討する時間がゼロ。信頼が下がる

【良い例】
Day 1  10:00 詰まる
       10:30 Slack で聞く「〜を試したが〜というエラーが出ます。〜が原因かと思っていますが…」
       10:35 先輩「それは〜の設定が必要です」
       10:40 解決。実装に戻る
       → 消費は40分。信頼は下がらない（むしろ状況を共有できる人と見られる）

悪い例のポイントは、Day 3 のデイリーで嘘をついたことです。 ここで「実は詰まっています」と言えていれば、まだ間に合いました。

聞き方のテンプレート

丸投げの質問は答えづらく、返事が遅れます。この4点を添えてください。

【やろうとしていること】
ローカルで API サーバーを起動しようとしています。

【起きていること】
起動時に以下のエラーで落ちます。
（エラーメッセージを全文そのまま貼る）

【試したこと】
- ポートが使われていないか lsof で確認 → 使われていませんでした
- .env の DATABASE_URL を README の通りに設定 → 変わらず

【聞きたいこと】
このエラーの原因として、他に確認すべき箇所はありますか？

チームでの振る舞い

分報（times チャンネル）

多くの Web 系企業には times-あなたの名前 のような個人チャンネルがあります。 そこに作業中の独り言を書きます。

10:00 検索APIの実装開始
10:30 Spanner のクエリが遅い。EXPLAIN を見てみる
10:45 インデックスが効いてないっぽい？
11:00 → 主キーの順序が原因だった。解決

これは日記ではなく、非同期の助けを呼ぶ仕組みです。 通りかかった先輩が「それインデックスの順序では」と教えてくれることがよくあります。

新人ほど書く量を多めにしてください。 何に時間を使っているかが見えると、周りは助けやすくなります。

会議で分からない単語が出たら

聞いてください。「すみません、SLO というのは何ですか」と。

新人が聞くと、実は他の人も分かっていなかったことが判明する場面がよくあります。 分からないまま議事録を書くと、間違った内容が残ります。

その場で聞けなかったら、あとで調べてメモに残してください。

最初の1ヶ月でやるべきこと

ケーススタディ: 3日黙った新人

C さんは「決済のリトライ処理を実装する」チケットを受け取り、3日で終わると見積もりました。

Day 1  外部決済APIの仕様書を読む。リトライの条件が書いていないことに気づく
       → 「たぶんタイムアウトの時だけだろう」と自分で判断して実装を進める
Day 2  実装するが、テストでどう再現すればいいか分からない。悩む
Day 3  デイリーで「順調です」と報告。実際は8割の確信もない
Day 4  レビューで「冪等性は考慮していますか？」と指摘される
       → 冪等性を知らなかった。設計からやり直し
Day 7  完成。スプリントには間に合わず、次に持ち越し

分岐点は Day 1 でした。 仕様書にリトライ条件が書いていないと気づいた時点で、

決済APIの仕様書にリトライ条件の記載が見つかりません。 タイムアウト時のみリトライする想定で進めようと思いますが、認識は合っていますか？ （リトライ時の二重決済が心配なので、そこも確認したいです）

と聞いていれば、Day 1 で冪等性の話が出て、正しい設計から始められました。

C さんの技術力に問題はありません。 確認をしなかったことだけが問題です。

ケーススタディ: 良いレトロ

スプリントの最後にレトロ（振り返り）をします。よく使われる KPT という型があります。

新人でもレトロで発言していいです。むしろ新人にしか見えない問題があります。

• README 通りにやっても環境構築できなかった
• この用語がドキュメントのどこにも定義されていない
• チケットの受け入れ条件が空欄のことが多い

これらは、慣れた人には見えなくなっている問題です。

実務の落とし穴まとめ

1. 詰まったことを言わない — 最も評価を落とす。30分ルールを守る
2. デイリーで「順調です」と言い続ける — 困りごとを言う場だと理解する
3. 仕様の不明点を自己判断で埋める — 確認は5分、手戻りは3日
4. 見積もりが外れそうなのを直前まで報告しない — 外れること自体は問題ではない
5. DM で質問する — パブリックチャンネルなら知識が残り、他の人も助かる
6. 分からない単語を分からないまま流す — 他の人も分かっていないことが多い

まとめ

• 見積もりが当たらないのは、毎回が初めての作業だから。あなたのせいではない
• ウォーターフォールとアジャイルは優劣ではなく、不確実性の量で選ぶ
• スクラムの各会議には目的がある。特にデイリーは困りごとを出す場
• 見積もりは外れる。問題なのは報告が遅れること
• 30分詰まったら聞く。聞くのはチームのコストを下げる行為
• 質問には「やろうとしたこと・起きたこと・試したこと・聞きたいこと」を添える
• 新人にしか見えない問題がある。レトロで言っていい

章末問題

これで第2部は終わりです。ここまでで、チームで働くための土台が揃いました。

第3部からは技術の話に戻り、ネットワーク・Web・ブラウザの仕組みを見ていきます。