こんにちは、タイミーでバックエンドのテックリードをしている新谷（ @euglena1215 ）です。 今回は、社内向けに公開したバックエンド開発Handbookと、それをClaude CodeやCursorといったAIエージェント向けスキルとして届けることで、気づいたらHandbookを参照している状態を目指した取り組みについて紹介します。 バックエンド開発Handbookとは何か バックエンド開発Handbookは、タイミーのバックエンド開発における設計・実装・運用のガイドラインをまとめたドキュメント集です。GitHub Pages でホスティングし、開発者が見やすい形で公開しています。 タイミーでは GitHub Enterprise Cloud を利用しているため、GitHub Pages のアクセス制御機能でリポジトリの読み取り権限を持つメンバーのみに公開範囲を制限できます。 バックエンド開発トップページ なぜ書き始めたのか 事業の成長・変化に伴い、バックエンド開発に関わるエンジニアが増えてきました。AIツールの進化も相まって、バックエンド以外を専門とするエンジニアが越境してコードを書く機会も増えています。 こうした変化の中で、これまでチーム内で暗黙的に共有されてきたノウハウや設計思想を形式知として残し、誰でもアクセスできる状態にしておく必要がありました。 たとえば戦略的プログラミングの重要性、概念モデリングの進め方、テーブル設計の注意点など、日々の開発で繰り返し必要になる判断基準を体系化しています。 カバー範囲 Handbookは開発プロセスの全体を一気通貫でカバーしています。 フェーズ トピック はじめに 戦略的プログラミングの心構え、秘匿情報の取り扱い、タイミーを取り巻く法律 設計 概念モデリング、ギャップ分析、テーブル設計、Web API設計、クラス設計、非同期処理設計、バッチ処理設計 実装・レビュー 実装ガイドライン、コードレビュー、自動テスト設計、コードの整頓 運用・保守 ログ設計、監視、障害対応 リリース デプロイ・リリース 設計に重点を置いているのは、バックエンド開発に慣れていない人がAIエージェントを使ったとしても、カバーしにくい領域だからです。実装やレビューのプラクティスはある程度一般化されていますが、「タイミーのバックエンドとしてどう設計するか」はチーム固有の知見が多く、形式知にする価値が高いと考えました。 たとえばタイミーでは、Sidekiq ジョブ実行中にデプロイが行われると、Sidekiq プロセスに SIGTERM が送信されます。その25秒後にたとえ実行途中であってもジョブをキューに戻す、という実装上の制約があります。開発者はこれを考慮してジョブの処理をべき等にしたり、25秒を超えないように処理対象を分割してジョブに切り出すなどの対策を行う必要があります。このような暗黙的かつ独自の制約は特に Handbook として残すべきだろうと考えていました。 Handbookをどう届けるか Handbookを書いて公開するだけでも価値はありますが、ドキュメントは自分から読みに行く必要があり、ひと手間かかります。存在を知っていても、忙しい開発中には思い出せないこともあると思います。 いま、社内の多くのエンジニアがAIエージェントを日常的に使って開発しています。Claude CodeやCursorなどのツールが開発フローに組み込まれているのであれば、 AIエージェント経由でガイドラインを届ける という選択肢があります。 開発者が意識しなくても、AIエージェントがガイドラインを参照しながら設計や実装を支援してくれる。そうすれば、「気づいたらガイドラインに沿った開発をしていた」という状態を作れます。 この考えから、Handbook公開と同時にAIエージェント向けスキルとしても提供することにしました。現在、Claude Code Plugin と Cursor Agent Skills の2つの形式で配布しています。 ここからは、AIエージェント向けスキルの技術的な仕組みと、人間側の学びを促す工夫の2つの観点で説明します。 スキルの技術設計 リポジトリ構成 1つの工夫として、Handbookのマークダウンドキュメントとスキル定義を同じリポジトリに同居させています。 handbook/ ├── backend/ # Handbookドキュメント（マークダウン） │ ├── design/ │ │ ├── web_api_design.md │ │ ├── table_design.md │ │ └── ... │ ├── implementation/ │ └── operation/ ├── .claude-plugin/ # AIエージェント向けスキル定義 │ └── timee-backend-handbook/ │ ├── plugin.json │ └── skills/ │ ├── ref-design-api/ │ ├── wf-code-reading/ │ └── ... └── scripts/ └── build-cursor-skills.sh # Cursor向け変換スクリプト ガイドラインの原文とスキル定義が同じリポジトリにあるため、ドキュメントの更新とスキルの更新を同じPRで行えます。ドキュメントとスキルが乖離するリスクを構造的に減らせます。 Reference SkillsとWorkflow Skills Handbookの内容を、AIエージェントのスラッシュコマンドで呼び出せるSkillsとして提供しています。今回、スキルの役割に応じて Reference Skills と Workflow Skills という2種類の分類を独自に定義しました。これはClaude CodeやCursorの公式な分類ではなく、Handbookスキル群の設計方針として導入した概念です。 Workflow Skill（高レベル） ├── Reference Skill A を呼び出し ├── Reference Skill B を呼び出し └── Reference Skill N を呼び出し（必要に応じて） Reference Skills Reference SkillsはHandbookの各ページと1対1で対応します。 /handbook-ref-design-api # Web API設計 /handbook-ref-design-table # テーブル設計 /handbook-ref-design-class # クラス設計 /handbook-ref-impl-code-review # コードレビュー ... たとえばAPI設計のReference Skillsは以下のように定義されています。 --- name: handbook-ref-design-api description: Web API設計のガイドラインを参照してエンドポイント設計をレビュー・提案 context: fork agent: general-purpose allowed-tools: Bash(gh *) --- ## Web API設計ガイドライン !`gh api /repos/my-org/handbook/contents/backend/design/web_api_design.md -H "Accept: application/vnd.github.raw"` ## タスク 上記のガイドラインに従って、$ARGUMENTS のWeb API設計をレビュー・提案してください。 ポイントは context: fork です。サブエージェントとして独立したセッションで実行されるため、メインセッションのコンテキストウィンドウを消費しません。情報量の多いHandbookの取得をサブエージェントに委譲し、要約のみを返すことで効率的に運用できます。 また、 gh api -H "Accept: application/vnd.github.raw" でマークダウンの原文をそのまま取得できます。Handbookが更新されれば自動的に最新の内容が反映されます。 Workflow Skills Workflow Skillsは、状況に応じて複数のReference Skillsを組み合わせるユースケース特化型のスキルです。 context: current でメインセッション上で実行されます。 現在はWorkflow Skillsを4つ提供しています。 スキル フェーズ 内容 /handbook-wf-code-reading 理解 既存機能を体系的に理解する /handbook-wf-modeling モデリング 概念モデリングを実施する /handbook-wf-plan 計画 開発中: 詳細設計を行いつつ、複数個の実装計画に落とし込む /handbook-wf-implement 実装 開発中: 与えられた入力を元に実装する たとえばモデリングフェーズのWorkflow Skillsを実行すると、以下のような流れで進みます。 イントロダクション : 概念モデリングの重要性とギャップ分析の考え方を説明 ガイドライン取得 : 必要なReference Skills（概念モデリング、ギャップ分析など）を自動で選択・呼び出し 意図の深掘りと目標の合意 : 何をモデリングしたいのか、スコープを確認 すり合わせの質問 : ドメインの境界やビジネスルールについて質問を提示 メインセッションでモデリング実行 : 回答を踏まえて一緒にモデリングを進める 開発者はスラッシュコマンドを1つ実行するだけで、必要なガイドラインの参照からモデリング作業までを一気通貫で進められます。ガイドラインの存在を知らなくても、Workflow Skillsが自動的に適用してくれます。 階層構造のメリット Reference SkillsとWorkflow Skillsの2層構造には、以下のメリットがあります。 再利用性: 同じReference Skills（たとえばギャップ分析）が理解・モデリング・設計の各Workflowから呼ばれる 動的選択: Workflow Skillsがユーザーの入力や状況に応じて、必要なReference Skillsだけを選択的に呼び出す コンテキスト効率: ガイドラインの取得処理はサブエージェントに委譲され、メインセッションには要約のみが返る また、Workflow Skillsは自作も可能です。既存のWorkflow Skillsを参考にしながら、チームの開発フローに合わせたワークフローを追加していけます。こうしたスキルが充実すれば、どのタスクに取り組むときでもHandbookの知見にガイドされる状態が作れます。新しくチームに加わった開発者でも、スキルを通じてすぐにチーム固有の設計方針をキャッチアップできるはずです。 人間の理解を置き去りにしない設計 スキルの技術設計だけでは不十分です。ここが一番気をつけたポイントです。 AWSが提唱しているAI-DLC（AI Driven Development Life Cycle） は、AIの出力を妥当にジャッジできる人間の存在を前提としています。人間側の理解が伴わなければ成り立ちません。 しかし現実には、AIの出力を「なんか良さそうだから」とそのまま使ってしまい、人間側の理解が追いつかないケースも起きがちです。AIの進化によって実装の詳細を人間が把握しなくてよくなる部分はあるでしょう。ですが、背景にある考え方を理解していなければ、AIと適切にコミュニケーションを取ることはできません。 だからこそ、このスキル群では人間に考え方やインサイトをインプットする工夫を随所に入れています。いわば、いつでも質問できるメンターをAIで実現する試みです。 工夫点１：イントロダクションで「なぜ」を伝える 各Workflow Skillsの冒頭にイントロダクションを設けています。ここではいきなり作業に入るのではなく、「なぜこのフェーズが重要なのか」「このフェーズで何を学ぶのか」を説明します。 たとえば理解フェーズのイントロでは、コード理解には概念・構造・実装の3段階があり、概念レベルから順に深めるアプローチが有効であることを説明しています。 ## 推奨アプローチ 概念レベルから順に理解を深めることを推奨します： 1. 概念レベル: まず全体像を掴む（どんな世界なのか） 2. 構造レベル: データとクラスの設計を理解（どう表現されているか） 3. 実装レベル: 具体的なロジックを理解（どう動くのか） 工夫点２：ガイドラインURLの提示 全てのスキルで、参照したガイドラインのホスティングしているURLを、ユーザーに必ず提示するようにしています。 重要: 参照したガイドライン（https://{my-org}.github.io/handbook/backend/design/web _ api _ design.html） をユーザーに必ず提示してください。 AIの要約だけで完結させず、元のドキュメントに戻れる導線を用意しています。全体像を掴んだ上で、気になった箇所は原文で深掘りできます。Handbookそのものの認知と活用が進む効果も期待しています。 工夫点３：抽象から具体へ段階的に Workflow Skillsのフロー全体が、抽象度を段階的に下げていく設計になっています。 ワークフローの4フェーズ（理解→モデリング→計画→実装）がそうですし、各フェーズ内でも同様です。理解フェーズでは概念→構造→実装と段階的に深め、計画フェーズでは概念モデルの出来事やモノをAPIエンドポイントやテーブルへ変換していきます。 一気に情報を出すのではなく、フェーズごとにすり合わせの質問を挟むことで、開発者自身が考える余白を作っています。 以下は、思考実験として「タイミーで企業合併を表現するなら？」というお題で、モデリングのWorkflow Skillsを試したときの様子です。 「将来の新設合併対応を見据えて、今回のモデルはどの程度汎用的にすべきですか？」「合併には時間的なフェーズがありますか？」という質問が飛んできました。そもそも合併に吸収・新設のパターンがあることを私は知りませんでした。Handbookの設計ガイドラインを熟知したエキスパートと、ドメイン知識を持ったエキスパートが悪魔合体するとこんな体験になるのか、と末恐ろしくなった瞬間です。 工夫点４：各ステップに学習ポイントを明示 Workflow Skills内の各ステップには「なぜそうするのか」「ここで何を学ぶか」を明示しています。 📚 学習ポイント: - 出来事（申請する、承認する）→ APIエンドポイント - モノ（勤務実績、勤務時間）→ リソースとリクエスト/レスポンス - ビジネスルール → バリデーションとエラーハンドリング 💡 ガイドラインのポイント: - 出来事は動詞で考え、APIでは名詞（リソース）として表現 - 選択された名前（例：「勤務実績」）をリソース名に反映 作業の手順だけでなく、その背景にある考え方を一緒に伝えることで、AIが出す結果の「なぜ」を開発者自身が理解できる状態を目指しています。 使ってみての感想 自分自身の所感 実際に使ってみて、これまでとは一線を画す体験だと感じています。 従来のAIエージェントの出力は、一気にたくさんの情報を出してくることが多く、情報量に圧倒されて消化しきれないことがありました。ですが、このワークフローでは抽象度を段階的に下げながら教えてくれるので理解がしやすいです。普段の会話で賢いなと感じる人は、抽象的なところから徐々に具体へ落としていくのが上手ですが、このワークフローにも同じ感覚があります。 AIエージェントは便利な開発アシストツールだと思いつつも、開発のギアが上がる感覚はこれまでありませんでした。ですが、このワークフローは明確にゲームチェンジャーだと感じています。 VPoEの反応 VPoEに実際に動かしながら紹介したところ、その場でEMチャンネルに @here 付きで共有してくれました。特に、AIエージェントが段階的にガイドラインを適用しながら開発者と対話する体験に手応えを感じてもらえたようです。 語彙力が下がっているVPoE 他開発チームメンバーの反応 現在、社内への全体発信を終えて各チームへのハンズオンを順次進めているところですが、すでに手応えを感じ始めています。 既に普段の開発で使ってくれているエンジニアからはこんなコメントをもらっています。ありがたい限りです。 handbookはここ1,2年で一番自分に刺さったプロダクトです おわりに この記事では、バックエンド開発Handbookと、それをAIエージェント向けスキルとして届ける取り組みについて紹介しました。 ドキュメントを書くだけでなく、AIエージェントを介して開発フローへ自然に組み込むことで、ガイドラインを届ける新しいアプローチを模索しています。AIへ任せきりにせず人間側の理解を促すことが、知の高速道路を敷くうえで最も大事なポイントだと考えています。 今回の取り組みを通じて、AI時代の開発組織に必要な要素が見えてきた気がしています。短期目線での開発の高速化だけでは不十分で、「全タスクがオンボーディングタスクになっていること」「メンターを基本的にAIが担い、いくらでも質問できて自走できる環境が整っていること」。この2つが揃えば、誰でもどのチームに移っても素早く立ち上がれるようになります。つまり、必要な場所に必要な人材を配置できる人員の流動性の高さに直結します。Handbookとスキルの取り組みは、その第一歩です。 今回作成した Agent Skills はカジュアル面談でもデモできるので、興味ある方はお気軽にお声がけください！実際に触ってみたい方は、ぜひタイミーに入社してください！ product-recruit.timee.co.jp

