「LLMをプロダクトに組み込んで、新機能を開発しました！(ｷﾗｷﾗ)」
(うおっまぶしっ！過去の自分...！)
というのは冗談で。
今回はその裏側が必ずしもキラキラしておらず、泥臭さにあふれていたことを3つに分けてお話ししようと思います。
そういった話こそ役に立つと信じて。多くが5月以前の事例なので、今はもっと便利なツールがたくさんあります。お手柔らかに。
リンクアンドモチベーションでQAやEMをしている小島です。
β版を6月ごろに、正式版を8月にリリースしました。
βのプレスはこちら
試行錯誤に集中できる環境づくりから
仕様を細かく決めてからプロンプトを実装しよう！
...ではなく、大枠を決めたらとりあえずプロンプトを動かしていきました。
すぐに動作してくれるのは嬉しい限り。
実行環境には、Opt-OutされたアカウントでOpenAIのPlaygroundを使用しました。
実行環境を自前で作らなくても試行錯誤できるのでおすすめです。
System, User, Assistantの使い分けや、パラメータ(Top PやTemperature)の理解も、GUIのおかげで誰もがスムーズに進められたのは副産物でした。
GPTには過剰に期待しよう
さて、環境が整いました。
最初はとにかくLLMに無茶振りしてみましょう。
gpt-3.5-turboを本番で使うにしても、まずはGPT-4で試したり、Top PやTemperatureを高めに設定してみることがおすすめです。表現幅が大きなLLMを使用することで、「おぉ！ここまでできるのか！！」という結果が出せるケースがあるからです。特に、複雑なプロンプトを組む必要がある際には有用です。
１つでも理想形が見つかったら、それを再現できるような具体的な指示をプロンプトに書き出していきます。
Top PやTemperatureを低くしながら、時にGPT-4をgpt-3.5-turboに変更しつつ、出力の安定を狙います。
再現が難しければ、「その返答を再現できそうなプロンプトを書いて」と頼んでみるのもいいでしょう。
理想の返答が安定的に返ってくるようになったらプロトタイプの完成です。
バージョン管理は突然に
ワイワイとみんなで試行錯誤をしていると、次はプロンプトのバージョン管理が必要になってきました。
OK！GitHubでいい感じに管理を...と思ったのですが、大事なのは「誰にでも(エンジニア以外でも)」「すぐに」「最新版を使える」こと。
「Aさんの最新プロンプトをPlaygroundにコピペして改善したい！」という開発者体験を実現しようと、スプレッドシートでプロンプト集シートを作成しました。
こうすることで、誰でも最新のプロンプトを改善できるようになりました。
飛び込んで来てくれたデザイナーやEMも一瞬でオンボードでき、オンボードの途中で驚く姿にメンバーもちょっと得意げなご様子。
なお、完成したらバージョン管理ツールに移行することをおすすめします。あくまでみんながわいわいと試行錯誤できるようになるための仕組みです。
プロトが動くならインタビューにも出れる！
プロンプトだけで最低限の価値が出せる場合、この段階で顧客インタビューにも出れてしまいます。まずは社内のメンバーに意見を聞いてみるのもいいでしょう。
とにかく、できるだけ早く・多くプロトタイプでの仮説検証を進めました。
もちろん多ければ多いほど良いわけではありません。インタビューのたびにプロンプトの内容や、出力結果を埋め込むデザインを改善して仮説検証しています。健全な仮説検証の打席数が増えるのは本当に大事なことでした。
エンジニア・デザイナー・PdMがリアルタイムで連携してインタビューの準備を進めていくスピード感も、お祭りみたいで楽しい体験です。
まだまだあるよ！そろそろインフラ設計をしよう！
OpenAI Playgroundで実装したものを、どうシステムに落とし込もうか？
Azure OpenAI Serviceも使ってみよう！
ということで、SREやテックリードと力を合わせてインフラ構成の設計も始めました。
OpenAI APIとAzure OpenAI ServiceのAPIで出力が異なる場合も多々あります。
使用するAPIはできるだけ先に確定させておきましょう。
JIRAを手放す、そして取り戻す
1日どころか数時間でやるべきことが変わるプロジェクトの水面化では、
「スプリントでタスク管理できない！」
「JIRAでうまくタスク管理できない！」
という課題にみんなが頭を抱えていました。
もちろんJIRAでうまく進める方法もあったと思うのですが、チームメンバーの意見ベースで3つのコミュニケーションルールを作成しました。
- 朝会ではStandup & Prosper(下画像)で各自のタスクや相談を共有しよう！
- 困り事は逐次gather.town(ビデオ会議ツール)やSlackで！
- 毎日夕会を行い、緊急の共有や合意事項のまとめ、課題管理を行おう！
普段は朝会でスプリントゴールや各自の週次目標への到達度合いも共有しています。
ただ、プロジェクトの中盤までは週次のゴールがすぐ変わりやすかったので、「やったこと」だけで軽量に運用していました。
不確実性が少なくなってきたタイミングで、JIRAは無事復活を遂げました。
そうだ、MVPを作ろう。
MVPを考える前は、最初から正式版としてリリースする想定で詳細まで練っていました。しかし、早期にリリースしてフィードバックをもらおう！と意思決定し、最低限に削ったMVPを定義し始めました。
合意できている仕様とそうでない仕様がわかりやすいよう、付箋の色にルールを設けています。
青が合意、ピンクが課題や質問、緑が情報。
どんどん青色が増えていくと進捗感も出ていい感じです。
1日でも早くお客様に試してもらえるよう、みんなで集中的に議論をして実装を進めました。
おまけ: 溶けていく役割を常に明らかに
LLMを活用したプロジェクトは、いい意味で役割が溶けていきました。プロンプトが誰にでも改善できるのは大きなポイントです。
ただ、常に各自が役割を変え続けると急にボールが落ち始めます。なので、定期的に役割や移行度合いを明示化しておくことが必要でした。
まとめ: 技術進化を組織進化のきっかけに
書いたことのいくつかは、LLMだけでなく普段の開発でも実践できるノウハウだったと振り返ります。いつも同じプロセスを磨き続けることで開発を進めるだけでなく、時には大きくプロセスを変えることも、チームの基準を高める上では効果的かもしれません。開発の中でのコラボレーションの形が幾分か変わるLLMを、そんな変化のきっかけとして活用するのも一手なのではないでしょうか。
