前職フィードフォースで働いていた時から、チームを移動した後に見えた光景に「ああ…」という気持ちになることがあり、結果的にやっていることがあります。

フィードフォースの時もこんな記事を書きましたが、esa の社内記事に置いてきてしまったので、アップデートを加えつつまとめます。

この記事に触発される人には言わずもがなですが、どれも最初の現状把握のあとに行動することが重要です。現状把握なしの行動は、逆にチームのスピードを下げる可能性が高くなりますから…。

(1) ノイズを減らす

まずはとにかくノイズを減らし、重要でない情報を目に入れないようにします。無意識のうちに集中が削がれるからです。

不要な記事はアーカイブもしくは削除

例えば、古くなったり要らなくなった社内記事はアーカイブもしくは削除します。

削除の判断は難しいことが多いので、アーカイブできるサービスを使うことが重要です。そういう意味ではアーカイブすると検索スコアが下がる esa.io は秀逸でした。検索対象から外さないのが素晴らしかったです。

Slack channel をまとめる

Slack channel をまとめるのも良いでしょう。例えばめったに来ない通知用の channel をアーカイブし、チーム用の channel にマージするなど。

メールのノイズも減らす

個人ではメールのノイズも減らします。不要なメルマガは停止したり、停止できないメールは Gmail のフィルター等で目に入れないようにしたり。gmailctl [2022-02-13-1] のようなツールで、フィルターをコード管理すると意外と楽しくできたりはします。インボックスゼロを保つことが重要です。

(2) リンクを添えることを日常とする

社内記事や、Slack や GitHub でのコミュニケーションの際は、リンクを添えることを日常として下さい。

読み手に情報源を推測させない

例えば Slack で何か書いた時に、読み手に情報源を推測させないようにします。書き手はリンクを添えて、読み手に情報源を見に行く選択肢を作ります。書く回数は 1 回ですが、読まれる回数は多くのケースで 1 回よりも多いです。

これが根付くと、情報をいもづる式に辿ることが出来るため、情報取得の難易度が下がります。出来てない場合は、辿れず諦めるケースも多いかと思います。「誰かに聞けば分かる」みたいな、属人性が根付いてしまう危険性もあります。

古くなった文書を敢えて削除しない

少し発展的な使い方としては、古くなった文書や Google スプレッドシートは削除せず、新しい文書へのリンクを張り、誘導するのもとても良いです。古くなった文書をそのまま放置するのが、一番良くありません。

導線を作るのも良い

なにか形が見えてきたら導線を作るのも良いでしょう。先月入社した会社では、一ヶ月かけてようやくこんな導線を作ることが出来ました。逆に言えばなかったので、最初の現状把握がとても大変でした。

チームのホームとなる Slack channel（新規作成）
↓ channel bookmark
チームのホームとなる社内記事（新規作成）
↓
チームの GitHub リポジトリまとめ社内記事（新規作成）
↓
各 GitHub リポジトリ の About に LookML プロジェクトの URL を追記
↓
各 LookML プロジェクト

(3) 情報はできるだけ一ヶ所にする

現状把握が進み、文書をリンクで繋いだり、導線を作ったりしたら、いろいろ見えてくるものが出来てきます。例えば重複した文書を１つにまとめたり、似た情報の距離を近くしたり。

具体的な取り込み例

前職や現職では、こんな取り組みをしました。

GitHub Wiki は使わない

社内記事用のツールを分散させないことも重要です。

例えば私は会社では GitHub Wiki を使いません。GitHub リポジトリの Settigns から Wiki 機能自体を Disable にします。

既存の社内記事と分散するのもそうですが、GitHub Wiki は変更しても通知が飛ばないのと、ページを跨いだ Diff URL を組み立てるのが面倒だからです。

GitHub と紐づく情報は社内記事に記載し README.md からリンクを張るか、GitHub リポジトリに .md ファイルを作ります。両者の使い分けはケースバイケースです。

更新頻度が高かったりガイドラインのような情報だったら社内記事、API ドキュメントや Scheme 定義のように Pull Request でまとめて差分を表現したい時は GitHub リポジトリの .md ファイルなど。

まとめと考察

「チームのスピードを下げさせない３つの大原則」をまとめました。

マネージャーやチームリーダーは、チームにこれらの仕掛けをしたり習慣を根付かせることで、チームのスピードを下げさせないことが重要だと思います。

すでにチームのスピードが高くない場合でも、実践することで積もり積もってスピードが上がるはずです。実感としては「気づいたら上がっていた」かな。

今回の大原則を踏まえれば、さらにチームが良くなる可能性があります。再現性もありそうです。

以下は例です。

  • チームメンバーでも他メンバーの状況を把握しやすくなるので、今までより短時間で密度の濃い朝会が出来る
  • KPT などの振り返りで、メンバー間で改善ポイントを話しやすくなる
  • 余裕が出来て、情報共有会などで相互に高め合う取り組みが生まれる
    • 既存技術や新しい技術、ドキュメントライティング [2023-03-12-1] の共有など