GitHub Discussionsで社内のQ&Aフォーラムを開設する

プロダクトエンジニアリング部の二宮です。

LIFULL では「エンジニアいつでも相談」という名前で、GitHub Discussionsを使った社内向けの Q&A フォーラムを有志で運営しています 🙌

このフォーラムは「あるシステムについて誰か詳しい人に相談したい」とか「設計についてチーム外にも相談したい」とか、エンジニアリングで困ったことをなんでも聞ける窓口になることを目指しています。最近ではアーキテクトチームや QA チームなどの公式の窓口としても利用でき、質問の内容に応じて適切な部署や人がアサインされる体制も整い始めました。

従来は相談相手を見つけるのにも苦労したり、そもそも窓口が用意されていなかったりすることもあり、社内アンケート調査等でよく情報共有が課題に挙がっていました。そこで、社内向けの Q&A フォーラムを用意することで、その問題の一部を解消しつつあります。

エンジニアいつでも相談の利用方法

まず利用方法を紹介します。エンジニアいつでも相談の GitHub リポジトリが用意されていて、その Discussions にフォーラムが用意されています。

f:id:LIFULL-ninomiyt:20220218155001p:plain

ここで過去の質問を検索・起票できます。詳しい案内はトップのハウスルールが掲載されており、初めての人でもあまり迷わずに操作できると思います。ハウスルールには次のような内容が記載されています。

GitHub Discussion 上で過去の質問の検索を行う
解決した場合、Vote をする
既存の質問で解決しなかった場合、「Q&A🙏 」カテゴリで起票する

フォーラムに質問が投稿されると、質問の回答者となるチームに通知されます。GitHub Actions によって、タイトルや内容によって各チームにメンションを付けたり、Slack 通知を飛ばす機能が実装されています。もちろん、それ以外の社員も回答できます。

f:id:LIFULL-ninomiyt:20220218183440p:plain

質問者は、問題が解決したら、回答の中からベストアンサー（Mark as answer）を選んでクローズします。

このように、一般的に想像するフォーラムの機能はそろっており、通知の自動化なども必要に応じてすぐに実装できます。

GitHub Discussions を利用するメリット

過去のツールの変遷

実は、エンジニアいつでも相談は、発足当初から以下のような思いは一貫しています。しかし、ツール面ではいくつかのものを渡り歩いてきました。

社内のドメイン知識や社内ルールが分からず悩んでほしくない
将来的にエンジニアの共助・評価・成長につなげたい

具体的には以下のような変遷がありました。

Google グループをフォーラムとして利用する
フォーラムを使わずに有志でチャット上で質問・回答をする
GitHub Discussions でストック化を促進

まず、Google グループではなかなか質問自体が集まりませんでした。これは、普段利用しているツールではなく、業務の導線にないからだったと思っています。
（ただし、Google グループは、 GitHub アカウントを持っていない社員からの質問も受け付けられる点でメリットがあると思います。発足当初は職種からエンジニアへの質問も想定していて、現在はそこのコミットメントは諦めた形になります）

また今から考えると、アサインや通知の自動化がやりづらく、この状態でスケールさせることも難しかったと思います。

次に「普段利用しているサービス上なら質問・回答がやりやすい」という仮説のもと、専用のチャットルームを用意して、有志でそこで質問・回答するようにしました。これはコンスタントに質問が行われるようにはなったものの、「あれ？どれが回答済みなんだっけ？」というやや混乱した状態にもなっていました。またせっかく回答しても、その場限りでナレッジにならないという歯がゆさもありました。

Discussions を利用するメリット

それらと比較して、Discussions を利用することについて、以下のメリットを感じています。

業務で普段利用しているサービスであること
Q&A が直接ナレッジとして蓄積できること
GitHub Actions で自動化ができ、Pull Request で変更を受け入れられること
内容がオープンであること

1, 2 は、ほかのツールとの比較で自然にわかると思います。3 について補足すると、たとえば「GitHub Actions によって各チームに通知を飛ばす」機能は、Discussions 起票時に以下のようなシェルスクリプトを起動することで実現しています。

if [[ "$CATEGORY" = "Q&A" ]]; then
    (
        regexp="([kK]eel|KEEL|[dD]ocker|[kK]ubernetes|ECS|EKS|[pP]rometheus|[gG]rafana|[vV]irtual[[:space:]]?[sS]ervice|[dD]ev[oO]ps|[vV]1[cC]luster[bB]ootstrap|[sS]pinnaker|[sS]elf([-]|[[:space:]])?[hH]osted([-]|[[:space:]])?[rR]unner|J-?SOX)"
        if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then
        addDiscussionComment "$ID" "KEEL: ${KEEL_TEAM}"
        fi
    )
    (
        regexp="([aA]rchitect|アーキ|設計相談|[bB]ff|BFF|[nN]c[aA]pp|[nN]ext[cC]ore|lhv5|[pP]roject[xX]|PJX|pjx|[fF]ront|ベストプラクティス)"
        if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then
            addDiscussionComment "$ID" "Architect: ${ARCHITECT_TEAM}"
        fi
    )
# 以下略

この通知スクリプトに各チームが通知内容を設定するようにしています。チーム側からこれらの修正を Pull Request として送ってもらうことで、運営チームはあまり負荷を感じることなくメンテナンスできます。

また、一度の投稿で、複数のチームに相談できるというメリットもあります。たとえば「何かのプログラムの問題について QA とアーキテクトに相談したい」というとき、以前はそれぞれの jira で起票する必要があったのですが、今では統一されたフォーラム上で一度に相談できます。

今後の展望とまとめ

このように、GitHub Discussions を利用することで、あまり負担なく便利な社内フォーラムが用意できます。

当初は何人かで集まって「誰に質問すればよいか分からんから俺らで作ろうぜ」と勝手にやっていただけなのですが、投稿されたほとんどの質問は何らかの形で解決でき、上記のような便利な状態を実現できました。これは、運営メンバー外で質問をチェックや運営へのフィードバックをしてくれている社員も多くいてくれたおかげだと思っています。

また、従来はチーム内で閉じていた技術的な議論がチーム外も巻き込んだ形で行われているなど、想定していた以外のところでもうれしい事例も生まれています。引き続きよりよい開発文化のために貢献できればうれしいです。

最後に、LIFULL では一緒に働くエンジニアの募集をしています。この記事だけでは普段の開発の様子は分からないと思いますが、ぜひほかの記事も読んで興味を持っていただけたらうれしいです。カジュアル面談もあります。

hrmos.co