次世代プロビジョニングシステムの開発に、アジャイル手法を導入する。「やったことがない」チームに、3ヶ月でアジャイルを浸透させるプロジェクトが始まった。
Read the Story
次世代通信インフラの開発は、要件が固まる前に始めなければならない時代になっていた。
ある大手通信会社が、次世代プロビジョニングシステムの開発を決めた。
次世代NW（ネットワーク）スライスや次世代基地局への対応——これらは、仕様が完全に固まる前から開発を進めなければ、市場への対応が間に合わない。従来のウォーターフォール型開発（要件定義→設計→実装→テストの順番で進める）では、スピードが出ない。
しかし、開発チームは長年ウォーターフォール型で仕事をしてきた。
「最初に全部決めて、その通りに作る」——この考え方が、チームの文化として根付いていた。「途中で仕様が変わったら困る」「完璧な設計書がないと開発できない」——アジャイルへの移行には、このメンタリティの変容が必要だった。
「うちのチームは優秀です。でも、アジャイルで動くためのマインドセットが、まだない。技術力の問題ではなく、仕事の進め方の問題でした。」——プロジェクト関係者の証言（匿名）
アジャイルコーチングは、座学ではなく実践から始まる。
担当したエキスパートは、アジャイル開発体制の構築経験を持つPM専門家だ。
彼のアプローチで特徴的なのは、「アジャイルを教えること」より「アジャイルで一緒に動くこと」を重視することだ。
座学でアジャイルの概念を教えても、実際の開発プロジェクトでは使えないことが多い。重要なのは、実際のプロジェクトの中でアジャイルを実践し、振り返り、改善する——この経験を積むことだ。
「スクラムのルールを全部覚えてもらう必要はない。大事なのは、『短いサイクルで試して学ぶ』という感覚を、身体で覚えてもらうことです。」
アジャイルの研修より、アジャイルの実践が先だ。
担当エキスパートが選んだアプローチは、「研修ファースト」ではなく「実践ファースト」だった。
最初の2週間で、最小限のスクラムチームを組成し、実際の開発タスクをアジャイルで回し始めた。
スプリントは2週間。毎スプリントの終わりにレビューと振り返りを実施する。「動くソフトウェアを2週間で届ける」というプレッシャーを、最初から経験させた。
「最初のスプリントは、ぐちゃぐちゃでいい。ぐちゃぐちゃになった理由を振り返ることが、アジャイルを学ぶ最速の方法だ。」
最初のスプリントは、案の定、計画通りには終わらなかった。
見積もりが甘かった。タスクの依存関係を見落としていた。「完了」の定義が曖昧だった——これらの失敗を、2週間後の振り返りで丁寧に整理した。
「この失敗から何を学ぶか」をチームで議論することが、アジャイルの文化を作る最初のステップになった。
3ヶ月は短い。でも、正しくやれば、チームは変わる。
5名のコアチームでスクラムを開始した。
プロダクトバックログの作り方、スプリントプランニングの進め方、デイリースタンドアップの運用——これらを「教える」のではなく、「一緒にやりながら調整する」形で進めた。
「バックログの書き方を1時間説明するより、実際に書いてみて、『ここが曖昧だから修正しよう』と言う方が、10倍速く伝わる。」
2ヶ月目は、スプリントの質を上げることに注力した。
ベロシティ（チームの生産性指標）のトラッキングを開始し、見積もり精度を改善した。また、「完了の定義（DoD: Definition of Done）」を明確化し、品質の基準を統一した。
チームの5名から12名に拡大するタイミングも、この月だった。新しいメンバーへのオンボーディングを、既存メンバーが主導する形で実施した——チームが「自走し始めた」最初のサインだった。
3ヶ月目の目標は、「エキスパートなしで動ける体制」を作ることだった。
スクラムマスターとプロダクトオーナーの役割を、チームメンバーが担えるようにした。振り返りのファシリテーションも、チームが自主的に行えるようになった。
3ヶ月後、エキスパートがプロジェクトから離れたとき、チームはスプリントを止めなかった。
短期間でのアジャイル導入は、成果より「状態の変化」で測られる。
3ヶ月のアジャイル導入プロジェクトで、最も重要な成果は「チームが自走した」ことだ。
エキスパートがいなくなった後も、スプリントが止まらない。振り返りが続く。改善が積み重なる——これが、アジャイル導入の成功を示す唯一の証明だ。
「最初は『アジャイルって何をすればいいんですか？』と聞いていたメンバーが、3ヶ月後には振り返りのファシリテーターになっていた。これが全てです。」——担当エキスパート（匿名）
開発のスピードも上がった。ウォーターフォール型では「要件定義完了まで開発できない」という状態だったが、アジャイル型では「動くものを2週間で届ける」サイクルが回り始めた。
アジャイルは、手法ではなく文化だ。文化の変容なしに、アジャイルは機能しない。
アジャイルの概念を理解してから実践するより、実践しながら理解する方が、定着が速い。
最初のスプリントは失敗してもいい。失敗から学ぶプロセスそのものが、アジャイルの文化を作る。
アジャイル開発で最も重要なプラクティスのひとつが、「完了の定義（DoD）」の明確化だ。
「何ができれば完了か」を全員が同じように理解していないと、品質のバラつきが生まれる。DoD の設定と共有は、アジャイル導入の最初にやるべき作業だ。
アジャイル導入の成功は、「導入できた」ではなく「チームが自走している」で測られる。
スクラムマスターやプロダクトオーナーの役割をチームメンバーが担えるようになること——これを最初から目標として設定し、3ヶ月で実現することが、アジャイル導入PMの役割だ。
アジャイル開発の導入を検討している企業に向けて。
ひとつでも当てはまる方へ
アジャイル導入は、ツールやプロセスの問題ではなく、チームの文化変容の問題だ。
外部のアジャイルコーチが短期間チームに入り、「一緒にやりながら文化を変える」——このアプローチが、最も定着率が高い。
ExpertMatchを通じて、アジャイル体制構築の経験を持つPM型エキスパートをアサインできる。初回相談は無料。