HOME 製品 PERFORCE 技術情報

この文書では、¹ソフトウェア製品に対する変更管理において、私が見つけた最良の方法を 紹介するつもりである。私が説明する方法は、ソフトウェア能力成熟度モデル [CMMI1.02]²のレベル2で述べられたほとんどのキー・プラクティスをカバーしている。それは、要求ド リブンのプロセスであり、特定のプログラミング手法に限定されるものではない。

開発の目標は、製品の価値を上げることである。価値は、その製品市場の顧客によって決定される。もしも、あなたの製品が彼らにとって十分に価値のあるものであるならば、彼らはそれで得た価値の一部をあなたに支払うであろう。

しかし、我々の顧客は常に価値に対する考えを変え続けているため、ソフトウェア・プロジェクトは、急速かつ頻繁に発生する要求変更に直面している。良質な製品というのは、常にそれらの要求を満足させ続ける必要があり、その結果、良質な製品を生産するためのプロセスとは、それらの要求変更を注意深く追跡していくことである。

目標を達成するために、我々がしなければならないことは以下の通りである:

1. 何に価値があるかを理解する,
2. 我々の努力が、その価値に対して注力されているかを確認する
3. 以前のもの以上に価値のあるものを提供する

価値とは何かを理解することは、すべてのプロセスの鍵である。 それは、“要求管理”[CMMI1.02, p86]によって達成される。

要求管理とは、どのように開発側が顧客の望むことを識別するか、ということである。要求管理の主な機能は、顧客の要求を記述したドキュメントを維持管理していくことである。このドキュメントには、顧客が望んでいることが明瞭に記述され、かつ、かつ、会社にとって各々の要求がどの程度の価値があるか見積もった価値量も記述されているべきである。以下にいくつかの要求の例を挙げる:

• 機能;
• 環境、例：製品はWindows NTで動く;
• 他のソフトウェアとの互換性;
• 性能特性、例
  ：その製品は1秒間に10以上のウィジェットが処理できる;
• エンジニアリング特性、例：その製品を維持するために新しい開発者を教育するのに要する期間が一ヶ月以下である;
• 信頼性特性、例：クラッシュが一週間に一回以下である

要求ドキュメントが完全であることは必ずしも必要でなく、本当に重要なものがカバーされていれば良い。定義するために最も重要なことは、通常は機能ではなく、クリティカルな属性である。それらは、追跡したり制御したりするのが最も難しいものである [Gilb88]。先ず、あなたの知っていることから始めなさい。そうすれば追加すべき他の要求もすぐに見つかるであろう。

要求ドキュメントは、顧客の要望と価値についての最良のアイデアを含んでおり、客観的で測定可能な言葉で記述されている。“良くできていること”というのはあまり計測的な表現ではないが、それらは、計測的な各要素に切り分けることは可能であろう。例えば、インストール時間、最初に使えるようになるまでの時間、使い易さ、最初の30分間の経験などである[Gilb88, chapter 9]。

我々が顧客の要求を見つけたときはいつでも、それを要求ドキュメントに追加する。そして、我々はその要求を開発計画に利用する。

要求につきまとう問題として、それらが常に変化しているということが挙げられる。そして、それらの要求との距離は常に縮められてはいるが、決してぴたりとは一致しない。もしも、我々がそれらのすべてを、長い出荷サイクルに合わせようとすれば、我々は望まれていないものを供給しなくてはならないという苦しい立場に立たされるか、出荷できる頃にはすべてが遅すぎてしまう。

一度にすべての要求を満たすような試みは、ビッグバン・デリバリ[Gilb88, pp9-10]と呼ばれている。 開発グループは、ハイパー・スペースに飛び込み、期待された結果のどこか近くに現れることを期待している。製品はバラバラにされ、すべてのものが完了するまで何も動作しない。それらを組み合わせ直して“動くようにする”ために、無駄な“コードフリーズ”が必要となってしまう。さらに、開発サイクルの最終段階に至るまで、製品が試されることがないため、要求や設計およびコーディングにおけるエラーが見つかった頃には、既に手遅れになっている。要求段階でのエラーは修正に最もコストがかかるため、このような開発は非常にリスクを伴う戦略であるといえる。

