第3回：これまでとは「違うやり方」の広まり

今回は「第3回：これまでとは「違うやり方」の広まり」についてご紹介します。

関連ワード （不確実性の時代に、アジャイル開発で向き合っていこう、開発等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。

　前回の「ウォーターフォールに対するアンチテーゼとしての反復型開発とアジャイル」では、ウォーターフォール方式が、それまでの優れたエンジニアの職人芸頼りであったソフトウェア開発に秩序をもたらした一方で、構造的な問題を抱えていたこと、そして、その解決策の1つとして「反復型開発手法」が提唱され、それが2001年に公表された「アジャイルソフトウェア開発宣言」につながっていったところまでを解説しました。

　今回は、ちょうどその時期（1990年代後半～2000年代）に、IT業界で実際に起きていたことを開発プロセスの視点から追ってみます。

　現在では多くの企業システムにおいて使用されている「Linux」が、当時小さなカーネル（オペレーティングシステムの基本機能を担う部分）の開発から始まり、急速に注目を集め始めた1990年代半ば、米国でフリーのソフトウェアプログラマーであったE. Raymond氏は、当時Linux開発の背後にあった新しい思想と動向に注目し、1997年に「伽藍とバザール」（光芒社、1999年）を発表しました。その当時は、まだキラーソフトになるとも考えられていなかったLinuxが世の中を席巻するに至り、Raymond氏がいったい何に気づいたのかは世間の大きな注目を集めました。

　「伽藍とバザール」は、Raymond氏による原文、および野村総合研究所研究員で翻訳家の山形浩生氏による日本語訳の両方ともにコピーレフトで公開されており、ネット上で読むことができます（注1）。その内容を簡潔に要約するとすれば、「ソフトウェア開発は伽藍（大聖堂）を造るが如く、見取り図（アーキテクチャ）に基づきチームが組成され、細かく分担しながらミスをチェックする命令型の『伽藍方式』よりも、バザール（市場）のように公開されたソースコードがあり、それに対してみんなが自由に機能を追加したりバグを取り除いたりしていく『バザール方式』のほうがずっと望ましい結果が出る」ということです。

　（注1）https://cruel.org/freeware/cathedral.html

　本書では、さまざまなソフトウェア開発の取り組みから学んだ19のバザール方式の教訓を取り上げ、ソフトウェア開発における良いプラクティスとそれらが持つ特性の説明で構成されています。全てをこの場でご紹介することは控えますが、いくつか興味深いものをピックアップしてみます。

　6. ユーザーを共同開発者として扱うことは、迅速なコードの改善と効果的なデバッグを実現するための最も簡単な方法である：これは、スクラムやエクストリームプログラミング（XP）における顧客の考え方や、そこから得られるフィードバックの効用を指しています。

　11. 良いアイデアを持っていることの次に良いことは、ユーザーからの良いアイデアを認めること。時には後者の方が良い場合もある：これも、スクラムが提唱するコラボレーションやフィードバックループを通じた学習や改善と本質的には同じことです。

　7. 早くリリース、頻繁にリリース。そして、顧客の声に耳を傾けよ：今日における商用ソフトウェアの修正プログラムの配布など、現在では当たり前に実践されているプラクティスです。

　3. でき上がった 「バージョン」を捨てることを念頭に置いておけ。どのみち、そうする（捨てる）ことになる：一旦作り上げたものが、ニーズの変化や技術的な理由などにより「新たなバージョン」に置き換えられていくことは今日のソフトウェア開発の世界ではごく当たり前の概念でしょう。別の言い方をすれば、「反復」により変化への対応、品質の担保が可能となり、またそうすべきだという考え方です。

　4. 正しい姿勢で臨めば、解決すべき問題は向こうからやってくる（自ずと見つかる）：これは、開発者が持つべきマインドに言及したものですが、本連載の第2回で述べた「正しいことをやる（Do the right thing）」と同じことです。

　これらの教訓を改めて眺めてみると、最も成功したオープンソースソフトウェア開発の1つであるLinuxから得られた教訓の多くが、アジャイル開発の方式にほぼそのまま受け継がれていることに驚かされます。さらに、分かりやすさを優先し、あえて二項対立の形式で表現するとすれば、伽藍方式とは、その当時まで主流であった中央集権的なウォーターフォール方式で、バザール方式とは、自己組織化されたアジャイル方式、と言って差し支えないでしょう。

　最後に2点補足します。1つは、一概に伽藍方式がダメということではありません。例えば、金融の世界で用いられる、大規模かつ複雑な、しかも厳重なセキュリティが求められるシステムを、純粋なアジャイル手法だけを用いて開発するというのはイメージしづらいと思います。そこでは、Big Design Up Front（BDUF）ではないにせよ、アーキテクチャの検討や設計に相応のワークロードが投入され、細かいチェックも必要となるでしょう。