はじめに
こんにちは。
FusicAdventCalendar2025 9日目です！
昨日は@TsuMakotoさんの 推薦システムをChatGPTで でした。
株式会社Fusicでエンジニアをしている、岡山です。
今回の記事では、岡山とチームメンバーである同社社員竹口くん(@takeguchi_dev)2名で、AI駆動開発による社員の日程調整に関する課題を解決するアプリを開発した話を紹介します。
【アプリ画面】
3行まとめ
- 開発で重要なのはパッション(欲望)
- 仕様駆動開発とドキュメント駆動を両取りして、AIと人にとってフレンドリーな設計
- 速度と精度のトレードオフの解消にはマルチモデルによるチェックが大事
背景
当社Fusicでは定期的に「開発合宿」を行っており、コワーキングスペース等で終日こもって各々作りたいものを作って発表するというイベントを定期開催しています。
※前回のイベントレポートはこちら
今回の開発合宿は、FusicのHRBPチームが抱えている課題を要件定義から設計開発までやるという、これまでの開発合宿とは異なる「テーマ型合宿」でした。
期間も1日ではなく、1日ガッツリ開発した、2週間後に発表会があるという新しいスタイルです。
今回、僕はせっかくなら開発合宿もチーム開発したいという気持ちから竹口くんを誘って、HRBPから出された課題の1つ「Outlookでの複数人日程調整ツール」の開発を行うことにしました。
Fusicでは志望者が最終面接で1日かけて社長、副社長を含む10名弱のメンバーと1対1の面接を行います。
志望者にとっても中々大変な面接ですが、面接を行うメンバーの日程調整がとても大変。
そこで、参加メンバー、確保する時間、期間を指定したら調整しやすい日程候補をピックアップしてほしい、というのが要件でした。
この日程調整ツールを含めて3つの課題に対して各々開発を行い、最終発表にてHRBPチームに採用されたらなんと「ウナギ」が賞品としていただけるとのこと。
これは頑張るしかない。
僕らはせっかくなら良いものを作ろう(ウナギ食べたい)という熱い想いをもって、本気で開発に取り組むことにしました。
開発フェイズ
今回の開発における課題は以下の3点でした。
- 短期間である程度の成果物を完成させるためにはどうしたらいいか
- 岡山・竹口2名とも通常業務がある中、開発工程をどうやって進めるか
- それぞれ技術スタックが異なる中(竹口くんはPHP,岡山はRuby)、技術選定をどうするか
これら課題に対して僕らが立てた作戦はこんな感じ。
- 何を作るかをチームで徹底的に決めて、要件資料を作成、リポジトリでdoc/ディレクトリにまとめる
- doc資料を元に、AIが必要な仕様書はAI/ディレクトリに抜粋する
- このdoc資料を元に随時メンバーは仕様を理解し、プロンプトを投げ、AIはAI用の仕様書を参照・更新しながら実装を行う
この作戦のキモは、メンバー用のドキュメントと、AI用の仕様書を両方作成することです。
いわば「ドキュメント駆動開発(DocDD)」と「仕様駆動開発(SDD)」を並行することで、非同期的に開発をする際のメンバーの認識相違をドキュメントで補正、AIには仕様書で制約を付与することで、開発の大きなズレを防止しようというものでした。
実際の構成は以下です。
プロジェクトルート/
├── AI/ # AI参照用ドキュメント（仕様書）
│ │ # 役割: 「なぜそうなっているか」「どういう仕様か」を定義
│ │ # 目的: AIがコード生成・レビュー時に参照
│ ├── README.md # AIディレクトリの説明・ガイドライン
│ ├── REQUIREMENTS.md # プロジェクト全体の要件定義書（約2,500行）
│ ├── API_SPECIFICATION.md # バックエンドAPI仕様書
│ ├── OUTLOOK_API_GUIDE.md # Microsoft Graph API詳細ガイド
│ └── TIMEZONE_GUIDE.md # タイムゾーン処理の方針・実装例
│
├── docs/ # 開発者向けドキュメント（手順書）
│ │ # 役割: 「どうやってやるか」を説明
│ │ # 目的: 開発者が環境構築・実装・テスト・デプロイを円滑に進める
│ ├── README.md # 開発者向けドキュメントの目次・ガイドライン
│ │
│ ├── getting-started/ # 初期セットアップ
│ │ │ # 役割: プロジェクトの初期セットアップ手順
│ │ ├── README.md
│ │ ├── QUICK_START.md # クイックスタートガイド
│ │ └── SETUP.md # 詳細セットアップガイド
│ │
│ ├── configuration/ # 設定関連
│ │ │ # 役割: 環境変数、モックAPI、営業時間などの設定
│ │ ├── README.md
│ │ ├── ENV_SETUP.md # 環境変数設定ガイド
│ │ ├── MOCK_API_SETUP.md # モックAPI仕様書
│ │ ├── BUSINESS_HOURS_SETUP.md # 営業時間設定ガイド
│ │ └── LEFTHOOK_SETUP.md # Gitフック設定ガイド
│ │
│ └── features/ # 機能別ドキュメント
│ │ # 役割: 各機能の設計・実装・テストに関するドキュメント
│ ├── room-selection/ # 会議室選択機能
│ │ ├── README.md # 機能概要とドキュメント一覧
│ │ ├── TECHNICAL_SPEC.md # 技術仕様書
│ │ ├── TESTING.md # テスト手順
│ │ └── USER_GUIDE.md # ユーザーガイド
│ │
│ ├── date-range-selection/ # 日付範囲選択機能
│ │ ├── README.md # 機能仕様
│ │ └── E2E_TEST_SCENARIOS.md # E2Eテストシナリオ
│ │
│ ├── interview-scheduler/ # 面接予約機能
│ │ ├── README.md # 機能概要と実装状況
│ │ ├── DESIGN.md # 詳細設計書（665行）
│ │ └── IMPLEMENTATION_NOTES.md # 実装ノート
│ │
│ ├── quick-schedule/ # スケジュール早見機能
│ │ └── README.md # 機能概要・日単位/週単位カレンダー表示
│ │
│ ├── room-status/ # 会議室利用状況表示機能
│ │ └── README.md # 機能概要・リアルタイム状況表示
│ │
│ └── pwa/ # PWA機能
│ └── README.md # PWA機能の詳細ドキュメント
│
└── （その他のプロジェクトファイル）
ここまでの説明で端折ってしまいましたが、実はHRBPから要望されていた「最終面接用の日程調整ツール」だけではなく、「通常会議時間調整機能」、「選択したユーザーのスケジュール早見機能」「会議室利用状況確認機能」といった欲しい機能全部盛りのアプリ設計にしています笑。
それもあり、如何に認識ズレを防ぎつつAIで爆速で作れるかが、この開発のキーポイントでした。
次に、技術スタックとしてドキュメントが豊富・AWS Documentation MCP Serverを活用できるReactとAWS Amplifyを選定。
Amplifyについては社内ツールとして安価に今後も活用できることを訴求できること、Amplify Gen2を使いこなしたいというチーム意思もありました。
あと、メンバーどっちもガッツリ使ったこと無い技術のほうが、同じ知識レベルで開発が進められるので良いのではという魂胆もあったりしました笑。
そんな感じで、技術スタックも決めたので、以下のような構成で開発をすることに決定。
※開発当時の設計なので、現在はさらにアップデートしています。
あとは開発するだけですが、前述した「岡山・竹口2名とも通常業務がある中、開発工程をどうやって進めるか」という課題に対して、以下のルールで対応をしました。
- プルリク・レビュー依頼して30分経ったらマージしてOK
- Copilot ReviewとCodex Reviewを用いてセルフ修正する
- セキュリティ担保だけはしっかりやって、あとは作り変える前提で結果にコミットする
今回の開発合宿での一番の懸念は、発表までの約2週間における開発に使える時間がそれぞれ異なることによる、開発遅延でした。
そこで、人の時間にPRを合わせるのではなく、PRに人が合わせる「プルリク見たければ、あなたが合わせてください」スタイルを取ることにしました(強引)。
一方で、このスタイルだとバグを見落とすリスクもあるので、Copilot ReviewとCodex Reviewをレビュアー指定し、セルフチェックでの対応で解決に努めました。
さらに、メインで利用していたClaudeCode(Sonnet4.5)のサブエージェントを用いた客観的レビューとCodex、Composerなど複数のモデルでのチェックを行うことで、致命的ミスを防止しました。
大前提として、セキュリティだけはこのやり方だと非常に怖かったので、開発合宿の最初の1日は2人でしっかり開発・チェック作業を行うことで担保をしました。
成果
開発合宿から発表まで2週間あったものの、夜のスキマ時間・土日の空き時間にslackでワイガヤしながらなんとか形にすることができました。
実質かけた工数としては最後の土日全力でやったくらいなので、多分5人日くらいな気がします
実装した画面としてはこんな感じです。
※社内情報が入っている部分があるため黒塗りにしています。
【TOP画面】
【会議時間調整機能】
参加者、時間、期間、部屋を選択すると、候補日を算出、選択した候補日の表示、予約が可能。
ブックマーク機能でよく招待する人、場所を登録できるようにしています。
【最終面接調整機能】
関係者、日程、面接時間、会議室など必要項目を設定し、ブッキングを考慮したマッチング度順で提案。
【スケジュール早見機能】
対象者、会議室を選択すると日単位、週単位でのタイムラインを表示。
【会議室利用状況】
現在時間の会議室利用状況と、その次の予約時間の表示、予約可能な場合は予約が可能。
この短期間の割には、実用可能なアプリケーションが開発できたのではないかなと思っています。
肝心な最終発表ですが、1位は取ることができませんでした...
ですが！！！！
なんと、1位の方(部門長)が賞品を譲ってくださり、ウナギを食べることができました！！
さらに、社内アプリとして正式に採用され、全社員が使えるツールとして先日ロンチを行いました。
開発を通した学び
今回ドキュメント駆動と仕様駆動の両取りで開発を行いましたが、しっかり人のためのドキュメントを作ったことでメンバーの開発意図が共通化され、手戻りを少なくすることができたと思います。
AIの仕様書だけだと、何をどういう意図でどのように実装したいかという包括的な情報が足りないので、ここを補填、かつAIにはドキュメントからAI用の要件定義、仕様書を読み込ませることで、実装をある程度コントロールできました。
一方、当初社内共有用でConfluenceにもドキュメントを転記する形で進めていたのですが、機能実装に伴うリポジトリ上のドキュメント更新に追随させることができませんでした。
実際、GitHubのリポジトリ上で完結させたほうが開発への反映や引継書としても活用できるので結果オーライだったと考えています。
ということで、ウナギという賞品に駆動された欲望でAI駆動開発をした結果、個人的にはとても良い経験をさせていただきました。
今回要望に対して開発を進めてきましたが、
「もっとこんな機能をつけたら皆が喜ぶ！」という情熱と「ウナギ食べたい！！！これだけ機能つけたらウナギ食べられるかもしれない！！！」という欲望があったからこそ短期間で良いモノづくりができたという実感があるので、モノづくりにはパッションが大事だと改めて感じる良い機会でした。
2025年10月時点の開発ではClaudeCode(Sonnet4.5)とCursorのComposerを活用しましたが、12月現在ではOpus4.5やKiroといった仕様駆動がしやすい環境になっており、今開発するなら別の手法を取ったかもしれませんが、少なくともチームメンバーの共通理解になるドキュメントを作ることはAIの進歩と独立しているので、今後も活用していけるノウハウだと思っています。
最後に、この短期間で「この機能追加したい」「デザイン変えよう」といった自分の無茶振りに付き合ってくれた竹口くんにこの場を借りて感謝を伝えたいと思います。