この問題に対する解決策としては、段階的な計画と出荷[Gilb88, chapter. 7]がある。 考え方はシンプルで、以下のようにまとめられる:

1. 現在のソフトウェアと、今我々が考えている顧客の要求とを比較しなさい。これは、我々に見通し − 向かうべき方向 − を与える。
2. 最小の期間で最大の価値を顧客に提供するために、その方向性の中で最も大きな要求またはリスクに対する措置を講じなさい。
3. 完全な製品（つまり、完全にパッケージ化され、ドキュメントなどが揃っているもの）を出荷しなさい。それは、顧客のすべての要求を満たしていなくとも、前のものよりも格段に良くなっていれば良い。
4. 顧客からの情報を収集しなさい。特に、出荷した製品に対する反応などが重要である。これは、顧客の要求に対し、我々が持っている考えを改めさせるだろう（それも通常かなりの割合いで）。
5. 以上を繰り返しなさい。

これは、段階的な出荷サイクルと呼ばれる。 見通しを立てて、それに対する対処を行い、また別の見通しを立てて、さらに別の対処を行うといった具合である(図2を参照)。 この方法では、変化して行く要求に追随することが必要となるが、たとえ顧客の考えが変わったとしても、顧客が本当に欲しているものに次第に近づいて行けるようになる。このサイクルを短縮すればするほど、我々にとっては都合が良い。³間違った方向に進んで浪費される無駄な努力が減って、より価値のある製品を供給できるようになるからである。

実際、それはちょうど“編集−コンパイル−実行”のサイクルに良く似ている。そのため、すべてのプログラマは、既にこのプロセスについて知っているはずである。プログラマが何かを開発する場合には、結果を試し、考えを修正し、さらに開発を進めるといった手順を踏む。ここでは、我々は製品を“編集”し、それをリリースに“コンパイル”し、顧客がそれを“実行”しているのである。

我々が顧客に対して早くリリースすればするほど、我々の見通しは正確になり、成果物は高品質になる。顧客にとっても、彼らが最も重要だと考えている要求を満たすソフトウェアがすぐに手に入るため満足するのである。

このテクニックのもう一つの特筆すべき点としては、重要な出荷に関する問題を早い段階で解決することである。しばしば、非常に重要な項目が、最後まで忘れられている場合がある。⁴各段階で完全な製品を出荷することによって、我々は、それらをより早く発見し、最終段階でのパニックを避けることができる。納期間際での作業は、欠陥が紛れ込み易く、もしそれが何かクリティカルなものであれば、そのとき製品の品質はより悪化してしまう。

この方法の不利な点としては、事前により詳細な解析と計画を行わなければならないという点と、ソフトウェアを変更するのにより多くの時間がかかるという点だ。利点は、最終成果が望まれているものに非常に近く、不必要な変更や繰り返しの作業で時間を浪費せずに済むという点が挙げられる。私の経験では、利点は不利な点よりも圧倒的に勝っている。問題は、あなたが最初に不利な点を経験してしまうということだ。

いくつかの要求が与えられた時、次のステップはソフトウェアの現在の状態を観察し、それと要求とを比較することである。もしも現在の状態がわからなければ、どの程度クリティカルな要求を満たしているかについての測定方法を開発することが急務となる。あなたは、これを行うテストを開発できるかもしれないが、いくつかの定性的な測定もまた必要とされる。

状態と要求との間には必ず違いが存在する。リソースは限られているため、一度にすべての要求を満たすことは期待できない。その時に実現できない最も価値のある要求を選び出しなさい。失敗する危険性が最も高い要求に対して、最高の優先度を与えなさい [Gilb88, chapter 6].

ここに具体的な例を挙げる。顧客は、ソフトウェアが新しいプラットフォーム上で動くことを要求している。この要求にはいくつかの改善が必要となる。新しいプラットフォーム上ですべての機能とすべての性能が要求されているか？どれが顧客に対して最も価値があるか？もしも、あなたがそのプラットフォーム上でただ一つか二つの機能しか提供できない場合、それはどれか？最初にそれらを書き留めなさい。

