動画を自動で翻訳してくれるアプリを新卒みんなで作りました【CTOづやの宿題】

こんにちは！ デザイナーのもんろーです。

今回は、新卒向けの技術研修「CTO合宿」で取り組んだプロダクト開発についてご紹介します。

CTO合宿では、職種や得意分野の異なる新卒メンバーがチームを組み、短期間でひとつのプロダクトを企画・設計・実装・テスト・リリースまでやり切ることに挑戦しました。

今回私たちが取り組んだテーマは、「動画をアップロードするだけで、言語を自動認識し、英語へ翻訳してくれるWebアプリ」の開発。

エンジニア、デザイナー、PMそれぞれが役割を持ちながら、ゼロからプロダクトを形にする実践的なチーム開発を経験しました。

最初は右も左もわからない状態からのスタートでしたが、議論を重ね、試行錯誤しながら、なんとか「動くプロダクト」までたどり着くことができました！

この記事では、そんなCTO合宿の制度紹介と、わちゃわちゃしつつも本気で取り組んだ開発のプロセスを振り返っていきます。

CTO合宿とは？

▲LIGのCTO・づやさん

CTO合宿は、LIGのCTO・づやさんが中心となって実施している新卒向けの技術研修です。

最大の特徴は、「チームでプロダクトをリリースするところまでやり切る」こと。

単に技術を学ぶだけでなく、設計・役割分担・スケジュール管理・意思決定など、実際の開発現場に近い経験を通して、開発全体を俯瞰できる視点を身につけることを目的としています。

合宿は1泊2日で実施され、その後約1週間の課題期間を設けて、プロダクトの完成を目指しました。

課題は「ElevenLabsを使った翻訳システム」

CTOから渡された要件はこれだけ。

• ElevenLabsを使った翻訳システムであること
• 日本語の動画をアップロードし、英語へ変換できること（音声・字幕は選択式）
• 対応言語はできるだけ多いほうがよい
• 動画だけでなく、添付資料も英語に翻訳できること
• 可能であれば、会議のリアルタイム翻訳にも対応できると理想

細かい仕様や実装方法は一切決まっておらず、「何を作るか」「どう作るか」も含めて新卒メンバーに委ねられていました。

メンバー紹介

今回この課題に取り組んだ24・25新卒のメンバーを紹介します！

	PM担当：タカラいろいろなチームを駆け回っている。業務コンサル、セールス、テック案件/Web案件のデリバリーに従事。👉️メンバーページ

	設計担当：やましょうAI推進チームに所属。基幹システムの開発・保守に従事。👉️メンバーページ

	デザイン担当：もんろーUIUXチームに所属。画面デザイン業務に従事。👉️メンバーページ

	フロントエンド担当：にっしーSystemArchitectチームに所属。FE開発・最近はレビュー業務多め。👉️メンバーページ

	バックエンド担当：まさSystemArchitectチームに所属。普段は設計・バックエンド開発に従事。👉️メンバーページ

	バックエンド担当：いおりんSystemArchitectチームに所属。最近はフロントエンド開発に従事。👉️メンバーページ

それぞれ普段の業務も得意分野もバラバラ。考え方や作業スタイルの違う6人がチームを組み、ひとつのアプリを作りました。

メンバーたちがどんなふうに力を合わせて開発を進めていったのか、制作のプロセスとともに振り返っていきます！

開発の流れ

ここからは各フェーズの担当者に話を聞きながら、実際にどんなことをしていたのか、工夫やトラブルなどを紹介していきます。

1. 要件の整理

▲役割分担をし、誰がどう動くか決めている新卒たち

まず取り組んだのは、CTOから渡された要件をもとに「このアプリで何を実現するのか」を整理するところからでした。

動画翻訳というテーマは決まっていたものの、どこまでの機能を持たせるのか、どんなユーザーを想定するのか、どのようなシステム構成で実装するのかは、すべてチームに委ねられていました。

限られた期間の中で作り切るため、今回は「1週間で完成させられる現実的なスコープかどうか」を特に重視。

エンジニアメンバーに実装の難易度を確認しながら、CTOのづやさんとも認識をすり合わせ、要件にブレが出ないよう慎重に進めました。

中でも苦労したのが、外部サービスである ElevenLabs の仕様把握です。限られた時間の中で「何ができて、何が難しいのか」を整理し、要件にどう落とし込むかを考える必要がありました。

正直、1日でやるものではないと感じました。（タカラ）

2. 画面遷移図・ワイヤーフレームの制作

担当：タカラ（PM）、もんろー（DE）

要件整理で洗い出した機能をもとに、「どんな画面が必要で、ユーザーはどんな順番で操作するのか」を整理し、画面遷移図とワイヤーフレームを Figma に書き起こしていきました。

このフェーズで特に意識したのは、ユーザーが迷わず操作できるかどうか。機能をただ並べるのではなく、操作の流れが自然か、使う側の視点で考えるようにしました。

