こんにちは、トモラク株式会社の渋谷です。
突然ですが、こんな経験はありませんか？
「仕様書を受け取って実装したら、そもそもこの設計は無理があった」「テストケースを別の人が書いてくれたけど、実装の意図と微妙にズレていた」「リリースしたけど、その後どうなったか結局わからない」
分業制の開発では、こういったすれ違いやもどかしさが生まれやすいものです。
トモラクでは、エンジニアが仕様策定・UI作成・テストケース作成・開発・リリース・効果測定をすべて担当する「フルサイクル開発」という形で開発を進めることがあります。
今回は、この開発スタイルを選んでいる理由と、実際にどんな良いことがあるのかをご紹介します。
フルサイクル開発って何？
一般的なプロダクト開発では、PdM・デザイナー・エンジニア・QAといった役割が分かれており、それぞれの担当がバトンを渡しながら進んでいきます。
トモラクではこの「バトン」をなくし、エンジニア一人が最初から最後まで責任を持って開発します。
【一般的な分業開発】
PdM → デザイナー → エンジニア → QA → リリース → (別チームが効果測定)
【トモラクのフルサイクル開発】
エンジニアが仕様策定 → UI作成 → テスト設計 → 実装 → リリース → 効果測定
ただし、ここで一つ大事なことをお伝えしておきたいです。
「一人が担う」≠「一人で全部決める」
仕様の方向性に迷ったとき、設計に不安があるとき、チームメンバーへの相談やレビューは当然あります。むしろトモラクでは、要所要所でしっかり議論することをとても大切にしています。
相談・レビューこそがフルサイクル開発の要
実はこれ、私自身が身をもって学んだことです。
フルサイクルで動いていた頃の話ですが、最初のうちは「自分でやりきらなければ」という意識が強く、迷いがあってもそのまま実装を進めてしまうことがありました。結果、よくない仕様のまま進んでしまって大きな手戻りが発生する、ということが何度かありました。
その経験から、迷ったら積極的に相談するスタイルに切り替えました。すると手戻りが明らかに減り、開発のスピードも品質も上がっていきました。
「相談することで一人のオーナーシップが薄れる」わけではありません。最終的な責任と推進力は自分が持ちながら、判断に迷う場面では仲間の視点を借りる。このバランスがフルサイクル開発をうまく回すコツだと思っています。
LLMが「越境」のハードルを下げた
フルサイクル開発と聞くと、「エンジニアがUIも仕様も全部やるの？」と感じる方もいるかもしれません。確かに少し前までは、専門外の領域に踏み込むには相応のコストがかかりました。
しかし今は、LLMがその状況を大きく変えつつあります。
たとえば仕様策定の場面では、「このユースケースで考えられる仕様の選択肢と、それぞれのトレードオフを整理して」とLLMに投げかけることで、思考の整理やアイデア出しをサポートしてもらえます。UI設計でも、「このフォームのUXで気をつけるべき点は？」と聞けば、専門的な観点のフィードバックをすぐに得られます。
もちろんLLMの出力をそのまま使うわけではなく、最終的な判断はエンジニア自身が行います。しかし「専門外だから触れない」という心理的・実務的なハードルが、LLMによって確実に下がっています。
エンジニアが越境しやすい環境が整いつつある今だからこそ、フルサイクル開発というスタイルがより現実的な選択肢になってきていると感じています。
やってみて感じたメリット
1. コミュニケーションコストが劇的に下がる
関わる人数が少ない分、「この仕様、誰に確認すればいい？」「実装の認識合わせをしたい」といったやりとりが大幅に減ります。
周知の手間も同様です。仕様変更や設計変更が生じたとき、分業制だと多くの人に連絡・調整が必要になりますが、フルサイクルでは関わる人数が少ない分、相談・合意すべき相手がシンプルになります。もちろん仕様変更の際は関係者に相談し、仕様書やテストケースも更新しますが、そのコストが分業制と比べてずっと小さく済みます。結果として、意思決定とリリースまでのスピードがかなり上がっています。
2. 実装視点で仕様の良し悪しを判断できる
仕様を書く人と実装する人が同じなので、「これ実装するとかなり複雑になるけど、本当にこの設計でいいんだっけ？」と早い段階で気づけます。
トモラクはアジャイル開発を重視しており、作り込みすぎないことを大切にしています。仕様と実装を同じ人が担うからこそ、「この要件はもっとシンプルな実装で実現できる」という提案を仕様レベルで行えます。結果として無駄な作り込みが減り、開発スピードの向上に直結しています。
3. 責任感とオーナーシップが生まれる
全工程に関わるということは、そのプロダクト・機能への当事者意識が自然と育まれるということでもあります。
「自分が仕様を決めて、自分が作って、自分でリリースした」という体験は、プロダクトへの愛着と責任感につながります。「作って終わり」じゃなく、効果測定まで見届けるからこそ、次の改善にもつながるサイクルが生まれています。
4. 品質への感度が上がる
UIも自分で作り、テストケースも自分で考えるので、「使いやすいか」「抜け漏れがないか」を実装と同じ目線で考えられます。
仕様・実装・テストの一貫性が保たれることで、「仕様書と実装の解釈が違った」というような認識のズレによるバグが起きにくくなるのも実感しています。
5. エンジニアとしての成長が加速する
仕様策定やUI設計、効果測定まで関わることで、技術だけでなくビジネス視点も自然と身につきます。「必要なものを最速でお客様に届けるにはどうすべきか」を技術ベースでも仕様ベースでも考えられるエンジニアになれる環境です。
おわりに
フルサイクル開発は、「少人数でも大きな価値を生み出せる」という考え方のもとに成り立っています。
そしてそれは、一人が孤独に全部抱えるということではなく、チームで支え合いながらも一人ひとりが主体的に動ける、そんな開発スタイルです。
LLMの普及によって、エンジニアが専門外の領域に踏み込むコストはこれからもどんどん下がっていくはずです。そんな時代において、フルサイクル開発は「一部の特殊な開発スタイル」ではなく、多くのチームにとって現実的な選択肢になっていくのではないかと思っています。
トモラクでは現在、一緒にプロダクトを作ってくれるエンジニアを募集しています。もし興味を持っていただけたら、会社のHPを見てみてください！
Discussion