アジャイルな思想が変える社会の未来予想図

アジャイルの考え方はソフトウェア開発以外のどのようなシーンで活用できるのか、具体例を挙げてみよう。

たとえば、あなたがダイエットをして理想の体型を手に入れたいとする。

どのように計画を立てるだろうか？
まず現在の体重、体脂肪率、筋肉量、腹囲などの数値（メトリクス）を計測し、各メトリクスの目標値を立てるのではないだろうか。
そして、各メトリクスの目標値に近づけるよう、運動や食事のメニューを考えることになるだろう。

運動や食事のメニューが適切かどうか、多くの場合、体重や筋肉量を計測するなどして現状把握に努めるだろう。
また、各メトリクスの目標値を追いかけるばかりだけではなく、鏡で自分の全身を見て、全体としてバランスが取れているかについても気を配るだろう。
例えば理想とは異なる部位に筋肉がついてきたとすれば、運動メニューの見直しを行うだろう。
もし数値に届かなくても自分の体型に満足がいくならば、そこでダイエットをやめることもあるだろうし、過度なダイエットになるようであれば、目標とした数値の見直しを行うだろう。

そう、私たちはアジャイル開発を知っていようが知っていまいが、自分の過去の行動を振り返る術は知っているし、現実のアセスメントをして目標を軌道修正することを知っている。
日常生活において、アジャイルはきわめて身近なものといえるのである。

先ほどダイエットの卑近な例を挙げたが、ものづくりの現場でもアジャイルは浸透しはじめている。
アジャイル開発に向いているプロダクトの特徴として、市場のニーズに適合するためにフィードバックを得ながらゴールを常に修正する、変更が容易であるといった特徴があげられる。 
そのため、製造業ではアジャイル開発はまず向かないと考えられてきた。
しかし、カプセル化、関数化をすれば、ハードウェアであろうが、ソフトウェアであろうが、原理的に変更容易性は向上するはずであり、アジャイル開発を行う技術的基盤は整うはずなのである。 

どういうことか？

各パーツを部品化（＝関数化）して、ほかのパーツと接続するインターフェース仕様を決める（＝カプセル化）。
インターフェース仕様や部品は徹底的に規格化し、交換を容易にする。
たったこれだけだ。こうすれば、ほかの部品に取り換えても大丈夫である。

部品化して依存関係を極力排除すればパラレルに開発を進行することができるので、製造期間の短縮も見込める。
また、個々の部品のインターフェース仕様さえ変わらなければ、ある部品の修正や改良はほかの部品に影響を及ぼさないので、心置きなくおこなえる。

どんな企業がこれらを実践し、高速な開発を実現しているかといえば、その最たる例はかの有名なテスラである。
通常、自動車会社は2年、3年でおこなうマイナーモデルチェンジをテスラは毎日一回以上、おこなっていることが知られている。

具体的には、
・毎日60個の部品を追加生産し販売
・毎日61個の部品が削除(エレクトロニクス、ソフトウェア含む)
・一日60個の部品ソフトウェアがリリース
というのである。

このスピード感をもって、2日で変更、設計、テスト、リリースまでやってしまう。
モデル3とモデルYの充電ポートは3時間でアップデートされたというから驚きだ。まさに地球上最速である。

テスラではスクラムをもう使わない。スクラムはどんなに短いスプリント期間でも1日であり、それより高頻度のリリースでは有用ではないからだ。

テスラの例のように、従来では考えられないほどの開発スピードはどうやって実現しているのだろうか。
一つの重要なファクターは「予算のサイクル」である。

