🥷
精読「アジャイルサムライ」(第四部　アジャイルなプロジェクト運営)

2025/01/02に公開
アジャイルサムライ――達人開発者への道

アジャイル開発を実践するための具体的な方法論と心構えを学べる一冊です。チームで成果を出す秘訣や、迅速かつ柔軟に価値を届けるためのツールや考え方をわかりやすく解説。初心者から経験者まで、アジャイルの本質を知りたいすべての人におすすめのガイドブックです！
関連記事https://zenn.dev/joaan/articles/1f20cd0329b390

https://zenn.dev/joaan/articles/3e5fdc23b2d6a6

https://zenn.dev/joaan/articles/8a2f89e227162a

https://zenn.dev/joaan/articles/f7c492568ab436

https://zenn.dev/joaan/articles/5f43c06dd45e36

 イテレーションの運営：実現させるアジャイルプロジェクト運営では、イテレーションを回して実際に動くソフトウェアを作ることが重要。本章ではイテレーションの進め方を説明し、続く章ではアジャイルチームが活用するミーティングや情報同期の方法を紹介する。また、現場環境を改善することで、状況が明確になり、仕事が効率的に進むことを解説する。

 価値ある成果を毎週届けるアジャイル開発では、インデックスカードからリリース可能なソフトウェアを作るために、3つの重要なポイントがある
まず、文書化に時間をかけず、必要な情報を必要な時に手軽に記録できる方法を使うこと。
次に、開発プラクティスをチームにしっかり根付かせ、手戻りやバグ修正の時間を減らすために、実装開始から動作する状態を保つこと。
そして、テストは開発と並行して進め、プロジェクトの初日からシステムが全体として適切に動作するようにすることです。

 アジャイルなイテレーションアジャイルなイテレーションは、1〜2週間の期間を固定したタイムボックスで進行し、開発チームが顧客の優先順位に従ってストーリーを動作するソフトウェアに変換する。イテレーションのゴールは、テスト済みで動作するソフトウェアを実装し、価値のある成果を顧客に届けること。



イテレーションとは？スプリントとの違いやアジャイル開発におけるメリットより
イテレーション中に作業内容を変更することは通常なく、イテレーション終了後に軌道修正が行われる。方針転換が必要な場合もあるが、基本的にはイテレーション内での変更は避ける。

 【急募】アジャイルチーム【切実】ミスター・ケリーから依頼されたウェブサイト構築のプロジェクトでは、1回のイテレーションで全てを作成するのは無理だが、最初の2週間で2つのストーリーを実現することが重要。
これを実現するために、以下の3つのステップで進める

分析と設計：作業の段取りをつけ、何をどう進めるかを計画する

開発：実際にコーディングや作業を行い、機能を実装する

テスト：実装した内容が正しく動作するか確認する
これらのステップを踏むことで、2つのユーザーストーリーを実現できるようになる。

 ステップ１：分析と設計：作業の段取りをするアジャイルな分析では、次の2つの重要な柱がある
必要な分だけを、必要なときに

分析は、進行中の作業に必要な範囲で行うべき。過剰な分析は時間の浪費になり、逆に不十分だと問題が起こる。小規模なチームでは、インデックスカードや簡単な会話、図を使って情報を共有できる。規模が大きくなれば、文書やリストで情報を整理する必要があるが、無駄な作業は避けるべき。
ジャストインタイム分析

ユーザーストーリーの実装を予定するイテレーションの1つ前に分析を行う。これにより、最新かつ最も充実した情報をもとに作業を進めることができ、学習を繰り返すことで分析スキルが向上し、手戻りを減らすことができる。
具体的な作業として、ストーリー「作業許可証を申請する」では、フローチャートを作成し、ペルソナを定義、プロトタイプを作成してデザインを検討し、テスト条件を明確にする。分析と設計段階で過剰な準備を避け、最適なタイミングで行動することが重要。

 ステップ２：開発：作業する開発では、アジャイルプロジェクトにおいて、分析したストーリーを「金塊」に変える—リリース可能なソフトウェアに実装することが求められる。これには規律、技術的卓越性、そして以下のエンジニアリングプラクティスが必要