それらの高い優先度を持つ要求を分析して、それらの要求を満たすために必要な作業量を見積もりなさい。できる限りそれらをより管理しやすい（小さな）作業区分に分け、最も影響のある部分を優先度リストの最初に置きなさい。

この段階であなたは、バージョンプランニング−, ソフトウェアプロジェクトプランニング”[CMMI1.02, p97]の手法−を用いて、製品の次のバージョンに対する計画を立てるこ とが可能となる。

一つのバージョンは、製品の仕様が進展していく過程での一区切りである。バージョンはあなたが実際に予定したスケジュールの中で満たそうとした一定の要求サブセットである。バージョンを絶え間なく変わる要求のスナップショットとして考えても良い。

製品の次のバージョンは、事前に選んだ優先度の高い要求を満たすようにすべきである。その後のバージョンは、順次、優先度順に要求を満たすようにしていくべきである。必要な作業見積もりをしているので、それぞれの製品バージョンの出荷時期を計算する事が出来るはずである。次のバージョンは実現し易い範囲に設定し、そのリリース日は出来るだけ近い将来に設定しなさい。もしも、作業したり、見積もりをするのに余りに規模が大きすぎる場合には分割しなさい。これは、製品の設計変更や、最終的な完全実装を目指して、もう少し長期間の開発パスの選択を意味する場合もある。確実に製品を出荷したり計画の変更に対処したりするために、そのような事を行う価値がある。それはまた、プロジェクトが適応できるように、柔軟で変更可能な設計を行うことを強いるだろう。⁵

このような詳細度レベルで計画を立てることに価値があるのは、せいぜい2ないし3バージョン先までであろう。というのも、要求は変更されるものであるし、次のバージョンで再度それに取り組む事になるからである。それよりも先の計画はラフなものにすべきであり、詳細な計画を遠い将来に亘って作成しても、労多くして益少なしである。

重要な要求に対してそれぞれバージョンを指定しなさい。これは、どの属性をどれ位実現しようとしているのかを示している下記の表と同じ程度の簡素なもので構わない（図3を参照）。

製品の価値を上げるために今やるべきことは、次のバージョン仕様へと進化すべきソフトウェアに対し、その変更を制御していくことである。次のバージョンを出すまでの期間は、製品のライフサイクルを考慮して要求を収集し、次のサイクルを計画しなさい。開始と終了については考えずに、継続的な進化と製品の改善について考える事が重要である。

実際に変更管理が関わってくるのはここからである。 図2は、各開発サイクルがどのように製品を顧客の要求に近づけ、価値と品質を上げているかを示している。図3は同じものを別の方法で示している。製品のマスター・コードラインが継続的に顧客の要求へと進化していくのがわかる。

この変更管理プロセスのキーとなるコンセプトは、継続的な改善である。 これは常に要求に対して近づいていく事を意味し、また変更によって要求から遠ざかる事がないように する。これは、たとえ“一時的なもの”であっても、決して機能を取り除いたり、一部の コードを壊したりするような変更を許さないことを意味している。マスター・コードライ ンは常に改善されていかねばならない。実際的な言い方をするならば、これはマスター・ コードラインがいつでもビルドでき顧客にリリースできる状態になっており、マスター・ コードラインが顧客にとって以前よりもっと価値のあるものになることが分かっている事 を意味する。 図4は、 私がこのシンプルな考えを説明するために好んで用いるダイアグラムである。 これは“ソフトウェア構成管理”とはどういうものかについて表している[CMMI1.02, p182]。

これは出荷期限を遵守し易くする。あなたは、いつでも出荷できる状態にある。唯一変動するものは、出荷するものであり出荷時期ではない。マスター・コードラインから生成されるソフトウェアは、常にリリースの準備ができている。重要な要求に作業工数を集中し、柔軟な設計を行い、作業を細かく分割していれば、あなたは常に次の出荷の時点までできうる限り製品の価値を上げ続けているだろう。

