Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！

この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！

Tebiki社のDiscussionsとは？

Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。

TebikiのDiscussions

Discussionsの運用ルール

Discussionsを運用するにあたって、以下のようなルールを作っています。

特に重要なルールは、

・Slackの会話で、みんなに共有した方が良さそうなルールが見つかったらDiscussionsのQ&Aに起票する。（Slackの会話のリンクを張る）

・Pull Requestで指摘された内容のうち、レビューイが重要だと感じた内容はDiscussionsのQ&Aに起票する。（指摘コメントのリンクを張る）

このようなルールにより、放っておくと埋もれてしまう知識をDiscussionsに蓄えています。

また、Tebiki社では、onboarding というラベルを作りました。入社時につまずきやすい内容やドメイン知識に関するQ&Aには、onboardingラベルを貼り、新人が見るべきQ&Aが一目で分かるようにしています。

Discussionsの効果

Discussions導入前は、SlackのやりとりやPull Requestでのコメントでチーム内の知識が共有されていました。しかし、Slackでの会話, Pull Requestのレビューによるやり取りでは、それぞれ次のような課題がありました。

Slackの会話だと、時間経過により会話が流れてしまい、後から見直すことが難しくなります。そもそもチャンネルに参加していないメンバーは会話内容自体に触れることができません。

また、Pull Requestのコメントによるやり取りだと、レビューイ、レビュアー以外がPRを見ることが少ないため、せっかくの指摘事項がチームに共有されないまま閉じてしまいます。

一方で、Discussionsを導入後は、これまで流れていた知識のうち重要なものがQ&Aとして残るようになりました。これにより、一度誰かが発見した知識にチーム内の誰もがアクセスできるようになりました。

文章化するコストを小さくできる

弊社でも設計書や社内ルールをドキュメント化する仕組みはありました。（イメージとしては、esaやQiitaなどのMarkdown記事です）。これらは、内容を構造化して文章を書く必要があるため、書き手にとって、記事を作成するのがおっくうになるというデメリットがありました。

一方、DiscussionsのQ&Aであれば、残しておきたい内容を一問一答形式で書けば良いので、ドキュメント化するよりも短時間で終わります。

実際、社内でもDiscussionsのQ&Aが作成されるペースは、社内ドキュメントの作成ペースよりもはるかに早いです。

暗黙知の撃退

また、Discussions導入前には、チーム内に複数の暗黙的なルールがありました。そのため、新しく入ってきたエンジニアが、暗黙的なルールを知らずに実装し、レビューで何度も差し戻されるなどの非効率な場面が見られました。

そこで、社内のエンジニアにとっては当たり前だが、新人にとっては困惑するような暗黙的なルールが見つかった時は、都度Discussionsを起票しました。Discussionsがチーム内の暗黙知を形式知に変換するきっかけにもなっています。

Discussionsをどのようにチームに浸透させたか？

ここからは、Discussionsをどのようにチームに浸透させたか？についてお話しします。

出発点

この活動は、私のオンボーディング時の経験から始まっています。

私がTebiki社に入社したのが、2021年10月（この記事の約半年前）なのですが、入社直後の1~2ヶ月あまりは、実装がなかなか進まず苦しい時期を経験しました。同じ失敗を繰り返さないように、当時の指摘事項を個人的にメモしていました。

その中で、私が知らなかった内容や、つまずいた箇所をあらかじめ共有できる仕組みがあれば、今後入社される方がもっと楽にオンボーディングできるのでは？と考えました。

そこで、GitHubのDiscussionsに、一問一答形式でQ&Aをたくさん作るのはどうか？とチームに提案し、言い出しっぺの私がDiscussionsを書くことから始めました。

まず、私がこれまで個人的に記録していたメモをDiscussionsのQ&Aにひたすら転記しました。1日2個ペースで、約2週間。計20個程度できました。

次に、「これは新人向けだな」と思うものには、onboardingラベルを貼って完成です。

お披露目

その翌週、週次ミーティングでDiscussions一覧ページをメンバーに公開しました。メンバーから「良さそう！」と好反応をもらえて嬉しかった記憶があります。まずは、チームでゆるくDiscussionsを活用するという流れになりました。

徐々に浸透

お披露目から1ヶ月程度すぎると、徐々にメンバーからも、「これDiscussionsに起票した方が良いのでは？」という声が上がるようになり、他のメンバーによる起票も増えてきました。

もしかしたら、最初に書いた20件のDiscussionsが、他のメンバーが書く時のサンプルになったのでは？と思っています。

現在

DiscussionsのQ&Aを起票するだけでなく、回答がイマイチだな〜と思う時は、回答を追記して、Discussionsを洗練させる文化ができつつあります。

また、質問に回答する時も、これまではSlackに回答を直接書いていたのですが、Discussionsのリンクを共有することが多くなりました。

今後の展望

今後は、オンボーディングを利用して、Discussionsの内容をさらに洗練できたらと思っています。

具体的には、入社したエンジニアにonboardingラベルがついたDiscussionsの内容を共有しつつ、自身がつまずいた内容を入社3ヶ月以内にDiscussionsに起票してもらう予定です。

というのも、入社直後は、新人にとって全てが新鮮なので、既存社員が気づかない違和感に気付きやすいのです。しかし、入社して半年、1年と時間が経つと、入社時に苦労した内容もだんだん風化するため、忘れる前につまずいた内容を知識化しようという狙いです。

これにより、入社される方が増える度に、新入社員のつまずきが知識化されるので、オンボーディング用の辞書としてDiscussionsを活用できるのではないかと考えています。

フローからストックへ

Tebiki社には、「フローからストックへ」というカルチャーがあります。

日常業務から生まれる様々な会話や知見を発信して終わりにするのではなく、抽象化し、意味づけ、構造化して組織の知見として使える状態にする

社内のSlackやGitHubコメントでは、様々なノウハウが流れていきますが、一度誰かの目にふれるだけで終わりにすると、とてももったいないです。

Discussionsに残すことは、流れていく知識をせき止め、知識をチーム共通の資産に変えることができると思っています！