開発プロセス・方法論の用語
37語を収録しています。
あ
（あじゃいる／Agile）
計画を固定せず、短い区切りごとに作り直す前提で進める開発の考え方です。同じ語で呼ばれていても、現場の実態は組織ごとに大きく違います。
（いんしでんとたいおう／Incident Response）
障害や攻撃が起きたときに、検知、影響の抑制、復旧、ふりかえりまでを決めた手順で進める活動。誰が何を判断するかを事前に決めておく点が要になります。
（いんふらすとらくちゃあずこーど／Infrastructure as Code）
サーバやネットワークの構成を記述に置き換え、変更をレビューできるようにする実践です。同じ定義から同じ環境を作れる状態を目指します。
（うぉーたーふぉーる／Waterfall Model）
工程を順に固定して進め、前には戻らない前提で計画を組む開発の進め方です。受託や業務システムの出身者の経歴書に頻出します。
（うけいれてすと／受入テスト／User Acceptance Test）
利用者や発注者が、合意した要件や業務上の受け入れ基準を満たすかを確認するテスト。検収との関係と合否の基準は、実施の前に定めておきます。
（うんよう、ほしゅ）
稼働中のシステムを安定して使える状態に保ち、監視、問い合わせ対応、障害対応、改修を継続する業務。担当の範囲は組織によって異なります。
（えーあいくどうかいはつ／AI-Driven Development）
人が書きAIが補助する形から、AIが書き人が検証する形へ反転させた開発の総称です。実装より、仕様の言語化と検証に時間が移ります。
（えーあいでぃーえるしー／AI-Driven Development Life Cycle）
人の手作業を前提に組まれた開発工程そのものを、AIの働き方に合わせて組み替える方法論です。AWSが2025年に公開しました。
（えすえるおー・えらーばじぇっと／SLO / Error Budget）
信頼性の目標と、その未達の許容枠をあらかじめ合意しておく仕組みです。障害のたびに力関係で優先順位が決まる状態を避けられます。
（えむえるおぷす／Machine Learning Operations）
機械学習モデルの開発から配備、監視、更新までを継続して回すための実践。データの変化で精度が変わりうるため、作り直す前提で仕組みを整えます。
（えむぶいぴー／Minimum Viable Product）
仮説を確かめるために必要な最小限の機能で作る製品。単に機能を削った試作ではなく、利用者から何を学ぶかを先に決めたうえで範囲を絞ります。
か
（かいはつせいさんせい／Developer Productivity）
開発組織が価値を届け続ける力を、速さ・品質・安定性・開発者の働きやすさから捉える考え方。個人の作業量ではなく、組織としての流れを見ます。
（かんばん／Kanban）
板の上で作業の流れを可視化し、同時進行の上限を決めて滞留を防ぐ手法です。運用や保守のように依頼が随時発生する仕事で選ばれます。
（きほんせっけい）
要件定義を受けて、画面や帳票、外部との連携など利用者から見える仕様を決める工程。発注側と合意する対象になる範囲で、外部設計とも呼ばれます。
（けつごうてすと／インテグレーションテスト／Integration Test）
複数のモジュールや外部サービスをつないだ状態での動作を確認するテスト。単体では表れない前提のずれや、データの受け渡しの不整合を見つける工程です。
（こーどれびゅー／Code Review）
実装を別の開発者が読み、欠陥の検出と設計判断の確認を行う工程です。実施しているかどうかではなく、基準と承認の条件まで示せるかで差が出ます。
さ
（しーあいしーでぃー）
分岐した作業を毎日のように統合し、いつでも出せる状態を保ち続ける仕組みです。自動テストとビルドの自動化が前提になります。
（しふとれふと／Shift-Left Testing）
後の工程ほど修正の費用が大きくなるため、検査を前方へ動かす考え方です。テストの量ではなく、置く位置を変える話になります。
（しようくどうかいはつ／Spec-Driven Development）
コードではなく仕様を正本に置き、変更は仕様側から入れて再生成する進め方です。生成の入力を安定させることが狙いになります。
（しょうさいせっけい）
基本設計で定めた仕様を、処理手順やモジュール構成、データ構造など実装できる粒度まで具体化する工程。対象の範囲と呼称は開発体制によって異なります。
（すくらむ／Scrum）
誰が何に責任を持ち、いつ何を確認するかだけを定めた開発の枠組みです。具体的なやり方はチームに委ねられ、正本のガイドは意図的に薄く書かれています。
（すぷりんと／Sprint）
スクラムで、価値を生む作業を行う固定長の期間。1か月以内で長さを一定に保ち、計画、レビュー、レトロスペクティブなどのイベントを含みます。
た
（たんたいてすと／ユニットテスト／Unit Test）
関数やクラスなど、ソフトウェアの小さな単位が期待どおり動くかを確認するテスト。自動化される例が多い一方、実施の方法は開発体制によって異なります。
（ちーむとぽろじーず）
チームの型を4つ、チーム同士の関わり方を3つに絞って調整の経路を設計する枠組みです。近年の職種名を読み解く下敷きになります。
（てすとくどうかいはつ／Test-Driven Development）
テストを先に書くことで、何ができれば正しいのかを実装前に決める手順です。テストしやすい形を先に考えるため、設計にも影響します。
（てすとじどうか／Test Automation）
人が繰り返し行う確認を、実行可能なコードとして残す取り組み。変更のたびに同じ検査を走らせ、壊れた箇所を早く見つける狙いがあります。
（でぶおぷす）
変更を出したい開発と、安定させたい運用の対立を、工程と分担の設計で解く取り組みです。自動化はその手段のひとつにあたります。
（とらんくべーすかいはつ／Trunk-Based Development）
分岐の寿命を1日から数日に抑え、統合の衝突が育つ前に解消してしまうブランチ戦略です。GitFlowとの対比で語られます。
は
（ぴーおーしー／概念実証／Proof of Concept）
考えた方法が実際に成り立つかを、小さく作って確かめる活動。本開発に入る前に、技術や前提の不確かさを減らすために置く工程を指します。
（びーぴーあーる／業務プロセス改革／Business Process Re-engineering）
既存の業務手順を前提とせず、成果の向上を目的に業務プロセスを根本から見直して再設計する取り組み。組織や役割の変更を伴う場合があります。
（ふぃっとあんどぎゃっぷぶんせき／フィットアンドギャップ分析／Fit and Gap Analysis）
既製のシステムの標準機能と自社の業務要件を突き合わせ、合う部分と合わない部分を洗い出す作業。差の埋め方を決めるための材料を作ります。
（ふりかえり／振り返り／レトロスペクティブ／Retrospective）
一定期間の進め方をチームで見直し、次に試す改善策を決める場。KPTなどの手法を使い、個人の責任追及ではなく進め方と仕組みの改善を対象にします。
（ぷろだくとでぃすかばりー／Product Discovery）
作る価値があるかを、作り切る前に確かめる活動。開発と並行して進め、検証の結果を次に何を作るかの判断へ反映する進め方を指します。
（ぷろだくとばっくろぐ／Product Backlog）
プロダクトに必要な作業を優先順に並べた一覧。プロダクトオーナーが並び順に責任を負い、内容は開発の進行にあわせて更新されます。
（ぺあぷろぐらみんぐ／Pair Programming）
書いている最中に判断を共有することで、設計のやり直しと知識の偏りを同時に防ぐ手法です。常時行うものではなく、場面を選んで使います。
や
（ようけんていぎ／Requirements Definition）
作るものが満たすべき条件を、関係者から引き出して文書にまとめる工程。何を作るかを決める工程であり、どう作るかを決める設計とは分かれます。
ら
（りりーすかんり／リリースマネジメント／Release Management）
変更を本番環境へ反映する手順と可否を統制する活動。切り戻しの手順と、誰が承認するかを事前に決めておくことが前提になります。