ファイルバージョンの管理だけで十分ですか?意外と知らない構成管理の正体(1)

» 2004年07月27日 12時00分 公開
[今村智ボーランド]

 短期連載(要求仕様のボトルネックを探る)では、ITプロジェクトにおける“要求”というものにフォーカスし、高品質な要求開発と、その要求を管理することについてお話ししました。今回の連載では、構成管理(SCM:Software Configuration Management)について見ていきたいと思います。

 読者の中には、構成管理といわれると「ソースコードのバージョン管理のことでしょ」ということで、主にライブラリアンと開発者が気にするものという認識の方も多くいらっしゃるのではないかと思いますが、本当にそうでしょうか? 数人のチームで、1カ月程度で作り上げるようなシステムや、オープンソースではうまくいっても、ある程度の規模の受託開発や、製品開発ではそれだけではうまくいかないことが多いのです。そこで今回は、まずは構成管理の概要をつかんでいただきたいと思います。

プロジェクトの現場で見られる問題点

 さて、あなたのプロジェクトでは、以下に挙げるようなことが起きていませんか?

  • ライブラリアンが最も長時間労働を行っている
  • ビルドのたびに、1度は失敗する(原因調査にも苦労している)
  • どのファイルを使えばよいのか分からない
  • どこかでデグレードが起こったようだが、経緯が分からない
  • いつ、誰が、何の目的で作成したか分からないコードが多い(特に、長期にわたって運用されているシステム)
  • プロジェクトのたびに、ソースコード変更の手順を定めている。しかも、いつの間にか正しく運用されなくなる

 ほかにもたくさんの課題があって、挙げていくとキリがないわけですが、そもそもプロジェクトとは、プロジェクトオーナーの要求を実現する複数のタスクの集合であり、タスクには必ず成果物が伴わなければならないものですから、プロジェクトオーナーから、「私のこの要求を実現するための成果物はどれですか?」といわれたときに、「これらの一式です」と直ちに提示できなければならないわけです。勘違いしないでいただきたいのですが、プロジェクトオーナーは神さまだといっているのではありません。

 ただ、プロジェクトは、最後にきちんと納品さえすればよいというものではないのです。いつでも、指定された時点におけるプロジェクトの結果、状態を把握できなければいけないということなのです。そこには、タスクの依存関係、成果物の依存関係、それぞれに要したコスト、さらには検出された障害情報などが含まれていなければなりません。また、どのような経緯でそれらの成果物が出来上がったのかを示すことは、あなたがプロジェクトオーナーの立場なのか、開発者の立場なのかを問わず、あなたの身を守ることにもなります(これはもろ刃の剣ですから、あなたが不誠実、不正確な対応をしていたとすれば自爆することにもなります)。

 このように考えると、ソースコードのバージョン管理だけではとてもこのような要望には応えられません。また、これらすべてを管理台帳のようなものとして作成し、人手で管理しなければならないとしたらどうでしょうか? 大変な労力を要しながら、ミスも続発するという事態になっても何ら不思議ではありません。

構成管理を導入する

 構成管理という考えは、すでに30年以上前から存在しているわけですが、残念ながら日本語の書籍は少ないようです。ITプロジェクトの現場への浸透度としては、最近になってCMMIへの取り組みの広がりとともに、言葉自体は浸透しているように思われます。しかし、実体としては、管理対象はソースコードのみというケースが多いようです。構成管理とは、具体的に何をどのように管理するものなのか、ということについては、次回以降で詳しく述べることにして、まずは構成管理を組織に導入するための手順を簡単にまとめておきたいと思います。

 構成管理の必要性を理解し、導入しようという話は結構あります。だいたいはまずツールを購入します。ところが、買ったツールそのままでは自分たちのやりたいことは実現できず、ツールをカスタマイズする必要性に迫られます。カスタマイズできるのであればいいのですが、カスタマイズ作業があまりにも困難で、ツールの利用をあきらめるという場合が多々あります。結局はツールを購入する前の状態に逆戻りというわけです。これは本当に残念な話です。最初の一歩さえ間違えなければ、投資を無駄にせずに済んだのに、と思えてなりません。このような失敗を繰り返さないためにも、これから構成管理に取り組もうと思われている方は、以下の手順を頭に入れておいてください。

(1) 計画を立てる
(2) 構成管理プロセスを定義する
(3) 構成管理ツールを評価する
(4) パイロットプロジェクトへプロセスとツールを導入し、双方を評価する
(5) ほかのプロジェクトへ展開する
(6) プロジェクトからのフィードバックを基に、プロセス、ツールを改善、カスタマイズする

 先に挙げた失敗パターンは、(1)、(2)がない状態で、(3)と(4)を同時に行っているということになります。この場合、評価の基準がない状態ですから、ひたすら要求だけが膨張していき、収拾がつかなくなるのです。何だか失敗開発プロジェクトそのものを見ているような気がしませんか?

 それでは上記手順について、簡単に説明しておきます。

(1)計画を立てる

 構成管理プロセスを導入するための計画として、以下についてまとめます。

  • 目的(何のために構成管理を導入するのか)
  • スケジュール(構成管理プロセスを定義して、パイロットプロジェクトの評価を終えるまで)
  • パイロットのターゲットとなるプロジェクト
  • 担当者

(2)構成管理プロセスを定義する

 構成管理プロセスまたは構成管理ガイドとして、大きくは以下の4つについてまとめます。これらの詳細については、回を改めて説明したいと思います。

  • 構成要素
  • 変更管理手順
  • ステータス管理
  • 監査

