社内アプリコンテスト 運営記 第4話「運営アプリの実装!!トークンが足りない!!!」

システム開発第二事業部の冨永です。

主にiOS/iPadアプリの開発を担当しております。

前回は、ペルソナやジャーニーマップを通じて、ユーザー中心の設計がいかに大切かという話をしました。

「では、いざ実装だぁ〜〜!!(一番楽しい)」

そう意気込んでいたのですが、、、、、

その矢先に、時間という敵が襲い掛かることになりました。

目次

LT会告知まであと1週間!

スコープが決まり、デザインも進み、いよいよ実装へ進もうという段階の出来事でした。

「あ、そういえば2月上旬にLT会がありますね。」

運営メンバーの一人がぼそっとつぶやいたその瞬間——

会議室の空気が一変しました。

「え、LT会?」

「2月上旬……今日何月だ?」

時計を見ると、すでに1月中旬。

LT会の告知は、2月上旬。つまり、あと2週間足らず。

「あ、これ、時間がない。まずい。」

アプリの実装が完全に追い付いていません。デザインも詰めている途中です。API側も叩き台という段階。

それなのに、LT会では「こんな運営アプリを作ってます。」という告知をしなければならないのです。

チーム分割で並行開発へ

その時点で、運営メンバーの間で決断がなされました。

「サーバチームとアプリチームに分けて、並行開発しよう。」

サーバ側(API開発・フロント開発):2名 アプリ側(iOS開発):2名

役割分担をして、並行して作業を進めることにしたのです。

「API側が先に叩き台を作ってくれれば、アプリ側はそれを使って実装できる」

「両側が並行して進められば、時間的ロスが減る」

API側は叩き台完成、アプリ側は……

1月末頃、APIチーム側からいい知らせがありました。

「API側の叩き台、完成しました!!!」

サーバチームの努力により、アプリ側が使用できるAPIの仕様が決まり、実装も完了していたのです。

APIの叩き台が完成。。。!

「よし、これでアプリ側も実装を進められるぞ」

そう思ったのですが、アプリ側の状況は、その時点では日に日に悪化していました。

業務が忙しい時期と重なってしまったのです。

「いや、本当に業務が……」

アプリチームの2名は、日中の業務をこなしながら、夜間や休日を使って開発を進めなければならない状況が続いていました。

「このままだと、LT会に間に合わない……」

そんな不安が、運営メンバーの間で広がり始めました。

KMPとSwiftUIの選択

絶望的なスケジュールを前にして、僕たちは技術選定に関して、ある決断を下しました。

「Kotlin Multiplatform Mobile(KMP)を採用しよう。」

これまでネイティブアプリでの開発が主だったのですが、

「今後のスマホアプリ開発において、ビジネスロジックを共有化できるKMPの採用が増えると予想される。この機会に知見を溜めておきたい」

そうした考えがありました。

KMP

同時に、iOSアプリのUI層にはSwiftUIを採用することにしたのです。

「冨永がSwiftUIの知見を持っているし、開発速度を重視するなら、SwiftUIとの親和性が高い。」

そうした理由からです。

あとは、最近Apple Vision Proを購入したので、visionOS向けにも作ってみたかったというのもありました。

KMPのキャッチアップ、アーキテクチャ選定、実装方針が決定し、

「よし、これならスピード感を持って開発できるぞ」

そう思っていた矢先に。。。

祖父の訃報が舞い込む

2月上旬のこと。

突然の祖父の訃報が舞い込みました。

葬儀は大阪で行われることが決まりました。つまり、急遽東京から大阪へ行く必要があります。

「あ、これ、開発できないな。」

LT会の告知まであと数日。実装はまだまだ終わっていません。

「どうしよう……」

そう思った矢先のこと。

常々社内アプリコンテストへの参加を打診していた社内のバックエンド若手エースエンジニアから嬉しい申し出が。

「運営を少し手伝いたいのですが……」

その時点で、彼も業務が忙しい最中でしたが、申し出てくれたのです。

ぜひぜひぜひぜひお願いします!!!!

運営チームメンバーに了承をいただいた後、即座にお願いして、チームに参入してもらうことになりました。

このタイミングでのメンバー参入が、後々、葬儀中の開発を大きく救うことになるとは、この時点では想像もしていませんでした。

寝ずの番でマルチエージェント開発へ

葬儀は、親族として参加する必要があり、丸々1日は開発に費やすことが難しい状況でした。

ですが、その前後の時間を使って、開発を続けることはできます。

「どうやって効率的に開発を進めるか」

そう考えた時に思い当たったのが、Claude Codeのマルチエージェント機能でした。

現在、Claude Codeでは複数のエージェントを並列で稼働させ、同時に異なるタスクを進めることができます。

「このマルチエージェント機能を活用すれば、複数の実装を並行して進められるかもしれない」

※現在は公式からAgent Teamが提供されているのですが、当時は提供されておらず、以下のmulti-agent-shogunというシステムを使いました。

https://github.com/yohey-w/multi-agent-shogun

そう考えた僕は、複数のエージェントを同時に稼働させ、

  • エージェント1:API連携ロジックの実装
  • エージェント2:UI実装
  • エージェント3:テスト対応

といった形で、並列に開発を進めることにしたのです。

並列実装!

