だれも書かなかった反復型開発のホントの姿：開発プロセス再入門（1）

[津田義史（豆蔵），＠IT]

下流工程における開発プロセスの復習

　昨今、開発プロセスについての関心が大変に高まっています。しかし、開発プロセスに関する文章をいくつか読んでみると、抽象的で分かりにくいものが多く、具体的にどうしたらいいんだろうとお考えの読者もおられるのではないでしょうか。開発プロセスとは、もっとずっと具体的かつ実践的なものであるはずです。

　本連載では、ソフトウェアの開発プロセスを具体的に、特に下流工程に主眼を置いて説明していきます。あえて上流工程に着目しない理由は、これが非常に難しい仕事だからです。要求仕様の獲得と分析はドメインによっても難易度が異なりますし、ソフトウェアの設計は属人的なスキルや経験、計算機に関する技術的な知識などに頼らなければならないことも多いものです。

　ですから、このあたりの作業を単純にプロセス化することは困難で、どんなドメインにも適用できる上流工程の開発プロセスの案出というのは非常に難しいと考えられます。無理に作ってみたら、RUPのようにカスタマイズして使うことが前提となるような、大変大きく重たいものになってしまうかもしれません。ドメインによっては、上流工程のソフトウェア開発の作業というのは複雑すぎて、ルーチンワークとして抽出できる作業を見つけることができず、単純な「プロセス」に落とし込むことはできないかもしれません。皆さんが、皆さんのドメインに合致した開発プロセスを作り上げることはとても価値のあることですが、それは簡単ではなく、この文章で説明できることの範囲を簡単に超えてしまうでしょう。

　これに対し、ソフトウェアの開発プロセスの下流工程においては、開発プロセスの定型化がずっと簡単で、しかも確実に役に立ちます。RUPだろうが、XPだろうが、Agileだろうが、どんな開発プロセスを採用したところで、ソフトウェア開発の下流工程は非常に似通ったものになります。もちろん、それでもドメインによって開発の下流工程をカスタマイズしていく必要が皆無というわけでは全然ありませんが。

　筆者は、複数の外資系ソフトウェアベンダで開発業務に従事したことがありますが、どの企業も下流工程においては非常によく似たプロセスで開発を行っていることに大変驚いた経験があります（それらの企業が開発していたソフトウェアのドメインが似ていたということも、理由の1つかもしれません）。ひるがえって、日本ではソフトウェアの開発プロセスが企業によってまちまちで、開発工程に対するコンセンサスが取れていないと感じています。企業によっては、同じ社内であってもプロジェクトごとにソフトウェア開発の工程そのものや、工程を指す概念、用語が異なっている場合もあるのではないでしょうか。

　そこで、皆さんがソフトウェア開発現場における上流工程のプロセスを分析するといった難しい仕事に取り組む前に、下流工程の開発プロセスをこの連載で復習していただければ幸いと思います。

ロールの種類

　開発プロセスを解説していく前に、このプロセスの中でソフトウェア開発に従事する人たちのロール（役割）とその呼称を規定しておきます。ロールとは帽子のようなものなので、状況に応じて別の帽子をかぶり分けることができるものです。つまり、1人が複数のロールを担当しても問題ありません。ただし、同時にかぶることができる帽子は1つだけなので、別の帽子をかぶりたいときは、いまかぶっている帽子を（一時的に）脱がなければなりません。開発作業に従事するときは、いま、自分がどの帽子をかぶって開発に参加しているのかを意識しておく必要があるということです。

［プロジェクトマネージャ］ 一番偉い人。全メンバーを統括する棟りょう ［開発者］ 作る人。Developer、Devとも呼ばれる ［開発マネージャ］ 開発者の棟りょう ［QA］ 検証する人。Quality Assurance。QE（Quality Engineer）、テスターとも呼ばれる ［QAマネージャ］ QAの棟りょう ［ビルド担当者］ ビルドの担当者。Build Master。ビルドの担当者は開発プロセスを学習しやすいため、新人の開発者がこのロールを（も）担当することが多い

　大ざっぱに過ぎるようですが、取りあえずこれで十分だと思います。各ロールのより具体的な責務は、本連載中で少しずつ明らかにしていきます。

反復型開発の復習

　さて、本連載で解説する開発プロセスは皆さんおなじみの「反復型開発」と呼ばれるものです。この開発プロセスはウォーターフォール型開発プロセスの以後に登場したものですが、XPやRUP、Agileなどのプロセスが登場するずっと以前から使われています。どんな開発プロセスを使ってソフトウェアを作っても、ソフトウェア開発の下流工程は非常に似通ったものになると述べましたが、この似通っている部分がすなわち、トラディショナルな反復型開発プロセスと呼ぶべきものです。

