構成管理、変更管理、プロジェクト管理の密接な関係

2005年に書かれた@ITの記事を読んで、この記事に書かれている内容は全てRedmine＋チケット駆動開発で実現できると直感したのでメモ。

【元ネタ】
＠IT：意外と知らない構成管理の正体（1）第1回 ファイルバージョンの管理だけで十分ですか？

＠IT：意外と知らない構成管理の正体（2）第2回 プロジェクトの構成要素を探す手順

＠IT：意外と知らない構成管理の正体（3）変更管理、その正体と対策

＠IT：意外と知らない構成管理の正体（4）構成管理とプロジェクトマネジメントの関係

構成管理は誰のためのものなのか？: プログラマの思索

(引用開始)
ただ、プロジェクトは、最後にきちんと納品さえすればよいというものではないのです。いつでも、指定された時点におけるプロジェクトの結果、状態を把握できなければいけないということなのです。そこには、タスクの依存関係、成果物の依存関係、それぞれに要したコスト、さらには検出された障害情報などが含まれていなければなりません。また、どのような経緯でそれらの成果物が出来上がったのかを示すことは、あなたがプロジェクトオーナーの立場なのか、開発者の立場なのかを問わず、あなたの身を守ることにもなります。
(中略)
このように考えると、ソースコードのバージョン管理だけではとてもこのような要望には応えられません。また、これらすべてを管理台帳のようなものとして作成し、人手で管理しなければならないとしたらどうでしょうか？ 大変な労力を要しながら、ミスも続発するという事態になっても何ら不思議ではありません。
(引用終了)

成果物の管理は単なるバージョン管理だけではない。
成果物の作業履歴を残すだけでなく、変更管理プロセスそのものも必要だし、工数やコスト、障害一覧の情報も必要だ。
チケット駆動開発なら、成果物の修正履歴はSCMリポジトリ、成果物の作業履歴はITSチケットで使い分けて、更に相互リンクすることで、変更理由を追跡できるインフラもある。

(引用開始)
それは、構成管理を導入してもこんな状況は解決できないというものです。もちろん、構成管理では解決できないITプロジェクトの問題は山ほどあるわけですが、「構成管理を導入すれば、これは解決できる」という誤解を抱かれやすいケースがあるのです。それは、私が“インクリメンタルのドツボ”と呼んでいるものです。
(中略)
さて、1カ月を過ぎたころ、あなたはどのような状況に置かれているでしょうか？ 予定では2回目のインクリメントに入っているはずです。あなたは、確かに2回目のインクリメントの開発をしているようです。しかし浮かない顔をしています。初めは調子が良かったのに、この1週間、深夜残業が続いているようです。なぜでしょう？ お分かりですね？ そうです、1回目のインクリメントのデバッグと、2回目のインクリメントの追加機能開発に追われているのです。しかも、構成管理プロセスに従って、1回目のインクリメントのコードと、2回目のインクリメントのコードは別管理されています。あなたは、修正と追加のコードをそれぞれ別のファイルに行い、2回目のインクリメントのデイリービルド用にマージ作業まで行っています……。
　つまり、プロジェクト計画に致命的な問題があるわけですが、構成管理の仕組みがあれば、別々のリビジョンとして並行開発のコード管理ができるので大丈夫（？）という、とんでもない問題点のすり替えが平気（かどうか分かりませんが）でまかり通っていたりするのです。
　確かに、あるソフトウェア製品の奇数バージョンと偶数バージョンを並行開発するとか、簡易版とプロフェッショナル版を並行開発するとか、そのような場合には、構成管理をきちんと行うことが重要ですし、そうすることによって混乱を防ぎながら短期間で次々とリリースすることにもなるでしょう。この場合には、もちろん、担当者がそれぞれで別であれば、という条件付きなわけですが。
(引用終了)

「インクリメンタルのドツボ」とは並行開発の罠のことだ。
繰り返し開発は実は並行開発である事実を知らずに実践しても、すぐに破綻する。
その考察については以前たくさん書いた。