G-gen の堂原です。当記事では、 Google Workspace の Gmail で、メールの送受信を特定のメールアドレスやドメインとの間にだけ許可し、それ以外は制限する方法について解説します。 はじめに 当記事について 仕様 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 手順1-2 : アドレスリストの作成 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 手順2-2 : 「配信を制限」の設定 はじめに 当記事について E メールの利用に際して、組織内のユーザーが外部の不特定多数とメールを送受信することを防ぎたいケースがあります。例えば、学校の生徒が持つメールアドレスからは、同じ学校の教師と生徒だけと送受信できるようにするケースが考えられます。 Google Workspace の Gmail には「 配信を制限 」という機能があります。これを利用することで、管理者が許可した特定のメールアドレスやドメインとのみ送受信できるようにし、それ以外は禁止するように構成できます。当記事では、「配信を制限」機能の設定方法を紹介します。 参考 : メールの送受信を承認済みアドレスまたはドメインのみに制限する - Google Workspace 管理者 ヘルプ 仕様 「配信の制限」設定を行うと、対象の 組織部門 に所属するユーザーは、指定されたアドレスリストに含まれない送信元からのメールを受信できなくなり、またアドレスリストに含まれない宛先へメールを送信できなくなります。 制限に抵触した場合、送信元のメールアドレスには バウンスメール が返送されます。 バウンスメール例 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 まずは、送受信を許可したいドメインやメールアドレスを設定した アドレスリスト を作成するために、「アドレスリストの管理画面」へ遷移します。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 「Gmail の設定」に遷移するため、設定項目にある「ルーティング」をクリック 「アドレスリストの管理」は最上位の組織部門でしか設定できないため、最上位の組織部門を選択 「アドレスリストの管理」をクリック 手順1-2 : アドレスリストの作成 「アドレスリストの管理」画面にて、アドレスリストを作成します。 「アドレスリストの管理」にて、「アドレスリストを追加」をクリックします。 「アドレス」に送受信を許可したいアドレスとドメインを入力します。注意点として、メールの送信に失敗した際に送信元に送られてくるバウンスメールを受信するためには、 mailer-daemon@googlemail.com を許可する必要があります。 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 「配信を制限」設定は「Gmail の設定」の「コンプライアンス」画面にあるため、まずはそこまで遷移します。 左のサイドバーにて、「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 設定項目にある「コンプライアンス」をクリック 手順2-2 : 「配信を制限」の設定 「配信を制限」の設定画面を開きます。 メールの送受信を制限したい組織部門を選択 「配信を制限」欄にある「設定」をクリック 以下が「配信を制限」の設定画面です。 メールの送受信を許可したいアドレスリストを 1. の箇所に追加します。 2. の箇所に入力した文言は、バウンスメール管理者からのメッセージとして記載されます。 再掲 : バウンスメール例 3. にチェックを付けた場合、同じドメインの Google Workspace アカウント（今回だと dev.g-gen.co.jp ）に対して送信するメールは、「配信を制限」設定の影響を受けなくなります。すなわち、組織のドメインをアドレスリストに追加していなくても、組織内であればメールの送受信が可能です。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

