新しいツールを調査するときの心得

風音屋の兼業データアナリスト、星野（@mochigenmai）です。

この記事は僕が新しいツールを調査するときに意識している心得をまとめたものです。元々は社内向けに作成した記事なのですが、もっと多くの人に届けられるといいなという思いで社内記事の内容をほぼそのまま発信することにしました。新しいツールを社内に取り入れるために調査を行っている人の参考になれば幸いです。

1. 調査のフォーカスポイントを明確にする

1-1. 課題を特定する

まず、以下のようなフォーマットを使って課題を言語化してみてください。

このステップを行うことで、依頼者はそのツールに何を求めているのかが整理され、無駄な調査の削減や、調査対象の変更など柔軟な対応ができます。結果として「依頼者の求めているアウトプットと違った」といったことが起きにくくなります。 また、レポート作成時には、調査を通して何を伝えるべきかが明確になるため「調査の結果をどうまとめていいか分からない」といったことが起きにくくなります。

💡 誰　　　　　　　 : __________ は
🕐 場面　　　　　　 : __________ とき
💭 目的　　　　　　 : __________ したいが
🚫 阻害要因　　　　 : __________ によって実現できないため
🗿 不合理な代替手段 : __________ によって解決しようとしており
🌋 課題　　　　　　 : __________ という課題がある

参考 : スマートバンクさんの @Think N1 Sheet(公開用)

1-2. 課題を解決したとみなせる最低限の条件・要素を定義する

課題が特定できたら、その課題を解決したとみなせる最低限の条件・要素を定義します。これを行うことで、調査内容を以下のようなパターンでまとめることができ、安定した品質の調査レポートを作成できます。

• 定義した条件・要素で課題を解決できなかった場合
  • どういった条件・要素は満たせていたのか（反対にどういった条件・要素が満たせていなかったのか）を記述する
  • 他のツールによってその課題は解決できないかを記述する
• 定義した条件・要素で課題を解決できた場合
  • そのツールの何の機能によって、どのように課題が解決されるのかを記述する
  • そのツールの応用した使い方を記述する
    • そのツールには他にこのような機能があり、それを組み合わせるとこういったことができる
    • 他のツールと組み合わせるとこういったことができる
    • 今後こういったことができる可能性がありそうでも良い

また、コストや制約などすでに分かっている情報があれば、それも一緒に言語化しておくとさらに調査ポイントが明確になります。

2. ツールを調査する

メモは自分だけが分かるものでいいので必ず残してください。ポイントとなりそうな箇所はスクショも撮っておくのがオススメです。調査内容をまとめる時に「あの時スクショを撮っておけば良かった」と思うことがよくあります。

体験談 : 無駄な動作確認をしていた話

調査に慣れていない頃はメモを残すことが少なく、調査内容をまとめるときに再度同じ動作確認をしてスクショを撮っていました。しかし、調査したときと全く同じ動作にならず、文章の方を修正するといったことが起きていました。

• 公式ドキュメントではないもの（これ以降は 非公式ドキュメント とする）をなるべくたくさん読む（Xのポストなどもユーザーの反応が分かるので良い）
  • 今回の調査対象ツールの類似ツールが見つかる
  • 応用した使い方の事例が見つかる
  • 事前に他の人がそのツールを使う上でハマった箇所に気が付ける
• 公式ドキュメントを読み込む（1-2 で定義した条件・要素を重点的に）
  • 公式が一番正しい情報であり、これを元に調査レポートをまとめられる（公式を参照しながらの説明が一番説得力が増す）
  • 公式では推奨していないが、非公式ドキュメントで紹介されている使い方などは Appendix 用の「応用した使い方」としてメモを残しておく
    • 応用した使い方についての公式の見解や、やり方も押さえておく
• 実際に動作確認できる場合は実施する
  • 公式ドキュメント通りに動作させることができるか試す
    • 環境によって権限やセキュリティなど公式通りにはいかないことがよくある
    • つまづいた箇所があったら1つ1つの操作レベルでスクショやメモを残しておく（他の人が調査レポートを読んで再現した時に解決できるようにするため）
  • 応用した使い方も動作させることができるか試す
• 解決できない疑問が出てきたら他者を頼る
  • 公式に問い合わせる
  • 有識者を探して壁打ちしてもらう

体験談 : 公式ドキュメントを全然読まなかった人が読むようになった話

有名なツールだと非公式ドキュメントが豊富なので、わざわざ公式ドキュメントを読む必要はないだろうと思っていました。日本語で読むことができ、応用事例も多く紹介されているからです。しかし、最新のアップデート内容が抜け漏れたり、「依頼者が知りたいこと」ではなく「みんなが紹介していること」の調査になってしまったりすることが多発しました。今にして思うとプロフェッショナル意識が低かったのだと思います。「自分がこのツールの先駆者になるんだ」と思うようになってからは、しっかりと公式ドキュメントを読み込むようになりました。

3. 調査内容をまとめる

まず、依頼者以外の想定読者をイメージします。イメージした想定読者のリテラシーに合わせながら調査内容をまとめます。以下のようなフォーマットを利用することで、情報の過不足が起きないようにまとめることができます。調査したものや想定読者によって構成は変えるべきで、必ずしも以下のフォーマットでまとめればよいわけではありません。参考程度に留めてください。

1. 課題の定義
   • こういった場面でこういった課題に直面していませんか
   • その課題を解決するためにはこういったアプローチが考えられます
   • このツールを導入することで、そのアプローチを実現することができそうです
2. メインで調査したツールと他の類似ツールの紹介
   • 公式的にはこう謳っているツールであり、この点が優れています
   • このツールと近い機能を持ったツールにはこれがあります
   • それらにはこういった違いがあり、メリットとデメリットはこうです
3. 具体的な動作の紹介
   • 公式で紹介されている使い方の手順はこうです
   • この場面でこういった落とし穴があり、対処方法はこうです
   • 応用した使い方にはこのようなものがあります
4. Appendix
   • 公式では推奨していないみたいですが、工夫するとこういった使い方ができます

4. さいごに

新しいツールを調査する場合、まだ情報が世の中に出回っていないことも多く、そのため、調査や検証をしている自分が一番知識がある状態になりやすいです。自分より詳しい人がいないように感じて、誰にも相談できない状態に陥り、自分の調査結果に対して自信が持てず不安を抱くことも多いかと思います。

しかし、壁打ちのつもりで誰かに相談してみると、問題を解決できなくても調査や検証の進め方が見えてくることがあります。なので、困ったらすぐに相談するようにしましょう。

また、分からないことがあった時は積極的に公式と連絡を取るようにしましょう。はじめは、公式に連絡したくない気持ちになることがあるかもしれません。僕自身も以前は、公式に問い合わせるという経験があまりなかったため、「公式に問い合わせる」＝「クレームをつける」というような印象を持っていました。しかし、公式と一緒にそのツールを盛り上げるアンバサダー的な役割になっていると感じるようになってからは、むしろ積極的に公式に連絡を取れるようになれました。公式側はユーザからの貴重なフィードバックとして扱うことが多く、あまりネガティブに感じないものなので、そういったモチベに切り替えていきましょう！