日本版CMMに対する私の意見


2001年6月16日発表の中間整理案についてのコメント

 平成13年6月16日に、経済産業省から、日本版CMMについての中間整理案が公表されました.昨年末に「日本版CMM」の取り組みが公式にマスコミに発表されてから、ソフト業界やソフトウェアの開発組織においては、気になる存在となったようです.正直いって、私自身も、日本版CMMは「気になる」存在でした.

 おそらく、今回の「日本版CMM」の推進に協力してこられた方々も、この内容には満足されていないのではないかと思われます.彼らは、日本のソフト産業の将来を憂えて、忙しい中で今回の企画にボランティアで協力してこられたわけですが、複雑な思いを抱いて居られるのではないでしょうか.

 私自身、プロセス改善活動の中でCMMと遭遇して、はや10年が経ちました.そして90年代の半ばからCMMを改善活動のなかに取り入れるようになったわけですが、今回の「日本版CMM」には、以前からいくつもの疑問や懸念を抱いていました.残念ながら今回発表された中間整理案で、それらの懸念が、私の思い過ごしに終わらない危険を感じています.

 日本に於て.この種の取り組みが遅れていること、いや、遅々として進まないことに対しては、関係者の一人として深く憂慮しています.だからこそ、私の持ち時間のほとんど全てを使って、「プロセス改善活動」を広げようとしているわけです.でも、一人で出来ることは限られています.20社も30社もサービスできません.かといって、自前の人材を育てている時間はありませんので、顧客の中に、種を蒔いて育てることにしたわけです.

 でも、日本においてこの種の取り組みが進まない理由が、CMMが認知されていないからではありませんし、リードアセッサーがいないからでもありません.いくらかは影響していますが、産業界全体で見ると、別の要因の方が大きいと考えています.今回の中間整理案では、その問題に触れられることなく、「日本版CMM」を導入して・・・というところに、危うさを感じざるを得ないのです.

 CMMは、それ自身よく考えられた SPI・SPA 手法です.もちろん、「万能」ではありません.CMU/SEI でのCMMのスポンサーが米国防総省であることが、大きな偏りを生んでいることも確かですが、それはCMMを活用しようとしている人が承知していれば済む問題であり、加減すれば良いわけです.

 今回の「日本版CMM」には、それとは違った問題を抱えているように思っていますので、このページを使って、逐次、幾つかの問題点を指摘し、そこに私の考える所を紹介していくことにします.この種の取り組みが、正しい形で広がっていき、多くの組織でエンジニアが創造する喜びを感じながら、ソフトウェアの開発・設計に取り組む環境が整うことを願っています.

 なお、経済産業省から、今後も、適時この種の情報が公開されるものと思われますが、現在、「我が国ソフトウェア開発・調達プロセス評価指標(日本版CMM)の策定に向けて(案)」と、他に関連する資料が、以下のサイトで見ることが出来ますので、ぜひ、皆さん自身で確かめて頂きたいと思います.なお、7月16日まで「パブリック・コメント」が募集されています.


