第５回までで、運用業務での品質管理に価値を生み出すために使うツールについて説明しました。最終回である今回は、自ら始めてみんなで効果を出す品質管理のストーリーについて説明します。

目次

■品質管理活動に対する頑張り方■

■小集団活動とTQMの組み合わせ■

■なぜ品質管理活動を一人から始めるのか■

■個人のPDCAの先に組織のPDCAがある■

■品質向上のための自動化と自働化■

■あとがき■

■品質管理活動に対する頑張り方■

品質管理についての活動は、企業としての戦略の一環から、チームや部課ごとの活動と幅広く行っていると思われます。
全体最適を図るという言葉を聞く機会があると思います。品質管理をすることの目標は全体最適にならないと意味を持ちません。
また全体の中には各個人が含まれますので、各個人の最適化も大きな要素です。
誰も犠牲にせず、個々人が改善し、それが組織の改善の流れとして一本化され、企業が進化しなければいけません。
文章で書くと堅苦しいのですが、ヒーローがたくさんいるアニメで考えると、一人一人の武器から小さく細いエネルギーが出ますがそれだけでは強敵を倒せません。同じ志を持ったヒーローたちが集まりエネルギーを連携して相手に向けると、倒すに十分な武器に変わります。
品質向上を狙う活動も同様に、皆さんもまずは小さなエネルギーを出せるようになること、そして同じ目標に向かってみんなのエネルギーを合わせることが重要です。そして誰一人、力尽きて倒れないようにお互いにケアしながら戦うことが必要です。
無暗にエネルギーを発射していると成果が出る前に疲労して倒れます。どこに向けるか、きちんと皆で目標を定めておくことが重要です。
同様に品質管理においても、解決すべき目標を解決できる仕組みにより、小さな成果を大きな成果に変えていくために、様々な単位で品質管理のPDCAサイクルを回します。
人の単位 ：個人で回す、チームで回す、部課で回す、会社で回す
時間の単位 ：会議の中で回す、午前中に回す、今日回す、今月回す、今年度回す
これらの活動が重なっていたり独立していたり様々ですが、枝分かれ構造で関連が付いているはずです。そうでないと利益に結び付かない活動になってしまいます。

■小集団活動とTQMの組み合わせ■

ボトムアップである小集団活動としてのPDCA品質改善は部分最適として優れていますが、必ずしも全体最適にならない結果を招くことがあります（つまり他の誰かに皺寄せが向くだけ）。とは言ってもトップダウンで行うTQMではモチベーションを保つことが難しいようで形骸化し易いようです。組織の特性に合わせてバランスの良い組み合わせを見出さないといけません。
管理サイクルに慣れてくれば、品質管理として始めたPDCAサイクルの管理にて、ほぼ全ての仕事が、親子関係や相関関係でPDCAサイクル上に乗ってきます。これが第３回で言葉だけ出てきた工程管理とEVMに並ぶ、「品質管理をベースとしたプロジェクト管理」になります。
まずは自分が受け持っている一つ一つの仕事の関連性をしっかり理解し、それぞれの仕事のQCDの目標値が他の仕事にどう関わるか、自分の中で関係性を理解することが必要です。
最初は「この作業を終了させてからでないと次の作業に進めない」という認識から始めるのも良いと思います。大切なのは「作業を終了させる」という目標達成の具体的成果の定義です。ちゃんと出来ていると考える人が多いのですが、その割には「あれ？あそこ、ちゃんとやっていたはずだが、おかしいなぁ」と後戻りするケースが日々発生しています。作業の品質が悪い＝後戻りで工数を無駄にする＝スケジュールを後退させる、というQCDの連鎖的悪化を招きます。
PDCAサイクルに乗せながら作業を行う場合に最も重要なのは、「できた！ということはどのように表せばいいか」をQ,C,D,のそれぞれの観点からの要素をPlanすることです。初めてこのアプローチをする際は思考に慣れていないために時間がかかり、うまくいかなく、散々悩んでしまうかもしれませんが、何をするにも最初はそうなのです。諦めず日々練習して、まずは自分の仕事にストーリーを持たせて、計画に対する成果の刈り取りに慣れなければ技術者としての論理的思考が身に付きません。（ここの流れはOODAでも良いかとも思います）
この時点で、各自、たくさんの改善サイクルを持ち、かなり速いペースで回して仕事を行うことになります。これらの方向性が正しければ、チームのPDCAの一部として機能します。

