こんにちは、ファインディでFindy Toolsの開発をしている本田です。
このたび、Findy Toolsの新機能として「アーキテクチャAI」をリリースしました。要件を入力するとAWSのアーキテクチャ図と設計の提案が生成される機能です。
今回の開発では、PM・仕様策定・スコープ定義・インフラ・FE/BE開発・テストまで、ほぼ一人で1か月で担当しました。そして、コーディングはほとんどClaude Codeに任せ、私自身はほぼコードを書いていません。
この記事では、そんな開発を進めるなかで分かったこと、難しかったこと、そして改めて実感したエンジニアの仕事について紹介します。
アーキテクチャAIについて
本題に入る前に、リリースした機能を軽く紹介させてください。
アーキテクチャAIは、Findy Toolsの中で提供している機能の1つで、「作りたいシステムの要件」を入力するとAWSを使った構成案とアーキテクチャ図、そして設計の考え方の解説がまとまった形で得られるものです。
ai-architecture.findy-tools.io
アーキテクチャの設計はサービスの土台を決める工程で、経験や周辺知識の広さが問われる領域です。そうした知見を持った人に相談しづらい場面でも、構成の検討を前に進める助けになることを目指しています。
ここから先は、この機能を一人で1か月で作ったなかで気づいたことを中心に書いていきます。
一人開発の全体像
今回は、PMから開発、テスト、リリースまでを一人で担当しました。具体的には次のような範囲です。
- プロダクトの方向性・優先順位の決定
- 仕様策定、スコープ定義
- インフラの構築
- フロントエンド・バックエンドの実装
- テスト、リリース作業
開発のワークフローはシンプルで、だいたいこのサイクルを回していました。
- GitHub Issueに「なぜ作るのか」「何を作るのか」を、PRDやユーザーストーリーの形で書く
- Claude CodeにIssueを渡して実装してもらう
- 自分は差分をレビューし、必要に応じて指示を出す
- 別チームのメンバーにレビューしてもらい、PRをマージする
実装の途中でも、作りたい背景やユーザーに届けたい価値に立ち戻って方針を調整することはよくありました。
仕様策定やUIのモック作成も、AIと壁打ちしながら進めていました。結果として、自分でコードを書いた量はごくわずかで、ほとんどの実装はClaude Codeが書いています。
一方で、「自分はほぼコードを書いていない」からといって仕事が少ないわけではありませんでした。むしろコーディング以外にやることが山ほどあるというのが実感です。
- 何を作るか、何を削るかの判断
- 仕様の細部に関する意思決定
- 技術選定
- コードレビューと品質の担保
- スケジュール管理とリリース計画
ここからは、この進め方で1か月やってみて感じたことを書いていきます。
エンジニアが価値とコストを自分で判断する
最も強く感じたのは、エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携わることの強みです。
今回は一人で担当していたので、事業やプロダクトの意図、技術的な実現可能性、実装コストが、すべて自分の頭の中に揃っていました。「ユーザー価値として外せない部分はどこか」「コストをかける価値があるのはどこか」を、自分の中でつなげて考えながら開発を進めることができます。
具体的には、開発の途中でアーキテクチャ図の描画ライブラリを切り替える判断をしたり、リリースの2週間前になってからSNSで共有されたときに見栄えの良い画像を生成する機能を追加する判断をしたりと、方針転換を素早く進められました。技術的に成立するかをClaude Codeで素早く検証しつつ、プロダクトとして本当に必要かを自分で判断できたことで、価値とコストの両取りを狙える選択肢を見つけやすくなっていました。
体制を一人にしたことが本質ではないと思っています。大事なのはやはり、作る側のエンジニアがユーザー価値や事業価値を理解したうえで、コストと価値のバランスを判断しながら開発に携われているかだと、今回の開発を通じて改めて感じました。
対話で判断の視野を広げる
意思決定が速いのは良いことですが、速ければ良いわけではありません。一つの視点だけで速く判断を続けていると、気づかないうちに筋の悪い方に流れてしまいます。
ここで効いてきたのが、一人で担当していても孤立はしていないという体制づくりでした。
開発中は、事業部長・PO・デザイナと定期的に相談・共有できる場を持ち、それ以外の場面でもいつでもコミュニケーションを取れるようにしていました。
- プロダクトとして何を大事にしているか
- 事業としてこの機能にどういう期待があるか
- デザインとして譲れない部分はどこか
こうした観点を継続的にすり合わせることで、自分一人では見えていなかったより良い選択肢を見つけやすくしていました。
自分の頭の中だけで判断すると、どうしても視野が狭くなります。そこに他の立場の視点が入ると、「他にもっと良い選び方はないか」という問い直しができます。スピード重視の体制であっても、というよりスピード重視だからこそ、チームとの対話は欠かせないと感じました。
動くもので共通認識を作る
もう1つ強く感じたのが、速く見せられるもの・動くものを使って共通認識を作ることの効果です。これ自体は昔からよく言われる話ですが、AIの力でぐっとやりやすくなりました。
今回は、実プロダクトの開発を始める前に、別リポジトリでPoCアプリを作り、ステークホルダーやインタビューにご協力いただいた方に、実際に見たり触ったりしてもらう時間を取りました。
文章やスライドだけで議論すると、どうしても抽象的になり、認識のズレに気づきにくくなります。動くものがあると、「これは欲しい」「ここは期待と違う」というフィードバックが具体的に返ってくるだけでなく、「どういう価値が得られそうか」という部分でも共通認識を作りやすくなります。
PoCを見たり触ったりしてもらうなかで見えてきたのは次のようなことです。
- ユーザーが本当に価値を感じるのはどの部分か
- 最初はあると便利そうに見えたが、実際はなくても困らない機能
- 技術的に見落としていた制約や、逆に想定より軽く実現できそうな部分
PoCで得られたこれらの情報が土台になって、本開発のスコープと方針が定まっていきました。AIで「仮に動くもの」を高速に作れるようになった強みを活かして、動くものを中心に仮説検証のサイクルを回せたことが、1か月という限られた期間のなかで特に効いたポイントだと思います。
自分の仕事は減らず、判断と意思決定の時間が増えた
ここまで書いてきたことを踏まえて、改めて感じたのは少なくとも今回の自分の経験では、コーディングをAIに任せても、エンジニアとしてやることは減らなかったということです。むしろ、本質的な判断に集中する必要が出てきた感覚でした。
今回の開発で自分が時間を使っていたのは、次のような部分です。
- この機能を作る意味は何か、誰のどんな課題を解くのか
- スコープをどこまで広げ、どこで切るか
- どの技術を選び、どの技術を見送るか
- 出てきたコードが本当に要件を満たしているか、将来の運用に耐えるか
どれも、意思決定と判断の仕事です。コーディングそのものをAIに任せられるからこそ、こうした判断に集中できる時間が増えました。
AIと協業するなかで変わる部分と変わらない部分があり、「コードを書く時間」は確実に減りますが、「エンジニアリングを行う時間」は減らない、むしろ増えている感覚でした。
まとめ
ほぼ一人で1か月かけてアーキテクチャAIをリリースしてみて、次のことが学びとして残りました。
- エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携われると、価値とコストの両取りを狙える選択肢を見つけやすい
- 速さだけを追うのではなく、複数の視点を対話で取り込んで選択肢を広げていく
- AIで仮の動くものを高速に作れるようになった強みを活かせば、短期間でも動くものを軸に仮説検証を回しやすい
- 少なくとも今回の自分の経験では、コーディングをAIに任せても仕事は減らず、判断と意思決定に集中する時間が増えた
AIと一緒に開発する時代になっても、「何を作るか」「どう作るか」「なぜそれを選ぶか」を考え抜くことの大切さは変わらないなと、今回の開発を通じて改めて感じました。
アーキテクチャAIは次のページから触れます（Findy Toolsの会員登録が必要です）。ご興味のある方はぜひ試してみてください。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
