アジャイル開発

アジャイル開発が広がった背景には、開発の途中で要件が変わることを避けきれない、という現実があります。市場や利用者の要望は動きますし、作っている最中に「本当に必要だったもの」が見えてくることも少なくありません。最初に立てた計画どおりに一気に作り切る進め方だと、途中の変化を取り込みにくく、完成した頃に狙いとずれてしまう場合があります。

そこでアジャイル開発では、短い期間の中に「計画・設計・実装・テスト・確認」をひとまとめにして回し、そのたびに動く成果物を確認します。区切りごとに方向を見直せるため、変化に合わせて優先順位を組み替えやすくなります。手戻りを一度に大きく発生させるのではなく、小さく気づいて小さく直す、という考え方だと捉えると分かりやすいでしょう。

ここでのPM（プロジェクトマネージャー）の役割は、開発チームが反復に集中できる環境を整えることと、関係者との合意形成を継続的に行うことに寄ります。一度の要件定義で終わらせるのではなく、優先順位の議論を繰り返し引き受ける立場だと考えると、担う仕事の輪郭がつかみやすくなります。

アジャイル開発の進め方は、大きく次の流れで回ります。軸は「誰が・何を・どの順で・どんな成果物で」です。

• やることの一覧をつくる：実現したい機能や要望を一覧にまとめ、優先順位をつけます。この一覧は固定ではなく、状況に応じて並べ替えていきます。
• 短い期間の計画を立てる：一覧の上位から、次の反復で扱う分だけを選び出します。欲張らず、確実に終えられる範囲に絞るのが要点です。
• 設計・実装・テストをまとめて行う：選んだ範囲について、設計から確認までを一つの反復の中で進めます。反復の終わりには動く状態を目指します。
• 関係者と一緒に確認する：できあがった分を関係者に見せ、意見を集めます。ここで得た気づきを次の一覧の並べ替えに反映します。

登場人物としては、要望の優先順位を決める役、実際に作る開発チーム、そして進行を支えるPMが基本です。成果物は、要望の一覧、動くソフトウェア、そして反復ごとの振り返りメモが中心になります。作った機能そのものだけでなく、次にどう進めるかの判断材料が残っていく点が、この進め方の要になります。

アジャイル開発は自由度が高いぶん、運用でつまずく形もはっきりしています。よく見られるのは次のようなものです。

• 「計画がない」と誤解する：反復ごとに見直すことを、計画を立てない言い訳にしてしまう例です。実際には短い計画を何度も立て直しており、無計画とは異なります。
• 優先順位が決まらない：一覧に要望を積むだけで順位づけが曖昧だと、反復のたびに何から手をつけるか迷います。決める役を明確にしておく必要があります。
• 反復に詰め込みすぎる：短い期間に多くを入れると、終わらない分が積み残り、動く成果物を確認できないまま次へ進んでしまいます。

PMとしては、これらを一人で抱え込まず、優先順位を決める役や開発チームと役割を分けておくことが助けになります。特に、関係者に「途中でも動くものを見せ、そこで方向を直す」という前提を早めに共有しておくと、後半での大きな手戻りを減らしやすくなります。合意の場を反復のリズムに組み込んでおくと、運用が安定しやすくなります。

ウォーターフォールとの違いは、比較軸を先に決めると整理しやすくなります。ここでは「計画の立て方」「変化への対応」「成果物を確認する時期」の三つで見ていきます。

• 計画の立て方：ウォーターフォールは最初にほぼ全体の計画を固めます。アジャイル開発は全体の方向を持ちつつ、詳細は反復のたびに決めていきます。
• 変化への対応：ウォーターフォールは後工程での変更に手間がかかりやすい一方、アジャイル開発は変化を前提に優先順位を組み替えます。
• 成果物を確認する時期：ウォーターフォールは終盤にまとまった形で確認する場面が多く、アジャイル開発は反復ごとに小さく確認します。

どちらが優れているという話ではなく、対象に向くかどうかが判断の軸になります。要件が安定していて工程の見通しを立てやすい場合はウォーターフォールが合うこともありますし、要望が動きやすく早めの確認が効く場合はアジャイル開発が向きます。PMは、案件の性質を見て、どちらの考え方を軸に置くかを選ぶことになります。

アジャイル開発の経験は、PMのキャリアでいくつかの形で活きます。まず、要望の優先順位を関係者と繰り返し調整した経験は、限られた時間と人手の中で「何を先にやるか」を決める力として説明できます。これは開発以外の場面でも通用する判断力です。

次に、動く成果物を早めに見せて反応を確かめる進め方に慣れていると、大きな計画を一度に固めるより、小さく試して直す仕事の運び方が身につきます。転職の場面では、扱った案件の規模だけでなく、変化にどう向き合い、関係者との合意をどう積み重ねたかを具体的に語れると、進め方の理解度が伝わりやすくなります。手法の名前を挙げるより、実際に行った調整の中身を話すほうが説得力を持ちます。

アジャイル開発とスクラムは何が違いますか。

アジャイル開発は、短い反復で進める考え方全体を指す言葉です。スクラムはその考え方を実践するための具体的な枠組みの一つで、役割や会議の持ち方などが定められています。アジャイルという大きな方針の中に、スクラムという進め方がある、という関係で捉えると整理しやすくなります。

アジャイル開発では計画を立てないのですか。

立てないわけではありません。全体をあらかじめ固定しない代わりに、短い反復ごとに計画を立て直します。何度も計画を見直すため、むしろ計画に触れる回数は多くなります。無計画とは異なり、変化に合わせて計画を更新し続ける進め方だと理解するのが適切です。

どんな案件にアジャイル開発が向きますか。

要望が動きやすく、早めに動くものを見せて反応を確かめたい案件に向く傾向があります。反対に、要件が安定していて工程の見通しを最初に固めたい場合は、別の進め方が合うこともあります。案件の性質を見て、どちらの考え方を軸にするかを選ぶとよいでしょう。