課題駆動型開発を提案します！：開発プロセス再入門（10）（3/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が正式な仕様となり、インターネットを利用する世界中の人に対してこれを守ることが強く推奨されます。仕様を記述するための文書にも状態があり、このライフサイクルを管理すべきものであることが分かりますね。
ソフトウェア開発において記述すべき文書は、どんなものであれ、状態を持ちます。社内で開発プロセスを統一しようとする活動においては、まず文書の書式を統一することがよくあります。そのアプローチは、非常に正しいものですが、それだけでは不十分です。その文書がどのような状態を取り得るのか、どのような状態遷移を通して文書が詳細化されるのか、解決されるのか、凍結されるのかを検討する必要があります。文書は、書き手の意図を正しく読み手に伝えるために書くのですから、その文書の対象読者が、その文書を担当する担当者となります。誰が何のために読むのかを意識すれば、その文書の状態を正しく設計することができるでしょう。
開発プロセスとは
あらためて、開発プロセスとは何か、簡単にまとめます。開発プロセスとは、複数のロール（役割）やアクティビティ（作業）、アーティファクト（成果物）などから構成される、ソフトウェア開発を支援するための工学的な方法論です。ソフトウェア開発には、職人的（エンジニア）な側面と工学的（エンジニアリング）な側面が含まれていますが、開発プロセスはこの工学的な側面を支援するものです。新人プログラマであっても、達人プログラマであっても、本連載に示した作業の実施手順はまったく変わらないことに注目してください。以下に、優れた開発プロセスや、プロセスに関するコミュニティを列挙しておきますので、ぜひ学習してみてください。
| ASD（Adaptive Software Development） |
| プロジェクト管理に重きを置く、アジャイルなソフトウェア開発方法論です |
| CMM（Capability Maturity Model） |
| 組織の成熟度を5つのレベルに分類し、段階的に組織を育てていく方法論です |
| DSDM（Dynamic Systems Development Method） |
| 短期間で業務における価値を開発するための、フレームワークを提供します |
| FDD（Feature Driven Development） |
| モデル主導の短期反復型開発プロセスで、設計と構築を2週間単位で繰り返します |
| LD（Lean Development） |
| ムダを省いてサイクルタイムを短くする、トヨタ生産方式にヒントを得た開発方法論です |
| Scrum |
| 毎月マイルストーンを設定してソフトウェアを開発する、プロジェクト管理重視のプロセスです |
| TDD（Test Driven Development） |
| テストでソフトウェア開発を駆動する方法論です |
| UP（Unified Software Development Process） |
| 複数の開発プロセスを統一した（と主張している）プロセスです。Rational社（IBM）は、この独自の実装であるRUPを販売しています |
| XP（Extreme Programming） |
| 12のプラクティスを可能な限り極大（extreme）に実施することで、プログラミングの効率を上げます |
| アジャイルプロセス協議会 |
| 日本において、アジャイルプロセスの普及活動をしています |
| 要求開発アライアンス |
| オープンな要求開発方法論 (openthology) を体系化し、提供しようとしています |
このほかにも、多くの開発プロセスが提唱されています。これらの開発プロセスのうち、どれか1つだけを選択しなければならないというわけではありません。実は、どんなプロセスであれ、必ずカスタマイズが必要なのです。本連載においても、ビルドをリリースする頻度、ビルド番号の書式、ビルド曜日とリリース曜日、不具合報告書の書式と状態など、非常に多くのパラメータをご紹介しました。いろいろなプロセスを学習したうえで、それぞれのいいとこ取りをし、皆さんの組織に合ったプロセスを作り上げてください。
この連載の第1回「だれも書かなかった反復型開発のホントの姿」でご紹介した論文「伽藍とバザール」から重要な一節を再度引用して、これまでの連載を締めくくりたいと思います。
「はやめのリリース、ひんぱんなリリース。 そして顧客の話をきくこと。」
これこそが、反復型開発の神髄です。つまり、
- 可能な限り早く、最初のビルドをリリースすること
- 継続して、頻繁にビルドをリリースすること
- 顧客（QA）からのフィードバックを得て、少しずつ段階的に仕様を詳細化すること
ビルドとは、配置可能で（インストール手順が決まっていて）、実行可能なソフトウェアのことです。これを頻繁にリリースしながら、顧客（クローズドな開発においては、QA）から継続的なフィードバックを受け、その後の開発を方向付けていきます。反復型の開発プロセスにおいては、テストは開発の最後にやるものではありません。インクリメンタルにテストケースを追加しながら、開発とテストを並行して進めるプロセス、これが反復型の開発プロセスなのです。ぜひ、皆さんも反復型のソフトウェア開発計画を立ててみてください。
今回で、本連載は終了です。長い間お付き合いいただき、ありがとうございました。またどこかでお会いしましょう！
この記事に対するご意見をお寄せください
managemail@atmarkit.co.jp
著者紹介
▼津田義史
5年間、某外資系ソフトウェアベンダでパッケージ製品の開発とグローバリゼーションに従事。その後、オブジェクト指向技術に疑問を感じ、2000年に豆蔵に入社。現在は、コンサルティングを通して、間違った開発プロジェクトをみることが多く、改めてソフトウェアというものが難しい仕事であることを実感する毎日。興味の対象は、C++のテンプレートを使った静的な多態性の活用だが、最近はC++のコードを書く機会そのものが少ない。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
人気記事ランキング
- 管理職なら年収2000万円超え サイバーセキュリティという困難だが“もうかる仕事”
- “生成AI依存”が問題になり始めている 活用できないどころか顧客離れになるかも？
- Microsoft DefenderとKaspersky EDRに“完全解決困難”な脆弱性 マルウェア検出機能を悪用
- 生成AIは2025年には“オワコン”か？ 投資の先細りを後押しする「ある問題」
- AI市場は約7000億円規模に 2024年以降の成長率はどう推移する？ IDC予測
- 投資家たちがセキュリティ人材を“喉から手が出るほどほしい”ワケ
- Microsoft、脆弱性の開示に向けて業界標準の体系を採用 大改革がもたらすメリット
- 「アダルトビデオが無料です」――IE標的のトロイの木馬に要注意
- 江崎グリコ、基幹システムの切り替え失敗によって出荷や業務が一時停止
- 「Copilot for Securityを使ってみた」 セキュリティ担当者が感じた4つのメリットと課題
ITmediaはアイティメディア株式会社の登録商標です。