皆さんこんにちは！ Technology & Design DepartmentのSREチーム所属のしょーやです
リモートワークも長くなってきて自宅の作業環境がだいぶ整ってきましたが
部屋が狭いため、居住空間を侵食しており試行錯誤を繰り返してます...
リモートワークでの悩みといえば、対面でのコミュニケーションがどうしても減ってしまうため「リモートになってから情報共有が行いにくくなった」という方も多いのではないでしょうか
弊社では、フルリモート開始以前から esa を利用させていただいており、そのおかげで「リモートワークになってから情報共有が行いづらい」という事態に陥ることなく、今まで通りお互いの知見や経験を共有することができております
そこで、今回は esa を使って弊社でどのように情報共有を行なっているのかをご紹介させていただきたいと思います
esa.io とは 🐥
esaの初期READMEから引用
esa.io とは、「情報を育てる」という視点で作られた、自律的なチームのためのドキュメント共有サービスです - esa.ioの使い方 - チームへの招待方法
下書き状態でも情報を公開して貯めておくことが出来るため「とりあえず書いておく」という情報公開の敷居がかなり下がるため、まさに「情報を貯め・育てていく」ことに適したツールであると利用してみて感じております
また、esaではチームの画像を変更することができるため、弊社ではオリジナルアイコン
を使用してます
※ esaのロゴマークは「クリエイティブ・コモンズ 表示-非営利-改変禁止 4.0」に指定されていますが 、このアイコンは本記事のへ掲載にあたり、問い合わせにてesa LLC様に確認し許可をいただいて掲載しております。
これだけでもかなり愛着が湧き「早くエサをあげなきゃ」となります！（個人の見解です
また、esaにGA4を導入しようとした際、GA4に未対応っぽい挙動であったためサポートに下記のお問い合わせさせていただいたところ、驚くほどの爆速対応してくださったことがあり「ああ、もっとesaを使って情報を育てていこう」という強い気持ちが芽生えました
（サポートの対応も素晴らしかったです。ということが言いたい）
弊社では、導入当初は「まず情報を貯める文化を作る」ことを目指し、特に運用ルールは定めず各々自由に利用してもらいながら情報を貯め続けてきました
そして、ある程度の情報量が溜まって来た頃にゆるめのルールを作成し、現在もその運用ルールを利用しております
弊社のesa運用ルール
README.md について
README で始まるドキュメントは、いつもカテゴリページの一番最初に表示される
(foo/READMEというタイトルにすると、fooカテゴリの一番上に表示される)
チームでよく使うページのリンクなど、頻繁に見たい情報を貼っておくと便利です
READMEの扱い
- このREADMEをプロジェクト/チームのIndexページと捉えてください
- 新規参画メンバーが最初に見て全容を把握するページ
- 後述するディレクトリ構造にREADMEと書かれている箇所には基本的に配置してください
- 他にも必要と思われる箇所には自由に置いてください
README に記載して欲しい基本的な内容
- プロジェクトの簡単な説明
- 関連する人々とその関係性
- システム利用者
- gitリポジトリの場所
- jiraのプロジェクト
- 関連するslackチャンネル
- リンク集
- esa以外にドキュメントを置いている場所(google drive等)
タグについて
- 基本的にカテゴリで階層分けをしていく
- 作業したプロジェクトやチームの下に記事がたまる
- タグは利用技術やツールで検索したい際の補助とする
- 例) aws, ec2, cloudfront, gitlab, ruby, php, nginx, docker, terraform, capistrano ...etc
BulletGroup流 ディレクトリ構造
README #esaのルールや使い方など
日報 #個々の作業状況などを記録
┗ %{Year}/%{month}/%{day}/%{me}
作業メモ #どこに入れていいかわからない記事や個人的な記事などを一時的に格納
┗ %{me}/title
Poem #記憶ではなく記録に残そう。名言を
┗ %{me}:title
Designer #デザインチーム用のディレクトリ
┗ チーム内でよしなにご利用ください
Operation #オペレーションチーム用のディレクトリ
┗ チーム内でよしなにご利用ください
Projects #各プロジェクトの情報を集約するディレクトリ
┗ {product/team名} #プロダクトやチームごとに作成
┗ README #プロダクトの紹介, プロダクト情報のindexページ
┗ tips #プロダクトについてのHowToや作業記録など
┗ 手順書 #リリース手順や確認手順などの情報
┗ releases #リリースに含んだ内容など
┗ 議事録 #プロダクトに関するMtgの議事録
Tools #社内ツールの情報を集約するディレクトリ
┗ {tool名} #ex) esa, gitlab, mackerel ...etc
┗ README #ツールの紹介, ツール情報のindexページ
┗ tips #ツールについてのHowToや作業記録など
┗ 手順書 #ツールのアップデート手順など
Template #記事のテンプレート一覧
┗ {テンプレートを配置}
Archived #アーカイブした記事が集まる場所
┗ {アーカイブした記事達}
このような形でざっくり大枠だけでも決めておくことで
「いつでも・誰でも必要な情報にたどり着ける」環境を作ることができます
チーム分割
esaには記事や階層毎での権限分割はできません
これは 情報の透明度 という観点から見れば納得の仕様なのですが、
実際には様々な理由により閲覧できる人を絞りたいケースがあると思います（弊社でもありました）
そのため、弊社では複数のチームを用途毎に作成してesaを利用しております
チームを分けるといっても この人には見せたくない という切り分け方ではなく この人に見えても邪魔な情報 となるものを分割するにより 必要な情報をより見つけやすくする ことを目的に情報のカテゴリにあわせてチームを分けてます
チームを複数作成すると「チーム毎にユーザ課金されて費用が膨らまないのか」という疑問を持たれる方もいるかと思いますが、esaでは決済連携をすることで 同じ人が複数のチームに参加していても１ユーザとしてカウントされる という素敵仕様となっているため、その心配はありません！
詳しくは公式の情報をご覧ください
さいごに
今回は弊社で利用している情報共有ツールのesaとその活用方法をご紹介させていただきました
対面でのやりとりが減りドキュメントとして知見などを共有することの重要性は高まっている今だからこそ、これまで必要性を感じながらも取り組めていなかったドキュメント化を進めてみてはいかがでしょうか
文章に書き起こしながら作業をすることで、自身の頭の中を整理することもできるため個人的には大変おすすめです！
この記事がご覧いただいた方の参考に少しでもなれば幸いです
