JTCではアジャイルと言いつつ外注を多用する理由

アジャイルを始めて数年経つ。

社内資料にはスクラムという言葉が出てくる。スプリントもある。デイリーもある。スプリントレビューも、レトロスペクティブも、予定表には入っている。JiraやAzure DevOpsにはバックログが並び、バーンダウンチャートらしきものも作られている。

だから会社は思っている。

うちはもうアジャイルをやっている、と。

この思い込みが一番きつい。

本当は、数年前にアジャイルを始めたのではなく、スクラムっぽい予定表を導入しただけだった。イベント名だけは変わった。会議体も変わった。開発計画の単位も、月単位からスプリント単位になった。だが、顧客の反応を見て判断を変える文化は育っていない。作ったものから学び、次の優先順位を変える筋肉も育っていない。

なんちゃってスクラムは、数年かけて社内に定着する。

これが厄介だ。始めたばかりなら、まだ分かっていないと言える。ところが数年やると、本人たちは経験者の顔をし始める。スプリントを回した経験がある。POを置いた経験がある。レビューもレトロもやってきた。そういう言葉だけが積み上がる。

その結果、アジャイルを分かっていない人が、アジャイルを分かった前提で意思決定する。

この状態で開発が思ったほど速くならない。品質も安定しない。リリース前に手戻りが出る。レビューで詰まる。受入で揉める。顧客の要望が増え、バックログは膨らむ。すると会社は、スクラムの中身を点検する前に、体制強化という言葉へ逃げる。

そこで外注が増える。

開発の一部を外へ出す。テストを外へ出す。画面実装を外へ出す。やがて機能単位、チーム単位で外部パートナーに任せ始める。社内では、内製だけではスピードが足りない、専門性を借りる、品質を安定させる、という説明が付く。

その説明には、ある程度の正しさがある。外部の力が必要な場面は確かにある。専門性を持つ人を一時的に入れる価値もある。だが、JTCのなんちゃってスクラムで起きている外注多用は、そこまで健全な話で済まない。

社内が学習していない穴を、外注で埋めている。

ここを見落とすと、話がぼやける。

アジャイルは、高速な学習を繰り返すことで、正しい方向に最短距離で近づこうとする行為だ。速く作ることだけが目的なら、ただの作業加速で終わる。品質を上げることだけが目的なら、ただの工程改善で終わる。アジャイルの芯は、短い周期で現実を見て、判断を更新するところにある。

なんちゃってスクラムの会社では、ここが抜け落ちる。

スプリントレビューでは、できました報告が行われる。POは顧客価値を問う人というより、説明役や受入担当になっている。ステークホルダーは感想を言う。課長や部長は進捗を確認する。フィードバックはバックログに戻るが、優先順位を変えるほどの判断にはつながらない。

レビューで拍手をもらっても、次の判断が変わらないなら、それは発表会だ。

レトロスペクティブも同じだ。KPTを書く。付箋を貼る。改善アクションを決める。だが、次のスプリントで本当に変わるのは会議の時間か、テンプレートか、連絡方法くらい。設計の粗さ、POの判断遅れ、受入条件の甘さ、レビュー観点の弱さ、品質基準の不在には踏み込まない。

こうして、スクラムの外形だけが残る。

数年やっても、会社の判断力は太くならない。顧客の反応をもとに機能を削る判断ができない。技術的負債を返す判断ができない。リリース後の問い合わせから、プロダクトの仮説を見直す判断ができない。何を作るかを決める場と、何を学んだかを受け止める場がつながっていない。

そこへ外注が入る。

外注先は、与えられた範囲で成果物を作る。設計書が浅ければ質問する。仕様が揺れれば確認する。受入条件が曖昧なら、想定を置いて進める。だが、プロダクトの方向そのものを引き受ける立場にはない。顧客の反応を見て、事業判断を変える責任も持たない。

それなのに社内は、外注先が入れば開発が回ると期待する。

この期待が、かなりしんどい。

なんちゃってスクラムを数年続けた会社は、アジャイルを学んだつもりになっている。だから、うまくいかない原因を自分たちの理解不足に置かない。POの責任が曖昧だからだ、と言い切れない。スプリントレビューが進捗報告に変質しているからだ、と見に行かない。バックログが顧客価値ではなく社内要望の倉庫になっているからだ、と認めない。

