はじめに こんにちは、バックエンドエンジニアの小笠原（ @yukineko_819 ）です。 Checkout Reliabilityチームに所属し、負荷試験環境の構築や購入ロジックの最適化など、購入体験の信頼性向上に向けた取り組みをしています。 今回は、「どのショップでも、いつでも安定して購入できる」という購入体験を守るために、購入時のクレジットカード決済へ流量制御（以降、レートリミッタ）を導入した話をご紹介したいと思います。とくに、 特定のショップに購入が集中しても、ほかのショップでは決済ができる状態にする ために、アクセス集中の影響をできる限り抑え、全体の購入可用性を平準化する設計をどう考えたか、というところが中心になります。 あるショップにアクセスが集中している時、ほかのショップで購入ができない まずは、私たちが解きたかった問題からお話しさせてください。 一般的に、決済処理には安定稼働のために単位時間あたりに捌ける流量の上限が設定されており、これを決済流量制限（以降、決済レートリミット）と言います。平常時であればこの決済レートリミットを意識することはほとんどありません。しかし、大型の販売イベントや限定商品の販売といったケースで、特定のショップに対してごく短期間に購入が一気に集中している時、この決済レートリミットが問題になります。 このとき、購入が集中しているショップの決済で決済レートリミットに達すると、まったく無関係なほかのショップにも影響が及んで制限がかかり、購入できなくなってしまう可能性があります。 これは購入者から見れば、自分にもショップにも何の落ち度もないにもかかわらず購入できない、というマイナスの体験となってしまいます。ネットショップの買い物体験として、これほど避けたいものはないでしょう。 いつでも買えるカートを目指して そこで私たちが目指したのは、特定のショップに購入リクエストが集中している状況でも、ほかのショップではいつもどおり購入できる状態を保つことでした。これを実現するために、次の2つを満たすレートリミッタの設計を考えました。 1. 流量を自分たちで把握して制御する ひとつめは、流量を自分たちでカウントして能動的に制限をかけることです。決済レートリミットに到達しているか否かわからないまま決済を実行するのではなく、安定して捌ける範囲の上限を自社側で定義し、あえて能動的に流量を絞る方針を取りました。 2. その他のショップの取り分を「引き算」で残す ふたつめは、アクセス集中ショップとその他のショップを分けて管理することです。これまではアクセス集中ショップが流量を独り占めしてしまい、その他のショップの決済が通らなくなってしまう危険がありました。そこで、あえてアクセス集中ショップに本来の上限値よりも少しだけ低い上限を設定し、残った流量をその他のショップが使えるようにする、という方針を取りました。 この設計のポイントは、その他のショップ用の流量を予め確保しておくのではなく、アクセス集中ショップの上限値にキャップをかける形にしたことです。アクセス集中ショップといっても常に上限に張り付いているわけではありませんし、その他のショップでの購入がたまたま同時刻に重なってリクエスト数がはね上がる可能性もあります。この方針は、その他のショップ側の流量に不要な制限をかけてしまわないようにするという意図があります。 図1: アクセス集中の影響を抑え、その他のショップの取り分を「引き算」で残す どう作ったか ここからは、より具体的な処理フローの話に移りたいと思います。 決済を実行する直前に、1トークンを要求する レートリミッタをどこに挟むべきか検討した時、私たちは決済処理を実行する直前に挟むことにしました。 決済処理は、その実行前にレートリミッタへ「1トークンください」と要求します。このレートリミッタの実体は、専用のRedis上でアトミックに実行される Luaスクリプトで、古典的なトークンバケットとして振る舞います。 なぜLuaなのかというと、「トークンの回復 → トークン残量を確認する → トークンを消費する」という一連の判定をひとつのアトミックな操作にまとめたかったからです。こうしておけば、同時に大量のリクエストが来ても、競合することなく正しくカウントできます。 このレートリミッタは、トークンが残っていればトークンを消費してOKを返し、制限と判定されればNGを返します。レートリミッタを呼び出したアプリケーション側は、判定がOKであればそのまま外部APIを実行して決済に進みます。NGであれば外部APIを実行することなく、決済を諦めて処理をエラーで終了させます。 グローバルバケットとアクセス集中ショップ用バケットの2段構成にする ただ、総量を制御するだけでは足りません。先着順でトークンを奪い合うと、アクセス集中ショップが全てのトークンを独占してしまい、その他のショップが締め出されてしまうからです。これでは今までと何も変わりません。 そこで中核になるのがアクセス集中ショップ用に別途専用のトークンバケットを用意するという方法です。 全ショップが共通のグローバルバケットからトークンを消費する アクセス集中ショップだけアクセス集中ショップ用バケットからも追加で消費する アクセス集中ショップ用バケットの上限をグローバルバケットより小さく設定する ポイントは、アクセス集中ショップではないショップ向けのバケットを明示的に確保しているわけではない、というところです。あえてアクセス集中ショップ側を絞ることで、その差分がその他のショップの取り分として引き算で自動的に残るようにしています。 この設計には、 work-conserving （余力を遊ばせない）という嬉しい性質があります。アクセス集中ショップがなければグローバルバケットは誰でも使えるので、トークンが余ることはありません。アクセス集中ショップが現れて初めて、その分だけアクセス集中ショップ用バケットの制約が効き始める、というわけです。 判定のルールを整理すると、次のようになります。 アクセス集中ショップ ： グローバルバケットとアクセス集中ショップ用バケットの両方に空きがあってはじめて許可。 その他のショップ ：グローバルバケットに空きがあれば許可。 図2: その他のショップはグローバルバケットだけ、アクセス集中ショップは両方の空きが必要 なお、レートリミッタが制限と判定したときはトークンを消費しないようにしています。これは、弾いたリクエストでトークンを消費してしまうと本来なら通せたはずの後続のリクエストにまで影響が及んでしまうからです。 アクセス集中ショップをどう見分けるか アクセス集中ショップをどう判定するか、という点にも少し工夫が要りました。 素朴に閾値だけで判定すると、ショップの状態が閾値の前後で行ったり来たりしてしまい、挙動が安定しません。 そこで、ショップごとに単位時間あたりの決済リクエスト回数をカウントし、一定以上に達したらアクセス集中ショップと判定するようにしました。さらに、一度アクセス集中ショップと判定されたらしばらくはそのフラグを引き継ぐクールダウン期間を設けています。このクールダウン時間は、実際の過去のリクエストの状況を分析して決定しました。 Off → Observe → Enforce、3つのモードで段階的に出す 決済という事故が許されない経路に新しい制御、それも決済を能動的に遮断する機能を入れるわけですから、リリースの手順は慎重に検討しました。いきなり遮断するようなことはせず、フィーチャーフラグで3つのモードを切り替えられるようにして段階的にリリースできるように設計しました。具体的には、以下の3つのモードを管理画面から瞬時に切り替えられるような作りにしました。 Off ：完全な機能OFF状態。Redisにも通信しない、完全に無害な状態で本番に導入する。 Observe ：制限の判定はするが、制限はせずに全て許可する状態。「もし遮断していたら、いつ・どれだけ弾いていたか」を記録するだけにとどめる。このモードで誤って制限してしまうケースがないかを本番のデータで実測する。 Enforce ：制限の判定を行い、遮断も実行する状態。この状態で初めて本格的なレートリミッタの挙動がリリースされる。 万が一 Enforce で誤った遮断が起きても管理画面からフラグを即座にObserveへ戻すだけで、デプロイなしに誤遮断を解除することができます。さらに、この状態の計測自体は継続することで、何が起こったか後から分析できるように情報を残すこともできます。この「デプロイなしで止められる」「後から分析できるデータも残せる」という安心感は、本番に投入していくうえで大きく効いたと感じています。 レートリミッタで決済を止めないようにする 当然ですが、流量制御のために導入したレートリミッタ自身が新たな障害点になってしまっては本末転倒です。レートリミッタの不調で決済全体が止まってしまうのは、避けたい事態の中でも最悪の部類だといえます。 そこでRedisに異常があったときは判定をスキップして決済を通すfail-open方針にしました。「厳密に上限を守ること」よりも「決済を止めないこと」を優先する、という価値判断です。あわせて、判定にかけるタイムアウトはごく短期間に設定し、Redisが重くなったときも素早く安全側に倒れて、決済の本流の足を引っ張らないようにしています。 すべての判定を観測する 最後は観測の話です。すべての判定経路で、レートリミッタの呼び出し毎に1つのイベントを記録するようにしました。 記録しているのは、どのモードで動いていたか（Off / Observe / Enforce）、許可したのか制限したのか、制限判定の理由（グローバルバケットで弾いたのか、アクセス集中ショップ用バケットで弾いたのか）、処理にかかった所要時間、そしてfail-openが発生したかどうか、といった情報です。 特に Observe モードで記録した「もし遮断していたら弾いていたはずの量」は、Enforce へ昇格してよいかを判断するための一次データになります。また、レートリミッタが事前に遮断したものと、決済処理そのものが失敗したものとでは意味がまったく異なるので、ログには専用のタグを付けて、両者をはっきり区別できるようにしています。 おわりに 今回は、購入時のクレジットカード決済に流量制御を導入した話をご紹介しました。 やったことを一言でまとめると、 特定のアクセス集中ショップに購入が集中しても、その他のショップに影響が及ばないように、限られた決済の流量を能動的に制御することで受け止められるようにした 、ということになります。決済の流量を1つのグローバルカウンタで測って制御しつつ、アクセス集中ショップ用バケットによってアクセス集中ショップの流量に少しだけきつめの制限を設け、その他のショップの決済分を引き算で残す。そして3つのモードで安全に段階リリースし、万が一レートリミッタ自身が不調になってもfail-openで決済を止めない。 ひとつ補足しておきたいのは、これは「決済の処理能力がこれ以上伸ばせないから絞っている」という話ではない、ということです。実は、既存の実装を整理することで、レートリミッタを導入してもなお、単位時間あたりに捌ける決済の流量そのものはむしろ増えています。だからこそ今回、思い切ってアクセス集中ショップに制限を設けるという判断ができました。レートリミッタ導入前と比べても、アクセス集中ショップが単位時間あたりに購入できる流量はむしろ増えているのです。 そのうえで、限られたリソースのバランスを短期的に取るための手段として、レートリミッタによる制御を併用している、という位置づけです。一部のショップへのアクセス集中でシステム全体が不安定になれば、影響を受けるのはほかのショップだけでなく、アクセスが集中しているショップ自身も同じです。全体を安定して動かし続けることこそが、結果的にすべてのショップの購入機会を守ることにつながると考えています。 もちろん、ここで満足しているわけではありません。処理能力そのものの引き上げや、ほかの選択肢の検討も含めて、「どのショップでも、いつでも買いやすいカート」を目指して改善を続けていきます。 派手な機能ではありませんが、「どのショップでも、いつでも購入できる」という当たり前を裏側で支える仕組みとして、地味に効いてくれるものになったのではないかと思っています。今回のような改善はユーザーの目に直接見えるものではありませんが、快適な購入体験のために、Checkout Reliabilityチームではこういった細やかな改善を引き続き積み重ねていきます。 BASE では、「どのショップでも、いつでも購入できる」という当たり前を、こうした地道な設計と運用で支えていく仲間を募集しています。カートや決済まわりの信頼性に興味がある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