なぜ「日本版」か? (2001/7/1)

 今回の「日本版CMM」に於ける最大の問題は、「日本語」ではなく、どうして「日本版」なのかということです.そこには、単に英語と日本語の問題ではなく、“ローカライズ”という行為が入っているわけです.CMMに対抗するものとして、ヨーロッパでは「SPICE」などが古くから取り組まれてきました.つまり、「ヨーロッパ版CMM」です.「SPICE」は、「ISO-15504」として発展し、さらに「CMMI」の中に採り入れられます.「日本版」が、このようなものをイメージしているのであれば、何も「CMM」である必要はないわけです.独自に、世界に認められる SPI・SPA 手法を構築すれば良いわけです.

 トは言っても現実問題として、自前で構築できる状態ではないし、だいいち「2003年までに世界でも最先端の電子政府を構築する」さらには「2005年に世界最先端のIT国家を実現する」というプランに間に合いません.もちろん、この「e-Japan計画」自体、目標とする状態を考えると乱暴きわまりないものです.ソフトウェアエンジニアリング教育の充実を伴わないままで、この計画が達成することはないでしょう.ソフトウェアエンジニアリング教育の見直しを含むような教育改革は、効果が出るまでには少なくとも5年程度の時間がかかるでしょう.ドイツも5年後の効果を目指して、カリキュラムの改革に取り掛かっています.しかしながら、今現在、日本においてソフトウェアエンジニアリング教育の改革は着手されていません.その結果、「e-Japan計画」も、おそらく最後は、政府省庁へのPCの普及度や、ホームページの数などで達成したとするのでしょうが、ソフトウェア産業の育成やソフトウェアの適正な調達は、そういう誤魔化しが効きません.

 結局、「国際的に認められた評価指標を採用することは有益」であると言い訳をすることで、「CMM」という既製品の導入を正当づけているように思われます.とはいえ、アメリカ版のCMMをそのまま日本に持ち込むには、いくつもの「壁」があります.その障害のほとんどは、ソフトウェアエンジニアリングの教育レベルの差に起因しています.リードアセッサーが生まれにくいのも、組織の中でSEPGやSQAの人材を確保できないのも、元をたどれば、「ソフトウェア・エンジニアリングが根づいていない」ことに、原因の多くが根差しており、同時に企業内部での人事制度などに関係しています.

 でも、このような状況だから、「SEI版CMM」の基準を少し緩めた「日本版」を作ろうと云うのであれば、本末転倒です.ソフトウェア産業を「21世紀の戦略産業」として位置づけ、「国際市場で通用する産業競争力を涵養していくことが必要」というのであれば、基準を緩めることは間違いです.中間整理案では、「日米の市場特性の差」があって、それがために、「SEI版」をそのまま日本に持ち込むことは適切ではないとしていますが、経済がグローバル化している今日にあって、この説明には納得しがたいものがあります.そこで「日本版」として許されるのは、日本の企業の実情に合わせて導入をスムースに運ぶようなガイドラインに調整することぐらいです.

 今日、CMMは世界各国で採り入れられています.でも、「オーストラリア版CMM」とか、「イスラエル版CMM」「インド版CMM」というものは見当たりません.確かにこれらの国には、言葉の障壁はありませので、翻訳というステップを挟む必要はありません.では、「市場特性」も差異はないのでしょうか.そうなると、「日本版CMM」で掲げられている「日米の市場特性の差」とは、いったい何を指しているのでしょうか.おそらく、ソフトウェアエンジニアを初めとする教育水準の差の他に、企業の商習慣の差、組織内での行動規範の差、企業の役所依存体質の差、などを含んでいるものと考えられますが、この現実を保護するような「日本版」は、結局、日本という「どんぶり」の中でしか通用しない基準を作ってしまうことにならないでしょうか.

 中間整理案には、「アセッサーの育成や認定は、・・公正かつ中立的な公的機関(政府又は政府に準じる機関)がこれらの役割を担うことが必要である」としています.この公的機関はこれから設立するのでしょうが、SEI のような能力を持つことは可能でしょうか.単に、牛乳パックの「公正」マークを付与するような「公的機関」になる危険性はないのでしょうか.さらに、ここで認定されたアセッサーは、日本以外で活動できるのでしょうか.もし、トレーニングや認定基準が、SEIの基準に従うのであれば、何も「日本版」とする必要はないでしょう.たしかに、アセッサーのトレーニングが日本で出来ることには大きなメリットはあります.でも、認定については、世界共通の基準でやって欲しいと思いますし、SEI で認定を受けるという選択も可能なようにすべきでしょう.

 「日本版」とすることで、「SEI 版」との差異の追及を逃れ、独自に運営していこうというのであれば、前車の轍を踏むことになるでしょう.


