「清水さん、これまでいろんな本を読んだりして、“いいところを”取り入れようとやってみるのですが、気がついてみるとスタートラインに戻っているんです」とか，「これじゃいけないと、３年前に標準化に取り組んだ時もそうでした」「去年、レビュー技法に取り組んだときも、やっぱりいつの間にか元のままでした」−この仕事をしていてよく聞かされる言葉です。
そうして、少し間が開いて「プロセス改善って、理想なんでしょうかね」という言葉がため息に混じって続いてきます。確かに、一つの理想郷だることは確かですが、それは実現できない理想ではなく、実際に今も着々と実現している組織があるような理想郷なのです。やり方を間違えているだけなのです。
この国は、ソフトウェアの開発に関して、あまりにも野放しすぎました。組織によっては、９０％以上の人が、そのようなプロセス改善なんて出来っこないと思っているようです。だから管理職（マネージャーとは言わない）も、そんなことを考えている暇があれば、１分でも早く（コードを書く）作業を続けろというわけです。その結果、気づいたときには、市場の要求が膨らんで、手に負える状態ではなくなっているのです。結局、これが「デスマーチ」の理由の一つなのです。
「プロセスの改善」などのように、ソフトウェアの開発工程に関る改善活動は、そこに関っている人たちの意識を変える事であり、習慣を変える事でもあります。習慣というのは、最初に、顧客から出てきた開発依頼を受けて取り掛かる行動や、ちょっと内容が見えてきたと思ったら、何らの設計書も書かないで画面に向かってソースを打ち込んでいく行為、メンバーの一人が書き上げた設計書が回ってきた時、ちらっと表紙と厚みを見て〔何も考えずに）机の端に積み上げる行為なども指しています。また、〔明確な設計工程を置かずに）実装中に仕様の不備に気づいても、次の瞬間“デバッグしながら直していけばいいや”という言葉がいつものように脳裏をよぎるのも、実は習慣の為せる技です。
その他，遅れながらもプロジェクトが終わったとき、１冊のバインダに綴じられたバグの報告書を前にして、今回も、そこから何も学習しようとしないのも習慣の問題です。
プロセスの改善というのは、このように作業をうまく運ぶことに繋がらない「習慣」を変えることを意味しています。ただ、いろいろな判断や決定が、変わりきっていない以前の習慣の体系の中から行われるため、なかなか変化しないわけです。以前の習慣へのアクセスが１回でもあれば、その分、生き残る理由になってしまいます。
そのような現状を何とか変えたいと思うから、「サバイバルガイド」や「ソフトウェアプロセス成熟度の改善」や「・・ＣＭＭによるガイドライン」や「構造化ウォークスルー」などの本を買って、そこから何か自分たちの現状を変えてくれそうな方法を手に入れようとするわけです。それらの文献は、総じて間違ったことは書いていません。もっとも、それらの殆どは翻訳本ですので、人によっては、“外国でうまく行っている方法でも、日本で通用するとは限らない”と、最初から決めてかかっている人もいますが、このような姿勢では何も手に入らないでしょう。たぶん，この人も，かって同じように取り掛かったものの、気づいたときにはスタートラインに居た、という経験があるのでしょう。
文献というのは、読み手とは違った文化を持った人が書いていますので、簡単には、その真意を理解することはできません。このホームページの「分かる」のページにも書きましたが、「個体」が違うということはとても厄介なことです。読み手が“分かった”と思ったことは、読み手の知識や経験の中で判断できる範囲に限られます。しかも、その読み手が効率良く作業が出来ていないのですから，書き手の考えの半分も理解できない可能性があるのです。
書き手としても、サンプルを紹介するなどして、少しはこの食い違いを少なくすることは出来ても、根本的な解決にはなりません。つまり、読み手が“なるほど、こうすればいいのか”と理解したつもりで、早速に取り掛かったとしても、うまく行かない可能性は依然として残ってしまうのです。先の“達観”した人は，たぶん此処で断念したものと思われます。
チームや組織の前提も違うし、仕事の価値観も違うでしょう。論理的な思考に慣れているかどうかの問題も小さくはありません。そのような部分に関係する内容は、１度読んだ程度では分からないでしょう。だから失敗するのです。いや“失敗”とまでは言わないとしても、うまく行かないのです。そして、多くの人はそこで止めてしまうのです。
言うまでもなく，このような状況は，翻訳本に限ったことではありません。ソフトウェア・エンジニアリングの関する優れた文献が，翻訳本に多いというだけでしょう。
なぜ、その文献を何度も読もうとしないのでしょう。最初に読んだときは見落とした文章も、改めて読んでみたときには目に付くものです。一度実行してみたことで、すでに前回読んだときとは「読者の状態」が変わっているのです。著者の文化や思考の一部が取り込まれている状態でもう一度読むことで、新たな発見があるのです。
２年ほど前に、ヨードンの「構造化ウォークスルー」という本（ＣＭＭで言うところのピアレビューの原点）を読んで、取り組んだ経験のある人と話をする機会がありました。その本の中に、「少なくとも一つの肯定意見」を述べることを求めていますが、その人は、この文章に気づいていませんでした。欠陥や否定意見を出すことによってレビューの場が気まずくなってしまったとき、もう一度この本に戻るべきだったのです。でも、その人は、この本に戻って判断することをしないで、その時点での「自分」の中にある知識や経験に基づいて判断しようとしたため、デベートの文化を持たないこの国では無理だと判断してしまったのです。本当は、ディベート文化の問題ではなく「人の心理」の問題なのです。
また、文献を先入観で読んでしまっていることもあります。同じ文献で、ウォークスルーを実施するときは、対象となる成果物の１段階前の成果物と比べる形で行うことが書かれています。分かりやすく言えば、コード・ウォークスルーは、ソースコードだけで実施するのではなく、その前提となった設計書（の類）と見比べて、設計書の通りに実装されていないことを指摘〔確認）する行為であることが書かれていますが、このことも、殆ど知られていません。たぶん、「レビュー」に関する先入観があって、その上で文献を読んでいるものと思われます。
結局，成果物が、適切な作業を挟んで変化していく状況にあることで、はじめてヨードンのいうウォークスルー（ＣＭＭでいうピアレビュー）が実施出来るのです。
こうしたことは、１度読んだぐらいではなかなか気がつかないものです。「構造化ウォークスルー」を読んだことのある人は、この機会にもう一度読んでみてください。もっとも、「構造化・・」というタイトルの文字も、先入観を誘発しているかも知れませんが。
文献から新しい考え方や方法を取り入れようというとき、それが新しいものであるが故に、読者の知識や経験では判断しきれないものが多く存在することを認識する必要があります。読者の求める（べき）ものは，本当はそれ（まだ認識できていないもの）であって，その時点で既に認識できているものではないはずです。にも変わらず，それを手に入れるような読み方をしていません。
先の例で、ウォークスルーの場が険悪な雰囲気になってしまったとき、もう一度文献に戻って、そこに答えを求めるべきだったのです。ドキュメントの欠陥がうまく指摘されないため、ウォークスルーの意義が問題になったときも、元の文献に戻って判断すべきだったのです。
プロジェクト管理も、本に書いてあることをやってみても、そこで出来ることは読み手が解釈し理解し得た範囲に限られてしまうわけです。その上、どうしたらいいか迷ったときに、その本の内容を理解していない本人の知識の範囲で行った判断は、当然、その本の著者の判断とは大きく異なる可能性があるわけです。
ＣＭＭの解説本も、サバイバルガイドも、同じことが起きるのです。
もちろん、すべての文献にそのような答えが書かれている保証はありません。でもそれは、文献の「範囲」の問題である可能性が高いものです。たとえば「構造化ウォークスルー」では、どうやって成果物と作業を連携させるかということには触れていません。それはその本の範囲を越えているからです。
評価の高い文献というのは、総じてその期待を裏切ることはありません。それは私自身の経験でもあります。
このことは、文献の“つまみ食い”はもっと難しいことを意味します。そこに書いてあることの中から、自分たちの組織に“使えそうな”取り組みを探して、それとそれまでの自分たちの組織のやり方の“いいところ”を融合しようと言うわけですが、言葉ではうまく行くように聞こえますが，この“融合”の判断が、“どこ”で為されているかが問題です。
その時点で、かなりうまくやることの出来る（ＣＭＭでいうところのレベル３以上の）組織や人であれば、それも可能かも知れませんが、レベル１の組織の人が、融合の前提となる“使えそう”あるいは“いいところ”の判断が出来るかどうか危ういです。おそらくその判断は、文献によるのではなく、その時点での“うまく出来ていない”自分の知識と経験に基づいて行われるものと思われます。
またプロセスが、１部分だけうまく行っていないという状況は、どちらかというと稀なのです。いつ終わるかやってみなければ分からないという開発組織が、要求仕様書だけは誰にも負けないものを書いているということは殆どありません。逆に、要求仕様をまとめる工程を放置したまま、構成管理に取り組もうとしても、仕様が安定せず、それにまつわるプログラムのバグも次々と発生し、とても変更制御など出来る状態にはなりません。また、プロセスを明確にすることを放置したままでは、成果物が「流れ」を持ちませんので、効果的なレビュ（ピアレビュー）は実現せず、レビュー漏れなどのバグは消えることはありません。
つまり、プロセスの改善というのは、ある程度の「セット」で取り組まなければならないということで，組み合わせをよく考えないままの“つまみ食い”は，多くの場合，机上の空論で終わる可能性があるのです。
その組織が、何らかの方法でソフトウェアを開発しているということは、そこにはプロセスが存在している事を意味しています。組織に存在しているプロセス、すなわち慣習的に行われている作業の流れ（それは決して合理的なものではないが）の中で、そこにいる人たちは、各自（分担＝役割として）のプロセスを身に付けているのです。その証拠に、次回も、同じような手順や判断で作業を進めるでしょう。したがって、〔新しい）プロセスが身に付かないというのは、既にプロセスを身に付けてしまっていて、それを変えることが出来ない状態なのです。
こうしたソフトウェアの開発作業のプロセスを変えるためには、日常のプロセスも変えなければなりません。つまり、文献に接する時のプロセスは言うまでもなく、時には、職場に入って最初にする行為〔習慣）も変えなければなりません。今までやっていないことを取り入れたり、逆に、今までやって来たことを止めたりして、日常の中の習慣も一緒に変えることです。
プロセスは習慣と化しているだけに、開発作業だけのプロセスを変えるのではなく、それに関係しそうな、その人の内側にある日常のプロセス、普段のプロセスも変えないと、なかなか思ったようには変えることは出来ません。作業における判断も、そこから発しているのですから。人に関するプロセスを変える事が出来ないという人たちが見落としていることはこの点です。
もう一度いいます。プロセスを改善するということは、このような（一旦身に付いた）プロセスを変えるということであり、そこに、強い意志と具体的な方法〔＝形）が不可欠なのです。まずは、「分かる」という根本問題を認識していただいたうえで、文献の読み方、接し方、メモの取り方などを変えてみてください。プロセス改善はそこから始まるのです。