Kibelaでナレッジマネジメント始めました

0
1,233 ビュー

とある開発者の朝


会社行く前にツイッター見よっと

へー、こんなサービスあるんだ。うちでもやってみたいな。

ピコン

あ、これツイッターで見たやつじゃん。

カタカタカタカタ

まあ、でも社長を説得するのは大変そうだなー

ピコン

!!??


申し遅れました。(株)スパインラボでコドモンの開発に従事しているハヤシと申します。

弊社では、数日前にこんなやり取りからKibela(ナレッジマネジメントツール)を導入することになりました。
ぼくは、強い組織はナレッジマネジメントが優れていると考えていて、まだ社内でナレッジマネジメントがされていなかったこともあってツールを探していました。
そんな時に、上記のような流れから代表の小池にKibela導入を進言し、言い出しっぺということでその運用を任されることになったため、今回は導入の背景と野望について書きたいと思います。
まだ手探り状態なので、すでにナレッジマネジメントがうまく行っている先輩企業さんからアドバイスを頂けたら有り難いです。

弊社代表小池も「イケてる企業はイケてるツールを使う」と考えていて、ナレッジマネジメント以外にも効率化・自動化を考えてツールを探しています。
社内で片手間に独自ツールを作るより、サービスとしてツールを作っている会社の製品の方が良いに決まっています。
他に任せられることは任せて、全リソースを自社製品であるコドモンの開発・運用に注いで日々コドモンをより良い製品にしています。

また、ターゲットとする業種・業務は違えどSaaS(Software as a Service)という観点では他社の製品とコドモンは同じ枠組みです。
単に利用者としてツールを使用するだけでなくサポート体制や画面・機能の作り方など、参考になることは多くあります。
他社製品の良いところを吸収してコドモンの開発・運用に活かしています。

課題感(なぜKibelaを導入しようと思ったのか)


現在弊社では、一部エンジニアを除いて知識や情報をドキュメントに残すという習慣がありません。
そのためメンバーがこれまで経験して得た知識が暗黙知として埋もれ情報の属人化が発生しています。

今は会社も小さく社員数も20名ほどなので全メンバーが1フロアで仕事をしています。
なので、分からないことがあればすぐに聞くことができます。
ただ、今後会社の規模が大きくなっていくと今までのようには行きません。

会社の規模が大きくなると部署ごとにフロアが分かれたり、顔を合わせたことのないメンバーも出てきます。
その際にドキュメント化の仕組み作りがされていなければ個人の知識を組織として活かせず組織力が低下してしまいます。

問題としてはまだ表出していませんが、問題が顕在化する前の今。
組織として小さく、開発も営業もバックオフィスも皆が同じフロアにいる今だからこそ。
今後の会社組織としての発展のためにドキュメント化の仕組み作りと文化形成が必要だと考えました。