この文書の後半では、いかにしてこのような幸福な状況を達成するかを述べることにする。

変更を追跡し管理する目的で、2種類の文書が使われる: 「問題」と「変更」である。

「問題」とは、製品が顧客の要望を満たしていない点について報告された文書である。これは、製品がその仕様に従っていない（欠陥）か、仕様が顧客の要望を表していない（エンハンスメントまたは新規要求）のいずれかである。この違いは顧客にとっては大したことではない。要するにどちらの場合でも、彼らが望む事を製品が提供していないので、変更して欲しいと言っているのである。本文書で述べられているプロセスは“新規開発”と “バグ修正”を同様に扱っている。「問題」は、製品にプロブレムが見つかったときにはいつでも作成される。「問題」はバグ報告書と改善要求を包括する。

「問題」は、変更に対する唯一のきっかけである。変更が顧客に対してその製品を改善 しないのならば、それを行う価値を持たない。インフラの改善であっても、結局は価値を上げる必要がある。

「問題」はマネージメントによって、調査追跡する必要があるかどうかが決定される。それが欠陥である場合は、その影響度に応じてスケジュールされる。エンハンスの場合は、新規要求になる場合もある（要求文書の変更を行う）。

もし、調査追跡する必要があるならば、それらは分析される。問題が注意深く理解され再現される。⁶必要な工数の見積もり値と共に色々な解決方法が提案され、プロトタイプが作成される。次にその「問題」は、マネージメントによって再度検査され、変更を行うか否かが決められる。変更するに当たっては、1つ以上の解決方法が実施される。

変更文書は、製品の修正手順を述べ、何が行われたかを正確に記録する。さらには、実際にその作業によって問題が解決され、本当の改善を製品にもたらしたかをダブルチェックできる。それがチェックされない限り、この変更を製品に反映してはならない。これを実現するには、変更をブランチ上で行いチェックを行った後にのみマージされるようにする（図5参照）。

変更のチェックは、製品の完全性を保つために極めて重要である。それゆえ構成管理に とって重要なステップであるチェックとは、全体の設計戦略に対する変更の適合性をシニ アエンジニアがいかに保証するかという事である。そこは、CMMレベル3のキー・プラクティス[KPA1.1, L3-93]の一つである“ピア・レビュー”⁷のような確認のステップを組み入れるべき格好の場所である。(確認はCMMレベル3 [CMMI1.02, p267]のキー・プロセス・エリアである。) さらにはその変更が、そのグループに対するベスト・プラクティスとして適している かどうか、ソフトウェア品質保証がチェックできる段階でもある。

顧客が製品で欠陥を発見した時には、彼らは可能な限り早く直してもらいたいと思うものだ。技術サポートの指針は、その顧客に対し2、3日以内に修正または回避手段を提供することかもしれない。問題に対する“迅速な修正”ソリューションは、長い目で見た場合その製品にとっての正しいソリューションになるとは限らない。迅速な修正は、しばしば製品全体の方向性との整合性を熟慮しないで始める必要があるからである。製品が山のような応急処置の塊になってしまわないように、こうした修正と問題に対する適正なソリューションとを分離する事が重要となる。

我々は、顧客が既に持っているリリースに対してパッチを当てることで、素早く顧客の問題を解決することができる。これは問題を修正するために、出来るだけ小規模で迅速な変更を行う事を意味する。これは、最新のマスター・ソースコードからビルドしたものを顧客に出荷するよりは良い。というのは、それでは、顧客に問題を引き起こしてしまうような方法で変更されている可能性があるためである。また最新のマスター・ソースコードを出荷する事も危険である。それらは、顧客の環境と互換性のない変更を含んでいる可能性があるからである。また、その仕様が分からないので（従って、どういう事をしようとしているものなのかを顧客に話す事が出来ない）、将来保守するのが容易ではない。それらは、おそらく最後のバージョン以降、十分なテストが行われていない。安定したリリースにパッチを当てることは、迅速で高品質な修正結果をもたらす。これが、）バージョンブランチを推奨する主たる所以である （図6参照)。

