こんにちは 
id:masutaka26 です。夜の散歩（意味深）に勤しむ毎日です。
フィードフォースではドキュメント共有ツールには esa と Google ドキュメント1を、コミュニケーションツールには Slack を採用しています。
情報共有はかなり活発で、2021/2/1 現在の esa 記事数は 81,324 です2。
- 現在のカテゴリ構成と課題
- チームのスピードを上げるための大原則
- チームのスピードを上げるための情報整理
- それをチームでやるのは難しすぎない？
- esa は難しい
- esa の本当の正体
- esa への要望
- まとめ
- esa 公式アカウントからのアドバイス
- コラム
現在のカテゴリ構成と課題
トップカテゴリは厳密にルール化されていて、これらの種類以外のカテゴリが増えることはありません。
日報/2021/02/01 (月)/masutakaといった記事が置かれる- 曜日がないなど、型から外れた日報は小人さんによって速やかに修正される。Bot 並に早いw
プロダクト1/- 実際には
Feedmaticなどのプロダクト名が入る
- 実際には
- ︙
プロダクトN/プロジェクト/- 期間が決まっている系のプロジェクトカテゴリが並ぶ
チーム/- 人事や情報セキュリティなどのチーム系カテゴリが並ぶ
コミュニティ/- 技術系や読書会などのコミュニティ系カテゴリが並ぶ
ノウハウ/- 各種ツールのノウハウ系カテゴリが並ぶ
Feedforce Inc./- 会社全体に関係する記事が置かれる
Users/Templates/Archived/
例えば「プロダクト1」の下は、議事録系を除き基本的に Stock 型の記事になっており、「マニュアル」カテゴリの下にはさらに 15 の子カテゴリが生えているとします。
プロダクト1/議事録/開発/コンサルティング/マーケティング/インシデント/ナレッジ/マニュアル/- 子カテゴリ数は 15
- ︙
その他/
※ 複数のプロダクトから作った架空カテゴリです。
ここまでならよく整理されているように見えますが、実際は古くてメンテナンスされていない記事が多く、言ってしまえばノイズが多い状況です。情報共有されればされるほど、ノイズが増えてしまう悪循環です。
Slack に目を向けると、こちらもオープンではありますが、時にブログ記事並みのメッセージが投稿されることがあります。未読メッセージを読み進めると手が止まり、読み切るのが難しいと想像されます。
細切れの情報も多く川の流れのようで、断片化した情報をつなぎ合わせるのは難しいと思います。
世の中には情報共有が足りないことに悩む組織は多いと思いますが、活発になったとしても、適切に整理されていなければその量に溺れてしまいます。
一方で、最近のコロナ禍もあって 10 年前と今とでは変化のスピードは上がっています。変化に強いチーム設計、つまりは変化に強い情報整理設計が重要です。これをやらなければ、チームのスピードは徐々に下がっていくでしょう。
チームのスピードを上げるための大原則
私が社内で様々なプロダクトを渡り歩いた経験上、チームのスピードを上げるためには以下の 2 点が重要だと感じています。
- ノイズを減らす
- 情報を一ヶ所に集める
マネージャーはこれらの阻害要因を減らす仕掛けを作る必要があります。
ただ、そういったことが得意な方ばかりではありません。むしろ情報量が一番多く、一番困っているのは彼らかもしれません。マネージャーに余裕がなければ、それがボトルネックとなりチームのスピードが下がります。
これからその対策を考察していきます。
チームのスピードを上げるための情報整理
はじめに書いておくと、出来るだけ整理を頑張らないことが重要です。
1. Flow 型と Stock 型の記事を理解する
まずは公式ドキュメント「記事のストック・フローの分類と検索」を読んで、Flow 型と Stock 型の記事の存在を知り、理解します。
2. 基本は Flow 型の記事にする
全て Flow 型にするくらいの気持ちで記事を作ります。記事が多くなっても視界に入りづらいし、整理する必要もないためです。
書き捨ての記事であれば プロダクト1/2021/02/01/タイトル、今月中は更新する記事であれば プロダクト1/2021/02/タイトル で良いと思います。ただ、さすがに今年中更新する記事は Stock 型の記事にしたほうが良いと思います。
3. 議事録カテゴリは出来るだけ作らない
プロダクト1/議事録/ のような議事録カテゴリはできるだけ作らず、プロダクト1/2021/02/01/〇〇会議 議事録 のようなカテゴリとタイトルにします。議事録のような使い続けない記事を視界に入れるのは、どちらかと言えばノイズだからです。
社内で以下のような階層をよく見かけますが3、一回限りの会議の置き場所に悩んでしまいます。
プロダクト1/議事録/〇〇会議/YYYY/MM/DD/〇〇会議プランニング/YYYY/MM/DD/プランニング
プロダクト1/議事録/20210201 〇×会議 議事録 のような自由なパターンも現れたりして、さらに悩ましくなります。
過去の議事録をたどる目的でカテゴリを分けたいのであれば、記事の最初に「議事録一覧はこちら」みたいな検索リンクがあれば十分でしょう。
それでも作りたい場合は プロダクト1/議事録/〇〇会議/2021/02/01/〇〇会議 議事録 のような記事名にして、後から プロダクト1/2021/02/01/〇〇会議 議事録 に一括変換して視界から消せるように、設計するのが良いと思います。
一括変換の仕方は公式ドキュメント「記事のカテゴリを一括変更」が分かりやすいです。
4. Slack に流れていく情報も Flow 型の記事にする
Slack にはブログ記事並みのメッセージが投稿されることがあります。
そうなりそうになったら迷わず プロダクト1/2021/02/01/○○のお願い といった Flow 型の記事を作り、その URL を Slack で共有します。
他の場面で引用したい時は意外とあるものですし、内容をあとで更新したいこともあります。Slack だと特にあとからの更新には不向きです。
何より当該記事をブラウザで開き、残りの Slack 未読メッセージをスイスイと読むことが出来ます。Slack に投稿されてしまうと、その長いメッセージを読みながら、他の channel に移動するのは億劫です。
5. 使い続けられる情報を Stock 記事として引き上げる
結局のところ、ほとんどの情報は使い続けることはありません。具体的すぎるからです。そのような具体的な情報は寝かすことで、抽象度の高い情報、例えばカテゴリ名を炙り出せることがあります。
良いカテゴリ名が思いつかない時は、まだ抽象度が高くないと思うので、引き上げないほうが良いでしょう。
いくつかの Flow 記事をしばらく寝かしたら、あとから汎用的な抽象度の高い Stock 記事のアイディアが湧くこともあります。
6. 整理を頑張らないことで整理の難易度が低くなった
ここまででほとんどの記事は Flow 型の記事のはずです。冒頭に述べたノイズになるような記事は少なく、情報に溺れる確率は低いと思います。
使い回しが効かない具体的な情報を Flow 型の記事に追いやることで、整理の難易度を低くすることが出来ました。
7. esa を全ての情報の起点にする
では、Google ドキュメントも同じようにしましょう！とは思っていません。esa を全ての情報の起点にする勢いで、適宜 Google ドキュメントにリンクを張ると良いでしょう。
Google ドキュメントのフォルダ整理は出来るだけやらないほうが良いです。時間がいくらあっても足りません。Google Drive はただの情報プールです。Google Drive 内検索も優秀です。
それをチームでやるのは難しすぎない？
そう思った方、正しい感覚です。
「チームのスピードを上げるための情報整理」は「私が考える esa 原理主義」に振り切って書きました。情報整理のスキルに関して少数精鋭チームでないと、運用するのは難しいと思います。
現在私は開発者 1 人、ビジネスメンバー 2 人のチームに所属しています。私主導でカテゴリを決めているので、これまで書いた方法で整理し、うまくいっている実感があります。
そういえば初期は Flow 型の記事しか作りませんでした。
esa は難しい
フィードフォースでは 1 年半ほど前まで Qiita:Team を使っていました。
Qiita:Team はほぼ Flow 型の記事しか書けないため、これまで話した問題は出てきませんでした。いや「表面化しなかった」が正確でしょう。
esa は Stock 型の記事も書けます。ブログと wiki が合体したようなツールなので、難しくないわけがありません。
wiki を書くためには抽象的思考が必要です。私の観測範囲では、半分以上の方は具体的思考に寄り過ぎているため、得意ではないという実感です。意識したことがないかもしれません。
esa の本当の正体
正直言って現在の esa は「情報整理のスキルに関して少数精鋭チーム」でないと、乗りこなすのは難しいと思います。
これに気づいた時、Ruby という言語に似ていると思いました。
Ruby は esa で採用されているプログラミング言語です。初心者はにこやかに迎えてくれますが、本番環境で使い続けるためには、コードで表現されていない振る舞いを読み解く必要があるなど、実は少数精鋭チーム向けの言語です。
esa LLC は少数精鋭チームのようなので、良くも悪くも「コンウェイの法則」が働いて、そのようなサービスになったのだと勝手に想像します。
esa への要望
社員数 100 人オーバーが見えてくると、型（制約）の必要性を感じます。
- 新規作成時にデフォルトカテゴリが Flow 型になるような、型を設定できると良い？
- 例:
プロダクト1/以下での新規作成は、デフォルトカテゴリがプロダクト1/YYYY/MM/DD/になる
- 例:
- フレームワーク的に、何らかのパターン以外のカテゴリを作れないようにする？
- 第一階層カテゴリ以下で、そのようなパターンを数種類から選べるようにする？
どれも難しい話ですかね...？
現在社内で抱えている課題として「記事整理にハードルがある」は間違いなくあると思います。
- たくさんの記事を移動すると、
/postsがその情報で埋まる4 - 移動しただけなのに、記事に自分の小さなアイコンが付く
- そもそも記事を 1 つ 1 つ移動するのが大変
- タイトルに入れてしまった日付をカテゴリにして...とかまですると、API を使わざるを得ない
出来れば Windows のエクスプローラのようなカジュアルさで、且つ履歴が残るとうれしいです。
あと、要望したことはありますが、現在の「カテゴリ以下の記事全て」に加えて、「カテゴリ直下の記事」「アーカイブした記事」を切り替えるような機能が欲しいです。
イメージとしては、GitHub の UI に「カテゴリ直下の記事」を加えたものです。
「カテゴリ直下の記事」は on:カテゴリ で検索できますが、知っているユーザーはごく僅かです。
アーカイブの認知も怪しくて、古い記事が残る要因かもしれません。一部カテゴリではこんな工夫をしています。
難しいと思いますが、情報整理のスキルがそれほど高くなくても使える UI 設計をお願いしたいところです。🙏
もし、もっと詳しく私にヒアリングしたいなどあれば、masutaka@feedforce.jp または @masutaka の DM までお知らせ下さい。
まとめ
私から見える、フィードフォースで抱えている情報整理の課題をまとめ、チームのスピードを上げるための整理方法を提案しました。
ただ、それは「私が考える esa 原理主義」に振り切っているため、チームで採用するのは難しいと思います。
カテゴリがデフォルト Flow 型になるなど、情報整理を頑張らず済む使い勝手になると、とてもうれしいです。
esa 公式アカウントからのアドバイス
- 新規作成時にデフォルトカテゴリが Flow 型になるような、型を設定できると良い？
こちらのアドバイスを頂いたので早速試しました。良さそうです！
あるカテゴリ配下で "Create a new post" ボタンで記事を新規作成するときに、カテゴリが一致するFlowのテンプレートがあれば、そのテンプレートが自動的にプリセットされるという機能があります。（続く→）
— esa_io (@esa_io) 2021年2月3日
例えば以下のテンプレートがあったとして
— esa_io (@esa_io) 2021年2月3日
- Templates/カテゴリ1/YYYY/MM/DD/テンプレートA
- Templates/カテゴリ1/サブカテゴリ1/YYYY/MM/DD/テンプレートB
「カテゴリ1」配下で記事作成→ テンプレートA
「カテゴリ1/サブカテゴリ2」配下で記事作成 →テンプレートB
がそれぞれ自動適用されます
後日アンサー記事も頂きました！「所感」にこの記事の感想が書いてあります。 ProTip/2021/02/03/特定のカテゴリ配下の記事作成時に、テンプレートを適用する - docs.esa.io
コラム
自分の思いを書ききれないので、コラムに逃しました。(^^;
記事のカテゴリ整理を頑張らない理由
こんな理由からです。
- 歴史が証明している
- esa の検索がそこそこ優秀
今では信じられないかもしれませんが、1990 年代の Yahoo! JAPAN は、人間のスタッフがウェブサイトの情報を収集してカテゴリ分類して登録する、ディレクトリ型検索サービスでした5。今はロボット型検索が使われているのは周知のとおりです。
そのため Stock 型の記事だけを作り続けるといずれ破綻することは、1 歴史が証明していると言えます（やや大げさ）。
2 については、公式ドキュメント「記事の検索方法」にある検索クエリで、それなりに検索できます（諸説あり）。「キーワード検索しやすい記事にするコツ」も参考にすると良いでしょう。
Flow カテゴリをどこまで許容するか
Flow カテゴリをどこまで許容するかは、悩ましいところです。
(a) 制約をつけずに自由に作ることを許容するか。
- プロダクト1
- セールス
- ...
- YYYY
- MM
- DD
- MM
- 開発
- ○○機能
- YYYY
- MM
- DD
- MM
- YYYY
- YYYY
- MM
- DD
- MM
- ○○機能
- YYYY
- MM
- DD
- MM
- セールス
(b) 原理主義っぽく、１つの Flow カテゴリしか許容しないか。
- プロダクト1
- セールス
- ...
- 開発
- ...
- YYYY
- MM
- DD
- MM
- セールス
(a) は職種横断的な情報共有を重視しないチームに合うと思います。中規模以上のチームです。
(b) は職種横断的な情報共有を重視するチームに合うと思います。小さなチームです。
はじめは (b) で作ってみて、やりづらくなってきたら (a) にすると良いでしょう。ただし、(a) の プロダクト1/開発/○○機能/YYYY/MM/DD/ まで細かく Flow カテゴリを作るのは、把握が難しくなりそうですので、オススメはしません。
-
Google Workspace（旧称 G Suite）を契約しています。↩
-
現在のメンバー数は 90、最古の記事は 2014/4/3 です。↩
-
過去に推奨したことあります。ｽﾏﾇｽﾏﾇ…。↩
-
Archived/以下への移動は更新日時が変わらず/postsに現れないので、カテゴリ一括変更と組み合わせれば、一応回避はできます。↩ -
今回の件で調べたところ、その「Yahoo!カテゴリ」は2018年3月29日まで動いていたことを知りびっくりしました↩
