開発手法の一覧【2026年版】｜発注者が選ぶ判断軸と比較表

「提案書にウォーターフォール、アジャイル、スクラムと並んでいるが、どれが何を指すのか整理できない」——発注側の担当者から、こうした相談をよく受けます。手法名を調べ始めると記事が長く、工程やイベントの細部まで出てくる。いま必要なのは深掘りではなく、一覧で地図を持つこと、という段階です。

結論から言うと、開発手法は「どれが一番よいか」ではなく、要件の固さ・変更の起きやすさ・発注者の関与・契約形態の相性で選ぶものです。アジャイルは思想、スクラムやカンバンはその枠組み、ウォーターフォールは工程を一方向に進める進め方——この階層を押さえれば、提案書の言葉はかなり読みやすくなります。

地図を持ったうえで自社案件に当てはめれば、流行に流されず稟議用の一文が書けます。逆に、手法名だけを追うと「名ばかりスクラム」や「請負なのにアジャイル」といった噛み合わせの悪さが残ります。失敗のもとです。

本記事では、開発手法の一覧(階層と要点)、発注者が使う判断軸と比較表、自社への当てはめ(ハイブリッド・契約・当社の向き不向き)、よくある質問の順に解説します。ウォーターフォール・スクラム・アジャイルの詳しい進め方は、それぞれの専門記事へ案内します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。この記事を読み終えるころには、提案書の手法名を同じ土俵で比べ、自社に合う候補を絞れるはずです。

開発手法の一覧——提案書に出る名前を階層で整理する

提案書や見積もりの説明資料には、ウォーターフォール、アジャイル、スクラム、カンバンといった言葉が並びます。名前だけを横並びで覚えると混乱しやすいです。先に「階層」を押さえ、そのうえで各手法の要点を一覧にします。工程の細部や会議体の運用は、本記事では深掘りしません。必要なときだけ専門記事へ進んでください。

まず押さえる階層——思想・枠組み・補助・文化

発注者が迷う最大の理由は、手法名が同じレベルに見えてしまうことです。実務では、次の4層に分けて読むと整理が早くなります。

ポイントは、「アジャイルとスクラムは並列の選択肢ではない」ことです。アジャイルは思想、スクラムはその実践枠のひとつです。ウォーターフォールはアジャイル思想とは対照的な進め方の型として並びます。この関係を誤ると、比較表の列が崩れます。

代表的な手法の要点一覧(表)——各手法は1段落+深掘りリンク

ウォーターフォールは、前工程の成果を確定してから次へ進む前提の進め方です。総額と納期の説明がしやすい一方、後半の変更は手戻りコストが大きくなります。工程ごとの発注者の決め事やV字モデルの話は、『ウォーターフォール開発』の記事にまとめています。

アジャイルは「一度決めた計画を守ること」より「変化に適応すること」を重視する思想です。外注では請負より準委任との相性がよく、発注側の継続関与が前提になります。契約・体制・失敗しやすい理由は『アジャイル開発 外注』の記事へどうぞ。

スクラムは、スプリントという時間の器と、プロダクトオーナー・スクラムマスター・開発者といった責任分担で反復を回す枠組みです。イベントや作成物の定義は『スクラムとは』の記事(スクラムガイド2020年版ベース)を参照してください。反復の長さそのものの意味は『イテレーションとは』の記事も補足になります。

カンバンは、ボード上で作業の流れと仕掛り上限を見える化する枠です。期日より流れの改善が主目的になりやすく、保守や問い合わせ対応と相性がよいです。スクラムのような固定長スプリントが必須ではありません。

XP(エクストリーム・プログラミング)は、テスト自動化やペアプログラミングなど、技術プラクティスで品質とフィードバックを早く回す枠です。発注者が「XPで」と宣言するより、チームの成熟度と品質方針の話として出てくることが多いです。

プロトタイピングは、動く試作品で認識のズレを早期に潰す補助です。画面や操作が重要な案件で効きます。試作品を本番コードに流用しすぎると品質が落ちるので、「確認用」と「本番用」の線引きが要注意です。

スパイラルは、機能やリスク単位で設計・実装・評価を繰り返し、各周回の冒頭でリスクを見直す進め方です。大規模で不確実性が高いときに候補になりますが、管理が複雑になりやすいのが実情です。

DevOpsは、開発手法の名前というより、開発と運用が分断されない文化と自動化(CI/CDなど)の話です。ウォーターフォールかアジャイルかと並べて「第3の手法」と誤解されがちですが、層が違います。

仮説を小さく検証する進め方そのものは、MVPの文脈でも整理できます。検証単位の切り方は『MVP開発』の記事を参照してください。

よくある混同——「スクラム=アジャイル」「DevOps=開発手法」

