TECH PLAY

プログラミング

むベント

マガゞン

技術ブログ

はじめに こんにちは、バック゚ンド゚ンゞニアの小笠原 @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でのコヌディングで難しいのは、もはやコヌドを出すこず自䜓ではありたせん。課題はその呚蟺にありたす。意図を正確な仕...

動画

曞籍