SECIモデルと組織における情報共有の課題 このエントリをはてなブックマークに登録

2016年11月02日

amachinamachin /

はじめに

弊社ではDocBaseという組織向けの情報共有・ドキュメント共有ツールを開発、運営しています。

組織内の情報共有については、どのような組織でもレベルの差はあれ、情報共有は行っていると思いますが、「うまく機能しているのかわからない」ということが多いのではないでしょうか。また「全然足りていない」と感じている人も多いと思います。

今回はチームや組織における情報共有の目的や課題について、私なりに考えたことをお伝えします。組織での情報共有について見直すきっかけになればと思います。

情報共有の目的

他にもあると思いますが、一つ選ぶとすれば組織の成長のためだと考えました。ここでの成長は規模の話だけでなく、組織やチームの総力の成長でもあります。

では組織の成長とは何でしょうか? 私が考えたのは『個人の知識が集まって組織の知恵となり、その知恵が個人の知恵となり成長を促し、組織全体の力が大きくなっていく』ということでした。そもそもDocBaseを開発したのも組織内にある暗黙知をうまく共有できれば組織全体の力が上がるはずだと考えたからです。

そんなときに知ったのがSECIモデルです。

SECIモデル

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 平鍋 健児 (著), 野中 郁次郎 (著) で、SECIモデルとは「知識というものがどのように発生して成長するかを暗黙知形式知という二つの知識形態を螺旋として捉えたものである」と書かれていました。

23935338-e9c4-43d4-97df-cb64792dc087

SECIモデルにある4つのプロセスの説明と、組織の中でのどんな活動に当たるのか考えてみます。

共同化 (Socialization) (暗黙知→暗黙知)

個人が組織の中で暗黙知を共有する活動である。個人が持っている暗黙知を、共同で作業をしていく中で他人に伝え、組織の協同の暗黙知とする。(P.230)

情報共有ツールではサポートするのが難しい部分です。例えば弊社のようなソフトウェア開発企業ですと、次のような部分になるのかと思います。

  • コードレビュー
  • ペアプログラミング
  • 朝会
  • ふりかえり

表出化 (Externalization) (暗黙知→形式知)

個人や組織内で持っている暗黙知を分析し、文書化することで形式知に変換し、伝達可能な形にする活動である。これまで言葉になっていなかった暗黙知を言葉で語り、対話や思索を通じて文章や図、あるいは仮説の形に想像するのである。(P.230)

情報共有ツールでサポートしやすい部分です。
弊社ですと次のような情報を暗黙知から形式知に落とし込んでいます。

  • コーディングルール
  • 技術ドキュメント
  • インフラ情報
  • データ分析

情報共有ツールでは情報の作成と周りへの通知、その後の対話や思索をしやすくといったことをサポートしています。

  • 手軽に情報を作成できる
  • Slackなどの外部サービスとの連携
  • 編集履歴やコメントによる思索や対話

連結化 (Combination) (形式知→形式知)

形式知同士を組み合わせたり、編集したりすることで、知識を体系化し新しい知識を生み出す活動である。・・・既存の形式知から、さらに新しい形式知が生み出される。(P.230)

連結化も情報共有ツールでサポートしやすい部分です。

  • カテゴリ、タグ、メンバー毎など様々な形で情報を整理
  • 目的の情報を探しやすい
  • 情報の重要度がわかりやすい

その他、DocBaseではドキュメントの中に、別のドキュメントを差し込める機能があり、形式知同士を組み合わせて、体系化しやすくしてあります。(例:DocBase APIドキュメント

内面化 (Internalization) (形式知→暗黙知)

新たに生み出された形式知を、今度は個々人の暗黙知として取り込む活動である。・・・行動で通じて形式知を具現化し、実践することで、身体で理解・学習していく。新しい暗黙知を獲得することで、個人は階段を一段上がる。(P.231)

情報共有ツールではサポートするのが難しい部分だと思います。「どの情報が自分にとって重要なのかをわかる」「暗黙知として取り込みやすくする」などのサポートはできるかもしれません。

組織における情報共有の課題

SECIモデルで組織の成長を促すための情報共有については理解しやすくなりましたが、課題がいくつかあると考えていました。

  • 関係者全員で情報共有できない
  • 組織全体で活用できない
  • ドキュメント作成の労力が大きい
  • そもそも共有する気が起きない

関係者全員で共有できない

プロジェクトには様々なメンバーが関わっています。職種の違いもありますし、組織外のパートナーやクライアント、またはアルバイトやインターンなど。

例えば社内で使っている情報共有ツールがあったとしても一部の人が使っているだけで関係者全員が使っていないと結局メールになってしまったりします。また職種によって慣れているツールが違っていて、情報のフォーマットがバラバラになってしまうという問題もあります。

組織全体で活用できない

あるプロジェクトで他のチームにも役立つ情報が共有されたとしても、プロジェクト内に閉じてしまう場合が多くあります。また部署毎に使っているツールが違っていて、組織を横断して情報共有できないといった問題もあります。

ドキュメント作成の労力が大きい

チームメンバーに共有するためのドキュメントを書こうとすると正しく、きちんとしたドキュメントを作らないといけないと構えてしまいます。そのため、下書きのママになってしまったり、良質な情報でも「小さな情報」は共有しづらくなってしまいます。

そもそも共有する気が起きない

共有する気が起きない理由には次のようなものがあります。

  • 書いても反応ないし
  • みんな知ってる情報だと思う
  • 粒度や共有先がふさわしくない
  • 大人数の場に投稿するのが怖い

情報共有を活発にする。組織全体で活用していく。

やはりツールだけではうまく活用することは難しく、SECIモデルの共同化と内面化を促してSECIモデルのサイクルを回していく組織の仕組み作りが必要だと思います。さらに言えば、個人と組織の成長を見えるような仕組みができれば最高ですね。

次回は「組織の情報共有の改善」について考えてみたいと思います。

DocBaseについて

DocBaseは今回挙げたような課題の解決と情報共有を活発にして組織が力を最大限発揮できるようにすることを目指した情報共有・ドキュメント共有サービスです。

詳しくはこちらから。
https://docbase.io

acfe5f7d-fac5-40de-9a75-554cbee0dfe2

関連記事

クレイについてもっと知りたい方は…

  1. クレイの3つの強みを見てみる。
  2. WEBシステムのことなら何でもご相談ください。

「いいね!」で応援よろしくお願いします!

このエントリーに対するコメント

コメントはまだありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)


トラックバック

we use!!Ruby on RailsAmazon Web Services

このページの先頭へ