ソフトウェア開発での「技術の伝え方」問題（前編）

畑村洋太郎氏の新書『組織を強くする技術の伝え方』を読んでの書評を書こうと思ったのだが、タイトルからの連想で本の引用なしで書いてしまったので書評ではない形式で載せておく。

ソフトウェア開発での「技術の伝え方」問題

ソフトウェア開発や運用の現場でも、技術の伝え方は非常にクリティカルな問題だろう。それには大きく2つの問題があるのではないか？

1つ目は一部の優秀な開発者にのみ技術・知識が蓄積され、「誰々に聞かないと分からない」領域が出来上がってしまうこと。

2つ目はなんとか仕様や技術を形式知化しようとして、大量の（それもExcelでの）設計書や手順書を作成して、結局大量すぎてメンテされず使われなくなること。

野中郁次郎先生のSECIモデルで整理するとこれ以外にも考えられる問題がありそうだが、今回はこの2点に絞ってみる。

技術の属人化

技術とは属人化しやすいもので、何故かと言うと以下の3点あたりが主要な原因だろう。

開発者自体も無意識に行っていることを含んでいるため、他人に伝えられる形になっていない、その形にすることが面倒
他者に伝えることで「自分だけが知っている」という優位性がなくなってしまうため、伝える側にとって面白くない
技術を他者に伝えるという行為自体は（ソフトウェア開発という意味で）生産活動ではないため、伝えるという行為に意味を見出せない

1.は野中先生が扱っている「暗黙知の形式知化」の話なので今回は詳細は省こう。意識的に言葉にする、形式知化するというのは意識的にやらなければなかなかやらないし、やってみると如何に非常に難しい（出来ないことを実感させられる）行為なので、ひたすら推進するしかないのでは。

優位性がなくなってしまう恐怖

自分の技術に自信を持っている開発者になればなるほど、自分の技術を神聖視する。これは自分でしか出来ないことで普通の開発者では理解できない、と。（これは言い過ぎか。）

これを打破するには、技術共有自体を評価する制度が必要だろう。「君しか出来ない」ことを評価するのではなく、むしろ他のメンバでも出来るようにしたことを評価すること、またその後のポジションを保証する、むしろより魅力的なものを用意することが必要だろう。そのためには人材に流動性がある（新入社員が定期的に配属される、毎年昇進・昇給のチャンスがある）ということが必要であるが。

生産活動ではない行為

開発者の本分は開発である。人に教えることではなく動くモノを作ることが主目的であるし、実際にそれを行っているときが一番「楽しい」ときのはずだ。（マネジャー視点ではそう思っている人を採用しなければいけないし、そう思わせるようにしなければいけない。）そういった人々に開発を行わずに、今まで開発してきたものの仕様や、蓄積してきた知識を形式知化しろと言っても（仮にそれが評価されることだとしても）面倒臭いだけだろう。

何故面倒臭い、価値を見出せないのだろうか？たぶんそれが生産活動ではないからだ。動くモノ、プログラムを書くことは生産活動そのものであり、即「使ってもらえる」ものになるので価値創造をしている実感が湧きやすい。それに対して人に教えるということは、それがいつ実になるか分からず、そうするとモチベーションに繋がらなくなる。*1

これを解消するには形式知化の作業自体を生産活動の中に組み込んでしまうのが良いのではないか。生産活動と切り離してしまうから面倒になるので、それがシームレスに同一作業に内包されていれば面倒さは軽減されるだろう。

具体的に言えば、ペアプログラミングを利用して実装方法を属人化しないとか、開発レビューを多人数で行ってチーム内で仕様を共有しておくという手法。あるいはコード内のコメント規約にてコーディングとともに仕様をコメントに落としこむようにするとか。

この開発行為（生産活動）と形式知化の一体化はもっと具体例とともに掘り下げたいところ。また考える機会を設けてみよう。

といったところで長くなったので中断。2つ目の「仕様書がメンテされない問題」は次回のテーマとしてみる。