「有識者」に頼らない仕組みを作る

様々な社会、様々な企業、様々な現場でよく聞こえてくる

　「有識者」

という言葉。
昨日、属人化について書きましたが、要するにそれって「有識者」依存しているということでもあります。一般的に、有識者と呼ばれる存在は、組織の中でも少数です。大多数が有識していれば、「有識者」という呼ばれ方はしませんから。

だから、有識者を作り、有識者に「有識者じゃないとできない仕事」を押し付けると、

　①場合によっては、有識者の業務が過剰に膨れ上がる
　②有識者が業務のボトルネックになる
　③有識者がいなくなった途端、業務のパフォーマンスが地に落ちる

という状況を招きます。有識者は、その存在のありがたみと同時に、有識者でない人の甘えと、それに伴うリスクを招き寄せる諸刃の剣であると言うことを、利用する側は知っておかなくてはなりません。

「有識者」の利用とは、言ってみれば先行きの見えない株運用などと同じです。常に状況・状態を監視し、適切に取り扱っていれば、いくらでも甘い汁は吸えるかもしれません。ですが、一般的に「有識者」に頼り切った運用しかしない組織は、"丸投げ"する傾向にあり、状況や状態の適切な監視を行っていませんので、

　・有識者の努力や貢献も見ていないから評価が変わらない
　・有識者がパンク寸前になっても気づかない、あるいは対策を打たない
　・有識者が倒れたり、退職したりしてから、慌てだす

と言った問題を引き起こします。

まぁ…そもそも社会に出て、それでも他人にもたれ掛かって甘えるだけという精神がもうすでにどうしようもない気がしないでもないのですが、そうした事例には事欠きませんので、居るところには居ると言うことでしょうか。

「有識者」であるか否か

それは、真面目に取り組み、情報を整理して、自分の知識として取り込んだ者の総称です。逆に「有識者ではない」人と言うのは

　・新参者で、経緯や情報の整理が途上にあり、追い付いていないもの
　・情報を整理して、理解する努力を放棄したもの

のいずれかとなります。有識者になるための努力を続けていて、まだそのレベルに至っていない人は仕方のないことですが、後者の場合はもう色々社会人あるいは組織人としてアウトです。得手不得手があって、他に得意としているもので貢献しているというのであれば、それはそれで一つの有識者と言えるかもしれませんが、そうでもないなら、いったい何の権利があって他人（有識者）を利用しているのでしょう。

そうして「有識者」にもたれかかって、すべてをゆだねてしまうと、責任や仕事量を、

　"押し付けるもの"と"押し付けられるもの"

に大別されていくようになります。
そうやって、一部のまじめに働く有能な人材に対して過重労働偏重を容認するようになっていくと、人は疲弊してしまったり、退職に追い込まれたりすることになったりするわけです。

なにより、押し付ける側で気楽に過ごしてきた人たちは、その"有識者"がいなくなった途端、無能者の集まりとなってしまい、チームとしても、組織としても破綻してしまいます。

有識者に頼るのであれば、なによりも有識者を丁重に扱っておかなかければなりません。

やはり、大切なのは「仕組み」

そういった危険な組織や環境を作らないために、「仕組み」が必要になります。仕組みには、遵守すべき『ルール(基準)』と、徹底すべき『プロセス(手順)』があります。この双方を定義し、運用できるか否かが、責任者あるいは管理者と呼ばれる人の能力の見せ所となります（もうワンランク上の人なら、責任者や管理者がずっと定義・運用を切り盛りしなくても、惰性でサイクルできるようにすると思います）。

しかし、仕組みとか、プロジェクトマネジメントとか堅苦しいことを言われても、まず、何から手を付けていいのかわからないでしょう。

たとえば、「働き方改革」と言われても、

　「残業規制以外、何をすればいいのか…」

と言う多くの企業と同じことになるはずです。
この「働き方改革」と同じレベルの言葉を用いるのであれば、仕組みの構築改革とは

　　　　　　　┌──→②働き方の改革→──┐
①働きやすさの改革　　　　↓　　　　④働いた結果の改革
　　　　　　　└──→③進め方の改革→──┘

と定義することだと私は考えています。

①作らせやすさの改革

これは、環境の改革です。
もちろん、物理的な意味だけではなく、人間関係を含む、全体的な環境改善です。

