開発標準を導入、トップダウンかボトムアップかこうすればできる開発手順の標準化(3)

今回は開発標準の導入のアプローチについて説明します。一般的な開発標準の導入方法というのはあるのですが、個別の開発プロジェクトに適用するとなると、いろいろな問題点が出てきます。御社での開発標準導入はスムーズですか?

» 2006年10月20日 12時00分 公開
[瀬谷茂,豆蔵]

1. IDEALモデル

 一般的な開発標準の導入方法として、CMM/CMMIの開発元であるカーネギーメロン大学のソフトウェアエンジニアリング研究所(SEI)では、IDEALモデルという組織の改善モデルを定義しています。IDEALモデルを図1に示します。

ALT 図1 IDEALモデル

 それぞれのフェーズの説明は以下のとおりです。

  • Initiating(開始):改善の動機付け、コミットメント確立、推進体制確立
  • Diagnosing(診断):改善目標設定、現状把握、改善項目特定
  • Establishing(確立):改善戦略立案、改善計画作成
  • Acting(実践):標準プロセス作成、試行、試行評価
  • Learning(学習):学習、次の活動提案

 D→E→A→L→D……については、何度も繰り返しながら、段階的に組織の成熟度を向上させていく、というのがこのモデルです。例えば、レベル1の段階のサイクル、レベル2の段階のサイクルなどとして、改善を繰り返していきます。

 IDEALモデルの詳細については、さまざまな文献や書籍などで説明されていますので、ここではこれ以上は触れません。以下では、筆者の経験を基に、実際に開発現場ではどのように標準化を行っているかを説明します。

 理想的には、標準化を含めた開発業務の改善には、前述のIDEALモデルを適用できると思いますし、筆者もこの考え方自体にまったく異論はありません。しかし、実際には必ずしもこの流れで組織全体の開発業務の改善活動を進められるケースばかりではありません。特に最初の「Initiating−動機付け」については、最初から会社や組織のトップから開発業務改善活動についてのコミットメント(十分な人や資金の提供も含む)を得るというのはなかなか難しいようです。また仮にコミットしてもらえたとしても、人や資金が改善目標に対して必ずしも十分ではないということも少なくありません(前回「開発標準導入の阻害要因」の記事で、このことに関連する標準化の課題を書きましたので、そちらも参照ください)。

 IDEALモデルをそのまま実践できれば強力で効率的な改善活動につながる可能性は高いと思うのですが、このモデル自体、どちらかというと欧米的なトップダウン型の会社や組織により適合しているように感じられ、日本的な現場レベルでの改善活動が活発な組織では、そのままではうまく適合できないことも少なくありません。

2. 現場主導の標準化

 では、もしIDEALモデルが最初から組織全体にうまく適用できない場合、実際にはどのように標準化を進めればよいのでしょう? 筆者のこれまでの経験やその研究結果では、まずは現場主導でできるところから活動を開始し、徐々に広げながらトップを巻き込んでいくという方法がうまく適合するような気がします。これは、ほかの現場レベルの業務改善活動の進め方と全く変わりありません。ただしこの場合、単に現場レベルでの「標準化活動」を進めるのではなく、特定の開発プロジェクトをターゲットにした活動にした方が、より効率的ではないかと思いますし、実際そのような事例が増えているといえます。

 ここまで説明してきましたように、筆者は、開発標準の導入には大きく上記の2つのパターンがあるととらえています。最初からIDEALモデルを組織全体に適用するような方法を「トップダウンアプローチ」と呼び、現場主導で特定のプロジェクトをターゲットに適用するところから始める方法を「ボトムアップアプローチ」と呼びます。もちろん、この2つのパターンですべての開発標準の導入事例を網羅できるわけではありませんが、およそこのようにパターン化できるのではないかと考えています。

3. トップダウンアプローチ

 このアプローチのイメージを図2に示します。