現場で繰り返し見る混同は次の3つです。

1. スクラムとアジャイルを同一視する。アジャイルを選んだあとに、スクラム・カンバン・XPのどれで回すかを決める、という順序が正しいです。
2. DevOpsをウォーターフォールやアジャイルと同列の「進め方」だと思う。DevOpsはリリース後の改善速度と組織の連携の話で、上流の進め方選択とは別レイヤーです。
3. 手法名を契約形態だと思う。ウォーターフォールだから必ず請負、アジャイルだから必ずラボ型、と機械的には決まりません。ただし相性はあるので、次章の判断軸で契約列を必ず見てください。

名前の一覧が揃ったら、次は「自社はどれを選ぶか」です。次章では発注者が使う判断軸と比較表に落とします。

発注者が使う判断軸——比較表で「どれを選ぶか」を決める

一覧で名前が分かっても、「自社の案件ではどれか」は別問題です。流行やベンダーの得意分野だけで決めると、あとから契約と運用が噛み合いません。発注者が見るべきなのは会議の名前ではなく、次の5つの判断軸です。人材紹介の現場でも、単価表より先に「何に払う契約か」を揃えるのと同じで、手法選びも構造から入るのが実情です。

判断軸5つ——要件の固さ、変更頻度、発注者の関与、成果の見え方、契約相性

要件の確定度・変更の見込み・発注者の関与・リスク(または納期固定)といった軸で点数化し、手法を振り分ける型は、実務で広く使われているものです。本記事も同じ発想で、イベント運用の細部には入りません。

手法×判断軸の比較表

読み方のコツは、「列を全部アジャイル寄りに寄せる必要はない」ことです。たとえば要件は固いが、画面の細部だけ試したいなら、本体はウォーターフォール、画面だけプロトタイピング、という補助の足し方が現実的です。逆に、要件が動くのに請負の一括固定だけを求めると、変更のたびに追加見積もりが積み上がります。

カンバンとスクラムの違いは、時間箱と役割の有無です。スクラムはスプリントと責任分担があり、カンバンは仕掛り制限と流れの可視化が中心です。保守チームが「スクラム」と名乗りつつ実態はカンバン、という提案も少なくありません。名前より、表の「関与」と「成果の見え方」の列で実態を確認してください。

稟議で使える一文——流行ではなく案件特性で選ぶ

社内説明では、次の型が使いやすいです。

• 「本案件は要件を着手前に確定でき、変更を抑える前提のため、ウォーターフォール型で総額と納期を固定する」
• 「本案件は仮説検証が主目的で仕様が動き得るため、アジャイル(スクラム)型とし、契約は準委任で優先順位を週次更新する」
• 「稟議上は総額の上限が必要だが実装は変化に強くしたいため、要件定義と受入は確定型、実装は反復型のハイブリッドとする」

「アジャイルが流行だから」だけでは稟議は通りにくいです。判断軸のどれが自社で高いかを先に書き、その結果として手法名を置く順序にしてください。

自社の数字がまだ粗い場合は、次章の4問に答えると候補が絞れます。手法名が決まったら、契約と体制を同じ机に並べてください。

自社案件への当てはめ——ハイブリッド、契約、当社の位置づけ

比較表は「地図」です。最後に必要なのは、自社案件への当てはめです。ここでは4つの質問、ハイブリッドの注意点、当社(TALENTBASE VIETNAM)のラボ型が向く案件・向かない案件を正直に書きます。手法名の押しつけはしません。

当てはめの4問——答えが出たら手法の候補が絞れる

次の4問に、高・中・低で答えてみてください。

1. 着手前に、作る範囲を文書で確定できるか(要件の固さ)
2. 開発中に仕様が動く可能性は高いか(変更頻度)
3. 発注側で、優先順位や受入を継続的に担える人はいるか(関与)
4. 対価は「完成した成果物」に払いたいか、「期間の体制」に払いたいか(契約の好み)

読み方の例です。1が高く2が低く4が成果物なら、ウォーターフォール×請負が第一候補です。1が低く2が高く3が高く4が体制なら、アジャイル(スクラム等)×準委任・ラボ型が第一候補です。3が低いのにアジャイルだけ選ぶと、優先順位の空白で稼働だけが消費されます。失敗のもとです。

3が弱い場合の選択肢は、(a)社内にPO役を置く、(b)日本人PMやブリッジが優先順位の整理を支援する体制にする、(c)そもそも反復型を選ばない、の3つです。手法を変える前に、関与の設計を先に決めてください。

ハイブリッド(上流確定+下流反復)の注意点

大規模案件では、要件定義と基本設計はウォーターフォール的に固め、実装以降を反復にするハイブリッドが増えています。稟議では総額・納期・受入基準を書きやすく、実装の細部は変化に強くできるためです。

