はじめに
2025年7月～10月の期間で、23新卒社員の3名でユーザー企業様とチームを組み、3か月の内製開発ハッカソン【ANGEL Dojo】に参加してきました！
沢山のことを学んだので、今回は弊社参加メンバーで、やったことや学んだことを振り返っていきたいと思います。
ANGEL Dojo とは
ANGEL Dojoとは、AWSが主催する長期ハッカソンイベントです。
aws.amazon.com
3か月間という期間での開発コンテストで、参加者は期間中の木曜・金曜の業務時間を丸々使ってテーマに沿ったアプリケーションを開発し、発表を通じてそのビジネス価値や技術を競います。
これまでも弊社社員が挑戦してきました。
ANGEL Dojo カテゴリーの記事一覧 - サーバーワークスエンジニアブログ
毎年要件は少しずつ変わるそうで、2025年は以下のような形でした。
- 原則ユーザー企業（事業会社）とAWSパートナー企業（事業会社相手にAWSについて技術支援を行っている企業、弊社も該当）でチームを組む
- ユーザー企業の課題を解決するようなソリューションを開発する
これまではパートナー企業同士でのチーム分けもあり、BtoCの大衆向けアプリケーションがよく作られていたのに対し、2025年は【ユーザー企業の内製化の重要性】を強く押し出していたのが印象的でした。
（チームによっては「ユーザー企業側メンバーにエンジニアが全くいない」ということもありました！）
チームについて
サーバーワークスとしては、若手エンジニア3名ということで、23卒のインフラエンジニア同期3人（足達、垣見、圡井）で出場しました。 ランダム選出によってチームを組んだユーザー企業様は積水化学工業株式会社様2名と株式会社NTTデータセキスイシステムズ様2名の計4名（うち未経験者3名、アプリケーション開発経験者1名）が参加してくださいました。
私たちはスクラム開発を実践しました。
内製開発ということもあり、プロダクトオーナーとスクラムマスターを両方ともユーザー企業（積水化学工業株式会社様）メンバーから出すという挑戦も実施しました。
皆様とてもやる気にあふれ、それぞれの得意領域を補い合うとても良いチームだったかと思います。
作ったもの
私たちが開発したのは「ヨコノバ」というアプリケーションです。
ヨコノバは社員が匿名で「課題」と「事例」の投稿やコメントのやり取りができるプラットフォームで、投稿した課題には過去の類似事例が推薦されるのが特徴です。
さらに、匿名ではあるものの、申請で双方が承認すれば、投稿者同士の連絡先が開示されるような仕組みになっています。
それでは、3人の弊社参加メンバーの所感をそれぞれまとめていきます。
参加した目的
Q.皆さんがANGEL Dojoに参加した目的は何ですか？
足達
アプリケーション開発の実践経験
これまで、インフラ周りの業務がほとんどだったため、アプリケーション分野についての知識に自信がありませんでした。
また、普段の業務でインフラを構築していても、その上で動くアプリケーションのイメージがほとんどついておらず、お客様の要望・期待に応えられているのかという不安もありました。
ANGEL Dojoにて、アプリケーションの開発経験を積むことで、インフラへの理解もより一層高まるのではないかと考えて参加しました。
モダンアーキテクチャの構築経験
普段の業務では、EC2やRDSなど比較的昔からあるサービスの構築を取り扱うことが多く、LambdaなどのサーバレスコンピューティングサービスやAPI Gatewayなどを実際に触ったことがほとんどありませんでした。
そのため、この機会にモダンアーキテクチャと真剣に向き合い、知識の幅を広げたいと考えていました。
垣見
アプリケーション・フロントエンド開発経験
アプリケーション開発に関しては足達さんとほぼ同じなので割愛します。
せっかく普段AWSを触っているので、アプリケーション開発を学んで作れるものを増やせれば、より人生が楽しくなりそうという期待もありました。
さらに、自分はUIUXデザインにも興味があったものの、経験が皆無でした。一つのサービスデザインを行う上でその基礎も学べると考えました。
ユーザー企業の課題の理解
普段、パートナー企業としてユーザー企業様向けに技術支援やコンサルティングを行なっています。 しかし、新卒でサーバーワークスに入社したということもあり、まだまだ視野が狭い部分があると感じていました。ANGELDojo参加を通じ、他企業様の業務や課題感により寄り添えるようになることを期待しました。
圡井
AWSに対するかかわり方の異なる人と交流したかった
私は所属がAWSパートナー企業であるため、普段はAWSパートナーとしての視点でAWSに関わることが多い状況でした。
ANGEL Dojoに参加することで、さまざまな立場や視点を持つ方々と交流し、AWSに対する多様なかかわり方を学びたいと考えていました。
企画からスタートするサービスの開発経験
これまでの業務では、すでに決まっている要件に合わせてインフラ構築を行うことが多く、企画段階から携わる機会がほとんどありませんでした。
ANGEL Dojoでは、企画からスタートするサービス開発を経験することで、ユーザー視点でサービスを考え、それを形にしていくプロセスを学びたいと考えていました。
内製化支援への挑戦
今年のANGEL Dojoのテーマは「内製化支援」ということで、この企画で作成したものを「使い続けていく」ことに対して、自身のこれまでの経験が通用するかどうかを試したいと考えていました。
お客様が自らサービスを運用・改善していくための支援に、どのように貢献できるかを学びたいと思っていました。
各人の役割
Q.皆様はANGEL Dojo期間中、それぞれどんな役割を担いましたか？
足達：各種機能開発と運用整備
主に、フロントエンド（React）とバックエンド（Lambda/RDS）を用いた、比較的細かめな機能開発を行っていました。
イメージがつきやすい部分だと、具体的に以下のような機能を実装しました。
- コメント投稿/閲覧機能
- マイページ表示機能
- 検索機能
- 通知機能 etc...
インフラ屋さん的なこととしては、開発ツールを統一する目的で構築したEC2やアプリケーション用に構築したRDSの自動停止設定なども実施しました。
このあたりの技術的な話は、別途エンジニアブログとして執筆しておりますので、こちらもぜひご覧ください。
垣見：コア機能とデザイン・セキュリティとコスト
大きいところでは、Amazon Bedrock Knowledge Basesを使ったコア機能開発と、フロントエンドのデザイン統一を担当させていただきました。
コア機能開発
- ユーザー企業の方と分担しつつ、技術選定から設計・構築を行いました。
- 技術選定ではユーザー企業様のデータ保管要件や今後の運用面・コスト面を意識しました。 また、今回は対象データの条件により処理フローを変える必要があったので、AWS Step Functionsを用いた分岐処理を実装したのが印象的でした。
フロントエンド
- 学びたかったということもあり積極的に挑戦させていただきました。
- デジタルに疎いペルソナも意識した見た目のデザインの他、ポジティブなアクション（いいねなど）とネガティブなアクションの見た目を分ける、ユーザーが待たされてアクションしてよいかわからない時間を減らす、などを意識しました。
- デザインについて最初に要件を決めていなかった・知識が少なかったため、メンバーによってbootstrapを使ったり、cssファイルを分けたり分けなかったり、などが発生してしまったのは反省点です。(今はAmazon Q Developerなども使えるので、最初にruleファイルとして決めておけばよかったです）
セキュリティ・コストのガードレール
- 今回はユーザー企業様が払い出してくださった環境で開発を行うということもあり、最初にAWS CloudTrailやAWS Security Hub CSPM、Amazon Budgetsといった基礎的なセキュリティ・コストのガードレールを設定しました。
- 開発を始める前にそれら設計・構築と通知設定等も行い、ユーザー企業様向けの勉強会を実施するなどしました。
圡井：各種開発手法レクチャー・レビューなど
チームの中では開発経験のあるメンバーとして、開発環境の準備やAWS上で開発によく利用するサービス、実際の開発手法についてレクチャーを行いました。
具体的には、以下のような活動を行いました。
開発前
- 開発環境整備（Coderサーバのセットアップ、テンプレートリポジトリの作成）
- Gitの使い方等の準備・レクチャー
開発初期
- AWS上での開発レクチャー（API用リソースの構築レクチャー、コーディング）
開発中期
- コードレビュー（Pull Requestのレビュー、コンフリクト解消、バグ修正）
開発後期
- デプロイ（本番環境へのデプロイ）
- バグ修正
このように、開発の各フェーズにおいてチームメンバーをサポートしながら、プロジェクト全体の推進に貢献しました。
できたこと・成長を感じたこと
Q.それぞれANGEL Dojoを通して何を学びましたか？
足達
動くアプリケーションが出来上がるまでの流れの理解
ANGEL Dojoに参加する前までは、かろうじて「Web3層構造」などの知識がある程度で、それぞれの層でどのような実装がされているのかなどは、あまり理解できていませんでした。
今回開発した構成は、あくまでアプリケーションの動かし方の一例ではありますが、実際にコードを書いて、それぞれの層を繋ぎ込む経験を経て、アプリケーションの裏側で行われている処理への理解度が格段に上がったと実感しています。
機能単位でタスクを割り振ることによる疎結合な開発
今回、チームでのタスク割り振りは、「ユーザーが○○をできるようになること」のように機能単位で区切りました。
一つの機能に関わるフロントエンドからバックエンドまでを一貫して担当することで、「フロントエンドをAが担当、LambdaをBが担当、DBをCが担当」のように割り振る場合と比べて、意思疎通のためのコミュニケーションが省けたと感じています。
また、タスクの切れ目が明確で、手が空いて追加タスクが欲しいときなどに各自で容易に拾い上げることができていたので、上手く疎結合な開発を回せていたと実感しています。
Amazon Q Developerを用いたスピーディな開発
エディタとして利用していたVSCodeの拡張機能で、Amazon Q Developerを入れて活用することでスピーディな開発ができました。
必要に応じて、リポジトリ内の状況を読み込みつつコードを作成してくれるため、状況に適したコード作成が容易にできました。（例えば、共通で利用しているコンポーネントがあった際などに、それを加味して作成するような指示ができました。）
ここまでAmazon Q Developerをフル活用したことがなかったので、良い経験になりました。
エラー発生時のトラブルシューティング
ブラウザで開発者ツールを開いて原因を特定したり、Lambda関数実行時にログを出力させるようにしてCloudWatch Logsで確認したりと、開発時に発生したエラーを解消するための術を学ぶことができました。
チーム内の開発経験者のサポートも大きかったですが、後半はエラーの解消も含めてほぼ自走することができたため、大きな成長だったと感じています。
垣見
アプリケーション・フロントエンド開発の理解
実際に流れを体験することで、概要を掴み、自主的に勉強を進める上でのフレームワークが頭の中にできました。
実際、全く別のハッカソンに参加したときには、ReactとTailwind CSSを使ったフロントエンド画面を一人で実装することができました。（↓こちらのチーム1「わいわい」です。Yukki賞をいただきました！）
実際の学びとして、基本のサーバレスアプリケーションをAmazon Q Developerの力を借りて開発する基礎の流れについて、以下のブログにハンズオンスタイルでまとめています。
開発中に気付いたQ DeveloperのTipsなども貼っているので、ご興味あればぜひご覧ください。
blog.serverworks.co.jp blog.serverworks.co.jp
Knowledge Basesを使ったRAGの構築
今回、背後にAmazon OpenSearch Serverlessを置き、RetrieveAPIを使って類似した文章を取得する仕組みを作りました。
Amazon Bedrock Knowledge Bases経由でベクトル化を行う仕組みについて理解が深まりました。
また、「投稿者が一致しないと評価したら再度同じものを返さない」という仕組みや「古い課題投稿に対し新しい事例のレコメンドが来る」という条件フローを考えるのも面白かったです。
ユーザー企業様の立場での内製開発
単なる「役に立ちそうなもの」の開発ではなく、「誰が何に困っていて」「どのような価値を生む」ために「どの立場の人間が」「何を作るのか」という、内製開発だからこそ、どの課題に注力すべきなのか考えるフローを体験できたのはとても良かったです。
同じ会社として利益になることでも、それは一定金額を払って外注すべきなのか、それとも一定の社内コストを抑えて内製開発すべきなのか、また運用や社内展開はどうするのか、という視点で物事を見ることが出来ました。
普段はベンダー側として立ち回ることが多いので、とても勉強になりました。今後のお客様へのご支援でも生かせる重要な視点かと思います。
圡井
ユーザー視点で作りたいものを考えること
ANGEL Dojoでは、Amazonが提唱する「Working Backwards」という手法を用いて企画を進めました。
この手法では、「最初にユーザーが求めるものを考え、そこから逆算して必要な機能やサービスを考えていく」というアプローチをとります。
この手法を用いることで、ユーザーが本当に求めているものを明確にし、それに基づいて開発を進めることができました。
日々の業務では、要件がすでに決まっていることが多く、ユーザー視点で考えることが少なかったため、ANGEL Dojoを通してこの手法を学び、実践できたことは大きな成長であったと感じています。
アジャイルスクラム開発の経験
ANGEL Dojoでは、アジャイルスクラム開発手法を用いて開発を進めました。
日々の業務では、どこまで作るかの要件が決まっていることが多く、アジャイルスクラム開発手法を用いる機会が少なかったです。
先述した「Working Backwards」で企画した内容を「User Story」に落とし込むことで、ユーザーが価値を感じる機能を漸進的に提供していくことができました。
この経験を通して、柔軟な開発手法の重要性を実感することができました。
AWS開発ノウハウを言語化してチームに共有すること
これまでは、課の先輩メンバーが蓄積してきたテンプレートなどを活用して開発を行ってきましたが、ANGEL Dojoでは、AWS上での開発経験が浅いメンバーも多く、ゼロからの状態で開発を行う必要がありました。
そのため、AWS上での開発ノウハウを言語化したり、時には実際に手を動かしながらレクチャーを行うことで、チーム全体の認識を合わせて開発スピードを上げることができました。
普段は暗黙知として自分の中にあった知識を、明文化して共有する力を養うことができたと感じています。
生成AIとの共創
ANGEL Dojoは3か月という短い期間での開発であったため、開発スピードを上げるために生成AIを活用しました。
具体的には、コードの自動生成やドキュメントの作成、テストケースの生成などに活用しました。
生成AIを活用することで、開発スピードを大幅に向上させることができましたが、うまくコンテキストを伝えられないと、意図しないコードが生成されることもありました。
事前にどのような準備をすることで生成AIを効果的に活用できるか、このAIとともに協創していくためのスキルを身につけることができました。
実際に使ってみて、「こうしたらよりよいのではないか」という振り返りブログを執筆したので、ぜひご覧ください！ blog.serverworks.co.jp
さいごに
それぞれたくさんのことを学べた、とても良い機会でした。参加にあたってフォローいただいた皆様、またチームの皆様、本当にありがとうございました。
ぜひ、これを読んだ皆様が、「私もANGEL Dojoに参加してみたい！」と興味を持っていただけたら幸いです。