バージョン・ブランチは、マスター・ソースコードがバージョン仕様を満たすと考えられる時に、マスターソースコードから分岐を行う事により生成される。（あるいは、締め切り日がきてしまったので、仕様を全く満たしていないが、とりあえず何かものを出荷しなくてはならないような時も、しばしばバージョン・ブランチは生成される。）バージョン・ブランチ上のソースは、バージョン・ソースと呼ばれる。製品のバージョン・リリースは、ラベル付けされたバージョン・ソースから作成される（図6参照）。

製品のリリースは、バージョン・ブランチ上のソースからのみ作成される。ソース制御用ラベルは、そのリリースが再現できるように、リリースの作成元となったソースに印を付けるために使用される。加えて、製品イメージ（顧客に配布されたもの）も保管される。

リリースは決して変更しない。リリースの内容そのもは、そのリリースに関するソース 制御用ラベルが作成された時点でコミットされている。そのリリースに関する問題は、次 のリリースで解決されなければならない。

すべてのリリースが顧客に出荷される訳ではない。リリースは、製品の品質査定の一手段として社内用に作られる事もある。これは、とりわけバージョン・ブランチの最初のリリースに当てはまる。そのようなリリースをテストすることで、バージョン・ブランチに対してパッチを当てなければならない欠陥が往々にして見つかる。

欠陥に対する修正変更は、バージョン・ブランチにおいてのみ行われる。欠陥とは、リリース製品がバージョン仕様を満たしていない箇所を指す。通常“バグ”と呼ばれているものは、この定義に含まれる。⁹ほとんどの場合、製品がその機能の一つを実行出来なくなるものである。ある意味でバージョン・ブランチは、マスター・ソースコードがあるべき要求に向かって進化していくのと同様に、その仕様に向かって進化する (図7参照)。

最も重要な事は、バージョン・ソースは既知の物だという事である。そこからビルドされる製品は、完全にテストされた後でリリースされており、小さい変更は結果が予測可能なものでなくてはならない。こうした理由から、重要なことは余り多くの変更を行わない事であり、修正を行う場合は、顧客が抱えている特定の問題を解決するための必要最小限のものとすべきである。この狙いは、問題を迅速に修正することであり、他の問題を持ち込まないようにすることである。

もちろん、もし欠陥がバージョン内で見つかった場合には、それはおそらく同様にマスター・ソース内にも存在しているので、そこでもまた修正する必要がある(図6参照)。 マスター・ソースに対して行われる修正は、より注意深く計画された変更であるべきである。主に、それは保守が可能な変更で、適切にドキュメント化され、製品のアーキテクチャに留意している必要がある。このマスター・ソースに対する変更は永久に行われる必要があるが、バージョン・ブランチに対する変更は顧客が次のバージョンへアップ・グレードした時点で終了する。

この作業は明らかに重複したものであるが、無駄なものと考えてはいけない。むしろ好機として見るべきである。なすべき事を成し遂げるために、ほとんどの作業は問題の分析に基づいて行われるべきである。そして、問題を修正する為にバージョン・ソースに対してはパッチを当て、マスター・ソースに対しては根本的な治療を施すのである。“迅速な修正”とは顧客に対する回避策の事であるといえるかもしれない。

リリース・コードをビルドした後はテストを行う必要がある。このテストの目的としては 二点挙げられる。このコードが一般のリリースに適合しているかどうかをマネージメント が判断するために、製品と仕様とを比較するという目的と、“ソフトウェアプロジェクト管理” [CMMI1.02, p124]の一部として、計画に対するフィードバックを行う目的である。

受け入れ検査は、バージョン仕様に基いて行われる。バージョン仕様は、製品がどういうものでなければならないか（あるいは、要求とどのように違っているか）ということと、リリースがそれにどのように適合していなければならないかということについて厳密に述べたものである。受け入れ検査開発は、バージョンが計画されるのと同時に、製品の開発と平行して始めることができる。

リグレッション・テストは問題に基いて行われる。各々の問題は一つのリグレッション・テストによってカバーされるが、一つ以上の試験による事もあり得る。テストと問題との関係が明白である限り、多対多の関係があり得る。リグレッション・テスト開発は、ソリューション開発と平行して、問題がどういうものか分析することにより行われる。

