日本版ＣＭＭに対する私の意見-２
（2001/12/26発表に対する意見）
実態の認識が甘い
前回同様に、最初に情報サービス産業の急速な拡大について触れています。平成１１年には、情報サービス産業全体としての売上高が１０兆円に達し、そのうちソフトウェア開発・プログラム作成が６兆４千億円と報告されていますが、その後で、政府調達の７〜８割が１０社で占めているということで、多段の下請け構造が問題だとしています。でも、１０兆円ついては、何も修正されていません。多段の下請け構造が存在しているということは、売り上げの統計自体が、その集め方によっては重複していることを意味しています。たとえば、経済産業省が毎年行っている「情報サービス業調査票」のようなものに基づいているとすれば、ダブルカウントは避けられません。
もし、丸投げ構造が改善され、最初の発注者のところで適切に発注の単位が分割され、それぞれが適当なソフトウェアの開発業者に発注されれば、３割程度は金額が減少するのではないかと思われます。実際に、５段くらい先の下請け業者に降りたときには、一人当たりの金額が半分ぐらいに細っていることも珍しくありません。
外国の石油会社が日本でガソリンスタンドを建設する際に、本国からコンサルタントを連れてきて分割発注することで、国内の石油会社の建設費と比べて３割程度安く出来たと言われています。ガソリンスタンドの建設では、それほどの多段の下請け構造はないと思われますが、それでも、３割安く仕上がるというわけです。
政府調達ソフトウェアの場合は、５段ぐらいの下請け構造は珍しくありません。それから判断しても、３割ぐらいは水増し状態の可能性は否定できません。そしてこの問題は、単に金額だけの問題では済みません。「エンジニアの不足」という点でも、過剰に見積もられている可能性が出てきます。この中間まとめ案の中でも、「高度なＩＴ人材が極端に不足」していると報告されていますが、現実問題として、末端レベルで有能なエンジニアが不足しているというのか、一人が３０件もの丸投げ先の管理をしているという実態を緩和したいのか、どちらを指しているのか分かりません。現状の多段下請け構造の末端レベルで「高度なＩＴ人材」が不足していると言うのであれば、それはコスト面からも実現しないと言わざるを得ません。
この中間まとめ案では、「高度な人材」が育たない企業の体制については、何も触れていません。足りない足りないと言いながら、現実問題として、組織の仕組みが高度な人材が育つのを阻んでいると思われます。優秀なエンジニアに対しては、限度を超えた仕事の量が課せられているのは日常茶飯事ですし、ある程度の年数が経っているということで、組織の慣習として「管理職」という立場に釣り上げてしまいます。当人は、エンジニアで居続けたいと思っていても、「管理職」でないと報酬は増えません。住宅ローンの支払いや、子供の教育費を考えるとエンジニアから足を洗って「管理職」に就くのも止むを得ないか、といって自分に言い聞かせるのです。それに、山ほどの仕事に追われるのも疲れたし、まぁこの辺でいいか、ということになってしまわないでしょうか。こうして十分にソフトウェア開発について研究する時間を奪われてきたことが、いまだに「３５歳定年」が存在し続けている根本的な原因なのです。
それぞれの組織が、独自にＣＭＭに取り組めないのも、実際に上手くできた経験を得るまで、現場のエンジニアを続けて来た人がいないからです。上手くやったことの無い人にとっては、ＴＲ２５は味気のないものに映ってしまうでしょう。逆に、実際にＱＣＤをある程度達成し、上手くやったことのある人にとっては、ＴＲ２５は、読んで響くものなのです。彼は、ＣＭＭの背後のある「有効な技術」のいくつかを手に入れているでしょうから、ＣＭＭに取り組むのは、それほど困難ではないはずです。問題は、こういう人が企業の中で育っていないことです。現実の組織は、失敗を繰り返しても徹底して経験する機会を与えられない制度になっているのです。このような環境を改善しなければ、いつまで経っても「高度なＩＴ技術者」は確保できませんし、ＳＰＩなんて定着しません。これが実態なのです。
旧態依然とした社内の制度こそ、日本の競争力を損ねているのです。これこそ、政府が関与して改善すべきなのです。労働時間の監視や有給休暇の消化などを、きちんと罰則をもって推進することにすれば、「３５歳定年」をなくすことができるのです。そして、組織の中で、プロセス改善をリードできる人材を確保出来るのです。
ＱＣＤを前面に押し出してきたのは良いが
今回は、ＱＣＤの向上が大事であるということを前面に押し出していることは評価できます。もっとも、前回がＣＭＭを前面に出しすぎたために、激しい反発にあったことに懲りた結果なのかもしれません。とはいえ、ＣＭＭといっても、これはＱＣＤを向上させるための一つの「ツール」ですから、この認識は正しいと言えます。ただし、問題があります。この中間まとめ案では、ＣＭＭがＱＣＤ向上と直結してイメージされる危険があることです。
ＣＭＭのアセスメントは、必ずしも「技術」を評価できません。いや、場合によっては評価しないといっても良いかも知れません。たとえば、要件管理のＫＰＡで、要件の変更に対してきちんとしたプロセスが定義され、それが実施されていることが求められますが、要件管理の元になる、要求仕様書の書き方が適切かどうかまでは問えません。もちろん、あまりにひどいものは、「能力２」を満たさないと判断されるでしょうが、ある程度の表現がなされていればＯＫとするしかありません。
実際には、仕様の漏れが多く隠れていれば、後になって仕様の変更が多発します。でもＣＭＭ的には、要件管理のプロセスで適切に対応することになるわけで、これで要件管理は実現していると判断されます。しかしながら、仕様変更の発生の時期によっては、プログラムの品質を大きく損ねますし、納期だって満たさないでしょう。もちろん、コストは大きくオーバーします。これでも「ＣＭＭ的」には問題ないのですが、「ＱＣＤ的」には失敗なのです。少なくともＣＭＭのレベル２や３程度であれば、ＱＣＤを満たさなくても、特に問われないでしょう。
では、この案件は、もともと最初の工数では実現しなかったのでしょうか。最初から、仕様変更を織り込んだ工数を見積もるべきだったのでしょうか。もし、要求仕様の書き方に工夫の余地があって、仕様漏れが起きにくい書き方があるとすれば、最初の工数では無理としても、それに近い工数で実現する可能性が出てきます。仕様漏れが起きにくい書き方というのは、同時に、仕様漏れが発見しやすい書き方でもあります。その結果、仕様の変更の多くが、設計以前の工程で出てきますので、プログラムの品質を大きく損ねる危険は減少します。でも、このような要求仕様を書く技術の有無は、レベル２や３あたりのＣＭＭアセスメントでは問われないでしょう。それはＣＭＭが悪いのではなく、アセスメントの限界なのかもしれません。この意味で「ISO-9001」も同じと考えています。レベル４での取り組みにある「品質管理」のところでは、品質目標の設定に伴って、それを実現するための技術の存在が問われる事になるでしょうが、それ以前のレベルでは、技術を問うのは難しいでしょう。
ＱＣＤを前面に出したのであれば、ＣＭＭとのギャップをどうやって埋めるのかということに触れておくべきでしょう。現状の中間まとめ案では、ＣＭＭのレベルを取得することとＱＣＤの向上とが繋がっていると解釈される可能性があります。
政府調達の改善に徹すべき
もともとの発端は、政府調達ソフトのいい加減さが問題だったのではないでしょうか。複数の省庁で同じようなものを発注していることも明らかになっています。期限までに機能を満たさないので、一旦、機能未達のまま納品し、その後で「改良」作業が継続するということは珍しく無いようです。継続作業は、実際には別の名目になるのですが、実態は、満たさなかった仕様を盛り込むための作業が行われているのです。もちろん別料金です。こんなことが日常茶飯事で行われているとすれば、これこそ改善すべき対象です。
今回の「プロセス改善」の取り組みや、開発業者の能力判定、さらには、プロジェクトの厳密な進捗管理を必要としているのは、まさに政府調達ソフトなのです。だったら、ここに的を絞って、対応策を考えれば良いものを、自分たちも取り組むので、国中の皆さんも一緒になって取り組んでください、と風呂敷を広げるものだから、違った思惑に巻き込まれてしまうのです。
アメリカ政府のように、政府側にしっかりしたシステムエンジニアが居ない限り、大手以外に政府調達ソフトを発注することはできません。案件をどこかに「丸投げ」して、そこからの提案書を見て、そのまま良さそうな所に発注するしかないのですから。もちろん、提案書と実際の開発を分ける方法もありますが、いずれにしても、省庁内に優れたシステム・エンジニアが必要です。
中間まとめ案では、中小のソフト会社にも応札の機会を与えるべきなどと奇麗事が書かれていますが、応札するためには、案件を分析して、システムのアーキテクチャ設計まで終えて、実現性に問題がないことを示さなければなりません。中小のソフト会社にとって、その負担は容易ではありません。ましてやそれで受注できるとは限らないのですから。中小のソフト会社が参加できるには、発注前にシステムが設計され、中小のソフト会社でも扱える規模に分割されることが条件です。その部分を、省庁のシステムエンジニアが担当できない以上、大手のソフト会社に（丸投げ的に）発注するしかありません。
日本版ＣＭＭが導入されようとも、今の状態では、案件を丸投げする以外に方法は無いのですから、応札するのは、今と同じ大手１０社程度にならざるを得ないわけです。中小のソフト会社は、それらの大手のソフト会社に股を掛ければいいわけです。その方がリスクがないのですから。となると、中小のソフト会社がＣＭＭの認証を取得したとしても、政府の窓口には、そのソフト会社が直接見えるわけではありません。結局、大手のソフト会社がシステムを分割して中小のソフト会社に発注するときに、認証を取得している所に発注することで規制することになります。
そうであれば、政府調達ソフトの現状を改善するために、政府と大手のソフト会社の関係者たちとで、問題の解決方法を考えれば済むことです。ＱＣＤを達成するために何を改善すれば良いのか、考えれば済むことで、何も「ＣＭＭ」を持ち出さなくても解決します。日本中を混乱に巻き込まなくても、自分たちで取り組んでみて、うまくいった実績が出たところで、はじめて日本中に紹介し、リードすれば良いのです。その時には、指導者もそれなりに確保出来ているでしょうし、何よりも「実績」がものを言います。
もしかすると、現状の「ＣＭＭ」よりも優れたところがあるのかも知れません。今のように「ＣＭＭ」を追う限り、ＣＭＭを越えることはできませんが、別の方法であれば、ＣＭＭを越えることも可能です。西欧を真似ることはしても、西欧を越えようとはしないというのは、ある意味では、最近の日本の特徴なのかもしれません。誰も行ったことの無い道を行くのは、誰だって恐いのです。でも、そこに踏み出さない限り、日本は世界をリードすることはできません。
まるで、今の政府の進め方は、「プロセス改善」に関連して各企業で起きていることと全く同じです。ＣＭＭへの先発組は、周到な準備をして取り組んだのですが、第２陣は、焦りも手伝ってか、直ぐに全社的に取り組もうとします。どこかで確実に実現できることを確認してから、全社的に取り組めば良いものを、遅れを取り戻そうと拙速に出てしまいます。これでは、人材の育成も間に合いませんし、上手くいく道理がありません。混乱するだけです。
確信が持てるような手を打つべき
今回、「ＣＭＭ」を前面に出して強く押すという表現は無くなっていますが、それは表現だけの問題であって、それでは、具体的に「ＳＰＩ」や「ＳＰＡ」をどう進めるのかといえば、やはり「ＣＭＭ」（実際には「ＣＭＭＩ」の方）でなくちゃと言うことを含ませています。もっとも「ＣＭＭＩ」の場合、「Staged」モデルと「Continuous」モデルでは、様子が変わってくると思われるのですが、そのことは触れていません。つまり、本音のところは「ＣＭＭ」なのですが、それを前面に押し出すことをためらっているのです。そのため、今回の中間まとめ案は、主張が良くみえなくなってしまいました。
前回のように「ＣＭＭ」を強く押せない理由は、政府が推進するものとしては、一つのもの（方法）に統一すべきでではない、という意見が強く働いたものと思われますが、その他に、「ＣＭＭ」でうまくいくという確証がないのではないかと思われます。経済産業省の発注案件で、どこかで実験すればいいのですが。もしかすると「単年度予算」の弊害かも知れません。
現在、日本国内でＣＭＭの認証を受けた組織は、中間まとめ案では６社となっていますが、実際にはそれの倍以上はあるでしょう。その多くは公表していないものと思われます。公表しない理由は、ＣＭＭの認証が、実際のプロジェクトのＱＣＤに繋がっているのかどうか、まだまだはっきりしないのかも知れません。特に、レベル２程度では、認証の取得の仕方によっては、ＱＣＤについては改善していない可能性があります。もし、レベル２でＱＣＤに大きな変化がみえたにもかかわらず公表されないとすれば、その理由は、組織内部の１部門での取得であって、まだまだ安定していないということぐらいしか考えられません。
いずれにしろ、ＣＭＭでの国内の実績が、あまりにも少なすぎるのです。それにも関わらず政府が「ＣＭＭ」を押すのは何故でしょう。確かに、前回の中間整理案でこのあたりを激しく叩かれたことが、今回の躊躇につながっているものと思われます。そのため、経済産業省としてどうするのかも曖昧に成ってしまった感は拭えません。
ISO-9000 シリーズとの関係は？
もう一つ曖昧なままなのが、「ISO-9000シリーズ」との関係です。製造業では、ソフト部門を抜いて取得している所もあるのですが、ソフト部門やソフト会社で取得している場合は、ソフトの開発工程そのものに対して「ISO-9001」を取得しています。しかしながら、その殆どがＱＣＤに貢献していません。現場にとっては、決められてい成果物を「余分な作業」として残すだけの対応になるか、あるいはＱＣＤを無視して「ISO-90001」の品質マニュアル通りに作業を進めるかになっています。さすがに後者のケースでは、「ISO-90001」は無視されていることは無いようですが、市場の要請とのギャップで、大きな負荷に成っていることは確かです。
ソフトウェア部門に於ける「ISO-9001」も、ＣＭＭのアセスメントと同じように、背後にある「技術」を評価することは難しいはずです。あくまでも、管理手順に手落ちが無いこと、その手順を順守していることを評価することになります。つまり、要求仕様に漏れが無いような技術が使われているかどうかは問えないし、今回の開発プロセスが、今回の要求に対して最適に考えられたものかどうかを問うのは、容易ではありません。だから、いつも同じものを作り出し、いつもと同じプロセスを実行するのです。
従って、これらの有効な技術を持たないままに「ISO-9001」を取得した場合、成果物は“生み出すだけ”に成ってしまい、以降の作業（プロセス）の入力として十分なものであるとは限らないのです。そのため、その場しのぎで何かを整理した断片が無計画に生み出されていきます。また適切な要求仕様を書く技術がなければ、要件管理のプロセスは忙しいでしょうし、仕様漏れのバグで、担当者は追いまくられるでしょうから、ＱＣＤはミートしません。
必要な技術を伴わない状態での「ISO-9001」は、ＱＣＤとは離れたところにあるのです。多くの場合、このような組織が、再び「ＣＭＭ」の取り組みに直面するわけですが、ＣＭＭがこれらの問題を解決してくれるわけではありません。「ISO-9000」で遭遇している問題（の重要な部分）を解決できなければ、「日本版ＣＭＭ」の登場は、現場にとっては混乱をもたらすだけです。
認証ビジネスの餌食になる危険性
今回の政府の動きに呼応するかのように、インドのソフト会社が、ＣＭＭ認証取得を支援するコンサルティング・ビジネスを展開し始めたようです。「ISO-9000シリーズ」の時のように、「日本版ＣＭＭ」での認証ビジネスが成立すると読んでいるのでしょう。実際に、ＣＭＭ認証へ向けての第２陣、第３陣の動きが表面化したことは確かです。
多くの組織の担当者の間では、ＣＭＭがどこまで有効か、またどの程度のものか分からないままに、他社よりも遅れたくはないという心理が働いているものと思われます。逆に言うと、その心理こそ「認証ビジネス」が成立するためのベースとなるものです。アメリカでは、国防総省への応札実績のあるメーカーやソフト会社の殆どが、１０年近い時間をかけてレベル３以上の認証を取得しました。それを見届ける形で、国防総省は「レベル３」を応札条件にしたのです。従って、認証ビジネスと言えるほどのものは発生していないようです。
これに対して、日本で進めているやり方では、「認証ビジネス」が持ち上がってくることは避けられません。このことは「ISO-9000シリーズ」で経験したはずなのに、ＣＭＭでまた繰り返そうとしています。今回の中間まとめ案では、この「認証ビジネス」の問題には、一言も触れていません。まるで、自分たちには関係ないことで、それに乗らなければよいだけ、とでも言うかのように。今のような対応では、中小のソフト会社が、大手１０社の下請けの形で政府調達ソフトの開発を請け負うには、「認証」が必要になるのではないかという思惑が先行することは防げません。
この点については、きちんとした指針を示す必要があります。そうでなければ、早い者勝ちということで、認証を競うべく動き出すことでしょう。有効な技術を伴えば良いのですが、そうでなければ、この競争の犠牲になるのは現場のエンジニアです。「ＩＳＯ」の過ちを反省することなく、再び同じ過ちを繰り返そうとしていることは、残念でなりません。
この面からもやはり、先ずは政府調達ソフトに限定して、大手１０社など限られた関係者の中で、ＣＭＭも含めて効果的な方法を考え、実験すべきと考えています。その中では、必ずしも一つの方法に限定することもありませんし、さらに言えば、ＣＭＭに限る必要もありません。現実の何が問題なのかを見極め（＝要求の見極め）、それにはどのような事が実現すればよいのかを特定し（＝要求の仕様化）、それをどのよう方法で解決すれば良いのかを検討し（＝設計）、望ましい答えを出せばよいと思います。結果は、ＣＭＭで無くても良いでしょう。
要は、問題を解決して求められるＱＣＤを達成するような効果的な方法を見つけ、それを習得するための方法を確立すれば良いのです。