ALT 図2 トップダウンアプローチのイメージ

 このアプローチのきっかけは、企業や組織のトップからの開発業務改善要求になります。そしてその要求自体、その企業あるいは組織のビジネス的な改革・改善計画から出されていることが少なくありません。最近でいえば、企業の内部統制の強化(いわゆる、J-SOX法対応)を起点にしているという例もあります。ここでの推進役は、企業や組織横串の開発業務改善(あるいは標準化推進)ワーキンググループなどです。

 この場合、開発標準の策定や導入はその開発業務改善活動の一環という位置付けになり、開発標準自体も最初からその組織全体で共通に利用できるよう、できるだけプロジェクト固有分を除去した汎用的なものになります。

 このため、策定した開発標準を実プロジェクトに展開する場合は、それぞれのプロジェクトの状況に合わせて変形し、より詳細化しなければなりません。このプロジェクトの状況に合わせる作業をテーラリングと呼びますが、テーラリング自体にも、ある程度のルールが必要になります。

 このアプローチを最初から適用できるのは、以下のような場合です。

  • 企業・組織トップのコミットメントがある
  • 企業や組織としての「標準的なプロジェクト」をある程度明確にできる(複数あってもよい)
  • 開発標準の策定・普及のための企業・組織全体としての体制を設立・維持できる

4. ボトムアップアプローチ

 このアプローチのイメージを図3に示します。

ALT 図3 ボトムアップアプローチのイメージ

 このアプローチのきっかけは、現場レベルでの開発業務改善要求やプロジェクトの要求になります。プロジェクトの要求というのは、例えば過去メインフレーム向けのアプリケーション開発を行ってきてそれ用の開発標準はあるが、今回それをオープン系のアプリケーションで作り直すというような場合で、オープン系の開発標準がなくその整備が急務となります。

 この場合は、取りあえずはそのプロジェクト向けの開発標準を策定することになります。そのプロジェクトに必要最低限の範囲・詳細度で、利用技術や体制にフィットさせた内容になります。

 このため、この開発標準をほかのプロジェクトでも利用できるようにするには、一度その固有部分を分離してより汎用的な標準を策定する必要があります。

 このアプローチを適用できるのは、以下のような場合です。

  • プロジェクト責任者(あるいはその上級管理者)の意思や承認がある
  • ターゲットとなるプロジェクトに対する開発標準策定やトレーニングの工数・期間を確保できること
  • その後の展開を考えると、ターゲットプロジェクトがその組織の「リファレンスプロジェクト」に成り得るものであることが望ましい

5. それぞれのアプローチのメリット、デメリット

 上記、2つのアプローチには、それぞれメリット、デメリットがあります。簡単にいえば、作成された開発標準の汎用性の高さ、導入の効率(トップのコミットメントによる支援があるという前提)においてはトップダウンアプローチに、より短期間での実践的な開発標準の策定と成功事例の獲得のしやすさではボトムアップアプローチの方にメリットが見いだせるといえます。またコストで考えると、立ち上げコストではボトムアップアプローチの方が少なく始められるといえますが、組織全体への普及活動全体まで考えると、最初から組織全体をターゲットにしているトップダウンアプローチの方が低くなる要素があるように思えます。表1に、メリット・デメリットをまとめてみました。

  メリット デメリット
トップダウンアプローチ ・個々のプロジェクトの問題や特殊性に引きずられず、組織のあるべき開発標準をまとめやすい

・トップの意思が明確な場合、改善や普及がより容易になる
・必然的に抽象的な開発標準になりがちで、個々のプロジェクトへの適用には、特化・具体化が必要

・過去に適用実績がない為、最初の適用には組織としてのそれなりの支援が必要
ボトムアップアプローチ ・より短期間に、特定のプロジェクトで利用できるレベルの開発標準を定義することができ

・プロジェクトが成功すれば、「成功事例」として普及活動に利用できる
・特定のプロジェクトに対して、開発標準策定と適用という負荷をかけることになる(ただし、組織標準の策定コストよりは低い)

・組織の開発標準の策定の遅延が、開発標準の乱立を生み、組織の品質や生産性向上を阻害

6. おわりに

 今回は、開発標準の導入のアプローチについて、説明を行いました。いずれのアプローチを採用するにしても、まずは開発業務の改善に対する意識付けが必要です。それがいつどのようにできるかは別にして、実際に開発標準を組織全体に展開する際には、それは経営レベルから現場レベルまで共有できていなければなりません。そのような文化的土壌がその組織にあるか否かによって、開発標準導入(もちろんほかの開発業務改善もそうですが)の成否が大きく左右されるといえ、必要ならば早い段階でそういう土壌を作り出さなければなりません。開発標準の導入に当たっては、常にこのような点を意識して活動を推進する必要があります。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