ソフトウェアの変更領域に焦点を絞ってテストすることもまた有用である。変更ドキュメントを調査して最新の変更部分に焦点を当て、リグレッション・テストと受け入れテストを行う。

テスト結果と、要求、問題との比較表を作り、バージョン計画テーブル図3参照)と直接比較して、リリースの品質と価値について明確な判断材料を作る。 これにより、上層部は詳細な情報を得た上で一般的にリリースの承認を容易に行うことが出来る。

欠陥(リリースとそのバージョン仕様との相違点)は問題としてサブミットされる。我々は既にバージョン・ブランチを作成しているので、欠陥に対しては9章で説明した方法で素早くパッチを当てることができる。そのため、決して一般的なリリースが著しく遅れるようなことはないのである。

私はこのプロセスを、プランニングやソース管理の全く無い状態から始めて、約20名のエンジニア・チームに対し、およそ12ヶ月で実装した。新しい組織に対しても、各々のスタッフがその基本理念を良く理解していれば、あなたが行おうとするプロセスを実装することは可能である。

これは、まさに我々が Ravenbrook Limitedにて行ったことである。このセクションでは、このプロセスを Ravenbrook でどのように実装したかについて述べることにする。 Ravenbrook はこのプロセスを用いて、Perforce Softwareの商用プロジェクトを仕上げた。そして、Perforce 社は我々がオープンにできる事例としてそれを用いることに快く同意してくれた。Perforce Defect Tracking Integration (P4DTI) プロジェクトは、<URL: http://www.ravenbrook.com/project/p4dti/>で見ることができる。それは、完全で、商業的で、現実的で、なおかつ完全に文書化されたプロジェクトであり、間違いやそれに対する修正も含まれている。それは、プレゼンテーション用に整えられたものではない。あなたは、ここでプロセスの実装における実際を見ることができるであろう。

この文書で述べてきたモデルの実装には、数多くの方法が存在するということを理解しておくのは重要である。私は過去10年間に、3つの異なった組織に対して、3つの異なった方法でこのモデルを実装してきた。様々な種類のデータベースが使用される可能性があるし、形式と実施方法についてもまた、プロジェクトの大きさやスタッフの自覚度に応じて様々なものになりうる。

Ravenbrook では、私は FreeBSD とApache、Perforce上で動作する“情報サーバー”を立ち上げて、さらに Apache を Perforce リポジトリの全内容を処理できるように設定した。私は、Perforce のファイル仕様が、URL と相互互換性で類似しているという事実を用いた(我々のディポは、通常 Perforce リポジトリに対して用いる“depot”ではなく“info.ravenbrook.com”という)。これは、情報の共有を至極簡単にする。プロジェクト・チームの全ビジネスE-mailは、各メッセージ毎にユニークな URL が付けられて保管されている。すべてのドキュメント -- 要求、計画、バージョン、リ リース、問題、変更、設計、手順、テスト、提案、会議の議事録、ソースコード・ファイル -- は Perforce に格納され、URL を用いて参照できるように通常 HTML でインデックスが付 けられている。私は特に、コードから要求、デザイン、変更、問題、E-mail連関までのクロス・レファレンスを推奨する。

ドキュメント名は、クロス・レファレンスの鎖が断ち切れないように注意深く選ばれている。このスキーマは、Tim Berners-Lee の論文 "Cool URIs don't change" [TBL98]で記述されているものに近い。

作業をする際には、全員が手順の“ハンドブック”を使用し [RB98a]、そして、それらの手順はどうすればより効果的なものになるかを学ぶに従って、保守され練成されていく。 我々はまた、これを修正する場合にも、前述のバージョン計画、問題、変更のプロセスを使用している。

プロジェクトの要求は、大きな表を含んだ要求ドキュメントの中で維持される。各々の要求は、他のドキュメント（古いもの及び新しいもの）から常に現在のものが参照できるように、ユニークで再利用されない番号が与えられる。ある要求に対して修正があった場合には、たとえそれが些細なものであっても新しい番号が割り当てられる。