　このプロセスはソフトウェア開発の上流工程、つまりさまざまなドメインを分析する際のモデリング技法については何一つ規定しません。ソフトウェア開発の上流工程がトレンドですが、上流の「開発プロセス」として紹介されているものは、実はそのほとんどが「モデリング技法」であって、「プロセス」とは異なるもののようです。モデリングの概念とプロセスの概念はほとんどきれいに直交しており、どんなモデリング技法を選択して顧客のドメインを分析しようが、どんな開発プロセスを選択するかということには関係がありません。

　実際のところ、いわゆるオブジェクト指向技術を使わなくても、反復型の開発プロセスを導入することは可能です。ソフトウェア開発の上流工程においてはより「モデリング」が重要であり、下流工程では「プロセス」の方がより重要になってくるということです。これが、ソフトウェア開発の上流工程よりも、下流工程を形式化する方がずっと簡単である理由の1つかもしれません。少なくとも、オブジェクト指向が、最初は実装技術から始まって設計技術、分析技術に発展してきたように、開発プロセスも下流工程の方から方法論と呼べるものが完成されてきているように感じます。

「伽藍（がらん）とバザール」、あるいは反復型開発の有効性

　ところで、「伽藍とバザール」（The Cathedral and the Bazar）という、Eric S. Raymond氏による有名な論文があります。http://cruel.org/freeware/cathedral.htmlで山形浩生氏による名訳が読めるのでぜひ一読をお勧めします（本当に素晴らしい訳ですが、Cathedralの訳語としては伽藍よりも大聖堂の方が好ましいと思います）。この論文は、ドッグイヤーと呼ばれるコンピュータ業界では、すでに相当に古いものですが、ソフトウェアの開発コストと品質について、多くの示唆が得られます。

　簡単に説明すると、この論文はソフトウェアの開発方法には伽藍（大聖堂）方式とバザール方式の2つがあり、バザール方式の方が品質の良いソフトウェアを安く開発できるということを主張しているのです。

　伽藍（大聖堂）方式とは、ソフトウェアをあたかも大聖堂を建てるときのように、中央集権的に開発する方式のことです。親方（棟りょう）に当たるロールのスタッフが、開発に携わるメンバーたちの進ちょくを管理し、役割を与えてシステマチックに分業させ、建てるものが傾かないように監視しながら、荘厳なものを上手に組み上げるといった感じのやり方です。

　これに対してバザール方式とは、いわゆるオープンソースの開発モデルを指しています。誰もが開発に参加できるようにソースを公開し、外部の優秀なエンジニアたちを大勢巻き込み、みんなで騒々しくソースコードをいじり倒して、わーっと作っていくやり方です。そんなの、とてもうまくいかないような気がしますが、Raymond氏はバザール方式で開発したことにより成功したソフトウェアを複数挙げることで、これが非常にうまくいくことを例証しています（そのようなソフトウェアの代表がLinuxです）。ただし、特定のユーザーのために、がちがちにカスタマイズしたソフトウェアをバザール方式で開発するのは無理があります。シンプルかつ強力で、汎用的な、世界中の優秀なエンジニアたちがとても便利だと感じて使ってくれるソフトウェアを開発するには、バザール方式が適しています。あるいは、ネットワークインフラやデバイスドライバのような水平的なソフトウェアを開発するときも、バザール方式はうまく機能するでしょう。一方、垂直方向に特殊化されているために、大勢のユーザーが使おうとは思わないであろうソフトウェアを開発するときにはバザール方式を適用することは困難です。まして、われわれのユーザーはコンピュータの専門家（＝エンジニア）ではないことがほとんどです。

　反復型開発は、この2つの方法の間に位置付けられるもので、いわば「伽藍でバザール」（The Bazar in the Cathedral）方式ともいうべき開発プロセスです（中間とはいっても、相当に伽藍方式寄りではありますが）。石工の棟りょうは、素晴らしい大聖堂を建てるという魅力的な目的を示すことで、半人前の石工たちに建築の動機を与え、彼らをうまく分業させながら、現場の一切をさい配します。クローズドなソフトウェアを伽藍（大聖堂）方式で開発するのはやむを得ないことですが、これにバザール方式の良い部分、適用可能な部分を取り入れていくことはできます。すると、自然に反復型の開発プロセスを発見することになります。チームメンバーの動機付けや「目玉たくさん効果」（目玉が多い方が伝統的なマネジメントよりも、バグの見落としや細部の見落としに対してはずっと効果的）などの点においても、くだんの論文が説明するバザール方式から重要な示唆が得られますが、この論文から得られる最も重要なヒントは、ソフトウェアの品質を高めるためには「早めのリリース、しょっちゅうリリース」をしなければならないということです。

　反復型開発とは、細かいリリースを何回も繰り返しながら開発を進める手法のことです。反復の期間は、1週間もしくは1日という程度の細かさです。反復の単位が1週間と聞いて、短すぎるのではと感じたあなたは、おそらく本当の反復型開発を経験したことはないということになります。

　次回から、具体的に反復型開発の方法を説明していきます。お楽しみに。