たとえば、どんなに有能な人物で、結果を出してきた人でも、必ずしも「指導」できる人材とは限りません。そんな人が上司になると、部下が成長しないばかりか、どんどん辞めていくだけで、組織にとって害となることもありうるのです。

今までやってきたこと、顧客や上司が指示すること、それらはみなさんにとって、開発しやすい条件が整っていますでしょうか。あるいは、そう言った観点で世の中にどんな働きやすい環境があるかを知らずに、何となく開発していたりしないでしょうか。

環境を整えようとせず、いきなり②の働き方（ルールやプロセス）で縛ろうとすると、必ず負担が増えます。そもそも、今の環境下で最適化された働き方となっているのであれば、環境がついてこない中で働き方だけ変えても、従業員にとっては、負担にしかなりえません。

それは働きやすさとは180度異なる結果となってしまうことでしょう。
過去多くのブラック企業は、何一つ環境を整えずに従業員に無理を強いたから、ブラック企業となったのだと、私は思います。

②作り方の改革

みなさんの仕事では

　どのような手順があって、
　どのようなアウトプットを残して、
　どのような確認の仕方で

仕事をしてきたでしょうか。
それは、誰がやっても同じパフォーマンスが出るようなルールやプロセスが明確になっていますか？ベテランでも、新人でも、最低限引き出せるパフォーマンスは同じになっていますか？

もし、人によってまったく結果やパフォーマンスが異なるのであれば、それは非常に属人的で、チームや組織として確立されていないと言うことです。
まだ"個人事業主の集合体"でしかありません。

作り方の雛形を用意し、最低限度のことは誰がやっても同じ結果となるように標準化することは、体系(業務標準)を定めるのと同義です。

③進め方の改革

プロセスを効率的に進めるためには、進める順番や関連性、情報の共有方法などを明確にし、チームや組織内において、ある組織活動に対して困ったり、悩んだりしないようにしなければなりません。

そのための引率役として、「人」ではなく「ルール」や「プロセス」が誘導するのが、この『進め方』であり、即ち『マネジメント』となります。

引率、けん引、誘導などによって、あらかじめ用意された道を整備する仕事ですから、新人では無理かもしれません。ですが、『先輩』という肩書を持ってしまえば、少なからず若年層でも可能なはずです。

まさか、後方にふんぞり返ってあーだ、こーだ指示を出すだけの人が偉いというわけではありませんから、有言実行、率先躬行し、後輩や部下に道を示して成功を経験させるというのはとても重要なことなのです。

④働いた結果の改革

こうして①②③が用意され、その仕組みに従ってモノを作ってきたからこそ、初めてその「結果（成果）」が妥当であるかどうかを第三者が評価できます。

一般的な製造業における品質保証も同じようなことが言えます。

　①作りやすい環境を整える
　②作るためのルールや方式を定義する
　③作っていく手順を明らかにする

その通りに進めた結果として、できたモノの検証結果に正当性がついてきて、正当性があるから、論理的に正しいものであると証明することができるのです。仮に、東大入試の試験で、あてずっぽうで答えだけ書いて、途中式も何も書かなかったら、点数は０点になるのと同じことです。

ソフトウェアの品質も、最後の最後だけ、正しく動いているように見えたら正しい…と言うわけではありません。"正しい手順で作った"結果として、"正しく動く"から「正しい」と証明できるのです。

　「有識者が正しいと言ったので、大丈夫です」

なんて説明をユーザーにすることは決してありません。

ソフトウェア開発では中途半端な有識者が失敗を引き起こす

この全体のあり方を理解しないエンジニアたちが、適当に我流でモノを作って、「思った通りに動けばＯＫ」と言って開発してしまった場合、時として、大きなトラブルをおこしたり、ちょっとしたミスがでた時に、「他には問題が無い」ことの説明ができなかったりして、延々とムダな工数を使い続けることになります。

そうなったときに"我流"で進めて失敗を引き起こした自称"有識者"のエンジニアたちに、

　「なぜ、それでいいと思ったのか、その根拠は？」
　「でも、それで失敗してる以上、おそらくその根拠は誤りだよね？」
　「で、結局、責任はとれるの？」
　「自分たちで、最後まで後始末できそう？」

とやんわり聞いてみてもと、何一つ具体的な回答を得られることはありません。"我流"に自信があった以上、それ以外の方法は検討していないでしょうし、自称有識者の頭の中では正しいと思っているため、出てくるのは「言い訳」ばかりの方が多いためです。