P4DTIの要求は、<URL: http://www.ravenbrook.com/project/p4dti/req/>で見ることができる。いくつかの要求は、そのプロジェクトを遂行している間に陳腐化してしまう。それらは、引き続き参照できるように印を付けられるが、ドキュメントから削除されることはない。要求は、プロジェクトで作成された、設計における決定事項を正当化するものであり、それらの決定事項を説明するために常に公開されていなくてはならない。いくつかのより小さな要求に分割したものもある。オリジナルの要求は保存しておき、新しく分割した要求に対しては新しい番号を割り当てた。P4DTI よりも大きいプロジェクトでは、要求を管理するためにある種のデータベースの導入を考慮するだろうが、基本的な考え方は同じである。

プロジェクトのマスターソースは、Perforce リポジトリ "//info.ravenbrook.com/project/P/master/..."に保持されている。ここでPはプロジェクト名である。マスターソースには以下のものが含まれている:

• ソースコード;
• ユーザードキュメンテーション;
• 設計ドキュメンテーション;
• 製品に関連した手順、例えばビルド手順やりリースの作成およびテスト手順など。;
• テストケース;
• 製品を発展させるために必要ないくつかのツール

現在の P4DTI プロジェクトのマスターソースは、<URL: http://www.ravenbrook.com/project/p4dti/master/>で見ることができる。

マスターまたはバージョンソースは、"//info.ravenbrook.com/project/P/branch/YYYY-MM-DD/T/..."として開発用にブランチされている。ここでPはプロジェクト、YYYY-MM-DDはブランチが作成された日付、そしてTはブランチに対して名づけたタイトルである。一人以上の人間が、そこでその変更に対して作業を行う。このスキーマは、彼らが共同で作業をするための環境を提供し、彼らの進捗状況を記録するために、変更点を彼らのプライベートブランチ上に頻繁に⁸サブミットすることを許可する。

P4DTIプロジェクトブランチは、<URL: http://www.ravenbrook.com/project/p4dti/branch/>で見ることができる。ここではまた、ブランチのリストとそれらのステータスを保持している。

バージョンブランチを生成するための完全なツリーは、"//info.ravenbrook.com/project/P/version/V/..." にブランチされている。ここで、Vはバージョン名である。バージョン名は、任意の規約に従う。Ravenbrook では、常に2つの番号を用いた。最初の番号は、メジャーバージョン番号である。この番号を変更するということは、互換性を失うコード変更のような、大きな製品のステータスの変更を意味する。互換性を保ったエンハンスメントがなされた時には、マイナーバージョン番号が変更される。例えば、製品を正式にリリースした場合には、"0.x"から "1.0"に変更する。これは、"正式サポート" を仕様に追加したと見なすことができる。製品に対して何かを追加した場合には、"1.0" から "1.1" に変更する。他の組織では、私は、完成品に付けられたバージョン番号とはあまり関係のない、内部バージョンのコードネームを用いた。

P4DTIプロジェクトのバージョンは、<URL: http://www.ravenbrook.com/project/p4dti/version/>で見ることができる。

リリースは、バージョンブランチ上のフィックスドポイントからビルドされる。Perforce では、単にリリースがビルドされたポイントを記録するためにチェンジリスト番号を使用する。製品のイメージは、"//info.ravenbrook.com/project/P/release/R/..."に入っている。ここで、Rはリリース名である。リリース名は、任意の規約に従う。Ravenbrook では、バージョン番号の後にリリースレベルを識別するための番号を付加したものを用いた。例えば、"1.1.3" はバージョン "1.1"のリリースである。より数の大きい番号では、以前のリリースで見つかった欠陥が修正されているが、製品がエンハンスされているとは限らない。

P4DTIプロジェクトのリリースは、<URL: http://www.ravenbrook.com/project/p4dti/release/>で見ることができる。リリースを作成するための手順は、<URL: http://www.ravenbrook.com/project/p4dti/master/procedure/release-build/>にある。この手順が製品と共に発展していくことを理解することは重要である。例えば、バージョン1.1からリリースを作成する手順の実際は、<URL: http://www.ravenbrook.com/project/p4dti/version/1.1/procedure/release-build/>にある。

