はじめに

本連載では、「⁠透明性」というキーワードで、アジャイル開発について説明してきました。最終回の今回は、「⁠透明性」を高めるということの意味を、形式知と暗黙知という観点から考えてみたいと思います。

アジャイル開発における「透明性」の確保

ソフトウェアの所有者である顧客が、本当に自分が欲しいソフトウェアに少しでも近づけるように、フィードバックを繰り返しながら仕様の微調整と機能拡張を繰り返すのが、アジャイル開発の基本です。その為に、開発者側は、顧客に対し、可能な限り分かりやすい形で、また可能な限り早いタイミングで、ソフトウェアを見せるように努めることが必要です。更に、開発チーム内部でも、お互いの作業状況を常時公開し合い、個人で作業を抱えるのではなくチームとして作成途中の成果物を共有することが必要です。このように、アジャイル開発では、ソフトウェアの開発途中での情報の流通量は圧倒的に多く、透明性が高いと言えます。

形式知重視の弊害を越えて

「透明性の確保をする」とは、「⁠見える化」を実践することです。しかし、「⁠見える化」の実践をしようとすると知識の表出化(文書化・データ化)を連想しがちです。開発プロセスの中で、細かく情報を取り出し、形式化・定形化といった加工を施して、他人が判断な可能な情報にして伝達する。それ自体は、情報共有を進める上で欠かせないものです。

また、文書の整備や、計測目的でのトラッキング等、情報を測定可能性を高めるべく形式化・定形化してゆく作業は、繰り返し作業の効率化や人為的なミスの削減には貢献します。しかし、創造的な作業を行うに当たっては、むしろ弊害になりかねません。

ソフトウェア開発以外の分野では、還元主義的・合理主義的な手法だけでは、物事の本質を捉えることができないという考え方が、20世紀後半では一般的になっていました。経営学や組織理論といった分野では、企業文化や、個人または組織の自律性といった、目に見えない人と人との相互作用が、組織の優劣を分ける要因となるという考え方は、常識となりつつあります。例えば、ドラッガーの知識社会や、コアコンピタンス経営理論、各種イノベーションに関する理論、ラーニングオーガニゼーション理論等、多数あります。

また、複雑適応系理論のように、秩序だった定形的なプロセスではなく、絶えず変化する環境の中でこそイノベーションが生まれるという考え方は、学問の分野を越えて、大きな影響を与えました。自律した個々の主体の相互作用により、全体が個々の総和よりも大きくなるという「創発」の理論は、創造的な組織活動を考える局面において、大きな理論的転換となっています。

アジャイルへの影響

アジャイル開発手法も、そのような人間の相互作用を重視する流れの中で、生まれてきています。たとえば、ハイスミスの適応型ソフトウェア開発手法は、その名が示すとおり、複雑適応系の理論を、その背景に据えています。スクラムも、その理論的背景として、知識創造理論や組織学習の理論を引用しています。他のアジャイル開発手法も、程度の多寡はあれ、そのような時代背景に影響を受けているのです。そして、こういった背景を理解することで、アジャイル開発手法がもつ、プラクティスの意味がよりはっきりと見えてきます。

暗黙知と形式知

ここでは、相互作用を重視する理論の一つとして、野中郁次郎先生の知識創造の理論をご紹介します。理論自体は1990年代初頭のものとなります。

この知識創造の理論では、知識を、形式知と暗黙知に分けて整理します。形式知とは、言葉や図で文書なりに表されていて、見たり聞いたりすることで習得することが可能な知識です。暗黙知とは、経験やノウハウとして各個人の中に溜まっている洞察力、直感、経験値といったもので、言語化されていない知識を指します。

そして、組織の知識創造とは、形式知のみならず、暗黙知も大切であり、形式知と暗黙知、個人と組織の間で知識交換が起こる過程で、新たな知識が創出されるというのが、知識創造理論です。

個人の知恵は形式知として表出化します。
(暗黙知から形式知への転換)

その形式化した知識は、集まって連結化されることで、さらに新たな価値を生み出します。
(形式知から形式知への転換)

それらの知識は、個人によって咀嚼されることで、内面化されます。
(形式知から暗黙知への転換)

そして、共通体験を通じてその知識を共同化することで、新たな価値を生み出します。
(暗黙知から暗黙知への転換)

そして、組織を管理する側は、暗黙知を含めた知識創造のスパイラルが、円滑に回るように働きかける必要があるのです。

暗黙知を重視するアジャイル開発

知識創造理論においては、暗黙知と形式知のどちらが優れているというものではなく、相互に作用しあうことで、スパイラル化することが大切です。

しかし、知識創造理論がエポックメイキングだったのは、やはり、形式知重視の時代背景において、暗黙知にスコープを当てた点だと考えます。

