この記事は、Merpay Tech Openness Month 2023 の9日目の記事です。
はじめに
こんにちは。メルペイのバックエンドエンジニアの@tanaka0325です。
この記事では、私が最近サイドプロジェクトとして取り組んでいる「なめらかなナレッジシェアリング文化を創る」ための活動について紹介したいと思います。
事前に断っておきたいこととして、このプロジェクトはまだ始まったばかりです。プロジェクトメンバー全員がサイドプロジェクトとして参加しているので、これから少しずつ進めていくものになります。
今回は私たちがどのような活動を行っているのか、現状の状況や今後の方針についてお話できればと思います。
※この記事では表記ゆれを避けるため、資料やコンテンツ、知見などをまとめて「ナレッジ」と表現することとします。
きっかけ
まずは、この活動を始めたきっかけについてお話したいと思います。
日々仕事をしていくなかで求められるスキルはたくさんあります。また、求められるスキル以外にも個人的に身につけたいスキルもたくさんあります。
ひとつずつ学んでいく必要があるわけですが勉強は大変です。できるだけ効率よく学びたいものです。
メルペイには優秀な人達がたくさんいます。集合知を活用していくことで効率的に学習できるのではないかと考えました。
みんなの持っているナレッジを何かしらの形にし、それを教材にできるとよさそうです。いわゆるナレッジシェアリングの仕組みが必要でした。
もちろん私がこんなことをいうまでもなく、すでに社内には当然のように学習に使えるナレッジがたくさんあります。しかし現状ではうまく有効活用できている実感がありません。今よりももっとなめらかにできるのではないか？と思いはじめました。
上記の課題感を当時のマネージャーとの1on1で話した際に、一緒にやろう！となったのが、この活動を始めたきっかけです。
求めるもの
自分が求めている「ナレッジシェアリングの仕組み」とはどのようなものなのかを考えたとき、いくつかの条件が見えてきました。
- 個人のペースに合わせて学べるようになっている
- ルールが存在し、一定の品質が担保されている
- 内容が古くならないように、必要に応じて更新される
- 一部の人だけでなく、みんなが有効活用できる
個人のペースに合わせて学べるようになっていてほしい
ナレッジにはいくつか種類があります。
たとえば、新しく参加したメンバー向けのオンボーディング資料や新人研修資料、機能の詳細を知るための仕様書、知識を定着させて使えるものにするためのハンズオン。形式についても、動画、リアルタイムの講義やハンズオン、テキストなどいろいろと考えられます。
今回は、私自身がそのナレッジを使って学習したい、という気持ちがあるので、新人向けやオンボーディング資料は適しません。私は新人ではないのです。
また新人とは異なりすでにプロジェクトにアサインされているためいくつかタスクを抱えており、学習に使える時間が限られているので「4時間の研修です！」といったものは厳しいです。
自分のペースで学べるよう、動画かテキストの形式がよいです。
ただし、動画は作成の負荷が高い上、何度も見返すには早送り/巻き戻しを駆使する必要があります。作業負荷や使い勝手を考慮するとテキストが良さそうです。
ちなみに弊社には新人向けのナレッジとしてDevDojoというものがあります。
いくつか公開されているものもあるので、もし興味があればこちらの記事を参照ください。
メルカリの2023年技術研修DevDojoの資料と動画を公開します！
ルールが存在し、一定の品質が担保されていてほしい
前述のとおり、すでにメルペイには学習に使えそうなナレッジが数多く存在しています。
しかし、それらは全体的なナレッジシェアリング目的で作られたわけではなく、各チームのオンボーディング資料であったり新人研修資料であったり各人の学習メモであったり、多種多様な目的で作られてきたものです。
当然フォーマットも情報の粒度もバラバラです。さらにメルペイでは歴史的経緯によりナレッジシェアリングツールが複数存在しており、上記のナレッジが書かれている場所もバラバラです。
学習効率という観点ではフォーマット/情報の粒度/場所は統一されているほうがよいので、特定のルールにそって管理されていてほしいです。
次のような状態になっていると自分は嬉しいです。
- 分量が必要十分であること
- フォーマットが決まっていること
- 何を書いて、何を書かないかが決まっていること
分量が必要十分であること
情報が少なすぎると、それだけを読んでも十分な知識を身につけることはできません。
逆に多すぎると、学習負荷が上がり最後まで読むのが大変です。学習する対象が複雑であれば分量が増えていくのはある程度仕方がありませんが、その場合はちょうどよい量、たとえば初級/中級/上級など、で分割されていたほうがよいです。
また分量が多く学習負荷が高い状態になってしまっている場合、もしかすると公式ドキュメントや書籍で学習したほうが効率がよいかもしれません。
匙加減が難しいところではあります、それを読むことでまぁなんとなく理解でき、ある程度仕事はこなせるくらいの知識が身につく。そしてより深く知りたい場合に公式ドキュメントを読む際の下準備が整う、くらいの分量/情報量になっていると良さそうに思いました。
フォーマットが決まっていること
読み手目線ではフォーマットが決まっているほうが読みやすいです。たとえばすべてのナレッジの一番最初は概要を書く、次に目次を書く、など。
これがあることで、読み手の中にメンタルモデルが形成され、読む際の認知負荷が下がります。
書き手目線ではフォーマット、つまりテンプレートがあることで書きやすくなります。0から書き上げることは大変です。テンプレートが用意されていれば文書構造を考える必要がなくなり書く難易度がぐっと下がります。
何を書いて、何を書かないかが決まっていること
前述のとおり、歴史的経緯によりメルペイには複数のナレッジシェアリングツールが存在しています。ツールが複数存在していること自体は個人的には問題ではありません。それらツールの使い分けにルールがないことがややこしくしているのだと思います。
たとえば、仕様書はツールA、Design DocはツールB、作業メモや個人メモなどはツールCなど使い分けがなされているのであれば、複数ツールが存在することはむしろ好ましいとすら思っています。
しかし使い分けがされていない状態だと目的のドキュメントにたどり着くためには、極論するとすべてのツールで検索し、探しだす必要があります。さらに仕様書のような確定情報が見たい場面で、個人の設計メモのような情報が出てくるかもしれません。
何を書いて、何を書かないかを決めることで、必要な情報にアクセスしやすくなるはずです。
他にも細かいルールについてはいろいろと考えられますが、重要なことは「ルールが存在し、一定の品質が担保されている」ということです。
内容が古くならないように、必要に応じて更新されていってほしい
これはいわずもがなでしょう。すでに古くなってしまった情報を参照してつらい思いをする人を減らすために、何かしらの仕組みがあってほしいです。
よくある工夫としては、最終更新日から一定期間が経過した記事には読み手に注意文が表示されたり、書き手に更新を促す通知が飛んだりなどが考えられます。
手段は何でもよいですが、内容が更新されていってほしいです。
一部の人だけでなく、みんなが有効活用できていてほしい
メルペイにはたくさんのチームが存在しています。マイクロサービスアーキテクチャを採用しているので、それらのチームが独立して開発・運用しているケースが多く、チームを跨いだコミュニケーションは少なくなりがちです。
チーム内に閉じたナレッジシェアリングに関してはうまく運用できているチームはあると思います。しかし別チームを巻き込んでの共有まではあまりできていない印象です。
各チームが運用しているマイクロサービスは共通の技術・インフラを使用しているので、身につけるべき知識やつまづきポイントなども共通なことが多いです。
自分や自分のチームのみならず、みんなが活用している状態になっていると、全体的なスキルアップ/業務の効率化が測れそうです。
これまで
ここまでで、自分がこの活動を始めたきっかけ、そしてどのようなものを求めているのかについて紹介してきました。
次にこれまでに何をやってきたかについてお話します。
仲間集め
まずはじめにしたことは仲間集めです。「きっかけ」にあるとおり、最初のメンバーは自分と当時のマネージャーの二人です。この活動をするには単純に人数が少ないですし、チームを跨いだナレッジシェアリングを目指していることを考えると、別チームの人もいたほうがよいです。
しかしプロジェクトの初期段階で多くの人を集めてしまうと、認識のすり合わせをするだけでも大変になってしまいます。最初はある程度絞って声をかけることにしました。
最終的には自分たち含め、同じ課題を感じていた5人のメンバーでやることになりました。
認識のすり合わせ
次にしたことは目指すゴールの認識のすり合わせです。それぞれがどんなものを作りたいかを持ち寄り、議論を重ね、最終的に全員で共通の認識を持ちました。決まった内容はおおむね前述の「求めること」に書いたようなことなので、具体的な内容は割愛します。
ものすごく簡単に説明すると、次の二軸をやっていくぞ！といった内容です。
ナレッジシェアリングをする「場所作り」
特定の誰かが頑張ることなく運用されていく「文化作り」
OKR作成
前述の決めたゴールをもとにプロジェクトのOKRを作成しました。Objectiveはこのブログ記事のタイトルでもある「なめらかなナレッジシェアリング文化を創る」です。
ナレッジシェアリングの場所を作るだけでは意味がありません。社内にはすでにたくさん書く場所があるのです。大事なのはそれが適切に回っていくような文化を創ることです。
プロトタイプ作成
次にナレッジシェアリングをする場所、ようはナレッジシェアリングツールをどうするかを決めました。大前提として、このツールをゼロから自分たちで開発する必要はないと思っています。すでに世の中にはたくさんのよいツールがあります。
重要なことはしっかりとルールを作り、そのルールにそって運用することです。ルールが曖昧なままでは、仮にどれだけよいツールを使っても上手くいかないと思います。
まずはシンプルなツールを選ぶことにしました。使っていくうちにいろいろと希望が出てくるかもしれないので、プロトタイプとして気軽に試せることが大事です。
ちなみに選択したものはMkDocsです。次のような点から選びました。
- すでに社内で実績がある
- Git管理できるので、GitHubのレビュープロセスが使える
- ドキュメントが単純なmarkdownファイルなので、今後別のツールに移行しやすい
- plugin機構があるので、カスタマイズできる
そしてちょうど今現在、プロトタイプを絶賛作成中です。
次の項目の「ルール決め」と同時並行で進めている最中になります。
ルール決め
前述のとおりこのプロジェクトでもっとも重要なことは、しっかりとしたルール作りです。とはいえ実際に手を動かしてみないとよいルールは浮かんでこないです。プロジェクトメンバーで実際のコンテンツを作りながらルールを考えていっています。
ルールの大枠の方針は、前述の求めるものを満たせるようなものを検討しています。
これから
改めて今現在の進捗状況は次のとおりです。
- ナレッジシェアリングツールのプロトタイプ作成中
- 実際にコンテンツを作成しながらルール策定中
今後はこれらが揃ったタイミングで、改めて実際に本番で想定している運用をプロジェクトメンバーで回しながらブラッシュアップしていくつもりです。
ある程度納得できる状態になったら、トライアルという形で、社内で協力者を募集しようと思っています。
ただしこのあたりは進むにつれ、その都度検討しようと思っているので大いに変わる可能性はあります。
おわりに
この記事では、私が取り組んでいる「なめらかなナレッジシェアリング文化を創る」ための活動について紹介してきました。
組織が小さいときはうまくいっていたことでも、大きくなるにつれ自然には回らないことが増えてきました。ナレッジシェアリングもそのひとつです。今後組織がより拡大し、成長を続けるためには必要な活動だと思っています。
この活動はまだまだ初期段階です。これからプロジェクトが進むにつれて今までとは違った新たな気づき、知見が得られると思います。その際は改めて何かしら紹介できたらと思います。
明日の記事は @Amit.Kumarさんです。引き続きお楽しみください。
