みなさん、こんにちは！ タカハシ(@ntakahashi0505)です。
日本企業は何かをはじめるのは得意だけど、終わらせるのが苦手とも言います。
「ずっとやっているけど、この業務意味あるのかな…？」
そう思えてしまうような形骸化している業務、けっこうあるのではないでしょうか。
今回は、「どうすれば形骸化した業務をやめるという判断ができるのか」考えてみたいと思います。
では、行ってみましょう！
あるある形骸化業務ベスト3
定例会議
まずひとつは定例会議です。
一日のスケジュールの中に、会議がたくさん詰まっているとやっている感がすごい出ます。
しかし、中身をきちんと見ていくと、ただの進捗報告に終わっているケースや、上司からのカタチばかりの指導だけで何も進捗していないということはよくあるものです。
最近は1on1も流行っていますが、形骸化していることが多いと聞きます。マネージャーにとっては人数分だけ大量に時間がロックされてきついですよね。
報告業務
報告業務の多くも形骸化しているように思います。
小さなものでいえば毎日の日報はよく形骸化している業務として見かけます。
毎日同じようなコメント書いて報告している方、多いのではないでしょうか。
マネージャーのほうも、毎日×メンバー分をきちんと見て、判断して、ときにフィードバックするのは大変ですよね。提出だけ確認している、場合によっては見てもいないということもあるのではないでしょうか。
また、大きなものでいえば会議や報告のための資料作成もよく形骸化しています。
現場の担当者は毎週かなりの手間をかけて資料をつくるものの、その資料がどのような議論にどのように使われたのか、現場にフィードバックされることはあまりありません。
そのくせ、「次からこれも欲しい」という依頼が時々発生するので、どんどん内容が追加されていき、削られることはありません。
承認手続き
もうひとつが承認手続きです。
本来、部門長だけで良かった決裁が、何か問題がおきたことをきっかけに、全部門の部長がハンコ押すことにしようと承認手続きが増える方向に変更されることがよくあります。
また、承認のための新たな申請書を増やしたりというのもよく見かけます。
リスクを避けようとすると、どんどん膨らんでいくのが承認手続きのプロセスです。
やめるのが難しい業務の共通点
関係者がいる業務は辞めづらい
定例会議、報告業務、承認手続き…これらの業務を眺めてみて、ある共通点があることにお気づきでしょうか。
それは、関係者がいるということです。
つまり、関係者がいる仕事は辞めづらいのです。
ある業務について、自分ひとりにすべての裁量があるのであれば、さっさとやめることができます。
しかし、そこに関係者がいるのであれば、それら関係者に説明が必要となり、やめてよいかおうかがいを立てなければいけなくなります。
説明やおうかがいは面倒ですし、関係者一人ひとりの顔を思い浮かべて「あの人は反対しそうだな」と思えた時点で、やっぱやめておこうとなりがちです。
形骸化に対してリーダーがすべきこと
リーダーがトップダウンですべて判断すればいいというアイデアもあります。
しかし、末端のすべての仕事を把握して、その必要・不必要まで判断するリソースはまず捻出できません。
では、どうすればよいでしょうか。
リーダーシップを個別の案件から組織づくりに向けることができます。
個々の案件にリーダーシップを発揮するのではなく、現場の裁量で判断と、やめるという行動がとれるような組織づくりをすることにリーダーシップを発揮することができます。
案件ごとの関係者が多いなら少なくする、判断プロセスが複雑ならシンプルにする、現場の裁量が少ないなら多くする…そのような組織づくりです。
リーダーがソフトウェアを学ぶべきもう一つの理由
密結合と疎結合
その点、参考になるのがソフトウェア設計の考え方です。
ソフトウェア設計でも、ユニットごとに、良し悪しを判断して、ユニットごとに改善をする、それをスピーディに行えるのが理想です。
しかし、ユニットごとの関係性が複雑で、絡まりあっている状態（これを密結合といいます）だと、ユニットの良し悪しの判断や改善の難易度が上がります。
たとえば、Aというユニット、もっとよりよい処理に変更できそうだから、プログラムを修正したいと思ったとします。
しかし、Aの動作には、どうやらBとCとDという他のいくつかのユニットが関連し合っているらしいことがわかりました。
Aの変更が、BとCとDに影響を与えないか、検証と判断が必要になってしまいます。
それであれば面倒だからやめておこう、目先に必要な追加のプログラムを先に着手しようという判断になります。
こうして複雑で絡み合った古い部分は取り残され、そこに新たな要素が追加されていってしまいます。
一方で、良いソフトウェア設計は、ユニットごとを個別に判断、改善しやすくなるよう、他のユニットの関連性を下げます。これを結合度を下げる、疎結合にするなどといいます。
BとCとDの影響がない、もしくは少数で明確であるなら、その部分だけ検証すればよくなります。
これ以外にも、ソフトウェアの世界には、ソフトウェアの複雑性を下げ、改善がしやすいようなノウハウがたくさん蓄積されています。
コンウェイの法則
さらに、これに関連した面白い法則があります。「コンウェイの法則」といいます。
このような法則です。
組織がつくるソフトウェアの構造は、その組織のコミュニケーション構造にそっくりになる
たとえば、複雑に絡まりあった組織がつくるソフトウェアは複雑に絡まりあったものになり、シンプルで個々の役割が明確な組織がソフトウェアはシンプルで個々の役割が明確なものになります。
つまり、複雑性に立ち向かうためのソフトウェアの知識は、組織づくりに応用できるのです。
このDX時代において、リーダーがソフトウェアを学ぶということは、この点でも大きな意義があると思います。
まとめ
以上、「どうすれば形骸化した業務をやめるという判断ができるのか」についてお伝えしました。
引き続き、みなさんがいきいきと学び・働くためのヒントをお届けしていきます。次回をお楽しみに！
この話を耳から聴きたい方はこちらからどうぞ！
