はじめに
こんにちは。パーソンリンクアドベントカレンダー 2日めを務めさせていただきますshinoyuです。
1日めに引き続きよろしくお願いします。
弊社では、10月から社内ナレッジ共有を加速させる活動を始めました(｀･ω･´)
これまでもSlack上で散発的に行われていたのですが、共有や議論する人がごく一部に限られたり、クライアントワークで客先に行っているメンバーが参加しづらかったり諸々の課題がありました。また、Slack上だと流れていってしまう問題もありますよね。いざ後で参照しようと思っても探すのが結構大変だったり。
一番もったいないなと感じたのが、個々のエンジニアは各々で得意な領域がありそれなりの経験があるにも関わらず、社内での情報発信が少ないことでその能力が評価されづらかったり、他の人が知ってそうなところで嵌まり込むような光景を見ることがありました。
せっかく社内で出てきた議論をそのまま流すのはもったいない。
個々人が持っている情報をもっとオープンにし、そこから共有や議論を進めて、ストックしていく。個人だけでなく会社全体の資産にしてほしい。そういった思いで始めた活動です。
本日は、その活動の意味とどう進めているか？について語ろうと思っています。
そもそもナレッジ共有がなぜ大切なのか？
どうして情報のオープン化やナレッジ共有が大切なんでしょうか？
個人個人で異なる考えがあるのは承知の上で、私の考えでは大きく3つの効果があると考えています。
- 仕事で学んだ知識や身につけた知見をアウトプットすることで考えを整理し、より深い理解を得るため。
- 自分の得意な領域をみんなに開示することで、困った時にすぐ相談しあえ、より早く、より大きな価値に繋げるため。
- 自己のブランディング。自分はなにができる人か理解してもらい、活躍のチャンスに繋げるため。
まず、なにかの考えを理解すること。これが大変難しい。インプットだけですべてを理解することは難しいのです。ナレッジ共有としてアウトプットし、他の人に説明することができて初めて理解できたことになります。他の人に説明できるということはその概念を言語化できているということです。
そして言語化とは再現性です。得た知識をいつでも再現できる、活用できる。こうなって初めて知識と言えるのだと思っています。
この辺の理解を深めるためには、エンジニアの知的生産術をオススメします。去年かなり流行った本なので読んだ方も多いと思いますが、今読み直しても良い本だと思います。
次は自身の得意なことを開示していくこと。
要はせっかく仕事で色々学んだんだから、他の人にもそれを共有して、みんなで最高の仕事をしようぜ！ってことです(｀･ω･´)
私がこれまで居た5社を見ると、これが自然にできているところは社員の満足度が高く楽しく仕事ができていた記憶があります。知識を共有してみんながそれをできるようになれば、1人が作り出せる価値の総和がどんどん大きくなっていきます。
我々のようなクライアントワークの会社は、その価値をユーザーに届けることでお金をもらっているので、届けられる価値が増えれば増えるほど得られる利益も増えていきます。大きな結果を生み出すためにみんなの知識を活用でき、これまでより大きな仕事ができる。ぜひ目指していきたいですよね。
最後は自己ブランディングですね。
ちょっと話はズレるのですが、ここ最近ではエンジニアスクールなるものが目立つようになり、ITエンジニアへの参入者がどんどん増えていっています。実際弊社でも異業種からIT学んでエンジニアに転換しようとしている方とお話することがちょいちょい増えており、今後もこの風潮は加速していくんだろうなーと感じています。
そういう状態になったとき、自分の強みをどんどん発信していかないと数多くいるエンジニアの1人として埋もれていってしまいます。
どんなにすごい技術をもっている人でも、周りの人がそれを知ることができなければ価値を発揮することはできません。知ってもらわないと活躍することができない。だからこそアウトプットは重要なんですよね。
とはいえ、いきなり社外に発信してうまくやれる人は多くありません。今でこそ大分落ち着きましたが、以前はちょっとでも違うことを発信すると大量のマサカリが投げつけられていた時代。
そういう環境で臆すること無く発信し続けられる人は希少です。特に弊社は20代半ばくらいのメンバーが多く、アウトプットが大切だと分かっていても世の中に発信することを躊躇いがちです。
なのでいきなり社外に発信するのではなく、社内での発信をまずやってみる。社内であれば外より確実に安全性が高い場なので、そこで試しにやってみて徐々にできるようになっていく。その練習の場としても社内でナレッジ共有の場を作る意味は大きいと思っています。
長らくナレッジ共有の意義について書き綴りましたが、技術について語り合える場があることは何より楽しいです！楽しいから発信していく。議論していく。そういったエンジニア組織を作って、楽しく仕事していきたいですね(｀･ω･´)
なお弊社で定期的に開催しているもくもく会後の懇親会でそういう場を設けていたりするので、もし興味ある方いましたらいつでも遊びに来てくださいね。
何を使って共有を行っているのか？
さて、ここからはやり方の話です。
弊社ではknowledgeをAWS上にホスティングして使っています。
この活動を始めようと思った際に社内のエンジニアに相談したところ、以前構築したknowledgeが使えると聞いたので、それに乗かった形で始め、社員全員分のカウントを作成して利用し始めました。
特に記載内容に縛りを設けておらず、技術に限らず書きたいことを何でも書いてもらうようにしました。とはいえ最低限のレギュレーションは設けています。人を非難しない、公序良俗の欠ける内容は書かない、とか。
縛りを設けなかったのは「書く」というハードルを極力なくすためです。仕事に関係あろうがなかろうがまずは発信をしてもらうことを重視しました。
自分も勉強会のレポや、設計の話といった真面目な内容から、未だ実を結ばないダイエットの話とか、ランチの写真を貼り付けるだけの記事を書いたりしてます。発信とは習慣なのでまずは何でも書く。定期的に書き続けられることが何より大切で、まずはそこからやってもらいたいと思っています。
knowledgeの使い方については公式を見てもらうとして、knowledgeの優れているところは、わかりやすいUIと、閲覧などのアクションが可視化されるところですね。
一番気に入っているのは、Contribution Pointという指標で、投稿を見てもらったり他の人にコメントを送ることで数値が増えていきます。ゲーミフィケーション要素的なやつでよいモチベーションになります(｀･ω･´)
本来であれば、esaとかkibelaとかConfluenceとか、これまで慣れ親しんできたサービスを使う予定でした。しかし、まだ会社全体がそれを活用できるだけの動きができないので既存のツールを使って実践しています。まあ、根付くかわからない段階ではなかなかお金を取りに行く提案はしづらいですよね。費用が僅かだったとしても使われないと意味がないので...
しばらくはknowledgeを使い続けて発信する文化を構築した後、改めて他のツールの利用を考えようかなーと考えています。
普及を進めるにあたり自分がやったこと
ここからはどのように使い始めたか？についての話です。
他の会社から、エンジニア同士の情報共有の仕組み化をしているけれでどうまく行かない、という話を聞くことがあります。
最初ちょろっと使われて以降一部の人しか使わなくなるパターン...推進者も中々根付かないのでモチベーションが下がり、いつしか廃墟と化していくあれです(´・ω・`)
弊社では、初めてまだ2ヶ月程度なので成功したと言えないのですが、普及に向けて色々と活動してみたところ、投稿が少しづつ増え始めてきました。最初は自分しかアクティブなユーザーがいませんでしたが、今では大体４，５人が書いてくれています。大変ありがたいことです。
普及のために大きく４つの取組みをしてきました。
1. 推進者がひたすら使いまくる
仕事中にハマったことや書いたコードの説明等、気軽にガンガン投稿するようにしています。ピークだと1日3記事投稿しました。仕事ちゃんとしてるのか若干怪しくなるペースだと自分でも思います(ヽ´ω`)
推進者が使わないサービスを使ってくれることはほぼありません。一番のヘビーユーザーを目指して使い倒す。これを2ヶ月続けたことで少しづつ他メンバーの投稿が増えてきました。
この辺はプロダクト開発とも同じで、開発者が自分たちで使わないシステムは誰も使ってくれない。やはり自分が顧客となって使うからこそ顧客の欲しい物が理解できるのと似たような感覚ですね。
情報がないナレッジ共有ツールは望まれていない。やはり情報があり、それを投稿する人があってこそのナレッジ共有。
なので自分がガンガンコンテンツを作っていく。そうすると自然に他の人も投稿してくれるようになります。そういうサイクルが無事生まれてきたので一安心しています。
なお、コンテンツを作っていくのに、個人的にやってる分報が大分貢献してくれました。その時の作業状態を記録していくとそれを整理するだけで1記事はすぐ作れてしまいます(｀･ω･´)
これも一種のアウトプット。分報の普及も狙っていきたいところですね。
2. 見る人にとって価値のある記事を意識する
ただ薄い記事を大量生産しても使ってもらえません。「使える情報がある」ことが求められているものだからです。
なので1投稿1投稿、ちゃんと記事の内容を精査して関連情報のリンクを用意する。1記事書くのに30分-1時間くらい掛けて書いているのでそこそこ負担が大きいんですよね...
とはいえ、ちゃんと記事を作っていくと他の人も倣ってくれるようになります。参考情報がしっかりついた記事が増えてくるとよりアウトプットの質が増し、有益な情報が集約されていきます。
このサイクルを生み出すため、ある程度記事には力を入れた方がやりやすいかと思います。
3. 業務に関わる情報を書くために使ってみる
利用せざるを得ない形にしてしまう手もあります。
自分の場合だと新規入社者への会社設備説明資料だったり、プロジェクトのサーバー構築手順をknowledgeに投稿したりしました。
入社者に予めアカウントを発行しておき、入社と同時にアナウンスする。そこにしか情報がない状態にして、閲覧から使ってもらおう、という狙いがあります(｀･ω･´)
まずは見てもらって慣れてもらう。発信するにしてもまずはツールの使い方を理解してもらう必要があるのでまずは閲覧から、といった運用を実施しています。
4. 強制はしない
どこかの本で読んだのですが、「人は自分がやりたいことしかしない」生き物です。
ナレッジ共有もそれだと思っていて、強制的にやらされてもいいアウトプットにはなりません。各々が好きなタイミングで投稿してもらえればいいので、評価に組み込むとか、無理やり書かせるとかそういったことは避けるようにしています。が、声掛けは結構していますね...
弊社では週1回、週報と言う形で前の週の出来事をSlackに報告してもらっているのですが、そこで書かれていた報告でナレッジにできそうな話題があれば「めちゃくちゃいい話なのでknowledgeに投稿してください！」と常々コメントを投げかけています。
最近は促しをやりすぎて、週報全レスおじさんと化しつつあるので、もうちょっと自然な感じで誘導できるように気をつけていきたい....
終わりに
こういった文化を作っていくためには推進力をもった人がグイグイやっていくことがなにより大事です。
そういう人が自ら自分が一番のユーザーとして使い倒し、それを周りに広めていく。地道な活動から染み出して組織に浸透しきったものこそ、「文化」だと思うのです。
そういった気持ちをもって、これからも引き続きナレッジ共有の文化を作っていきます(｀･ω･´)
またうまく行った試みなどあれば随時共有していきます。
明日の、パーソンリンクアドベントカレンダー 3日めはshinoyuです。
引き続きよろしくおねがいします。
明日は、開発を加速させるためにDockerを整理した話を書きたいと思います。