テスターの信頼構築——再現性のあるパターン バグを報告した。正確に書いた。でも開発者の反応は「ふーん」の一言で終わった——テスターなら、一度はこの経験があるんじゃないでしょうか。 問題は、報告の質ではありません。あなたの話を、開発者は聞いていますか？ 戦略的思考の前提には、「この人の意見は聞く価値がある」と開発者に思われている状態が必要です。これがなければ、どんなに鋭い分析も、どんなに正確なリスク予測も、チームには届きません。 この記事では、テスターが開発者からの信頼を獲得するための、再現性の高いパターンを整理します。「コミュニケーション力を上げよう」「仲良くなろう」といった属人的なアド

システム開発で要件変更が起きる原因や費用・納期・品質への影響を解説します。変更を受け入れる判断基準、追加費用の確認項目、発注側と開発側が揉めない変更管理の手順も紹介します。 「 画面を少し直したいだけなのに、開発会社から追加費用と納期延長を提示された 」 このような予期しない状況に戸惑うケースは少なくありません。 開発側でも、現場や顧客の要望には応えたい一方、変更を無条件で受け入れれば、予算超過や品質低下につながるという悩みがあります。 システム開発における 要件変更 は、必ずしも失敗やトラブルを意味するものではありません。 事業環境や利用者のニーズが変わる以上、開発途中で新しい要望が生まれることはありますが、問題になるのは、影響を確認せず 場当たり的に対応すること です。 変更前後の差分、事業上の必要性、追加工数、納期、品質への影響 を整理すれば、感覚ではなく根拠に基づいて判断できるようになります。 そこで今回は、 システム開発における要件変更の原因や影響 、 受け入れる際の判断基準 、 実務で使える変更管理の手順 を順番に整理しました！ 発注側と開発側の認識をそろえ、必要な変更を適切に取り入れながら、プロジェクトを安定して進めるために役立ててください。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド 要件変更は「悪」ではない！まず原因と影響を正しくつかもう システム開発では、最初に決めた内容を 一切変えずに完成まで進められるとは限りません 。 利用者へのヒアリングが進んで新たな業務課題が見つかったり、市場や法制度が変わったりすれば、当初の要件を見直す必要が生じます。 そのため、要件変更の発生自体を失敗と捉えるのではなく、 価値のある変更を選び、影響を管理すること が重要です。 一方で、変更内容を口頭で受け入れたり、費用や納期を確認しないまま着手したりすると、開発範囲が際限なく広がります。 まずは要件変更の意味、発生する原因、プロジェクト全体に及ぼす影響を理解し、 関係者が同じ前提で話し合える状態 をつくりましょう。 そもそも要件変更とは？不具合修正や追加要望との違いを整理しよう 要件変更とは、一度合意したシステムの機能、性能、操作方法、対象業務などを、 開発途中で追加、削除または修正すること です。 たとえば、当初予定していなかった承認機能の追加や、外部サービスとの連携方法の変更などが該当します。 一方、合意済みの仕様どおりに動いていない場合は、一般的に 不具合修正 として扱われ、要件変更とは区別して考える必要があります。 ただし、要件定義書に「使いやすくする」「必要に応じて出力できる」といった曖昧な表現しかない場合、追加要望なのか当初範囲の修正なのかを判断できません。 判断するときは、要件定義書や仕様書だけでなく、見積書、契約書、提案書、議事録、メールなども確認し、当初どこまで合意していたかを整理します。 最初から責任の所在を争うのではなく、 現在の合意内容と変更後の内容との差分 を可視化することが、冷静な協議につながります。 合意内容そのものが不明確な場合は、一方的に要件変更と決めず、 当時の目的や説明内容まで振り返って判断しましょう 。 要件変更が起こる典型的な5つの原因を知ろう 要件変更が起きる主な原因は以下のとおりです。 ・開発前のヒアリングが不足 し、通常業務だけでなく例外処理や繁忙期の運用まで把握できていない。 ・経営層、利用部門、情報システム部門などの間で 意見がまとまらないまま 、開発を開始してしまう。 ・試作画面や開発中の機能を見た利用者から、 当初は想定していなかった改善案や追加要望が出る 。 ・ 法制度、市場環境、事業戦略、社内ルールなどが変化 し、予定していた仕様では事業上の目的を達成できなくなる。 ・外部システムの仕様、データの品質、インフラの制約などが開発途中で判明し、 技術的な見直しが必要になる 。 ヒアリング不足や社内合意の欠如は準備によって減らせますが、外部環境の変化を完全に防ぐことはできません。 重要なのは、すべての変更をなくすことではなく、 防げる変更と避けにくい変更を分け、発生時のルールを決めること です。 「少し変えるだけ」が大きな影響につながる理由を理解しよう 画面上では小さく見える変更でも、その裏側では複数の機能やデータがつながっていることがあります。 入力項目を一つ追加するだけでも、データベース、入力チェック、集計処理、帳票、外部連携、権限設定などの修正が必要になる場合があります。 プログラムの修正後は、変更箇所だけでなく、関連する既存機能が正しく動くかを確認する 再テスト も欠かせません。 さらに、要件定義書、設計書、テスト仕様書、操作マニュアル、運用手順など、関連する文書も変更後の内容に合わせる必要があります。 開発後半になるほど完成済みの設計やプログラムが増えているため、同じ変更でも初期段階より修正範囲が広がりやすくなります。 追加作業を既存スケジュールへ無理に押し込むと、テスト時間が不足し、品質低下や担当者の長時間労働を招くおそれがあります。 変更の大きさは見た目だけで判断せず、 設計から運用までの連鎖的な影響 を確認することが大切です。 管理しない要件変更がプロジェクトを壊すリスク 管理されていない要件変更が積み重なると、予算と納期は変わらないまま、開発する機能だけが増える状態になります。 このような 開発範囲の膨張 が起きると、計画上の余裕が失われ、重要な作業へ十分な時間を割けなくなります。 特に納期を優先してテスト期間を短縮すると、変更箇所だけでなく、既存機能にも不具合が残る可能性が高まります。 口頭やチャットだけで変更を進めた場合、実際のシステムと要件定義書、設計書、テスト仕様書の内容が一致しなくなることもあります。 さらに、発注側は当初費用に含まれていると考え、開発側は追加作業だと考えるなど、費用負担を巡る認識の違いが表面化します。 担当者が独断で変更を受け入れてしまえば、遅延や予算超過が発生した際に、判断した個人へ責任が集中しかねません。 変更内容、影響、承認者を記録し、 組織として意思決定する仕組み を整えることが、プロジェクトと担当者の双方を守ります。 その変更、本当に今必要？受け入れる前に5つの視点で判断しよう 変更依頼が届いたとき、すぐに「対応する」「対応しない」と回答する必要はありません。 最初に行うべきことは、当初の合意範囲、変更の目的、影響範囲、費用、納期、優先順位を整理することです。 変更によって得られる価値だけでなく、変更しなかった場合のリスクも確認すると、関係者が比較しやすくなります。 また、すべての希望を一度に実現するのではなく、範囲を縮小する、次期開発へ回す、既存機能で代替するといった選択肢も検討します。 以下の視点を共通の判断基準として使えば、立場や声の大きさに左右されにくい意思決定が可能になります。 視点1：当初の合意範囲と照らし合わせよう 最初に、変更対象となる機能や動作が、要件定義書や仕様書へどのように記載されているかを確認します。 見積書や契約書に記載された作業範囲、前提条件、対象外作業も照合し、当初の合意内容を整理しましょう。 合意した要件を正しく実現するために必要な修正であれば、不具合対応や当初範囲の作業として扱われる可能性があります。 反対に、新しい業務、新しい利用者、新しい外部連携などを加える場合は、追加の要件として扱うことが考えられます。 資料の表現が曖昧なときは、会議の議事録、提案時の説明、メールのやり取りなども確認し、決定までの経緯をたどります。 変更前後の内容を表形式で並べ、追加、削除、修正となる部分を示すと、関係者間の認識を合わせやすくなります。 誰が悪いかではなく、何が変わったか を最初に確認することが、感情的な対立を避けるポイントです。 視点2：変更の目的と事業上の価値を確かめよう 変更の必要性を判断するときは、「何を追加したいか」だけでなく、「なぜ今必要なのか」を確認します。 変更によって解決したい業務課題、利用者への効果、売上への貢献、作業時間の削減などを具体的に整理しましょう。 法令対応、重大なセキュリティ対策、事業継続に必要な機能であれば、費用が増えても優先度は高くなります。 一方、「あれば便利」「競合にも似た機能がある」といった理由だけでは、開発コストに見合う価値を判断できません。 変更しなかった場合に、どのような損失、業務負担、顧客離れ、法的リスクが生じるかも比較材料になります。 目的が曖昧な要望はすぐに開発対象へ加えず、要求者へ背景を確認し、別の方法で課題を解決できないか検討します。 変更によって得られる価値と実施しないリスク の両方を示すことで、経営層や決裁者にも説明しやすくなります。 視点3：影響範囲を漏れなく洗い出そう 影響範囲の確認では、変更する画面や機能だけを見るのではなく、関連するデータや処理までたどる必要があります。 機能面では、入力、計算、検索、承認、通知、帳票、外部サービスとの連携などへの影響を確認します。 性能、セキュリティ、可用性、バックアップ、保守性といった 非機能要件 への影響も見落とせません。 たとえば、利用者を増やす変更では、画面の追加だけでなく、アクセス集中時の性能や権限管理の見直しが必要になる場合があります。 設計、実装、テスト、データ移行、マニュアル、利用者教育、運用監視など、工程別に追加作業を整理しましょう。 既存機能へ不具合を持ち込まないためには、変更箇所と関連機能を結び付け、再テストする範囲を明確にすることも重要です。 変更内容と関連成果物をひも付ける管理 を行えば、仕様書だけ更新されないといった修正漏れを防ぎやすくなります。 視点4：費用・納期・品質の変化をセットで比較しよう 要件変更の影響は、追加費用だけを見て判断するのではなく、納期と品質を含めて確認します。 費用には、プログラムの修正だけでなく、影響調査、設計変更、会議、再見積もり、テスト、文書更新などの工数も含まれます。 納期については、変更作業の日数に加え、担当者の確保、確認待ち、外部サービスとの調整期間も考慮しましょう。 当初の納期を維持する場合、人員を追加する、ほかの機能を減らす、段階的に公開するなど、何らかの対応が必要になります。 期間を変えずに作業だけを増やせば、テストやレビューの時間が削られ、品質面のリスクが高まります。 「予算は増やせない」「納期も変えられない」「すべての機能が必要」という条件を同時に求めると、現場へ負担が集中します。 費用・納期・品質のどれを守り、どこを調整するか を明示し、現実的な選択肢から判断することが大切です。 視点5：優先順位を決め、代替案まで用意しよう すべての要望を同じ重要度で扱うと、本当に必要な機能へ時間と予算を集中できません。 要件を「必ず必要」「重要だが調整可能」「余裕があれば実施」「今回は見送る」などに分類しましょう。 優先順位は、要求者の役職だけで決めず、事業価値、緊急性、利用頻度、法的必要性、技術リスクなどを基準にします。 新しい機能を加えながら当初の予算と納期を守る場合は、優先度の低い機能を同じ規模だけ外す方法も有効です。 一度に完成形を目指さず、最低限の機能を先に公開し、利用状況を確認してから拡張する方法も検討できます。 既存の機能や手作業で一時的に代替できる場合は、次期開発へ延期する判断もしやすくなります。 実施、範囲縮小、段階的実施、延期、却下を並べ、 複数の選択肢から合意できる状態 をつくりましょう。 追加費用と納期延長はどう決める？双方が納得できる確認項目 追加費用を協議するときは、変更後の金額だけでなく、何の作業が追加されたのかを確認します。 影響調査、設計、開発、テスト、データ移行、文書更新、進行管理などに分けて示すと、見積もりの根拠が分かりやすくなります。 発注側は金額を一律に否定するのではなく、当初範囲との差分、必要工数、単価、再テスト範囲を確認しましょう。 開発側も「対応が大変だから」という説明ではなく、変更対象と関連機能を示し、追加作業が必要な理由を伝えることが重要です。 費用負担は、変更が発生した経緯、当初の合意内容、契約形態、双方の役割を整理したうえで協議します。 納期、納品物、検収条件、支払い時期にも影響する場合は、金額と併せて変更後の条件を明確にします。 基本的には正式な合意前に作業を始めず、緊急対応が必要な場合も、対象範囲と上限工数を決めて承認を残しましょう。 契約や責任範囲の判断が難しい場合は、 購買部門や法務部門などの専門部署 を早い段階で交えることが安全です。 要件変更を揉めずに進める！実務で使える6ステップ 要件変更を安定して管理するには、依頼を受けるたびに対応方法を考えるのではなく、共通の流れを決めておく必要があります。 基本となるのは、変更要求の記録、一次判定、影響分析、承認、正式合意、実装後の更新という流れです。 この手順を設ける目的は、変更を拒否することではなく、必要な変更を正しく選び、プロジェクトへ安全に取り込むことです。 小規模な変更まで複雑な会議へ回すと運用が続かないため、金額や影響度に応じて簡易手続きと正式手続きを分けるとよいでしょう。 それぞれの段階で誰が何を行うかを決め、判断の経緯を追跡できる状態にしておくことが重要です。 ステップ1：口頭依頼をそのまま進めず、変更要求を記録しよう 会議、メール、チャットで出た要望は、その場で開発へ着手せず、正式な 変更要求 として記録します。 管理先が複数あると確認漏れが起きるため、表計算、課題管理システム、申請フォームなど、一つの場所へ集約しましょう。 記録する基本項目は、 要求者、起票日、対象機能、現在の内容、変更後の内容、変更理由、希望時期 です。 加えて、変更によって得たい効果、実施しない場合の問題、想定する優先度も記載すると、後の判断がしやすくなります。 「検索機能を改善したい」といった抽象的な表現だけでなく、誰が、どの場面で、何に困っているのかを確認します。 変更前後の差分が分かる画面イメージや業務フローを添付すれば、発注側と開発側の解釈のずれを減らせます。 入力項目を増やしすぎると口頭依頼へ戻ってしまうため、 現場が継続して使える簡潔さ も意識しましょう。 ステップ2：緊急度と重要度を確認し、分析する順番を決めよう 登録された変更要求は、すべてをすぐに詳細分析するのではなく、最初に緊急度と重要度を確認します。 法令違反、重大なセキュリティ上の問題、事業停止につながる不具合などは、優先的な対応が必要です。 一方、利便性の改善や将来利用する機能は、次期開発へ回しても大きな問題がない可能性があります。 似た要望が複数の部署から出ている場合は、一つにまとめて分析し、個別対応による重複作業を減らしましょう。 要求内容を確認する際は、「 絶対に必要な条件 」と「 希望する実現方法 」を分けることが重要です。 実現方法を変えても目的を達成できる場合は、より低コストで対応できる代替案が見つかることがあります。 分析対象、保留、却下候補に分け、現在どの状態にあるかを要求者へ共有すると、放置されているという不満も防げます。 ステップ3：影響範囲を分析し、見積もりと選択肢を作ろう 詳細分析では、変更する機能だけでなく、 要件、設計、プログラム、データ、テスト、運用への影響 を洗い出します。 外部サービス、ほかの開発案件、共通機能などとの依存関係も確認し、想定外の手戻りを防ぎましょう。 洗い出した作業を基に、必要な工数、追加費用、延長期間、担当者、品質上のリスクを見積もります。 一つの案だけを提示すると、承認か拒否の二択になり、関係者間の調整が難しくなります。 当初の要望をそのまま実施する案、範囲を縮小する案、複数回に分ける案、既存機能で代替する案などを用意しましょう。 変更を実施した場合の効果だけでなく、実施しなかった場合に残る問題も示すと、比較しやすくなります。 費用・納期・効果・リスクを同じ形式で並べること が、決裁者の迅速な判断につながります。 ステップ4：責任者を交えて、実施・延期・却下を決めよう 影響分析が終わったら、発注側と開発側の責任者を交えて、変更を取り込むかどうかを決定します。 業務上の価値は利用部門が説明し、技術的な影響は開発側が説明するなど、役割を分けると判断材料がそろいます。 軽微な文言修正と、大幅な機能追加を 同じ承認方法にすると、意思決定が遅くなります 。 費用、延長期間、品質への影響などに基準を設け、担当者が承認できる範囲と責任者の承認が必要な範囲を分けましょう。 会議では実施するかどうかだけでなく、範囲、実施時期、優先順位、削除する機能などの条件も決めます。 承認、条件付き承認、延期、却下のいずれになった場合も、決定理由と参加者を記録します。 現場担当者だけに判断を任せず、 組織として決定した証拠を残すこと が、後の責任問題や認識違いを防ぎます。 ステップ5：費用・納期・成果物の変更を正式に合意しよう 変更の実施が決まったら、口頭の了承だけで終わらせず、変更後の条件を文書にまとめます。 文書には、変更内容、対象範囲、追加費用、新しい納期、変更する成果物、担当者などを記載します。 検収条件、支払い時期、役割分担、前提条件が変わる場合は、それらも併せて明確にしましょう。 契約内容への影響に応じて、変更合意書、覚書、追加見積書、発注書など、適切な方法で承認を残します。 軽微な変更で正式な契約変更を行わない場合でも、承認者、承認日、対応内容、費用の有無は記録しておくことが重要です。 合意前に先行作業を始めると、後から費用や納期について合意できなかった場合に、作業分を回収できないおそれがあります。 緊急対応では、調査だけを先行する、上限工数を決めるなど、 先行できる範囲を限定した合意 を取りましょう。 ステップ6：実装後のテストと文書更新まで完了させよう 承認後は、正式に合意した内容だけを開発対象へ反映し 、作業中の非公式な追加 を防ぎます。 実装が終わったら変更箇所だけでなく、影響分析で特定した関連機能も含めてテストを行います。 データ形式や外部連携を変更した場合は、移行処理、連携先、エラー時の動作まで確認しましょう。 要件定義書、仕様書、設計書、テスト仕様書、操作マニュアル、運用手順 も、実際のシステムに合わせて更新します。 変更内容は利用者や運用担当者へ共有し、操作説明、教育、問い合わせ対応の準備が必要かを確認します。 リリース後は、期待した効果が得られたか、不具合や業務上の問題がないかを一定期間確認することも大切です。 最後に見積工数と実績工数を比較し、差が生じた理由を記録すれば、 次回の影響分析や見積もりの精度を高められます 。 実装、テスト、文書更新、共有までを一つの変更作業 として完了させましょう。 発注側と開発側の役割を決め、個人任せを防ごう 要件変更を円滑に進めるには、発注側と開発側のどちらか一方へ判断を任せず、それぞれの役割を明確にします。 発注側は、変更の目的、業務上の必要性、優先順位、予算、意思決定者を整理します。 開発側は、技術的な影響、必要工数、品質上のリスク、実現可能な代替案を分かりやすく提示します。 プロジェクト責任者は、費用、納期、品質、事業価値のバランスを確認し、関係者間の意思決定を支援します。 追加契約や責任範囲の見直しが必要な場合は、購買部門や法務部門も早い段階から参加させましょう。 利用部門には要望を出すだけでなく、業務確認、試験利用、受け入れ確認などへ協力してもらう必要があります。 担当者が異動や退職をしても経緯を追えるように、判断内容を個人のメールへ閉じ込めず、組織で共有します。 目的を決める人、影響を説明する人、最終判断をする人 を分けることで、責任の押し付け合いを防げます。 ウォーターフォールとアジャイルで変更ルールを使い分けよう ウォーターフォール型では、要件定義、設計、開発、テストの順に工程を進めるため、合意済みの成果物が変更判断の基準になります。 後の工程へ進むほど完成済みの成果物が増えるので 、開発後半の変更は修正範囲が広くなりやすい点 に注意が必要です。 工程の区切りでレビューと承認を行い、 変更後にどの工程まで戻る必要があるかを確認しましょう 。 アジャイル型では、要望を優先順位付きの候補として管理し、短い開発期間ごとに実装する内容を選びます。 新しい要件を加える際は、同じ期間に予定していた優先度の低い項目と入れ替えることで、作業量の膨張を抑えられます。 ただし、アジャイル型だからといって、機能を無償かつ無制限に追加できるわけではありません。 開発対象の大枠、予算、期間、意思決定者などに影響が出る場合は、正式な変更管理と合意が必要です。 開発手法にかかわらず、 誰が優先順位を決め、何を基準に変更するか を明確にしておきましょう。 要件変更に強いプロジェクトをつくる5つの予防策 要件変更による混乱を減らすには、開発開始前に システムの目的、対象業務、利用者、成功条件 を明確にします。 現在の業務フローを通常時だけでなく、繁忙期、例外処理、障害時まで確認すると、後から重要な要件が見つかる事態を減らせます。 文章だけで認識を合わせようとせず、 試作画面、業務フロー図、データ例 などを用いて、完成後の姿を早めに共有しましょう。 機能だけでなく、性能、セキュリティ、可用性、バックアップ、運用体制などの非機能要件も初期段階で確認します。 利用部門、経営層、情報システム部門など、判断に必要な関係者をレビューへ参加させ、組織内の合意を取ります。 開発開始前に、変更の申請方法、承認者、影響分析の担当者、追加費用や納期変更の扱いも決めておきましょう。 変更に備えた予備費や予備期間を計画へ設けておけば、必要な変更が発生した際にも、全体計画への影響を抑えやすくなります。 変更を起こさない計画ではなく、変更が起きても制御できる計画 を目指すことが、安定したプロジェクト運営につながります。 まとめ システム開発の要件変更は、完全に防ぐものではなく、事業価値とプロジェクトへの影響を見ながら管理するものです。 変更依頼が出たら、その場で対応を約束せず、当初範囲との差分、目的、影響、費用、納期、優先順位を確認しましょう。 必要な変更であっても、実施時期や範囲、代替案を比較すれば、予算や納期への影響を抑えられる場合があります。 追加費用や納期延長は、発注側と開発側の感覚で争うのではなく、変更によって増える作業と当初の合意内容を基に協議することが重要です。 変更要求の記録、影響分析、承認、書面での合意、実装、テスト、文書更新までを一つの手順として整えましょう。 まずは、口頭で届いた要望を記録する場所と、変更を最終承認する責任者を決めることから始めてください。 担当者一人で抱え込まず、関係者が同じ判断材料を共有できる体制をつくることが、要件変更をプロジェクトの価値へ変える第一歩です。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