誰が「日本版」を欲しているのか? (2001/7/8)

 「日本版CMM」についてもう少し私の考えを述べることにします.CMM自身、米国防総省が自らのために SEI に開発を依頼したものですから、標準化(一般化)しているとは言え、当然、全ての産業や全ての規模の企業に適合するようには作られていません.「CMMI」は、米国防省寄りの傾向が一層強まっていると云われています.とは云っても、「上手く行く方法」というものは、多くの組織に共通していることも確かです.それは、今日までに既に証明されているといっても良いでしょう.業種や規模が必ずしもCMMで想定しているものとは違っても、これをプロセス改善の道具として使う側で加減すれば良いわけです.米国防総省の入札に関係しない多くの組織にとっては、その目的はプロセスを改善し、ビジネスを有利に展開することにあるのであって、CMMの認証を取ることが目的ではないでしょう.この点を外さなければ、日本語になった「SEI版CMM」でも構わないわけです.

 それでも「日本版」が欲しいというのであれば、それはどこから出る要求なのかを見極める必要があります.つまり「SPI」側なのか「SPA」側なのか.あるいは「認証機関」なのか.

 たとえば、これ(CMM)を自社のプロセス改善の道具として使おうという組織(SPI 側)は、あえて「日本版」を求める必要はないでしょう.「日本語」になっていることと、キー・プラクティスを自分たちの組織の中で「読み做す」ことができれば「SEI 版」で足りると思われます.CMMは「一般化」して表現されていますので、自分たちの組織の中で「具体化」しなければなりません.問題があるとすれば、必ずしも多くのソフトウェア開発組織では、そこから「具体化」できないということでしょう.もし、「国策」で「CMM」を活用して日本のソフト会社のプロセスレベルを引き上げようというのであれば、その部分は、「ガイドライン」のようなもので、幾つかのパターンに分けて無料で提供する方法があります.SEIに相当するような組織が研究し、その結果を公表する方法もあるでしょう.

 CMMの場合は認証に段階があって、段階で評価されるので、「ISO-9000」で起きたような「何でもいいから認証を取れ!」という事態は、ある程度回避できるだろうと思っていますが、それでも、とにかくCMMの認証を取って、それを材料にビジネスを有利にしようと考えているソフト会社もあるだろうと言うことは想像に難くありません.彼らは、この「日本版CMM」を待ち望んでいるのかも知れません.ただし、そのこと自体は必ずしも問題ではありません.認証を取得した結果、実際にソフト会社のプロセスの改善が実現し、顧客の要求に適切に応えることが出来ているのであれば良いわけです.もし、本気でそのようなビジネスの展開を考えているのであれば、なぜ「SEI 版CMM」で認証を取ろうとしないのか、という問題が残ってしまいます.費用の問題以外に、何か「日本版」に期待しているのではないだろうか.

 CMMの認証が、実態を伴わないかたちで与えられるようであれば、「日本版CMM」に対する信用が失墜するだけでなく、「CMM」そのものに対する認識も変わってしまう危険もでてきますし、「プロセスの改善」という取り組み自体への意識も冷めてしまうでしょう.アメリカでは有効かも知れないが、日本の風土には合わないもの、として切り捨てられてしまう.「日本版」が「SEI版」と比べて、認証が取りやすい、自分たちでも取れた、というようなことにでもなれば、このような「認証」そのものの価値がなくなってしまいます.それでも、「ISO-9000」のように、一度取った認証を必死に守るための「努力」が続くことでしょう.

 一方「SPA」側、すなわち、プロセスのアセスメントを行う側はどうでしょうか.昨今の景気の問題や、ソフト会社のコンサルティング業務(部門)の停滞状況を考えると、「日本版CMM」を機に、社員にアセッサーの資格を取らせて、新しい「SPA」ビジネスの展開を考えているものと思われます.これも実に全うなことです.私だってそのような立場であれば、これを機に自社の新しいビジネスの展開を考えるでしょう.ただし、私の場合は、「SEI 版」で取ることを考えます.

 現実問題として、ソフト会社やソフトウェア開発組織が、CMMの認証を受けようとしてアメリカのリードアセッサーに依頼すると、高額の費用が掛かるようです.その金額は、中小のソフトウェア会社では、ほとんど負担できない金額かもしれません.「日本版」ということで低価格で認証が取れるということであれば、それは素晴らしいことであり、それこそ、国を挙げての取り組みというものです.もちろんこの場合も、認証と実態が一致していなければ、逆に反動が発生し、ソフト会社によるこの種のコンサルティング・ビジネスは、致命的なダメージを受けることになるでしょう.ここでも、アセッサーの資格の取得が、言葉の障害を除いて、「SEI 版」と比べて取りやすいということになれば、彼らによる認証と認証を受けた組織の実態とが乖離してしまうことになってしまい、コンサルティング業務の信用失墜に繋がってしまいます.

 SEIのリードアセッサーによる認証費用の問題については、他に解決方法があります.政府の真意が、日本のソフト会社やソフト開発組織のプロセス改善を推進し、そのステップとして SEI の認証が有効であると考えるのであれば、政府がその認証取得にかかった費用の一部を補助してやれば済む問題です.例えば、レベル2だと30%、レベル3では50%、レべル4以上は80%ぐらい認証の取得費用を補助すればよいでしょう.平均200万円補助するとして、1000社が認証を取得したとしても20億円です.それで世界に通用するレベルに達しているとすれば、すぐに元はとれるでしょう.SEI のアセッサーということで言葉の問題があるのであれば、それこそ政府が支援して通訳を付ければ良いでしょう.このとき、完全にSEI から請け負うのは、トレーニングだけです.そのために、一定期間 SEIから要員の支援を受けることも有効でしょう.

 もう一つの立場があります.それは、日本においてアセッサーの育成や認定を行ったり、アセスメント結果を評価し、組織に対してCMMの認証を与える機関です.中間整理案には「公的機関(政府又は政府に準じる機関)の設立」が想定されていますが、もしかすると、この組織が「日本版」であることを必要としているのかもしれません.

 たしかに現実問題として、SEI の公認のリードアセッサーの資格を得るのは容易ではありません.言葉の問題を除いたとしても、所定の期間内に決められた活動をこなさなければなりません.でも、これはアセッサーの信頼を維持し、公正を維持しながら適切なアセスメントを実施するために必要なハードルです.「日本版」ということで、このハードルを下げるようなことがあってはなりません.また「SEI 版」では、アセッサーになるためにはアメリカに足を運んで1週間ほど滞在する必要も出てきます.ソフト会社という環境の中に居ては、この障害は越えられない可能性もあります.こう言った障害は、「日本版」ということで解決されることは望ましいことです.

 実際問題として、日本人の公認アセッサーは、今現在5人程度しかいません.そのほとんどは、メーカー系の人たちであり、外部の組織に対してのコンサルティング活動は限られているものと思われます.年度内に、もう少し公認されると思いますが、いずれも、メーカー系の人たちが中心になっているという現実は、資格をとる際の障害の高さを物語っています.

 ただし今のところ、彼らは「日本版」を求めてはいないと思います.「日本版」が世界に通用するかどうか分からない状態では、世界の市場を相手にしているメーカーにとって、メリットは無いはずです.CMMは、アジアの国々も取り組んでいます.そこでのCMMも「SEI版」です.そうなると、「日本版」が通用するのは日本国内に限られてしまうのでしょうか.もちろん、この辺りは、経済産業省の方で SEI と事前に協議し、「SEI 版に準拠する」ということで、ライセンスの共通化についての同意は取り付けていることと思います.でも、アセッサーの認定やアセスメントの認証が甘かったりすると、この同意は壊れてしまうでしょう.

 問題は、「日本版」が「SEI」と比べて遜色のないように運営できるかどうかです.それが実現すれば、「日本版CMM」も、いずれ世界において認知されるでしょうが、実態に乖離があるとなると、日本全体のソフトウェアの開発能力を疑われることになってしまいます.「日本版」は、それくらいの覚悟で臨んで欲しいと思います.


