これまでの「標準化」の間違い（2003/1/8) ソフトウェアの規模の増大や作業量の増加のたびに、また多量のバグの発生のたびに、事態の打開を図るために「標準化」への取り組みが浮上します。現場での作業が、人によってばらばらであったり、成果物の内容も担当者任せになっている状況が、作業を混乱させている次一つの要因であることは明らかなので、この“ばらばらな状態”を解決できれば問題は消える、と思うのも無理はありません。
実際、５〜１０年の間隔で「標準化」とか「標準プラットフォーム」という形で持ち上がってきます。そうして、取り組んだものの、ほとんどが失敗します。そして、後に残るのは“むなしさ”であり、諦めの思いです。この「失敗体験」のために、その現場では、このあとしばらく「標準化」という言葉はタブーになることさえあるのです。５〜１０年の“間隔”が開いているのは、この時に取り組んで失敗した人たちが、その後の何回かの人事異動で現場から離れるのに要する時間でもあるのです。
最近の「ＣＭＭ」への取り組みも、このサイクルの例外ではありません。９０年前後に「標準化」に取り組んで失敗しているところは、直ぐには「ＣＭＭ」には取り組めなかったと思われます。現場の人たちは、かっての悪夢を思い出し、「ＣＭＭ」を過去の取り組みとダブらせてしまうのでしょう。それでも、「ＣＭＭ」が世に出て１０年という時間が経って、世の中に認知されたことや、政府（産業経済省）を中心に盛んに「ＣＭＭ」を持ち出していること、幾つかのコンサルティング会社が「ＣＭＭ」のビジネスを展開し始めたことなどによって、過去に「失敗体験」を持つ多くの組織も、「引きこもりの穴」から這い出し始めるものと思われます。
問題は、過去の「標準化」での失敗の原因を解明せずに布をかぶせてしまい、それを外すことをタブー化してきた組織では、「ＣＭＭ」も、これまでと同じように間違った「標準化」の枠の中でしか考えられない可能性があるということです。
◆ 委員会方式の問題 ◆
これまでの「標準化」の取り組みでは、多くの場合「標準化委員会」という形でそれぞれの職場から人が集まって、そこで「あるべき開発手順」を練り上げるという形がとられてきました。そこでは、現状の問題をリストアップし、そこから「どうすれば良いか」を考え、「こういうドキュメントが必要だ」とか、中間成果物の構成の中に「こういう項目があった方がいいだろう」と言って新しい項目を盛り込んだりして、大掛かりな「標準」を作り上げてきました。そこで考えられた「標準」は、まさに「万能の標準」であり、これがあれば「これまでの問題はすべて解決でき」で、現状の「混乱から開放される」はずの救世主的な「標準」になっているのです。結局、いつの間にか『銀の弾丸』を作っていたのです。
それでも、こうして「標準」の形にまで持ち込めた組織は少なかったのではないかと思われます。「委員会」のメンバーは、他に開発の案件を持っています。いや、そっちが「本業」なのです。実際の開発がうまくいっていない組織の人たちですから、そのうちに（いつものように？）自分のプロジェクトで煙が出始め、「委員会」どころではなくなってしまい、いつの間にか形骸化し、さらには自然消滅してしまうケースも多かったのではないかと思われます。そのような状況の中では、１人が出席できないという一つのきっかけで、委員全員が“忙しい”状態を作ってしまうようになり、自然に「委員会」を再開する機会を潰す方向に動いてしまうようです。といっても、実際には、そこにある混乱を解消する方法が手に入っていませんので、何もしなくても再開できる目処は立たないのですが、少なくとも、「委員会」を再開させる方向に努力されることはなく、いつの間にか、「例の委員会は？」という言葉がタブーになってしまうのです。
委員会方式が上手くいかないもう一つの原因は、各部から選出される際に、適任者が選ばれているとは限らないことです。ひどい例は、入社して２，３年目の人が送り込まれることもあります。これは、「標準化」の取り組みが、組織を上げての取り組みになっていないことに原因があると思われます。部門長が、組織のために自分の部の中のキーマンの時間を割くことを快しとしないのでしょう。これでは、最初から結果は明白です。
◆ 誰もやったことの無い「標準」◆
幸運にも「標準」の形に持ち込めたとしても、これが実際に運用されることはほとんどないというのもまた現実です。委員会のメンバーが関係しているチームで試行的な位置づけで取り組まれることはあっても、そこから広がっていくことは非常に少ないと思われます。
そこで作られた「標準」が成果物中心に考えられていて、プロセスを含めて全体の合理性が追及されていないことが多く、実際に取り組んでみたプロジェクトの人から、「書かなければいけないドキュメントやレビューが増えて大変！」などという声が上がってくることもあります。そのため周りの人たちは“自分たちのところに回ってきては大変”と『警戒モード』に入ります。このような状況の中では「水平展開」も実現しないのは言うまでもありません。中には、半年かかって作った「標準」が、まったく日の目を見ないことすらあるのです。
なぜこうして作られた「標準」がうまく機能しないのか。忙しい中で、皆が集まって「叡知」を集めた筈なのに、なぜ使えないのか。ここに答えを出せないことが、“やっぱり・・・”とういう諦めや“むなしさ”の感情を生み出し、“タブー”という反応に繋がってしまうと思われます。何れにしても、ここで多くの人は「考えることを止めてしまう」ようです。
折角の「標準」がうまく使えない理由としては、大きく２つ考えられます。
１）「標準」が実際の要求にあっていない。
つまり、現実のプロジェクトの要求は似ているところはあっても毎回違います。前回と比べて、内容が簡単であったり難しかったりします。期間ももっと短い期間で仕上げることを求めてくるでしょうし、必ずしも「標準」で考えた中間成果物は必要ではないかも知れません。一番分かりやすい例を言えば、現実のプロジェクトの大半は「派生モデル」のパターンなのに、叡知を結集した「標準」は「新規開発」のパターンです。少なくとも、私は３０年間、５０余りの顧客に出向きましたが、「標準」と呼ばれるものの中に、「新規開発」のパターン以外は見たことがありません。つまり、現実の要求を考慮せずに、「あるべき姿」を追いかけたのが「標準」なのです。というより、あの時点では、「現実の要求」は考えていないのです。
２）その「標準」は、誰もやったことが無いものである。
ほとんどの場合、そこで考えられた中間成果物や作業の手順（プロセス定義の一種？）は、委員会のメンバーも含めて、誰もやったことが無いという可能性があります。しかも、そこでまとめられた「成果物の定義書」は、“プロセスと成果物の連鎖”という視点で考えられていないことが多く、現場のエンジニアには、どうすれば定義された中間成果物の項目を埋めることができるのかが見えないのです。それにも関わらずに硬直的に取り組まれるため、決められた「中間成果物を作る」ための作業が行われます。成果物は、利用されなければ価値はなく、そこに投入した時間は回収できません。その結果、「標準」は時間もコストもかかるもの、というおかしなことになってしまうのです。これでは、現場のエンジニアのとってはありがたくもないのです。
◆ “標準”は一つとは限らない◆
技術は常に変化します。要求も時間とともに変化します。製品のカテゴリが違えば開発の規模も違ってきます。その要求を実現する側の設計者たちの事情も毎回異なるでしょう。そのような中で「標準は一つ」というのはおかしいいと思いませんか。
プロセスの「標準」というのは、自動車の「プラットフォーム（車台）」と同じです。車台は、自動車のカテゴリごとに必要になります。同じように、ソフトウェアの開発プロセスの「標準」も、事業部によっては扱う製品（システム）の規模も開発の体制も大きくことなるかもしれません。それを組織の中で「一つ」というのでは、「標準」としては要求から距離がありすぎます。
一つの問題は、「標準」を“そのまま使おう”としていることです。自動車の「車台」は、シャーシとエンジンなどの「基本構造」しかありません。あとは、要求に合わせて、この「車台」に仕様を足していくことになります。「引くもの」はほとんど無いように考えられています。実際問題として、両方混じるとややこしくなります。
ソフトウェアの「標準プロセス」も基本的にはこれと同じように考えるべきです。それでも、新規開発用の標準としては複数パターンが必要になるでしょうし、派生開発用とは区別すべきです。一つの製品のカテゴリに限定すれば、そこでは新規用で１種類、派生用で１，２種類あればよいでしょう。結果として、別の製品カテゴリを扱う他部門で流用できる可能性はあります。
さらには、こうした「エンジニアリング・プロセス」だけでなく、要件管理や構成管理、進捗管理といった「マネージメント・プロセス」も、別に必要になります。マネージメント・プロセス」は、一般的にはほとんど共通に使えます。そこで使用するツールの違いなどで、若干の差が生じるぐらいです。
現場の人たちは、この「エンジニアリング・プロセス」の「標準」に対して、常に何らかの手を加える作業が必要です。「標準」を使うことによって、新規に開発プロセスを作る（プロセスを設計する）よりは作業は軽減されるでしょうが、必ず「標準」に対して手を加えなければならない状況に置いておくべきです。そうでないと「プロセスを設計する能力」が失われ、「標準」による弊害が出てしまいます。
先に触れたように、技術や要求は時代と共に変化しますので、プロセスも変化させなければなりません。今回の要求に応じるために必要なプロセスを考え（設計し）、「標準」のまま使えるところを理解した上で、不足するプロセスを「標準」に追加するのです。「ISO-9001」の問題の一つは、この「プロセスを設計する」能力を発揮させなかったことです。
◆ ベストプラクティスを吸い上げる ◆
これまでの「標準化」の取り組みでの大きな間違いが、実際に誰もやったことの無い「理想」の「標準プロセス」を持ち込もうとしたことにある、ということは最初に触れました。プロセスの改善というのは、突き詰めれば「個人の習慣の改善」でもあり、それがために簡単に実現しないのです。
「標準」と、エンジニアの身に付けた習慣との開きが大きすぎると、自分の習慣との親和性が無くなり、「標準」は取り組まれなくなります。もちろん、「トレーニング」というプロセスを持ち込むことで、身に付けた習慣を「標準」に近づける方法があるのですが、「レベル２」に達していない組織では、それはほとんど実現しません。教えることができる人が存在しないのと、「トレーニング」の準備に投入できる時間が確保できないからです。
したがって、実際にそこで行われている作業（プロセス）を調べて、ちょっと改良すれば使える成果物やプロセスを見つけて、それをベースにして、親和性を維持しながら以前よりは“ましなプロセス”を組み上げるのです。エンジニアの身に付いた習慣（＝プロセス）との乖離が少なければ、習慣を新しい「プロセス」に近づけることができます。もちろん、これは「銀の弾丸」ではありませんので、画期的な結果はもたらさないでしょうが、前よりは“ましな結果”を手に入れることができます。
大事なことは、そこに居る人たち全員が、「何かを変化させたら結果が変わる」ことを知ることであり、これを繰り返すことで、「“なかなか良いじゃない”開発プロセス」を手に入れることになります。これが「ベスト・プラクティス」です。これは、実際に現場の人たちが考え、そして実行し、改良してきたものです。まだまだ「格好良い」ものではないかもしれませんが、間違いなく、この開発プロセスは実行できるものです。そして、何よりも大事なことは、ここに関わってきた人は、全員「プロセスを設計する」ことができるようになっているということです。ですから、彼らは、この後も、継続的にこの「ベスト・プラクティス」を改良することができます。
こうして使われてきたものを「組織の標準」として取り上げるべきなのです。もちろん、「標準」とするには、そのプロジェクトにユニークな要求に応えるためのプロセスや成果物は削ぎ落とすことになります。こうして「車台」ができるのです。
削ぎ落とされてシンプルになった「車台（標準）」を使うには、この「標準」の適用可能な範囲や、そこに設けられているプロセスや成果物の意図を読み取り、そこに自分たちの要求を満たすプロセスを加えて「自分たちのための開発プロセス」に仕上げることになりますが、これができるのは、ある程度「プロセスを設計する」能力を持っていることが条件になります。
これは、プログラムがある程度書けるようになるまでは、人のプログラムを読みこなせないのと似ています。標準化委員会のメンバーの人も、昔はそうだったはずです。これと同じように、自分自身の分担部分の「プロセスを設計する」ようになって初めて、「標準」の意図が読め、それなら「こう変更すればよいだろ」として標準プロセスの定義の一部を変更できるのです。最近では、オブジェクト指向のライブラリを理解し、それを使いこなすという場面で、まったく同じ問題が発生します。
実は、「水平展開」ができるのはこの時ですが、こんなことはお構いなしに、組織の上の方から、「水平展開」を進めよ、という号令が飛んできます。関係者全員が、このように「プロセスの設計」に取り組まなければ、プロセスの「標準」は浸透しないのです。
１０年前、「ＣＭＭ」と出会って研究に取りかかったとき、レベル２では必ずしも「標準」を持ち込まなくて、むしろ自分たちでプロセスを設計し、それを積み上げて「ベスト・プラクティス」を作ることに重点が置かれていることに気がつきました。他にも重要なポイントはありますが、これなら「間違った標準化」に陥らないと判断し、それ以来、「ＣＭＭ」を勧めてきているのです。私は、公認のリードアセッサーではありませんので、「ＣＭＭ」に特に義理はありません。それでも、これは信用できる方法だということで勧めているのです。
◆ 最初から教えれば済むか？ ◆
「標準」に取り組む際の難しさは、それまでに身に付けた「習慣」との乖離にあるという説明をしましたが、それなら、最初から「“そのまま使える”標準」を教え込めばどうなるか。
確かに、そのカテゴリ（や特定の現場）では上手くいく方法なので、しばらくはそこで発生する要求には応えられるでしょう。しかしながら、問題は市場の要請は止まっていないということです。言語も設計手法も変化していきます。手法が変化すれば、中間成果物は変化し、それに対応するプロセスも変わらなければなりませんが、この時に、自在に「プロセスを設計する能力」がなければ行き詰まります。
たとえば、組織の上層部にいる人たちは、その時々の状況の中でそれなりに上手くやってきた人たちだろうと思われます。その人たちの中には、今でも「テストをガンガンやって品質を上げればいいじゃないか」と言います。この人たちにとって、いわば成功体験として「テストをガンガン・・」という方法を身に付けているのでしょう。だが、生産規模も違うし規模に対して与えられている期間も違います。言語やプログラミングの方法も違います。ソフトウェア・エンジニアのハードに対する知識のレベルも違う。開発環境も違う。そのような中で、とにかくさっさとプログラムを書いて、あとは「テストをガンガン・・」というやり方は通用しなくなっているのです。
このことは一般には『成功体験の問題』として論じられていることで、このＨＰでも別の所でこの問題に触れることにしますが、最初から「出来合いの標準」を身に付けておくことで、少なくとも、これを何も持っていない人よりも長く仕事に対応できるでしょうが、実際に、時代の変化によって、プロセスを変化させる必要が生じたときには、対応できなくなります。
大事なことは、組織の全員が「要求を実現するために最適なプロセスを設計できる」能力を持つことです。「標準」がそれを邪魔しては本末転倒になります。「標準」を持ち込むメリットを活かしながら、それでいて「標準」によって大事な能力を失わないところに「標準」を求めるべきです。少なくとも、「ＣＭＭ」のレベル２とレベル３のところに、この配慮が働いているというのが、私の理解するところです（私の独断かも知れませんが）。
◆ 出来合いの標準の弊害 ◆ （2003/3/22追加）「標準」ー何と心地よい響きだろう。
開発組織に中で、大幅な納期の遅延が起きていたり、多発するバグを処理しきれずに市場トラブルとなってはじめて、何とかしなくてはと動き出します。私のところに来るのも、ほとんどはそのような状態に陥ってからです。
その中に３つのタイプがあります。一つは、何をしていいのか分からず、取りあえず相談にくるというタイプ。２つ目は、社内で「標準化委員会」を立ち上げたものの、そこでの進め方を相談に来るというタイプ。そして３つ目は、ISO-9001 などで決めた手順に沿って作業を進めてきたが、ここに来て市場の要求からずれてきてしまい、どうすれば良いのか分からないというので相談にくるタイプです。
３つに共通しているのは「標準」です。第１のタイプも、実は「標準化」に取り組もうとしているのですが、その取り組みもかわからない状態です。それが分かれば第２のタイプとなります。“巷には「ＣＭＭ」というのがはやっているようが、これを導入すればなんとかなるのではないか”という期待が背後にあるのです。実際、多くの組織では、「ＣＭＭ」は品質を改善してくれる「標準」の一種と認識されているようです。どうやらこの段階では、ＣＭＭの資料（ＴＲ２４など）はほとんど読まれていないのでしょう。
◆ 銀の弾丸としての「標準」 ◆ （2003/3/22追加）
多くの組織では、混乱の原因は「標準」が欠けていることだと思っている。確かに、そこで行われているソフトウェアの開発作業には、“統一”されたものはありません。“統一”されたものがあるべきだという認識があって、だからそれが欠落していることが原因だということになるのでしょう。そこで必死になって“統一”するための「標準」を求めることになります。このとき、「標準」は「銀の弾丸」として捉えられているのです。これさえあれば、現場で起きている問題は解決すると思っているのです。いや、思いたいのかもしれません。
もちろん、そこでイメージされている「標準」は、成果物の標準であったり、一般的な工程レベルの作業手順の標準でです。プロセスのコンサルティングをしている者の立場から見て、そこで起きている問題は、そのような「標準」の問題ではなく、それらの前提となる「要求を仕様化する技術」の問題であり、その要求にマッチした「プロセスを自在に設計する能力」の問題なのですが、混乱に陥っている組織に、その区別は付かないかも知れません。
そして、社内で「標準化委員会」のようなものが組織されたとたん、その委員会のミッションは「標準を作ること」になってしまいます。これは過去に何度も繰り返された行動です。その度に、むなしい思いをしたはず。それなのにまた繰り返そうとしているのです。あの時に作った「標準」が、実は不十分なものだったのだという認識か、取り組みやすい「標準」ではなかったという認識なのでしょうか。あるいは現場の人たちがまじめに取り組まなかったからという認識もあるかも知れません。だが本当の原因は、そこでまとめた「標準」は、現場の誰も実行したことが無い「絵に書いた標準」であったり、どこかの文献からの「借り物標準」であったり、現実の要求を無視した「ワンパターンの標準」だったりしたために活用されなかったのです。
多くの組織では、このような検証（失敗の検証）が行われることもなく、今回もまた「標準」に活路を見出そうとしています。
◆ 出来合いの「標準」を求める ◆ （2003/3/22追加）
「銀の弾丸」としての標準を求める気持ちがあるために、そのまま持ってきて使える「出来合いの標準」を求める方向に動いてしまいます。そこでの「標準」は、“万能”とまではいかなくても、少なくとも「標準」で決められた通りに作業をすればうまくいくものなのです。このような考えは、過去の「ＱＣ」活動のなかでも見られたし、「ISO-9001」でも見られたものです。そしてそのほとんどは失敗したのです。
たしかに、製造現場では「標準」にそって作業を進めていくように考えられています。つまり「標準プロセス」に人の方が合わせるののです。それくらいに細分化しているし、パターン化できる世界でもあるのでしょう。
だが、ソフトウェアの設計は、そうはいきません。要求（機能＋品質＋制約）が変化することによって、その要求に応えるために毎回プロセス（の一部）を調整しなければなりません。対応する人のスキルも変わるし開発環境も変わります。そんな中でも毎回使える「出来合いの標準」を求めているのです。過去の「標準化」の取り組みが継続しなかった原因の一つがここにあるにもかかわらず。
◆ ISO-9001 に見られる２つの行動 ◆ （2003/3/22追加）
メーカーのほとんどは、「ISO-9001」の認証を取得しています。ソフトウェア会社でも「ISO-9001」を取得しているところは多いようです。これも「標準」です。残念ながらこれがソフトウェアの品質や生産性にほとんど寄与していないのではないかと思われます。それも当然です。「ISO-9001」はＣＭＭでいうところの「レベル３」に相当します。しかしながら現実の組織は「レベル２」にも達しないのです。つまり組織のの能力は「ISO-9001」が取得できる状態ではないのです。
ここで２つの動きを見ることができます。１つは、「ISO-9001」を無視して、形だけのものにしている組織です。この場合は、審査の直前にドキュメントを整える作業が入ります。もう一つは、「ISO-9001」を忠実に守って、これに沿って確実に作業をする組織です。問題は後者のタイプで、このような組織では、「ISO-9001」の導入当時としては、これで多くの問題を解決したかにみえたのでしょう。だが１０年経って、その「標準」は時代の要求に合わなくなってしまったにも関わらず、組織の誰も、この「標準」を変えることができないでいるのです。
◆ 出来合いの「標準」が何をもたらしたか ◆ （2003/3/22追加）
「ISO-9001」は、組織の中に「標準」をもたらしました。「審査」という関門があることで「標準」として維持されてきたのです。だがそこでの「維持」は、多くの場合「方法を変えない」「標準を変化させない」方向に誘導したようです。たしかに前回の審査と変わっていなければ、審査はやり易いでしょう。だがその結果、変化する世の中の要求に合わなくなったとしても不思議ではありません。
「ISO-9001」もこのことに気付いて、2000年の改訂版で変化を誘導できるように改良を加えました。だが遅すぎました。少なくとも日本では遅かった。１０年間、先人が用意した「標準」を守ってきた結果、時代に合わせて新しい「標準」を構築できる人が、組織の中にいなくなってしまったのです。１０年前に「標準」に取り組んだ人も、９０年代のリストラの波を受けて今はもういないかもしれません。僅かに残っている場合も、かつての時と同じ「標準化」の行動をとってしまうでしょう。
安直に「出来合いの標準」を使うことに慣れてしまったことで、結局、変化する要求に合わせて、自在にプロセスを設計する能力を失わせることになったのです。私には、今またこれを繰り返そうとしているように見えます。『便宜に生きて、便宜に死す』の典型例である。
◆ ＣＭＭでも間違いを繰り返そうとしている ◆ （2003/3/22追加）
今、多くの組織は、再び「出来合いの標準」を求めて動き出しています。今度は「ＣＭＭによる出来合いの標準」です。だが、既に「出来合いの標準」を使うだけの環境の中に１０年身を置いてきた人たちに、新しい「標準」をリードできる人がどれだけいるでしょうか。「出来合いの標準」以外のところに「標準」を求めることができる人はいるでしょうか。
そもそも「ＣＭＭ」が目指すのは、“組織の能力”を引上げることです。そこでいう“組織の能力”とは、要求を実現するための最適のプロセスを自在に設計できる“能力”です。要求は絶えず変化し続けます。それに応じる側の体制も常に変化します。特に、ソースから距離が離れるプロセスに於いては、２度と同じプロセスは使えないと言っても良いくらいです。
「ＣＭＭ」の中で盛んに使われている「テーラリング」という言葉が、自在の能力を求めていることを象徴しています。「ＣＭＭ」に於いても「標準」は存在します。だがそれは「出来合いの標準」ではありません。ましてや、どこかから持ってきた「借り物の標準」でもないのです。それは紛れもなく自分たちがこれまで実行してきたプロセスを元にして作ったものです。前回のプロセスから枝葉を取り除いて共通的なものだけを「標準」として残したのです。もちろん、パターンは一つに限ってはいません。
ここでの「標準」は、そのままでは使えないのです。プロジェクトの要求に合わせて、具体的な成果物名を特定したり、調査のプロセスを追加したり、メンバーに合わせてプロセスを３つに割ったりしなければならないのです。「標準」は、プロセスを１から構築する時間と、その際のブレを省くのが目的であって、自分たちのプロジェクトに対する要求を実現するために、毎回、プロセスを設計する能力を失わせてはならないのです。
プロセスを自在に設計する能力を失った組織が、「レベル３」というのでは笑えない喜劇です。
「Software Process」のメニュー に戻る
［］