品質から始めよう

ＱＣＤの管理が全く出来ていない会社に赴任されたあなたへのアドバイスです。コストの管理やプロジェクト進捗や課題の見える化、やることは色々あるでしょうが、リソースは質、量ともに不足しています。そんな中で、日本での高い管理レベルを引き合いに出して、それをシステムとして丸ごと入れようとするのは止めましょう。出張者を呼んでそれを指導させたところで、受入側にキャパシティがない状態では、定着しないでしょう。それをもってして、現地人のレベルが低い、現地人の血を入れ替える必要がある、と短絡的に判断したならば、それはその判断そのものに問題がある、と考えます。あなた自身が先人達の知恵と努力が結晶した管理システムという敷かれたレールの上を一度走ったことがあるからといって、現地会社を上から目線で見下すことは、大変失礼な態度だと思います。

さて、まず何から手をつけるか。結論です。

「品質から始めよう。」

品質問題は、我々情報部門が提供しているサービスという価値の根源が揺らいでいる、という状態です。我々の存在意義が危機に瀕している状況であり、ビジネスリスクがＩＴによって作り出されている状況です。一刻も早く事態を好転させなければなりません。まずは、マイナスをゼロ（イーブン）まで引き上げることが急務です。

では、品質管理の何から始めればよいのでしょうか。

「ＳＬＡ（サービスレベルアグリーメント）はお客様へのサービス保証レベルであり、そこから始めないと、何が正常で何が異常か分からない」という意見もあるでしょう。特に、サービスをベンダーにアウトソースしているような場合は、ベンダーマネージメントという観点からも、ＳＬＡは大変重要です。そして、もしあなたの会社に品質マネジメントなるものが、何も無いとしたならば、ＳＬＡは入り口ではなく、出口に近いところで出来る議論だと私は考えます。机上の理屈で稼働率９９．９９％を目指すとしても、今現在の身の丈がどの程度か知らずにそれを議論する意味がどれだけあるでしょうか。自分の現在の体重を知らずして、目標体重を掲げるダイエットに挑戦するようなものです。
品質改善の取組みの始め方は、①品質を管理するサービス範囲を定める　②その範囲でサービスが提供できない事態を品質事故として事故レポートを書く　③そのレポートのレビューを定期的会議で行なう、という三つの管理サイクルから始めます。

①のサービス範囲ですが、まずはあまり欲張り過ぎず、お客様から多大なクレームを受けているサービスに特化しましょう。例えばメールシステムの稼動やネットワークといった「稼働率」が問題になるインフラ系サービスと、発注やＡＴＰといったサプライチェーンにおける対外に影響の出る「締め切り時刻」に間に合うかどうか、といった点が問題になるようなミッションクリティカルなサービスに注力しましょう。プロセス関連では、ビジネス側の運用課題とＩＴ基盤の稼動を分ける理由も必要もありません。プロセスとＩＴが一体となって一つのサービスとなっているのですから。範囲を決めたら、何が○で何が×かといったトラブルの認定基準を決めます。稼働率が問題になるようなサービスでは、とにかくメンテナンスの計画停止以外で止まったら×。締め切りが問題になるようなケースでは、締め切りに間に合わなければ×です。シンプルに行きましょう。もう一度繰り返しますが、スタート時点では、管理する対象や範囲を絞って、重点課題に集中しましょう。

次に、「②事故レポート」ですが、スタート時点では、事実をもらさずに集め、記録することに注力し、それが出来ていなければ、徹底的にその部分を指導してください。記録すべき事実には、何月何日何時何分にその問題が発生し、いつその問題が解決し、計何分サービスがダウンしたのか。それによってどのようなビジネス面での影響が発生したのか。問題の現象と解決までに取った行動の時系列での記録です。それに対する考察としての、原因分析、対策といった部分は、担当者が上げてくる最初の報告書としては不十分であっても構いません。ただ、事実の記録に関しては、これは当事者にきちんと網羅して記述してもらうしかありませんし、その事実の妥当性は、自分自身では検証不可能なものがほとんどですから、絶対的な事実が網羅的に記録されている必要があります。まずは、事実がきちんと記録されるようになれば、「グッドジョブ！」と手放しで褒めてあげましょう。品質問題を抱え続けている会社に共通していることは、対策がきちんとできていない場合よりも、むしろ包括的、網羅的に事実を掴む力がないことに問題の本質が横たわっています。不十分な、断片的な、時には誤った事実に基づいた「正しい判断」による行動を続けても、事態は一向に好転しません。

