多くのソフトウェアの開発組織において、これまで数知れず「ＱＣ活動」やその他の改革／改善活動が取り組まれてきましたが、残念ながらそれらの改革／改善の活動は、殆ど成果を生み出していません。そこでは一所懸命に取り組んでいる人たちもいれば、“どうせ上手くいかないだろう”という気持ちで取り組んで（？）いる人もいます。というより、後者の人が大半でしょう。
そして数ヶ月後。やはり結果は何も変わらず、そこで行なわれている作業は、以前と殆ど変わらないのです。要求仕様書は相変わらず書かれていないし、設計書のレビューも今までと同じで上手く出来ない。バグの修正も担当者が“責任をもって”修正し、治っている事を確認するのです。
いったいこの半年、職場内を駆け巡ったあの「風」は何だったのだろう。
・・・これが現実でしょう。
以前と比べて作業が円滑に進められているわけでもなし、有用な成果物が産み出されるようになったわけでもありません。そこでは、メンバーは、不機嫌な顔をして相変わらず残業を積み重ねて「黙々」と作業をしているのです。
変わったことは・・・一つだけ。それは誰も作業の改革／改善を口にしなくなったことです。
いったい、どうしてこのようなことになるのか。そこで取り組もうとしたことは、今振り返っても、どれ一つとして間違ってはいないはず。それが出来るようにならなければ、数年後の市場の要請に応えられなくなるのでは、という危惧も間違っているとは思えません。
ただ、その種の「危惧」は５年前にも言われていたが、「今」もこうして仕事をしている事は確かです。もちろん、仕事の成果に対して誰からも感謝されたことはありませんが。一体、あの時の危惧は、単なる思い過ごしだったのか？ それとも、今度は「本物」か？
残念ながら、これを判断するには、技術動向や社会情勢のの変化、「大勢」を見なければならず、多くの職場にあっては、判断できる人はいないかもしれません。ただ、好ましい状態ではないとしても、相変わらず彼らが「そこ」で仕事を続けている理由は、「他に選択肢がないから」だけかも知れない、ということには気付いた方が良いのですが。
それでは一体、この種の取り組みが実を結ばないのは何故か。
それは、そこで挙げられた幾つかの「取り組み」が、問題の根源に触れていないからです。表面に出ている「症状」の背後には、いくつもの「問題」が絡みあっています。
例えば、毎回同じようなバグを出すというのは、そこのプログラムの仕組みが理解できていないからと思われますが、それには、ソースを読む力が不足しているのかも知れませんし、プログラムを理解する「形」を持っていないのかもしれません。また、修正する前に「変更点」を文書化して、チームや組織で制御する、いわゆる「変更制御」の仕組みを取り入れれば良いのかも知れませんが、そうなると、自分の持ち時間を割いて人の変更点を検証して上げなくてはならず、自分の作業も約束できない状態では、殆ど望むことはできません。そんなことをしたら、自分の分担が間に合わなかった言い訳が出来なくなり案すし、リーダーや管理者も、その点に関しては全く憶病です。また、そのような方法（変更制御の考え方や方法）をトレーニングしようとすれば、この場合もそのような時間を確保できないのと、どうして忙しい思いをしてそのようなトレーニングを受けなければならないのかという問題にも突き当たります。
「ツール」を使いたいと思っても、それを使いこなすためには、「手法」を修得しなければなりません。どう考えてもそのような時間を自分で融通することはできず、さりとてマネージャーに直談判しようにも、それを使いこなす自信がないため、そこで思い止まってしまいます。結局、今まで通りの作業を続けることになります。
このように、「問題」はいろいろな問題と絡んでいて、一見しただけでは、何処が「糸口」なのか分かりません。はっきりしていることは、作業標準を策定しただけではだめだということ、ＯＳを入れ換えただけでもだめだし、オブジェクト指向を取り入れただけでもだめだということ、負担を小さくするために分担を小さくしただけでも、もちろんダメだということです。
「問題」は以下の４つの領域に存在し、一つの問題が他の領域の問題の「原因」となっています。特に、プロセスに関する問題の殆どは、他の３つの領域に起因する問題（原因）の影響を受けています。したがって、４つの領域に対して同時に働き掛けないと、期待する結果が得られないことになります。
●仕事の仕方の領域（プロセス）
●アーキテクチャの領域
●意識の領域
●組織の領域
殆どの改革／改善の取り組みは、この領域に含まれます。作業手順の確立や、ＣＭＭの取り組みの他、それらの取り組みを支援する各種の手法や技法の修得などが含まれます。以下に、その中の代表的な幾つかを列挙しますが、これを見てもお分かりのように、これまで多くの組織で取り組まれてきた項目は、殆どこの領域に属しています。
作業の手順的なものとして、
要求仕様の作成と管理
スケジュールの立案と進捗管理
作業手順の確立
外注管理
構成管理と変更制御の仕組み
品質保証の仕組み
レビューの運用
チームの運営と組織内の協調の仕組み
成果物、およびプロセス・データの測定と判断の仕組み
技法的なものとして
レビュー技法
サイズ見積技法
スケジュール見積技法
分析・設計技法
テスト技法
欠陥予防のための技法
など
これらの技法の習得や、作業手順の確立を実現するには、他の３つの領域の状況に大きく依存します。
アーキテクチャ領域の問題というのは、そのシステムの設計思想が間違っていたり、使用している言語が障害になっていたり、あるいはシステム構成上、拡張性などの品質が考慮されていなかったりすることを指します。
例えば、適切なＯＳやリアルタイム・モニターが搭載されていないという状況や、システムの殆どがアセンブラで書かれているような状況では、製品の表面上は簡単な機能の変更のように見えても、実際の変更作業は大変な作業になることも考えられます。そして、そのような事態は、「プロセスの改善」の枠の外に位置します。
また、グローバル・データが氾濫していて、内容の更新のタイミングが把握できないような状況とか、流れの制御の為に「フラグ」が多用されていたり、関数の呼び出し構造が複雑で、図式化出来ないような状況では、一つの修正行為が、新たな不具合を注入してしまう可能性が高く、「仕事の仕方の領域」の「変更制御」の取り組みも、殆どはスポイルされてしまうでしょう。
このような時は、プロセスの改善とは別に、アーキテクチャの問題を特定し、その状況の改善に同時に取り組む必要があります。
この種の改革／改善の取り組みにおいて問題となるのは、この領域です。
ただせさえ忙しいのに、どうして仕様書の書き方とか、見積もり方法の勉強をしなければならないの？どうせ書いたって誰も見やしないじゃない。それにレビューなんてやったって時間がもったいないだけよ。
どうして、結合テスト前のテストまで、不具合票を書かなければならないの？
オブジェクト指向分析を勉強しなくても、オブジェクト指向言語でプログラミングできるではないか。
「その日の遅れがその日に分かる」ような詳細なスケジュールなんて書いてられないよ。そんな時間があったら、１行でもコードを書いているほうがましよ。どうせ予定と一致することなんてありえないのだから、適当でいいじゃない。
言うまでもなく、このような考え方の下では何も変わらないし、何も取り組めないことは言うまでもありません。実際には、このようなあからさまな抵抗を示すことは少ないかも知れませんが、多くは、「やり過ごし」という“手法”が使われます。それだけに逆に厄介なのです。
要は、仕事の意義とか、何のために新しい技術を身に付けるのか、何のためにプロセスを改善するのか、という点に関して、一定の理解と認識がないと、何も進めることはできません。
組織やチームの在り方とか、成果物の測定やプロセスの測定の意味も、その上でなければ理解できないでしょう。「幸福」の原点が、仕事を上手く仕上げるところにあるということに合意が出来なければ、一緒に仕事をしていくことも、一緒にこの種の改革／改善に取り組むことも出来ないでしょう。
そのためにも、意識の領域に潜む問題をクリアしていかなければなりません。ただ、この領域の問題の幾つかは、組織の領域の問題から派生しているのです。
組織の領域の問題としては、評価基準や、それに伴う昇進・昇給の仕組み、減点主義的風潮の存在、“言い出しっぺ”が損をする仕組みなどが挙げられます。この種の取り組みのためには、現実の仕事の合間を縫って勉強しなければならず、そのことが評価される仕組みが無かったり、取り組みが当初の目論見通りの効果を上げなかったときは、その責任を追及されたり、評価を下げるような仕組みの下では、誰だってこの種の取り組みに対して「忙しさ」を理由に“やり過ごす”しかありません。
そのような組織にあって、「今、その取り組みに手をつけると、この作業が遅れてしまいますよ」というセリフに対応できる管理者は一体どれだけいるでしょう。
この種の取り組みは、これまで述べてきたように、実に複雑で厄介な者ものです。ちょっと“善意心”を発揮したぐらいで実現するものではありません。したがって、「組織」はむしろ、そのような人を積極的に「支援」すべきであって、責任を云々する状況ではないはずです。
「やってみようか」という人が一人も居なくなってしまった組織を想像すると、空恐ろしい限りです。ここでいうような組織の仕組みが悪ければ、数年でこのような組織になってしまいます。これでは従業員が１０００人いても、その組織が社会に貢献するとは思えませんし、そこに居る人たちが「幸福」を感じることもないでしょう。
この領域のもう一つの問題は、それぞれの人の「役割」が明確にされていないことです。多くの現場では、何となくその「役」を勤めていますが、果してその人の守備範囲と責任範囲が明確でないため、この種の取り組みに際しても曖昧になってしまいのです。
以上、プロセスの改善に纏る４つの領域の問題について述べてきましたが、残念ながらこのような観点から問題を捉えている組織は殆どないと思われます。その原因の一つは、そこに居る人たちのスキルが「部分」に偏っていることが上げられます。とても意識の領域や組織の領域にまで考えが及ばないのが現状ではないでしょうか。
しかしながら、ここに挙げたようなそれぞれの領域に存在する問題にきちんと対応されなければ、プロセスの改善には取り組めないことは、これ以上、言を重ねなくてもお分かり頂けると思います。