■なぜ品質管理活動を一人から始めるのか■

各個人の改善サイクルを重視するのには理由があります。
技術者は各自が自分の得意な技術分野を持ち、自分自身の商品価値を高める、つまり今の環境で妥協や満足をしないで個人競争力を持つように努力すべきで、この努力をするから技術者と言える訳です。（場合によっては薄く広く、という技術の持ち方もあります）
自分の技術力の刷新を行うため改善活動をするのですが、その目標が身近にないと腰砕けになりがちで、成果が出なく、結局は技術力も身に付かない無駄な活動になってしまいます。
そうならないようにするために、仲間とコミュニケーションを図り、目標がブレていないか、やり方に無駄がないか、一人でやるのではなく一緒にやった方がいいか、など思考を整理します。これにより、お互いがどの部分に対してどのようにアプローチをしているか理解するので全体バランスを取り易くなり、チーム全体の抜け漏れ、強み弱みが明確になってきます。
このあたりは「カイゼン」の中で語られています。
その積み重ねが、自分のPDCA、チームのPDCA、今日のPDCA、今週のPDCA、半期のPDCA、年度のPDCAと描いた成長ツリーです。重要なポイントは、個々のPDCAを「小さく動き素早く結果を回収する」ことで、計画に沿っているか、より良い発見がありツリーの修正が必要か、逸脱して無駄がないかを素早く見つけ、マイナスが発生する前にPDCAサイクルの調整をしていきます。「そんなに計画をしょっちゅう変えていたらプロジェクトが管理できなくなる」と思われるかもしれませんが、ほとんどの場合、評価軸の調整ですので、日々の業務が大きく変わるわけではありません。業務運営で無益となってしまった目標を追いかける方が無駄になります。
ここで陥る罠を一つだけ紹介しておきます。目標設定やPDCAサイクルの運用をケース・バイ・ケースで小まめに入れ替えることがあると申し上げましたが、計画変更は常にリスクを伴います。リスク低減のため計画変更においてもPDCAサイクルが適用され、その変更が正しい決断だったかを評価しなければなりません。プランニング役が判断のPDCAサイクル（あるいはOODAサイクル）を省略して実務のPDCAサイクルのPlanを変更していくと、現場が混乱し誰が旗を振るのかも分からなくなり、他のPDCAサイクルとの整合性が取れなくなります。このケースは割と見かけるので十分に注意してください。勘が鋭い優秀なエンジニアの方々は「そんな手間暇かかることは、いちいちしてないよ！」と思われるかもしれませんが、そのレベルの方々は脳内でPDCAをシミュレートしてストーリーを組んで追跡して効果回収しているものですので、充分なスキルを身に着ける前に表面的な真似だけをすると酷い目に遭います。

■個人のPDCAの先に組織のPDCAがある■

