💯

仕組みか個人か、という不毛な論争の答

に公開

しばしば、なぜなぜ分析などの文脈で「仕組みか個人か」という不毛な論争が生じます。何かのトラブルがあった場合などに、仕組みの改善を図るか、個人の改善を図るか、といったような話です。
これについて、自分の中で「メカニズムも含めて」どういう判断をすべきかの結論が出たので、それを記します。つまり、どちらの改善も否定せずに、かつどのように仕組みの改善・個人の改善を選ぶべきか、という指針を述べます。
一言でいうと、以下のようなことです。

熟達(個人の改善)に必要なコストが暗黙的に発生するので、仕組みに倒す事が最適な場合もあるが、一方で個人において記号接地していない仕組みは次に繋がらないので、成長や深さを求めるには個人の熟達が必要である。この構造を理解して改善を選択・設計する。

仕組みか個人か、という問題の構造

この問の背景にある構造とその答についての骨子を述べます。具体例を先に読んだほうが頭に入りやすいかもしれません。

  • 個人の改善とは、つまり熟達を意味する
  • 「仕組みか個人か」という問いは、仕組みの改善か熟達か、と解釈できる
  • 仕組みの改善と熟達は必ずしも相反するものではない
    • もし可能かつ効果的なら両方のアプローチを考えるべき
  • 仕組みの改善も熟達も、リスクを厳密にゼロにすることは難しい
    • したがって、定量的にどれぐらいのコストでどれぐらいリスクを下げるかによって判断すべき
    • 例えば車を使う限り、どんな仕組みでも事故のリスクは厳密にゼロにはならない
      • 車を使うことの恩恵と事故リスクを天秤にかけて我々は生活している
  • 熟達には時間コストがかかる、誤った道を進むと熟達はできず、かつ熟達に近道はない
  • 熟達圧をかけすぎると人間は耐えられなくなる
    • いきなり熟達はできず、熟達の過程は苦痛を伴う
    • 苦痛や時間コストを感情的に過大評価してしまうケースがある
  • 仕組みによる改善は、しばしば個人の理解や熟達を必要としない
    • 極端な言い方をすれば、理解・記号接地していなくても失敗しない状態になる
  • 仕事の深さ、あるいは継続的な進歩を求めるには記号接地・熟達が不可欠である
    • 職人的な仕事が必要な場合には、仕組みだけでは原理的に到達できない
      • 熟達にあたっての仕組みの有効性を否定している訳ではない
    • 例えば車の運転の場合、教習所などを通じて一定の熟達が必要となる
      • 一方シミュレータや教習、あるいは道路交通法という仕組みも熟達に貢献している
  • 熟達には時間がかかるので、熟達を必要とする仕事は自然とできる人が限られる
  • 仕組みで改善するか熟達で改善するかは、その仕事および延長となる仕事に必要な深さで判断する
    • もちろん、どちらか一方に限定するものではない
    • 熟達がコストを必要とすることを踏まえて、仕事をどう設計するかということ
  • コーチ役となる人は、過負荷を避け適切な負荷を与えて個人を熟達に向かわせることで効率化できる
  • これらの事を、それまで考えたことがない個人が考えるのは非常に難しい
    • 例えば、なぜなぜ分析の誤用による「事故」が発生しがち
    • しかし、こうした事を考える練習をしなければ、その能力はいつまでも身につかない
      • こうした認知を持つこと自体の練習が必要となる
    • このような取り組みについてもコーチの存在が効果的である

具体例で理解する

自動車の運転

自動車を運転するとき、事故のリスクはゼロになりませんが、人や物を運ぶことによって生じる対価は大きいため、リスクとコストを天秤にかけた結果として日常的に運用されています。
自動車の運転には、まず道路交通法という仕組み・決まりがあり、その枠組の中で運転免許などの仕組みがあります。運転免許は一定の熟達が認められた人に対して発行されるものです。個人の熟達を促す仕組みや、罰則も定められた法律や、その他物理的に事故や被害を少なくする仕組み(滑りにくいブレーキ、ガードレールの敷設)などを組み合わせて、最終的に仕組みと個人の熟達の双方で、なるべく事故の少ない状況を作ろうとしています。今のあり方がベストということはなく、今後も状況に応じて方法が改善され続けるでしょうが、これまでと比べてベターではあるでしょう。
最終的に「個人の熟達を促す仕組みや、個人の熟達を必須とする仕組みになるまで仕組み化が行われる」という意味で仕組み化が必須というのは正しいですが、一方で 根本的に一定の熟達が必要である という構造もあります。仕組みで解決するか熟達で解決するかというと、結局両方の要素が必要である、ということです。
この熟達を促すうえで、自動車の場合は教習という仕組みがあります。自動車の教習には一定のコストが発生することに注意します。

