はじめに

知識の共有に関して、事例と知見と参考文献を記録しておく。

知識とは

本記事における知識とは以下を指す。

• 開発対象システムの仕様及び仕様を説明するために必要となる知識
• 開発対象システムの使用目的，使用環境，ユーザ，関連システムといった背景の知識
• 開発対象システムの開発（品質保証・保守・運用を含む）で必要となるプロセス（手順，方法論，ツール，設備）に関する知識
• 開発対象システムの開発（品質保証・保守・運用を含む）に関わる組織・チーム・人に関する知識

人によっては「知識」という言葉の対象が異なるかもしれない。
今回まとめた事例と知見は、多少「知識」の対象が異なっても活用できる可能性は高い。
参考記事：
https://qiita.com/kaizen_nagoya/items/9d8843d255eb105d8588

共有とは

@kaizen_nagoyaさんが上記記事で、以下のように述べている。

共有は、共に有する。
なんらかの所有権がお互いにあることが条件。
共有という言葉を聞く時の、半分以上の場合が、「それ共有じゃなくて、情報の献上じゃね」と思うことがある。

本記事において、共有とは、「共に所有すること。共有しているのであれば、誰でも変更できる。」と位置付ける。

事例

私のプロジェクトでの知識共有の事例を「ナレッジスタッフを中心としたニーズ駆動知識共有アプローチの提案 ～ドメイン知識の共有を阻害する問題の解決～ 」というタイトルで、ソフトウェア品質シンポジウム2020で発表した。

概要

ドメイン知識の共有は多くのチームで重要な課題となっている。我々のプロジェクトでも、以下の状況が見受けられ、ドメイン知識が共有できている状態にする必要があった。
　・情報を見つけるのに時間がかかった
　・見ていた情報が誤っていた
　・知らない情報があり失敗した
　・同じような質問を何度もされ回答が面倒
分析の結果、ドメイン知識を共有する活動を継続的に行うためには、以下の問題を解決する必要があると考えた。
　・知識提供者には、知識利用者から必要とされるドメイン知識がわからない
　・知識提供者には、ナレッジ DB へのドメイン知識の登録を妨げる時間的制約と心理的障壁がある
本研究では知識共有を妨げる問題を解決するために、先行研究を参考に、知識共有を妨げる要因を解消できる「ナレッジスタッフを中心としたニーズ駆動知識共有アプローチ」を考案した。また、考案したアプローチをもとに、ドメイン知識共有システムを構築した。
構築したシステムを1年間運用し、Wikiが継続的に更新・参照され 知識利用者から必要とされるドメイン知識がWikiに登録され続ける状態が維持できることを確認した。考案したアプローチとシステムにより、ドメイン知識を共有する活動が継続し、ソフトウェア開発の効率向上と品質安定化に繋がる効果が期待できる。

発表に対する質疑応答

質問：
保守担当者は専任でしょうか。ナレッジスタッフと保守担当者の1日の従事割合はどの程度でしょうか。
回答：
「保守担当者」は、業務を行いつつではありますが、1人に任せているという感じです。ナレッジスタッフと保守担当者1日の従事割合は、日によってかなりばらつきがあります。厳密なデータはないのですが、1日0Hの日もあれば、2H程度を記事作成に充てているような日もあります。平均すると、1日30分～1時間程度は時間を使っていると思っています。

質問：
Wikipediaは完璧じゃない前提で理解している人も多いと思うのすが、仕事においての知識はWikipediaと同等の品質前提で取り組まれているのでしょうか。または、内容の確からしさ（品質）のチェックはナレッジスタッフが行っているなどあるのでしょうか。
回答：
Wikipediaと同等の品質前提で取り組んでいます。つまり、Wikiには極力、引用元を書くようにしており、情報の精度が必要な場合は参照者が引用元を見て裏付けることは運用の前提です。ナレッジスタッフも記事は確認していますが、誤りがあれば「皆で修正」を目指しています。
Wikiに公式なドキュメントへのリンク情報も記載しております。業務では、もちろん公式なドキュメントを入力に、開発を行います。Wikiは、知識獲得の補完・知識獲得の入り口のような存在です。

質問：
よく使われている用語でも広義と狭義で意味が異なりますが、メンバー間での解釈の違いには、どのように対応してますか。当たり前のように使われている用語ほど、実は人によって解釈が違ってて、議論が噛み合わないことがあります。
回答：
ご認識の通りです。単一の用語でも、複数の意味が場合によって異なる場合や、広義・狭義の意味がある場合は、1つのページにそれらの可能性も記載するようにしています。

質問：
ナレッジスタッフがこの作業に割り当てている工数の割合はどのくらいでしょうか。ナレッジスタッフはマネージャーも兼務という事なので負担が大きいのか、それほどでもないのかお聞かせください。
回答：
ナレッジスタッフの負担としては、平均すると、1日30分～1時間程度は時間を使っていると思っています。ナレッジスタッフ側は楽しくやってます。

質問：
知識提供者へのインセンティブは何か設定しました、それとも強制的に入力させた？
回答：
ほめます。感謝します。一応、自主性を尊重しています。

質問：
数あるWikiエンジンの中で、MediaWikiを選定された特別な理由がありましたら、教えていただけないでしょうか？
回答：
特にありません。Wikipediaのベースであったことと、メンバの一人がMediaWikiで「自分の知見メモ」用に作って利用していたので、それを有効活用する形で活動を広げていった経緯があります。