代わりに、人が足りないという話になる。

人が足りないから遅い。スキルが足りないから品質が安定しない。社員だけでは回らない。外部の力を借りる必要がある。そう言えば、経営層にも通りやすい。調達も動く。予算も付く。体制図もそれらしくなる。

だが、人数を増やしても学習は増えない。

むしろ、学習しない組織に人を増やすと、確認と調整が増える。仕様確認会が増える。レビュー待ちが増える。受入の説明が増える。社員は判断者になるどころか、外注先から上がってくる成果物の確認係になっていく。プロダクトを前に進めている感覚より、未読チケットとレビュー依頼に追われる感覚が強くなる。

ベロシティを買ったつもりで、判断待ちの列を伸ばしている。

ここで外注先を責めても筋が悪い。多くの場合、問題の根は発注側にある。何を作るかを決めきれていない。なぜ作るかを言語化できていない。どこまでできたら価値があるのかを定義できていない。何を検証したいのかも曖昧なまま、作業だけを渡す。

その状態で、スプリント単位でお願いします、と言う。

これはアジャイルというより、小分けにした発注だ。

小分けにした発注は、一見アジャイルに見える。2週間で成果物が出る。毎回レビューがある。バックログもある。変更にも対応しているように見える。だが、その場で学習が発生していなければ、ただの短納期案件の連続になる。

外注を使うなら、社内に残すものを先に決める必要がある。

実装を依頼してもいい。テスト自動化を依頼してもいい。クラウド基盤の一部を依頼してもいい。だが、プロダクト判断、優先順位、品質基準、設計思想、顧客理解まで外へ流したら、社内には管理作業だけが残る。

管理作業だけ残った社員は、アジャイルの担い手になれない。

ここが、JTCのきついところだ。

会社は社員にアジャイルをやらせたい。だが、社員に任せるには時間がかかる。学習も必要になる。失敗から立て直す経験も必要になる。POは発注担当の延長では務まらない。開発者も、チケットを消化するだけでは済まない。レビュー、設計、運用、顧客理解まで引き受ける必要が出る。

そこで会社は、外注を増やす。

社員にアジャイルをやらせたいと言いながら、社員がアジャイルを学ぶ機会を外へ逃がしている。これが矛盾の芯だ。

なんちゃってスクラムが数年続いた会社では、アジャイルがすでに社内用語として消費されている。だから、今さら基礎から学ぼうという空気になりにくい。スクラムガイドを読むことすら、初歩に戻るようで格好がつかない。POとは何か、スプリントレビューとは何か、Doneとは何か。そこを問い直すと、過去数年の取り組みが薄かったことまで見えてしまう。

だから、問い直さない。

この沈黙が一番重い。

上層部は、アジャイルを導入済みの施策として扱う。管理職は、既存のプロジェクト管理にスクラム用語をかぶせる。現場は、形だけのイベントを回しながら、実態としては従来の受託型開発に近い動きを続ける。外注先は、その枠組みの中で成果物を出す。

全員がそれなりに忙しい。だから、誰も根本に触れない。

本気で変えるなら、最初に見るべきは外注比率ではない。社内の学習比率だ。

スプリントの終わりに、何を学んだか。顧客の反応で、何を削ったか。品質問題から、どの基準を変えたか。外注先の成果物を受け取ったあと、社内にどんな知識が残ったか。POが次の判断を変えたか。開発者が設計の選択理由を説明できるか。

ここに答えられない会社が、外注を増やしてもアジャイルには近づかない。

むしろ、なんちゃってスクラムが強化される。会議は増える。チケットは増える。レビュー依頼も増える。体制図は立派になる。だが、顧客価値に近づく判断は太くならない。会社の中に、プロダクトを引き受ける人間が育たない。

アジャイルを数年やった会社ほど、最初に疑うべきものがある。

自分たちは本当に学習してきたのか。

この問いを避けたまま外注を増やすと、現場にはまた新しい役割名と管理表だけが増える。PO、SM、開発チーム、外部パートナー、スクラムイベント、バックログ、ベロシティ。名前は揃う。予定表も埋まる。

それでも、顧客の反応を受けて判断を変える人がいないなら、アジャイルは社内の飾り棚に置かれたままだ。