開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）：The Rational Edge（2/2 ページ）

» 2007年09月27日 12時00分 公開
[Scott W. Ambler, Per Kroll，IBM]
前のページへ 1|2 　　　　　　

ベストプラクティス（最優良事例）の紹介

　図1は高効率ガバナンスの手法間の関係を分類および図解しており、以下はアルファベット順でそれぞれの概要を示している（今回のシリーズを通じて各手法を詳細に探求していく）。

ALT 図1 高効率ソフトウェア開発ガバナンスの各種手法 （クリックすると拡大）

高効率ソフトウェア開発ガバナンス手法の概要一覧

プロセスの導入　チームは規模、分布、重要度、管理ニーズ、そしてメンバースキルがそれぞれ異なるため、1つの大きさのプロセスですべてに対応することはできない。プロセスは、チームのニーズに正確に合うようカスタマイズする必要がある。さらにプロセスは、評価をしたうえで、変化し続ける組織のニーズに合わせて時間とともに進化できるようにする必要もある。

人事ポリシーとITの価値との調整　技術スタッフの採用、引き留め、そして昇進には、非技術系のスタッフとは異なる戦略が必要となる。納期を確実に守るための技術スタッフの考え方や、新技術の再教育といった重要な業績に合致した特別な奨励金／報奨金を用意する必要がある。

組織構造とアーキテクチャとの調整　プロジェクトチームの構成は、チームの作業を合理化するために構築中のシステムにとって望ましいアーキテクチャ構造を反映する必要がある。例えば、分散されたチームはパーティション化されたアーキテクチャの開発にうってつけだが、集中管理型チームは集中管理型アーキテクチャの構築に適している場合が多い。

ビジネス主導のプロジェクトパイプライン　投資は、業務方針にうまく沿っていて、決まった価値を生み、企業の優先事項とうまくマッチするプロジェクトに対して行うべきだ。このアプローチは、「すごい技術」はあまり重視せずに業務の支援を重視することを意味する。

継続的改良　プロジェクトでは、最後だけでなく、それを通じて学んだ教訓の特定と、それに対する対応に努める必要がある。例えば、各フェーズ最後で簡単に作業を振り返り、重要なマイルストーンでは詳細に振り返ることは、プロジェクトの進展に合わせて行える分かりやすい改善方法だ。

継続的なプロジェクト監視　自動メトリクス収集により、プロジェクトの監視が可能になり、早期問題解決のためのプロジェクトチームとの密接な協力に向け、潜在的な問題も特定できるようになる。また、収集する最小限の値を最初に特定しておく必要がある。

コンプライアンスの組み込み　別途コンプライアンスプロセスを用意するのは不要なオーバーヘッドにつながることが多く、コンプライアンス部分は日常のプロセスに組み込んでおく方がよい。自動化は重要だ。

柔軟なアーキテクチャ　サービス指向、コンポーネントベース、あるいはオブジェクト指向となっていて、共通のアーキテクチャとデザインパターンをインプリメントしているアーキテクチャは、一貫性、再利用性、強化性、そして適合性の向上に役立つ。

統合ライフサイクル環境　メトリクスの収集やシステムの構築など、「嫌な仕事」はできるだけ多くを自動化するよう努めるべきだ。ツールとプロセスは、ライフサイクル全体を通じて効果的に組み合わせたい。プロジェクト当初のツールセットに対する初期投資は、プロジェクト全体を通じた作業削減という大きなメリットを生む。

反復開発　ソフトウェアの配布に向けた反復型アプローチは、ソフトウェアコンポーネントの開発と開示を徐々に進められるようにし、全体の障害に対するリスクを削減し、きめ細かい調整を可能にし、手直しも最小限の時間で修正可能にする。

実質的ガバナンス組織　効果的なガバナンス組織は、開発チームが費用効果が高くタイムリーな形で開発できるようにすることに重点を置く。一般的に、核となるスタッフは最小限にとどまり、その大部分は統治される組織の関係者が占める。

リスクベースのマイルストーン　プロジェクトのリスク、特にビジネスおよび技術関連のリスクはライフサイクルの早い段階で緩和しておきたい。これは、チームが目標にするマイルストーンをプロジェクトに複数用意することで行う。各マイルストーンの目標は、「構築」開始前に可動コード全体でアーキテクチャの検証が必要なRational Unified Process（RUP）のLifecycle Architecture（LCA）マイルストーンのように、最低1つのリスクに対処することだ。

シナリオ主導開発　各部品を理解せずに全体を定義することはできないし、全体を理解せずに各部品を詳細に定義することもできない。シナリオ主導のアプローチを取れば、システムを実際に使う方法を理解することができ、実際のニーズに合ったものを構築できるようになる。

自己管理されたチーム　作業立案に最も適しているのは実際に作業をする人だ。IT専門家は自分たちの協力戦略を判断できるインテリジェントな集団として尊重されるべきだ。彼らは多少の指導と指標さえあれば、反復範囲などの確定要素の中で計画を立てることができる。

シンプルで関連性のあるメトリクス　メトリクスの収集は最大限自動化し、収集数は最小限に抑え、収集する理由を理解しておく必要がある。

段階プログラム配布　関連するプロジェクトの集合であるプログラムは、少しずつ段階的に投入する必要がある。サブプロジェクトを待ってリリースを控えるよりも、個々のサブプロジェクトのリリース日をあらかじめ決めておく必要がある。サブプロジェクトが期限に間に合わない場合は、それを次期リリースに先送りし、顧客に対するプログラムの影響を最小限に抑える。

貴重なIT資産　プログラミングガイドラインやデータベースデザイン慣例などの指標や、フレームワークやコンポーネントなどの再利用可能な資産は、開発者の価値を高めると認められれば選定する。開発者ができる限り簡単に準拠できるよう、そして（さらに重要なこととして）企業のITインフラをさらに活用できるようにしたい。

　後編で、a）実質的ガバナンス組織の目的と原則や段階プログラム配布、b）ビジネス主導のプロジェクトパイプラインおよびシナリオ主導開発と呼ばれる組織とミーティングについて説明していく（本稿のパートIIおよびIIIでは上記以外のベストプラクティスをカバーする）。

　前述のベストプラクティスの中から、メリット、関連トレードオフ（今後の手法を維持するための組織内の必須要件）、アンチパターン（手法に反し、インプリメンテーションの脅威となったり、メリットを打ち消す行動）、そして推奨デフォルト（組織内で当該手法を確立するために取るべき最低限の手順）をカバーしていく。

［後編に続く］

本記事は「The Rational Edge」に掲載された「Best practices for lean development governance」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM



「The Rational Edge」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