暗黙知という迷宮

ソフトウェア開発

Tracにはソースコード作成と同時に設計の考え方をまとめたり、関連する内容のチケットを作ったりクローズしたりしている。開発メンバー全員がこのような使い方をしてくれれば情報共有という面で有り難いのだけど、中には「リードオンリー」となって自分からは決して書こうとしない人もいる。酷い開発リーダに至っては「担当者が記載しろ、自分は内容を確認する（ので書かない）」というケースも珍しくない。ブログで情報を発信する人の数と、情報を参照して読む人の数を比較すると、圧倒的に後者のほうが多いそうだが、それは開発現場というクローズドな環境でも変わりないようだ。

仕様書を始めとする資料の作成は嫌われがちな作業であることが多く、それは仕方ないことかも知れないけれど、それならそれなりに手早く片付ける方法が有ると思う。チケット駆動開発も同様だけど、簡単に使える優れたツールが用意されているのにそれを使わない（使おうとしない）人が少なくないのはどうしてなのだろうか？しかも、開発業務は対価を貰う仕事なのだ。わざわざ開発効率の悪い方法で作業をしているなんて大きな無駄だし、個人の好き好みで仕事を選別するのは基本的に許されないはずだ。

そんなことを考えつつ「ウェブで学ぶ――オープンエデュケーションと知の革命」を読んでいたら、ツールとナレッジの関係について上手く表現されている記述に出会った。

要するに、教育的『テクノロジー』や『コンテンツ』は、ウェブ上に載せればすぐに「オープン」になり共有化することができるが、自分の頭の中にある教育的『ナレッジ』（知識や経験）は、自分が意図的に取り出し、他の人に簡単に理解できる形で表現しなければ『オープン』にすることはできません。これは、知的にかなり大変な作業なので、「オープン・ナレッジ」を普及させるためには、この知的作業を本質的な部分を損なわずに効率化するための「知的支援ツール」を作ることが大事だ、ということになります。

なるほど、ツールを用意して記載しただけでは不充分であり、そのツールを使って何をどのように表現するかという考え方が必要になるのだ。考えて見れば自分では「手っ取り早く簡単な方法で情報を整理して共有したい」という目的があってPukiWikiやTrac等のツールを使い始めたため、多少なりとも「自分の頭の中にある教育的『ナレッジ』（知識や経験）は、自分が意図的に取り出し、他の人に簡単に理解できる形で表現」することには慣れているつもりだ。何かで習ったという記憶はないけれど、開発作業の必然として学んだ現場の知恵の一つだと思う。

しかし、そのような目的意識や表現の経験が無く、すなわち暗黙知を形式知に変換した経験が無く、いきなりツールを渡されて「チケット駆動開発に使え」と言われても、そもそも「何を書くべきか分からない」「今まで通りメールで済ませたい」「チケットに書かなくても分かっている」と抵抗する開発者が現れるのは仕方ないことなのかも知れない。「知的支援ツール」なるものがこのような開発者にも有効な存在になり得るのか分からないが、必然性を理解しない開発者にツールや方法論を持ち込んでも、それは結局無用の長物になってしまうだろう。

ソフトウェア開発の現場に問題は山積みだ。ソースコードというアウトプットは見えるけれど、その本質（例えば、スパゲティコードで実現していること）はなかなか理解出来ないし、雑多な開発情報から構成される開発プロジェクトは外部から（あるいは当事者でさえ）見えないことが多い。そのような開発者が抱えている暗黙知を形式知へもう少し容易に変換することが出来れば問題の所在が明確になり、その対処方法が他の人にも伝承できるので、ソフトウェアプロセスに関わる開発者はもう少し幸せになれそうな気がしている。

ウェブで学ぶ　――オープンエデュケーションと知の革命 (ちくま新書)

ウェブで学ぶ　――オープンエデュケーションと知の革命 (ちくま新書)


関連