技術の伝承と良い習慣の伝承

企業において、若手を育成するため、先輩から後輩への知識を伝達するため、仕事を引き継ぐため、といった理由から「技術の伝承」と称した活動が行われたりします。

技術を伝承するというのは、短期間に簡単にできるもでのはありません。私自身が大学時代から今日まで経験してきたことを、すべて伝承することはできません。それに加えて、スキルを伝承できる能力が必要となります。

伝承が失敗した例として、『アプレンティスシップ・パターン』に次の例が説明されています。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得

• 作者: Dave H. Hoover
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/07/08
• メディア: 単行本（ソフトカバー）

　17 世紀と18 世紀のアントニオ・ストラディバリ（Antonio Stradivari）の工房で作られたバイオリンとチェロは、歴史に残る名作です。それらは、定期的に数億円で売られ、過去300 年間に、それらを再現しようと多くの挑戦が行われてきました。しかし、The Craftsman（p.75）に書かれているように、「アントニオ・ストラディバリやグァルネリ・デル・ジェス（Guarneri del Gesu）のような熟練職人の秘密は、実際、彼らと一緒に消えていきました。膨大なお金を費やして、数知れず行われた実験は、それらの熟練職人の秘密を探り出すのに失敗してきました。彼らの工房の性質の何かが、知識の伝達を抑制していたに違いありません」。ストラディバリが歳を取り、弟子のアプレンティスのように日々活動的でなくなるにつれて、彼の工房での楽器の質は落ちました。彼の工房は「1 人のたぐいまれな才能のもとに発展し」、そして、ストラディバリは自分の才能をアプレンティスに受け継がせることができなかったため、彼の工房は彼と共に死を迎えました（The Craftsman、p.76）。
　ストラディバリのアプレンティスには、彼の2 人の息子も含まれていました。そして、息子達に対して何かを隠すつもりはありませんでした。私達が知る限り、彼は息子達に知っていることすべてを教えました。いや、むしろ、息子達にとって知るのが重要だと彼が考えたすべてを、息子達に教えたのです。しかし、彼は、まさに失敗しました。なぜなら、彼が認識していなかった暗黙知のすべてが、彼のスキルセットの一部だったからです。当時彼が重要には思えなかったために記録しなかったすべての微妙な知識の関連と、彼がアプレンティスと取り組んだ些細な仕事で彼が適用したすべての暗黙知の中に、彼の工房の破綻は深く根付いていたのです。

『アプレンティスシップ・パターン』（p.151）

技術の伝承は容易ではありませんが、伝承するための努力を組織は行い続ける必要があります。その場合、特定の技術を教えるというのではなく、良い習慣を伝承させて、スキルを伝承できる能力を伸ばしていくことが必要となってきます。

たとえば、勉強会を継続的に主催したり、勉強会へ参加するという習慣を継続して行えばその勉強会で学んでいる技術的な事柄だけでなく、参加者の経験談や失敗談を伝えることで伝承していくことになります。

継続的インテグレーションにしても、その環境に対して日々どのような開発を行うかが重要です。たとえば、コミットする前に自分のマシンでコンパイルからテストまでが成功するのを確認してコミットするのか、コンパイルできただけでコミットするのかは、良い習慣で開発しているのか、悪い習慣で開発しているのかという差になっていきます。この場合でも、良い習慣の開発を伝承していく必要があります。

防御的プログラミングを行うとしても、それを、コードレビューできちんと指摘するというのを習慣にしている人には当たり前ですが、いい加減なコードレビューしかしていない組織では防御的プログラミングさえ行われなかったりするかもしれません。知識だけでなく、実際の開発で実践することで、防御的プログラミンを伝承しかなければなりません。

結果として、一時的なノウハウ（技術）の伝承よりは、ソフトウェア開発全体に対する良い習慣を若い人たちに伝承することが組織としては重要になってきます。そして、その習慣を通して、ソフトウェア開発に関する技術の伝承をできる人材が育っていく必要があります。しかし、その前に良い習慣を持った組織を作り上げなければならないので、ニワトリが先か卵が先かになってしまいがちです。

現実的には、良い習慣を持たない既存の大きな組織を良い習慣を持つ組織に変えることは非常に困難です。むしろ、良い習慣を持った小さな組織に、毎年若手を入れて年々拡大していくということで大きな組織にしていくのが、遠回りのようで近道だったりします。

継続した学習と勉強会

会社で始業時間前に行う非業務の勉強会を始めたのが富士ゼロックス情報システム（FXIS）に勤務していた1999年の初め（「勉強会一覧」）です。現在でも平日の始業前に、私が主催している勉強会が2つ、参加している勉強会が1つあります。

勉強会を開催して始める頃には、参加者も多いのですが、途中で少なくなっていって、参加メンバーが固定されていきます。自主的な参加の勉強会ですので、途中で参加しなくなってしまう人が出てくるのは仕方ないことかもしれません。ただ、新卒新人の場合には、強制的に参加させる必要がある場合もあります。

FXIS勤務時代は、フレックス勤務でしたし私自身が部門長でしたので、コアタイム前に勉強会を開催して、新卒新人は強制参加で業務扱いにし、先輩は非業務扱いの自主参加にして開催する勉強会もありました。新卒新人には半年から一年間はとにかく継続的に強制参加させていました。その参加を通して、継続して学習する習慣を身につけるだけでなく、非業務でありながら参加している先輩と一緒に学習することで、学習を継続するのが当たり前だという認識を持ってもらう訳です。

完全な自主参加の勉強会の場合には、様々な理由から脱落していく人が増えてきます。

• 業務が忙しいので業務を優先したい
• もともと朝早く起きるのが苦手
• 他の勉強を優先させたい

これらは、自主参加の勉強会の場合には、本人にとってはもっともらしい正当な不参加理由に思えるかもしれません。しかし、このような理由で途中から参加しなくなった人が、本当に一人で学習を継続していることはまれです。

たとえ、週1時間であっても、一ヶ月に4時間か5時間、一年で50時間以上になります。50時間としてもそれだけ時間をかければ技術書によっては読み終えるかもしれません。技術書を読み終えるという経験を積み重ねるには、一人で学習するよりは、勉強会への参加の方が良かったりします。