一般的に、ウォーターフォール開発の場合、予算の計画から見直しまで一年以上かかる。お客様からのフィードバックを受けて投資する領域を軌道修正したり、金額を柔軟に変えることができなければ、イノベーションを起こすにはほど遠い状態になってしまう。
１年といわずとも、四半期毎、月次に予算計画を立てる場合もあるだろう。
だが、四半期に一回計画を見直そうとしても、初めのころに何を思って予算を計画したのか、たいていの場合覚えてはいない。
テスラはこのようなオーバーヘッドを許さない。さまざまな分析データに基づいて予算配分をリアルタイムに変え、投資領域を変えるのである。
なぜこれほどまでの徹底したスピード感が必要なのか？なぜなら、予算のサイクルを超えるスピードでイノベーションは起こせないからだ。
予算を執行するタイミングで承認をとり、事業計画を考えていては、イノベーションを起こすには程遠いだろう。
マイナーモデルチェンジを１日に複数回行うために、１年単位で予算計画を作成していては精度が悪すぎることは明らかだ。

上記のテスラの例で見た通り、製造業においても、リリース頻度の向上に向けた取り組みを組織全体でおこなっている。

それに引き換え、多くの身近なソフトウェア開発の現場はどうだろうか。
手の付けられないスパゲティ構造のコード、ソースコード行数の肥大化を招くコピペコードが散見される。
ソースコードの部品化や規格化は進まず、変更容易性はどんどん下がっていく。リグレッションテストは書かれず、埋め込まれた不具合の発見は遅れていく。ソースコードはハードウェアのようにわかりやすく形があるものではないため、このような状態になっていることにはた目から気づきにくく、可視化する努力を怠ると現状の把握すら難しい。

一旦スパゲティ状になってしまったコードを修正するために資金を投入することはきわめて非現実的だ。
なぜなら、コードの設計思想が変わらない限り、次の改修で再度クリーンでないコードが追加される可能性が高いからだ。モグラたたきのような対応に毎回資金を投入する意思決定をすることはありえない。追加改修を前提とした設計思想を整えない限り、技術的負債はこのようにして積み重なっていくことになる。
これではリリース頻度を上げることは難しく、イノベーションは起きにくいだろう。

どれも解決が難しいうえに、抱えておいてもいまのシステムは稼働しているので、あえて触れる必要はないと思われるだろうか？
ご自身の企業ではテスラのようにリアルタイムに予算配分を変え、毎日60個の部品を生産するようなことをしたら大混乱を招くので、現状を維持するほうがよいと思われるだろうか？
テスラでは現実味が感じられないみなさんのために、現実のソフトウェア開発で何が起きているか、冒頭のダイエットの例で言えば次のようになるだろう。
ダイエットの目標数値の設定は非常に難しいので、調査を実施し、体重、体脂肪率、筋肉量、腹囲の一般的な値を設定する。
そして、各数値目標に向かって運動や食事のメニューを計画する。 優先事項は数値目標が一つでも多く達成できることであり、最悪、期日までにすべての数値が目標に達していればよい。
いつの間にかダイエットの目的は理想の体型を手に入れることではなく、それぞれの数値を追いかけることが目標になっている。
全身で見たときのバランスという視点が抜けおち、運動や食事のメニューは過度なものになりかねない。

個々のタスクを期日までに終わらせることが目標になる。
コードはコピペされ、開発品質は低下しているのに、現状がどれだけ悪い状態なのか全体を見通せる人がいない。テストは遅れ、チームが疲弊する、ウォーターフォール型プロジェクトマネジメントの典型的な失敗例では、自身のダイエットの場合では起きると思えないようなことが起きているのだ。

しかし、裏を返せば、日常生活でごく当たり前にアジャイルに親しんでいるともいえるのであるから、アジャイルにことさら難しさを感じる必要もない。
難しいといっている間に皆さんの現場と先端領域にある企業との差はすでに開いており、手を打たないとどんどん広がっていく。
始めるなら早いほうが良いだろう。 

私たちは知らず知らずのうちにアジャイルの考え方を取り入れて生きている。
またテスラの例では、日常生活や、製造業など、ソフトウェア開発とは遠いところでもアジャイル開発・運用が採用されていることを見てきた。
近未来においては、製造業も含めた先端競争領域すべてが、より高速なアジャイル開発・運用が主流になるだろう。物理プロダクトも数日の単位でモディファイとリリースが繰り返されるようになるかもしれない。

わたしたちソフトウェア開発の現場も、アジャイルの恩恵をより受けられるように変化していく必要があるだろう。