組織で効率的に情報をアーカイブするには? メルカリの社内Wiki導入・運用法

 

組織の知識やノウハウをストック・共有するためには欠かせない、社内情報のアーカイブ。情報を可視化することで、コミュニケーションを円滑にできるだけでなく、情報伝達のためのコミュニケーションコストも削減できる。しかし、社内の情報共有システムがうまく機能せず、業務が回らないケースは少なくない。社内の情報を、どこに、どうやってストックしていくかは、さまざまな企業が抱える課題ではないだろうか。

それを解決するのが、社内の集合知を共有するツール「社内Wiki」だ。しかし、社内Wikiを機能させるには、情報を常にアップデートさせるなど、メンバー同士の協力が欠かせない。

企業規模が大きくなっても、活発に情報をストックし、共有していくにはどうすればいいのか。社内Wikiとして「Crowi(クロウウィ)」を活用しているメルカリのVP of Engineeringで、Crowi開発者でもある柄沢聡太郎(@sotarok)さんに、Crowiの導入方法と活用術について語ってもらった。

社内Wikiで検索すれば、問題解決できる状態が理想

現在メルカリの社内Wikiとして使っているCrowiは、ありとあらゆる社内情報がストックされています。有給休暇の申請方法や出張の段取りなどの業務マニュアルをはじめ、プロダクトの仕様や分析結果、過去に行った施策の結果レポート、さらには個人のメモや日報まで。全社員が記事作成・編集の権限を持っており、ほとんどの記事は、基本的にメルカリ社員であれば誰でも閲覧できます。

たとえば、「US 出張」というキーワードで検索すると、出張前に行うタスクや出国時の注意点、出張後のレポートの書き方についてなど、一通りの情報が得られます。業務中に「どうすればいいんだろう?」と迷ったら、Crowiで検索するだけでほとんどの問題が解決する状態を目指しています。

バラバラだった情報ストックツールをCrowiで一本化

そもそもCrowiは私が創業したクロコス【※】で、2012年に開発したWikiツールです。当初は社内ツールとして使っていたのですが、ヤフーに売却するタイミングでオープンソース化しました。
※ 柄沢さんは2014年11月に、株式会社クロコスをヤフー株式会社に売却。

メルカリでは、もともと「USWiki」「JPWiki」と利用エリア別にWikiを分けていたうえに、情報格納ツールも「Google Sites(グーグルサイト)」や「Qiita:team(キータ チーム)」など、エリア内でも部署やプロジェクトごとにバラバラでした。

ストックするツールが異なると、探している情報がどのツールにあるかわかりづらいうえに、ツールによっては専用のアカウントを持っていないとアクセスができません。そこで、社内にくまなく情報共有をするため、2016年にCrowiに一本化することにしました。

Crowiは動作が軽く、シンプルで一覧性が高いのが特徴です。試しに立ち上げて、一部の人に共有してみたところ、反応がもよかったので、そのまま全社導入しました。

社内ツールは導入ではなく、定着がゴール

Crowiを社内に広めるには、社内で「書くマインド」を醸成する必要がありました。社内Wikiは社員が記事の追加・更新を続けないとうまく機能せず、結果として使われないツールになってしまうからです。

そこでまず、コーポレートチームの総務や人事のリーダー、マネージャークラスの10人程度をピックアップし、「キーマン」としてSlack上でCrowiの使い方をレクチャーしました。

総務や人事部門は、勤怠のつけ方や会食の設定方法・精算についてなど、さまざまな手続きの方法や社内情報を全社員に伝える必要がありますよね。そんなコーポレートチームなら、積極的にCrowiを使ってくれそうだと考えたのです。

ここで重要なのは、各部署の立場から「今抱えている問題が、Crowiでこういう風に改善ができる」と、具体的なメリットを提示すること。さらに、各部門のニーズを満たすことです。

たとえば、CS(カスタマーサポート)部門からはCrowiの活用方法について多数質問があがりました。そこで、SlackにCSの各リーダーを集めたサポート用チャンネルを作成。CSはマニュアルを確認しながら顧客対応をするため、ツールによって業務効率が大幅に変わります。「200ページ以上ある対応マニュアルを再編したい」「階層内の検索機能が欲しい」など、部門の要望にあわせて機能を実装しました。

