CMMの取り組みについて
List
プロセスを改善するということ
プロセス改善には２つの対象があります。
１）個人の中に習慣として根付いているプロセスを変えること
２）組織の文化となっている邪魔な慣習を変えること
一般には、１）の方しか認識されていません。個人の習慣を変えることについて：
今回の要件にあったプロセスを設計する（私は“定義する”とは言わない）習慣を持たない人にとっては、「プロセス」は外にあるのではなく、個人の習慣の中に取り込まれた「作業のやり方」そのものがプロセスなのです。事前に決めたものがあっても、それが身に付いた習慣と置き変わっていないかぎり、朝、出社してＰＣの前に座った途端に、体に染みついた方のプロセスが動き出すのです。事前に決めた方のプロセスに対しては、何だかんだと出来ない理由が付けられて退けられて行くのです。
そこで「出来ない理由」は簡単に出てきます。成果物の内容とプロセスが合理的に繋がっていないために、事前に考えたプロセスに入れないことが生じます。さらに、事前に考えたプロセスに対してシミュレーションをしていません。多くの場合、“決めただけ”です。何度もシミュレーションをすることによって、それまで見に染みついた方のプロセスの記憶が薄れていくのです。
しかしながら、そこで定義されたプロセスは、成果物との合理的な連鎖が確保されていなかったり、成果物の定義そのものが冗長すぎたりして、うまくシミュレーションできないものが多いようです。それでも、従来のプロセスとの差が少ないときは、まだ新しいプロセスでイメージできるかも知れませんが、「親和性」を崩してしまうと、簡単にはシミュレーションできません。
また、新しいプロセスを考えたとしても、そのプロセスで納期に間に合うことをイメージするには、サイズに基づいた見積りが必要になりますし、途中で大きく想定を崩すような「リスク」にも対応できることが求められます。残念ながら、これらの取り組みを最初から一気に出来る状況にはないのが現実です。
これが、事前に決めたようにはできない仕組みなのです。
組織の文化を変えることについて：
ところが、現場ではこうして「改善されたプロセス」を実行しようと思っても、組織の上層部の人の「一言」で壊れてしまいます。工程の６割を過ぎても、１行のソースコードも書かれない状態に不安を感じて、「そのやり方で間に合うのか？」といったことで、現場は混乱してしまうのです。現場のエンジニアも初めての取り組みですので経験はありません。リーダーが“これでいけるはずだ”と思っても、上から「失敗はゆるされないから」と釘を刺されると萎縮してしまいます。
私のコンサルティングを受けるというときに、チームリーダーに対して「やるからには結果を出すように」という余計な一言が発せられることがあります。上司としては予算を隠した手前、結果を出してくれないと困るという思いがあるのでしょうが、プロセスを変えることの意味を理解していないために、余計な圧力をかけてしまうのです。これも、その企業組織の文化です。
仕様の変更が何の制限もなく発せられる状態や、間違った反省会の進め方やレビューでの習慣など、チームレベルで改善しようと思っても組織の文化が邪魔をすることもあるのです。“上手くできて当たり前”で、そこを褒めない文化の中では、個人やチームの小さな「成果」を拾い上げることもできませんし、ましてや組織のレベルに昇華し展開することもできません。それでいてトップからはなんとか「水平展開」するように、という指示がでるのです。この「水平展開」するようにという指示は、何代も続いていて、ある立場に立った人は必ずその言葉を発しているのです。本人も含めて組織中を「否定眼」で埋め尽くしておきながら、「水平展開」を指示するのですから、何をかいわんやです。
その組織に営々と受け継がれてきた人事制度の文化も、こうした取り組みの邪魔をする一つです。私のコンサルティングの中で、チームレベルとしてはどこに出しても恥ずかしくないレベルに達していても、１回の無神経な人事異動によって、それまでの３年にわたる取り組みが水泡に帰したことは何度かあります。
また、「全体最適」よりも「部分最適」の発想が強い組織では、優れた人を「SQA」に確保しようと思っても、現場の長が優れた人材を離さないことがあります。こうした「文化」もプロセス改善に大きな支障を来します。優れた人を「SQA」に提供してくれないために、そのチームの成果を組織全体に広げることが出来なかったことも１度や２度ではありません。その内に、人事移動で崩れてしまうのです。
「プロセスを改善する」というのは、こうした「個人の習慣」と「組織の文化」の両方を変えていくことによって、改善の取り組みが自律展開する状態にできるのです。
CMMで前提となっている技術
90年代の初めに、私がCMMを研究する中でわかったことは、CMMに取り組むときには幾つかの技術は修得できていることを“前提”としていることです。たとえば、
・要求を適切に仕様化できる
・ソフトウェア・エンジニアリングやコンピュータ・サイエンスの知識や技術
・要件に適したプロセスを設計できる
・サイズに基づいた見積りができる
・リスクを発見し適切に表現し追跡できる
・プロセスに対応した形でスケジュールが立てられる
・肯定意見を出す習慣を持っている
などは、PSPやTSTで準備されることになっていたり、エンジニアリングやコンピュータ・サイエンスなどは、それ以前に学習し修得していることが前提となっています。もちろん、全員が高いレベルで修得していることまでは期待されていませんが、これらのことについて、誰も満足なレベルに達していないような組織を対象としていないのです。もともと、CMM（CMMI）は、アメリカの国防総省（DoD）が、自らの都合のために考えたモデルであって、世界のソフトウェア産業のために考えたものではありません。DoDとしては、これらの知識や技術を十分なレベルで持たない組織は対象にしなければよいのです。SEIにおける研究には公的資金を使っていることもあって公開されているので、民間の組織が勝手に使っているだけです。
しかしながら、日本のソフトウェア開発の組織で、これらの知識や技術を満足の行くレベルで修得している組織は少ないと思われます。汎用機系の組織では、ある程度は満たすかと思われるのですが、組み込み系の組織ではほとんど「０」に近いのではないでしょうか。頻発する仕様変更や仕様関係のバグ、さらには要求を満たすための適切な設計ができないのは、これらの技術が未熟だからなのです。
日経コンピュータ（2006.1.9）で、日本IBMの執行役員の内永氏は、自社での新入社員のITスキルを50項目のアンケート調査を実施した結果、「ほとんどが５段階評価のレベル０か１の低い判定になった」といっています。ちなみに米国やイスラエルでの調査では「過半数がレベル３に達していた」ということです。この調査は、新入社員に対するものですが、入社後のレベルアップにも、大きな足枷になることは言うまでもありません。
組織の重要な位置にいるマネージャーは、このように必要な知識や技術のレベルが高くないだろうということを認識していると思われますが、CMMで品質問題が解決すると思い込んでいる（誰かがこのように吹聴した？）状況では、こうした前提とする技術もCMMの取り組みと一緒に手に入るものと勘違いしている人も少なくありません。
コンサルティングの中で、あるチームは
・ベースライン設定後の仕様変更率は１％
・仕様関係のバグはもちろん、その他のバグも含めてQAテストでのバグの発生率は１件／KLOC以下
・当初の約束の納期も達成している
のですが、組織としてはCMMのレベルには達していません。この組織が適当なCMMの認証が取れないのは、
・前他の知識・技術レベルが低い
・組織としてのプロセスが存在しない
・センターSQAに適任者を充てることができない
だけです。でも、このようなチームが存在しているということは、そこには“うまくいく方法”があるのですから、このような組織こそCMMの取り組みが可能となるのです。
CMMが楽しくなる仕掛け
CMMには、３つの視点で褒める仕掛けが仕込まれています。少なくとも、私にはそのように見えますし、そうでなければ、CMMは推奨する価値はありません。その３つと言うのは、
１）ピアレビュー
これは、チームのメンバーによって成果物の中の肯定点を見つけ出す仕掛けが取り込まれています
２）SQA
ここでは、熟練したエンジニア（SQA）の目から見て肯定点を見つけ出し褒める仕掛けがあります
３）ポストモーテム
ここでは、チームメンバーの他に、自分自身でもうまくいった認識を確認する仕掛けがあります以下に、これらの３つの視点での褒める仕掛けについて簡単に説明します。
ピアレビューでの肯定意見：
担当者が、自分で仕様モレが起きにくい構成や書き方を工夫したり、画面遷移図と個々の画面仕様書を画面番号で繋いだり、操作画面のグループが分かるような画面番号の体系を取り入れるとします。彼としては、効果があると思っているのですがその効果はまだ確認できていません。あるとき、彼の書いた画面仕様書がレビューの対象になります。レビューで事前に彼の成果物を見たチームのメンバーが、何だか読みやすくなていることを感じ、さらに注意して見てみると、これまでの画面仕様書の書き方と違っていることに気付きます。この時、チームのメンバーは彼の“意図”を読み取り、その効果をレビューの場で「肯定意見」として出すわけです。
自分が改善の工夫した箇所が、レビューの場で、メンバーに認められて肯定意見として出されたときは嬉しいものです。いくらかは恥ずかしさはあるものですが、それでも「このメンバーは分かってくれる！」という思いは何ものにも変えがたいものなのです。その結果、彼とこのメンバーとの間に深い信頼関係が築かれるのです。
このように、レビューで肯定意見を出すことの効果は、メンバーが彼の成果物の中から肯定てきる箇所を認めることで、「因と果」を関係付けながら肯定意見として出すことで、認めた人の中にもこの工夫が入り込むことです。つまり、肯定した人の中に、「こうすれば、このような結果になる」という仕組みが理解できたことで、肯定意見を出した人も、彼の工夫が取り入れられることになるのです。レビューを通じて、こうした肯定眼を持つ人を養成することができるのです。そしてこれが、組織の足元で伏流となって「水平展開」を自然に推進する推力となるのです。
SQAによる評価：
テレビの番組で、プロ野球の球団から戦力外通告を受けた選手が「トライアウト」に挑戦するドキュメンタリー番組を見たとき、彼らもまた、日本の社会における「否定眼」の犠牲者に見えたのです。彼らは、５、６年前にドラフトの５位前後で指名され、希望に胸を躍らせて入団したのです。当初はレギュラーで出場していたのですが、毎年入団する新しい選手との間でポジション争いに負け、次第に出番が少なくなっていき、ついに戦力外通告を受けることになったのです。
番組の中で映された範囲の中で見たかぎりでは、彼らの練習の様子、トライアウトの本番での投球やバッティングの様子を見ていて感じたことは、そこに何の工夫もないということでした。投球フォームそのものも素直すぎるし、足の下ろし方や体のひねりかた、ボールのリリースポイントなど、打者のタイミングを外す工夫をしているようには感じません。バッターの方もボールを待つときの腕の位置や振り出しのタイミングに何の工夫もありません。普段からバットの振り出しをぎりぎりまで遅らせるための練習が為されていないのです。結局、トライアウトで選ばれることなくユニフォームを脱ぐことになったのです。
番組の後、彼らはなぜ工夫しなくなったのか考えさせられました。おそらく少年野球の時代から、褒められたことがないのではないかと思われます。ホームランを打った時や、バッターを三振にしとめたときなど、「結果」に対して褒められることはあっても、その結果を手に入れるための取り組み（プロセス）に対して褒められたことがないのではないでしょうか。工夫というのは、結果に対して出来るものではなく、プロセスに対して行うものですが、彼らの指導者にはその「眼」が備わっていなかったのでしょう。
バッターにボールの出所を見えにくくするために、左足をクロス気味に踏み出してみようというような工夫をしても、結果が出なければそのような取り組みは評価されないのでしょう。本来なら、そのクロスの仕方にまだ工夫の余地があり、優れたコーチであれば、そのヒントを与えることができるのでしょうが、日本では、結果に繋がらないことをやると直ぐに「標準形」に矯正されてしまうようです。その結果、彼の体の特徴を活かせず、競争に負けて活躍の場を失ってしまうのです。
このような日本の常識と全く正反対な動きをしているのが、ボクシングの「亀田３兄弟」です。父親がコーチをしているが彼はボクシングの経験はないということです。だが、業界の常識を覆すような工夫を練習の中に取り込んでいます。一般のボクシングジムでは、このような練習方法は評価されないでしょう。でもそんな声に惑わされることはないようです。その練習内容はとんでもなく厳しいが実に合理的に考えられています。結果に繋がることをイメージして練習内容が工夫されているのです。余りの厳しさに体験入門したボクサー（この人もプロです）も１日で根を上げるということです。
良い結果を得るにはこうした工夫を評価する人が必要なのですが、日本のソフトウェア開発の現場にはいないのです。日本のソフトウェア開発の現場にあるのは、先の戦力外通告を受けた元プロ野球選手のように、その選手の特徴を無視して「標準」のフォームに強制されてしまうのです。現場の能力を活かすことはCMMの中で勧められている「SQA(CMMIではPPQAと呼称が変わったが、ここではSQAで通すことにします)」なのですが、もともと日本の組織には“褒める”習慣がないために、現場の状況（能力）にあった標準を判断できるようなSQAの適任者は見つからないのが現実です。
組織の中に配置した専任のSQA（センターSQA）が、プロジェクトと並走しながら、そこで行われているプロセスや成果物をチェックし、事前に想定した範囲の中で作業が進められているかチェックするのですが、その時、それぞれのエンジニアの工夫を見抜く必要があるのです。しかしながら、まだ結果に繋がっていない状況で、それが工夫されたものなのか、単に事前に想定した通りとは違い、昔の習慣に戻った状態なのかを見抜くのは簡単ではありません。現役時代に工夫したことのない人には、その違いを見抜くことは無理かも知れません。
いうまでもなく工夫がすべて評価されるわけではありません。少なくともすべての工夫が望ましい結果に繋がるわけではありません。だからこそ工夫されていることを早期に発見し、その着眼点や工夫の状況が、望ましい結果に繋がるものかどうかを判断し、場合によっては「調整」のヒントを与えることも必要になるのです。もちろんその前に、基本的に工夫の意図や姿勢が正しいものであれば、工夫の内容とは別に評価しなければなりません。そうでないと、工夫の楽しさを身に付けることができいないからです。その時、評価する人は、チームのリーダーやマネージャーよりも、SQAのような立場の人からの評価の方が効果的なのです。
ポストモーテムによる評価：
ポストモーテムで重要なところは、担当者個人が取り組みの効果を評価することです。もちろん、ピアレビューのように、チームのメンバーからの評価もありますが、実際に工夫し取り組んだ担当者が、今回の取り組みをどのように考え、その結果をどのように認識しているのかということを文字や言葉にすることが重要なのです。自己評価ですので、基本的には適切なデータがあるこことが望ましのは当然です。
たとえ、その時点では最終結果には繋がっていなくても、要求仕様の書き方を工夫したことで、レビューでの指摘件数が、事前の予想とくらべて１０倍も指摘されているというデータがあることで、ある程度の効果はあったことが分かります。もちろん、今回はこのほかに目立った改善の工夫はされていないとすれば、最終的な結果には、必ずしも繋がらないかも知れないのですが、それでも従来ならバグとして残った可能性があるものが何１０カ所も指摘されたのですから、間違いなく改善の効果はあったのです。
ポストモーテムでは、このタイミングで「○○を工夫したことで、□□の問題がこの段階で多く発見された」というように「因と果」を繋いで文字にしたり言葉にして発表するのです（実は、「因と果」を繋いで文字にするするというのは私の工夫であり、TSPの中でポストモーテムを発見するずっと以前からやっていたことなのです）。成果物に対する改善の意図はあったわけですから、そこから何を改善すればそのような結果が得られるかということについて考え、それを取り組んだことで（ある程度の範囲で）狙った結果が得られたときに、直ぐに「因」と「果」の形で認識しておかないと、何が効果をもたらしたのかが分からなくなってしまいます。
ポストモーテムには、このほかに「PIP（プロセス改善提案）」を出す機会があります。効果が不十分なとき、さらにどのように改善するかを直ぐに考えておくことは有効です。そして、日常的に「因」と「果」を繋いで考える習慣を身に付けていることで、こうした改善提案もスムースに考え出せるのです。
このように、CMMでは、褒める、あるいは肯定点を探す、ということを３つの視点から取り入れているのです。こうした環境の中でのソフトウェア開発の作業が楽しくないはずはないのです。
地に足着けた取り組みを
多くのソフトウェア開発現場でのプロセス改善の取り組みの過ちは、せっかちで、急ぎすぎることです。そこでの取り組みは、私には地に足が着いていない状態に見えます。Ａ社がCMMのレベル３の認証を取ったということで、トップの方から“我が社も１年以内に取れ！”と「檄」が飛んできます。自分の組織の実情を見たこともない人が、何の根拠もなく「１年で・・」とか「２年で・・」と檄を飛ばすのです。日頃から、プロセスの設計や優れたレビューの運営が行われているのであれば、そうした檄も推進力になって悪くはないのかも知れませんが、今まで、いい加減なプロセスで作業をやってきた組織が、「檄」だけで目標を達成できるものではありません。
プロセスを改善するには、エンジニア自身が習慣の中で身に付けてしまったプロセスを改善するだけでなく、センターSQAのような組織を配置したり、肯定眼を組織に普及させたり、従来から続けている「反省会」を止めて「ポストモーテム」に切り替えるといった、『組織の文化』を改善することも含まれるのです。多くの組織では、直ぐにセンターSQAとしての適任者は見つからないと思います。数年という時間をかけてプロセス改善の取り組みの中で育てなければなりません。この部分を疎かにしたままCMMの認証取得を急いだところで、その状態（レベル）を維持することが出来なくなります。その意味からもプロセスの改善は地に足着けて取り組むべきなのです。以下に、地に足着けた取り組み方の幾つかを紹介します。
ソフトウェアの開発組織に適当なエンジニアリング・プロセスや管理プロセスを持たない状況であれば、外部から参考になるようなプロセスの見本（PFDで表現されたものと定義の組合わせ）を導入することは妨げません。ただし、その通り実行するのではなく、まずはその表現を参考に、自分たちの中で行われているプロセスを表現してみるべきです。このときは「as-is」で構いません。そうして表現された自分達のプロセスを検討して、そこから改善すべきプロセスや成果物を特定するのです。その場合も、「親和性」を無視した変化は失敗する危険が高くなりますので、３０％程度に抑えることをお勧めします。現状（今、いる場所）によっては、一気に頂上には登れません。
プロセスの改善で大事なことは「失敗」しないことです。取り組みとして「不足」の状態であれば、次回はもう少し範囲を広げたり、精度を高めたりする動機になりますが、やり過ぎて「失敗」した場合は、チームやメンバーにこの種の取り組みに対する「免疫」を付けてしまう危険がありますので避けることが肝要です。その意味からも、最初はゆっくりと取り組むべきです。
そうして、計画的に現場のリーダーに“うまくできる経験”を積ませることです。
その中で、彼は、
プロセスの設計
サイズ見積り
スケジュール
進捗管理、
要求の仕様化
レビュー技術
などの技術を修得していきます。この時、新しく取り組むときは、かならず「ガイドライン」を作りながら進めていきます（「手順書（ガイドライン）の作り方の項の「現場のリーダーが作れ」を参照）。ガイドラインは、既に誰かが書いた物があれば、それを参考にして自分たちのプロジェクトに合うように調整します。これは「テーラリング」の練習を想定したものです。
どこに、どのようなガイドラインがあるかは、センターSQAに任命された人が知っています（というよりも、そこに情報を集めるようにします）。初期の頃では、この人も必ずしもSQAの適任者ではないかもしれませんが、SIPの推進者など準適任者であれば十分です。本当のセンターSQA担当者は、この時点で実際のプロジェクトを指揮するリーダーの中から出てきます。初期のセンターSQA担当者は、先駆者としてセンターSQA担当者が生まれる環境を作ることが大事です。
このセンターSQA担当者も、現場のリーダーと一緒になって走ることで、間接的にプロジェクトの成功体験を積むことができますので、率先して良い経験を積むことで、SQAの適任者になる可能性もあるのです。
こうして、組織の各階層の人の力でプロジェクトを成功させるのです。ＰＬに力を貸してプロジェクトの成功の経験を積ませることで、プロジェクトを成功に導く要素を体得します。こうした取り組みを組織的に繰り返すことで、彼らは「次代のセンターSQA」の候補となるのです。
そしてその過程で、組織の中に「褒める文化」、あるいは「肯定眼で見る姿勢」を広げることも重要です。これには組織のトップの支援が不可欠ですが、初期のセンターSQAの担当者と協力して、ピアレビューの機会を使って肯定意見が出やすい組織の風土を作っていきます。こうした環境の中で育ったプロジェクトのリーダーは、後に続く人たちのために、センターSQAの役を引き受けてくれるものです。その方が、自分が得た成功体験を広く普及させることがでできることに気が付くのです。
能動を引き出すこと
プロセス改善の取り組みでもっとも重要なことは、現場のエンジニアの「能動」を引き出すことです。“やらされる改善”では効果的な工夫は出てきませんので、形骸化してすぐに効果を出さなくなります。
プロセスを改善する必要があるというのは、そのプロセスが省かれていたか、適切に実施されていなかったことを意味します。したがって、そこでは新たな取り組みが増えることでもあり、やり方を変える必要があるのです。もちろん、省かれていたプロセスを取り入れることで、前回のプロジェクトでは何度か「メモ」を作って補った行為が不要になったり、適切なデータ構造が選択されますので、この方面での手戻り作業がなくなるのですが、「受け身」で取り組んでいる状態では、この「増えるプロセス」に対応する形で「減るプロセス」が具体的にイメージできませんので、プロセスの改善が中途半端になってしまいます。そこで増減する「量」のイメージができないことも、適切にプロセスを変化させることなく取り組んでしまうことに繋がっているのです。
本来、「プロセスを改善する」ということは、そこで行われていたプロセスよりも合理的なプロセスになるのですから、合計の作業量（工数）は減るはずなのです。でも、「増えるプロセス」と「減るプロセス」が明確にイメージできないままでは、プロセス改善の取り組みによって作業量の増加を招いてしまい、約束している納期や工数に対する負担となるのです。こうなると、ソフトウェア開発の現場は、頭ではプロセス改善の必要性は認識していても、現実の「約束」に対する圧力から、新たな取り組みを拒否したり、“今回は取り組めない”理由を探すようになります。
現場のエンジニアたちが“取り組めない”と言ってしまえば、周囲の人はどうすることもできません。もちろん、コンサルタントもお手上げです。直属の上司も、場合によっては身動きが取れなくなります。そして、「プロセス改善」に対して「受け身」の状態で開けられた「穴」は、現場の人たちの姿勢が「受け身」であるかぎり広がることはあっても塞がることはありません。
このように、プロセスの改善は受け身の状態に陥らないように工夫しながら進めていくことが大事です。そのためには、取り組んだだけの効果が上がることを実感できるように取り組みを計画することと、最初に取り組みの「課題」を背負い過ぎないことです。その上で、プロセスを改善することの意味や取り組みの目的を理解してもらうことが必要です。
その中で、プロセス改善の取り組みにおける時間の足し算と引き算の仕組みを理解してもらうことも必要です。「増えるプロセス」と「減るプロセス」を明らかにすることで、合計時間が増えないことがわかることで、取り組みの不安は軽減します。それと、あとで結果を検証できることで、取り組みの効果も見えます。
ソフトウェアの開発組織の状態によっては、最初は新しい取り組みが、トータルの工数を決して増やさない仕組みを確立し、納得してもらうことは重要です。現状のプロセスが不適切な状態であることで混乱し、納期を遅らせているのですから、プロセスを改善することは、必ず工数的にも心理的にも軽減されることになるはずです。でもそこで計画された取り組みによっては、逆に工数は増えてしまうのです。それは明らかに「間違った改善の取り組み」と言えます。
新しいプロセスに対してスムースに取り組めるようにイメージトレーニング（シミュレーション）することも大事です。今までにない新しい成果物を生成することが想定されているのですから、紙に書いただけでは過去の習慣が邪魔をしてうまくいきません。事前にシミュレーションした上で、センターSQAの担当者が実際にプロジェクトに並走して、事前に想定したようにプロセスが実行できることを支援することで、所期の結果を得るよいに誘導することが大事です。
今回取り組むテーマも、一方的に押し付けるのではなく、バグデータやこれまで習慣的に実施されてきたプロセスを確認し、そこで現場のエンジニアたちが納得して取り組めるようにします。ガイドラインも自分達で作るほうがシミュレーションになるのと、実感も湧いてきますので、センターSQAの人が手伝ってあげてください。既成のガイドラインを持ち込む場合も、必ずチームのメンバーが咀嚼し、“過大”にならないように手を加えて下さい。
自分達が「これなら取り組めそうだ」「これに取り組もう」と“決めた”ことに取り組み、その結果を手にすることが大事です。そこに「能動」の楽しさが味わえるのです。最初は小さな効果であっても、それが「能動」で動いた結果での成果であれば、すぐに大きな成果になっていくはずです。
この他に、プロジェクトの運営の中で「能動を誘う仕掛け」はいろんなところで可能です。
「ピアレビュー」
レビュー対象の成果物を事前に配付することで、前もって目を通すことに能動を誘うことができます。指摘箇所を事前にメールで送ってくれたり、肯定意見を出してくれたりすることに対して感謝してください。欠陥の指摘だけでなく、より良い成果物になるための「提案」も大歓迎です。担当者もこれによって成長するわけですから。
「プロセスに対する提案」
エンジニアリングプロセスはもちろんですが、各種の管理プロセスにおいて、小さな提案を誘い取り上げてください。日常の中で、改善できる箇所について考えてくれることは、組織的にプロセス改善に取り組む上では非常に重要な姿勢です。そのために、「標準」と呼ばれるものは最小限のレベルに押さえておき、現場の人たちが取り組み方法を考える余地を残すことも重要です。
当初の「ISO-9001」では、企業という組織全体に「１つの標準」しか認められませんでしたので、そこで作られる標準は「MAX＝最大定義」の状態にならざるを得ませんでした。そのような「標準」では能動が入る余地はありません。幸いにも、「CMM」や2000年版の「ISO-9001」は、「部門」のような単位ででの標準を認めていますし、最終的には要求にマッチした「プロジェクトの標準」が認められていますので、随所に能動を仕掛けることが可能です。
日常の中で、能動的に考え工夫することを仕掛けることが大事です。このような組織の姿勢が次代のリーダーやセンターSQAを育て、最終的にレベル５の「エンジン」にもなるのです。