質問：
ドメイン共有は課題に持っていますので、非常にいい仕組みだと考えます。Wikiが使えない場合、Excelとかでやる場合難しいでしょうか？後、ナレッジスタッフを設けにくい現場だと難しいでしょうか？
回答：
Wikiは、もともと、不特定多数の人間が編集を繰り返して知見を蓄積する目的のシステムで、そのための機能が多く備わっているので、とても便利です。（編集の容易さ、履歴管理、自動リンクによる記事間の紐づけ、…）この手のシステム運営は放置ではなかなか継続しないのも実体と思います。今回の活動の考察としては、ここで言う「ナレッジスタッフ」という牽引役があって上手くいたのかと思っています。

質問：
ナレッジスタッフからの働きかけによって知識提供者が記載する、というプロセスを導入されていますが、以下の点で質問があります。
1. 知識提供者が特定の人物に偏ってしまうことはないか
2. スタッフからの働きかけなく、自律的に情報が更新されるような変化はあったか
回答：
1. 実質、偏ります。でも、ここは仕方がないと考えていますが、DBにより将来的に楽になるように黙認しています。
2．少しづつ、手ごたえはあります。ただし、「ナレッジスタッフ不要」とまではなかなか判断できる状況にはいきません。

質問：
特定のプロジェクトでの活動のようですが、上手く回っているようですので、同様の取り組みをしたいというプロジェクトは出てきていますでしょうか。
回答：
他のプロジェクトが我々のWikiに乗っかってくる（別ドメインのナレッジも登録されてくる）という動きはあります。こちらはうまくいっています。まったく同じ仕組みに、入れるノウハウを増やしただけのため。

質問：
Wikiの編集については、編集する方の文章作成能力に依存して記載内容が分かりやすかったり、分かりづらかったりがありそうな気がしますが、そのあたりでバラツキが発生しないような工夫などは何かされていたのでしょうか。
回答：
おっしゃるとおり、バラツキがでます。我々のプロジェクトでは、バラツキに気づいた人が、そのバラツキが気になるようであれば修正するという行為が行われておりました。通常のWikipediaと同じ状態かと思います。ちなみに、バラツキを一番多く修正していたのは、ナレッジスタッフです。

質問：
ドメイン知識にプロセス（手順、方法論等）を含んでいるとのことですが、プロセスは組織標準などで管理されていたりすると思います。組織標準の更新により、Wikiの情報が古くなることも想定されると思います。このような情報の重複に対しては、Wikiの記入ルールや定期的チェックをされているのでしょうか？
回答：
組織標準が存在しているのであれば、その内容を重複して記載することはしておらず、その組織標準へのリンクを記載するということをしておりました。

知見

『実践！ソフトウェア品質向上のための原因分析セミナー』の感想

• 原因分析は4つに分類される。過去の失敗だけでなく、過去の成功と将来の失敗と将来の成功の分析もある。
  • 成功事例から得られる暗黙知を形式知化することが重要
  • 成功事例は分析されにくい
  • 成功した本人は分析の必要性を感じない
  • 成功事例は、本人には分析させないのがポイント
• 原因分析には構造化された知識（因果関係図、原則）が必要
  • 専門家は構造化された知識を持っている
• 構造化された知識を伝承することは難しい
  • 無駄に思うかもしれないが、もう一度同じように構造化する行為をしない限り伝承されない
  • チームで形式知化することも１つの手
  • 技術伝承は20才くらい離れた弟子にしたほうがよい（※感想:伊勢神宮の式年遷宮の期間と一緒だけど、何か関係があるのか？）
  • 同年代を同じチームに入れるのはよくない（ライバル心が学びを邪魔をする）
• 専門家を選定するには、自分が専門領域の知識をもち、専門領域の課題を把握し、議論できる状態になる必要がある

松尾谷徹さんに教えていただいたこと

• wiki などは、価値を得る人を増やすことで更新が続く。チームで当たり前になった知識は展開する価値を感じない。そんなときは、展開する範囲を広げる。新たな人がwiki を見て価値を感じることで、また更新が活性化される。徐々に参照者（価値を得る人）を増やすことがポイント。
• ナレッジを引き出すのも技術。

参考文献

[1] Noriko Iizumi，“Utilization of Domain-Specific Knowledge for Quality Software Design”，5th World Congress for Software Quality，2011
[2] 中谷康子，“知識継承のしくみづくり”，人工知能学会誌/Journal of Japanese Society for Artificial Intelligence,22(4),467-471，2007
[3] 塚松一也，“ナレッジマネジメント成功への鍵<上>創造的組織と個人を生み出すマネジメントを実践するために”，JMAマネジメントレビュー，2001
[4] 塚松一也，“ナレッジマネジメント成功への鍵<下>ナレッジマネジメントからナレッジクリエイティブマネジメントへ”，JMAマネジメントレビュー，2001
[5] 梅木秀雄，“コミュニケーションに埋もれた知識を活用するコミュニティウェア”，情報処理学会誌 43(10),1085-1092，2002
[6] 梅木秀雄，堀川 将幸，“コミュニティベース知識協創プラットフォーム”，東芝レビュー 56(5), 14-18, 2001
[7] “Wikipedia:五本の柱”，https://ja.wikipedia.org/wiki/Wikipedia:五本の柱
[8] “Wikipedia:編集方針”，https://ja.wikipedia.org/wiki/Wikipedia:編集方針

特に[3][4]の塚松一也氏の記事「ナレッジマネジメント成功への鍵」は、必ず目を通したほうがよい。

また、「SECIモデル」についても、もちろん重要であると思われるが、私がお勧めできる書籍がない状態なので、今回の参考文献には掲載を見送る。

関連記事