運用のこと

えー、その筋の人は「PDCA」ってイヤになるほど聞かされてる言葉だと思いますが、これ、実際には何をやるものかを勘違いしてる人も多そうなのでちょっと記そうと思いました。前職の現場での理解では、P（プランを立てて）->D（実行して）->C（見直し、練り直して)->A（実施）　と解釈してるバ。。人が多く、またこれが改善サイクルで現場の自浄作用と捉えてるように見受けられました。ずいぶん前に読んだITILの参考書にもそんな風に書いてあった記憶があります。自浄はともかく、どんどん良くなっていくスパイラル的な説明だったかと。

ところが実際はというと、そのPDCAが実行され、成果が出ているところを見たためしが無いんですね。何かが起きる毎にPDCAだPDCAだとギャアギャア言う割りに、運用が良くなっていく現場とは縁がない。ここで多くの人は「(PDCAという言葉の流行の発端になった）ITILは聖書」として「できれば素晴らしいんだろうけど、できれば苦労しない」と諦めたりとか、「実際の現場に沿ったフレームワークへの落とし込みがどうのこうの」というところに腐心したりする。資格のための知識と割り切って諦めてしまえばもうそれで良いかもしれないし、それで運用を設計する側にも行きたければ行けるでしょう(私が今ココ）。しかし諦めたらモヤモヤしたまま残業してなきゃいけないし、実行部隊から抜け出して万歳！じゃ解決してない。そしてまた新しいアルファベット3~4文字の手法に踊らされて運用現場に余計な仕事が増えていくと。

でも違うよね。と。ITILなんてそもそも顧客（英政府かなんか）から押し付けられたもの。そうじゃなくて「運用ってもっと楽にできる余地がすごいある気がするのに、なんでこんなバースト？？」という現場のモヤモヤ感を立脚点にして、考え直す必要がある。ITILがOSI参照モデルとすると、TCP/IPにあたる具体的なプロトコルも必要じゃないか。それが無いからいろいろダメっぽい。と思った次第。
「フレームワークへの落とし込みどうのこうの」はその中間をすっ飛ばしてる感がある。

それで状況を整理するためにWikiでPDCAサイクルの項目を見てみると、一発で何もかもわかった気がしたので（というか自分の勘違いに気付いた）この記事を書くに至った。wikiでの説明は次の通り。

1. Plan（計画）：従来の実績や将来の予測などをもとにして業務計画を作成する
2. Do（実施・実行）：計画に沿って業務を行う
3. Check（点検・評価）：業務の実施が計画に沿っているかどうかを確認する
4. Act（処置・改善）：実施が計画に沿っていない部分を調べて処置をする

「実施が計画に沿っているかどうか」ですよ。「計画が実施(実情)に沿っているかどうか」でなく。

最初のプランがどんなに現場の仕事に合ってなくても、それを修正する仕組みはこの中には無い。これまでのみんなが「見直し、練り直し」だと解釈していたCは、最初のプランに違反してないかどうかをチェック（Checkだぬ）するパートだし、AはCでの違反部分をPに沿ったものに戻す、という工程だったりする。Actの説明文に改善って書いてあるけど、これはCで違反があった場合は当初のPより「悪い」からそれをPになおすこと。に留まってる。Pをより良くしようとする改善ではない。

でもITの現場は取り扱うものや技術の進化がすごいと言われているし（他の業界知らんけど）、そうして変化したものや技術を使ってる側からの要求は当然一つの進化に対して複数生まれるので、もっとすごい。だからむしろ当初のP計画が今のD実情に体系を与えることができているかどうかを見直す必要がある、ということ。

で、PDCA本来の意味がどうであれ、Cが現状に即したプランへの練り直しとAがその実行という意識でみんな、特にDに一番詳しいはずの作業者が行動しているなら、うまく回らない理由にならないじゃないかと考える向きもあると思うが、ほとんどのバーストしてる運用の問題点はむしろここ、というのがwikiを見てバーンと思いついた。

これって、Doは現場の人が実行するんだけどPとCとAは現場にいるより上の人間がやってる。運用フレームワークはDoをする人間達をきっちり管理する目的で導入されてて、自浄ではないという本質がある。だから現場でCheckを行っても現場判断で勝手にActするわけにはいかない。でもとにかくその場はやらなければしょうがないので直属の上長に相談？報告？して承認され、Actの前例は増えていく。これはつまり作業員目線の場当たり的な対処が増えてくことで、上の人からみたらどんどんPlan無視の方向に進んでいるように見える。

　さて、管理対象の作業員達が、管理者の決めたプランに従わずに仕事をしていて、忙しい忙しいと言って来たら管理者はどう思うだろう？現場の風潮にもよるだろうが、まずはPを守れ、定量的なデータを出せ、その上でデータの分析・問題点の抽出を行い、話はそれからだ。というのがよくある流れじゃないだろうかと思う。でもそもそも、Doする人たちにとってCheckは余分な工数だし、工数としてでなく思考の中でCheckが行えているなら追加の工数をとらずに説得力を持たせるのはなかなか難しい。大抵の（自ら自身の作業に対してCheckを行う良心的な）作業員はここでモチベーションを失ってリビングデッド化するんじゃないか？

　もうちょっと食い下がる人なら業務終了後に残業し、定量データをまとめて、考察つきのレポートを出すかもしれないけど、これもすんなり受け入れるような文化の土台が日本には無いように感じてるし、そのレポートの内容が尤もだとしても、必ず何かのケチはつくもんだと思う。
　ある管理者は作業員にドキュメント作成のスキルを身につけてもらおうという良心からレポートのレイアウトを指摘するかもしれないし、別の管理者は自分の仕事を増やされたくないという思いから、効率がどうであれSLAは満たしている、と言って相手にしないかもしれない。レポートを受け取って、「わかった。考えとく」と言ったきり何も無いという管理者も実にいそうだ（爾後確認に行ったら大した説明も無く「ああ、あれね。ダメだった」とか言われる）。

作業員はPを修正させたい。運用設計者は設計しなおすためのデータが欲しい。間にいる人間はトップダウンを守らせるつもりでいて、ボトムアップをPに反映させるきっかけになるポジションという意識があまり無い。だから作業者から上がってくる対処法を都度承認して終わる。承認された対処法は毎度OKが出るもんだからすぐにそれが仕事の一部と考えられるようになってしまい、運用の再設計をする人間がわけのわからないまま現場はバーストしてる。こんなところじゃ無いかと思う。
　これは、間にいる人間がバカだとか悪いとか言うんじゃなく（気は利かないと思うが)運用再設計に至る仕組みがないのが問題だということで、それが「有る」と作業者に誤解させているのがPDCAという言葉なんだろうなぁ。ということ。

長くなってしまったのでまた帰ってきてから続きをします。でかけなきゃ（・ω・`