自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）：The Rational Edge（3/3 ページ）

[Scott W. Ambler, Per Kroll，IBM]

［高効率ソフトウェア開発］

　Mary PoppendieckとTom Poppendieckの両氏はその共著である「Implementing Lean Software Development」（Addison Wesley 2006刊）の中で、高効率製造の原則をソフトウェア開発に適用してIT全体の価値ストリームを最適化する方法を説明している。高効率ソフトウェア開発には以下の7つの原則がある。

1.無駄の排除。ソフトウェア開発の中で最も多くの無駄が発生するのが、余分な機能の追加、余分な作業、そして組織の境界を越えることの3つだ。組織の境界を越えると、レスポンスタイムが遅れ、コミュニケーションを疎外する緩衝域が作り出されるため、コストが25％以上増加する可能性がある。開発チームは、達成を目指す作業を反映した方法で自己管理し、自力で運営できることが重要だ。この原則は、「自己管理チームの推進」「実用的ガバナンス団体」「ビジネス主導のプロジェクトパイプライン」「リスクベースのマイルストーン」「継続的改善」「統合ライフサイクル環境」、そして「評価企業資産」の各手法に対応する。

2.品質の確保。Poppendieckの両氏は先の共著の中で、簡単に次のような所見を述べている。検証プロセスで定期的に問題が見つかる場合は、そのプロセスに欠陥があるはずだ。ことガバナンスに関しては、開発者がしてほしくないことをするようなケースや、すべきことをしていないケースが定期的に見つかる場合は、そのガバナンスに対するアプローチが間違っているはずだ。戦略としては、ガバナンスをソフトウェアプロセス作業を増やすようなものにせず、開発者が可能な限り簡単に適切な作業を行えるよう、プロセスの中に組み入れることだ。品質は「反復作業開発」「リスクベースのマイルストーン」「コンプライアンスの組み込み」、そして「評価企業資産」の各手法によって組み入れる。

3.知識の作成。計画は有益だが、学習は絶対不可欠だ。チームが利害関係者の本当に必要としているものを見つけ出し、その知識に基づいた行動を取れるようにする「反復作業開発」などの手法を推進したい。従いたいと思わせ、具体的なニーズに合わせて修正することができる基準、指標、そして再利用可能な資産を持つことは、非常に重要なことであり、そのためには「評価企業資産」の手法が重要になってくる。また、首尾一貫したタイムリーなフィードバックも、役立つソフトウェアを定期的に開発するチーム内と、「継続的なプロジェクト監視」および「シンプルで関連性の高い評価指標」の両手法全体のプログラムレベルの両方で重要になる。知識の作成は、学習と改善に努めることから「継続的改善」の手法でサポートされ、個人に自分たちの作業について考える機会が与えられることから「自己管理チーム」の手法でサポートされる。

4.コミットの後回し。完全な仕様を定義してからソフトウェア開発を始める必要はなく、反復作業を繰り返せばよい。ビジネスは、変化に対する許容範囲の広い柔軟なアーキテクチャや、不可逆的判断が必要な予定を可能な限り後回しにすることで効果的にサポートできる。これには、包括的なビジネスシナリオを、場合によっては複数にまたがるアプリケーションで開発された機能とを異なるプロジェクトごとに密接に結び付ける能力も必要になる。お分かりのように、「反復作業開発」「柔軟なアーキテクチャ」、そして「シナリオ主導開発」の各手法は、コミットを可能な限り後回しにしてくれる。

5.素早い配布。品質の高いシステムを素早くタイムリーに配布することは可能だ。チームの能力に合わせて作業を制限したり、能力以上のことを強制せず、自己管理を求め、自分たちで達成できることを判断させれば、信頼性が高く、反復作業可能な作業の流れが実現できる。組織レベルでは、最も遅いプロジェクトではなく、最速のプロジェクトのペースに合わせてプログラムが事業価値を提供できるようにしなくてはならない。前者に合わせるケースがあまりにも多く見られる。「自己管理チーム」「プログラムの段階的配布」「反復作業開発」「評価企業資産」、および「柔軟なアーキテクチャ」の各手法が素早い配布を可能にする。

6.人材の尊重。Poppendieck両氏は、継続的利点は　積極的に関与する思考力のある人から得られる、との所見を述べている。このことは、IT固有の人事戦略の必要性、そしてチームをコントロールするのではなく権限を与える必要性を意味している。この原則は「プロセスの導入」「自己管理チームの推進」、そして「人事ポリシーとITの価値の適合」の手法の動機になる。

7.全体の最適化。開発作業を効果的に管理したい場合は、個々のプロジェクトチームではなく大局を見る必要がある。個々のシステムがサポートし、複数のシステムにまたがる場合の多いハイレベルビジネスプロセスの理解が必要になる。利害関係者に完成度の高い製品を配布できるよう、相互に関係するシステムのプログラムを管理する必要がある。測定値は、事業価値をどれだけうまく提供できているかを測定する必要がある。それがIT部門の存在理由だからだ。全体を最適化するには、「プログラムの段階的配布」「シナリオ主導開発」「継続的改善」「シンプルで関連性の高い評価指標」「継続的なプロジェクト監視」「統合ライフサイクル環境」「評価企業資産」「柔軟なアーキテクチャ」、そして「組織構造とアーキテクチャの適合」など、さまざまな高効率開発手法に従う必要がある。

---

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

---

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）