コパイロツトは、クライアントやパートナー会社の『copilot / 副操縦士』となって、
目的地にたどり着くまでの過程をトータルでサポートします。

とてもベーシックなナレッジマネジメントの方法論を開発しています。(1)

開発中のプロトタイプについて書いてみたいと思います。
今回は最初のプロトタイプをつくるまでのプロセスと、それがユーザーインタビューで「使えない」というレビューを受けるところまでを紹介します。
そう、最初のプロトタイプはあっさりと否定されてしまいましたが、それはこのエントリの後半で明らかになります。

なぜあえてベーシックへ?

「ナレッジマネジメント」や「ナレッジ」の概念は非常に多義的で、いろいろな切り口で研究したり実践したりすることができます。
それゆえ、これまでナレッジラボチームではアンテナに引っかかってきたいろいろなことに取り組んできました。
このブログでもそうした試みの成果がナレッジラボのメンバーによって書かれ始めています。

しかし、一方で、じゃあ具体的にどこから始めると便利になるの?というところにあまり注力できていませんでした。
そこで、非常に具体性が強く、実効性が高い、とてもベーシックなナレッジマネジメントにあらためて目を向けることにしました。その具体的な方法論の確立に取り組んでいます。
おそらく、時間をとってやろうと思えばいつでもできそうと思われがちですし、それで解決するチームもあると思います。 しかし、そうでない場合には実はなかなか手ごわい相手になります。

ナレッジの定義を、小さく、限定的に。

先にも書いたように、ナレッジラボチームが書いたブログエントリでは、「ナレッジ」を多様で多義的であり、定型的でなく常に流動するものとして論考をおこなっています。
それはとても本質的であり創造的です。
一方で、あれもこれもとなると、どこから手を付けていいかわからなくなる、あるいはどこからでもいいよという問題も生まれます。
そこで、いま開発しているプロトタイプでは、「ナレッジ」を、あえて限定的で固定的なものとして扱っています。


開発中のプロトタイプでの定義

ナレッジ
業務に役立つノウハウで、形になっているもの(形式知化されているもの)。

ナレッジマネジメント
チームにあるナレッジをチームメンバーが使える状態にすること。


あくまでももっとも小さいプロトタイプをつくるうえで変動要素を限定し、仮説を検証しやすくするためです。
また、実践の現場においても、まず理解しやすいサイズや形状で扱うほうが導入が容易であろうという仮説にも起因しています。
こうして、シンプルなナレッジマネジメントの骨格がしっかりしていれば、その後にナレッジに多様性をもたせたり、流動的なものとして扱ったりすることは可能であろうと思っています。
その骨格をいまは作っているということになります。

カギは「構造化」の方法論だと思っていた。

プロトタイプは、ある限定した領域のナレッジを集め、構造化すれば、十分にナレッジの共有が可能ではないか、という仮説によるものでした。
扱う領域も、ただ限定するだけではなく、構造がチーム内で理解しあえるようなものをまずは選ぶことにしました。

ここまでで言うと、共有しているサーバやクラウドストレージなどで、フォルダをしっかり構造化して活用し、機能しているチームもあると思います。
しかし、コパイロツトでは業務内容が多様で、プロジェクトごとの固有性が高いせいか(←これもまだ仮説です)、この構造化が非常に困難でした。
そのため、プロトタイプでは、①チーム内で経験やスキルの共通性が高い業務、②構造化の分類方法に異を唱えづらい業務、に絞り込んで構造化することにしました。
構造化の方法にこそ、ナレッジを共有するカギがあるのではないかと思っていたのです。ですから、まずは構造化の方法として難易度が低いと思われるところからはじめました。
そのうえで、固有性が高いとか、難易度が高いナレッジをどうしていくかをその先で捉えなおそうとしました(そしてそれはこのプロトタイプの延長線上ではなく、まったく別のものになる可能性もあると思っていました)。

この構造がどのような状態であれば使いやすい状態になるのかを検証し理解を深めるために、ユーザーインタビューを実施しました。対象は、コパイロツトのエンジンチームです。

ところが。
インタビューでは「使えない」という結果になりました。
そして、こういうふうになっていてほしい、という要望を聞いて、何が足りないのかがわかりました。
それはナレッジをつなぐ「コンテキスト(文脈)」でした。

「構造化」だけではコンテキストがつくれない(ことが多い)

構造をみただけでわかるということは、その構造を読み解けるだけの共通のコンテキストがあることが前提です。
しかし、先に述べた仮説の、「業務内容が多様で、プロジェクトごとの固有性が高い」ことが困難さを招いているとすれば、構造化と、それに付随するファイル名やフォルダ名の付け方などの範囲では解決が難しいということになります。そこで、そこにコンテキストをつくることが必要になります。

ちなみに、「使えない」というレビューと解決の大きなヒントをくれたメンバーは、おそらくこのプロトタイプの範囲では、コンテクストを備えていて理解できていたと思います。
それではなぜ「使えない」と言ったのか。それは、いま自分がほしいと思っているナレッジは、こうした構造だけでは探したり使ったりできないという経験を持っていたからだと思います。
ナレッジの構造化は必要だったとしても、そのナレッジどうしをつなぐ「コンテキスト」をつくらないと、使えるナレッジにならないことを体感的に理解していたからこその「使えない」だったと思います。

必要なのは、コンテキストを生み出す「ガイド」である。

さて、そこで、ナレッジをつなげるコンテキストを補うために、「ガイド」という考え方にたどり着きました。
「ガイド」を適切に付加していくことで、必要なコンテキストをつくり、ナレッジがつながり、読み解けるようになるはずです。

ではコンテキストを生み出す「ガイド」とはなんなのか。どのようにしてつくっていくのか。
それはまた次回のエントリでお伝えしたいと思います。
それではまた来週、よろしくおねがいします。


このブログへのご意見、ご質問などをこちらで受け付けています!
感想など、お気軽にどうぞ!
フィードバックフォーム(Googleフォームが開きます)

高橋 悟志

TOP