アジャイル開発手法も同様で、暗黙知の交換を円滑に促進する作用を、プロセスやプラクティスの中に盛り込んでいる点が大きな特徴の一つです。

コードをチームで共有する。

まず、コードの共同所有のようなプラクティスがそうです。毎日リポジトリにコードを登録して、誰でも参照・改変できるような状態を維持します。加えて、アジャイル開発では繰返し型の開発スタイルをとりますので、他人の書いたコードや文書をレビューする機会が頻繁におとずれます。これらは、形式知を内面化する文化の醸成に有用です。

このような、コードレビューやテストレビューのような「場」は、コードに関する考え方や、設計・実装のノウハウを交換する良い機会となります。すなわち、暗黙知の共同化を推し進めるプラクティスとなっています。

更に、より直接的に経験を共有するプラクティスとして、ペアプログラミングがあります。試行錯誤の過程を共有しますので、暗黙知の共同化には最適なプラクティスです。

対話を促進するプラクティス

日々のスタンドアップミーティングでは、メールやWiki での進捗報告ではなく、全員集まっての直接対話が推奨されています。また、短いイテレーションの最後には、レトロスペクティブの場があり、チームとして、振り返りと改善の場が用意されています。このような、人と人とが直接対話するような「場」を様々な形で設けています。

このようなプラクティスがアジャイル開発に用意されている理論的根拠は、「⁠場」を共有する共同作業が、暗黙知の共同化にはもっとも効率が良いからです。

更に「場」を提供するだけではありません。同一の「場」における共通体験から、より多くの知識を共有する為には、コンテキストの理解をそろえておくことが必要です。チームの文化を共有するといってもかまいせません。その際に役に立つのが、XPにおけるメタファーのプラクティスです。これはある特定のコンテキストにおいて、固有の意味を指し示す際に使うもので、共有概念がメタファーを生み、メタファーが共有概念を明確化する相互作用を持ちます。

同様の効果をもつものとして、パターンやパターンランゲージもあげられます。コンテキストの共有を前提とするかどうかといった違いはありますが、ノウハウをメタファーとして定形的なテンプレート化することで、気づき = 内部化を促進する意図を持つ点では共通です。そして、形式知の裏に隠された暗黙知の伝達に配慮しているという意味で、重要です。特に、アジャイル開発ではリファクタリングの際に、コードの臭いをかぎ分けて、きれいなコードに修正をします。「⁠臭い」や「きれいなコード」といった概念を共有する上で、テンプレート化されたノウハウは基準として有用です。

顧客と開発者の間での暗黙知の共有

顧客と開発者との間でも、創造的な対話が必要です。XP では、全員同席のプラクティスで、顧客と開発者とが常に同一の空間を共有することを強く推奨しています。スクラムにおいても同様で、スクラムチームとは開発者チームのみならずプロダクトオーナーまで含めて、1つのスクラムチームです。チーム=仲間として、顧客・開発者が一丸となって目標に突き進むとことが求められています。 いずれも、人と人との相互作用を重視し、暗黙知ベースでの情報共有を活性化させることを目的としています。しかし、受託開発中心の日本のソフトウェア開発の現場においては、なかなか顧客との暗黙知の共有は難しいものがあります。筆者らのチームでも、この点を重視し、代替となるプラクティスを模索中です。

透明性とは

このようにアジャイル開発では、人と人との相互作用を重視し、暗黙知ベースでの知識交換、さらには、形式知と回すことでの知識創造を促進する仕組みを中に取り込んでいます。

アジャイル開発の一つ一つのプラクティスは、過去に提唱されてきたものと大差無いように思えるかもしれません。 しかし、形式知を重視するソフトウェアエンジニアリングの世界から、暗黙知にも目を向けたソーシャルエンジニアリングの世界にまで幅を広げたという意味で、アジャイル開発は従来のソフトウェア開発手法とは、異なるパラダイムに属するといえるでしょう。

本連載では、全六回にわたって、アジャイル開発における透明性について、様々な角度から見てきました。

• 顧客から見た開発者の透明性
• 開発者から見た顧客の透明性
• 開発者から見た開発者の透明性

その全てにおいて、形式知ベースでの情報共有のみならず、暗黙知ベースでの情報共有が重要となってきます。これらの情報共有が円滑に進み、知識創造のスパイラルが回りだす状態が、透明性の高い状態なのです。

ソフトウェア開発は、創造的な作業です。単純な繰り返し作業のように見える部分もありますが、設計や実装の随所に、知恵やノウハウが詰まっています。それらの知恵やノウハウを有効活用すべく、透明性を高める工夫をこらすことが、ソフトウェア開発においては大切なのだと考えます。