自転車の運転

自転車の運転はどうでしょうか。軽車両である自転車は、ある程度自動車に近い扱いを受けていますが、免許は必要ありません。自転車にも免許を導入する議論はありますが、自転車の免許を発行して確認してというコストと、それに対する一般市民の反応を検討すると、現段階ではコストや心理的負担に見合っていない(と考えられている)ということなのでしょう。あるいは、他に優先して対応すべき課題がある、ということかもしれません。
一方、その扱いに一定の熟達が必要であることは明らかです。単純に自転車を動かすにも練習が必要です。全く自転車を練習したことのない人が自転車に乗る練習をする場合しばしば苦痛が伴いますが、それに耐えて練習する必要があります。また、安全に運転するには運転技術だけでなく個人が道路交通法や慣習を理解することも必要です。車道の右側を走行すると事故のリスクが高まります(法律にも違反する場合があります)。
現在の状況を改善するためには仕組みを改善することが必要ですが、個人の一定の熟達は必要であり、また今後もし免許が導入されたりした場合には 個人が最低限到達すべき熟達の水準が上がる ということになります(理由なく日常的に車道の右側を走行する人は自転車を運転できなくなる)。

システムの開発

では、システムを開発していく場合はどうでしょうか。システムを開発する際にも法律で決まっていることはありますが、システム開発そのものを事業領域によらず包括的に対象とする法律というものはほぼ存在せず[1]、開発するシステムが実際に運用される個別領域の法律にシステムも従う必要がある、というのが現状です。
したがって、開発全般という括りで国のレベルで強い強制力のある仕組みは少なく、実際の開発プロセスについては個々のチーム内で規定されることになります。そのため個々のチームにおいて仕組みづくりを検討する必要があります。自動車の運転のような物事については、ほとんどの人は法的な仕組みの改善を考えて実施するということはありませんが、システム開発においては個々のチームで仕組みの改善を考えて運用することが必要 なのです。

継続的な熟達

ここで、事業が成長していく場合、あるいは世の中の新しい技術や法律の変更などがある場合には、仕組みもまた動的に変化していくことが必要です。そうすると、他の例と同じように、熟達をどれぐらい求めるべきかを考えながら仕組みを作っていく必要があります。特に重要なのは、システム開発の分野によっては継続的な熟達が必要になる 、ということです。これは開発そのものについてもそうですし、事業領域に関する知識についてもそうです。深い仕事を求めようとすると、熟達は不可欠となります。システム開発以外の一般論として、高度に熟達した職人の深い仕事を再現しようとすると普通は熟達が必要になりますが、それと同じようなことです。[2]

これを踏まえて、たとえばシステムを開発する中でトラブルが発生した場合を考えてみましょう。トラブルの恒久対策として、仕組みと熟達の双方で検討が発生します。トラブルの種類によっては仕組みだけで対応することもあり得ますが、単純に開発者の熟達が必要なケースも多く存在して、そのような場合には教育やその他熟達を促すことも必要となります。実際、制度的な部分において、技術の一部を問うような試験はあるにしても、開発の絶対的な免許というものは存在せず、また事業領域の知識も含めて開発者の知識を担保するような仕組みはほぼありません。
これは知識のない開発者が「悪い」という意味ではありません。もちろん知識の内容や不足量にもよりますが、事前に必要な知識を完全に列挙することは難しいです。知識がなかったことを必ずしも悪とは捉えずに、柔軟に新しい知識を獲得する・熟達していくという姿勢が重要になります。[3]

熟達圧への注意

開発の業務では働きながら熟達することが必要となります。働きながら熟達するということ自体は、他の職人として働くような仕事では特に当たり前のことですが、ここで一般的に注意すべきことは過剰な熟達圧(熟達することへの要求)です。
熟達の過程は、多くの場合は楽ではなく、一定の苦痛を伴います。あまり強く熟達を要求すると苦痛の量が限界を迎えてしまうため、適切な圧になるようにコントロールする必要があります。

