ITエンジニア基礎用語集 プロジェクト編

ウォーターフォールの最初の工程です。まず、RFP要求仕様書と呼ばれるものが、開発の発注者から提示されます。これを最初の資料として、発注側と開発側で、開発全体に対する大枠を決めていきます。作るもの、目的、納期、進め方、優先順位などが決定されます。

開発側はプロジェクトマネージャーと呼ばれる開発の取りまとめ役がこの工程を行うことが多いです。ここで決定されたことは要件定義書というドキュメントにまとめられ、次の工程に渡されます。

基本設計とも呼ばれます。要件定義書を元に、開発の発注者からも見える部分の設計を行います。具体的には、機能設計、画面設計、データベース設計などが行われます。これにより、機能設計書、画面定義書、データベース仕様書などの成果物が出来上がり、次の工程に渡されます。

システム内部の設計を行います。発注者から見えない部分の設計を行うため、外部設計に対して内部設計と呼ばれます。外部設計で決められた機能を、内部でどのようなモジュール単位に分割するか、データのフローはどうするか、などを決めます。この後は製造に入ることが多いですが、より細かくプログラム分割を行ったり、プログラム内を一度日本語で書き起こしたりする詳細設計を行う場合もあります。

実装、コーディングなどとも呼ばれます。内部設計で決められた設計書に従って、プログラムを記述します。SE、プログラマと言う単語からイメージされるのが主にこの工程で、システム開発と言えばずっとプログラムを書いていると思いがちですが、実はプロジェクト全体の中では、あまり時間的に大きな割合ではありません。

試験はテストとも呼ばれ、関数単位、処理単位など、プログラムの小さな固まりが仕様どおり動作するかを確認します。ここでは、内部の分岐を全て通すホワイトボックスと呼ばれる試験手法が採用されることが多いです。関数など単体で動かないプログラムに対しては、ドライバーやスタブなどを別途用意して試験を行います。最近では、色々な言語でユニットテストツールと呼ばれる“試験を行うためのツール”が充実してきていて、試験のためのプログラムを記述し、そのプログラムを実行することにより試験を実行します。

プログラムをいくつか組み合わせ、試験を行います。単体試験では問題なかったプログラムも他と組み合わせることにより、仕様と違った動きをする場合があるので、そのような不具合を発見します。結合試験からはプログラムの内部の処理を全部通すのではなく、予め決められたインタフェースの仕様に従って、それらの入出力が正しいかを確認するブラックボックスと言われる試験の手法が使われることが多いです。これらの試験の手法に関しては、現場によりケースバイケースです。

システム全体を組み上げて、要件定義で決められた仕様が満たされているかを試験します。実際のシステム運用を想定したシナリオ試験などもここで行われます。この試験を通過すれば、システムとして稼働させることができます。

バグ曲線は、試験項目の消化率に対する、バグの発生件数をグラフに表したものです。この曲線が収束していくことにより、バグが正常に消化されていくことを表します。

システムを作っていると、各工程においてバグは必ず発生します。発注者は「バグ」という言葉に過剰に反応してしまいがちですが、逆に試験工程でバグが発生しないシステムは、本番稼働が開始されてから致命的な不具合が発生する恐れがあります。各試験工程においてバグが見つかることは、本番で安定的に稼働させるために大事なことになります。

主にウォーターフォール型の開発で使われる、工程管理のための表です。棒グラフの1種で、プロジェクトの各段階を作業単位まで分解した横棒を工程順に置いていき、進捗状況を記入します。各工程には、作業開始予定、作業終了予定、担当者、依存する前後工程が記入されることが多いです。次の工程に移る前に終わらせておかなければいけない工程を、視覚的に認識することができます。

主にスクラム開発で使われる、バックログを登録しておくためのツールです。JIRAが有名ですが、最近はこのあと登場するソースコード管理ツールの中に内包されていることも多いです。課題を1つずつ登録することができ、それぞれ担当者と対応予定のスプリントを記入しておきます。また、最近はカンバン方式の運用を行えるようになっているツールも多く、視覚的にどの課題に対応しているのかを素早く確認することができます。

開発者が作ったプログラムを管理しておくためのツールです。SubversionやGitなどの種類があります。サーバーサイドアプリケーションとして用意され、開発者はチェックイン、チェックアウト、コミット、プッシュ、フェッチなどの操作でチームのソースコードを管理します。複数人で開発をする場合、ソースコードの競合やデグレーションが発生することがよくあるため、それらを防止するための仕組みが用意されています。

データを保存しておくためのソフトウェアです。表組みで保存しておく仕組みのリレーショナルデータベース、Key-Value型で登録しておくNoSQLデータベースなどがあります。

UIが存在しない処理の単位です。定期的に実行されたり、何かのきっかけで実行されるようなものがあります。

主に開発者向けに用意されたシステムの実行環境のことを指します。
開発者が動作確認を行うために利用されます。

発注者にシステムの動作を確認してもらうための環境です。
開発環境で構築したシステムを定期的にステージング環境に反映し、動作が仕様どおりになっているかを確認してもらいます。

リリース環境とも呼ばれます。ステージング環境で確認され、最終出荷前の試験をクリアしたシステムを配置する環境です。

システムを利用可能な状態にすることです。開発環境からステージング環境にデプロイ、ステージング環境から本番環境にデプロイ、などという使い方をします。

今回は、基礎的なものを中心にご紹介しました。実際の現場では、これら以外にも数多くの用語や、その現場・会社特有の用語も多く登場します。しかし、本日ご紹介した用語の基礎知識があれば、それら応用的な用語が登場しても対応できるようになるでしょう。ぜひこれからの現場で活用してみてください。

• 開発環境
• 外部設計
• 仮想環境
• 内部設計
• 本番環境
• 要件定義

（2019年4月現在）