裏プロセスは並行プロセス: プログラマの思索

アジャイル開発が並行開発になる理由: プログラマの思索

TiDDを実践して気付いたことpart7～繰り返し開発を制する者はSW開発を制す: プログラマの思索

TiDDを実践して気付いたことpart3～繰り返し開発の戦略: プログラマの思索

並行開発の問題は、ソフトウェアプロダクトラインや派生開発にもつながる。
繰り返し開発をスムーズに運用するには、メインラインモデルという構成管理が最低限必要であり、最終的にはGitやMercurialのような分散バージョン管理でブランチ管理しなければ解決できないだろうと思っている。

(引用開始)
これらを行ううえで、重要なものがあります。それは、ベースラインです。上記の3つの活動は、結局のところ構成要素に対する変更を管理、監視するというものです。そして、この活動を開始するきっかけが、ベースラインとなります。ベースラインとは、構成要素全体に対する、ある時点でのステークホルダー全員の合意といえます。変更管理、ステータス管理、監査とは、このベースラインに対する包括的な変更管理にほかなりません。ベースラインのない状態での変更管理はないということです。
(中略)
実際には、変更管理手順が、合意を確立する手順として効果的なものであるために、最初のベースラインを作成する前の段階から、変更管理手順を適用するケースも多く見かけます。しかし、変更管理の本質とは、ある合意に対する変更を管理し、新しい合意を適切に確立するための手順であるということを常に認識しておくことは重要です。明確な目的の達成のために管理する、ということが重要なわけですが、得てして管理すること自体が目的だという錯覚に陥りがちだからです。正しい目的のない状態での管理、ルールは、非常に簡単に崩壊してしまうのです。
(引用終了)

構成管理のベースラインは、SCMのタグ(tag)であり、リリース済バージョンに相当する。
つまり、ベースラインはユーザと開発チームの合意というマネジメント上の意思決定であるだけでなく、リリース物件に含まれる成果物のスナップショットでもあり、アジャイル開発のイテレーション(スプリント)にも対応付けられる。
ユーザに価値あるソフトウェアを届けるタイミングで、SCMリポジトリにタグが振られて、SCMリポジトリからビルドされたソフトウェアやドキュメント一式が作られる。
そのタイミングはイテレーションが終了した直後であり、リリース直後にもなる。
考察した詳細は既に書いた。

チケット駆動開発の本質はバージョン・ファースト: プログラマの思索

イテレーションはSW開発で何故重要なのか？: プログラマの思索

つまり、プロジェクトライフサイクルの管理とベースラインの管理、リリース管理は同値。
Redmine・SVN・HudsonというITS・SCM・CIツールとの関連については下記に書いた。
この関連を意識して運用すれば、成果物の追跡だけでなく要件から作業、成果物までの修正を追跡できるインフラが自然に整う。

RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索

(引用開始)
システム開発における変更管理とは、
変更要求を一意に識別し、
変更要求に対応することによる影響を正しく把握したうえで対応計画を立て、
対応作業の実施およびその結果を確認すること
によって、常にすべての成果物間の整合性を確保・維持すること、です。
　CMMIの構成管理に該当する説明には、詳細な記述がありますが、日常業務の範囲であれば、“最終的に”上記の認識で十分です。“最終的に”とは、「変更要求にはどんなものがあり、影響を把握するとはどういうことで、成果物間の整合性を確保・維持するためにはどうすればよいのか」といったことを理解したうえで、上記の認識を持てばよいという意味です。「なあんだ」と思うかもしれませんが、大事なのは、全体の構造を理解したうえで、上位概念を意識に留めておくということです。そうすれば、いつでも細部を思い出すことができます。
(引用終了)

上記の文章はITILの変更管理を連想させる。
変更要求はRFC、変更要求に対する意思決定は変更管理委員会(CAB)に相当する。
そして、ITILの変更管理で計画された対応内容は、ITILのリリース管理で実施されて評価される。
その場合、変更対象の成果物は構成アイテム(CI)として構成管理DB(CMDB)で修正内容も含めて一元管理される。