自動化されたテストを書く
設計を継続的に改善する
コードを継続的にインテグレーションする
顧客の言葉に合わせてコードを書く
また、イテレーション・ゼロという準備期間が必要で、ここではバージョン管理、ビルド自動化、テスト環境の設定などを行う。イテレーション・ゼロでは、アーキテクチャ検証のためにストーリーの一部を実装することもある。
さらに、アジャイルでは「コードの共同所有」が推奨され、チーム全員がコードの変更を自由に行える状態にすることで、コミュニケーションを活発にし、アーキテクチャの一貫性を保つことが重要。

 ステップ３：テスト：作業の結果を確認するアジャイル開発では、作業結果を確実に確認するためには、お客さんからのフィードバックを得ることが重要。デモを通じて、実際にソフトウェアを操作してもらい、期待通りに動作しているかを確認するのは効果的な方法。アジャイルでは、開発チームは常に受入テストが可能な状態を目指すべきだが、正式な受入テストは開発が進んでいく中でも依然として必要。最終的な受入テストは、お客さんが真剣にシステムの問題を確認できる機会であり、開発チームが自信を持って受け入れられる品質を提供できているかを示すために重要。
アジャイルチームが正式な受入テストを不要だと断言できるほどコードの品質が高く、スポンサーが納得できる証拠を示せるようになれば、その段階で形式的な受入テストを省略することが可能になる。

 カンバンカンバンは、トヨタが開発した情報伝達システムに由来し、作業の進行を管理する方法。カンバンボードでは、**同時に進める作業（WIP）**に上限を設け、チームが着手できる作業はその制限内であり、優先順位に従って次の作業に取り掛かる。カンバンの特徴的な点は、イテレーションが不要で、優先度が高い作業から順に進めていく点。
カンバンの利点には、イテレーションのプレッシャーから解放されることや、大きな問題をそのまま進めることができる点。また、作業の見積もりや期待管理もシンプルで、例えば「同時に4つまでしか作業できない」という形で進行状況を把握できる。
カンバンは、運用やサポート業務のようにイテレーションを必要としない仕事に適しており、アジャイル開発においてもイテレーションが必要な場合と、カンバンを選んだ方が効果的な場合がある



トップ エキスパートによる「かんばん」初心者完全ガイドより

 アジャイルな意思疎通の作成本書のアジャイル手法におけるアドバイスは、開発チームが同じ場所で作業し、動作するソフトウェアを定期的に顧客に見せること。
それ以外の具体的な進め方（イテレーション、チーム編成、意思疎通、フィードバックの取り入れ方など）は、すべてチームの決定に任されている。
本章では、アジャイルな意思疎通の方法を明確にし、チームが価値ある成果を生み続けるためのリズムや習慣を身につけるためのヒントを提供する。

 イテレーションでやるべき４つのことアジャイルプロジェクトで重要な取り組みは、期待のマネジメントとフィードバックの取得である。これを継続的に行うためには、顧客と定期的にレビューを行い、フィードバックループを形成していくことが求められる。イテレーションごとに以下の4つのミーティングを定期的に開催する習慣をつけることが推奨される。

ストーリー計画ミーティング（今回のイテレーション作業への備え）

ショーケース（今回のイテレーションのフィードバックを得る）

イテレーション計画ミーティング（次回のイテレーション計画）

ミニふりかえり（次回のイテレーション改善点を探す）


【アジャイル】アジャイルサムライを読む その10 ~ アジャイルな意思疎通の作戦より

 ストーリー計画ミーティングストーリー計画ミーティングは、ジャストインタイム分析の結果を確認し、次のイテレーションで取り組むストーリーが準備できていることを全員で確かめるためのミーティングである。顧客と受入テスト条件をレビューしたり、開発チームが見積もりを確認したりする。もしストーリーが想定より大きかった場合は分割し、逆に小さければ他の小さなストーリーを追加して計画を更新する。ストーリー計画ミーティングはアジャイル手法に一般的に言及されていないが、無駄を避けるために有効な方法である。

 ショーケースショーケースは、チームが実装したストーリーを顧客にお披露目し、実際のフィードバックを得る機会である。このミーティングでは、テストサーバにデプロイした本物のコードを見せることが重要で、目論見や未完成なものではなく、完成した成果を示す。ショーケースはイテレーションの締めくくりとしても適しており、成果を自慢し、フィードバックをもらい、顧客に直接操作してもらうことが求められる。

 イテレーション計画ミーティングイテレーション計画ミーティングでは、開発チームと顧客が次のイテレーションの作業を計画し、ベロシティを確認し、取り組むストーリーを整理して、コミットする作業量を決定する。また、プロジェクトの現状を確認するタイミングでもあり、課題や問題を共有し、選択肢を示す場でもある。バーンダウンチャートを使って、プロジェクトの進捗と完了予定を可視化し、現実的な見通しを伝えることが重要。アジャイル開発では、「悪いニュースは早めに」との方針で、顧客に状況を正直に報告する。最後に、イテレーションの改善点を話し合う「ミニふりかえり」も実施する。

 ミニふりかえりミニふりかえりは、短時間（10～15分）で行う集中したミーティング。チーム全員でうまくいったことや、改善できる点を話し合う。重要なのは、参加者が安心できる雰囲気を作ること。ミニふりかえりでは、良い点を褒め合い、改善点を挙げて今後の作業に活かす。これにより、チームは集中力を取り戻し、改善点に取り組む意欲を新たにする。改善テーマを次のイテレーションで取り組み、進捗を確認するのも良い方法である。ふりかえりに関する詳細は『アジャイルレトロスペクティブズ』が参考になる。

 デイリースタンドアップデイリースタンドアップは、チームメンバーが毎日集まり、短時間で重要な情報を共有するミーティング。通常、会議として正式に「開催」するわけではなく、メンバーが自主的に集まり、立ったままで5〜10分程度行われる。基本的に、各メンバーが自分の作業の最新状況を報告し、他のメンバーに知らせるべきことを共有する。従来の報告方法では、次の3つを伝えるのが一般的。
