開発プロセス・方法論の用語
18語を収録しています。
あ
（あじゃいる／Agile）
計画を固定せず、短い区切りごとに作り直す前提で進める開発の考え方です。同じ語で呼ばれていても、現場の実態は組織ごとに大きく違います。
（いんふらすとらくちゃあずこーど／Infrastructure as Code）
サーバやネットワークの構成を記述に置き換え、変更をレビューできるようにする実践です。同じ定義から同じ環境を作れる状態を目指します。
（うぉーたーふぉーる／Waterfall Model）
工程を順に固定して進め、前には戻らない前提で計画を組む開発の進め方です。受託や業務システムの出身者の経歴書に頻出します。
（えーあいくどうかいはつ／AI-Driven Development）
人が書きAIが補助する形から、AIが書き人が検証する形へ反転させた開発の総称です。実装より、仕様の言語化と検証に時間が移ります。
（えーあいでぃーえるしー／AI-Driven Development Life Cycle）
人の手作業を前提に組まれた開発工程そのものを、AIの働き方に合わせて組み替える方法論です。AWSが2025年に公開しました。
（えすえるおー・えらーばじぇっと／SLO / Error Budget）
信頼性の目標と、その未達の許容枠をあらかじめ合意しておく仕組みです。障害のたびに力関係で優先順位が決まる状態を避けられます。
か
さ
（しーあいしーでぃー）
分岐した作業を毎日のように統合し、いつでも出せる状態を保ち続ける仕組みです。自動テストとビルドの自動化が前提になります。
（しふとれふと／Shift-Left Testing）
後の工程ほど修正の費用が大きくなるため、検査を前方へ動かす考え方です。テストの量ではなく、置く位置を変える話になります。
（しようくどうかいはつ／Spec-Driven Development）
コードではなく仕様を正本に置き、変更は仕様側から入れて再生成する進め方です。生成の入力を安定させることが狙いになります。
（すくらむ／Scrum）
誰が何に責任を持ち、いつ何を確認するかだけを定めた開発の枠組みです。具体的なやり方はチームに委ねられ、正本のガイドは意図的に薄く書かれています。
た
（ちーむとぽろじーず）
チームの型を4つ、チーム同士の関わり方を3つに絞って調整の経路を設計する枠組みです。近年の職種名を読み解く下敷きになります。
（てすとくどうかいはつ／Test-Driven Development）
テストを先に書くことで、何ができれば正しいのかを実装前に決める手順です。テストしやすい形を先に考えるため、設計にも影響します。
（でぶおぷす）
変更を出したい開発と、安定させたい運用の対立を、工程と分担の設計で解く取り組みです。自動化はその手段のひとつにあたります。
（とらんくべーすかいはつ／Trunk-Based Development）
分岐の寿命を1日から数日に抑え、統合の衝突が育つ前に解消してしまうブランチ戦略です。GitFlowとの対比で語られます。
は
（ぷろだくとれっどぐろーす／プロダクトレッドグロース）
営業ではなくプロダクト自身に顧客の獲得と定着を担わせる成長モデル。無料で使い始められる入口と、課金までの経路を製品側に組み込みます。
（ぺあぷろぐらみんぐ／Pair Programming）
書いている最中に判断を共有することで、設計のやり直しと知識の偏りを同時に防ぐ手法です。常時行うものではなく、場面を選んで使います。