サーバントリーダーシップ
以前に不正確さは他人の仕事を増やす話を書きましたが、今回はその逆側の視点、すなわち、正確さを発揮することにより他人の仕事を減らすお話です。
上記エントリの説明により、仕事は実作業と同じぐらいに作業前の確認が大事だと分かりました。
不正確さが他人の仕事を増やすならば、正確さは他人の仕事を減らします。
しかし、作業前の確認作業は作業であるにも関わらず第三者視点からは作業にカウントされない悲しい現実があります。
さらに、分割された作業をまとめるコストやタスクのスイッチングコストも作業見積もりのコストには含まれない場合が多いと思います。
こういった目に見えないコストを陰ながら解消するのがサーバントリーダーシップです。
マスターではない使用人(サーヴァント)がリーダーシップを発揮するとはどういうことでしょうか？
サーバントリーダーシップにおけるリーダーシップは「自発的」という意味でのリーダーシップです。
チーム作業でゴールを目指すためには役職としてのリーダーがいるだけではなく、個々人のリーダーシップやプロダクトオーナーシップが必要です。
自分の携わっているサービスやシステムを自分のアイデンティティの延長線上にあると捉えるなら、それに対して良い方向に導いてあげたり(リーダーシップ)、ちゃんと面倒を見てあげる姿勢(オーナーシップ)を発揮するのは自然なことです。
そういったわけで役職上のリーダーだけではなく、メンバー個人個人がリーダーシップを持つことは不思議なことではありません。(ちなみに本来のサーバントリーダーシップの定義(？)はリーダーが持つべき特性であることは承知していますが、ここではその定義を踏襲しません)
そして、この個人ごとのリーダーシップがないと仕事全体を通して「正確さ」を発揮することはできません。
「お仕事」とは基本的に相手の求める価値を提供する作業のことです。
我々は価値提供の見返りに金銭を貰って生活しています。
そう考えれば仕事に従事する人は全て依頼主(マスター)に仕える使用人(サーヴァント)であると捉えることができます。
読んでいるあなたが経営者だったり投資家であったとしても経済の使用人であることに変わりはありません。
我々はみんな使用人なのですから、みんながみんな「別に、サーバントリーダーシップを発揮しても構わんのだろう？」ぐらいの勢いでリーダーシップを発揮してもらえれればと思っています。
作業者の仕事が正確になればなるほどバトンを受ける第三者の負荷が減って、それが全メンバーに波及していき、どんどん仕事全体の負荷も減って、巡り巡って自分の仕事も楽になります。
サーバントリーダーシップが一番発揮される場面がドキュメントです。
キングオブサーバントリーダーシップです。
ドキュメントは説明の自動化で書いたとおり、ドキュメントほど第三者に貢献する作業はありません。
しかし、ドキュメントは言ってみれば「他人の仕事の見える化」であり、自分のタスクが(ドキュメントを書くこと自体がタスクでないのであれば)解消されるわけではありません。
ドキュメントは自分の評価を捨てて他人の評価を上げる作業と言ってしまっても過言ではないでしょう。
まさに私利私欲を捨てた利他主義の極致と言えるぐらいの使用人らしい行動です。
ドキュメントを書く人はサーバントリーダーシップを遺憾なく発揮しているといえます。
次にリファクタリングです。
リファクタリングはプログラマー界隈の用語ですが「編集」と言い直してもいいかもしれません。
リファクタリングが何をしているかというと、コードを読みやすくしているだけです。
コードが読みやすくなるだけで、バグが直ったりはしません。(まれによく直ったり、はたまた新しいバグが生まれたりします)
処理が高速化したりもしません。(たまに副次作用で速くなるときもあります)
もちろん、売上が上がるわけでもありません。(これは残念ながらどう転んでも上がりません)
ではなぜ一部の人々はリファクタリングをし、さらにその作業を啓蒙するのでしょうか？
これもサーバントリーダーシップの発露だと考えることができます。
リファクタリング作業は自分に対する利益はほとんどありません。(将来の自分に対してはあります)
ですが、その後にコードを触る全ての人に対して作業効率化の恩恵を与えています。
先程のドキュメントと同じように現状の自分のコストを支払って将来の自分を含めた自分以外全員をアシストしています。
ドキュメントが自分の評価を捨てて他人の評価を上げる作業であるならリファクタリングは自分の評価を捨てて他人の作業効率を上げる作業であると言えます。
リファクタリングに限らず「分かりにくいものを分かりやすく表現する」「曖昧な表現を減らし言葉の定義付けを行い正確な表現を心がける」などのように、人から人に情報を正確に伝達しようとする姿勢はサーバントリーダーシップがないとできません。
また、テストの実践もサーバントリーダーシップの発露といえます。
「テスト」もプログラマー界隈の用語ですが、一般的には「確認作業」と雑に解釈してもらっても問題ありません。
テストは自分の作業がちゃんと問題がないことを「確認」するために行うからです。
テストそのものはプロダクトとは別で、システム利用者にとってはあってもなくてもなんの違いもありません。
それでもテストをする理由は自分の仕事の結果を正確なものとしたいからです。
自分の成果物をより正確なものにすることにより他人の余分な仕事を増やさないようにするためのアプローチなのです。
他人に対する貢献作業という意味で(自分から進んでテストを行う場合においては)サーバントリーダーシップを発揮した結果といえます。
しかし、こういったサーバントリーダーシップはKPIのような業務評価指標には反映されないことが多いです。
そのため、他人の仕事の見える化はされても、正確さによって減らした他人の労力は見える化されません。
存在する実態は観測できても現実として起きなかった実態は観測できないのです。
業界のよくある愚痴として「問題が起きてからどれだけ頑張って解決したか」は評価されるけど「問題が起きる前にどれだけつまらない準備をしていたか」は評価されないことがあります。
今まで24時間ずっと安定稼働していたのにいざ障害が起きたときにだけ文句を言われ、安定稼働していた事実に関してはなんの感謝もされない、といった現実があります。
しかし、みんなの目に見えないところでサーバントリーダーシップを発揮してくれている誰かのおかげで仕事がなんとかまわっている現場も多くあることでしょう。
そういったサーバントリーダーシップに報いないからデスマーチが起きてしまうのです。
みんなが忙しいのはみんなが不正確な仕事をしているからです。
各々がサーバントリーダーシップを発揮することにより作業に「正確さ」をプラスアルファで付け加えれば、自分ひとりだけではなくみんなの仕事も速く回るようになるでしょう。