また、Crowiを積極的に使ってもらうために、Slackに「わからないことがあったらなんでもここで聞いてね」というCS専用のチャンネルを作成し、現在も私が質問に適宜答えています。社内ツールは、導入がゴールではありません。使い方を広めて社内文化にするまでは「やる」と言った人が責任を持ってやらなくてはいけないし、私自身もいまだに努力し続けているところです。

Wikiの書き方やページの作り方などをアドバイスするうちに、自分の書いた記事や、他部署のが書いた有用な内容の書かれた記事がSlackでシェアされるようになりました。すると、コーポレートチーム・プロダクトチームの垣根を超えて社内情報が一気に可視化され、情報の流通やコミュニケーションが円滑になりました。みんなが見えるところに情報を書き、それが部署を越えて全社に伝わっていくという好サイクルができ、能動的に情報共有するマインドが社内文化として定着してきたように思います。

大階層は利用エリア別、開発関連の情報だけは世界共通に

Crowiの記事作成にあたっては、「こういうふうに書かなくてはいけない」という厳密なルールは設けていません。しかし、「ページタイトルは日付で区切り、誰が見てもわかりやすくつける」「大階層(第1階層と第2階層)は勝手に作成しない」など、ざっくりとした決まりごとはあります。

弊社のWikiの階層は、まず<JP><US><UK>というエリアで区分しています。たとえば、JPの場合は第2階層に、<CS><Corp(コーポレート)><HR(人事)>といった項目が存在しています。

階層の区切り方で悩んだ部分もあるのですが、Crowi導入以前はエリアごとにWikiが作られていたので、そのままエリアで区切ることになりました。今のところ、この分け方がメルカリにとって一番自然な気がします。たとえば、日本オフィスに勤めている人が「勤怠のつけ方」を知りたいとき、グローバル共通情報ではなく「日本オフィスでの勤怠のつけ方」がわかればいいはずですから。

ただ、開発まわりは別です。第1階層にエリアごとの区分とは別に、開発担当者向けの<Dev>というカテゴリを設けています。複数のエリアで同じプロダクトを開発することがあるので、エリアに縛られない開発担当者用の枠組みを作ったほうが効率的だと判断しました。<Dev>内でのやりとりはすべて英語ですが、翻訳チームのサポートを受けながら、多くの開発メンバーが更新を続けてくれています。

図は参考例

<日付>で区切り、情報の信頼性を担保

国内出張時の〇〇の手配方法など、時間の経過にあまり左右されないマニュアル系の情報は<Corp>→<総務>→<国内出張>といった階層で区切り、情報をストックします。ただ、これらの情報もまれに変更されるものではある。ページ内に明示される更新日を、そこにある情報の信頼度の目安としつつ、「内容が古いな」と気づいたら、他の人が書いたページでも更新してもらうようにしています。

一方、個人メモや議事録、施策などの時系列に沿って増えていく情報は、<ページ名>→<日付>で区切って追加していきます。なので、たとえば、「/2017/04/」で検索すると、2017年4月に書かれたメモが存在するカテゴリを問わず、一覧で確認できます。

個人メモや議事録などは「 /第1階層/…/YYYY/MM/DD/ページ名」でストックする

情報整理とグローバルツール統合が課題

メルカリでCrowiを導入して1年たった今では情報量も増え、日々活発に更新されていますが、新たな課題も生まれています。それは、USやUKなどグローバルでの情報共有、そして情報の整理です。また、ツールとして使い続けるなかで、Crowi上のさまざまなページに同じような情報が存在し始めており、どれが正しいのかわからず混乱を招いてしまうケースも発生しています。

ほかにも、記事を追加するモチベーションを上げるために、書いた記事へのフィードバックが見えるようにして、「自分が書いた情報が見られている」と実感できる機能改善も検討しています。Crowiをインタラクションの起こりやすいツールにして、社内情報のアーカイブをよりスムーズにしていきたいですね。