●CMMI の日本語版（pdf）は「米国SEIのホームページ」からダウンロードできます。日本のSECのホームページからも、同じところにリンクするようになっています。（2006/1/6）
CMMと比べてボリュームは大きくなっていますが、内容は事例もあって読みやすくなっています。
●CMM v1.1 の日本語版(pdf)がいよいよ無料公開されました！ →こちら (1999/5/19)
SEA の方で翻訳作業が進められていたものですが、ようやく公開されました。
●「日本版ＣＭＭ」について （2001/12/30 改訂）
2001年12月26日に、「日本版ＣＭＭ」に関する中間まとめ（案）が公表されました。今回は、経済産業省の案内のホームページから「日本版ＣＭＭ」という表現は消えています。おそらく、先のパブリックコメントで各方面から、厳しいコメントが寄せられたものと思われます。今回の中間まとめ（案）に対する、私の見解を整理しておきましたので、参考にしてください。（2001/12/29追加）
●「プロセス改善の勘所」をオープンします。(2006/1/1)
９０年代にCMMが公開されて、問題の解決をプロセスに求める動きの中で「プロセスの改善」が叫ばれてきましたが、あれから１０年が過ぎました。果して、プロセス改善の効果は浸透したのでしょうか。CMMも本当に望ましい状態で取り入れられているのでしょうか。CMMの方はレベル３と認められたものの、QCDの方は一向に改善しないという組織も少なくないと思われます。NASAや国防総省とちがって、プロセス改善の取り組みが、なんらかの形でQCDに効果を表さなければ、現場に工数的に皺寄せがいってしまい、継続して取り組むことは難しくなります。
なぜプロセス改善はうまくいかないのか。そこにはプロセスの改善に対する誤解や勘違いがあります。また取り組み方も間違ったものが少なくありません。ここでは、１０年間プロセス改善のコンサルティングをやって来た中で、プロセス改善の考え方や注意するポイントなどを紹介しますので、皆さんの参考にしてください。
●ＰＦＤ（Process Flow Diagram）の書き方 (pdf形式)を大幅に改訂しました。（2009/8/15）更新
「ＰＦＤ」は、私が構造化分析手法のＤＦＤをヒントにして、成果物とプロセスの連鎖を表現するために７０年代後半ら使っていたものです（ＰＦＤという呼称は、ＤＦＤをもじって私が勝手に呼んでいるものです）。コンサルティングの中では、混乱の状況を立て直す際に、「要求の仕様化」と一緒に、最初に取り組んでもらう重要なテーマであり、混乱を静める有力な方法として確実に実績を上げているものす。２年ほど前から、外部の講演の資料でＰＦＤのサンプルを公開したり、今年出版した本や雑誌の中でも、ＰＦＤのサンプルを掲載していますので、多くの方が目にするようになったかも知れません。また最近は、私のコンサルティング先のソフトウェア企業を通じても、外に出始めているようです。
ＰＦＤによるプロセスの表現は、プロセス改善のツールとしてはもちろんですが、見積りやスケジューリング、進捗管理のツールとしても強力な効果を発揮しますので、多くの人に使っていただければ良いと思っています。私としても、どこかの時点で、ＰＦＤの書き方やその活用方法などを“活字”にする必要を感じていましたが、その時期よりも広がりのペースの方が早くなりそうです。折角の方法（ツール）ですので、勝手な表現が広まってしまえば「言語」としての意味がなくなってしまいます。そこでとりあえず、私がコンサルティングの中で勧めているＰＦＤの「表記上のルール」だけでも先に公開することにします。別に、ここで公表する表記法で強要する意図はありません。あくまでも参考にしていただくためのものです。
ーーーーー以下、2009年8月15日追加ーーーーー
これまでコンサルティングの中でもＰＦＤは必須のツールとして奨めてきました。ただし適当なツールはありませんでしいたので「Excel」で進めてきました。私の方でツールを作ることができなかったのが最大の理由です。「Excel」はもともとＰＦＤを書くためのツールではありませんので、ＰＦＤ書く人もルールを勝手に崩したりすることも多かったのですが、今回、スパークスシステムズジャパンの河野さんの方で「EA (Enterprise Architect)」のアドインツールとして作ってくれました。というよりも、以前からアドインツールとして作られていたのですが、ＰＦＤの書き方に関する本も出していませんでしたので、このホームページに掲載していた「第２版」を参考にされていたため、内容的には十分ではありませんでした。
今回、スパークスシステムズジャパンの河野さんと連携する機会を得たことで、私の方で「ＰＦＤの書き方」（第３版）を大幅に改訂し、ツールとしての価値を持つように内容を充実しました。そして河野さんの方でこの「第３版」の容を実現するようにアドインツールを改良していただきました。河野さんの方からアドインツールがリリースされるのに合わせて、「ＰＦＤの書き方」（第３版）を公開します。
いずれ、ＰＦＤの価値や現状のプロセス改善が進まない理由、CMMIの取り組みが形骸化する理由等と一緒に、ＰＦＤの書き方やいろいろな場面での対応方法などについて詳しくお伝えする機会があると思っています。今その作業に取りかかっていますが、もう少し時間がかかりそうですので、皆さんには申し訳ありませんが、それまでは「第３版」をお使いいただくようにおねがいします。
なお、この場をお借りして、スパークスシステムズジャパンの河野さんには厚くお礼申し上げます。 （2009年8月15日）
ーーーーー
なお、申し訳ありませんが、この件に関連して書き方の質問などのお問い合わせにはお答えしかねますので、ご理解願います。
◆これまでの「標準化」の間違い （2003/1/8）（2003/3/22 追記）
多くの現場では、間違った「標準化」の取り組みをしてきました。「標準」を「銀の弾丸」してしまったり、万能の「標準」を作ってしまったりしてきました。そして、多くの現場で失敗してきたのですが、その反省もないまま、今また「ＣＭＭ」に取り組もうとしています。過去に「標準化」で失敗してきた組織では、今度こそという思いを「ＣＭＭ」に託しているようですが、そのことは再び「銀の弾丸」を求める行動へと導いてしまう危険があります。過去の「標準化」の取り組みが何故失敗したか。「ＣＭＭ」とはどこが違うのかということを簡単にまとめてみました。
「出来合いの標準」のもたらす弊害について追記しました。（2003/3/22）
◆ＣＭＭは非人間的か （2001/6/4）
「ＸＰ」の出現によって、ＣＭＭなどのこれまでのプロセス改善の取り組みは、人間を無視したやり方ということで攻撃されています．また、「ＸＰ」自身も、最近になってマスコミを扱うようになって広がりを見せています．でも、私の目には、まるで「ＸＰ」が銀の弾丸であるかのような扱われかたで、却って危うさを感じてしまいます．ここでは、ＣＭＭが非人間的と言われる所以を解き明かします．
◆間違ったＣＭＭへの取り組み （更新：01/2/17）
「日本版ＣＭＭ」の動きに触発されるかのように、ＣＭＭへの関心が高まっているようですが、その分、取り組み方にも問題が目立ってきています。トップの協力は必要ですが、トップダウンだけで出来るものではありません。開発組織に適切な人材が居ることが必要です。それよりも、外形に囚われ、「ＩＳＯ」と同じように、認証に走りすぎる危険を感じています。
◆リワークが起きるもう一つの原因 (更新：00/12/29）
“リワーク”には、やり直し作業のようによく知られているパターンの他に、ほとんど気づかれていないパターンがあります。気づいたときに形にするタイミングを逸したことで、その後、形にする機会を失ってしまうパターンです。これらは、後になっては“思い出す”という作業を強いられるため、非常な苦痛を伴います。そのため、結局は形にすることが省かれ、大きな混乱を招くのです。
◆品質保証と品質管理 (更新：00/8/17）
品質保証と品質管理の違いを理解しないままでは、プロセス改善の取り組みはうまく行きません。焦らずに、品質保証の仕組みを作り上げることが先決です。これを省いては、品質管理は安定しませんし、殆ど実現しません。ソフトウェアの世界に限らず、現実に品質管理が破綻している背景には、品質保証の体制が整備されていないことが原因と思われます。ＣＭＭにおいて、それぞれの取り組みがレベル２とレベル４に分かれていることを理解する必要があります。
◆ハンフリー博士の講演について(更新：00/6/28）
６月１６日の、早稲田の大隈講堂で催されたＷ．ハンフリー博士の講演が行われました。講演の後で会場からの質問が受け付けられましたが、その最後の質問者とのやり取りが曖昧な状態で終わっていると判断しましたので、私の経験に基づいて（勝手に）フォローしてみました。 （ハンフリー博士に確認したものではなく、全く私の独断的解釈によるものであることを、最初にお断りしておきます。）
◆何が変わったか？(更新：00/4/29） ［PDF で提供します］
プロセスの改善は、体に染みついた習慣を変えることでもあります。折角、良いところまで出来ていたのに、ちょっとした不用意な行動で簡単に元の習慣に戻ってしまいます。また、ある種の姿勢のままでは、変化そのものが妨げられてしまいます。どのような時に戻ってしまうのか、また、変化できない姿勢とはどいういうものか。幾つか紹介しますので、参考にしてください。
◆FAQ for CMM (更新：99/1/2）
これまで電子メールやコンサルティングの場で寄せられたＣＭＭに関する質問事項の中から、多くの方たちに共通するものを集めましたので、参考にしていただければと思います。
◆デスマーチとＣＭＭ (更新：1999/2/14）
“デスマーチ”の原因と、そこから抜け出すための取り組み、あるいはデスマーチに陥らないための注意点について、簡単にまとめてみました。
◆ＣＭＭの取り組みのポイント (98/3/1）
レベル１の組織がＣＭＭに取り組む際の難しさは何処にあるか？ また、それをクリアする方法はあるのか？
◆Good EnoughとＣＭＭ (97/11/16）
“十分よいソフトウェア”について、主にＣＭＭの観点から考えてみました。このテーマは、少し厄介な問題を含んでいますので、慎重に読み進んで頂きたいと思います。
― 注意 ―
「ＣＭＭ」はＳＥＩ（Software Engineering Institute）の登録商標です。
ここでは、ＣＭＭの V1.1 を私の方で解釈し、実際の（レベル１の）開発現場でどのように適用すればよいか、あるいは、導入の困難な Key Process に対してどのような対処の方法があるかといったところについて、長年研究を重ねてきた結果（の一部）を紹介するものです。したがって、ここではＣＭＭの解釈の部分と、実際の現場での応用の部分が混じっています。
本格的に取り組もうと考えておられる読者の方は、できるだけ原書（原典）を辿って頂きたいと思います。
◆間違った「標準化」の取り組み（2003/1/8の時点で削除しました）
◆ＣＭＭの提案と取り組みの順序(3/18/97)
◆プロセスレベルの改善に取り組む
◆要求管理
◆品質保証
◆レベル２からレベル３への具体的取り組み
◆レベル３からレベル４への取り組み
◆レベル４からレベル５への取り組み
◆プロセス・レベルと人間性(3/18/97)
◆ＣＭＭとリスク管理 (1/1/98)
◆詳細スケジュールの作成と管理の方法(2/13/97)
◆要求仕様書について（再更新：1999/8/5）
2005年10月に、「要求を仕様化する技術・表現する技術」として技術評論社から出版しました。内容はそちらに詳しくまとめましたので、本の方を参考にしてください。
◆派生モデル開発 (6/29/97)
― 派生モデルの開発には、新規開発の方法とは違った工夫が必要！
2006年3月の「Software People」vol.8 にもう少し詳しく紹介します。
◆
◆