熟達を要求するということは、その仕事をできる人が減るということ

熟達を要求することについてのもう一つの注意点は、その仕事をできる人は設計上少なくなる、ということです。つまり、熟達するには一定の時間をかける必要があるので、仕事に対して熟達を求めると「今すぐそれができる」という人の数は少なくなります。システム開発の場合、例えば高度な技術を要求すれば今すぐそれをできる人の数は減る、ということです。これは狭義の技術に限らず、事業領域への知識なども同じ構造があります。開発者が事業について理解する必要がある場合は、当たり前ですが、その教育のコストが必要となります。

熟達水準の設計

仕組みで解決する、という方法は熟達と比較してしばしば対照的です。例えば、仕事を分割して易しくすることによって、教育コストが下がり多くの人が仕事できるようになる、といったケースがあります。ただし、このような場合、分割された特定の仕事の経験しか得られずに一人ひとりの熟達度合いが下がる可能性もあります。そうなると、仕組みでの解決に寄せた場合、確かに今の時点での仕事そのものについてはスケールするとしても、今後深い仕事を求めることになるとむしろスケールしなくなる可能性もあります。仕組みか熟達か、という選択がひいては事業の継続性やスケールの方向にも影響するということです。 これは非常に重要な観点で、それなりの品質を担保して大きくスケールしていくようなビジネスを展開するのか、より高い品質を目指しながら職人的な技術も含みつつ高度なビジネスを展開するのか、という方向性も踏まえて仕組みか熟達かの答を選択・設計すべきということなのです。検討の順番としては、ビジネスに必要な熟達を考えたうえで、そのための仕組みを設計検討する、ということになるかもしれません。

誰が熟達の設計を考えるのか

このような熟達の設計を考えるということは、おそらく多くの人は検討したこともないことで、つまり、まずこの設計への熟達が必要になります。それは容易なことではなく、たまに失敗する上に、いくつかの参考書はあるにしても、これと決まった教科書はないように思います。
でも、少なくともそれがチームの仕組みづくりを考えるうえで必要なことだと認識して、チームとしてどのような熟達の姿を目指すかを考えることは、非常に重要なことです。最終的な判断は別にして、熟達の設計・チームとしての熟達のあるべき姿を考え、その実現に向けて各人が行動していく、というあり方が望ましいと私は思います。そのために、ここに書いたような仕組みと熟達のメカニズムを理解しておくと、判断がしやすいかなと思っています。

マネジメントにおいてコーチングが求められる理由

このような熟達の構造が、マネジメントにおいてしばしばコーチングが求められることの理由となっています。つまり、メンバーの熟達が必要な場面において、効率的に熟達できるようにコーチングする機能がチームに必要になる、ということです。通常、メンバーに求められるチーム内での役割・機能性を一番理解しているのはマネージャーなので、必要な役割・機能性を目指したコーチングを行うことになります。
一般論として、組織全体において熟達が不要になる場面はおおよそ存在せず、誰かしらは熟達や成長を要する仕事をすることになり、そのメンバーの熟達を促す存在が必要になるのです。

むすび

仕組みか個人か、二項対立ではなくて、熟達の設計 という観点で考えていきましょう。
ChatGPTによると、以下のようにポイントをまとめる事ができます。

  • 仕組みは熟達を補うが、熟達を代替できない
  • 熟達を要求することは事業の方向性を決定する
  • マネジメントは熟達を設計・支援する役割を担う

各人が成長しながら成果を挙げ続けるような組織を作るためには、ここで述べた考え方が本当に大切だと思います。
感想などあれば、ぜひコメントに残すなどしてお伝えください。

脚注
  1. 開発を受託する場合の契約についての法律やプログラムに関する著作権などはあるにしても ↩︎

  2. 職人の仕事を観察したうえで、パラメトライズしてシステム化したり、あるいは機械化したりして同等以上の成果を出せる場合もありますが、そのような仕事は前提となる職人の熟達があって成立しており、職人の協力なしで無の状態から素人が同等の成果を出すことは普通は容易くありません。 ↩︎

  3. もちろん、世の中で既に広く知られていて、単に自分が知らないだけのことについて安易に「不確実性」とラベリングするのはよくないと思います。学習すべきことがある、ということについて謙虚な姿勢であることは必要です。 ↩︎

Discussion