「日本版ＣＭＭ」の動きが表面化して、ソフト会社にも「ＣＭＭ」への取り組みの動きが見えてきました。これまでは、ＣＭＭへの取り組みは、どちらかというと、メーカーのソフト開発組織を中心に取り組まれてきたように思います。そのような組織では、電子回路の技術者が転向してソフトの開発に回っている事が多く、一般にソフトウェア・エンジニアリング全般の知識を持った人が少ないことなどから、早い時期に開発自体が混乱の様子を見せていたことや、製品の発売時期などの制限が「ＩＴ」系のソフト開発よりも厳しいこと、その他に、既にＱＣ活動などの文化を持っていたことも作用しているものと思われます。
組み込み系のソフト会社の中には、関係先のメーカーからの指導や要請もあって、早くから取り組んできたところもあるようですが、多くのソフト会社は、昨年末に産業省（当時の通産省）が揚げた「日本版ＣＭＭ」の旗を見て、ようやく行動を開始したのではないでしょうか。これまでは、ソフト会社の中には、既にＣＭＭというものの存在を知っている人がいても、組織としての行動には繋がらなかったかも知れませんが、産業省が旗を振った事で、お決まりの「遅れてはならず」エンジンが始動したものと思われます。
メーカー系の組織だけでなく、一部のソフト会社でも、少し前から自主的に社内での体制を整備して取り組み始めているところがあります。しかしながら、その取り組み方に幾つかの問題も見えます。そこで、これから取り組もうとしている組織の人たちに注意を促す意味で、何が問題なのか、どこがおかしいのかと言うことについて、以下に少しまとめてみましたの参考にしてください。
なお、私自身はＳＥＩの公認のリードアセッサーではありません。あくまでも、私自身のこれまでのコンサルティングの経験に基づいて、また、私自身が考える取り組み方として紹介し、説明するものです。
ＣＭＭでは、レベル２から５への４つの段階に分けてＫＰＡが示されていますが、レベル２でのＫＰＡは、レベル２で完成するのではありません。実際には、レベル３へと引き継がれて完成に近づいていきます。そして、いわゆる“完成”のレベルに導くためにレベル４のＫＰＡを作用させるわけです。
たとえば、レベル２のＫＰＡでも、関係者が文書をスムースに書けるように、適切なトレーニングやオリエンテーションの実施が求められていますが、これは、レベル３のＫＰＡ（「組織プロセス重視」「組織プロセス定義」「トレーニングプログラム」など）の支援を受けて、より完成の域に近づくことになります。逆に、レベル３で求められている「トレーニングプログラム」は、レベル２に於ても、部分的に実施する仕組みが必要です。ただし、レベル１の状態の組織では、本格的にトレーニングプログラムを用意し実施するだけのリソースを確保できないため、それはある程度は約束出来る状態になったレベル２（Repeatableの状態）から、体制を整えて本格的に取り組めばよいということです。多くのレベル１の組織にあって、すぐに「ＳＥＰＧ」として活動できる人材を確保することは、殆ど不可能に近いものと思われます。
レベル３のＫＰＡになっている「組織プロセス定義」も、実際には、レベル２のＫＰＡに取り組む中で、プロセスを定義することが求められています。この場合は、基本的に、開発組織（チーム）自体で定義することで足りるのですが、チームの中の誰かがサンプルを作って、それに習う形で取り組むような仕掛けが用意されていないと、現場に持ち込むのは難しくなります。そして、プロセスの定義を本格的に組織全体に展開したり、「標準」の用意やテーラリングの指導などに踏み込もうとすると、専門の組織（ＳＥＰＧ）が必要になります。
「ピアレビュー」も同じことが言えます。レベル２への取り組みの中でも、「レビュー」は頻繁に求められますし、実際に、ＣＭＭの「活動」などにも多く書かれています。しかしながら、そのような組織では、人材的にも時間的にも「ピアレビュー」を実施できる状態ではありせん。したがって、そのような組織では、「ピアレビュー」とまでは行かなくても、時間のかからない効率的な（ただし、効果は限定的かもしれませんが）レビュー方法を考えて実施していかなければなりません。それは、組織の状況に応じて考え出されることになります。逆に、そのようなステップを踏んでいくことで、本来の「ピアレビュー」が可能となります。
このように、ＣＭＭのレベル２と３の合計１３のＫＰＡは、あくまでも“連続”であり、優先度の観点から別けられているに過ぎないのです。
ＣＭＭを読んでいると、レベル２のＫＰＡで要求仕様に含まれる要素が紹介されていたり、計画書の構成が示されていたり、作業の手順書の作成が要求されていたり、といったように、いわゆる「標準プロセス」を用意することを促しています。そのため、ＣＭＭへの取り組みを、そのまま「標準プロセスの確立」への道と捉えて、最初に、テンプレートや手順書の準備に取り掛かってしまうようです。
しかしながら、ここで良く考えて欲しいのです。それって、昔に取り組んだ「標準化」とかいって書式集を作ったりしたことと同じではありませんか？ あの時、関係する文献を参考にして標準の作業の流れや書式を決めたわけですが、それって、実際の作業の中で使われたでしょうか？
いえいえ、そのような「標準」が思惑通りに使われてきたのなら、ソフトウェア開発の混乱は今のようには起きていないでしょう。もちろん、そのような書式に従って作業が進められているからといって、バグが殆ど発生しないとは限りませんが、適切なプロセスに沿って作業が進められているのなら、ある程度のバグの発生は押さえられている可能性があります。
このことは何を意味するかというと、「ＣＭＭ」という看板にすり替わってはいるものの、そこで行われていることは、昔うまく行かなかった時の取り組みと殆ど変わっていないと言うことです。果たして、ＣＭＭの本を何度読んだでしょうか。レベル２だけとしても、一体どれだけ読み込んだでしょうか。読むだけでなく、そこに書かれている要点を抽出したりして、形を変えるような行為をしたでしょうか。実は、「ISO-9000」に対する取り組みも、これと同じことが起きてしまっていると見ています。
ＣＭＭやＩＳＯの参考書を片手に、みんなで壁を作り、部屋を区切って、２階に昇る階段を作って、窓はきれいな飾りで縁取り、壁には小さな絵をぶら下げ、そうして３階、４階と階段を取り付け、部屋を作っていく。最後にエンジ色の屋根を作って、さぁ完成したと足場を外して、外から並んで見上げてみたものの、いったいどうやってこの家に入るのか分からない。何かを忘れているのです。でもそれが何か分からない。参考書には書いていません（正確には読み取れない）。お互いにバツの悪い雰囲気で、結局は、丘の下の雨漏りのする（住み慣れた）家に住み続けているのです。お菓子の家ではなく“おかしな家”を建ててしまったのです。
なぜ、そのような事が起きるかというと、ＣＭＭという新しい文献を読んでも、それを解釈する「辞書」は、昔のままだからです。以前と同じ辞書でＣＭＭを読めば、やはり、テンプレートを作りなさい、手順書を用意しなさい、と書いてある部分しか目に留まらないはずです。人は、文献を読むとき、また人の話を聞くとき、そこで行われる「解釈」という行為には、その人が身に付いている「辞書」が使われます。そして普段の行動も、その「辞書」から発しているのです。
実際に、ＣＭＭを知らなくても納期を遅らさずに上手く出来る（た）人が読めば、テンプレートや手順書を用意しなさいということの他に、その組織の状態に合わせて、ステップを刻めばいいと読めるのです。そうでなければ、組織のレベルを５段階に定義する必要もないし、ＣＭＭとして４段階のステップを提示する必要はないのです。組織にとって、出来なければならないことを全部羅列すればいいわけです。それをせずに、自らの段階（状態）に応じてテーマを絞って取り組むことを勧めているのがＣＭＭであり、そこにＣＭＭの真価があるのです。
４段階の取り組みのステップも、あくまでも便宜的に分類しただけで、現実には、そこに居る人たちのスキルや組織の状態によって、もっと細かな取り組みの刻みがあっても良いのです。ただし、ＣＭＭというモデルに、そこまで細かくは表現できません。プロセスの手順書だって、最初はメモ程度のものでも構いません。大事なことは、工程（プロセス）の最後までイメージすることです。たとえ、一つひとつのプロセスを“しっかり”定義したところで、お互いのプロセスの連携が曖昧では意味はありません。理想的なことを書いても、それが実行できなければ、作業は繋がらないのです。
要求仕様書ひとつとっても、書式を定義したからといって、みんなが簡単に書ける訳ではありません。そのテンプレートを作った人も、資料を見ながら、“こういう内容のことを書くべきだ”というスタンスで書いただけなら、その人自身も上手く書けない可能性があるのです。ましてや、その他の人が上手く書ける可能性はもっと低いわけです。だからこそ「オリエンテーション」や「トレーニング」が必要なのです。テンプレートや、標準の手順書などは、それを実際に使いこなせる人がいない状態では、機能しないのです。いったい誰が、チームの人たちを指導するのですか。いったい誰が、メンバーの質問に答え、適切な方向に導くのですか。
また、要求仕様書のスタイルも、１種類にする必要はありません。そこで採用するソフトウェアエンジニアリングによっても違ってきます。たとえばＵＭＬを使って開発するのなら、おそらく「UseCase」を使うことになるでしょう。ただし、その中に書かれる「シナリオ」の構成には工夫が必要です。あるいはその前に、「要求」だけは、いったん文章形式で書いてもかまいません。その方が、「UseCase」をイメージしやすいのならそれでも良いはずですし、品質的要求はそれぞれの「UseCase」の中に書いても、最後まで文章形式で書いても構わないでしょう。また、扱う製品によっても要求仕様の形式や構成は変わってくるでしょう。
ガチガチに書式（標準）を固めることは、ＣＭＭの真意に沿わないというのが、私の考えです。特に、ＳＥＰＧの組織を作れない状態にあっては、「標準」を焦ることは危険です。その前に、そこにいる人たちが、稚拙ながらも自分たちのためのテンプレートを定義し、自分たちの作業を定義して、実際に今までと比べて納期がある程度の範囲に収まったり、バグが１／１０程度に減少した体験をすべきです。そこで初めて、ＣＭＭで求められている（勧めている？）テーラリングが可能となるのです。もちろん、その程度では十分ではありませんが、今回進めてきた手順などを参考に、次も上手くやる方法（テーラリング）が考えられるのです。そうして、そういう人たちを中心にＳＥＰＧの組織を作っていけばいいのです。
このように、ＣＭＭのレベル２で書かれているように、最初からテンプレートや手順書を用意しても、それだけでは実行することはほとんど困難です。先にも触れたように、そうしてテンプレートをまとめただけで、魔法にかかったように適切な文書が書けたり、今まで混乱していた作業ステップが整然と進められることはありません。それは、ちょっと考えただけでも分かることです。
開発プロセスの問題は、「習慣」にあります。そのような混乱した作業パターンが身に付いていることにあります。仕様を書くように勧めても、「ソースなら浮かぶのだけど」という人は少なくありません。本当は、問題なくすらすらとソースが書ける人は少なく、殆どの人は、何度も書き直したりして、それでも最後になって要求を外していることがばれて、また手直しするのですが、少なくとも、“その時”は、ソースなら浮かぶと思うわけです。これは、「仕様なんて書けないや」というフレーズを頭に浮かべた途端に出てくる行動（反応）です。
このような行動パターン（習慣）を身に付けてしまっていることが、今日の市場の要請に応えられなくなっている主要な原因の一つなのです。したがって、テンプレートや手順書が、今度は今までと違って「ＣＭＭ」という新しい考えに基づいて書かれたとしても、それだけで、このような行動パターンが一変するはずがないのです。でも、多くの現場では、相変わらず、「標準」に希望を託しているのです。
この問題を解く鍵に、「ＰＳＰ」というものがあります。既に翻訳本も出ているので、ご存知の方も居るとおもいますが、これは、ハンフリー氏が、ＣＭＭに続いて取り組んだもので、ＣＭＭが組織において実現するには、そこにいるエンジニア一人ひとりが、仕様を書くスキルや、見積もるスキル、結果を記録する習慣などを身に付けていることが必要である、という考えに基づいています。実際、アメリカの幾つかの大学では、すでに授業の中に、このＰＳＰが取り込まれています。最初から、プロセスを表現するスキルやＣＭＭに取り組めるスキルを身に付けた状態で社会に送りだそうと言うのです。
このことからも、これまでの「改善」の取り組みや「標準化」の取り組みがうまく行かなかった理由がわかるというものです。そうです。ＣＭＭということで、いきなりそこに書かれていることに取り組もうとしても、身動きが取れないのは、その壁を登る方法（スキル）を持っていないからなのです。「お菓子の家」を建てても、そこに入る方法を持っていないのです。いや、それを持っていないから、現実の開発作業に於ても混乱しているのです。その状態に対して、なんら適切なアクションが取られることがない状態で、いきなりＣＭＭに取り組もうとしても無理な話なのです。
簡単に言ってしまえば、皆さんも、ＣＭＭに取り組む前に、ＰＳＰのトレーニングを受けて、これまで不用意に身に付けしまった良くない習慣を追い出してしまえばいいのですが、現実問題として、このページの読者の殆どは、学生ではないでしょうから、悠長にＰＳＰのトレーニングを受ける事は困難かもしれません。では、どうするかというと、一つの方法は、ＣＭＭの取り組みを小さく刻んで、「手が届く」程の取り組みに分解することです。そうすることによって、開発プロジェクトの中で、小さなトレーニングも可能になります。計画書も一気にすべての項目を満たさなくても、自分たちの現場にとって書けそうなことから、そして効果がありそうなところから取り組めばいいのです。まずは、「一歩」を進めることであり、元に戻らないことが大事なのです。選んだ計画書の項目によっては、そのプロジェクトの大きな課題というものが明確になることもあり、それによって、早い段階で対応策を考えられることもあるのです。「リスク管理」とまで行かなくても、混乱の要因を少しでも減らすことができるのです。
要求仕様も、いままで途中の仕様の変更が多くて混乱しているというのであれば、先ずは、機能だけでも良いから、項目を大きく分類し、それにしたがって仕様を箇条書き（番号付きで）にするだけでも取り掛かることです。そうすれば、仕様モレや仕様間の矛盾についてレビュー出来ることに気付くでしょう。そして、設計作業がスムースに進んでいることに気付くでしょうし、途中での仕様の変更が、実はそれほど多くないことにも気付くでしょう。
ＰＳＰの各章で、どのようなテーマが扱われているかを調べ、それをどのようにして習得させようとしているのかを調べてみてください。そうすることによって、ＰＳＰでのトレーニングのテーマが、実際のＣＭＭの取り組みのどのＫＰＡに有効なのかも見えてくるでしょう。もちろん、それは実際の開発局面にも当てはまるものです。成果物のサイズ見積りも、具体的にどういう方法があるかＰＳＰに書かれています。それを現実の作業の中に取り込むのです。
もちろん、それだけを取り入れることはできません。ある程度、要求仕様が細かく書かれている状態とか、プロセスの出力としての成果物が明確になっている状態であれば、次の段階としてのサイズ見積りは可能になります。ＰＳＰの各章がステップ・バイ・ステップで取り組むことを想定して書かれているように、実際の作業に於ても、ステップ・バイ・ステップで進めていけば良いのです。
くれぐれも、「ＩＳＯ」で犯した過ちを繰り返さないようにしてください。