アジャイル開発

アジャイル開発の出発点は、要件が最初から正確に分かっているとは限らない、という前提に立つことです。市場や利用者の反応、技術的な制約は作り始めてから見えてくることが多く、最初にすべてを設計して一度に作り上げると、完成した頃には前提がずれているという事態が起こりやすくなります。そこで、短い期間で動くものを作って確かめ、ずれていたら方向を直す、という進め方が選ばれます。

この進め方では、優先順位を常に更新できることが価値になります。限られた時間の中で、今もっとも必要な機能から順に作り、使える状態にしていくため、途中で中止や縮小になっても、それまでに作った部分が成果として残りやすいという利点があります。

• 変化への対応を前提にする
  要件の変更をプロジェクトの失敗ではなく、学習の結果として扱い、計画へ織り込んでいきます。
• 早く動くものを見せる
  ドキュメントだけで合意するのではなく、動くソフトウェアを材料に、利用者や発注側と認識を合わせます。

一方で、反復するからといって計画が不要になるわけではありません。何を・どの順で作るかの見通しは必要で、むしろ更新し続ける前提の計画が求められます。

スクラムを例にとると、登場する役割は、優先順位を決めるプロダクトオーナー、開発を担う開発チーム、進め方を支えるスクラムマスターに分かれます。プロジェクトマネージャーはこれらの外側で、予算・納期・体制・関係者調整といった枠組みを管理する立場に立つことが多いです。

作業の流れは、おおむね次の順で進みます。

1. プロダクトバックログを作る
   実現したい機能や改善を、優先順位をつけた一覧として並べます。これが作るものの源泉になります。
2. スプリントの計画を立てる
   一定期間（たとえば1〜2週間）で着手する項目を、上位から選んで決めます。
3. スプリントを実行する
   日々の短い確認（デイリースクラム）で進捗と障害を共有しながら開発を進めます。
4. レビューとふりかえりを行う
   期間の終わりに成果物を関係者に見せて意見をもらい、進め方自体の改善点も話し合います。

成果物としては、プロダクトバックログ、スプリントバックログ、動く増分（インクリメント）、ふりかえりの記録などが残ります。PMの関心事は、この反復のリズムが崩れていないか、見えている範囲の優先順位が関係者の期待とずれていないか、という点に向きます。

アジャイル開発で起こりやすい問題は、形式だけを取り入れて中身が伴わない状態です。デイリースクラムが単なる進捗報告会になり、障害の相談が出てこない、ふりかえりが毎回同じ反省で終わり改善につながらない、といった形が典型です。

• 優先順位の決め手が曖昧になる
  プロダクトオーナーの役割が実質的に機能せず、誰も順番を決め切れないと、バックログがただの要望置き場になります。
• スコープと納期の両方を固定してしまう
  作る範囲も期日も動かさない前提だと、反復の利点が失われ、名前だけアジャイルの短い区切りになりがちです。
• 完成の基準が共有されない
  どこまでやれば終わりかの定義（完了の定義）がないと、動いたように見えても品質のばらつきが残ります。

PMの立場では、こうした兆候を早めに拾うことが役割になります。反復のたびに動くものが出ているか、関係者がレビューに参加しているか、ふりかえりで決めた改善が次に反映されているかを見ることで、形骸化を防ぎやすくなります。契約や予算の枠組みと反復のリズムが噛み合っているかも、見ておきたい点です。

比較するときは、軸を先に決めると混乱しにくくなります。ここでは、計画の立て方、要件変更の扱い、成果物が出るタイミング、という三つの軸で見ていきます。

• 計画の立て方
  ウォーターフォールは要件定義から順に工程を一度流す前提で全体計画を固めます。アジャイル開発は全体の見通しを持ちつつ、詳細は反復ごとに決めていきます。
• 要件変更の扱い
  ウォーターフォールでは変更管理の手続きを通して慎重に扱う対象です。アジャイル開発では次の反復で取り込む前提で、変更そのものは起こるものとして扱います。
• 成果物が出るタイミング
  ウォーターフォールは後工程でまとまった成果が出ます。アジャイル開発は反復ごとに動く部分が出ます。

どちらが優れているという話ではなく、向き不向きがあります。要件が明確で変更が少なく、工程間の役割分担がはっきりしている案件ではウォーターフォールが扱いやすい場合があります。要件が動きやすく、早く使って確かめたい案件ではアジャイル開発が合いやすい傾向があります。実務では両者を組み合わせる形も見られ、PMは案件の性質に応じて進め方を選ぶ判断を求められます。

アジャイル開発の経験は、プロジェクトマネージャーとしての市場価値を考えるうえで説明材料になりやすい領域です。ウォーターフォールの工程管理に加えて、反復のリズムを保ちながら優先順位を調整した経験を語れると、担当できる案件の幅を示しやすくなります。ただし、枠組みの名前を挙げるだけでは伝わりにくい面があります。どんな関係者がいて、どこで優先順位がずれ、どう合意を作り直したか、という具体の動きまで言葉にできると、進め方を理解したうえで管理していたことが伝わりやすくなります。転職を検討する際は、自分がどの進め方でどの役割を担ったかを、成果物や関係者の構図とともに整理しておくと、面接での説明がぶれにくくなります。

アジャイル開発はドキュメントを作らないのですか。

作らないわけではありません。動くソフトウェアを重視するという考え方であって、文書の全否定ではないです。必要な設計や完了の定義、バックログは残します。目的に合わない過剰な文書を減らし、判断に使う情報へ絞る、という整理の仕方が実態に近いです。

プロジェクトマネージャーはアジャイル開発で何をするのですか。

役割の線引きは案件で異なりますが、予算・納期・体制・関係者調整といった枠組みの管理を担うことが多いです。反復のリズムが崩れていないか、優先順位が期待とずれていないかを見て、契約や予算の前提と進め方が噛み合うよう整える動きが中心になります。

スクラムとアジャイルは同じ意味ですか。

同じではありません。アジャイルは反復して作るという考え方の総称で、スクラムはそれを実現する具体的な枠組みのひとつです。スクラムのほかにも進め方はあり、スクラムを採用しているからアジャイル、と機械的に結びつけると実態を見誤ることがあります。