もう10月も終わりに差し掛かり、年度が4月始まりの人はそろそろ上半期の振り返りを済ませる季節になりましたが、皆さんどのようにお過ごしでしょうか。
ところで、振り返りといえば「組織としてノウハウ共有をもっとやっていきたい」的なことを毎年目標にしてる人達って案外たくさんいるのかな〜と身の回りに人を見てて感じます。そこで今回はその「ノウハウの共有」について、自分の経験から思ってることをつらつらと書いていきます。ポエムみたいなもんです。学術的、技術的な話ではないのでご承知の上この先をお読みください。
浅はかな考え
会社や組織として何かをやっている人達にとって「ノウハウの共有」は永遠の課題です。チームやプロジェクトを隔てるとノウハウがうまく共有されず非効率的な仕事をすることになった経験は皆さんあると思います。複数のプロジェクトで同じ悩みを抱えてるのに、別々に考えて別々のアプローチをとって結局どっちも微妙にうまく行ってない、みたいな話はどこにでもあるものです。
とはいえ、ノウハウを蓄積して共有しよう！と言い出した結果として、
- 手間をかけてチェックリストやwikiを書いたけど全然見られてない。
- 勉強会を定期的に開いているけど業務の役に立ってる実感がない。（誰も発表してくれない）
みたいな経験は誰にでもあるのではないでしょうか。
そこで、もうちょっと深く考えてみましょう。
目指すべき状態は「ノウハウが共有できていて、それによって効率的に業務が行えている」状態です。そこまでのステップにはどのようなものが考えられるでしょう。
理想までのステップを考える
例えば、以下のようなものが考えられます。
- 他者の業務内容の理解
- 他者の専門性の認知
- 便益の実感
- 信頼感の醸成
- 協力機会の創出
これは一般的に言われてることやどこかの偉い人の研究成果などではなく、自分がそう考えて勝手に名付けてるだけのものです。
1個ずつ考えていきましょう。以下の説明では、簡単化のため「各メンバ」という表現を使ってますが、「各プロジェクト」でも「各部署」でも話は同じです。
1. 他者の業務内容の理解
これは、そもそも各メンバの間で「そもそも何をやってるか」を知る必要があるということです。前提となるシチュエーションが共有されなければ、ノウハウだけ聞いても役に立たないでしょう。程度の問題はありますが、各メンバが何となくお互いに何をやってるかを知ってるというのは重要な前提です。
2. 他者の専門性の認知
これは、各メンバが「他のメンバが自分が知らないことを知っている」と認識することです。「業務内容の理解」が出来れば自動的に満たされる可能性もありますが、一般的には少し踏み込んだ内容を共有する必要がある事が多いです。他者に業務内容を説明する場合、普通はそこまで踏み込んだ内容を説明しません。その業務を遂行するのに必要なスキルやノウハウをいくらかイメージしてもらうような機会が必要です。
3. 便益の実感
これは、各メンバが「他のメンバのノウハウが自分の業務の役に立ちそうだ」と認識することです。一般的には各メンバが似たような業務をしてるほうが好ましいです。そのためにはそもそもそういった環境を用意する必要があります。エンジニアであれば、使用するプログラミング言語やパブリッククラウド（AWSやGCP）を出来るだけ揃えるなどはわかりやすい例です。一般的な組織でいえば、取り組む課題やその中で関わるステークホルダーなどが同じであればよりノウハウは共有しやすくなります。そのうえで、各メンバにそれを実感として与える必要があります。
4. 信頼感の醸成
実際にノウハウを共有したり、必要に応じて質問したり協力したりするのであれば、メンバ間の信頼関係が必要です。個人として信頼を得る方法は世の中に色んな論があるのでそちらに任せますが、組織として取り組むのであれば、個人の努力に任せるのは不適当です。1on1や勉強会や雑談会などもありですが、個々人の成果を組織として認知できるような仕組みもあると良いでしょう。
5. 協力機会の創出
実際に同僚（もしくは彼らの知識）が自分の業務の役に立つ機会を作る必要があります。最初に例に上げたwikiや勉強会だけでなく「Slackの相談チャンネルに質問して回答をもらう」なども立派な機会になるでしょう。質問と回答というだけでなく、実際に手を動かしてもらうようなシーンもありえます。そういったやり取りが気軽に出来る場を用意しておく必要があります。
逆に言うと、そういったやり取りを阻害する要因は出来るだけ排除しましょう。わかりやすいのは主に時間的な問題と、権限的な問題です。
前提として、自分の知識を組織に共有するのも、込み入った質問や相談に答えるのもなかなか大変な作業です。日々の業務に追われてる人はまず行えなず、自分の時間をどう使うかのある程度の裁量が必要です。
また、プロジェクトの情報を社内の別組織に公開できない場合、そのプロジェクトのノウハウも共有できなくなります。上長の承認が必要というだけでも相当に難しくなるでしょう。逆に、別チームのプロジェクトのコードやドキュメントを見る権限があるかどうかも重要です。自由に見られるのであれば、質問や相談をするためのやり取りが楽になるでしょう。
まとめ
最初に話した通り、ここに書いたものは別に高名な学者が考えたフレームワークとかではありません。ただ、「ノウハウの共有」と一言でいっても様々なステップが考えられ、それぞれに対して異なる対策が必要なように思える、というのはなんとなく分かってもらえたかなと思います。
エンジニア的には、それぞれのステップに対して計測可能なメトリクスを提案しダッシュボードを作る！とか続けたいところですが、そのあたりはまた長くなるし、自分としてもあんまり良い方法が見つかってません。なにか良い方法が見つかったらまた記事にしようと思います。
