IT Office Nishimiyahara

個人用スマホから商用プログラミングまでなんでもお任せ下さい

作った仕組みに縛られている

      2014/02/28

成果目標ということで、色々な標準化、マニュアル化を目標に設定している。
今の上司がそういう系の仕事が好きなので(と推定)、そういう系の目標を立てているのだが…。

「仕組み作り」は良いことです。しかし、仕組みを作り出す立場の人は、『仕組みにより動かされていく人のモチベーションを考慮した仕組み作り』というコンセプトを肝に銘じて、取り組んでいく必要があると思います。「論理的にパーフェクトな仕組み」だけでは、「人を巻き込んだ仕組み」は作る事ができないのです。

転勤して現在の勤務地になったとき、前任者からの引継ぎ事項の中に「建物点検チェック表」の作成というのがあった。
引継ぎといっても潤沢に時間があるわけでもなく、実質「引継書」の説明だけで、あとは棚に保管してある書類を調べ、わからないところは電話で訊く、というのが我が社のスタイル(?)だ。
その引継の中で「建物点検チェック表」については、法定点検をベースにして作る、というはなしだったので、法定点検の点検結果報告書を元にチェック表を作った。
作る前に、方向性を上司と相談したつもりだったが、話がかみ合わない。
あとで気づかされるが、この上司は放任主義で、詳細な指示をしないタイプだった。
ともかく、こうして建物点検の仕組みが一つ出来上がった。
その仕組みが自分の首を絞めることになるとは思ってもいなかった。


点検チェック表は、誰が点検しても点検項目に漏れが無いように作るものだと理解している。
しかし、出来上がったチェック表は専門知識が無いと使えない代物だ。
それだけならまだ良いのだが、このチェック表は点検方法からすると、現場に持っていっても全く使えない代物になってしまった。
…何のためのチェック表を作ったのか?
とはいえ、作ったものは使うしかしょうがなくて、点検から帰ってきてから報告書とともに作成することになった。
それだけではなく、チェック表(と呼ばれるもの)だけでは不具合がわかりにくいので、不具合一覧表も別で作成することになった。
…何のためのチェック表を作ったのか?
もともと、清書のための書類は作りたくない、という上司の指導の下で作成したチェック表だったはずなのに、結果としては、報告書用に新しく書類を作ることになっている。
点検時に使用したチェック表を添付資料としてつけて報告する、という目的もあったのだが…。
結局作成する書類が増えただけだった。
残念。

respo

respo link

ZenBackWidget

 - 情報技術について