連載
» 2005年06月09日 12時00分 UPDATE

開発プロセス標準化への道(2):開発プロセスは継続的かつ段階的に改善すべし

[今村智,健全ITプロジェクトプロデューサー]

 今回は、継続的、段階的なプロセス改善についてお伝えしたいと思います。皆さんの中には、「継続的、段階的なプロセス改善」と聞くと、CMM(I)を瞬間的に連想される方もいると思います。そのように連想される方は、おそらくCMM(I)を正しく理解されている方だと思われます。ところが、いろいろな方と話をしていると、CMM(I)を何かライセンスのようなものと勘違いしている方が多く、せっかくの良いものが正しく理解、活用されていないなぁと残念に思うことがよくあるのです。ただ、今回は、CMM(I)に特化した内容ではありません。もっと基本的で、しかも、このことをみんなが理解したら、ITプロジェクトの現場がもっとハッピーになる、そんな話です。

究極の目的は、全員の成長

 前回、「開発プロセスの標準化は、開発力を高めるための取り組みの1つにすぎない」ということを書きました。そして、標準プロセスは、参照はするけれど絶対的なものとしないことが大切だということも書きました。そのような認識、心構えで標準プロセスをとらえた場合、そこから得られるものは何だろうか? という疑念がわき起こるかもしれません。それは、一言でいうと「成長」だと考えています。プロジェクトの成功ではありません。みんなが成長することによって、そのご褒美としてプロジェクトの成功の確率が高くなるのです。

 ここで、人の学習タイプを簡単に整理しておきます。人の学習タイプは、大きく3つに分けられます。

  1. 自分で考えて、自分で実践して学ぶタイプ
  2. 他人の経験、事例をまねることで学ぶタイプ
  3. 完全に他人の経験、事例、意見に従うタイプ

 3番目のタイプは、厳密には学ばないといえるかもしれません。1番目のタイプは、天才です。厳密にはこのタイプはいないと私は思っています。何1つインプットのない状態で、何かを考えたり、アイデアを思い付くことは普通できないと思うからです。2番目のタイプは、@ITを自発的に閲覧されている皆さんを筆頭にして、多くの人がこれに当てはまります。

 ということは、大多数の人が学ぶ、成長するためには、いうまでもないことですが、何らかの見本、手本が必要なのです。ポイントは、前回の繰り返しになりますが、絶対服従ではなく、何かを学ぶための材料として標準プロセスが必要だということになります。では、標準プロセスからどのようなことを学ぶかというと、

  1. まずは、標準プロセスに従って実施→うまくいったこと、改善の余地に気付く
  2. 改良版プロセスを実施→さらにうまくいったこと、改善の余地に気付く
  3. さらなる改良版プロセスを実施→……

ということです。これを際限なく繰り返すことが成長するということです。このような視点で見たときにも、標準プロセスを絶対的なものとして扱うことの問題に気付きます。標準プロセスを絶対的なものとするということは、

「あなた(自分)たちは成長しなくていいのだ」あるいは、「あなた(自分)たちが成長できるとは思っていない」

といっているに等しいからです。少し刺激的なことをいってしまいましたが、意図はくみ取っていただけると思います。

 同じものを大量生産するのであれば、一度成功が確認されたやり方を、毎回微に入り細をうがってまねることが得策でしょう。しかし、多くのITプロジェクトは違いますね? だから、すべてのITプロジェクトに通用する唯一のプロセスなどないし、個々のプロジェクトに最適なプロセスを事前にすべて作り上げることもできないのです。だからこそ、学んで、成長するしかないのです。