昨日やったこと
今日やること
チームの開発速度を下げる障害があればそれを報告
ただし、これだけでは新たなひらめきやチームの振る舞いを変えるには物足りない場合もある。そこで、報告の仕方を少し変えてみると、場の雰囲気が一変するかもしれません。例えば次のように報告してみよう
昨日、世界をどう変えたのか
今日は何をぶちかますつもりか
不運にも自分の行く手を阻んでしまった難問がどんな末路をたどるのか
こうすることで、チーム全体のエネルギーが高まり、コミットメントも強くなる。自分がやるべきことを宣言することで、実行するための動機づけとなり、より高い成果を上げられるようになるだろう。

 自分たちにあった手段を選ぼうアジャイル開発では、ミーティングの形式やタイミングをチームのニーズや状況に合わせて柔軟に調整することが重要。紹介された4つのミーティング（ショーケース、イテレーション計画ミーティング、ミニふりかえり、デイリースタンドアップ）は、それぞれに目的があるが、必ずしも個別に開催する必要はない。チームの状況に応じて、いくつかを1つのミーティングにまとめたり、別々に開催したりすることも可能。
例えば、ショーケース、イテレーション計画ミーティング、ミニふりかえりを1時間以内でまとめて実施する方法もあるし、顧客と開発チームが日常的にコミュニケーションを取っている場合、ストーリー計画ミーティングを別途設けずに済ますこともある。このように、やり方はチーム次第であり、価値が生まれないものや時間を無駄にするだけのものは省略することが推奨される。
また、イテレーションの途中でショーケースを実施しても問題ない。実際に動作するソフトウェアを顧客に見せ、フィードバックをもらうことで、期待値の調整や改善点を探ることができるので、タイミングにこだわる必要はないということ。
アジャイル開発は柔軟性が大切なので、いろいろな方法を試し、チームにとって最も効果的なアプローチを見つけていこう。

 ケーススタディシナリオ1：完成していないストーリー
プロジェクトマネージャーがストーリーポイントを半分だけベロシティに加算し、残りを次のイテレーションに持ち越そうとするアイデアに対して、アジャイルの原則に反するという点が指摘されている。アジャイルでは、ストーリーが「完了」しているか「完了していないか」の二択であり、中途半端な進捗を次のイテレーションに持ち越すことは推奨されない。ストーリーは完全にテストを通過し、完成するまでそのイテレーションのベロシティには加算されない。未完のストーリーは、次回のイテレーションに再度持ち越され、完全に完了した段階で評価されるべき。
シナリオ2：デイリースタンドアップの価値
デイリースタンドアップを不要だと考えるチームに対して、価値を理解させることが大切。しかし、チームの規模や働き方によっては、必ずしも毎日のスタンドアップが必要でないこともある。もしチームメンバーがオープンにコミュニケーションを取り、進捗を共有できているのであれば、デイリースタンドアップは必須ではないかもしれない。重要なのは、価値のある習慣を維持することで、無駄に時間を費やすことなく、チームの状況や必要に応じてミーティングの形式を柔軟に変更すること。
シナリオ3：何も価値を生み出せなかったイテレーション
イテレーションで価値を生み出せなかったことを顧客に隠すためにショーケースをキャンセルするという選択肢については、誤り。アジャイルでは、顧客に成果を見せることが重要であり、たとえ成果がなくても、それを隠すことなく伝えることが成長に繋がる。失敗を顧客と共有することで、チームはその後の改善に向けて動機づけられる。顧客に対して正直に、何がうまくいかなかったのか、なぜ進捗がなかったのかを説明し、次回に向けて改善策を示すことが、真摯な姿勢を示すためには必要。

 現場の状況を目に見えるようにするビジュアルワークスペースは、プロジェクトの進捗や優先事項を視覚的に整理し、チームの透明性を高めるための手法。例として、カンバンボードや進捗トラッキングツール（バーンダウンチャートなど）があり、タスクの状態や進行状況を一目で把握できる。これにより、問題の早期発見や情報共有がスムーズになり、上層部への報告もしやすくなる。目に見える形で情報を整理することで、チーム全体の意識が統一される。

 これは…荒れる！プロジェクトの状況を透明化し、関係者に実際の進捗を理解してもらうことは重要。特に、リソースが減少し、スケジュールが圧縮された状況で、ただ説明するだけでなく、視覚的に現状を伝える方法が求められる。具体的な手法としては、インセプションデッキ、リリースボード、ストーリーボード、ベロシティやバーンダウンチャートなどを活用すること。
これらのツールを使うことで、プロジェクトの進捗やリスクが一目で分かり、経営陣や他のステークホルダーに対して現実的な状況を効果的に伝えることができる。結果として、プロジェクトの方向性を再調整する手助けにもなり、期待値の調整や、今後の施策についての合意形成が進みやすくなる。

 貼りものの作り方チームがアジャイル開発に慣れるために必要不可欠な視覚的ツールを取り入れることで、進捗を管理しやすくし、仕事の優先順位やボトルネックを見える化する方法として、具体的には、次の4つのツールが推奨されている。
ストーリーボード:
チーム全員が毎朝のスタート時に次にやるべきことがわかる。
ボトルネックが視覚的に示され、リソース配分の決定に役立つ。



【アジャイル】アジャイルサムライを読む その11 ~ 現場の状況を目に見えるようにするより
リリースボード:
プロジェクト全体の進捗を一目で確認できる。
何が完了しているか、何が残っているかが明確に見える。



(https://blog.radicode.co.jp/development/2186)より

【アジャイル】アジャイルサムライを読む その11 ~ 現場の状況を目に見えるようにするより
ベロシティとバーンダウンチャート:
チームの進行ペースや進捗具合が視覚化され、計画と実績を比較できる。
プロジェクトの完了予定日を現実的に把握でき、期待管理にも役立つ。



【アジャイル】アジャイルサムライを読む その11 ~ 現場の状況を目に見えるようにするより
インセプションデッキ:
チームが「なぜこのプロジェクトに取り組んでいるのか」を常に意識できる。
プロジェクトのゴールや目的を全員が忘れずに把握するために便利。



【アジャイル】アジャイルサムライを読む その11 ~ 現場の状況を目に見えるようにするより
これらを壁に貼り出すことで、プロジェクトの進捗や問題点が視覚的に管理され、全員が自分の役割と目標を意識しやすくなる。また、進行状況をステークホルダーにも見せることで、現実的な期待を共有しやすくなる。

 チームの意思を明確にする「チームとしてこうやって作業したい宣言（Working Agreements）」と「チームが大事にすること（Shared Values）」は、チームの目標や行動指針を明確にするためのツール。前者はメンバー間の共通理解を深め、後者は価値観や理念を表現し、プロジェクトの進行中に意識を統一する。両方とも壁に貼ることで、チームの一貫性と目標に向かう力が高まる。

 プロジェクトで使う言葉を共有する業務で使われる用語がソフトウェアに反映されないと、以下のような問題が生じる

間違った抽象化（業務用語が誤解される）

変更しづらくなる（表示とデータが一致しない）

バグが増える（ソフトウェア変更が余分な負荷を生む）
これを避けるためには、チームと業務をつなぐ共通の用語を定め、プロジェクト内で統一した言葉づかいを徹底することが重要。顧客との打ち合わせで出てきたキーワードを明確に定義し、その定義をソフトウェアに反映させることで、バグや手戻りを減らし、顧客とのコミュニケーションも円滑になる。
『エリック・エヴァンスのドメイン駆動設計』は、このアプローチを深く学べる必読書。

https://amzn.to/3DQGTVz

 バグを監視する本番環境にリリース後、バグに圧倒されないためには、プロジェクト初日からバグの監視と追跡を徹底することが重要。毎回のイテレーションで10%の時間をバグ修正に充て、技術的負債を返済するのも効果的。また、バグを見つけたらその場ですぐに修正し、取り逃がさないようにすることで、リリース後のトラブルを未然に防ぐことができる。

 参考