我々は、イシューを保管するためにPerforce ジョブシステムを使用し、イシューとそれらに影響を及ぼすチェンジを結びつけるのに Perforce "フィックス"システムを使用している。Perforce はそのとき、リリースでどのチェンジが作成されたかを我々に教えてくれる。これに加えて、我々はリリースでの変更点を記述したリリースノートを生成するいくつかのツールと、どのバージョンにどの欠陥があったかをレポートするためのいくつかのツールを作成した。

P4DTIプロジェクトのイシューは、<URL: http://www.ravenbrook.com/project/p4dti/issue/>で見ることができる。我々は、各リリースにとっての既知のイシューのクエリーを含む、様々な種類のクエリーをビルドした。

我々が Revenbrook で用いたシステムは極めてシンプルであり、ツールやプロセスを実行するシステムはほとんどなかった。Ravenbrook 社のスタッフは高いレベルでのプロセスに対する自覚を持っていたため、これが可能であった。私の経験では、より混沌とした状況から成熟したプロセスに至ろうとする組織では、より多くのツール、トレーニング、プロセスのドキュメント、執行が必要となる。これらのうちでもっとも重要なものはトレーニングである。あなたのスタッフに理解させてプロセスに参加させるのに代わるものはない。彼らはそれを知的に変え、絶えず改良するための助けになるからである。

この文書では、私がソフトウェア製品開発管理において見出したベスト・メソッドを 説明した。そして、どのようにそれらがソフトウェア能力成熟度指標 [CMMI1.02]と関連するのかについて説明した。

この手法がどのようにソフトウェア設計や作業環境と開発者の態度に影響を与えるのかといったことについて、私が言及しなかったことはたくさんある。また、我々が学習して我々のプロセスハンドブックに組み込んだちょっとした教訓もたくさんある。それらのほとんどは、我々の組織と我々のソフトウェアの問題に特化している。

最も重要なことは、組織が情報システムを使用し、かつ、ソフトウェアそのものと同様に変更可能で進化していく定義されたソフトウェアプロセスを使用する事により、学習し続けていく事にある。製品のように、プロセスはそれが廃棄されるまでは決して終結しない、そしてプロセスの後継者は更に前進しつづける。

¹このペーパはGeodesic Systems社の内部文書[RB98b]を元にしている。

²この文書は "供給者同意管理"または "計測と分析" には触れていないが、この手法はそのまま後者をサポートしている。

³私の管理した約100klocのプロジェクトでは 2ヶ月のサイクルでうまくいった。

⁴ユーザーズ･マニュアルなど。

⁵Tom Gilbは情報システムの管理に対するオープンエンドの設計について議論している [Gilb88]。キーとなるアイデアは予想しなかった方法で変更､拡張をすることが容易な設計を選択することである。

⁶機能拡張については、 問題の"再現"とは新たな機能や振る舞いについての要望をシミュレートすることを意味する。

⁷私はソフトウェア･インスペクション[Gilb95]をレビューの強力な形式として推奨する。

⁸私は、開発者が一体となったグループの修正を行った際には いつでもサブミットすることを奨励する。開発者やその同僚にそれらの修正に伴う仕事の背景となる理由を 文書化する機会を与えることになるからである。私はいつも、約20分毎にチェックインすべきだと言っている。

⁹”バグ”という言葉を使いたくない理由が2つある。最初に､製品の振る舞いと仕様の違いを表すには”欠陥”がよりよい技術用語である。つぎに、 ”バグ”ではなにかそのソフトウェアに対する外部的な影響、例えば宇宙線、のような響きがあるが、通常は、理解し､修正され、避けるべき、誰かが犯した過ちであり、”ハエ叩きで潰される” だけのものではないからである。

Copyright © 1999-2001 Richard Brooksby. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.

本書は、(株)東陽テクニカが著者の諒解の下に日本語訳を行った。