システム開発を進めるとき、開発会社から提示されたスケジュールを見ても「 この期間で本当に間に合うのか 」「 どこを確認すればよいのか 」と不安になる場面は少なくありません。 特に、初めて開発を発注する場合や、社内の関係部署をまとめる立場にある場合は、専門用語や工程の多さに戸惑いやすいものです。 システム開発のスケジュールは、単なる日程表ではなく、 納期・品質・予算を守るための設計図 です。 工程ごとの目的や期間の目安を理解しておくと、開発会社との打ち合わせでも確認すべきポイントが見えやすくなります。 また、WBSやガントチャートを使って作業を見える化すれば、関係者同士の認識ズレや承認遅れ、仕様変更による手戻りも防ぎやすくなります。 そこで今回は、 システム開発のスケジュールの考え方から作り方、遅延を防ぐ実践ポイントまで をわかりやすく整理しました！ 読み進めることで、無理のない開発計画を立て、社内説明や開発会社との調整に活かしやすくなります。 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",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド システム開発のスケジュールは何のために作るのかを押さえよう！ システム開発のスケジュールは、開発開始日と納品日を並べるだけのものではありません。 要件定義、設計、開発、テスト、リリース、運用保守といった複数の工程を、どの順番で、誰が、いつまでに進めるのかを明確にするために作ります。 スケジュールが曖昧なまま進むと、現在の進捗や次に必要な判断が見えにくくなり、会議のたびに状況確認から始めることになりがちです。 特に発注側と開発側で認識がズレていると、完成イメージや優先順位が食い違い、後半で大きな手戻りが発生する可能性があります。 そのため、スケジュールは 関係者全員が同じ地図を見ながら進むための共通言語 として考えることが大切です。 また、システム開発では想定外の仕様変更や外部サービスとの調整、テストでの不具合発見などが起こることもあります。 事前にマイルストーンや確認タイミングを決めておけば、トラブルが起きたときも影響範囲を把握し、早めに立て直しやすくなります。 計画通りに進めることだけでなく、 変化に対応できる状態を作ること が、スケジュール管理の本質です。 全体像を見える化して、プロジェクトの迷子を防ぐ！ システム開発では、最初にプロジェクト全体の流れを見える化することが重要です。 要件定義で作るものを決め、設計で具体的な仕様に落とし込み、開発で形にし、テストで品質を確認し、リリースで実際に使える状態にしていきます。 この流れが見えていないと、どの工程で何を判断すべきかがわからず、開発会社に任せきりになりやすくなります。 一方で、工程ごとの役割や成果物が整理されていれば、発注側も「 今は何を確認する段階なのか 」を把握しやすくなります。 特に社内説明や稟議が必要な場合、全体像を示せるスケジュールがあると、上司や関係部署にもプロジェクトの進め方を説明しやすくなります。 スケジュールは、開発会社の管理資料であると同時に、 発注側が安心して意思決定するための資料 でもあります。 そのため、工程名だけでなく、各工程で決めること、確認すること、完了条件まで含めて整理することが大切です。 プロジェクトの迷子を防ぐには、最初に全体像を共有し、 関係者全員が同じゴールを見られる状態 を作る必要があります。 関係者の認識ズレを減らして、手戻りを防ぐ！ システム開発でよくあるトラブルの一つが、関係者同士の認識ズレです。 開発会社は仕様通りに作ったつもりでも、発注側や現場部門が想定していた使い方と違えば、「 思っていたものと違う 」という問題が起こります。 このズレを防ぐには、スケジュールの中に 確認タイミング・承認期限・成果物のレビュー を組み込むことが欠かせません。 たとえば、要件定義書や画面設計書を確認する日、現場担当者にレビューしてもらう期間、上司が承認する期限を明確にしておくと、確認漏れを防ぎやすくなります。 発注側の作業は、開発そのものではなくても、プロジェクト全体の進行に大きな影響を与えます。 資料提供が遅れたり、承認者が不在だったり、社内確認が長引いたり すると、その分だけ開発スケジュールも後ろ倒しになります。 だからこそ、発注側も「 いつまでに何を確認するのか 」をスケジュール上で明確にすることが重要です。 認識ズレを早い段階で見つけられれば 、修正の負担も小さくなり、納期や品質への影響も抑えやすくなります。 トラブルが起きても、早く立て直せる状態を作る！ システム開発では、どれだけ丁寧に計画しても、想定外の問題が起こることがあります。 仕様変更、追加要望、外部サービスとの連携不具合、テストでのバグ発見、担当者の急な不在など、遅延につながる要因はさまざまです。 大切なのは、トラブルをゼロにすることではなく、 発生したときに早く気づき、早く対処できる状態を作ること です。 そのためには、スケジュールの中にマイルストーンを設定し、 各工程の節目で進捗や成果物を確認 する必要があります。 マイルストーンがあれば、遅れがどこで発生しているのか、次の工程にどれくらい影響するのかを判断しやすくなります。 また、各工程に 一定のバッファを持たせておく ことで、小さな遅れを吸収しやすくなります。 バッファは余った時間ではなく、品質確認やリスク対応のために必要な時間です。 変化に対応できるスケジュールを作っておく ことで、トラブルが起きてもプロジェクト全体を大きく崩さずに進めやすくなります。 工程ごとの期間目安を知って、無理のない計画を立てよう！ システム開発のスケジュールを考えるうえで、まず押さえたいのが 工程ごとの期間目安 です。 一般的な開発では、 要件定義、設計、開発、テスト、リリース準備 という流れで進みます。 ただし、必要な期間はシステムの規模、機能数、画面数、外部連携の有無、関係者の人数、承認フローの複雑さによって 大きく変わります 。 小規模な業務ツールであれば数か月で進むこともありますが、基幹システムや外部サービス連携を含む開発では半年以上かかるケースもあります。 重要なのは、単純に「短くできるか」ではなく、各工程に必要な確認や修正の時間を含めて、 現実的に進められるかどうか です。 特に要件定義やテストの期間を短くしすぎると、後工程で手戻りが増えたり、リリース後の不具合につながったりする可能性があります。 スケジュールを見るときは、開発期間だけでなく、 設計やテスト、発注側の確認期間まで含まれているかを確認することが大切 です。 無理のない計画を立てるには、工程ごとの目的を理解し、どこに時間をかけるべきかを判断できる状態を目指しましょう。 要件定義では、作りたいものと優先順位を明確にする！ 要件定義は、システム開発の土台になる工程です。 ここでは、 システムを作る目的、解決したい業務課題、必要な機能、利用者、業務フロー、セキュリティや処理速度などの非機能要件 を整理します。 要件定義が曖昧なまま進むと、設計や開発の途中で「この機能も必要だった」「この業務パターンを考えていなかった」といった問題が起こりやすくなります。 その結果、追加開発や仕様変更が発生し、スケジュール全体が圧迫される可能性があります。 要件定義の期間は、システム規模や関係者数によって変わりますが、数週間から数か月程度を見込む考え方が現実的です。 発注側は、現場の要望、既存の業務資料、現在使っているシステムの課題、必要な帳票やデータ項目などを事前に整理しておくと、打ち合わせがスムーズになります。 また、すべての要望を同じ優先度で扱うのではなく、 必須機能 と できれば欲しい機能 を分けることも重要です。 優先順位が明確になれば、納期や予算に合わせて開発範囲を調整しやすくなります。 設計では、画面・機能・データの具体像を固める！ 設計は、要件定義で決めた内容を、 実際に開発できる形へ落とし込む工程 です。 主に、画面構成、操作方法、機能仕様、データベース構造、外部サービスとの連携方法、権限設定などを具体化します。 外部設計では、 利用者から見える画面や操作の流れを整理 し、内部設計では、 システム内部の処理やデータの持ち方 を決めていきます。 この工程で確認が不足すると、開発後に「ボタンの位置が使いにくい」「必要な項目が足りない」「現場の業務手順と合わない」といった問題が起こりやすくなります。 そのため、発注側は画面イメージや業務フローを確認し、実際に使う現場担当者にもレビューしてもらうことが大切です。 設計書は専門的に見えることもありますが、発注側が確認すべきポイントは、実際の業務で無理なく使えるか、必要な情報が抜けていないか、操作が複雑すぎないかです。 設計段階で合意を取っておけば、後の開発やテストが進めやすくなります。 完成後の手戻りを減らすには、 設計の段階で「使う人の視点」を入れることが重要 です。 開発・テスト・リリースでは、品質確認の時間をしっかり確保する！ 開発工程では、設計書をもとにプログラミングや環境構築を進め、システムを実際に動く形にしていきます。 機能数や技術的な難易度、外部サービスとの連携有無によって、必要な期間は大きく変わります。 ただし、スケジュールを考えるときに注意したいのは、 開発が終わればすぐにリリースできるわけではないという点 です。 開発後には、単体テスト、結合テスト、総合テスト、受け入れテストなどを通じて、 不具合や仕様とのズレを確認 します。 テスト期間が短すぎると、不具合を見つけきれないまま本番運用に入ってしまい、リリース後のトラブルにつながる可能性があります。 特に受け入れテストでは、発注側も実際の業務に近いシナリオで操作し、 現場で問題なく使えるかを確認する必要 があります。 リリース前には、データ移行、操作マニュアル、社内周知、問い合わせ対応体制、万が一の切り戻し手順も確認しておくと安心です。 品質を守るには、開発期間だけでなく、 テストとリリース準備の時間 をしっかり確保することが欠かせません。 スケジュール表はWBSとガントチャートでわかりやすく作ろう！ システム開発のスケジュール表を作るときは、いきなり日付を並べるのではなく、まず 必要な作業を分解することが大切 です。 この作業分解に役立つのが WBS です。 WBSは、 プロジェクトで必要な作業を細かく洗い出し、抜け漏れを防ぐための考え方 です。 一方、 ガントチャート は、洗い出した作業を時間軸に並べ、開始日、終了日、担当者、進捗状況を見える化するために使います。 つまり、WBSで「 何をするか 」を整理し、ガントチャートで「 いつ進めるか 」を確認できる形にする流れが基本です。 発注側にとっても、WBSやガントチャートがあると、開発会社の作業だけでなく、自社側の確認や承認のタイミングも把握しやすくなります。 特に、資料提供、レビュー、社内調整、上司の承認などは、発注側のタスクとしてスケジュールに入れておく必要があります。 スケジュール表は作って終わりではなく、進捗を確認しながら更新し、関係者で共有し続けることが重要です。 まずは必要な作業を洗い出して、抜け漏れを防ぐ！ スケジュール作成の第一歩は、プロジェクトに必要な作業を できるだけ具体的に洗い出すこと です。 最初は、 要件定義、設計、開発、テスト、リリース準備 といった大きな工程に分けます。 次に、それぞれの工程をさらに細かいタスクに分解し、どの作業が完了すれば次に進めるのかを明確にします。 たとえば要件定義であれば、 課題整理、機能一覧作成、業務フロー確認、非機能要件の確認、関係者レビュー などに分けられます。 タスクごとに 成果物、担当者、確認者、期限 を設定しておくと、進捗管理がしやすくなります。 ここで忘れやすいのが、発注側の作業です。 資料提供、現場ヒアリング、設計レビュー、受け入れテスト、承認手続き、社内周知 なども、プロジェクトを進めるうえで欠かせないタスクです。 作業の洗い出しを開発会社任せにせず、双方で確認することで、後から「 誰が対応する予定だったのか 」と迷う場面を減らせます。 作業の順番と依存関係を決めて、現実的な流れにする！ タスクを洗い出したら、次に 作業の順番と依存関係を整理 します。 システム開発では、ある作業が終わらないと次の作業に進めない場面が多くあります。 たとえば、要件定義が固まっていない状態で設計や開発を進めると、 後から仕様変更が発生し、修正工数が増える可能性 があります。 また外部サービスとの連携がある場合、 API仕様の確認や審査、テスト環境の準備などが遅れる と、開発全体に影響することがあります。 このように、遅れると 全体納期に影響しやすい作業を把握しておくことが大切 です。 特に、社内承認や関係部署の確認など、開発会社だけでは進められない作業もスケジュールに含める必要があります。 休日、繁忙期、担当者の不在、経営会議の日程、外部企業の回答待ち なども、現実的なスケジュールを作るうえで見落とせない要素です。 作業をただ並べるのではなく、どの順番で進めれば無理がないかを考えることで、実行しやすい計画になります。 WBSとガントチャートを使い分けて、進捗を見える化する！ WBSとガントチャートは、どちらもスケジュール管理に役立つ手法ですが、役割が異なります。 WBSは、プロジェクトに必要な作業を分解し、タスクの抜け漏れを防ぐため に使います。 一方で、ガントチャートは、 各タスクの開始日、終了日、担当者、進捗状況を時間軸で確認するため に使います。 WBSで作業を整理してからガントチャートに落とし込む と、何をいつまでに進めるべきかがわかりやすくなります。 小規模なプロジェクトであれば、Excelやスプレッドシートでも十分に管理できます。 一方、関係者が多い場合や、複数部署、開発会社、外部パートナーが関わる場合は、 プロジェクト管理ツールを使うと共有や更新がしやすくなります 。 重要なのは、ツールの種類よりも、関係者が同じ情報を見て、進捗や遅れをすぐに確認できる状態を作ることです。 進捗が見える化されていれば、遅れが小さいうちに対策を打ちやすくなります。 遅れないスケジュールにするための実践ポイントを押さえよう！ システム開発のスケジュールを遅らせないためには、最初から 「予定通りに進まない可能性」を織り込んでおくことが大切 です。 開発中には、仕様変更、追加要望、確認待ち、テストでの不具合、外部サービスの都合など、さまざまな遅延要因が発生します。 そのため、余裕のないスケジュールを組むと、小さな遅れが後半に積み重なり、納期や品質に大きな影響を与えやすくなります。 遅れにくい計画にするには、 各工程にバッファを入れ、重要な節目にマイルストーンを設定すること が効果的です。 また、 仕様変更や承認に関するルールを事前に決めておく ことで、判断の遅れや認識ズレを減らせます。 発注側としては、開発会社から提示されたスケジュールをそのまま受け取るのではなく、工程や確認期間、テスト期間が十分に含まれているかを確認することが重要です。 スケジュールの妥当性を判断できれば、社内説明もしやすくなり、プロジェクト全体を安心して進めやすくなります。 遅延を防ぐポイントは、細かな管理よりも、 早く気づき、早く相談し、早く判断できる仕組みを作ること です。 バッファとマイルストーンを入れて、遅延に強い計画にする！ システム開発では、最初の見積もり通りにすべてが進むとは限りません。 そのため、各工程の終わりには確認期間や修正期間を入れ、余裕のない日程にしないことが大切です。 この余裕が バッファ です。 バッファは単なる予備日ではなく、 品質確認や想定外の調整に対応するための重要な時間 です。 特に、 要件定義後の確認、設計承認、テスト後の修正、リリース前の最終確認 には、一定の余裕を持たせる必要があります。 また、プロジェクトの節目には マイルストーン を設定します。 要件定義完了、設計承認、開発完了、テスト開始、リリース判定などの節目を決めておくと、進捗が順調かどうかを判断しやすくなります。 マイルストーンごとに完了条件を明確にしておけば 、曖昧なまま次工程に進むことを防ぎやすくなります。 遅延に強いスケジュールとは、単に長めに期間を取ることではなく、 確認と判断のタイミングが明確な計画 です。 仕様変更と承認遅れを減らすルールを作る！ システム開発で遅延が起こりやすい原因の一つが、仕様変更です。 開発が進んでから追加要望が出ると、設計や実装、テストのやり直しが必要になり、納期や費用に影響する可能性があります。 仕様変更を完全になくすことは難しいため、事前に 変更の受付ルール を決めておくことが重要です。 たとえば、追加要望が出た場合は、 納期、費用、品質、他機能への影響 を確認したうえで、対応するかどうかを判断する流れにします。 また、 承認遅れもスケジュールに大きく影響します 。 承認者、確認期限、判断基準が曖昧なままだと、設計書やテスト結果の確認が止まり、開発会社側の作業も進めにくくなります。 そのため、 誰が最終判断をするのか、何日以内に返答するのか、判断に必要な資料は何かを事前に決めておくことが大切 です。 議事録や決定事項を残しておけば、後から認識のズレが起こりにくくなります。 初回リリースに必要な機能と、後から追加できる機能を分けることも、納期を守るうえで有効です。 開発会社に確認すべきポイントを押さえて、妥当性を判断する！ 開発会社からスケジュールを提示されたら、まず工程が一通り含まれているかを確認します。 要件定義、設計、開発、テスト、リリース準備 が入っているかは、最初に見るべきポイントです。 次に、 発注側の確認や承認、資料提供の期間 がスケジュールに含まれているかを確認します。 開発会社の作業だけで日程が組まれている場合、実際には社内確認の時間が足りず、後から遅れが発生する可能性があります。 また、テスト期間や修正期間が短すぎないかも重要です。 テスト工程が極端に短い場合、品質確認が不十分になり、リリース後のトラブルにつながるリスクがあります。 さらに、遅延が起きた場合の報告方法、進捗共有の頻度、判断が必要なときの連絡フローも確認しておくと安心です。 複数社の見積もりや工程表を比較するときは、金額だけでなく、 工程の粒度、リスク説明の丁寧さ、発注側の作業まで考慮されているか を見ることが大切です。 スケジュールの妥当性を判断できれば、開発会社と対等に話しながら、現実的な計画に調整しやすくなります。 まとめ システム開発のスケジュールは、単なる工程表ではなく、納期・品質・予算を守るための共通認識づくりです。 要件定義、設計、開発、テスト、リリース準備という流れを理解しておくことで、各工程で何を確認すべきかが見えやすくなります。 特に、要件定義やテストの期間を短くしすぎると、後から手戻りや不具合につながる可能性があるため、無理のない計画を立てることが大切です。 スケジュール表を作る際は、WBSで必要な作業を洗い出し、ガントチャートで日程や進捗を見える化すると管理しやすくなります。 また、発注側の資料提供、レビュー、承認、社内調整もスケジュールに含めることで、実態に合った計画になりやすくなります。 遅延を防ぐには、バッファ、マイルストーン、仕様変更ルール、承認ルールを事前に決めておくことが重要です。 開発会社から提示されたスケジュールを見るときは、工程の抜け漏れ、確認期間、テスト期間、遅延時の対応方法を一つずつ確認しましょう。 システム開発のスケジュールを正しく理解できれば、社内説明や開発会社との調整に自信を持ちやすくなり、プロジェクトをより安心して進められます。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

LINEヤフーの技術カンファレンス「Tech-Verse 2026」の公式記事です。AIでのコーディングで難しいのは、もはやコードを出すこと自体ではありません。課題はその周辺にあります。意図を正確な仕...