ちょっとしたツールを作るときの考え方と技術スタック
最近仕事でプロダクトの初期段階を作ったり、小さなツールで問題解決したりすることが多いので自分なりのやりかたをまとめておく。
まず、本当にモノを作る必要があるかを考える
逆説的だが一番大事なステップ。エンジニアをやっていると、問題を聞きつけたときにすぐそれを解決するツールを作りたくなる。
しかし、ユーザーに聞いてみると実はそんなに困っていなかったり、既存のツール（たとえばZapier）を使えば解決したり、1回気合で手作業するだけで良かったりすることがそこそこの頻度で存在する。
何かを作るということはその運用・メンテナンスの責任を追うことでもあるので、作ることには慎重になり、極力引き算で考えるのが良い。
作るとなったときにやること4選
だいたいヒアリング、紙に図を描く、Design Docを書く、実際にモノを作るの4つを行ったり来たりしながら進めることが多い。
似たような課題を以前に解いたことがあればモノを作るところから始める、全くユーザーの気持ちが想像できていない状態であればヒアリングから入る、のように状態に応じて臨機応変にやる。
ヒアリングをする
何に困っているかが腹落ちしていないときに行う。実際に問題を抱えている人にその課題について聞きつつ、以下の疑問に自分の中で答えが持てるようにする。
発生している問題のコアはなにか（何が一番厳しいポイントか）
仮にツールが存在して、本当に幸せになるか
どういうスコープでツール化すると前後の業務とのつながりが良いか
自分の手持ちの技術で解決できそうか
紙に図を描く
実現したいもののイメージがボヤっとしているときに行う。
ざっくりの画面を書いてイメージを具体化する
情報の流れとユーザーの操作手順を書き出して認識のズレをなくす
あたりを目的としている。見慣れない課題を解く場合や、この手の課題解決に不慣れなときは毎回やると良い。
いくつか描いてみた図を持ってヒアリングすることもあるし、オフィスに出社したときには実際に課題を持っている人とホワイトボードの前で話しながらやるのもオススメ。
Design Docを書く
作るスコープを自分に言い聞かせるために書く。ヒアリングを通して理解した課題を決まったフォーマットに落とし込みつつ、作るモノのイメージを固める。
Design Docの説明やその意義はWeb上にたくさん解説があるのでここでは省略するが、小さいツールを作るときは以下のフォーマットを埋める程度で良いと思う。
Goals / 結局何を実現したいのか
Background / ツールを作るに至った課題は何か
User Stories / ユーザーはこのツールで何ができるか
「（ユーザー）は（行動）できる。なぜなら（願望）だから」の形式で書くとよい
Functional Requirements / 実際どう作るか
紙で書いた図とか、システム構成図とかもここに書く
チームで開発するときはもう少し項目を増やして詳細に書いたほうが良いが、ひとりで開発するときは実現したい体験を自分が見失わない程度に書けばよいと思う。
実際にモノを作る
実際にプログラミングする。意識していることは
手に馴染んだ技術を使う
出来合いの技術を最大限組み合わせて使う
の2つ。目的はユーザーの課題を解決することと、それに自分の開発したモノが適しているかを検証することなので、車輪の再発明を避けてできるだけ早く作る。ついでに新しい技術も学ぼう、みたいな欲を出さないほうが良いことが多い。
よく使う技術スタック5選
ここまで考え方を書いてきたので、最後に自分の手に馴染んでいる技術スタックを列挙しておく。粒度は全然揃ってないが、ここに書いてあるものを組み合わせて課題解決することが多く、頻繁に使っていてすぐ取り出せる状態になっている。
Python
自分の主力言語のひとつ。ちょっとしたスクリプトもかけるし、エコシステムが充実していてプロトタイピングしやすい。本当に必要なら scikit-learn とかで機械学習も持ち出せるのもいい感じ。
CSV + Google Sheet
結果を .csv や .xslx で書き出して Google Sheet や Excel で渡してユーザーに使ってもらうパターン。
表計算ソフトは良くできていて使い慣れている人も多く、UI部分を考えずにロジックに集中しやすいので使いやすい。
ユーザー体験を少し犠牲にして、前後の業務とのつながりを大事にするときに使うことが多い。
Streamlit
Pythonスクリプトを書けばきれいなUIが出来上がるライブラリ。最近の主力。特にインタラクティブな体験を提供したいときによく使う。
UIを作り込まずともかなりレベルの高い体験が提供できるのでロジックに集中できる。必要に応じてデータをキャッシュするなど体験を作り込むこともできるので、プロトタイプの先の提供もある程度カバーできる。
Streamlitを使ってローカルで動くアプリを作り、そのPCをユーザーに操作してもらって検証するパターンがおすすめ。
Cloud Run
Streamlitで作ったアプリを社内展開するときによく使う。StreamlitのアプリをDocker Imageに固めて、Cloud Runにデプロイ。社内ツールの場合は認証が必要なので Identity-Aware Proxy (IAP) を利用すれば Google Groups を利用した認証がかけられる。
標準出力に構造化ログ（JSON形式のログ）を出力しておくことで、Cloud Loggingで利用状況のモニタリングもできる。
Slack App
Slackを利用することでUIをサボる。Slackにユーザーとの接点を寄せることで気軽に使えるほか、利用した履歴がSlack上に残るため後からユーザーのサポートをしたり監査に利用したりできるのも良い点。
他のSaaSとやりとりする系のアプリケーションであればZapierで作るのが選択肢に上がる。
自前でロジックを組む場合、Slack BoltというSDKを使うか Slack Next-Gen Platformを使うかが選択肢としてあるが、小さなツールの場合はSlack Boltを利用するのが今のところ良さそう。
デプロイはたいていCloud Runを利用している。
(おまけ) ChatGPTなどのAPIについて
ロジック部分にLLMを利用することは少しずつ増えてきたし、今後も増えていくと思う。
使う上では、ユーザーとLLMとの接点をうまく設計し、ユーザーが担当する仕事とLLMが担当する仕事をうまく切り分けることが大事だと感じる。
おわりに
ユーザーの課題解決のために小さなツールを作るパターンを整理してみた。書いてみて改めて、
ユーザーの課題を特定し、本当に技術で解決すべきかトリアージすること
何かを作る場合は小さく早く作ること
の2点が重要だと感じた。
小さいツールを作るのはプロダクトマネジメントの勉強にもなるので、これを読んでくれた人はぜひやってみてほしい。
いただいたサポートは机の上のガジェットや妻とのご飯に使わせていただきます。 SNSでnoteをシェアしていただくのも大きな励みになります。よろしくおねがいします。