政府が特定の手法を推すことの問題 (2001/7/8)

 今回、経済産業省の「日本版CMM」への取り組み方を見ていると、「SLCP」という、当時の通産省が勧めていた「ソフトウェアを中心としたシステム開発および取引のための共通フレーム」という取り組みの反省があるように思われます.「SLCP」は、94年に初版が出て、98年に改訂版が出ていますが、正直言って、この取り組みは、ほとんど普及せず失敗だったと思われます.その失敗の反省として、強制力を持たなかったことや、認定という目標を設けなかったことなどを学習したものと思われます.

 この種の取り組みを普及させるという観点から云えば、そのような学習は間違っていないと思います.だからといって、政府レベルで「CMM」という、一つのプロセス改善手法を推すことには、疑問が残ります.実際に日本では、「SPICE」の普及に取り組んでいる組織もありますし、「ISO-9000」との関係も問題になってきます.「ISO」の枠の中に「CMM」のステップを取り込んだり、あるいは「UML」の表記法を使って表現したりして、独自にプロセスの改善を進めている人たちも居ます.それで、納期や品質などの約束が満たされているのであれば問題ないわけです.「プロセスの改善」としては成功しているわけです.しかしながら.今回の「日本版CMM」によって、これらの活動は否定されるかも知れません.少なくとも、そのままでは認証を得ることはできないでしょう.本来、実態が問題なのに、宗旨が問われることになり兼ねません.それが、本当に政府の取るべき行動かどうか、疑問が残ります.

 防衛庁の調達部門とか、ある省庁の中の特定の部署が、管理上の都合から「CMM」などの特定の基準を採用するというのであれば、別に問題はないでしょう.このとき、政府の役割は、各種のプロセス改善手法を育成し、その普及を支援することです.それらを一同に会して、それぞれの特徴を主張しあう場を設けたり、普及活動を税制で支援したり、現場で取り組む人たちを増やすために、ソフトウェア・エンジニアリングに関する教育カリキュラムを整備し、教育活動を活発にすることです.少なくとも、「2005年に世界最先端のIT国家を実現する」という政府の目標の一環として、特定の方法を推奨するという形は、将来において、自らの行動を制限することになる危険があります.

 「CMM」とて未来永劫のものではありません.10年後に、もっと優れたプロセス改善手法が出現するかもしれません.少なくとも、アメリカというところは、そういう国のはずです.IEEE Software の July/August 2000 では、「Process Diversity」という特集が組まれていました.すでに、CMM一辺倒では無くなっているのです.いろいろな場面に応じたプロセス改善手法が研究されているのです.

 今、「公的機関(政府又は政府に準じる機関)の設立」を行って、政府が一つの方法を推すと言う形になってしまうと、その先で方向転換が出来なくなる危険があります.「日本版CMM」のために設立した政府機関が、すんなりと宗旨替えができるかどうかです.多様なプロセス改善手法を、どうやって認めるのでしょうか.それが出来なければ、世界では、既に新しい方法が考案されているのに、日本では、依然として「日本版CMM」を推奨しているということになります.これでは民間の企業も、動きづらいことになるでしょう.

 本来、政府のソフトウェアを調達する側の立場としては、税金を使って調達する以上、その時の優れたものを選択出来る状態にあるべきです.一方、ソフトウェア産業を育成する側の立場としては、民間の研究機関がいろんな手法を研究することを支援し、普及しやすい環境を用意することです.政府が一つの手法を推すことで、プロセス改善手法の自由な競争が阻害される危険もあります.「CMM」以外はダメ、という風潮を作ることは、決して、日本にとって得策ではありません.

 元来、ソフト産業は「官」への依存体質が強く、その時々で、「官」と手を組みながらやって来ました.「日本版CMM」の構想が打ち出されたことで、「政府の推すものを追いかけておれば間違いない」などと言い出す経営者も出てくるでしょう.これは、ソフト会社としては、まさに自滅への道です.

 今回の「日本版CMM」の取り組みでは、このような状態になることを望んではいないと思いますが、政府が「一つのものを推薦する」となると、そのような方向に向かってしまう可能性は小さくはないでしょう.