(3)構成管理ツールを評価する

 ツールの評価は、構成管理プロセスを実現できるかどうかについて、以下のポイントに着目して行います。

  • バージョン管理
  • 構成要素サポート(対応可能な構成要素)
  • プロセスサポート(ワークフロー)
  • 変更管理
  • チームサポート(チーム利用が可能か否か)
  • リポジトリ機能
  • セキュリティ(ユーザー管理、構成要素へのアクセス権設定)
  • レポートおよび分析クエリ
  • 他ツールとの統合
  • ビルドサポート
  • リリース管理
  • カスタマイズ機能
  • 分散拠点開発サポート
  • GUI(Client-Server,Web)(使いやすさ)

(4)パイロットプロジェクトへプロセスとツールを導入し、双方を評価する

 パイロットプロジェクトとしては、新規開発プロジェクトと、保守・運用プロジェクトがターゲットとなり得ます。前者の方が導入への抵抗、障害は少ない傾向にありますが、あなたの組織が置かれている状況に合わせて、ふさわしいプロジェクトを選択すべきです。また、評価については構成管理プロセスのとおりにできたかできなかったか、もっと良い方法としては何が考えられるかについて、整理します。

(5)ほかのプロジェクトへ展開する

 ほかのプロジェクトへの適用に際しては、その目的と、パイロットプロジェクトの結果から期待できる効果などを伝え、構成管理の仕組みの提供とともに円滑な導入が行えるよう、支援の体制を用意することが重要です。これにはパイロットプロジェクトにかかわったメンバーが適任です。ここでも、適用して終わりではなく、常にその結果について、パイロットプロジェクト同様に整理します。

(6)プロジェクトからのフィードバックを基に、プロセス、ツールを改善、カスタマイズする

 複数のプロジェクトに適用していくと、いろんな改善点が出てくることがありますが、それらの中には相反するものも当然ながら出てきます。ですから、すべての改善要望を取り込むのではなく、それぞれのメリット、デメリットを評価し、選別するか、特定のプロジェクトのタイプに分類できる場合には、構成管理プロセスにいくつかのバリエーションを持たせることを検討します。

構成管理を導入しても……

 さて、構成管理プロセスの詳細は後の回に譲るとして、今回の残りの部分でお伝えしておきたいことがあります。それは、構成管理を導入してもこんな状況は解決できないというものです。もちろん、構成管理では解決できないITプロジェクトの問題は山ほどあるわけですが、「構成管理を導入すれば、これは解決できる」という誤解を抱かれやすいケースがあるのです。それは、私が“インクリメンタルのドツボ”と呼んでいるものです。

 インクリメンタル開発や、イテレーション開発という言葉はいまや誰にとっても珍しくもないと思います。また、プロジェクトオーナーに対してはウォーターフォールで開発しますといいつつ、実態としてはインクリメンタルな開発を行うというケースもあちこちで見受けられ、リスクの軽減という点からも、私としても大賛成な状況が増えつつあるようです。

 しかし、あなたはこんな経験をしたことはないでしょうか? ここで、あなたはプログラマだと仮定します。あなたが参加することになった今回のプロジェクトは、Unified Processを採用し、要求リスク、技術リスク、リリースリスクなどをインクリメンタルな開発を行うことによって軽減しながら開発していくとのことです。あなたは、初めてのインクリメンタルな開発に少なからず期待しています。いままでは、上流工程のしわ寄せがすべて自分たちに来ていたために毎日が残業の嵐でした。でも今回は違います。1カ月ずつ何かを作り上げていきます。そのたびにリスクが軽減され、スケジュールの精度も上がり、人間らしい生活を送りながらプロジェクトを進められるということなのです。

 さて、1カ月を過ぎたころ、あなたはどのような状況に置かれているでしょうか? 予定では2回目のインクリメントに入っているはずです。あなたは、確かに2回目のインクリメントの開発をしているようです。しかし浮かない顔をしています。初めは調子が良かったのに、この1週間、深夜残業が続いているようです。なぜでしょう? お分かりですね? そうです、1回目のインクリメントのデバッグと、2回目のインクリメントの追加機能開発に追われているのです。しかも、構成管理プロセスに従って、1回目のインクリメントのコードと、2回目のインクリメントのコードは別管理されています。あなたは、修正と追加のコードをそれぞれ別のファイルに行い、2回目のインクリメントのデイリービルド用にマージ作業まで行っています……。

 つまり、プロジェクト計画に致命的な問題があるわけですが、構成管理の仕組みがあれば、別々のリビジョンとして並行開発のコード管理ができるので大丈夫(?)という、とんでもない問題点のすり替えが平気(かどうか分かりませんが)でまかり通っていたりするのです。

 確かに、あるソフトウェア製品の奇数バージョンと偶数バージョンを並行開発するとか、簡易版とプロフェッショナル版を並行開発するとか、そのような場合には、構成管理をきちんと行うことが重要ですし、そうすることによって混乱を防ぎながら短期間で次々とリリースすることにもなるでしょう。この場合には、もちろん、担当者がそれぞれで別であれば、という条件付きなわけですが。

 構成管理を正しく行えば、チーム内のコミュニケーションも円滑化されます。存在理由が不明な成果物もなくなります。プロジェクト資産の再利用にも役立つでしょう。しかし、安易なプロジェクト計画を許容するものではないということを忘れないでください。

 次回以降では、構成管理の具体的な内容を掘り下げていく予定です。

プロフィール

今村智(いまむらさとし)

 メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。個人Webサイト(http://www.human-process.com/)からの情報発信

も行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