ただし境界が曖昧だと、どちらにも失敗します。最低限、次を文書化してください。

• 上流で「変えないもの」(法令、会計ルール、外部IFの正本)と「下流で動かすもの」(画面の細部、優先機能)の線
• 契約の分け方(上流請負+下流準委任、など)。請負と準委任の違い自体は『準委任と請負の違い』の記事を参照
• 変更管理の入口(何が追加費用になるか)。仕様変更の線引きは別記事で扱っていますが、本記事では「手法と契約が矛盾していないか」だけを確認してください

ハイブリッドは万能ではありません。境界設計のコストを払えない小規模案件では、どちらか一方に寄せたほうが運用は単純です。

当社のラボ型が向く案件・向かない案件

当社(TALENTBASE VIETNAM)は、ベトナムのIT人財データベースから直接アサインするラボ型(準委任)を主に提供しています。公開単価の目安は、実務3年相当で1,500USD(約22.5万円、1USD=150円換算)、最小構成は日本人PMフロント+エンジニア2〜3人月で月額約80万円から、です。品質は設計レビュー、Gitのプルリクエストレビュー、リリース前ダブルチェックを標準にしています。

向く案件は、仕様が動き得る継続開発、SaaSや新規プロダクトのように週次で優先順位を見直す案件、内製に近い専属チームを持ちたい案件です。介護記録SaaSのCareViewerでは、日本語BrSE1名とフルスタック2名の体制で、週次の優先順位判断を回しながらコストを従来の半分以下に抑えた事例があります。声としては「想像以上にエンジニアのレベルが高い」という評価をいただいています。

向かない案件は、要件が完全に固まった単発の一括納品だけを求める案件、発注側で優先順位を一切担えない案件、機密データを海外に出せない制約が絶対の案件(設計自体の見直しが先)、です。この場合は請負中心の会社や国内体制を勧めることもあります。合わない案件には、その旨を率直にお伝えします。

ラボ型そのものの定義や費用は『ラボ型開発』の記事、オフショア全体の進め方は『オフショア開発の進め方』の記事へどうぞ。手法の地図を持ったうえで、体制の話に進むのが順序です。

開発手法の一覧でよくある質問

発注の相談で繰り返し出る疑問を5つにまとめました。一覧と比較表を読んだあとに残る論点——「一番よい手法はあるか」「スクラムとアジャイルの関係」「途中変更」「オフショア」「請負とアジャイル」——に絞っています。

Q1. 一番よい開発手法はありますか？

ありません。要件の固さ、変更の起きやすさ、発注者の関与、契約の好みで最適解が変わります。流行だけで選ぶと、運用と契約が噛み合わない原因になります。

Q2. スクラムとアジャイルはどう違いますか？

アジャイルは思想・価値観、スクラムはその実践枠のひとつです。カンバンやXPもアジャイル配下の枠として並びます。詳細は『スクラムとは』の記事と『アジャイル開発 外注』の記事を参照してください。

Q3. 開発の途中で手法を変えてもよいですか？

変えられますが、契約と体制の見直しがセットです。請負のままアジャイル運用だけを足すと、変更のたびに追加費用でもめやすいです。変更管理の入口と、準委任への切り替え可否を先に決めてください。

Q4. オフショアでもアジャイルやスクラムは使えますか？

使えます。ただし発注側の優先順位判断と、時差を踏まえた非同期の進め方が前提です。名ばかりのイベント消化は避け、週次のレビューと文書化された決定事項を優先してください。当社は時差2時間のベトナム拠点で、日本人PMフロントのラボ型を提供しています。

Q5. 請負契約のままアジャイルは可能か？

可能だが摩擦が大きい。完成義務と仕様固定が前提の請負に、仕様が動く反復を載せるため。短期の試作範囲だけ請負で切り出す、本体は準委任にする、など境界設計が現実解。

まとめ: 一覧で地図を持ち、判断軸で選び、詳細は各手法の記事へ

開発手法の名前は、思想・枠組み・補助・文化の階層で読むと整理できます。ウォーターフォール、アジャイル、スクラム、カンバン、プロトタイピング、スパイラル、DevOps、ハイブリッド——優劣ではなく、案件特性との対応関係です。

発注者が使う判断軸は、要件の固さ、変更頻度、発注者の関与、成果の見え方、契約相性の5つです。比較表で候補を絞り、ハイブリッドにするなら境界と契約の分け方まで書いてください。詳しい工程やイベントは、ウォーターフォール開発とはやスクラムとは、アジャイル開発の外注へ進むのが効率的です。

現在の体制と要件をお聞かせいただければ、合う手法と契約の組み合わせを、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。