ビジネスサイドのための IT 用語集

意思決定の場で使うための用語集です。意味だけでなく、得すること・損すること、使うかどうかの線引きまで解説します。

開発手法・プロセス

  • 開発手法・プロセス

    アジャイル開発

    Agile / アジャイル

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

  • 開発手法・プロセス

    ウォーターフォール開発

    Waterfall / ウォーターフォールモデル

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

  • 開発手法・プロセス

    技術的負債

    Technical Debt

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

  • 開発手法・プロセス

    CI/CD

    CICD / CI / CD / 継続的インテグレーション/継続的デリバリー / Continuous Integration / Continuous Delivery

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

  • 開発手法・プロセス

    スクラム

    Scrum / スクラム開発

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

  • 開発手法・プロセス

    PoC

    概念実証 / Proof of Concept

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

  • 開発手法・プロセス

    非機能要件

    NFR

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

  • 開発手法・プロセス

    要件定義

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

システム構成

  • システム構成

    ERP

    統合基幹業務システム / Enterprise Resource Planning

    会計、販売、購買、在庫などの基幹業務を1つのデータでつなぐ統合パッケージです。費用と期間は製品の標準に業務をどこまで適合させられるかで決定します。

  • システム構成

    API

    Application Programming Interface

    あるシステムの機能やデータを別のシステムが所定の手順で呼び出して利用できるようにした窓口です。CSVの受け渡しで十分な場面も多く、APIは開発後も保守が続きます。

  • システム構成

    SOA

    サービス指向アーキテクチャ / Service-Oriented Architecture

    業務の機能を他のシステムから呼び出せるサービスとして切り出し、組み合わせて全社のシステムを構築する設計の考え方です。ESBと呼ばれる連携製品を中央に配置する構成は変更のたびに中央の作業が必要になる問題を抱え、考え方はAPIに引き継がれました。既存の連携基盤は変更にかかる期間と担い手で評価します。

  • システム構成

    基幹システム

    SoR / System of Record

    販売、購買、在庫、生産、会計、人事給与など、取引を金額と数量で確定させて記録する業務のシステムです。基幹システムには変化の少ない処理だけを実装し、変化の速い機能は周辺のシステムで開発するほうがよいです。

  • システム構成

    マイクロサービス

    Microservices / マイクロサービスアーキテクチャ

    1つのシステムを機能ごとに独立して開発・リリースできる小さなサービスの集まりとして構築する設計の考え方です。多くの会社ではまだ不要で、まず1つのシステムで構築するほうがよいです。

  • システム構成

    モノリス

    Monolith / モノリシックアーキテクチャ / Monolithic Architecture

    全機能を1つのプログラムに集約し、一括で稼働・リリースする作り方です。多くの会社にとって標準の選択肢で、中を業務単位で区切った状態を維持すれば長く使い続けられます。

  • システム構成

    レガシーシステム

    Legacy System

    変更が困難になり、中身を分かる人も限られて、事業の足かせになったシステムです。保守費の膨張や、稼働させている基盤のサポート終了を伴うことが多いです。

  • システム構成

    ローコード・ノーコード

    ローコード / ノーコード / Low-code / No-code

    プログラムをほとんど書かずに、画面の構成要素や設定で業務アプリを開発する手法と開発基盤です。現場の社員が自ら開発する使い方と、開発会社が生産性を高めるために利用する使い方があります。

五十音順

あ

か

さ

は

ま

や

ら

お問合せ

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

お問合せ