飛躍的な成長はない

 IT業界でも、とても高名なプロジェクトマネージャや、名は知られていなくとも非常に優れたプロジェクトマネージャの方がいます。いうまでもないことですが、その方たちは、一夜にして優れたプロジェクトマネージャになったわけではありません。毎日の成長の積み重ねの結果、優れたプロジェクトマネージャと評価されるようになったのです。一歩一歩、一段一段階段を上ったのです。2段飛び、3段飛びはありません。

 ところが、標準プロセスには、その組織にとっては100段飛びとしか思えないような立派なものをよく見かけます。単体テストの自動化もしていないのに、イテレーティブな開発プロセスだったり、要求のタイプと構造すら整理できていないのに、品質管理については事細かに規定してあったり……。

 それは、標準プロセスではなくて、理想のプロセスなのです。しかも、あくまでもその時点で考えの及ぶ範囲での理想のプロセスです。標準プロセスは、いますぐ実行できなければ意味がありません。ですから、実行できる/できないという基準で組織のレベルとの関係を表すと、

  • 現在の組織のレベル < 理想のプロセス
  • 現在の組織のレベル ≧ 標準プロセス
  • 現在の組織のレベルの少しだけ上 = 今回実行するプロセス(標準プロセスをカスタマイズしたものなど)

という状況が、健全な状態だと考えています。ただし、現実的には、初めて標準プロセスを定めるような場合には、それ自体が、現在の組織のレベルよりも少し高いものとなりますが、実行時のイメージもわかないくらい立派なプロセスは実行することはできません。

ALT 図1 継続的、段階的な人、組織の成長と、継続的なプロセス改善を両輪に持つことで、開発組織の競争力を高めていくことが可能となる

 さて、ここで、どうしてもCMM(I)のことが気になる方も入ると思いますので、少し触れておきます。果たして、CMM(I)は、開発力の向上、強化につながるのでしょうか? 答えは、YES! でありNO! でもあります。なんだかありがちな答えで恐縮ですが事実なので致し方ありません。SEIの公式サイトで公開されているCMM(I)に基づくプロセス改善への取り組みによる各種結果報告は、こちら(http://www.sei.cmu.edu/cmmi/results.html)から見ることができます。ここにあるデータは、基本的に良い成果が得られた場合のものとなります。

 では、良い結果が得られない場合はあるのでしょうか? これについて、私は統計データを持ち合わせてはいませんが、TeraQuest社(2005年1月に米ボーランドと合併)のコンサルタントに聞いた話では、「少なくない」ということでした。それは、どういうことなのでしょうか?

 開発力は、図2に示すようにプロセス、人材、技術の3要素で構成されます。ある組織の開発力とは、これらの総和ではなく、積算で表されるものと考えてください。つまり、どれか1つでも“ゼロ”であれば、開発力も“ゼロ”です。開発力がゼロとは、顧客が求めるQCD(品質・コスト・納期)」を満たせないということであって、何も作れないということではありません。

ALT 図2 開発力は、プロセス、人材、技術の3要素で構成される

 この3つのどれか1つが弱くても、開発力は落ちるわけですが、とりわけ重要なのは人材であることに間違いありません。どんなに立派なプロセスがあっても、きちんと実践し、適宜改善しながら現実に対応できる人材がいなければ話になりません。同様に、どんなに素晴らしいITが存在したとしても、それらを適切に使いこなし、顧客の課題解決に適用できる人材がいなければ猫に小判というものです。

 話を戻すと、例えばCMM(I)のレベル3を達成するために必死にプロセスを定義しても、人材、技術のどれかがプロセス見合うだけのレベルに達していなければ、結果としてはNGとなるのです。

 開発プロセスの標準化に取り組む場合の多くは、文字通りプロセスの定義に注力してしまい、人材や技術の成長、整備に対応できていないのです。開発力を高めていくためには、理想の標準プロセスを作るのではなく、いま実行できるプロセスを作り、人、技術を少し成長させたらそれに合わせて少し標準プロセスのレベルを上げるという当たり前のことを着実にやるしかないのです。

ALT 図3 開発プロセスは常に改善していく必要がある

 今回は、組織、人の成長という視点からの標準プロセスへの取り組み姿勢についてお伝えしました。次回は、標準プロセスを作ろうとしたときに、まずはどこから始めればよいのかについてお伝えする予定です。

プロフィール

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

ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。 Webサイト( http://www.human-process.com/ )からの情報発信も行っている。



Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -