本文へスキップ

開発手法・プロセスの用語

14語

用語一覧

  • アジャイル開発

    開発対象を最初にすべては確定させず、数週間ごとに動作するものを構築して確認し、優先順位を再検討しながら開発を継続する考え方です。発注側が継続して関与する手間がかかります。

    成熟度: 定番
  • Webアプリケーション

    利用者側の導入と更新の作業は少ない一方、サーバーの運用、ブラウザへの対応、権限確認が継続して必要になる、ブラウザで使う業務ソフトウェアです。

    成熟度: 定番
  • ウォーターフォール開発

    要件定義、設計、実装、テストの工程を順に1回ずつ実施し、前の工程を確定させてから次へ移行する開発の進め方です。何を開発するかを開始前に決め切れる案件向けで、途中の変更には追加の費用と期間がかかります。

    成熟度: 安定
  • 受け入れテスト

    完成したシステムを発注側の業務担当者が実際の業務の流れどおりに操作し、業務で利用できる状態かを確認するテストです。開発会社のテストでは発見できない業務との不一致を、稼働前に検出します。

    成熟度: 定番
  • 技術的負債

    ソフトウェアの作りに改善の余地があり、以後の変更に余分な手間がかかる状態を借金にたとえた言葉です。開発の速度を優先して意図して負うことも、知識不足や運用後の発見で生じることもあります。

    成熟度: 定番
  • コーディングエージェント

    コーディングエージェントは、結果を確認しながら、ソースコードの読み取りと書き込みから、コマンドとテストの実行までを自律的に反復するAIです。人が1手ずつ実行しなくても作業が進むため、委任する範囲、レビュー、権限、機密情報の扱いを先に決定します。

    成熟度: 普及中
  • CI/CD

    ソースコードの変更をこまめに統合し、自動でテストして、いつでも本番に反映できる状態を維持する開発の進め方とその仕組みです。リリースが迅速になるほか不具合を混入させたときに前のバージョンへ切り戻しやすくなります。

    成熟度: 定番
  • スクラム

    1か月以内の短い期間ごとに動作するものを構築し、その結果をもとに次の計画を再検討するチーム開発の枠組みです。発注側からプロダクトオーナーを選出し、毎回の優先順位を決定し続ける負荷を計画に含める必要があります。

    成熟度: 定番
  • バイブコーディング

    生成AIに自然言語で指示し、出力されたコードを精査せずに採用して動作するものを作成する開発の仕方です。誰もコードを理解していないため、使い捨ての試作には有効ですが、顧客データを処理する本番や長期の保守では不具合の検知と改修が困難になります。

    成熟度: 登場期
  • PoC

    新規の技術や仕組みが自社の業務とデータで狙いどおりに機能するかを、本格的な開発の前に小規模な仕組みで検証する取り組みです。開始する前に、何が分かれば次の段階へ移行し、何なら中止するかを定めておきます。

    成熟度: 定番
  • 非機能要件

    システムに求める条件のうち、停止しにくさ、速度、安全さ、保守のしやすさなど機能以外の水準を定めたものです。水準を向上させるほど費用が大幅に増加するため、業務への影響から必要な分だけを定めます。

    成熟度: 定番
  • 並行稼働

    新旧のシステムを一定期間同時に稼働させ、同じ業務を両方で処理して結果を比較する切替の対策です。対象と期間を限定しないと現場の負担と費用が増大します。

    成熟度: 定番
  • 要件定義

    新システムで何をどこまで実現するかを、開発の前に決定して文書化する工程です。決定する責任は発注側にあり、範囲が確定していないなら要件定義だけを先に別契約で締結するほうが、見積もりの前提が発注側と開発会社で一致しない事態を防止しやすいです。

    成熟度: 定番
  • リバースエンジニアリング

    完成したソフトウェアや製品を解析して、仕組みや仕様を把握する手法です。実施前に権利・契約と調査範囲を確認し、結果は実際の挙動と比較して検証する必要があります。

    成熟度: 安定
用語集の一覧へ

お問合せ

事業の課題や技術的な悩みなどどんなことでもお聞かせください

お問合せ