1980年代の「最適化の呪縛」から脱却する　短期に小さく始めることが組織アジャイルの第一歩

ゴールが不確定なときに福音となるアジャイル

アジャイルという言葉がソフトウエア開発の現場で使われ始めたのは、今から20年ほどさかのぼる2000年代初頭。当時ソフトウエア開発のフローは、「作るものを決める→仕様と作り方を決める→開発する→できたものをテストする」が主流だった。それぞれのフェーズごとに内容を精査して顧客と合意し、合意したあとは前のフェーズには戻らない。一つひとつのフェーズに完璧を期することで、間違わずにゴールに至ることができると考えられていた。

ところが、その方法がうまくいかない場面が出てくる。顧客がアウトプットのイメージを持っていないときだ。ずっと最前線にいた市谷聡啓さんに当時のようすを聞いた。

「何が正解なのかわからない場合、この方法で進めていっても待っているのは作り直しか、顧客が泣き寝入りするかの結末です。そうした状況に対応するために用いられたのが、短期間、たとえば1週間でやるべきことの計画を立てて実行し、達成できたことを確かめ、その上で次の1週間の方向性を決定していくという方法でした。これがアジャイルの原型になります。今、いろいろな人がアジャイルを定義していますが、私は『現状をよく見る→取るべき行動を判断する→取り組む、というサイクルを短い期間で小さく試していくこと。そしてその結果から次の判断や行動をより適切なものにしていくこと』に尽きると考えます」

ソフトウエア開発の業界から始まったこの手法は、なぜ広く他業界の組織にまで広がっていったのか。それは、VUCAの時代がもたらしたゴールの決めづらさに、企業が新たな解決手法を求めたからだ。市谷さんは、多くの企業でアジャイル開発のサポートを行った経験から、環境の変化に対応し切れない企業に共通する傾向を、「最適化の呪縛」と見ている。