システム・ソフトウェア開発においては、特殊な用語が多く使われます。
ユーザ企業にとっては、なじみがない用語も多いので、ベンダ企業が当たり前に使うので「それって、どういう意味ですか」と聞きづらいこともあるかもしれません。
そこで、今回は、システム開発の現場で、よく使われる用語を解説します。
ソフトウェアの開発規模を表す単位の1つで、1人のエンジニアが1日要する作業量を1人日、1か月要する作業量を1人月と呼びます。
10人のエンジニアがフルタイムで作業して6か月かかる作業は60人月ということになります。
開発費用を算出には、この人日、人月から考えることが多いのです。
ソフトウェア開発手法の1つであって、開発作業をいくつかの工程に分けて(「フェーズ」)、各工程での成果を確認し、それが終わったら、次の工程へと進めていく方法です。
大規模なシステム開発では、数多くの工程があるので、一つずつの工程が、きちんと完了するのを確認して、先に進む必要があります。
基幹系情報システムの多くは、この手法を用いて開発されています。
一般的には、要件定義、基本設計、詳細設計、プログラム開発から単体テスト、結合テスト、システムテスト、運用テスト、運用・保守といった開発工程に区分されます。
ウォーターフォールモデルと異なり、プロジェクトの詳細な計画を作成せず、成果物やドキュメント等も詳細に定義しないまま作業が進められることを特徴としています。
ドキュメント作成作業を省略する代わりに、2週間あるいは1か月といったごく短い周期で開発、検証といった作業を繰り返しながらにのサイクルを「イテレーション」と呼ぶ)、システムを作り上げていくことです。
そのため、ユーザからの仕様変更や、要件の認識齟齬等を反映しやすいので、柔軟な開発ができることが特徴です。
RequestforProposalの略で「提案依頼書」と訳されます。
ユーザが、自社のシステム開発を委託するベンダを選ぶために、ペンダからの提案書の提出を求める文書です。
「要件定義」は、簡単にいうと、どういうシステムを開発するのかを決定する作業です。
実装すべきシステムの機能と、非機能要件を定義し、システム開発の範囲を画定する工程です。システム開発の最初のステップとして、非常に重要です。
この要件定義で、どのようなシステムを作るかを、どのくらいまで明確にできるかで、その後の開発の進捗にも影響していきます。
要件定義に基づいて、確定したシステムについて、画面や帳票、外部システムとのインターフェース等のシステムの入出力部分の設計を行う工程であり、「基本設計」「論理設計」と呼ばれることも多いです。
確定したシステム外部設計に基づいて、システムの内部構造、プログラムのロジックを設計する工程であり、「詳細設計」「物理設計」と呼ばれることもあるOこれらの工程の成果物として、プログラム仕様書等が作成されます。
プログラミングによって実装されたものが、仕様書とおりに動作するかどうかを検証する工程をいいます。
一連のまとまりあるモジュールを結合し、システム外部設計あるいはシステム内部設計の仕様とおりになっているかを検証する工程です。
疑似的な本番運用環境において、きちんと動作するのかの検証工程です。
多くの場合には、テストの実施主体は、本番稼働後に当該システムを使用するユーザです。
検証の範囲、項目、内容により、運用テスト、統合テスト、ユーザ受入テストなど様々な工程の名称、用法についてはベンダによって位置付けが異なります。
業務運用環境でシステムを稼働させ、業務を円滑に遂行させるための各種作業を行う工程であるサーバ機器の監視、システムの起動・停止など作業は多岐にわたります。
開発したシステムを業務に適合するよう維持管理(不具合の修補や、必要な機能改善等も含まれる)する工程です。
別途、保守契約などを締結することも多いです。
現在稼働しているシステムを刷新して新しいシステムに切り替える場合、ユーザが使用しているシステムの中に格納されている各種データ(例えば、ユーザの商品、取引先のデータや、受注、仕入などの取引データ)を新システムに移し替える必要があります。
こうした作業全般を「データ移行」と呼びます。
データ移行の作業には、データ移行のための抽出、検証、投入プログラムの設計、開発を行ったり、手作業での検証、補正(「クレンジング」などと呼ばれる)を行ったりするなど多様な作業が含まれます。
システム開発は、大なり小なり揉めることが多くあります。その原因は、ベンダ側、ユーザ側の意思疎通がうまくできていないことによることが多いです。
ユーザ側も、しっかりとシステム開発を理解するようにしましょう!