ソフトウェア・エンジニアリング教育の問題 (2001/7/8)

 今、日本にとって最も急がなければならないことは、ソフトウェア・エンジニアリング全般の教育の充実です.データ構造やアーキテクチャの設計など、ソフトウェア・システムを設計し、プログラミングするのに必要な知識の習得を急がなければなりません.「プロフェッショナル」として立ち行くための教育が急がれます.設計技法や分析技法も、基礎的な知識については、教育機関の中で実施する必要があります.

 ただし、厳密な意味で、このような教育機関に「即戦力」を求めることは間違いです.ソフト会社の経営者は、ここを勘違いしないようにして欲しいです.現場と違って、教育機関でできることは、「正解のある問題」での解決方法の訓練です.もちろん、この世界では「正解」は一つとは限りませんし、むしろ「正解を創る」領域でもあります.とは云っても結果を採点し、評価しなければならない状況にあっては、「正解のない問題」あるいは「正解が分からない問題」を扱うことはできません.それでも、このような教育・訓練をしっかりと受けた人が現場にたくさんいることが大事で、ここから、正しい意味での「OJT」が始まります.

 特に、日本にとって重要な意味を持っている「組み込みシステム」の世界において、このような教育・訓練を受けた人が不足しており、これからのソフトウェアの開発に、間違いなく支障を来すはずです.高度化し複雑化する要求に応えることのできるソフトウェア・エンジニアが不足しています.その意味からも、今、すでにこの仕事に就いているソフトウェア・エンジニアにも、このような教育・訓練を受ける機会を与えて欲しいものです.

 この時、いつも問題になるのは、省庁間の縄張り争いです.つまり、いわゆる「学生」の教育と、一旦就職した人向けの「再教育」のカリキュラムに大きな差が生じることです.現状では、厚生労働省が扱うときは、離職者に対する再教育という扱いになるでしょうから、教育期間も限られてしまうでしょう.でも、コンピュータ・ソフトウェアの世界では、最低でも半年から1年の期間をかけての教育・訓練が必要になります.もちろん、厚生労働省の管轄でこれを実施すればいいのですが、現実には、文部科学省が、そのような長期の教育・訓練は自分たちの領域だと主張するでしょう.どっちも良いのです.どっちでも良いから、速やかに実施してくれれば良いのです.そして、この教育の条件として、合格点に達しなかった人は、絶対に修了させないことです.この教育は、受けたことに意味があるのではなく、理解し体得したことに意味があります.「修了」は、それを証明するものでなければなりません.

 そのためには、この種のカリキュラムの統合が必要です.その上で、教育の目的に合わせて、5段階ぐらいに分類する必要があるでしょう.一般教養として知識を習得することが目的のものと、これを職業にしようと考えている人たち向けのものとは区別されなければなりません.つまり、職業向けにはそれなりのレベルのカリキュラムでなければなりません.明確にされ統一されたカリキュラムの下で教育・訓練を受けることで、修了時のレベルが保証され、彼らを採用した企業・組織は、そのレベルを前提に、実務に当たってもらうことができます.こうした、現実的かつ厳しいカリキュラムが実施されることによって、はじめて日本のソフトウェア産業の将来が開かれると考えています.

 また、「PSP」という個人のプロセスを確立するための訓練プロラムも、職業向けのコンピュータ・サイエンスの教育プログラムと組み合わせる形で実施されることが望ましいです.「PSP」は、「CMM」を補完するように考えられていて、事前に「PSP」の訓練を受けた人たちにとっては、「CMM」は困難なものではなくなります.「日本版CMM」を推奨するのであれば、何処かで「PSP」の訓練環境を整える必要があります.でも、中間整理案では、そのようなことには全く触れられていません.

 ところで、このような教育・訓練は、何もプログラムを設計し、コードを書く人たちだけに必要なのではありません.この種の組織に於けるマネージャーのあり方についての教育・訓練も欠かせませんし、これがないと、結局は、今の状態から大きく変わることは出来ません.実際問題として、多くの組織では、このマネージャーの知識や技能の不足による不適切な行動が、チームや組織にとって障害になっていることも少なくありません.

 このような教育・訓練が、ある程度のレベルで実施されていれば、わざわざ「日本版」などと云わなくても、「SEI 版」で普及していたはずです.公認のアセッサーも、もっと生まれていたでしょうし、もっと多くの企業や組織に於ても、積極的に取り組んでいたでしょう.もちろん、そのような積極的な動きになるかどうかは、企業内での人事考課の影響を受けますが、技術者の方に力があれば、彼らの主張によってルールや基準も変わっていたでしょう.つまり、組織において、もっと「プロフェッショナル」が生まれやすい状況が出来ていたでしょう.ソフト会社によるコンサルティング業務が停滞している最大の理由は、「プロフェッショナル」が育っていないことです.

 今回の中間整理案では、現状の日本のソフト産業の抱える問題として、「ソフトウェア・エンジニアリングが根付いていない」ことが指摘されています.しかしながら、そこでは根付いていない原因について幾つか紹介されているだけで、これについてどう取り組むべきかという議論は見当たりません.つまり、このような根本問題を抱えている「現状」を認識していながら、いきなり「CMM」に取り組もうとしているわけですが、これは乱暴な話です.「ソフトウェア・エンジニアリングが根付いていない」状態では、あまりにもハードルが高すぎます.それでも突き進むとすれば、このハードルの高さは、どこかで恣意的に変えられてしまう危険を感じます.

 何事も、目指すところに到達するには順序、あるいはステップがうまく考えられていることが必要です.それを無視すると、目標に到達できないだけでなく、そこに向かうことの意義そのものも否定される危険があります.「SPICE」に対して、「CMM」は、まさに「順序」の効果を証明したわけです.中間整理案では、その「CMM」を、まるで順序を無視して取り組もうとしているように見えるのです.

 ソフトウェア・エンジニアリングの教育も含めて、ソフトウェア産業の明日の姿を描き、目指すべく所に向かうための基盤の整備に取り組んで欲しいと思っています.もしかすると「単年度予算」という仕組みの中では、そのような時間のかかる取り組みが出来ないのでしょうか.もし、そうであるなら、「e-japan計画」は、何の上に書いた計画なのでしょう.