すばしこき この世界

2001年頃から、ソフトウエアのアジャイル開発手法という言葉を聞くようになりました。注目された「スクラム」の提唱者ジェフ・サザーランドは大野耐一のトヨタ生産方式(TPS)に着想を得たとしていますが、「一人一人が無駄をなくす意識を持ち、常に改善を心がける」といった背景の思想に触発されたのであって、TPSもスクラムも、適用に当たってはテーマや適用範囲の設定には細心の注意が必要だと思います。

かつて自分が担当者・プログラマとして関わった車両制御の組み込みソフト開発では、確かにウォーターフォールモデルやV字開発に固執する上司に違和感を感じており、（アジャイルという言葉が工学分野で使われる前のことですが、）「ソフトそのものが仕様書」「正式な仕様書は後回し」などといって、特に寒冷地試験の時は集中的にデータを取り、それを使ってどんどんアルゴリズムを追加していくなど、今でいうアジャイル開発に近い考えで取り組んでいたように思います。

但し、当時の比較的簡単なシャシー制御のプログラム（最初は1万ステップ程度のアセンブラ言語で一人で担当できました）といえども、対象はブレーキという極めてミッションクリティカルなものですので、スクラッチからアジャイルでやる訳ではなく、全体のアーキテクチャやハードウエアに存する部分の枠組み（あるいは大日程）をまずしっかり作り、つまりアジャイルにやる範囲をまず定義して、日々の（シミュレーションはパラメタ適合までの精度が出ないため）実際の試験車による実験で得られるデータを使いカイゼンのループを速く回していく、車の試作時期などに同期して仕様まとめ／リファクタを行う、といった事だったと思います。



一部のアジャイル手法で違和感があるのは、最後のドキュメントや仕様、一般的な設計の言葉でいうrationale（根拠：どうしてその設計・仕様に決めたのか）の記録と伝承を軽視しているように見えることです。分厚い設計仕様書や検討書は残念ながら誰も読まないということは「その通り」と思いますので、ソフトであれば適切なコメント、図面であればその図面にハイパーリンクで簡潔なメモが残っていることが望ましいと思うのです。機械CADのCATIAにはそのような機能があり、少なくとも一時はTRIZのアイデアデータベースとのリンクすらできたと記憶しています。こういう工夫がないと、社内向けのいつまでも手直しし続ければよいようなソフトはいいですが、自動車のBSWや少しづつバリエーションを増やし長く広く使っていこうという多くのシステム（ハードとの関わりの深い組込み系ならなおさら）となると、再現性・展開性が担保できず困ってしまうはず。優秀な「スクラム」チームを長期間維持することは極めて困難ですので、「動かない（保守できない）システム」を生み出す温床にすらなり得るのでは？（人材の流動性の高い米国では特に深刻な問題のはず。）

もう一つは、冒頭に書いたような適用対象です。サザーランドの著書「スクラム」には「トヨタは構想から完成まで十五ヶ月間でプリウスを開発した」という全く事実に反することが宣伝のように書かれていますが、純粋なソフトウェアプロジェクトに対しても賛否両論、いや、「成功例もあるようだ」という程度の「スクラム」の状況に照らして、あまりに罪作りな誤解を招く表現と言えます。

ちなみに、私が、日本人ではあまりなじみのないアジャイル（agile）という英単語に触れたのは、’94-'96の米国留学中に、本当にすばしこかった長男（当時1-2歳）を見た米人の友達に"He’s so agile!"と言われた時でした。その時、 "You need a leash!" （犬みたいにリードを付けないと！）とも言われたのですが、これは、上記の「アジャイル開発は、その適用範囲を定義すべし」に通じることなのかもしれません。こじつけ気味ですが。