ソフトウェアの本質的難しさ

ソフトウェア開発に関する名著の1つに，1987年にFrederic P.Brooks, Jr.が書いた「銀の弾丸はない：ソフトウェア工学の本質と課題」があります。本章では，この論文をもとに，プロトタイプの持つ意味と可能性を，現代的な文脈の中で再度考察してみたいと思います。

先の論文では，どんなに新しい技術が出てきても，狼男に対する「銀の弾丸」のように，それ一発ですべての問題が解決するキラーソリューションは存在しない，ということを主張しています。そして，残念なことに20年経った今でも，この命題は正しいようです。オブジェクト指向，パターン，UML，コンポーネント，SOA，MDA，Java，Ruby，アジャイル，…などなど，どんどん新技術，新手法が登場しては注目を浴びるのですが，どれひとつとして「決め手」として一発で狼をしとめることはできていないのです。

なぜでしょうか？ それは，ソフトウェアが「見えない」こと，「⁠抽象的である」ことが本質的難しさを生んでいると考えられます。

同論文から引用（※1）します。

ソフトウェアそれ自体の本質とは，…（中略）…，これらの概念構造体は，表現が異なっているだけで同じものであり，抽象的な存在だということである。にもかかわらず非常に正確に詳細に記述される。私は，ソフトウェア構築の難しさは，概念構造体の仕様化，設計，評価試験であって，…（中略）…，概念構造体の設計がいまだに難しいとなると，ソフトウェアを構築するのは常に困難だということになる。本来，銀の弾丸というものはないからである。

※1）

和訳は，『⁠ソフトウェアエンジニアリング論文集80's デマルコ・セレクション』（⁠児玉公信 監訳／翔泳社／ISBN：4798110612）より。

そして，この本質的難しさを，図1に挙げる4つに特定しています。

ソフトウェアは，（1）複雑であり，（⁠2）外界に順応する必要があり，（⁠3）変更が常におこり，かつ，（4）目に見えないものです。よく，ソフトウェア開発を建設・土木事業と同種にあつかうことがありますが，このメタファでは，複雑だが目に見えず，抽象構造体であり，変更が常に起こるという現代のソフトウェア開発は捕らえきれません。ソフトウェア開発は，人間が文明の中で始めて扱う種類の難しさだといえるでしょう。

プロトタイプの有効性

そこで，「⁠プロトタイプ」という手法が，この難しさにどのように有効でしょうか。Brooksは，「⁠銀の弾丸への期待」として，「⁠Adaのような高級言語」「⁠オブジェクト指向プログラミング」などを挙げ，さらに「ソフトウェアの概念的本質への有望な挑戦」として，「⁠プロトタイピング」「⁠インクリメンタル開発」などを挙げています。

ソフトウェアシステムを作る上で，最も困難なことは，何を構築すべきかをあらかじめ正確に決定しておくことである。…（中略）…ソフトウェア問題に対し，現在，最も有望な技術的な活動で偶発的でなく本質的な対策となるものは，プロトタイプの手法を繰り返すことで要求の仕様化を行うラピッドプロトタイピングの手法とツールの開発である。…（中略）…現在のソフトウェアの入手方法は，おおむね，前もって満足のいくシステムを仕様化でき，構築の入札を得て，実装し，据え付けるという前提で成り立っている。私はこの前提が基本的に間違っており，そこから多くのソフトウェア取得上の問題が起きていると考えている。…（中略）…その解決策とは，プロトタイプと製品の仕様策定と開発を反復することである。

Brooksは，ソフトウェアが複雑であり，さらに不可視であることから，仕様の決定自体が非常に難しいことを指摘しています。そこで，現在の仕様化，入札，実装，納品，という手順でできるという前提を根本的に問題視しています。そして，その最も有望な解決手法の1つとして，プロトタイピングとインクリメンタル開発を位置づけているのです。これは，現代においてアジャイルが注目されている事情そのものです（※2）⁠。

※2）

本記事では，引用にあるソフトウェアの調達や契約に関する問題には触れないでおきますが，ここにも本質的な課題があることは間違いありません。

プロトタイピングの役割は，このように不可視のものを見えるようにすることで，「⁠仕様の決定自体を助ける」というものです。人間は，見たこともないものを想像だけで詳細化することを苦手としています。完全でなくとも形や動きとして具現化することで，人間はその意味を理解します。プロトタイピングは，この理解の道具であり，仕様のやりとりのツールであると捉えられています。できたものを見せることで起こる会話（仕様情報の交換）が本質的に重要なのです。もう1つは，「⁠本当にできるだろうか？」という「作る側の不安を取り除く」役割です。どんなに魅力的な仕様を作っても，与えられた技術と予算の中で実現できないこともあります。プロトタイプはこの技術的リスク（技術的隘路）を早期につぶす役割も持っているのです。

アジャイルの台頭とプロトタイプ

2000年代にはいって，「⁠アジャイル開発」が注目されています。日本の中では未だメインストリームにはなっていませんが，とくにインターネットを使ったビジネスを行うサービス型のユーザ企業の中で，Salesforce.comのように内部のソフトウェア開発を全面的にアジャイルに変える企業も目立ってきています（※3）⁠。

※3）

BtoBのSaaSモデルで900,000サブスクリプションという成功を収め、日本にも進出しているsalesforce.com（セールスフォース）が、わずか1年で企業の開発全体をアジャイルに変え、リリース頻度を年1回から四半期1回にまで短縮したという報告があります。

このような文脈の中で，プロトタイプは以前と違った使われ方をしています。以前のプロトタイプは「使い捨て」であり，プロトタイプのコードは製品のコードにしないのが普通でした。あくまで，「⁠見栄え」や「技術的なポイント」を実装してそこからアイディアを得たら，捨ててしまうものです。逆に，プロトタイプはアーキテクチャをしっかり構築していないため，プロトタイプを元に製品コードを作っていくことは危険が大きいというわけです。

しかし，アジャイル開発では，「⁠コードを育てる」というモデルが前提になっています。プロトタイプから始まったものを，徐々に太らせていきます。プロトタイプをデモし，それについて意見をもらう形で仕様を明らかにしながら育てていくのです。

これができるようになったのは，「⁠オブジェクト指向技術」⁠，「⁠動的言語」の役割が大きいでしょう。小さくシンプルな構造をどんどん変更することによって，アーキテクチャを創発させること。機能を追加するときに，全体が汚くならないように，常に設計を見直して手直しをすること（リファクタリング）⁠。そして，前に作った機能がちゃんと同じように動くことを保証すること（テスティング）⁠。さらに，最近人気のある動的なスクリプト言語を使って，プログラムの中にあるノイズをできるだけ減らして，人間にわかりやすくシンプルにすること。そして，それを支援するRuby on Railsのようなアーキテクチャに特化したフレームワーク。─これらがそろった現在では，プロトタイプを「仕様決めの使い捨てモックアップ」ではなく，「⁠将来の製品に育てる最初の種」と捉えています。そして，成長させ続けることがソフトウェア開発だ，という捉え方です。

Brooksは，もし，ソフトウェアが複雑すぎて事前の仕様化，というやり方そのものに問題がある場合，ソフトウェア開発のモデルを根本的に変える必要があると言っています。そして，彼自身1958年に，「⁠書く」から「構築する」というモデルの変遷を身をもって大きなシフトを感じたと言っていますが，そこからさらに「成長させる」というモデルへシフトさせる必要があると発言しています。そして，これはそもそも，アジャイル開発が基礎としている考え方です。