一方で、エンジニアから「このエラーはどこで表示するの？」「この機能、ここにも影響しそう」といった指摘が次々に出てきて、自分たちの想定が甘かった部分が浮き彫りに。

デザイナーに伝える業務と、エンジニアに伝える業務があり、自分の中で整理して伝える力が必要だと感じました。（タカラ）

3. APIの整理

担当：まさ（BE）

FIgmaや要件定義で洗い出された機能をもとに、必要なAPIの基本設計をおこないました。エンドポイントとメソッド、想定リクエストと想定レスポンスをテーブル定義とともに仕上げました。

開発期間が限られていたため、フロントエンドと連携しやすい、シンプルな構成を意識して設計。要件自体はある程度固まっていたこともあり、主軸となる API は比較的スムーズに整理できました。

基本設計は大事だけれど、要件が定まりきってないとゴミとなる。（まさ）

4. 画面デザイン

担当：もんろー（DE）

ワイヤーフレームをもとに、画面デザインの作成を担当しました。ボタンやヘッダーなどの要素をコンポーネントとして分け、エンジニアが実装しやすい構成を意識しています。

今回、アプリ全体のデザインを一人で担当するのは初めて。Figma の使い方を調べながら、「使う人はどんな状況でこの画面を見るのか」を考えつつ進めました。

ただ、Figma の使い方が曖昧な部分も多く、エンジニアから細かいレビューをもらう場面も。

Figmaの使い方や、エンジニアの作りやすさが考えられたデザインを学べてよかった。楽しかった。（もんろー）

5. システム設計・インフラ設計

担当：まさ（BE）、にっしー（FE）

要件を実現するために必要な技術構成を検討し、インフラの構築を進めました。

今回はプロトタイプ開発がゴールだったため、費用と実装コストをできるだけ抑える構成を意識しています。

インフラが構築できないと開発が進まない状況だったので、急いでインフラの実装をおこないました。また、最初にフロントサーバが必要かも？ という話になって作成しましたが、実装途中で開発方針が変更になったので不要になったり……と必要なシステム要件の選定の難しさを感じました。

次インフラを作るときはもう少しきちんと作る。（まさ）

6. デザイン反映

担当：にっしー（FE）、いおりん（BE）

画面デザインをもとに、フロントエンドの実装を進めました。

複数人での実装となるため、他のメンバーも扱いやすいよう、コンポーネントの切り分けや構成を意識しながら作業しています。

実装の中では、デザイナーが意図していた見た目や挙動をどのようにコードで表現するかに悩む場面も多くありました。

特に動画アップロード周りの機能は処理が複雑で、バリデーションの実装に想定以上の時間がかかりました。加えて、仕様やデザインの変更も重なり、当初の見積もりよりも作業が遅れてしまう場面もありました。

しんどかった。（にっしー）

7. バックエンド開発

担当：まさ（BE）、いおりん（BE）

バックエンドでは、動画ファイルの連携や翻訳処理、ユーザー認証など、アプリの中心となる API の実装を進めました。

ElevenLabs API の仕様を踏まえ、要件を満たすためにどのような仕組みで実装するかの調整に時間がかかりました。

特に、利用していたインフラサービスの Lambda には実行時間が15分までという制限があり、15分以上かかる翻訳処理をどのように扱うかが大きな課題でした。

また、セキュリティを担保するため、これまで使ったことのないセッション管理の方法を採用したり、エラーパターンが整理しきれず、ハンドリング方法に悩んだりと、試行錯誤が続くフェーズでもありました。

リッチにしなければ早く作れる。リッチにしなければ。（まさ）

ElevenLabsもAWSも初めてで大変だったけど勉強になった。（いおりん）

8. API繋ぎ込み

担当：にっしー（FE）、まさ（BE）、いおりん（BE）

ElevenLabsの翻訳APIや自前APIの繋ぎ込みをおこないました。

APIの繋ぎ込み作業をする頃には他の作業遅延も重なっていたので、とにかく時短を意識して機能の実現を目指しました。時間がなかったこともあり、初期構想とは違った方針になってしまいました。

設計を他のエンジニアに共有・理解してもらうのってむずかしい。それぞれ宗教もあるし……（にっしー）

9. テストケースの作成

担当：やましょう（設計）

実装された機能が仕様どおりに動作しているかを確認するため、「何をテストするべきか」の整理から始め、テストケースを作成しました。

すべてのケースに対して、条件・期待値・データの流れを細かく記載し、再現性の確保を意識しました。また、仕様にはない想定外の動作や、境界条件でのエラーがないか、洗い出しきることを目標にしました。

テストケース作成中に設計の変更が入ったり、仕様について他のメンバーとの認識の齟齬があったりと、トラブル続きでした。そのたびに何度もアップデートして、矛盾がないかの確認が発生したので、想定よりかなり時間がかかりました。

