ノウハウ共有は技術的な利害関係者でいられるかどうかで決まる（かもしれない）

情報の共有については、2003年にPMPを取ったときに所属していた組織内で注目を浴びて、発表したあとスライドを共有してくれと言われたとき、正直『PMP取るときに（受験料以外で）いくら投資しているかわかっているのか』と思ったことはある。

結局共有したのだが、そのとき、逡巡を繰り返したあと、結果だけ共有しても、先を歩いているのだからもっと先を歩けばいいと自分の中で得るものがあったのは良かった。

担当していたビジネスでは、大規模開発よりは少人数のチームを編成することが多く、チーム編成もチームのスキルセットに合わせた最小限になり、メンバの実践知と形式知の背景の差をどうするかは常時課題ではあった。当時のメンバ達は、その辺を上手にやっていて、手順書や設計の検討資料、新機能の検証メモを自然と共有していた。

ツール的にはテキストやexcelなどのoffice stuiteのアプリに残していたが、それは次のプロジェクトで流用するのでwikiなどよりはよっぽど利用頻度が高かった。

自然と情報共有をしていたように思えるかもしれないが、よくよく考えれば（考えなくても）現場のニーズからそうならざるを得なかった、ということが言える。チーム編成は、チームとしてのスキルセットで編成する。アサイメントは、できる限り、プロジェクトの立ち上げから終了まで入れることを基本としていた（若手の育成の観点）ので、必然と少ないメンバであれこれとロールを担わなければならなくなる。プレングマネージャやリーダばかりで役割を分担していては、実務が回らないから裁量を持たせて若手エンジニアにある部分については判断を含めてデレゲートする。

そのためには、必要な情報をインプットすることが手戻りを防止する策だと誰もが気づくように、リーダたちが知っていることを共有する雰囲気が勝手に醸成されていく。

プロジェクトチーム内は、プロジェクトの目標達成という目的があるから勝手に進むが、プロジェクト間でも同じ現象は起きる。なぜなら、次のプロジェクトでは同じチームになる可能性が高い（実際、よくある）し、特に技術情報は、知っている人に躊躇なく取りに行くし、何か検証をするとメーリングリストで共有するので、お互いに情報を出す文化が出来上がっていた。

こうした文化はチーム（前述の複数のプロジェクトチームを束ねた組織的な意味合いで）の中で起きていたことで、これがチーム間になるとビジネスが違うので途端になくなってしまう。実際、組織再編があると必要とする情報に違いが出てくるから、前述のようなことは元々同じチームのエンジニア同士だったとしても同じようなことにならない。

ここのところ、エンジニア界隈では、ノウハウの共有、成長を支え合うような雰囲気がある。でも、これは組織の中では、実際にできていないからそうしたいという願望が根っこにあって、それをやっている事例にスポットライトが当たっているのかもしれない。

過去の体験を振り返れば、共有されるコンテンツは同じテーマ（全霊はビジネスという領域）をチーム全体で必要としていたから、そこで働くエンジニアには何かしら提供する機会が与えられていて（若手でも機能検証をすれば共有できる）、それを現場で使う場面があったところが大きいかな、と思う。

逆に見れば、需給のバランスが取れていないとか、同じエリアとか関連するコンテンツじゃないと技術的な利害関係者になれないというところがノウハウ共有により間接的に支え合う文化作りに参加しないのではないだろうか。