「精度」を理由に拒む抵抗勢力への対抗策 〜朝起きることが出来ないのは目覚まし時計の正確さではなく、習慣化の問題〜
今となっては昔のことですので時効になるかと思います。職場にて、ややずさんであった開発者の工数管理を進めようとしたときのことです。得てして、ソフトウェアの受託開発の見積もり精度は、同業者でも頭の痛い問題かと思います。比較的大きめの案件になればなるほど、土壇場にてバタバタするのはどの会社でも似たり寄ったりでしょう。
どの程度の工数を割いたのかを計測し、記録として残し、そして、レビューすることで見直すべき点を整理し、次回の開発の取り組みへ活かす活動は、一般的なものづくり／製造業では、極々普通に行われていることです。このＰＤＣＡ（個人的には、ＰＤＳＡのほうがベターだと思っています）サイクルも、習慣がない環境では何かと批判の的というか、抵抗勢力が現れます。
そもそも、「管理はあまりしたくない」と思われる上級管理職の方も少なくないと思います。しかしながら、ここで指している「管理」は、経営学で指す管理システム（management control sysytem）であり、「計画立案し、その程度を計る指標を決め、実行し、測定し、修正活動として直し、それを評価する行為」であり、まさにＰＤＣＡサイクルを回すことにあります。あくまでもですが、この定義に準ずれば、組織の上として「計画は立てたくないし、レビューとかやだね」と言っていることと類義になると言えるかもしれません。
また、この手のものになると、特にＩＴ系エンジニアに顕著に見られるように感じますが、０／１での議論になってしまう点が残念でなりません。要するに、やるということは絶対的な物差しで寸分違わぬ精度で万人にとって公平な物差しにて計測を行うということと解釈され、やりたくない派つまり抵抗勢力の格好の餌食となってしまうのです。抵抗勢力が指す不完全な状態であれば「やっても意味がない」との尺度の精度をエクスキューズにした反対意見です。堅い表現でいうならば、「絶対的測定妥当性の提示とその保証」を求めてきます。
とは、いうものの、案件納期直前にて、疲弊を募らせるのはまさに現場／本人であることも言うまでもありません。「見積もりの精度の甘さなどもあり、案件に対する工数の把握は必要だろう」との流れは出来ていました。
当時、私は抵抗勢力の方々へ次のように説明／口説きました。
私「まず、身の丈を知らずして、今後、どうすればいいのか、分からないのでは？」
私「そのために、まず、ざっくりでもいいので、どれだけのエネルギーを割いているのか、記録してみないか？」
開発行為に割くエネルギーを測るといっても、○○キロカロリーなどど消費エネルギーを計測することはあまり意味はないでしょう。また、この手のものになると、人によってソフトウェアの開発効率に大きな差があることも事実でしょう。
そもそも、開発への工数の把握が必要であろうと行き着いた根拠は、複数のメンバーが参画するプロジェクト案件に対して、納期直前の深夜／休日対応の多さに対する解決策としての気付きが得られないか、より正確に指すのであれば、「自身らにて何か考えた方がいいのでは？」と考えさせることにありました。そのため、比較的好き好んで進める個人ベースでガツガツ進める案件などは、目的の主旨としては、その中心として含んではいなかったのです。
ただし、工数を測るにあたっては、結果的にほぼ全員が何らかの案件に関わる以上、ある程度組織として一括してやらざるを得ない面もあるかと思います。
全体として用いるその尺度として、時間が最も分かりやすいとの議論もありましたが、深夜／休日対応に加え、移動時間など考えている時間はどうするのか？等、徐々に非常に細かな指摘への対応を検討せざるを得なくなるのではとの懸念も出てきました。無論、その背景として、時間をもってして、人事考課への判断材料となるのではとの懸念が大きく影響していたこともあったでしょう。（実際には、直接的な材料にはなっていなかったと思いますが）
結果的には、数期の見直しを経て、今では「１週間に費やしたエネルギーを１０とする」と非常にざっくりとしたな尺度として、計測することとしています。この尺度については、「非常に曖昧で報告できない」「時間外の負荷が十分加味されていない」と抵抗勢力の非難を浴びましたが、次のように投げかけました。
私「精度に関しては、指摘の通りかもしれない。でもね。まず、自分たちのやった仕事の記録を付けるという習慣付けもできていないのに、精度のことで指摘するのはどうかな？ まずは、習慣付けをしてみないか？ で、やってみて、３ヶ月でも半年でもね、それで、集計してみて、精度として、とんでもなくずれているか、見てみないか？」
ざっくりとした「１週間に費やしたエネルギーを１０とする」方式は、最小単位を１として、少数は抜きとしました。ある人は、月〜金を午前と午後に分けて、１ずつ割り振ったイメージだったかもしれません。客先訪問など、開発以外のイベントをさっぴいて算出したメンバーもいたかもしれません。
結果としては、このざっくり方式も、「実感と出て来た数字にそんなにズレはない」との意見が大半となり、以降、このやり方で進めています。この「１週間に費やしたエネルギーを１０とする」方式が絶対量としての工数になっているかいないかについては、その期間のメンバーの定時後の対応の状況を目にしているリーダーは、十分把握しているはずであり、２割増しで考えるべきか、５割増で考えるべきか、額面通りでよさそうかは、リーダーの力量にゆだねるものです。
結果として、得られたざっくり工数を、まずは客観的にさらけ出す一つの指標としてメンバーに提示／提供し、自らが進めて来た開発行為に対して、自分達で判断する材料になればよいでしょう。むしろ、参画したメンバーにて十分なレビューが出来れいれば、他の部門もしくは直接的に関係のないリーダー相当からガチャガチャいわれようが、それはありがたいお言葉として、ちょっと片隅においておけばいいだけのことでしょう。（年の功で、いろいろ物事を言いたい人はどこにもいますので、言わせてあげる機会を提供してあげたと思えばよいでしょう。）
数年前までは、やややりっ放し感のあるソフト開発も、今ではこの工数実績の方法にて定着しています。
朝、決まった時刻までに起きることが出来ない最大の理由は、果たして目覚まし時計が電波時計ではないからなのでしょうか？ 無論、目覚まし時計の時刻がずれていて、目覚まし時計のベルで起きたが、結果として遅刻してしまうことはあるでしょうし、少なくとも、過去にはそんなこともありました。
しかしながら、往々にして、毎日、毎朝、朝起きることが出来ない理由は、時計の精度の問題ではないと思います。日常、生活にあたり、自らが選び使用する時計ですので、多少のズレがあろうとも許容の範囲でしょう。（私自身、腕時計は運動をするとき以外は大抵は自動巻か手巻きですので、２〜３分ずれていることは極々当たり前のことです。それでも、使用しているのは、別に括弧が良いからではなく、その時計をしながら生活／仕事をする上で、そのズレを許容範囲として自ら受け入れることができるからです。ですので、資格試験などの日には、ジョグのときに使用するデジタル時計を持っていきます。普通の生活にて許容できる時間のざっくり感、堅い表現で言えば、粒度が許容できないからです。）
精度／粒度の話は、何事にも習慣となってからの話であり、習慣にもなっていないのであれば、そのような話はむしろ抵抗勢力の言い訳に過ぎないと思います。
抵抗勢力から、「精度」を理由に批判されるとき、真っ向から立ち向かうよりは、むしろ「精度は二の次」として「習慣化」から口説くのも一つの方法かもしれません。