設計の変更がない状態で着手できたらもっとスムーズだったと思う。案件では設計から自分で考えるため途中の設計変更は基本的に起こり得ない（起こっても対応しやすい）ので、良い経験になった。（やましょう）

10. テスト

担当：もんろー（DE）、いおりん（BE）

テストケースをもとに画面の挙動の確認と、データベースに正しくデータが登録されているかの確認を行いました。

画面側ではテスト項目にない部分についても丁寧に、要件とずれがないかチェックしながらテストしました。データベース側では、とにかく”ミスなく・漏れなく・確実に”を意識して、画面テストと連携しながら確認を進めました。

一番印象に残っていることは、途中でテストケースの更新があり、一周目のテストがすべて無駄になったことです。確認項目を一つずつ整理したり、想定していた仕様とテストケースの食い違いがあったりと、時間がかかりました。

テストが楽しかった。エンジニアにどうエラーを伝えたら直しやすいか考えた。（もんろー）

時間がかかるのと品質を保証するものだからストレスがかかる仕事。だからこそ効率的に丁寧かつ素早く行えるようになりたい。（いおりん）

完成したアプリの紹介

こうして試行錯誤を重ねながら、ついにアプリが完成しました。

動画を投げるだけで言語を自動認識し、英語に翻訳してくれるWebアプリが形になりました。

ここからは、実際に完成したアプリの様子を紹介します。

ログイン → 新規登録画面

まずはログイン画面から始まります。アカウントを持っていない場合でも、新規登録をすることですぐに使い始めることができます。

動画変換画面

日本語のmp4動画をアップロードし、変換したい言語を選択。変換先言語もたくさん用意しています。今回は英語を選んで「変換する」を押すと、数秒で処理が始まります。

変換結果画面

たったこれだけの工程で動画の言語が変換されます。

変換結果は下の一覧に反映され、カードをクリックすると変換前後の動画を並べて確認できます。

字幕の表示やダウンロードもスムーズに行えるようになっています。

削除・エラー時の挙動

不要なデータを削除する際には確認モーダルが表示され、誤操作を防止。

また、書き出し中にエラーが発生した場合は、トースト通知でユーザーにわかりやすくお知らせします。

こうして、アップロードから変換・確認・管理まで、一連の操作を直感的に行えるWebアプリが完成しました！

使いやすさにこだわったツールが、動画翻訳をもっと簡単に、身近にしてくれるはずです。

苦労や学び&メンバーの声

みんなから、今回のプロジェクトを通しての感想を聞いてみました。

PMOなどで案件に携わることはあったがPMはなかったため、非常に責任を感じた。（タカラ）

普段の案件では携わらない要件定義やデザインに触れることで考え方の幅を広げられた。一方で、考え方も能力も異なる人間を統率することの難しさも感じた。反省を案件で活かせるようにアウトプットしていきたい。（やましょう）

守備範囲も動き方もまったく違う6人だったので、案件の課題よりもコミュニケーションと交通整理の課題のほうが多かった気がする。新卒同士だからギリギリ軌道修正できた気もする。みんなよく頑張った。（まさ）

新卒みんなとものづくりをする経験が新鮮だった。それぞれの守備範囲が違うこともありコミュニケーション面にとても苦戦した。意図せずエンジニア語（エンジニアにしか伝わらない言葉）を使ってしまう悪癖を治したい。（にっしー）

全体的に本当にためになったし成長できた期間だった。上下関係なく話せる新卒でできたからこそ楽しかったし、怖がらずにぶつかって失敗できたし、いろいろ言い合えたと思う。（もんろー）

初めて AWS を扱ったこともあり学ぶことが多く、とても良い経験になった。ゼロから形にしていく開発は新鮮で、進めていく中で楽しさも感じながら取り組むことができた。（いおりん）

開発は、順調なことばかりではありませんでした。意見のすれ違いや認識のズレが起きてしまったり、スケジュール管理が難しく思うように進まない時期もありました。

特に中盤は、チーム内のコミュニケーションが思うようにいかず、誰がいつどこまで進めるのか、何を優先すべきかが曖昧になる場面もありました。それでも、「どうしたらより良いものを作ることができるか」という共通の思いの元たくさん話し合い、軌道修正をしていきました。

最終的にはそれぞれが自分の役割をしっかり見つけ、チームとしてひとつの方向に進めるようになったと思います。

苦労も多かったですが完成したときの達成感は大きかったです！

さいごに

このプロジェクトを通して感じたのは、チームで一つのものをつくり上げることの難しさと、コミュニケーションの大切だと思います。

思うように進まないときもありましたが、それぞれが自分の役割に責任を持って、支え合いながら最後までやり切ることができました。

今回得た知識や経験、チームでの連携の大切さを、今後の現場でもしっかり活かして、より良い制作につなげていきます！