ツール選定理由(Kibelaにした理由


「ナレッジマネジメントの重要性はわかった。じゃあなんでKibelaにしたの?」という質問にこれから答えます。
それは、後述の最低限必要な要素を備えている上でKibela独自の機能が気に入ったからです。

最低限必要な要素

  • 使いやすい
  • 記事をエクスポートできる
  • マークダウン記法に対応している

上記の3つがツールを導入する際に最低限必要だと考えた機能です。
1つ目は「使いやすい」ことです。
ツールへの投稿は必須ではないので、ユーザーが使いにくさを感じてしまうと投稿してもらえません。
メンバーに毎日利用してもらうためには使いやすさが1番大事です。
無料版で使ってみてデザインも洗練されていて使いやすかったのでKibelaにしました。

2つ目は「エクスポート機能がある」ことです。
導入の初期段階でメンバーが1番気にするのが他ツールにナレッジを移すことができるかどうかです。
まだ正式導入ではなく試験導入期間のため、他ツールに移せないと書き損になってしまう恐れがあります。
エクスポート機能があることで書き損にならないと説得できるのでナレッジの投稿をしてもらいやすくなります。

3つ目は「マークダウン記法に対応している」ことです。
ツール導入の際に1番味方にも敵にもなりうるのが開発者です。
彼らが普段使っているGithubなどのツールではドキュメントはマークダウン記法で書きます。
開発者を味方につけるためにもマークダウン記法に対応していることも重要だと考えました。

気に入った要素

個人的に1番気に入ったのがKibelaのBlog機能です。
Kibelaでは投稿がWikiとBlogの2種類あり、個人のノウハウなどはBlogとして投稿することができます。
Wikiだとオフィシャル感があり、投稿や編集を気軽にできない人もいます。
せっかくナレッジマネジメントツールを導入してもナレッジが投稿されないと意味がありません。
KibelaではBlogという形式があり気軽に投稿することができます。

また、ナレッジの共有への貢献が可視化されることも気に入りました。
ドキュメント化の大事さを理解してもらえても中々実践されないという悩みを持った人は多くいると思います。
個人的には、それを評価という観点から解釈すると分かりやすいと考えています。
ズバリ、ドキュメント化は労力のわりに評価されない仕事なのです。
せっせと社内Wikiにドキュメントを残している人よりも、口伝で情報を伝える人のほうが頼られて仕事ができると評価されるのはよくある光景だと思います。

KibelaではWikiやBlogを何件投稿したかを見ることができます。
良いと思った投稿にはいいね!をつけることもできます。
なのでドキュメント化への貢献が可視化され、従来は評価されづらかったドキュメント化という仕事を正しく評価することが可能になります。
これがドキュメント化のインセンティブとして働きます。

運用してみて


今週の火曜日にKibelaを導入したいと言ってその日のうちに導入したのでまだ3日しか経っていませんが、運用してみての感想です。

意外とみんな好意的

CS(カスタマーサクセス)の方など非エンジニアの方も自発的にWikiやBlogを投稿してくれています。
インターンの子も含めて3割程度の方が1件以上投稿してくれました。

ハヤシ、サポートセンター化

当たり前といえば当たり前なのですが、Kibelaについての質問が全部自分に来ます。
必死でKibelaの使い方のドキュメントを読み漁って回答しました。
それでも分からないものや要望などはKibela上から問い合わせをしました。
CEO自ら回答してもらえるなど、とても丁寧にかつ迅速に対応してもらえて大満足です。

二度手間問題

エンジニアの中にはGithubにドキュメントを残している人もいました。
そいういう人にとってはGithubとKibelaの両方に書きたくないと考えるのは当然です。
それでもKibelaに投稿してもらうことが大事だと考えて、万が一の場合は自分が書き写すからと説得してKibelaに投稿してもらいました。

もちろん懐疑的な意見も

もちろん懐疑的な意見もありました。
社内で頂いた意見を抜粋して紹介します。

  • ドキュメントは書いはいいもののメンテナンスされずに情報が古くなってしまう
  • たくさんドキュメントがあっても活用されない。現在Githubに残しているWikiもあまり活用されていない。
  • ドキュメントを探す手間で逆に効率低下する

健全な懐疑的な意見が出ることはとても良いことで頂いた意見を真摯に受け止めて今後の運用に活かしていきたいです。

これからの課題と野望


課題(これから解決していかないといけないこと)

社内で頂いた意見にもあるようにツールを導入することがゴールではありません。
ナレッジを蓄積しても「見る人」と「見ない人」がいます。
メンバーの教育も含めてドキュメント化の文化を根付かせていく必要があります。

ハヤシの野望

メンバー全員が「困ったらまずKibelaを検索する」ようにしたいです。
そのためにこれからやろうとしている施策は以下です。

    • 日報もKibelaに投稿してもらう

現在はSlackで日報を共有しています。
ただ日報もノウハウとして共有していけると思うのでこれからは日報もKibela上で共有したいです。
また、日報をKibela上で書いてもらうことにより毎日Kibelaを開く習慣がつきます。
Kibelaで日報を投稿するとSlackに通知が行くようにして現在は有志数名がKibela上で日報を書いています。

    • Wikiの整備

Wikiのテンプレートやフォルダ構成を整備します。
これは、今後ナレッジが増えていった際に目的の情報を見つけやすくするための施策です。

    • 直接攻撃

まだ投稿をしていない人、投稿が少ない人に直接依頼します。
初めの一歩が肝心で、まず1つ投稿をさせることができればそれ以降の投稿のハードルが下がります。

 

最後までブログを読んでいただきありがとうございました。
とりあえず2ヶ月間は無料でKibelaのStandardプランを使えるのでその間にKibelaを使い倒します。
2ヶ月間使ってみての感想などはまた別途ブログとして書きたいと思います。