課題駆動型開発を提案します！：開発プロセス再入門（10）（3/3 ページ）
実際にソフトウェア開発をマネージするときには、非常に多くの側面に注目しながら、プロジェクトの現在の状態を監視していかなくてはなりません。本連載では、特にビルドと不具合の追跡という側面に焦点を当て、なるべく具体的なプロセスを解説するように努めましたが、いかがだったでしょうか。今回は、ここまでに解説してきたプロセスを簡単にまとめ、皆さんが開発プロセスを改善するための具体的なアプローチを紹介します。
課題駆動型開発における文書のモデル
以下に、課題駆動型開発における文書のモデルを示します。これは、各文書の静的な構造をクラス図で表したものです。各文書が持つ属性（＝項目）は、略記しています。
リリースノートは、現在プロジェクトがどのビルドを開発しているのかをモデル化するための、特別な文書です。リリースノートという名前に違和感があれば、この文書をビルドノートと呼び替えてもよいでしょう。
Issueの各サブ文書は、それぞれ別の書式と状態の遷移を持ちます。たくさん書く文書であればあるほど、その書式が重要なものとなります。また、文書は一度書いたら終わり、ではありません。段階的に詳細化し、その解決と確認を追跡し、また現実世界のプロジェクトの状態を正しくモデル化し続けられるように、文書にはメンテナンスが必要です。つまり、文書は状態を持ちます。
ただし、いまのところは、私もすべての種類の課題について、書式と状態がこうあるべきという答えを持ってはいません。私は、いろいろな課題について、「ソフトウェア開発における課題の書式と状態のパターン」をカタログ化してまとめられないかと考えています。そのようなものをご存じの方は、ぜひytsuda@msd.biglobe.ne.jpまでご連絡ください。
文書が書式と状態を持つことについて、以下に具体的な例を紹介しましょう。
デザインパターンに見る文書の書式
デザインパターンは皆さんにおなじみのものと思いますので、詳細な説明は割愛します。ここで注目したいのは、デザインパターンを記述している文書の書式です。デザインパターンの本当の価値は、すべてのパターンを同じ書式でカタログ化したことにある、と私は考えています。以下に、デザインパターンの書式を紹介します（各項目の意味は割愛します）。
- 名前
- 目的
- 別名
- 動機
- 適用可能性
- 構造
- 構成要素
- 協調関係
- 結果
- 実装
- サンプルコード
- 使用例
- 関連するパターン
かのデザインパターン本では、すべてのパターンを上記の書式でカタログ化し、まとめています。この書式にならって、新しく発見したパターンを追加していけるのです。この書式の創案が、デザインパターンに大きな価値を与え、デザインパターンを「パターン」と呼べるものにしています。この観点からいえば、Martin Fowler氏のアナリシスパターンには書式が決められておらず、メタな視点でパターンを定義できていません。つまり、アナリシスパターンは、デザインパターンに比してへっぽこなものであると断言します（Fowler氏は日本語が読めませんから、断言してみても大丈夫でしょう）。
RFCに見る文書の状態
RFC（Request for Comments）とは、IETF（The Internet Engineering Task Force）が策定するインターネットの各種プロトコルに関する標準仕様を定めた文書のことです。RFCには通しのID番号が付けられており、このID番号でRFCを一意に特定できます（例えば、電子メールメッセージの書式の仕様はRFC 822が規定しています）。どのRFCも、すべて決められた状態遷移を経て正式な仕様（勧告）になります。この状態には、次のものが用意されています。
- メモ（Note）
- 草案（Working Draft）
- 勧告候補（Candidate Recommendation）
- 勧告案（Proposed Recommendation）
- 勧告（Recommendation）
最初は［メモ］という状態です。仕様が詳細化されるに従って次の状態に遷移します。この連載で紹介したビルドと同じく、候補（Candidate）という状態があることにも注目してください。最終的に［勧告］となったRFCが正式な仕様となり、インターネットを利用する世界中の人に対してこれを守ることが強く推奨されます。仕様を記述するための文書にも状態があり、このライフサイクルを管理すべきものであることが分かりますね。
ソフトウェア開発において記述すべき文書は、どんなものであれ、状態を持ちます。社内で開発プロセスを統一しようとする活動においては、まず文書の書式を統一することがよくあります。そのアプローチは、非常に正しいものですが、それだけでは不十分です。その文書がどのような状態を取り得るのか、どのような状態遷移を通して文書が詳細化されるのか、解決されるのか、凍結されるのかを検討する必要があります。文書は、書き手の意図を正しく読み手に伝えるために書くのですから、その文書の対象読者が、その文書を担当する担当者となります。誰が何のために読むのかを意識すれば、その文書の状態を正しく設計することができるでしょう。
開発プロセスとは
あらためて、開発プロセスとは何か、簡単にまとめます。開発プロセスとは、複数のロール（役割）やアクティビティ（作業）、アーティファクト（成果物）などから構成される、ソフトウェア開発を支援するための工学的な方法論です。ソフトウェア開発には、職人的（エンジニア）な側面と工学的（エンジニアリング）な側面が含まれていますが、開発プロセスはこの工学的な側面を支援するものです。新人プログラマであっても、達人プログラマであっても、本連載に示した作業の実施手順はまったく変わらないことに注目してください。以下に、優れた開発プロセスや、プロセスに関するコミュニティを列挙しておきますので、ぜひ学習してみてください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このほかにも、多くの開発プロセスが提唱されています。これらの開発プロセスのうち、どれか1つだけを選択しなければならないというわけではありません。実は、どんなプロセスであれ、必ずカスタマイズが必要なのです。本連載においても、ビルドをリリースする頻度、ビルド番号の書式、ビルド曜日とリリース曜日、不具合報告書の書式と状態など、非常に多くのパラメータをご紹介しました。いろいろなプロセスを学習したうえで、それぞれのいいとこ取りをし、皆さんの組織に合ったプロセスを作り上げてください。
この連載の第1回「だれも書かなかった反復型開発のホントの姿」でご紹介した論文「伽藍とバザール」から重要な一節を再度引用して、これまでの連載を締めくくりたいと思います。
「はやめのリリース、ひんぱんなリリース。 そして顧客の話をきくこと。」
これこそが、反復型開発の神髄です。つまり、
- 可能な限り早く、最初のビルドをリリースすること
- 継続して、頻繁にビルドをリリースすること
- 顧客（QA）からのフィードバックを得て、少しずつ段階的に仕様を詳細化すること
ビルドとは、配置可能で（インストール手順が決まっていて）、実行可能なソフトウェアのことです。これを頻繁にリリースしながら、顧客（クローズドな開発においては、QA）から継続的なフィードバックを受け、その後の開発を方向付けていきます。反復型の開発プロセスにおいては、テストは開発の最後にやるものではありません。インクリメンタルにテストケースを追加しながら、開発とテストを並行して進めるプロセス、これが反復型の開発プロセスなのです。ぜひ、皆さんも反復型のソフトウェア開発計画を立ててみてください。
今回で、本連載は終了です。長い間お付き合いいただき、ありがとうございました。またどこかでお会いしましょう！
この記事に対するご意見をお寄せください
managemail@atmarkit.co.jp
著者紹介
▼津田義史
5年間、某外資系ソフトウェアベンダでパッケージ製品の開発とグローバリゼーションに従事。その後、オブジェクト指向技術に疑問を感じ、2000年に豆蔵に入社。現在は、コンサルティングを通して、間違った開発プロジェクトをみることが多く、改めてソフトウェアというものが難しい仕事であることを実感する毎日。興味の対象は、C++のテンプレートを使った静的な多態性の活用だが、最近はC++のコードを書く機会そのものが少ない。
Copyright © ITmedia, Inc. All Rights Reserved.