ハロルド・ジェニーンの書いた「プロフェッショナルマネジャー」（田中融二訳）から関連する記述を抜粋します。

「マネジャーが目的を達成するために、なんとしても、正しい決定をするのに必要な情報を入手しなくてはならない。そうすれば、目的への道は一歩一歩、おのずと開けていく。どの一段を上がるにも、真の状況を把握するための正確な事実が必要だ。信頼できる情報に拠ることができれば、決定をおこなうことはさほど困難ではない。、事実は力である。それは良い経営に不可欠なものだ。」

最後は、「③レビュー会議」です。この会議の究極の目的は、徹底的に「事実」を求める態度を全員に徹底し、その事実から素直に「学習する」態度を醸成することです。「衆知を集める全員経営」のチーム作りのための修練の場です。この会議は、月一回、月初に行なうと良いでしょう。時間は三時間ぐらい確保してください。こなれてくれば一時間半ぐらいで終わるでしょうが、立ち上げ時には三時間程度は必要です。参加者は組織が小さければ全員参加、大きければスーパーバイザー（主任）以上が参加という形が理想です。報告でなく、議論の場ですから、できるだけリラックスした雰囲気作りが求められます。会議の最初の出だしは、他愛も無い誰でも入れる雑談からスタートするのも良いでしょう。トラブルの話は、ややもすると重苦しい雰囲気になりがちです。入り口のところでは、リラックスした雰囲気作りが重要です。会議では、トラブル報告書を書いた本人もしくはその上司が、説明します。一通り説明が終わった後、気づきや意見を述べる時間を取ります。会議をスタートしたばかりの時には、全員緊張していますし、ましてや自分の責任範囲以外のトラブルに対して意見を述べるという行為自体が、ジョブディスクリプション（職務権限）を超えるものである、という事実もありますので、最初から活発な意見は望めません。一人一人順番にコメントさせる方式をとった方が良いでしょう。あなたが上司であれば、気づきをコメントしたメンバーに対して、「とてもよい気づきだと思う。ありがとう。」と感謝しましょう。もし誰もあなた自身の気づきや疑問点に気づいてくれなかったら、その部分の周辺を婉曲的に触れながら、意見やましては命令ではなく、質問の形でみんなに投げかけを行なってください。模範回答を教えるのでなく、気づかせることが重要なのです。気づくというのは、自らが発見する、というこということです。ここでの「自ら気づいた」という体験が、知恵となりコンピテンスとして堆積していくのです。

ガリレオもこういっています。

「人にものを教えることはできない。みずから気づく手助けができるだけだ。」

また、気づきや意見があまりにも出ない場合には、５ＷＨＹ（なぜを５回繰り返す）といった分析のための技法をベースに全員でホワイトボードを使いながらレビューしていっても良いでしょう。この場合も教えるのでなく、気づく手助けをするというスタンスで、ファシリテーター役に徹します。このレビュー会議は、品質問題をネタにした人材育成の道場です。

