資料立ち読みコーナー  ソフトウェア構成管理のベストプラクティス

<<目次>>
    フリーサイズの SCM などない
    スケーラブルなベストプラクティスを設計する
  1. 注意深くSCM環境を計画する
  2. すべての成果物について絶対的な再現性を保証する
  3. 変更要求と変更パッケージを必須にする
  4. 開発者のプライベート ワークスペースを維持する
  5. 適切なベースラインを作成し、そこから作業を開始する
  6. プロセス改善のためにメトリクスを活用する
  7. 再利用可能なコンポーネントを作成する
  8. できるだけ頻繁にマージと統合を行う
  9. 分散環境のための構造
  10. 最後に

フリーサイズの SCM などない

2003年のStandishグループの CHAOSレポートによると、ソフトウェアプロジェクトの3分の2は失敗に終わっており、原因の大半はソフトウェア構成管理(SCM)がきちんと行われていないことだという。また、Anne Haasの『Configuration Management Principles andPractice』によると、ITユーザーは最も改善が必要なプロセスとして、プロジェクト管理の次に構成管理を挙げている。

多くの組織がプロセスの改善に失敗している背景には、開発環境がますます複雑になっているという事情がある。具体的には、複数のソフトウェア開発手法が並存していること、並行開発が複雑化していること、監査制度や法規制コンプライアンス制度による要求が増えていること、分散開発やアウトソーシングの影響範囲が拡大していること、アジャイル開発プロセスや反復型開発プロセスの導入が進んでいることなどが挙げられる。

多くの企業は、ソフトウェア構成管理を簡略化しようとして「1つのサイズですべてに合わせる」アプローチを採用しがちだが、そのようなやりかたはほとんど失敗すると言っていい。1つのサイズで間に合わせようとすると、複雑なプロジェクトを単純な CVSでバージョン管理したり、単純な Web プロジェクトに複雑な NASAの手順を適用するといったおかしなことになる。最適な方法を選択するには(つまりプロジェクトに合わせて適切な規模の SCMを選択するには)、着手しようとしているプロジェクトにはどんなSCMのルールを適用するべきか、きちんと理解して計画する必要がある。

スケーラブルなベストプラクティスを設計する

ベストプラクティスにも適切な規模というものがある。たとえば、1回限りのプロジェクトでありとあらゆるプロジェクトメトリクスを収集するのはやり過ぎだ。また、ベストプラクティスは別の開発手法にも応用できなければならない。ほとんどの企業では、すべてのプロジェクトに同一の手法を適用するというのは、すでに過去の習慣になっている。実際、TiwanaとKeilが述べているように「1つの手法をすべてに当てはめる」アプローチでは、プロジェクトに手法がマッチしないことが多々あり、プロジェクトが失敗するリスクが高くなる。今日、多くの企業はプロジェクトの種類に応じて最適な手法を選択できるよう、複数の手法を選択肢として認めている。

筆者の顧客である某独立系ソフトウェアベンダーは、ベータカスタマーと密接に協力しなければならない新規プロジェクトではアジャイル手法を選択し、一方、ライフサイクルの最終段階に入った古い製品にはウォーターフォールベースのアプローチを適用している。アジャイル開発チームは、ウォーターフォール開発チームの厳格なSCMプラクティスに従うのを拒否したため、顧客への正式なリリースを管理するのに苦労した。

より多くの手法を採用している大規模な IT企業やコンサルティングサービス会社の場合、問題はさらに大きくなる。そういった企業では通常、プロジェクトの種類やスコープ、リスクレベルに基づいて手法を選択する。

理想としては、どんな規模にも対応できるスケーラブルなSCM、要件管理、プロジェクト管理、品質保証に関するベストプラクティスのライブラリを用意して、どんな手法を採用する場合もその共通ライブラリを活用すべきである。

以下のセクションでは、そのようなライブラリに入れるとよいベストプラクティスをいくつか取りあげた。各ベストプラクティスとキーになる SCMプロセスの関係については図1を参照してほしい。各ベストプラクティスを簡単に説明し、スコープおよびリスクの観点から、どんな場合に適用するのがよいかを述べている。


1. 注意深くSCM環境を計画する

プロジェクトごとに適切なSCM環境を設計できている企業はほとんどない。プロジェクトマネージャーがプロジェクトのニーズを評価し、グローバルなSCMプロジェクトテンプレートをちょっと手直ししてプロジェクトを開始する、というケースが一般的だ。プロジェクトのスコープ/リスクとSCMポリシーとのミスマッチの結果、開発者が不幸になったりプロジェクトが遅延したりする。



続きはPDFで。。。
 
 

構成管理・変更管理ツール AccuRevに
関するお問い合わせ

  • テクマトリックス株式会社
    東京本社

    ソフトウェアエンジニアリング事業部

    03-4405-7853

メールでのお問い合わせ
accurev-info@techmatrix.co.jp

CONTACT

製品についてやテクマトリックスについてなど、
こちらよりお気軽にお問い合わせいただけます。