はじめに こんにちは。ZOZOでアプリバックエンドブロックのブロック長をしている湯川です。以前公開した記事では、ZOZOTOWNアプリ用APIのリプレイスの初期の開発・課題・解決方法などについて紹介しました。 techblog.zozo.com 今回はその続編として、商品詳細APIリプレイスをどのように進めたのかを紹介します。今回のリプレイス対象は、約5,000行のコードと約410項目のレスポンスを持つ巨大なAPIでした。長年の機能追加によって複雑化し、いわゆる「秘伝のタレ」と呼ばれる状態になっていました。 しかし本記事でお伝えしたいのは、単なるAPIリプレイスの話ではありません。 限られた期間の中で、以下に着目して大規模リプレイスを進めるための技術とマネジメントの取り組みについて紹介します。 巨大なモノリスをどう理解したのか 並列開発が可能な構造をどう作ったのか なぜ3チームでの開発が可能になったのか 目次 はじめに 目次 迫る期限と見えない全体像 「どんな手段を使ってもいい」 突破口となったフィーチャー分割 依存関係を可視化する 構造を見てから戦略を立てる スケールできた理由 あえて改善しない 結果 まとめ 迫る期限と見えない全体像 商品詳細APIリプレイスの着手時点で、私たちには大きな課題がありました。リプレイス前のAPIサーバーはオンプレで稼働しており、その縮退スケジュールは既に決まっていました。一方で、商品詳細APIは長年の改修によって巨大化しており、全体像を把握できるメンバーは誰も居ない状態でした。 価格、在庫、商品画像、サイズなど、多数の機能が単一APIに集約されていました。変更の影響範囲は広く、機能間の依存関係も複雑です。先述の通りコード量は約5,000行、レスポンス項目は約410項目もありました。 当然ながら、「どれくらい時間がかかるのか」すら正確には分からない状態でした。 「どんな手段を使ってもいい」 そんな状況の中で、上司から言われた言葉があります。 「どんな手段を使ってもいいので、達成方法を考えてほしい」 振り返ると、この一言が大きな転換点でした。 通常であれば、今いるチームで進めることを前提に考えがちです。既存の役割分担を維持し、既存の開発プロセスに合わせるのが普通です。 しかし、この言葉によって私自身がその前提を外せるようになりました。 チーム構成も変えていい。 担当範囲も変えていい。 進め方そのものを変えていい。 ならばまず、「この巨大な塊をどう攻略するか」を考えるべきだと思いました。 突破口となったフィーチャー分割 私は本案件の開発をリードするカイルさんに「どうにかしたいから対応方法を検討してほしい」と依頼しました。 カイルさんは 前編で紹介したフェーズ3からリプレイスにJOIN したメンバーで、このプロジェクトではアーキテクトも担当しています。 様々な切り口で分割を検討した結果、彼が提案したのは フィーチャー単位での分割 でした。この分割方法を掘り下げるため、カイルさんにインタビューしてきました。 湯川：最初に「どうにかしたいから対応方法を検討してほしい」とお願いしましたが、どうやってフィーチャー分割という発想に至りましたか？ カイル：最初はUIコンポーネント単位、レスポンスオブジェクト単位、データソース単位なども検討しましたが、レガシーエンドポイントのためコンポーネント間やオブジェクト間の依存関係が複雑です。開発単位として独立できないと思いました。その時、「このAPIをアジャイルでゼロから作った場合、どの粒度でどの順番で作っていくんだろう」と想像してみました。そうすると、ECサイトの商品ページに絶対必要なコアな機能と、一旦MVPができた状態で後から追加する細かい機能という粒度で分けられることに気づきました。 湯川：商品詳細APIは機能が多いですが、具体的にはどう整理しましたか？ カイル：そうですね、全部で41フィーチャーになりました。これだと依存関係や開発する順番を整理するのが大変そうだったので、細かい機能をさらに「基本機能」「商品タイプ」「追加機能」などカテゴリに分類しました。それぞれのカテゴリをひとつのフェーズとして順番に開発していくイメージです。 湯川：振り返ってみて、分割の観点で学びはありましたか？ カイル：「商品タイプ」のフィーチャーは様々な機能に横断して影響することが多く、分割観点としてあまりよくなかったかもしれません。後のショップ詳細APIでは、商品の属性ではなく機能の軸で分割するようにしました。例えば「◯◯ショップの商品」ではなく「特定ショップの専用UI」や「特定ショップのカテゴリ」というふうに細かく分けています。 このようにして、巨大なAPIを構造で捉えることができるようになりました。 さらに、分割のアウトプットとして、各フィーチャーごとに以下の情報もまとめてありました。 レスポンス項目 既存コードで該当箇所がわかるコメントをうったコミット 利用している外部API・マイクロサービス一覧 これらの対応によって、1チームで進めた場合は 約1年規模 という見積もりが出ましたが、並行開発という選択肢を取れるようになりました。ただし、並行開発を実現するためには、フィーチャー間の依存関係を明確にする必要がありました。 依存関係を可視化する 次に取り組んだのは依存関係の詳細な整理です。 依存度の高いフィーチャー 独立性の高いフィーチャー どちらが先に必要か、どこがボトルネックになるかを構造として把握できるように再度コードを解析し、各フィーチャーごとの依存関係を明確にしました。 NotebookLMを使って、依存関係を動的に可視化できるインフォグラフィックも作りました。 私たちはこの作業を通じて、「どう実装するか」ではなく、 「どこなら並列化できるか」 を考えられるようになったのです。 構造を見てから戦略を立てる ここでようやく組織の話になります。一般的には、先に体制を決めてから仕事を割り振ります。 しかし今回は逆でした。まず構造を理解し、次に依存関係を整理し、最後に組織を設計します。 つまり、組織に合わせてアーキテクチャを作るのではなく、アーキテクチャに合わせて組織を設計しました。 依存度の高い基本機能は特定チームが担当し、独立性の高い機能は別チームに任せます。 スプリントごとに担当フィーチャーを計画しながら、3チーム並列での開発体制を構築しました。 スケールできた理由 もちろん、人を増やしただけでは成功しません。むしろ、「人月の神話」の通り、遅くなることもあります。そこで私たちは、仕様理解のコストを下げることに注力しました。 実は商品詳細リプレイスの数か月前から、別チームがUIとレスポンスを紐付けた仕様書を整備していました。この仕様書が、フィーチャー分割、開発、テストのすべての基準になりました。 さらにレガシーAPIのリプレイスを進めていく中で、タスクテンプレートを整備し、チーム間でタスク粒度をある程度統一していました。 結果として、3チーム並列でもタスクの粒度が揃っているため、開発の相談ごとが発生しても連携がスムーズでした。 あえて改善しない もう1つの成功要因があります。それは、 改善しないことを決めた ことです。商品詳細APIには改善余地が数多くありました。せっかくリプレイスする・作り変えるのであれば、「不要と思われる仕様をなくしたい」「レスポンス構造も整理したい」「より適切なエラーハンドリングをしたい」と思います。 しかし、それを始めると終わりが見えません。これは今までのリプレイスプロジェクトで得た知見でした。 今回の目的は改善ではなくリプレイスです。 そのため、 現行をそのまま置き換える ことに徹底的に集中しました。この意思決定によって議論が減り、スピードが大きく向上しました。 結果 最終的に、以下の様々な良い結果を得ることができました。 3チームによる並列開発を実現 約1年規模だった開発を約3か月で完了 サイクルタイムを50％改善 レイテンシーを50％改善 リプレイス前のAPIサーバーのCPU負荷を70％削減（ピーク時） 不具合による切り戻しは0件 品質とスピードを両立しながら、オンプレサーバー縮退にも大きく貢献できました。 まとめ 今回のリプレイスを振り返ると、成功要因はやはりこのフィーチャー分割です。 このフィーチャー分割がきっかけで、後続のリプレイスも順調に進行しました。分割方法も改善を重ね、より細かくユーザーストーリーにあわせた分割ができるようになりました。そして、何より3チームのみんなで同じ目標に向かって開発を進めていくことができたのも大きな成果でした。 今回のプロジェクトは、まさにZOZOが大切にしている「想像」と「創造」を体現した取り組みだったと感じています。 この経験が、同じように大規模リプレイスへ挑戦する方々の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com