認識ズレを防ぐために仕様にIDをつけて会話する
こんにちは！プロダクトマネージャーのひまらつ（@himara2）です。
私はmicroCMSという会社でプロダクト開発をしていますが、そこでは日常の業務のために複数のツールを利用しています。チャットツールにSlack、ドキュメント管理にNotion、タスク管理にClickUp、テストケース管理にQaseなど。最近のサービスはどれも使いやすく、このように1つのチームで複数サービス使っている会社も多いのではないでしょうか。
複数サービスを横断して使っていると困るのが情報が散らばってしまうことです。例えばある機能についての状況を調べたいとき、その機能にまつわる仕様書やタスク、テストケースはどれか？探すのに手間取ってしまいます。
私のチームではこの課題を解決するべく、各サービスの情報に共通のIDをつけることで情報のつながりをわかりやすくしました。これが想像以上に良かったのでnoteで詳しく書いてみます。
Anken IDを発行する
microCMSでは機能開発や不具合などの改修の単位を「Anken」と呼んでいます。このAnkenにAnken IDというユニークな識別子をつけ、それを元に情報をつなげています。
開発チームのバックログはNotionで管理しており、バックログのアイテムひとつひとつがAnkenです。ここを中心にIDを発行するのが良いと考え、Notionをベースに他サービスが繋がる世界観で進めました。
IDはNotionのIDの仕組みを使います。アイテムのプロパティを編集し、「ID」のフィールドを追加すると自動的にユニークなIDが付与されます。
IDにはprefixがつけられるので設定します。後述しますが、prefixをつけることでIDを便利に活用できるのでつけておきましょう（Notionドキュメント）。
このIDを各サービスでどう扱っているかを紹介していきます。
各サービスでAnken IDを活用する
Notion
NotionのIDにprefixを設定すると、ID機能の恩恵をフルに授かれます。ひとつ目の恩恵は検索しやすくなるということです。
Notionでドキュメント検索するとき、通常であれば検索モーダルを開き、そこにページに書かれてそうな情報（タイトルや内容）のテキストを入力して調べるかと思います。IDを設定している場合、検索モーダルにIDを入力すると目当てのドキュメントを一発で検索できます。
個人的にSlackの日本語検索の精度はイマイチに感じており、探したいドキュメントがヒットしなかったりするのでID検索は便利です。また、技術設計やデータ分析など関連する他のドキュメントにもAnken IDを書くように運用しているので、Ankenに関するドキュメントを横断的に検索しやすいのも良い点です。
ID機能のもうひとつ便利な点として、URLの指定があります。NotionドキュメントのURLは通常 https://www.notion.so/{workspace_id}/{page_id} のような形式になっています。page_id にあたる部分はランダムな値となっていて覚えられるような値ではありません。IDを付与することで、 https://www.notion.so/ANKEN-1234 のようなURLでドキュメントにアクセスできるようになります。ワークスペースIDすら不要でURLを構築できるので大変便利です。
Slack
Slackで仕様相談する際、Anken IDを指定してコミュニケーションします。「Anken-1234ですが、この技術って〜」のような形です。これまでは「この画面にXXの機能をつける件だけど、これって〜」と書いていました。日本語は表現にブレが出ますし、同じ画面の改修が複数並行して進んでいるときもあります。議題となっているAnkenを勘違いして認識齟齬が起き、いろいろ会話した挙句お互い違うAnkenについて話していた、ということも実際ありました。一意のIDで話せばズレることはありません。また、Slackの過去のメッセージを検索する際もIDがついてると探しやすくなります。
SlackでAnkenについて話すときは、そのメッセージにAnken NotionのURLを添えるようにしています。これはメッセージを見た人がすぐに該当のAnkenの詳細を辿れる目的ですが、上述したURL構築の仕組みを使うと簡単にリンクをつけられます（https://www.notion.so/ANKEN-xxxx の形式で書けば良いので）。これまでは一度Notionを開いて該当ページのURLをコピーしにいく必要があったので、時間短縮できるようになりました。
Qase
Qaseはテストケース管理ツールで、リリース前に追加した実装に不具合がないか、デグレが発生していないかをテストするのに使っています。フローとしてはエンジニアがテストケースを作り、プロダクトマネージャーがそれを使って受け入れテストします。以前は対象のテストケースを探すのに手間取る時があったのですが、テストケースのタイトルにAnken IDを指定するようにしてからは滑らかに連携できるようになりました。
ClickUp
ClickUpはチームでのTodo管理に使っており、自分や他メンバーのタスク状況が見える化されています。例えば何かの機能を作る際、設計やテストケースの作成、リリース後の他チームへのシェアなど、毎回必ずやる必要のある仕事があります。これをClickUpのタスクテンプレートとして登録して、新しいAnkenが立ち上がるたびにそのテンプレートからタスクを生成しています。ここでもタスク名の先頭にAnken IDをつけて、認識齟齬を防いだり検索性を高めたりしています。
余談ですが何かインシデントが起きたとき、チームで再発防止策を考えるかと思います。再発防止策は同じミスを繰り返さないための重要な仕組みですが、数が増えてきたりしばらく同じ問題が起きなかったりして気を抜くと形骸化してしまう難しさがあります。microCMSでは再発防止のアクションの一部をClickUpのタスクテンプレートに追加して運用しているのですが、これは毎回のAnkenで必ず意識できるのでなかなか良い気がしています（エンジニアだとPull Requestのテンプレートにチェックリストを足したりしますが、チーム間連携とかフロー系の再発防止策はどこに書いておくか難しかったりするので）。
GitHub
GitHubではPull RequestのタイトルにAnken IDを含むようにしてもらってます。エンジニア以外でもその変更がどのAnkenに関する修正か分かりやすくなっています。
また、リリース前にどういう修正がそのリリースに含まれるかを確認するタイミングがあります。リリース前の統合テスト的なものなのですが、そこでもPull RequestのタイトルにAnken IDが記載されていると状況が把握しやすくなりました。今回のリリースでどのAnkenが世に出るのかを精度高く把握できます。
コミュニケーションの摩擦を減らす
認識齟齬のミスを減らせると良いという、なんだか当たり前のことを書いてしまいました。これは地味ですが効果があります。Anken IDがなくても9割くらいはちゃんと伝わると思いますが、残りの1割の可能性を常に気にしながら仕事や会話を進めるのはストレスになります。そこではなくディスカッションしたい内容そのものに10割の力を注ぎたいですよね。Ankenについて議論・連絡するのは日常的によくやることなので、頻度が高い分改善されるとトータルではかなり楽になっている気がします。
ちなみに各サービスがインテグレーションを実装している場合もあり、例えばClickUpとGitHubをつなぐと自動的にPull Requestがタスク側にも連携されます。こういったインテグレーションはとても便利です。理想的にはすべてインテグレーションで繋がれば良いのかもしれませんが、現状はサービスによって連携に使えるサービスが異なっていたり、欲しい連携がなかったりするので、「Anken IDを書く」という地味だけど一番汎用性の高い方法にしています。
おわりに
自分がサービスのUI/UXを考えるとき、よく「脳への負担を極力減らしたい」というのを考えます。できるだけ何も考えずに機能を正しく操作できるとユーザーもハッピーだよね、という理論です。このnoteを書いていて、それはチーム内のコミュニケーションでも同じなんだなと気づきました。
認識ズレをなくす工夫は地味だけど効果があります。もし同じようなことでお困りの方がいたら、ぜひ試してみて欲しいです。
プロダクトマネージャーをやりながら学んだことを「PdM日記」と名付けて書いてます。よければ読んでみてください:)
X (Twitter): @himara2
この記事が気に入ったらサポートをしてみませんか？