大小多数のPDCAサイクルを導き出すと、運用における実業務のほとんどがPDCAサイクルに載っていることが分かるかと思います。品質管理の業務とは、品質管理を行うという単体業務で存在するのではなく、日常業務の中に存在します。もし、今までQCDの目標値にて、Quality、Cost、Deliveryをカイゼン活動として実務とは別に設定して活動していたら、それは形だけの活動であり日常業務は良くなりません。
また、先ほど述べた自分で立てた計画がうまくいかない場合の見直しの他に、要求仕様が変わった場合など、業務に大きな変化があった場合のPDCAサイクルの見直しに躊躇しないことが重要です。実業務がPDCAサイクルに乗っている場合、業務目標に変化があればPDCAサイクルを見直すのは当然のことです。
こうして計画して実行するPDCAサイクルは、大雑把に言うと業務品質の向上を目標にしているはずです。ただ、目標が向上であるからと言って、向上した、つまり成功体験だけが価値を持つものではなく、失敗体験も重要で、結果を出せなかった活動は「なぜ失敗して何を考えるべきだったか」という大事な学習効果を身に着けるチャンスとなり、失敗体験も重要なノウハウとなります。逆の方向では、成功体験も「なぜ成功して成功し続けるためにはどうすればいいか」を考えることで自らの経験に基づいた競争力を獲得できます。
個人で活動することで得られた品質向上技術をチーム、組織へフィードバックすることは、事例分析による手順書の見直しやチェックシートの作成などでお馴染みと思います。
作業を行っているとトラブル解決により技術力が身に着くことは非常に多いと思います。これは現象、原因、対策をきちんと分析しているからです。机上の勉強で身に着けるよりも焦りや緊張の中で否が応でもやらざるを得ないから、いわゆる「体で覚える」ということになり、懲りるという経験で得たものはなかなか忘れないのが人間です。しかし誰にとっても懲りたくないのは事実ですので、仮説や事例をどれほど自分の問題と認識できるかが工夫する部分でしょう。
その反対の楽する部分については、例えば定型化して結果のみ必要な作業をマクロやスクリプトで自動化すると気持ちに余裕が出てきます。

■品質向上のための自動化と自働化■

単純に手順を機械的に置き換えるのではなく、その効果を測り、どのような作業をどのような方向性で行えば皆が楽になるかを考え、担当している一人一人が考えて工夫し情報交換し、皆で成果を上げることを、自働化という言葉で表現します。自動化ではなく、自働化できるようになり、初めて正確で効率的な運用を行えるチームに成長します。
このような活動をしていると、いつも問題点や課題、PDCAサイクルをたくさん回していることが夢にまで出てくるほど追い詰められるかもしれません。そうなるほど熟考する価値はあります。そしてその先には、いつも頭の中でPDCAサイクルが勝手に回り、日常の作業がどのサイクルのどこをやっているかが勝手に割り振られている状態になります。そして「回っているPDCAサイクルが少ないかな？」と感じて憑りつかれたように問題点を探すという行動を皆がするようになることで各員、チーム、会社のQCDが劇的に改善し、組織が強くなる、と結論付けられます。

■あとがき■

ここまで６回の話にお付き合いいただきありがとうございます。
「好きこそ物の上手なれ」
「楽するためには労を厭わず」
という言葉があります。筆者はこの２つを以下のように解釈しています。
エンジニアの仕事は、世の中に「あぁ、楽になった」、「これならなんだか楽しいぞ」というような喜びや幸せを提供する役割を持っていると思います。仕事をやらされ仕事ではなく自分自身の意思で誇りを持って取り組むためには、その喜びや幸せに敏感でいる必要があると思います。そしてその気持ちを仲間と一緒に味わうことで、誰かが犠牲になること無く全体が良くなるという理想に近づくと考えています。
そのためには、自分の仕事の進め方を、「楽すること、但し成果はきちんと出すこと」を念頭に置き、その仕事が好きになり、それによりさらに自分の技術力を高められるというサイクルに乗せることが非常に重要と考えています。
もし、仕方ない、今の状態でもいいじゃないか、という気持ちがあれば競争力を失い、エンジニアとして後手に回り、世の中の進歩に反する形で遅れが加速していきます。そうならないようにも、意識を高く持つことが必要と思います。
また運用管理の品質評価・改善を主業務として取り組まれる方へのお願いが一つあります。チームの品質を評価する際には、机上のデータだけで判断するのではなく、必ず現場に出向き、人の動きを自分の目で確認してください。その動きがどのように机上のデータに反映されているかを理解することが改善のカギになることは多々あります。
これを読まれた方が、「楽しいシステム運用であるためには何をすればいいか？」を考えるクセを身に着けていただけると幸いです。