株式会社LIFULLのプロダクトエンジニアリング部の二宮と申します。
以前「GitHub Discussionsで社内のQ&Aフォーラムを開設する」でもご紹介したことがあるのですが、LIFULLではGitHub Discussionsを使った社内向けのQ&Aフォーラムを有志で運営しています。現在、およそ500個の投稿があり、社内の情報やノウハウ共有に役立てていると思います。
このフォーラムは「あるシステムについて誰か詳しい人に相談したい」とか「設計についてチーム外にも相談したい」とか、エンジニアリングで困ったことをなんでも聞ける窓口になることを目指しています。最近ではアーキテクトチームや QA チームなどの公式の窓口としても利用でき、質問の内容に応じて適切な部署や人がアサインされる体制も整い始めました。
元々はQ&Aのみを想定していたのですが、予想していなかった嬉しい使われ方も行われています。今回はそれを紹介します。
（また、これを社内のエンジニアが見て、「こういう使い方をしてもいいんだ」と更に活性化することを期待しています！）
技術知見の共有の場になっている
GitHub Discussionsには、Q&A以外に Knowledge というカテゴリがあります。これを使って「皆に共有したい技術的な知見」を共有する人が現れました。
例えば次のようなものが投稿されています。
画像に lazy-loading を適応するとパフォーマンスが劣化する場合があるので気をつけてください #496
まとめ
- ヒーロー要素となる画像(LCPのターゲットとなる要素の画像)/first view に入る画像については、必ず lazy-loading を避けること
- むしろ優先度を高く読み込むようにする
<link rel="preload"fetchpriority="high"
（以下略）
Discussions上で、過去の質問を検索するとき、これらのKnowledgeも表示されるため、困っている人に直接リーチできる可能性がありそうです。
データについての相談も寄せられるようになっている
GitHubを利用しているので、元々はエンジニアだけをターゲットにしていたのですが、データ関連の問題も投稿されるようになりました。
LIFULLでは（他の会社でもままある話だと思うのですが）データについての相談を各部署の「詳しい人」が相談を受けて、データスチュワードという役割を設けて相談を一元管理しようという動きがあります。そちらの役割の方から投稿して頂いた内容がこのようなものです。
BQ：{あるデータのテーブル}の{種別カラム}=13は何ですか？ #487
相談
- BQ：{あるデータのテーブル}の{種別カラム}=13が何か知りたい。
- {種別カラム}の値と名称を管理しているマスタやドキュメントがあるか？
- マスタがない場合、最新情報を確認する手段を教えて欲しい。
分かっていること
- {種別カラム}=13は****年*月が初出っぽい
- {種別カラム}=13はすべて***
（以下略）
実はこれは、特定のユースケースで保存されるデータの一部に誤りがあり、データを生み出す側の実装を調べないと分からない問題でした。「データスチュワードが相談を管理して、実装上や仕様の問題はエンジニア向けのQ&Aフォーラムに投稿する」という動き方で比較的短時間で解決できました。
以前はこうした問題は「データ部署が仕様を調べてもよく分からず、各不動産マーケットに連絡が来て、そこのエンジニアが実装内容を調べて…」というチームをまたいで、長い時間がかかってしまっていたんじゃないかと思います。
こちらの質問はLIFULL Tech Hubという社内カンファレンスがきっかけで繋ぐことができました。LIFULLではこうした社内イベントもいろいろ工夫して実施されています。
提案や意見集約の場として使ってもらえている
開発プロセスの中で「何かちょっとイケてないけど、どこに提案すればいいか分からない。誰に修正してもらえばいいか分からない」というモヤモヤがあることもあると思います。そうした提案もいくつか行なってもらえています。
「開発チェックシート」の体験向上について #440
選択式アンケートは匿名回答のようなので、ぜひ率直なご意見をお寄せください。
背景
**開発者の方々などが使用している開発チェックシートは開発フロー上欠かせないものと考えていますが、現状の運用には次のような不便さがあると考えています。
- 共通テンプレートが改変されてしまう
- 共通テンプレートがどこにあるかすぐに分からない / たどるのが手間
（中略）
そこで、何らかの改善策が打てれば生産性向上に寄与できるのではないかと考え、以下の2通りの改善策を考案しました。（以下略）
何かプロダクトを作る際のサポートとしてGoogle Spreadsheetのチェックシートがあるのですが、その内容がいくつか古びてるんじゃないかというような内容でした。
こちらのdiscussionには「こう修正したほうがいいんじゃないか」とか「チェックシートができた当時より自動テストでカバーできる範囲も増えてるから軽減できるんじゃないか」みたいな意見が寄せられ、その結果を品質管理の部署に拾って改善に向けて動き始められたそうです。
まとめ
以上のように、GitHub Discussionsを使ったエンジニア向きのフォーラムは、けっこういろいろ面白い動きに繋がるものだと思います。『Googleのソフトウェアエンジニアリング』でも YAQS：Q&Aプラットフォーム という社内フォーラムが紹介されていますが、これと似た取り組みが普段使っているGitHub内ですぐに実現できます。
「GitHub Discussionsで社内のQ&Aフォーラムを開設する」でも紹介した通り、GitHub Actionsを使った自動化や通知なども簡単に実装できます。
皆さまの会社でもぜひやってみてください。