1. マネジャーの間には、部下が品質保証に関するノウハウを自由に発揮できる環境を作ることへの不安がある。マネジャーは、そうした環境を作ると部下との力関係がいずれ逆転してしまうのではないかと恐れている（この恐怖は通常、企業がどのように運営されるべきかをマネジャーが知らないことから来ている）
2. マネジャーは上記の恐怖から、居丈高に振る舞って部下の間に「会社の意向に反して製品の品質について進言したりすると、首になるのではないか」という恐怖心を植え付ける。この場合、マキャベリの同様の（だが、ある意味でより深遠な）言葉が思い浮かぶ。「愛されるより恐れられる方がはるかに安全だ」。結局のところ、トップとしての地位を守ろうとしない人はいない。IT部門においても同様だ

　恐怖心を与えることは、特定の状況でマネジャーが社員を指示通りに行動させる1つの方法だ。しかし、それが品質の高い製品を作る妨げになってはならない。同様に、QAマネジャーの個人的な都合によって、彼がQA部門にプロジェクトを任せるやり方が左右されることがあってはならない。そうしたマネジメントスタイルは社員のやる気をくじき、社内の活気がなくなってしまう。どんな会社でも、広い心を持ち、会社の顧客、製品、プロセスを精いっぱい大事にして会社の発展に尽力する人が、本当の勝者であることは明らかだ。米国の大企業の社員によく見られる自己中心的な傾向を考えると、それは非現実的な見方かもしれない。しかしわたしは、期待を持ち続けたい。つまり、QA部門の統括者が皆、すべてのプロジェクトで高い品質レベルを維持することの効果と重要性を十分に認め、理解することを。

実例――恐怖が事故につながったNASA

　1986年1月に起きたNASA（米航空宇宙局）のスペースシャトル・チャレンジャー号の爆発事故を振り返ってみよう。皆さんも覚えているかもしれないが、この事故の原因は、外気温の低下の影響でブースターロケットの接合部のすき間をふさぐために使われていたOリングが硬化し、機能を果たさなくなり、そこから燃料ガスが漏れたことだったことが判明している。シャトルの点検を担当した機械技師は、打ち上げの数日前にOリングの問題を発見し、上司に何度も報告していた。だが、上司はまったく取り合わなかった（チャレンジャー号の打ち上げは、悪天候のために既に2回延期されていた。彼らには守るべき期日があったというわけだ）。

　この技師が打ち上げ前にあらためてシャトルを点検したところ、Oリングの問題は解決されていなかった。彼はそのために起こり得る事態を認識していたが、状況を警告して打ち上げ中止を主張し、マネジャーの怒りを買ってしまったら仕事を失うのではないかと恐れた。そして何が起こったかは周知のとおりだ。何人かのマネジャーが自分の考えを強引に押し通して現場を萎縮させてしまったために、7人の命が失われたのは恥ずべきことだ。

　チャレンジャー号の機械技師が感じた恐怖は、IT部門の社員にもしばしばつきまとう。ソフトウェアは、人命が掛かっているものばかりではないかもしれないが、どのように作られるかはチャレンジャー号の場合と同種の条件に左右される。

コミュニケーション不足の弊害

　わたしの以前の勤務先では、週に数回ソフトウェアビルドを緊急に作成していた。この会社では、わたしのマネジャーもほかのどのマネジャーも、普段はわたしのグループと何もコミュニケーションを取らなかった。われわれに連絡が来るのは大変な作業が発生したときと相場が決まっていた。電子メールが送られてきて、マネジャーの設定した期限を守るために早急にテストを行うよう指示されるのだ（業務時間が終わる前の1時間で作業を片付けなければならないことが多かった）。突貫作業のため、QAグループはプロダクトが辛うじて基準を満たしたところでテストを終えざるを得なかった。

　だが往々にして、その後間もなく同じものを何度もテストする羽目になった。問題が最初に修正されなかったためだ。われわれはマネジャーからこう言われていたようなものだった。「さあ、後は君たちに任せた。がんばってくれ。ほとんど不可能なプロジェクトだけどな。でも、がっかりさせないでくれよ。でないと後悔することになる」

　同僚の多くは、こうしたやり方に反対すると仕事を干されるのではないかと恐れていた。だが、われわれは全員、土壇場になるまで蚊帳の外に置かれるのではなく、前もって情報を与えられていれば、ソフトウェアがもっと早く完成し、多くのトラブルを避けられたはずであることを理解していた。

　わたしはこうした経験を踏まえて、ITにかかわるコミュニケーションの破たんを防ぐ最良の方法は、以下のステップを着実に実施していくことだと考えるようになった。

1. 集中管理型の社内情報伝達方法の整備