はじめに 駅メモ！開発チームの id:kaidan388 です。 昨年の6月に新機能として「アルバム機能」をリリースしました。私はこの開発でリーダーを務めました。 このアルバム機能は、駅メモ！の中でも特に規模の大きな開発となりました。また、これまでの新機能がバトル面の強化やチェックイン・アクセスのしやすさが中心で、ライフログを強化する試みはあまり例がなかったため、「本当にユーザーの皆様に楽しんでいただけるだろうか」という懸念も当初はありました。 今回は、この大規模かつ前例のない開発を無事にリリースまで進めるために、チームで試みた2つの工夫について、そのメリットとデメリットを交えてご紹介します。 はじめに アルバム機能について 工夫1：大規模ドッグフーディングの実施 良かった点 1. クオリティの向上 2. 最適な画質の模索 難しかった点 1. 工数の予想が難しくなる 2. コードの整合成が取れない 3. 環境準備のコスト まとめ 工夫2：アジャイル的な週次動作確認 メリット 1. バグの徹底的な洗い出し 2. 段階的なクオリティアップ デメリット リファクタリングに時間がかかる おわりに アルバム機能について 駅メモ！は、おかげさまで11周年を迎えることができました。これを「20年続くゲーム」にしていくために、ゲームを継続して遊ぶこと自体が楽しさにつながる機能を、より増やしていきたいと考えました。 駅メモ！には、ユーザーの皆様の「おでかけの記録」を残すライフログという側面があります。 しかし、これまでの新機能はバトル面の強化や、駅の回収（アクセス）をしやすくする強化が中心で、このライフログという側面に関わる機能強化は比較的少ない状態でした。 そこで今回、ライフログ機能の強化を行うことになりました。 様々な軸が考えられましたが、まずは情報量が多く、ユーザー様が後から振り返る価値を感じやすい「写真」や「画像データ」の素材としての価値に着目し、それらを記録として残す機能の開発を進めることにしました。 また合わせて、以前からユーザー様からのご要望も多かった「過去の移動ログを残し、いつでも見返せる機能」も追加しました。移動の記録と写真を同時に見ることで、お出かけの思い出としてよりリッチに記録できる仕組みを目指しました。 工夫1：大規模ドッグフーディングの実施 前例のない機能だったため、開発の初期段階から「まずは社員で集中的に遊んでみて、そのフィードバックを元に仕様を変更していく」という方針を前提に進めました。 もちろん、駅メモ！では普段からリリース前に開発したものを社員で動作確認しています。 しかし今回はその規模を拡大し、駅メモ！開発チーム外からも、普段から駅メモ！で遊んでいる社員に参加を呼びかけました。最終的に、普段の動作確認の4~5倍の人数の協力を得ることができました。 この取り組みでわかった、良かった点と難しかった点をご紹介します。 良かった点 1. クオリティの向上 最大のメリットは、やはりクオリティの向上です。 人数が多いだけでなく、駅メモ！の熟練者から、チーム外のライトユーザーまで、多様な視点からの意見が数多く集まりました。これらの意見を集約することで、UI/UXをどのように変更すべきかが明確になりました。 例えば、ドッグフーディング中に参加者から「本当にただ写真を記録するための道具になってしまっていて、ゲームらしい『楽しい』という感情が湧きづらい」という指摘がありました。 このフィードバックを受け、急遽、画像を投稿する際に以下のようなミニでんこ画像を表示する仕様を追加しました。 かわいいでんこの画像を追加することで、シンプルに画面を華やかにしたり、でんこと一緒に記録して旅をしている感覚を高めたりする効果を狙っています。 この追加によってユーザー様の感情にどういった変化が生まれるかを定量的に計測するのは難しいですが、追加後の開発メンバーやドッグフーディング参加者の反応を見る限り、非常に好評でした。 2. 最適な画質の模索 画質についても、シビアな調整が必要でした。 画質を良くしすぎると画像1枚あたりの容量が嵩み、特にサーバーからの配信コストが非常に高くなってしまいます。かといって、画質が低すぎると「画像を記録する」という体験そのものの価値を損ねてしまいます。 ドッグフーディングを何度も行い、参加者から画質についての具体的なフィードバックを受けることで、コストと体験のバランスを見極め、細かく調整することができました。 難しかった点 1. 工数の予想が難しくなる フィードバックに応じて仕様を変更すると、当然工数も増えます。 後から工数が増えることで、開発の完了時期の予想が難しくなってしまいました。 対応策としてアルバム開発では、以下のようにチケット状況をグラフにして可視化し、期限までに完了できるかに注視しつつリソースの調整などを行いました。 傾きが急になっている箇所は、まさにドッグフーディングの結果を受け工数の見積もりが増加したタイミングです。 2. コードの整合成が取れない フィードバックに応じて仕様が変更されることで、開発初期に書いたコードと整合成が取れなくなり、結果定期的にリファクタが必要になりました。 これも工数を増やすことにつながります。 3. 環境準備のコスト そもそも、「本番のアプリで、一部の社員だけがアルバム機能（開発中のもの）を遊べるようにする」という環境を準備する作業自体にも、相応の時間がかかります。 今回は、２種類のビルド成果物を用意しておき、ユーザによってアルバム機能を含むビルド成果物と含まないビルド成果物を出しわける、という方法を取りました。 目的は達成されますが、２回ビルドが必要になるのであらゆる場面で時間がかかってしまい、コストが増えてしまいます。 まとめ クオリティが確実に上がるという大きなメリットがある反面、その分エンジニアの対応負荷が高くなるトレードオフの関係にあります。 何にでもこの規模のドッグフーディングを行うのはコストパフォーマンスが悪いと感じたため、プロジェクトの重要度や特性に応じて実施を判断すべきだと感じました。 工夫2：アジャイル的な週次動作確認 駅メモ！では通常、ある程度仕様やデザインが固まってから開発（実装）を開始する、ウォーターフォール型に近い進め方を取ることが多いです。 しかし今回は、 プロジェクト全体の規模が非常に大きい 前述のドッグフーディングの結果、仕様変更が予想される という理由から、従来のように「ある程度の要件が固まるのを待ってから開発する」という進め方ができませんでした。 そこで今回は、要件が固まりきるのを待たず、すでにある程度仕様が確定している画面から順番に開発を着手していきました。 特にドッグフーディングの実施日がマイルストーンとなるため、そこまでにコア機能（最低限、画像がアップロードできる部分など）を完成させる必要がありました。細かいデザイン調整は後回しにして、まずは動くものを優先する、といった判断も行いました。 感覚としては、「いつもの半分の開発工数で、7割くらいの完成度のものを作る」ことを求められるような状況でした。 また、開発と並行して、週に1〜2回のペースで、そこまでの開発進捗についてアルバム機能開発チーム内で動作確認会を行いました。 結果として、「1週間単位で計画立て→開発→動作確認→次の計画立て」という、アジャイル開発に近い体制を取ることになりました。 この方針にも、当然ながら良い点と悪い点がありました。 メリット 1. バグの徹底的な洗い出し まめに動作確認を繰り返すため、バグを早期に、かつ徹底的に潰すことができます。 実際、今回のアルバム機能は規模が大きかったにも関わらず、リリース時に機能起因の不具合は1件も発生しませんでした。これは大きな成果だと感じています。 2. 段階的なクオリティアップ 大規模なドッグフーディングにかける前、まずは開発チーム内で何度も動作確認を実施しました。これにより、チーム内で見つけた分かりづらい文言やUIの細かい調整を事前に実施できました。その結果、クオリティ向上につながりました。 デメリット リファクタリングに時間がかかる この進め方の宿命ですが、一度書いたコードを、後からの仕様変更に伴って何度も書き直していくことになります。 開発の終盤になるほどコードベースは全体的に混沌としていき、変更作業が辛くなっていく、という場面も多々ありました。 「変更に強いコードを書く」という基本がいかに大事か、改めて痛感させられました。 おわりに 今回は、駅メモ！の「アルバム機能」開発において試みた、「大規模ドッグフーディング」と「アジャイル的な週次動作確認」という2つの工夫をご紹介しました。 どちらもメリットだけでなく、工数の増加やコードの複雑化といったデメリットも抱えていますが、前例のない大規模開発を進める上では非常に有効な手段だったと感じています。 リリース後、多くのユーザー様がアルバム機能をご利用くださり、お出かけの思い出を写真と共に記録していただいている様子を拝見し、開発チーム一同、大変嬉しく思っています。 これからも駅メモ！を長く楽しんでいただけるよう、チーム一同、開発と改善を続けてまいります。