Re: チンチロに負けて AI FAX を開発した話
こんにちは。株式会社 IVRy でソフトウェアエンジニアをしている machinaga（@macchiitaka）です。
2024 年 11 月 5 日、IVRy は AI を活用したインターネット FAX サービス「IVRy AI FAX（β 版）」をリリースしました！
先日、同僚の菊川さん（@kikuivry）が「チンチロに勝ったら AI FAX が完成した話」という note を公開しました。
「チンチロに負けた人」である僕の視点から、チンチロ敗北からファーストリリースまでの AI FAX 開発の裏側をお伝えします。
ぜひ菊川さんの記事と合わせてご覧ください。なお、菊川さんの記事が主音声、こちらが副音声的な立ち位置です。
この記事は 株式会社 IVRy 白組 Advent Calendar 2024 の 22 日目の記事です。
白組の昨日は大曽根さん（@dr_paradi）の「いまさら聞けないSaaS+AIの指標」、明日はすぱこーさん（@SpicyCoffee）の「プロダクトエンジニアという魚は水が変わっても生きていけるのか？〜toC サービスから IVRy に転職したエンジニアの事例〜」です。
ノリでチンチロをする、そして負ける
2024 年 9 月初旬、オフィスで仕事をしていると「AI FAX のフロントエンド開発に誰かアサインしたい」という声が耳に入ってきました。その時点で AI FAX の知識はゼロ。何を作るのか見当もつきませんでした。ただ、フロントエンドエンジニアが不足していることだけがわかりました。
あまりにも状況がわからず、自分が手を上げるべきかどうかの判断材料もありませんでした。そこで何を思ったのか「チンチロで決めましょう」と口走ってしまいました。IVRy の Slack にはチンチロ bot が存在します。すると翌日、本当にチンチロ勝負が実現し、見事に敗北。こうして晴れて AI FAX の開発担当となりました。IVRy のノリの良さを甘く見てはいけません。
きっかけは完全にノリでしたが、新規開発は常にワクワクするものです。チンチロに負けて、勝負に勝ったと言えるでしょう。
僕は 2024 年 8 月入社です。つまり入社わずか 1 ヶ月のエンジニアを新規プロダクトの開発担当にアサインしたことになります。今思えば、これは非常に IVRy らしい意思決定でした。IVRy は、新メンバーに対しても信頼を前提としたコミュニケーションを取ります。お手並み拝見期間はありません。この文化があったからこそのアサインでした。
とにかくリリースだ！！！
アサインが決まり AI FAX のプロジェクトについて説明を受けると、ようやく「おお、これは面白そうなプロダクトだ！ぜひ作りたい！」という気持ちが湧いてきました。
AI FAX の開発体制は、PdM の高柳さん（@neveryanagi）、バックエンドの菊川さん、そしてフロントエンドの僕という 3 名構成でした。チンチロ勝負が行われた 9 月 3 日からファーストリリースの 9 月 27 日まで、実装担当者 2 名で集中的に開発を進め、1 ヶ月でリリースに漕ぎ着けました。
開発期間中、僕が心掛けていたことは「とにかくリリースだ！！！」というシンプルなことだけでした。
これには 2 つの理由があります。1 つ目は純粋に、これは良いプロダクトだと確信したからです。「これは早く世の中に出すべきだ！出さねばならない！」という思いがありました。非常にシンプルな理由です。
2 つ目は、AI FAX の開発に若干の停滞感を感じていたからです。これはあくまでも僕の主観であり、実際に停滞していたかどうかは定かではありません。あくまでも肌感覚のレベルです。しかし、あえてこの感覚の背景を分析してみると、それは AI FAX のプロジェクトとしての位置づけに起因していたのではないか？と考えています。
IVRy は 3 ヶ月ごとにプロジェクト編成を見直すプロジェクト制を採用しており、AI FAX はその中でサイドプロジェクト的な位置づけでした。そのため、メインプロジェクトと比べると優先順位は必然的に低くなり、いわば隙間時間を活用しての開発となっていました。スタートアップである IVRy には、取り組むべき課題が山積みの状況でしたから、なおさらです。
この状況で AI FAX を手放さなかった高柳さん、菊川さんの握力に感服すると同時に、どうすればもっと開発を進めやすい環境を作れるか？という考えが浮かびました。
そこでぱっと思いついたのは「勢いをつけて一気にリリースしちゃおう！」です。次のプロジェクトの区切りは 10 月 1 日。プロジェクトを跨ぐと開発リソースの確保に時間がかかりそうでした。「よし、じゃあ今のプロジェクト期間内、つまり 1 ヶ月以内にリリースしよう！」と勝手に決めました。
なお、僕はこの時点でまだプロジェクトの区切りを経験していないので、本当に手間取るのかは推測でしかありません。そう、完全な勘です。その勘をベースにロジックを組み立てていました。
「今プロジェクトでリリースして、次プロジェクト期間内で AI FAX の需要が見えれば、その次にはプロジェクト化するんじゃない？そしたら予算が付いて開発も進むっしょ！そこまでいけば多少の負債なら返済できるし、所詮は 2 人のエンジニアが 1 ヶ月で書いた分のコード量なんて知れているぜガハハハ！」という荒っぽいシナリオを脳内で描いていました。
この脳内妄想を経て、ここからはどうすれば開発速度を加速させられるか？を意識して行動していました。
いざ、開発スタート
不確実性を下げる
チンチロの翌日から即 AI FAX の開発がスタート！というわけには流石にいかず、数日はそれまでのタスクを片付けていました。タスクを片付けるのと並行して AI FAX の仕様を確認し、脳内でシステム設計を完了させていました。
この時点では方法不確実性を下げることを意識していました。スケジュールに不安がある中、それが高いままでは開発全体の不確実性が下がらないからです。そのため設計や実装方法が不明瞭な機能の技術調査を事前に完了させ、その後の開発で躓かないように準備をしていました。
その後、チームでコミュニケーションを取り AI FAX の機能仕様が確定しました。こちらは僕がジョインした時点でほぼ綺麗に決まっていました。機能はまさに MVP（Minimum Viable Product：実用最小限の製品）と呼ぶべき最小要件にまとまっていました。
リソース効率を最大化する
ここからバックエンドとフロントエンドで並列で開発を進めます。お互いフロントエンド、バックエンドどちらも書けるものの、短期勝負のため、最もスピードが出る領域をそれぞれ担当することでリソース効率を高めました。
OpenAPI で Web API のインターフェイスを決めてスキーマ駆動開発で進めました。途中、細かな設計の不備がありましたが、その都度コミュニケーションを取って即時解決するようにしていました。
バックエンドとフロントエンドの疎通確認はほぼ一発で通っていました。これは嬉しくもあり、同時に「そんなにスムーズにいくことあるか？」と疑心暗鬼にもなっていました。開発があまりにスムーズに進むと見落としがあるんじゃないかと不安になりますよね。みなさん安心してください。ちゃんと最後はバタバタとリリースしました。
モメンタムを生み出す
並列で作業を進める中、フロントエンドの開発では画面のある機能から作ることを意識していました。「フロントエンドはだいたい画面あるでしょ？」と思われるかもしれませんが、FAX の特性上、画像変換や PDF の作成など、画面の裏側の機能もそれなりにあります。そして総じてそれらの機能の方が画面よりも開発難易度が高いです。正攻法から言えば技術難易度の高い機能、つまり方法不確実性が高いところから開発するべきですが、あえて画面の作成を優先しました。それはプロジェクトに勢いをつけたかったからです。
見た目にはすごい力があって、それができてくると人は進捗を感じるんですよね。「おお、できてきた！」と盛り上がります。建設中の家の外壁が貼られると突然家ができてきたって感じませんか？まさにあれと同じです。見た目には魔力があります。なので画面のある機能から作って、進捗を演出していました。「あれ、気づいたら AI FAX すごい勢いで進んでない？」と周りに印象付けます。すると自然と開発にリズムができてきます。
この手法は開発に勢いをつけられる一方で、チームへのプレッシャーにもなり得ます。そのため実行するかは慎重に判断するべきです。今回はバックエンドが菊川さんひとりだけの最小チームだったので、僕は安心してアクセルを踏めました。
なお、菊川さんと仕事をするのはこれが初めてです。安心感の根拠は「菊川さんなら大丈夫そう」という勘だけ。慎重に判断するとは一旦何だったのでしょうか。
実際、「チンチロに勝ったら AI FAX が完成した話」の中で菊川さんがハイになっていたと書いてくれていました。この文面を読んだ人の中で、ほくそ笑んでいたのは世界中で僕だけでしょう。ふふふ。
こうしてフロントエンドが爆速で出来上がっていくので、バックエンドも負けてられないとお尻に火がつきました。身近な壁打ち相手ができたのも大きかったです。スケジュールはかなりタイトでしたが、どんどん動くものができていくのが楽しくて、ハイな状態になっていました。
走りながら最適解を考える
一部の機能はバックエンドでもフロントエンドでも機能を提供できます。FAX として送信する画像の変換や PDF の生成機能がこれにあたります。本来であれば今後の拡張性を考慮してあるべき設計を取りたいところですが、ここでもスピード優先です。
バックエンドの方がタスクが多い状態だったため、どちらでも提供できる機能はリソースに余裕があるフロントエンドで開発することにしました。作業量的にバックエンドに割り当てると不均等が生まれ、間に合わなくなるという判断です。
機能をフロントエンドで提供しても、バックエンドで提供しても、それぞれメリット・デメリットがありました。今後を踏まえてどうあるべきか？を判断できるほど僕らはまだ賢くありませんでした。これらはプロダクトをリリースしなければわかりません。本当にフロントエンドでやるのがベストだったのか？はこれからわかります。
ここからはまた雑な妄想です。「AI FAX がリリースされて、需要があることわかれば予算が付くはず。2 人のエンジニアが 1 ヶ月で開発したシステムなんだから、拡張性さえあればいくらでも変更可能だ！だからまずはリリースだ！」このロジックで進めました。そろそろ僕の思考パターンが読めてきた頃かと思いますが、これは戦略ではなく、ただの脳筋です。
開発期間はタイトでしたが、変更容易性とテスタビリティは絶対に確保するように開発しました。これらを確保できなければ先の妄想は絵に描いた餅で終わってしまうからです。各機能の追加 Pull Request を作成する前に、必ず半日から 1 日程度はリファクタリングの時間を設けるようにしました。そのためにも機能の開発は常に一日前倒しで進めるようにしていました。また、リリース後に AI FAX の設計思想や技術的な詳細をドキュメントにまとめ、属人性を下げるようにしました。
最後の追い込み
この 1 ヶ月間はお祭りのような勢いで開発を進めました。最終盤、ステージング環境でシステム結合に入ります。ここで並列で進めてきたことが裏目に出ます。CORS や IP 制限の設定などに漏れがありました。ここまでリソース効率を優先し過ぎたあまり、結合テストが甘くなっていたのです。慌ただしく SRE チームにインフラを設定してもらったり、terraform を書いてなんとか QA 評価できる状態まで仕上げました。
また、一部のモバイル端末で動作不良がありました。AI FAX のファーストリリース時点（2024 年 9 月末）では、まだプレスリリースを出しておらず、お客様の端末も限られていたため、こちらは後追いで修正版をリリースすることで対応しました。
慌ただしい最後の追い込みを経て、なんとかリリースに漕ぎ着けました。IVRy は全体としてスピードのある会社ですが、AI FAX を開発していた 1 ヶ月はさらに一段、速いスピードを感じました。まさにお祭りでしたね。本当に楽しかった。
そして開発は続く
AI FAX は好評いただいており、さらなる機能拡張を目指しています。はい、もう何を言いたいのかわかりますね？
そう、メンバーを大募集しています！
AI FAX に限らず IVRy では電話の自動応答やここでは言えないあんなプロダクト、こんなプロダクトを計画しています。
手前みそですが、開発中は「このプロダクト絶対いいじゃん！」と確信を持って開発をしていました。この感覚を持てるのはエンジニアにとってとても幸せだと思います。「これは誰の役に立つんだろう…」とモヤモヤしながら開発する時間はありません。QA 評価中には QA エンジニアから「革命起きてる」とコメントを貰い、僕も内心「そうでしょう？」とニヤついていました。
最後に例のリンクを添えて副音声は終了させていただきます。では 🎲🎲🎲