社内WIKIにGrowiを導入してユーザー数が700人に届いた話
こんにちは、自動化アーキテクトの森川です。
アドベントカレンダーと言えばブログ、ブログといえばアウトプット、日ごろのアウトプットといえば日記かWIKIですよね。
ということで本日は去年の9月頃に技術検証をスタートして仮運用～公開まで1年ほどかけて育てた社内WIKIに関するお話をさせていただきます。
WIKI導入のきっかけ
会社の成長に合わせて組織がスケールしています。
技術部門だけでも3年で4倍、500～600名の組織になり、技術ナレッジや人とスキルの情報共有が追いつかないという課題が発生しています。
もちろんこれらについてはスキルマップの整備や、情報可視化が正式な施策として進められています。一方でエンジニア・コミュニティな目線では、ナレッジを気軽にアウトプットして共有する草野球的な場所がほしいなぁ、と思いました。
『そうだ、エンジニア向けの社内WIKIだ！』
と思い、社内をかけまわって承諾をいただいてWIKIのワーキング・グループを結成して活動を開始しました。
事前アンケートで仮説を立てる
事前にナレッジ共有や社内WIKIについてアンケートをとりました。
事前アンケートざっくりまとめ
ナレッジ共有の手段が確立していない（人に訊くか自力で解決が大半）
WIKIがあれば積極的に活用したいと思う方は65%
記事を書くことに対してポジティブな方は69％
WIKI運用の懸念点は「記事が増える気がしない」が最も多く、次に「記事が整理されないのでは？」
WIKIの必要性は認められるものの、ただ公開するだけでは駄目。
記事が増え続け使ってもらうための施策を考える必要がありました。
まず目的をさだめます。
WIKIの目的
暗黙知を共有して作業効率・スキルをベースアップしよう
可視化することでヒトtoヒトの風通しをよくしよう
知識のPDCAをまわそう
次に記事を書いてもらうための施策と、記事を書く人が増える施策を打つことで自走できるサイクルが確立されるはず、という仮説をたてました。
記事を増やす施策案
「何を書いても良い」を奨励
記事テーマを用意して記載を呼びかける
勉強会や社内ミートアップの資料置き場として活用
記事を書く人を増やす施策案
新人研修でアウトプット習慣づくりのツールとして導入してもらう
技術ブログの下書き記載場所として活用
ツール選定
タイトルのとおり、WIKIツールはGrowiを選択しました。
OSS開発wikiツールのGROWI | 快適な情報共有を、全ての人へ
WESEEKさんが手掛ける国内OSSのWikiツールです。
弊社ではMS Office365を採用しているため関連ツールを検討しましたが難しくて、運用コストのかからないOSS x オンプレから始めることになりました。
esaやQiita TeamといったSaaSも候補にはあがりましたが、やはりコスト効果がボトルネックでした。
ちなみにNotionは単なるWIKIとして活用するには多機能すぎると判断しました。
Office365製品については、以下のような意見があつまりました。
MS Teamsはナレッジ蓄積には不向き
アカウントやプロジェクト毎に分離しているので共有ナレッジを書きにくい
そもそもチャットツールなのでナレッジ向きじゃない
Share Pointは全文検索が思うようにいかない、手軽に見る習慣がない、編集したがらない
OneNoteは横断的な全文検索が思うようにいかない
Growiについてはポジティブな意見が多くて、嬉しかったです。
エンジニアフレンドリーで良い
将来の複雑な要望に対応できそう（タグ＆階層、グループ機能）
ソーシャルっぽい機能で良い（いいね、ブックマーク、PV、コメント）
システム構成
当初はdocker-composeで立てて数人で利用していました。
公開に際してCloudformationでIaC化して、GrowiアプリとMongoDBを冗長化しました。ECS化やMongo -> DocumentDB化しなかったのはコスト面の問題からです。(DocumentDBにSaving Plan適用されてほしい…）
システム構成イメージ
ID管理はSAML連携で認証
MongoDBは自前でレプリケーション構成を作成
ElasticSearch、HackMDはシングル構成
定量値
本運用から3ヶ月でいっきにユーザが200人 → 700人ほど増えました。
記事数からもわかるとおり、大半は見る専ユーザーです。
期間
計画～構築 : 3ヶ月
仮運用 : 9ヶ月（技術部門内のみで運用）
本運用: 3ヶ月（全社で運用）
ユーザ数: 750名
記事数: 約900記事
ビュー: 約7,000ビュー
※ 本稿執筆時点
実際どんな風に使われている？
技術ブログの下書き原稿や勉強会の教材の格納場所としての活用が目立っていました。
純粋なナレッジ記事も現れていますが多数派ではない印象です。
WIKI利用規約として顧客名などのセンシティブな情報の記載は禁止していますが、それでも懸念があるからか、気軽に技術ネタやディスカッションメモとして使うのはハードルがあるようです。
気軽さとパブリックは両立が難しいということだと思いました。
とはいえ、まずは使ってもらえる状態にする、というところでは一定の成功をおさめたと思います。
課題｜欲しかったのは解像度＆自由度の高いツールだった
「エンジニアが息を吐くように書いてほしい」
手を動かしてみたTipsや、勉強会のログ、独り言を気軽に残しておいて誰でも見れる。そんな解像度と自由度が高いアウトプットを想定していました。
しかしながら、弊社の場合は顧客業務が大半であること、WIKIの公開性は心理的安全性にいささか欠けることが障壁になっていることに気づきました。
解決法の一つとして、実験的にユーザーグループを作り、その壁が生み出す心理的安全性が記事の増加につながるかを検証してみたいと思いました。
WIKIに村文化を許容するべきなのか、は迷うところですが、書き慣れる文化を育てるほうが大事だなぁ、とも思います。
うまく行けばGrowiのAPIと社員DB（のようなもの）を連携してグループを自動生成できると良さそうです。
課題はまだまだある
小さくとも見過ごせない課題がいくつか出てきていました。 + 今後一つづつ、解決法や落としどころを見つけていきたいです。
お客様VPNに常時接続のプロジェクトメンバーはアクセスしにくい（社内WIKIは弊社VPN必須にしているため）
お客様の案件で得たノウハウを秘匿情報を修正してWIKI化するコストは採れない
WIKI書くならばブログを書きたい（弊社では技術ブログ執筆者にインセンティブが施されます）
まとめ
WIKIを導入して公開から3ヶ月で700ユーザ、900記事
Growiを選定
エンジニアが息を吐くように書くにはクリアすべき課題あり
実験的にユーザーグループを作って村WIKI化して、活性化を促したい
以上、社内WIKIの導入について記事化してみました。
こういったツールの導入はうまく行かず墓場行きになることもしばしばだと思います。どなたかの参考になれば幸いです。
それではみなさん、楽しいWIKIライフを！
＼クリスマスまで毎日更新！明日の記事もお楽しみに！／
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：森川 知雄
中堅SIerでテスト管理と業務ツール、テスト自動化ツール開発を10数年経験。SHIFTでは、GUIテストの自動化ツールRacine(ラシーヌ)の開発を担当。
GUIテストに限らず、なんでも自動化することを好むが、ルンバが掃除しているところを眺めるのは好まないタイプ。
さまざま案件で自動化、効率化によるお客様への価値創出を日々模索している。2021年からは技術イベントSHIFT EVOLVEの運営を主担当。司会は大の苦手。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/