ITILとチケット駆動開発の密接な関係については下記に既に書いた。

ITILのプロセス関連図: プログラマの思索

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

ITILの内容はRedmineやTracのようなITS上で管理しやすい。
その理由は、成果物に対する変更履歴がITSのチケットで一元管理されるからだ。

頻繁なVerUpがソフトウェア開発の本質: プログラマの思索

(引用開始)
このタスクの進捗率は、どのプロジェクトでも扱いに困っている代表選手です。各担当者に進捗率として聞くと、80％くらいまでは一気に進捗し、その後は急に進捗しなくなるということは皆さんご存じのとおりです。そこで、有効な手段の1つとして、各成果物のステータスを細かく定義し、それぞれのステータスごとに進捗率を割り当てておくことで、進捗を把握するというものです。各担当者は、成果物を構成管理システムにチェックインするときに、ステータスを登録するだけですから、こちらも余計な負担を強いることはありません。
(中略)
さて、ここまで書いておきながらこのようなことをいうのもどうかと思うのですが、私は、進捗率を細かく把握することの意義には疑問を持っています。というのは、経験的に、細かく進捗を把握した場合と、そうしなかった場合でのプロジェクトの目的達成における違いがほとんど感じられないからです。
　実際にはどのようなレベルで進捗を見ることが多いかというと、各成果物が完成したか、完成していないか、つまり、0％か100％のどちらかのみです。お気付きの方も多いと思いますが、SCRUMに似たやり方です。また、これもSCRUMと同様ですが、日々、各担当者に「後何日で成果物が完了するか？」を作業時間とともに教えてもらいます。これは、日々作業を行う中で担当者の作業見積もりの精度も上がるため、スケジュール調整の判断に非常に有効なデータとなります。
(引用終了)

駄目な進捗管理では、90％まで進捗が進んだのにそこから完了までとても時間がかかる場合がある。
その理由は、進捗の定義があいまいであり、作業の終了基準があいまいだからだ。
タスクの進捗率は、アジャイル開発なら極めて明確だ。
ToDo、Doing、Doneの三つのステータスだけであり、0％か100％のどちらかだ。
Redmineならステータスごとに進捗率を指定できるので、ぶれることもない。

小技(0.9): チケットのステータスで進捗率を更新する | Redmine.JP Blog

(引用開始)
構成管理の仕組みを工夫して使うことによって、テスト結果の集計や、障害情報のステータス追跡、成果物への変更手続き、変更履歴の確認のほとんどを自動化することが可能になります。
(引用終了)

構成管理の枠組みは最終的にはプロジェクト管理サーバーの概念につながる。
つまり、ソフトウェア開発で発生する作業履歴は全てITSに蓄積されて、そこから進捗や品質、コストなどのメトリクスをいつでも出力できる。
更に、ITSを中核としたプロジェクト管理サーバーは、プロジェクトマネージャがプロジェクト運営する時の意思決定支援のツールになりうる。
そのアイデアは下記に書いた。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

プロジェクト管理サーバーのメトリクスは教科書みたいだ: プログラマの思索

チケット駆動開発が進むべき道 part3～BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd: プログラマの思索

構成管理を単なるバージョン管理と考えるのではなく、プロジェクトを丸ごと組織の資産として管理する。
仕組みとしてはITS・SCM・CIのインフラがプロセス資産になる。
つまり、開発チームは今までの開発や運用で得た経験をノウハウとして蓄積すれば、それは開発チームの資産になり、成長していくきっかけになる。
それがまさにプロセス改善になる。
そのアイデアは下記に書いた。

チケット駆動開発が進むべき道part2～プロジェクト管理サーバーは開発チームの資産: プログラマの思索

上記の記事は構成管理、変更管理、プロジェクト管理の密接な関係を抽象的に書いているが、チケット駆動開発ならその内容を全て具体的に実現できる。
その内容をもっときちんとまとめてみたい。