参考：Grady, R., and T.VanSlack, "Key Lessons in Achiving Widespread Inspection Use," IEEE Software, 11,4(July 1994),pp.46-57.
ここで言う「審査」とは「Inspection」であり、いわゆる設計インスペクション、あるいはコード・インスペクションのことです。また、この場合のインスペクションは、私が勧めるウォークスルーと同じものです。
この鉄則で述べられているように、インスペクションを上手に運用することが最も効果的であることは、２０年も前から主張されてきたことです。
インスペクションが有効である根拠は、自分で書いたプログラムに潜むエラーを自分で見つけることは容易ではない、と言うところにあります。間違った認識の下では、当人がそこにエラーがあることに気付くことは期待できません。その上、当人がテストする限りテストケースも認識の範囲内でしか想定されないでしょうから、そのようなエラーを検出するようなテストケースが想定されないないのです。
それに対してインスペクションでは、制作者と違った考え方や発想の人が参加することが期待でき、思い違いや認識不足の箇所に気付く事が出来ます。もちろんそれでも漏れることはありますが、それは全体の１８％ということです。
これだけの現実（データ）を示されているのに、最近のソフトウェアの開発現場では、この種のインスペクションは実施されなくなりました。その結果は、エラーの数は減少しないし、機能強化の保守作業によってソースに手を加えるような作業の場合、エラーが複雑化していく傾向すら見られます。これは、担当者が目の前のソフトウェア（ソース）を理解できなくなってしまった証拠とも考えられます。
実のところ、この問題の難しさは、インスペクションを作業のスケジュールに載せるところにあるのかもしれません。望ましいスケジュールは、小刻みに計画された成果物の仕上がりと、それに対応する形でインスペクションが計画されているものです。
しかしながら、現実にはこのインスペクションを日程に加えることができないのです。それをやると、インプリメントやテストの時間がなくなってしまうからです。その結果、（前回と同じように！）インスペクションの時間をカットし、その分をテストの時間に回すのです。これで、インスペクションは姿を消します。やればいいのかなとは思っていても、実際にスケジュールに組み込めないのです。
プログラムの仕上がりが不安だからテストの時間を多く割いてしまうのです。そして、その不安は（今回も）見事に的中し、テスト作業が大幅に膨らみ、挙句の果てに最終納期まで遅らせてしまうのです。このとき、“とてもインスペクションなんてやってられなかったな”ということになります。
こうなった理由は、最初からテストを前提とした作業を行ったところにあるのですが、多くの組織ではそのことに気付くことはありません。
インスペクションの方が効果的であることは証明されているのに。それがうまく行かないのは、やり方が悪いだけなのに・・・
昔（１５年以上前）は、どの組織でもコード・インスペクションを実施していました。５０００行であろうと１万行であろうと、担当者を含めて２、３名で、時には３日もかけてやっていました。多くの開発組織では、それが当たり前だと思っていたのです。
しかしながら、ワークステーションが普及して、いわゆる“コーディング”をしなくなり、設計書からコードまですべて一人の担当者のキーボードからインプットされるようになった頃から、コード・インスペクションは姿を消しました。と言ってもそれに代わる方法が現れたわけではありません。
確かに要求される開発期間の短縮、システムの規模の拡大や質的変化などもあるでしょうが、それとは別に、設計書やコードが直接コンピュータにインプトするようになって、紙に印刷されなくなったことと、仕事量の増加に伴ってソフトウェア・エンジニアが大量採用されたことなども原因と考えられます。
そこでは、プログラムの体裁はいいから早く“動くこと”が求められ、それに呼応するようにエンジニアの質が落ち、さらにインスペクションが出来る（取り仕切れる）リーダーを揃えることが出来なくなったことも一因です。
自分の成果物がインスペクションの場に晒されることに抵抗する情景も目にします。まるで業務プログラムであり製品であることを忘れてしまっているようです。また、自分が書いたプログラム（注意：自分のプログラムではない！）に、エラーを指摘されると怒りだす人もいます。「プロ」であることの自覚が存在しないか、「プロ」とはどう言うものであるかということを考え違いしているのでしょう。
開発者自身が自分達のプログラムを一切テストしないＣＲ手法（Crean Room
手法）は、その代わりに徹底したレビュー（ここでいうインスペクション）を行うことで、プログラムエラーの数を１０００行当りで数個まで減らそうという開発手法です。
時にはコンパイルもしないで評価チームに渡してしまうという、一部の人にとっては考えられないようなやり方です。しかしながら、このＣＲ手法は、インスペクションのやり方次第で、そして、インスペクションを旨くやれるようなドキュメントの書き方次第で、そこまで品質を高めることが出来ることを証明しました。
設計者が実施するテストというのは、基本的には自己満足の域を出ません。ましてや、散々いじくり回して自分の理解を超えてしまったプログラムに対して、一体、当人ができる効果的なテストというものが存在するでしょうか。
ＣＲ手法が実際に機能するという厳粛な事実に対して、関係者は正視すべきです。そして、その背景にあるのがインスペクションであることも、素直に認識すべきです。
ＣＲ手法では、設計書をインスペクションするだけでなく、コードもインスペクションします。だからこそコンパイルもしないで評価グループに渡すことができるのです。
しかしながら、「作文」と違って、人の書いた「プログラム（のコード）」を読むことは容易ではありません。彼が一体どういうつもりでこのステップを書いたのかと言うことは、相当訓練されなければ読み取れるものではありません。人によって考え方も違うし、どこまでプログラムに反映させるかと言う問題は、時として哲学の領域に足を踏み込むことになります。実際、プログラムを見ていると、その人の職業観や生活観といったものが分かることがあります。それだけ「個人」がそこに色濃く反映され、そのことが人の書いたプログラムを読むことを一層困難にしているのです。
“難しいからやらない”というのでは、いつまで経ってもＣＲ手法を手に入れることはできません。人の書いたものを読む訓練を早くからやっておくことが必要です。
インスペクションを経験したことがない、或いは人の書いたものを読んだことがないということは、その人はもしかすると、自分とは違った発想に最後まで触れる機会を得ないのかも知れません。自分で発見できないエラーを、他人が見つけられることは基本的にはありえない、などと思っているかも知れません。たとえ見つけられたとしても、それは「偶然」であり、“たまたま”見つかっただけだと思っているかもしれません。
もし、このような考えの人が過半を占めるような開発組織があるとすれば、一体そこから産み出されるソフトウェア・システムとはどういうものなのでしょう。
我が国の人件費の水準が高いことは既に広く知れ渡っているところです。その結果、九〇〜九三年の比較で、労働生産性は日本を一〇〇としたときに米国は一八二という状態です。今や日本の労働生産性は米国の半分に過ぎないのです。また資本生産性（生産財を含む資本がいかに有効に活用されているかという評価基準）も、米国の六割です。
一九八〇年代、日本の製品は先進国の市場を席捲しました。特に米国の市場は日本の製品によって大きなダメージを受けました。自動車の町デトロイトは相次ぐ工場閉鎖に追い込まれたし、連邦議会の議員たちがハンマーをもって家電製品を叩き壊すというパフォーマンスまで飛び出す始末でした。
一九八六年に、ＭＩＴ（マサチューセッツ工科大学）が「産業生産性調査委員会」を発足させ、「アメリカのインダストリアル・パフォーマンスにどのような変化が生じたのか。そしてこの事態を打開するためにアメリカができることは何か」というテーマに取り組ませたのは、その時代の危機意識からでした。
三年後、この委員会は「Made in America」として報告書をまとめました。そこには、経営戦略が時代遅れになっていること、製造プロセスの改善、大学を含めた学校教育に対する提言、企業内訓練の在り方、これからの労使関係、政府と産業界の関係の在り方、長期的視野に立った生産性向上の必要条件など、実に具体的で多岐に亙っての提言が盛り込まれています。
この報告書が発表されたあと、米国の政府、産業界、教育界が一斉にこの提言に沿って動き初めたのです。そうして九○年代に入って企業は経営戦略を変え、製造プロセスを変え、産学一体となって生産性の向上に取り組んできたのです。
前号にも触れましたが、モトローラ社が欠陥ゼロを目指す画期的な管理手法としての「シックス・シグマ」に取り組んだのは八七年ですし、ＩＢＭに居たミルズがソフトウェアの開発手法である「クリーンルーム手法」を発表したのも八七年です。この何れもが九○年代に入って結果を出し始めています。これらが米国産業全体の生産性に寄与してくるのは、むしろ二○○○年にかけてなのです。残念ながら今の情勢では、二〇〇〇年には日米の生産性の格差は今以上に拡大しているでしょう。
彼らは、部分ではなく、全体に亙って戦略を変え、思考を変え、プロセスを変えてきたのです。翻って、我が国ではこの間、企業や行政の管理手法に、ほとんど質的変化は見られません。堺屋太一氏によると、もともとこの国の企業の管理手法や組織形態は、役所のそれを真似たものということです。たしかに戸籍課の課長は、その課の係長を五年も勤めていれば大過なくこなせるでしょう。さらに言えば、コンピュータの導入によって、その作業の方法は変わっても、戸籍課の業務自体はほとんど変わりません。
これに対して、民間の企業には、こんな悠長な職種はないはずです。比較的変化のサイクルが緩いと思われる総務や人事の業務にしても、一〇年も前から大きく質的変化を求められているのですが、現実求められている変化に対して反応が遅いように思われます。
採用にしろ、評価にしろ、変えなければならないことは関係者は“分かっている”のです。しかしながら、採用方法だけ、あるいは評価基準だけを変えれば事は済むというものではありません。同時に、それぞれの現場に於いて、新しい評価基準を浸透させる手立てが必要ですし、作業のプロセスを変えて、正しく賃金が労働の対価になるようにしなければなりません。いずれは「生涯賃金」という考えを外さなければならないでしょう。また、退職金制度や年金制度、さらには税制も絡んできます。
「今の状態」から変化させようとすれば、一時的な混乱や軋轢は避けられません。一つの状態が長く続き過ぎた分だけ、向かう先との乖離が広がってしまいました。でも適切な変化は常に起こさなくてはなりません。その変化を避けても、日本を取り巻く世界が変化している以上、格差（乖離）は広がっていきます。
進んで変化させたときの混乱は、進んで変化させた組織には対応が容易です。同様の混乱は進んで変化させなかった組織も遭遇しますが、そのような組織に、その混乱を乗りきる対応が出来る可能性は少ないでしょう。受け身であるがために選択の余地が極めて限定されるのと、変化させるノウハウを持っていないことが原因です。
言い換えれば、自ら進んで変化させている限り失敗はないのです。あるのは期待した状況と少し違う状態がほんのしばらく続くだけです。
今日の市場からの要請は「量」から「質」への変化です。二〇〇〇年に向かって、この要請は揺るぐことはないでしょう。 ■
この国では秀吉は立身出世の代表として評価されていますが、ここで紹介する文章は、福沢諭吉が「日本には政府ありて国民（ネーション）なし」という自説を説明する中で引き合いに出されたものです。ネーションというとき、それは単に「国」に所属しているというだけではありません。
時あたかも、尖閣列島をめぐって、台湾と香港（中国）のネーションが命懸けで行動している場面が報道されていますが、これを多くの日本人がどのような思いで見ているかということを考えて見れば、福沢のいう「日本には政府ありて国民（ネーション）なし」という意味が良く分かるでしょう。
福沢に言わせれば、西洋の考え方では、藤吉が天下をとったとき、その出身母体である「百姓」全体の地位が上がらなければならないのに、この場合、藤吉だけが立身し、以前、その身を置いていた「百姓」の地位はそのままだというのです。
福沢は、この部分を次のように見事に表現しています。
「この人物は唯其の身を脱して他に遁れたるのみ。之を譬えれば、土地の卑湿を避けて高燥の地に移りたるが如し。一身のためには都合宜しかる可しといえども、元と其の湿地に自ら土を盛りて高燥の地位を作りたるに非ず」
福沢は、決して藤吉を非難しているわけではありません。ただ、東西文明の比較に於て、「日本の人民は国事に関せず」という特徴があることを見抜いたのです。それは歴史的にも、太平洋戦争の沖縄を除いて、人民は戦いに巻き込まれることがなかったところに由来しているのです。
団欒の 部屋のどこかで カネタタキ
とりどりの 紅葉の中 高速道
蹊成