そして、何より心強かったのが、葬儀の前に参入してくれたバックエンド若手エースの存在でした。

葬儀中は、僕がある程度開発に集中できない時間帯もあります。

ですが、その間も彼はAPIの実装を進め、修正対応をしてくれていたのです。

「本当に、このタイミングでの参入がなかったら、開発は止まっていただろうな……」

そう痛感しました。

爆速で修正されていくAPI実装!!エースエンジニアともなるとこんなに早いのね.....

トークン地獄へようこそ

さてさて複数エージェントで爆速開発を進めつつも、

複数のエージェントを同時に稼働させるということは、トークンを大量消費するということなのです。

Claudeのトークン消費は、入力と出力の両方でカウントされます。

複数エージェントが同時に走れば、その分トークンが消費されます。

長時間稼働させればさらに消費されます。

「あ、あとちょっとでMaxプラン使い切る」

LT会まで数日という時点で、そんな状況に直面していました。

葬儀の寝ずの番をしている最中にも実装し、とうとうMaxプランを使い切りました。

「今やらねば。。。」という決断のもと、Max × 5プランを追加で契約することになりました。(月3万円。。。!)

API結合テストで予期しない課題が発生

APIの叩き台が完成したことで、いよいよアプリとの結合テストへ進むことになりました。

「では、アプリ側で実装したUIと、API側で実装したエンドポイントを繋いでみるか〜〜〜」

と、思ったのですが、

——ですが、ここで問題が浮き出てきました。

実装時には想定していなかった、細かな仕様の齟齬が複数箇所で見つかったのです。

「あ、ここのレスポンスの形式が、ちょっと違う」

「ここのエラーハンドリング、どうしよう」

などなど、ドキュメントや当初の設計では想定していなかった、細かな修正事項が次々と浮き出てきました。

うわ〜この時点でこれだけの修正依頼を投げても間に合わないかな。。。。と絶望しました。

新規メンバーの爆速修正対応

その修正依頼に対して、バックエンド若手エースが

本当に5分くらいで、次々と修正を上げてくれました。

葬儀の合間。正直なところ、僕の心身は疲弊していたのですが、Slackの通知は鳴り続けていました。

「あ、このエラーハンドリング、こう対応します」

「このレスポンス形式、修正しました」

葬儀という人生の中でも特に重たい時間の中でも、彼は淡々と爆速で修正対応を進めてくれていました。

「本当に、このタイミングでの参入、そしてこの対応スピードがなかったら、リリースは無理だった」

心底そう感じた瞬間でした。

その後、再度結合テストを実施すると、ほぼすべての課題が解決しました!!

あとは外部審査だけだぁぁぁ!間に合えぇぇええ

GithubActionとissue駆動開発

また、時間もリソースも限られている中で、効率的に開発を進めるために、僕たちが採用したのが、

GithubActionを使用したCI/CDパイプラインIssue駆動開発でした。

高速道路をへの移動中や、葬儀の合間など、PCの前にいられない時間帯も存在しました。

そんな時でも、Github Actionsに仕込んでおいたClaudeコードの自動実行により、

開発作業を継続させることができたのです。

Issueを立てておけば、CI/CDパイプラインが自動的にコードを生成し、

テストを実行し、結果をレポートしてくれる。

そうしたワークフローにより、物理的に開発に参加できない時間帯でも、

プロジェクトを前に進めることができました。

「本当にPC入らなくなるかもな。これからはスマホだけで開発ができるのかも。」

と感動を覚えました。

一つ反省することがあるとすれば、通常のMaxプランの5倍のプランを契約したのですが、よく考えればチームプランを契約すればよかったなと。。。

よく考えればチームプランとかあったよな。。。と反省

ギリッギリでのリリース

LT会の告知予定日。

残念ながら、その日には完全な形でのリリースには至りませんでした。

一応デモだけは見せることができました。。!

ですが、その翌日、外部審査要件を満たし、正式に外部テスターとして社内の人が使えるようにリリースいたしました。

LT会の翌日、なんとかテスト版リリース!!

後日談

後になんとサーバーチームがWebアプリも作ってしまってました。(本当に2~3日もかかってないような。。。)

早すぎるて!!

実装フェーズを終えて

バックエンド若手エース達の休日深夜の貢献なくしては、

このアプリは完成していませんでした。

そして、マルチエージェントやCI/CDといった新しい開発の形が、

こうした絶望的なスケジュールでも、プロジェクトを完成へ導く手段となり得るということを学びました。

今後のソフトウェア開発の形が変わるな。。というのを体感しました。

おわりに

ということで、運営側のアプリ開発の実装の話でした。

ペルソナの話、スケジュール地獄の話、葬儀で開発する話、トークン地獄の話、Webアプリは2〜3日で完成する話——いろいろありました。

ですが、まだ開発は続いており、そしてデータもまだまだ足りません。。。。。

参加者たちは、このアプリを使って、何を作ったのか。

どんなアイデアが投稿され、どんなチームが組まれ、どんなプロダクトが生み出されたのか。

その話が、本編です。

乞うご期待です。


テコテックの採用活動について

テコテックでは新卒採用、中途採用共に積極的に募集をしています。 採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。 ご興味を持っていただけましたら是非ご覧ください。 tecotec.co.jp