仕事での過去ログの検索について言語化してみた
ある日のこと
仕事をしているときに「（仕様とかの過去ログの）検索早いですね」と言われることがありました。
自分では全く意識していなかったので、そうなのか？と思いつつ、褒められたのは嬉しかったので、言語化してみることにしました、
過去ログを追う方法
過去ログを追う方法には、3 つパターンがあると自分の中で思っています。
- 実装から過去ログを追う
- 社内のチャットツールから追う
- プロジェクト管理ツール（e.g. asana, jira, balcklog etc...）から追う
この 3 つのパターンをなんとなく頭の中で使い分けて自分はログを検索しています。
パターンの使い分け
1. 実装から過去ログを追う
実装がなぜそうなっているかがわからない/仕様通りになっていないなどの問題が発生した時などに使っています。
特に後者の時に便利で、実は仕様を一度合わせたが、それが反映されていなかった場合などに便利です。
基本的に私は vscode を使っているので、git lens から問題のコードの Github へ飛ぶことができます。
gitlens まで飛べればあとは楽で、PR に行けばもう勝ったも同然です。
もしきっちりとした案件ないし実装者であればプロジェクト管理ツールのチケットや会話のログを記載しています。
もしなくとも PR が作成された日付から社内ツールを追うことができます。
ここまでやれば、ほぼ取り切れるかなと思います。
2. 社内のチャットツールから追う
社内のチャットツールを追う場合は、仕様がなぜそう決まったか、または実装に乗っていない修正が必要なバグ/仕様を確認するなどで使います。
一番このパターンで検索をかけるのが多い印象です。
この時の検索では 2 つのことを無意識ですが意識していそうかなと思っています。
- 検索対象のチャンネルをあらかじめ搾る
- 検索ワードをなるべく絞らない
1 については非常に簡単で、どこで会話をされていそうかをざっくり考えてから検索するというものです。
例えば、下の例のような 3 つのチャンネルがあるとします。
# 案件全体のチャンネル
# 案件でのフロントエンドチャンネル
# 案件でのバックエンドチャンネル
このようにチャンネルが分けられている場合はなんとなくそれぞれの使い道があり、それぞれの特徴があると思います。
例えば上の例だとこんな形になるでしょうか。
# 案件全体のチャンネル → 案件の担当分野を超えた会話が多そう（e.g. 仕様など）
# 案件でのフロントエンドチャンネル → 案件のフロントエンドの実装の話やフロントエンドからの確認が多そう
# 案件でのバックエンドチャンネル → 案件のバックエンドの実装の話やバックエンドからの確認が多そう
上記のように属性が何となくわかっていれば、今過去ログを追いたいものがどんなものかから検索するチャンネルを絞れると思います。
例えばフロントエンド周りの仕様書には乗っていないエラーのハンドリングなどは２目、 # 案件でのフロントエンドチャンネル にありそうかなと検討が付けられます。
もし大きく変更された仕様などであれば # 案件全体のチャンネル のチャンネルでやりとりがされていそうだなと検討をつけることもできます。
どのチャンネルがどのように使われているかを抑えられていれば、最初から範囲を絞ってノイズを減らすことができるわけです。
2 については簡単で、検索ワードを絞り込みすぎないようにします。
これはワードを絞れば搾るほど結果が絞り込まれてしまい、逆に欲しい情報が引っ掛からなくなることを避けるためです。
私は基本的にはキーワードは最大で 2 つまでで検索するようにしています。
1 の段階で既にチャンネルというところで絞り込んでいるので、2 キーワード程度なら検索結果も 20 件程度に抑えられます。
このような 2 つの絞り込みをしてあげれば結構簡単に過去のログは見つけられます（おそらく）。
3. プロジェクト管理ツール（e.g. asana, jira, balcklog etc...）から追う
こちらは情報がチケットに固まっていることがわかっている場合に使います。
例えば決まったフェーズと仕様があった場合などです。
個人的な見解ですが、チケットベースでの検索はどうしても検索したいような細かな仕様などは把握できないイメージがあります。
というのも、基本的にチケットはかっちりと仕様が決まった時に作られる印象があって、そこまでの課程は別でログがあったりするためです。
なので基本的に私は 1 つめと 2 つめの方法で検索することが多いです。
終わりに 検索より何より大事なこと
さて、ここまで検索についていろいろ書いてきましたが、実はこんなフローを考えなくても良い方法があります。
それはちゃんとチケットを残すこと、そして資料はちゃんとメンテナンスすることです。
これは理想論でしかないですが、ちゃんとログを残すべきところにログを残して、ちゃんと変更があったら資料をメンテナンスできればこんなことができるようにならなくてもいいのです。
とはいえそうはできない（リソース不足や緊急の対応など）のが世の中なので、できる限り理想に寄せつつ、できないことはゆるく頑張りたいなぁと思いました。
Discussion