　社内のさまざまな関係者に情報が十分に行き渡らないと、相互の行き違いが生じ、最終製品の品質に関する無用のリスクを招くことになる。不都合な問題の重要情報が発生したら、その問題の影響を受けるすべての関係者に伝達すべきであり、中でも重要なのがIT部門への伝達だ。IT部門では情報伝達のために、会議を開いたり、トラブルチケットを作成したり、ポータルに文書を掲載したりといった方法を取っていることが多い。問題を一元的に管理するには、問題を周知し文書化して、適切な対応が行われるようにすることが重要だ。

2. 業務フローの明確化

　日々の業務フローに対する要望は、必ず前もってIT部門に知らせておかなければならない。業務フローのガイドラインを作る際は、既存の合意された社内プロセスを踏まえる必要がある（幾つか例外的な場合もある）。業務フローを整理して文書化しておくことは、IT部門を含む社内のステークホルダー間での、さらにはIT部門と社内顧客との適切なコミュニケーションを促進するのに役立つ。

3. プロジェクトの品質と手続き

　ビジネスプロセスやシステムの変更は、必ず適切な方法で行わなければならない。変更手続きのガイドラインは、上のステップ2で述べた社内基準を満たす必要がある。さらに、こうした変更の進め方は、追跡、検証、監査しなければならない。例えば、必ず検証を行うことにより、個別のソフトウェアプロジェクトの要件が社内顧客の要求に対応したものになるようにしたり、ソフトウェア開発の過程で、すべての関連部署が手続きのガイドラインに準拠するようにしたりすることが必要だ。

4. プロジェクト計画の立案

　プロジェクトを確実に成功させるには、開始から完了までのしっかりした計画が必要になる。プロジェクトの成功にとっては、ステークホルダー、開始から終了までのスケジュール、文書化、成果物提供、および要求を管理することが不可欠だ。設定された基準をすべて達成するために、最初のプロジェクト計画は、プロジェクトライフサイクルのできるだけ早期に立案する必要がある。

5. プロジェクトの文書化

　プロジェクトで使用、提供されるべき情報を把握しておくことは、IT部門がチーム間および社内顧客との間で、オープンなコミュニケーションを維持する上で極めて重要だ。この情報は、整理して文書化しておかなければならない。「文書足跡」を残すとともに、業務プロセスを再実行する場合に迅速化を図るためだ。適切な情報の収集と記録が確実に行われるように、文書標準が使われている場合が多い。わたしはこれまでに、数社の雇用主のために文書マトリックスを作成した。これは、顧客やプロジェクトの規模、コスト、期間に応じて、どのような文書が必要かを網羅的に示すものだ。われわれはこのマトリックスを使って、当時取り組んでいたプロジェクトで求められる成果物を洗い出していた。

6. 顧客の要望の明確な把握

　このステップは、IT部門内外で適切なコミュニケーションを進めようとする場合に関係する。前述したような形で社内顧客の要望を整理して文書化しておいたとしても、こうしてまとめられた要件が最初から社内顧客の要求に完全に合致することは、私の経験ではめったにない。要件のリストについて社内顧客の正式な承認を得た上で、プロジェクトのスケジュールや予算案を策定するべきだ。

　われわれは社内顧客の要件など、非常に重要な情報を電子メールなどの手段でやりとりすることにすっかり慣れてしまっている。しかし、これは内容の誤解を招いたり、受け取りミスが発生したりする恐れがある。要件に関する正式な文書は、行き違いが生じないように明確に記述し、レビューを経て、顧客と顔を合わせてあるいは少なくとも電話で、確認した上で承認を得なければならない。すべての要望に対応するとともに、不測の事態に備えた対策を講じておくことも必要だ。

7. プロジェクト目標の周知徹底

　IT部門と社内顧客は、異なる目標を掲げているかもしれないが、共にプロジェクト目標の達成に向けて協力しなければならない。プロジェクトのスコープと目標は（ステップ5と6に示したように）、適切に文書化して伝達する必要がある。IT部門も社内顧客も、前述のガイドラインへの準拠をおざなりにして、近道をしようとするのは禁物だ。目標は時間とともに変わるかもしれないが、そうした変更はできるだけ早く周知して、新しい最終目標が共有されるようにしなければならない。

　わたしは品質保証ディレクターとして、キャリアの中で多くの試行錯誤を重ねて、これら7つのステップをマスターした。これらのステップは、わたしの会社の仕事の品質を高め、社内チーム、社外チーム、われわれの顧客の間のコミュニケーションを充実させるために大いに役立った。7つのステップをすべて適切に実行すれば、IT担当者がしばしば陥る恐怖は、いずれは解消されるだろう。しかしそのためには、これらのステップが、経営陣からIT部門のインターンまでの各層に広く受け入れられ、定着しなければならない。

本稿筆者のジョン・スカーピノ氏は品質保証ディレクターで、ピッツバーグの大学で講師を務めている。