この会議は、トラブルを知ることによってシステムとビジネスを知る場でもあります。トラブルを通じて、そのサービスそのものが本質的にどういう機能と効用を持つのか、それが問題を起こすと、関連するサービスやビジネスがどのような影響を受けるのかを理解することでシステムの持つ本質的なサービス内容を全員が共有できます。縦割りマネジメントでは学ぶことができない知識とノウハウを学ぶ場でもあります。また将来のマネジメント候補を選別し、育成する場でもあります。積極的に他人から学び、かつ意見をするメンバーは、こういった場でメキメキと頭角を現します。
あなたに一貫して求められる態度は、事実を求める強い姿勢です。とにかく、品質問題の改善には、事実の正確な把握なくしては語れません。また、この会議であなたが、どういう質問をするかによって、あなたのマネジャーとしての資質が丸裸にされるとともに、その一貫した強い姿勢から求心力が生まれるのです。何のためか、それは正しい意思決定、正しい経営判断をあなた自身が下すためです。
この事実を求めるマネジャーの態度について、ハロルド・ジェニーンはこう述べています。

「本当に重要なことはすべて、自分で発見しなくてはならない。マネジャーには、ストレートな質問に対してストレートな答えを要求する権利があるが、そのためには質問が適切でなくてはならない。適切な質問は出所のさまざまな情報をもとにして、自分の頭の中で、しかも初めて、組み立てられたものでなくてはならない。」

「組織の中で良い連中はマネジャーから質問されるのを待ち受けている。なぜならば、彼らはそれに答えることができ、答えたいと思っているからだ。それから初めて両者は一緒に前進することができる。」

会議では、質問を発し、全員の衆知を集めて議論を尽くして行きます。事実の把握が出来、意見を集めた上で行なうことは「意思決定」です。あなたがマネジャーであれば、それはあなたの仕事です。
事実が十あるとして、その全てが揃っていれば、もはや思考を巡らすまでもなく、答えはその中にあり、それは誰が判断しても大よそ同じ結論に至るでしょう。この場合、もはや意思決定というより、承認と呼ぶ類の行為で、にっこり笑顔で「ありがとう。」でおしまいです。
一方現実の世界においては十の内、六も揃えばいい方、七まで揃えば万々歳といったところではないでしょうか。理想は、十まで事実を追求することですが、かかるコスト、時間、スキルや経験の実力値、設備面での限界能力を考えながらバランスの取れた判断をしなければなりません。感覚的な話になりますが、六ぐらいまで揃えば、考えられる仮説が多くても三つぐらいに限定され、そのうち二つのどちらかの可能性が高く、その二つを両方同時に走らせた方が、残りの事実を追求するよりもスピード、コストともに有利です。仮説の数がそれ以上になる場合には、もう少し事実の追い込みが必要でしょう。事実の整理が六、七合目に来たかどうかを見極め、周囲の意見に耳を傾けながら適切な仮説を立て、その優先順位を決め、適切なリソースの配分を行なうことが、あなたが行なう意思決定の内容です。見通しのきかない状況において、灯台のように光を照らし船の進むべき道を決定する行為が意思決定です。六合目だと思っていたが実は二合目だった、あるいは登る山を間違えていた、というような発見も、事実の調査を進めるより、仮説に基づいて行動を起こした方が早く発見できる場合が多いでしょう。それから、すべてのトラブルは科学的な説明が可能である、という考えを絶対視しないことも重要です。起こったトラブルを科学的に調査、分析するよりも、さっさとサーバーをリブートした方が良い場合がある（実に多い）ことを我々は経験的に知っています。

ハロルド・ジェニーンはマネジャーの意思決定についてこう述べています。

「決定は、とりわけきわどい決定は、マネジャーが、そしてマネジャーのみがおこなわなくてはならない。ある計画なり、部なり、会社なりの統率者は、そのために給料をもらっているのである。事実は権威である。責任者であるからには、正しかったり間違ったりする権利があるが、それはマネジャー本人でなければならぬ。マネジャーの命令は尊重されるが、それはマネジャー本人の命令でなくてはならぬ。マネジャーには、他の誰かに決定や命令を代行させる権利はない。」

品質から始めましょう。品質の取り組みを通じて正しい態度を身につけましょう。この取り組みを通じて、得られた知恵が、「７つの習慣」でスティーブン・Ｒ・コヴィーが述べた次のようなものであることを、私は切に願っています。

「問題は自分の外にあると考えるならば、その考えこそが問題である。それは、自分の外にある事柄に支配されることを容認することである。」