できるリーダーは「仕組みを作って満足しない」

業務ルール、新人用マニュアル、チェックリスト、メール送付時のルール、ファイルやフォルダ管理のルール、ミス報告書、見積書のフォーム、請求書発行システム…。

これらのルールやマニュアルなどの仕組みは、メンバーの業務を効率化し、業務レベルを標準以上にするために存在している。あるいは、コンプライアンスの観点から、会社やメンバー自身を守るため、というケースもあるだろう。ここで、できないリーダーは、「仕組みを作って満足」してしまう。

※本稿は、吉田幸弘 著『リーダーの「やってはいけない」』（PHP研究所）の一部を再編集したものです。

なぜ、仕組みを作っても問題だらけなのか？

たしかに、これらの仕組みは構築するだけでもひと仕事です。しかし、仕組みは運用しないと何の意味もありません。

　たとえば、仕組みを作っただけで満足しているリーダーの下では、次のような問題が発生します。

・業務ルールの「形骸化」

お客様から注文を受けた場合、生産管理部に当日17 時までにメールすれば、3営業日後に倉庫に納品される。しかし、ベテラン営業マンの中には、締め切りの時間を守らなかったり、ゴリ押しして2営業日後の納品にさせたりするケースが多発している。

・ミス報告書の「形骸化」

細かなミスもメンバーで共有する仕組みを設けたのはいいが、ミスを報告することに抵抗があり、きちんと提出されていない。むしろ、メンバーの中に、発生したミスを隠ぺいしているケースが見られる。

・「本末転倒」な見積書のフォーム

見積書の作成時間を削減するために、見積書の共有フォームを作ったが、エクセルの関数がきちんと反応せず、結局手書きで修正しているため、各々が見積書を独自に作成していたときより、時間がかかってしまっている。

これらの問題の共通点は、仕組みを作った後に、リーダーが事態を把握していないために、メンバーに不利益が発生している点です。しかも、部下はルールの改善などは提案するにもハードルが高いため、問題が放置され、チームの生産性は低いままとなってしまうのです。