SEの業務内容については前回の記事で紹介しました。
そこでもっと実際のシステム開発の業務をイメージしやすいように、
SEが実際に業務で行うシステム開発プロジェクトの流れを説明していきます。
目次
システム開発の工程
前回の記事でも紹介したので、軽くおさらい程度にまとめておきます。
システム開発の大まかな流れは、
要件定義フェーズ：提案時の顧客からの要件を定義する
基本設計フェーズ：要件を開発機器の設計概要に落とし込み、機器の確定、方式や採用技術を確定させる
詳細設計フェーズ：開発機器のパラメータやコードのような設定ベースを確定させる
構築・テストフェーズ：開発機器へ確定させたパラメータやコードを投入し、想定の動作をテストする
運用・保守フェーズ：システム稼働を行い、メンテナンス及びトラブル対応などを行う
システム開発の進め方
システム開発のプロジェクトの流れを説明するまでに、まずシステム開発には2種類の進め方があることを説明しなければいけません。
ウォーターフォール開発 と
アジャイル開発 の2種類が存在します。
主な違いは要件定義フェーズから構築・テストフェーズを一気通貫に行うか（ウォーターフォール）
繰り返し行うか（アジャイル）の違いです。
システム開発においてはほとんどはウォーターフォール開発の手法が取られます。
アジャイル開発はアプリケーション開発に取られる主な手法であり、仕様変更が頻繁に行われてスピーディな開発に用いられます。
イテレーションと呼ばれる工程の繰り返しを行うので、仕様変更や顧客からの要望にスピーディに応えることができます。その代わり各工程で設計資料のような成果物の提出を必須としないのでシステム開発より、アプリケーション開発に最適な手法です。
システム開発においてもアジャイル型開発の手法が取られることもありますが、多くありませんので、今回は一般的なウォーターフォール開発に焦点を絞って説明していきます。
プロジェクト発足の流れ（提案フェーズ）
競争入札の場合は、具体的には下記のようになっています。随意契約の場合はいきなり要件定義に入ります。
※競争入札は他社と1案件を獲得するために競う契約方式。随意契約とは他社と競わずに、顧客から直接お願いされる契約方式です。
新規案件の獲得
まずは新システムの開発を考えている顧客を見つける必要があります。新規案件を探す方法は主に、営業が中心となって
◆既存顧客に困っていることがないかヒアリングし、システム導入を提案する。
◆既存顧客が新しい案件を持ちかけてくる。
◆新規顧客へ営業をかける。
のパターンに別れます。
どちらにせよ、営業だけでは技術的な説明が不足してしまうので、この段階でもSEを同行させることはよくあります。
同行させるSEはベテランで技術に強く、顧客への説明が上手な人が選ばれます。このような技術営業職をSEとは別に設けている企業も多く存在します。SEと営業の中間職のようなイメージです。
そうして新しいシステム開発を検討している顧客が見つかれば、社内でもプロジェクト発足です。随意契約であればすぐにでも要件定義に入れますが、競争入札となってしまった場合は、細かい段階を踏んで競合他社に勝つ提案をかけていかなければいけません。
RFIによる業務要件整理
RFIとはRequest For Informationのことであり、簡単に説明するとシステム開発企業に新規システムに関する情報提供の依頼をするために、新規システムの要件をまとめた資料です。仕様書と呼ばれることもあります。
発注元から入札先の複数のベンダーに新システムに対する簡単な業務要件や機器の要望をまとめたRFIを送付し、それぞれの企業からの「ウチの企業ならこんな機器を使って、こんな感じであなたの企業のシステムを開発できますよ」という簡単な提案書を提出してもらいます。
その提案書は細かい内容や、細かい価格までは決めないものの、おおよその概要や概算費用を提出してもらいます。
導入製品カタログ内容の紹介や、自社内の似た事例の紹介も行い、自分たちの企業がどれだけ構築できるかをアピールします。
そうすることで、発注元（ユーザー）はどの企業が、どのような機器・仕様で要件を実現するのかを検討します。
この段階では発注元が比較や検討のために情報をもらうだけなので、システム開発ベンダーは確定させません。
SEは顧客から公示されたRFIに対する提案書の作成や、製品を取り扱うメーカーに問い合わせ対応やカタログの収集、概算見積もりの作成などを担当します。
RFCによる調達仕様整理
RFCとは、Request For Commentのことであり、簡単に説明するとシステム開発企業に新規システムに関する意見を依頼するために、新規システムの調達仕様をまとめた資料です。
RFCは場合によっては省略されたりRFPの後に行ったりすることがあるので必ず実施されるわけではありません。
発注元は、複数のシステム開発ベンダーからもらったRFIの回答（提案書）をもとに、新規システムの調達仕様をまとめます。
具体的には、新規システムについて
◆調達方式、単位
◆調達機器の条件指定
◆成果物の指定
◆入札要件、遵守事項
◆再委託事項
◆契約書記載事項
など、RFIのときには記載していなかったような具体的な細かい調達のための仕様をまとめます。
そうしてまとめた調達仕様をRFCとして公示し、システム開発ベンダーから、調達仕様を中心として意見をもらうことが目的です。
RFCの公示を受けたシステム開発ベンダー側は「ウチの企業なら具体的にこんな機器をこんな台数使って、こんな条件で調達しますよ。その時こんな契約もしますよ。」という意見をまとめて発注元に提出します。
SEはこのRFCに対する意見書の作成のために、機器を取り扱うベンダーと問い合わせ対応を行ったり、技術仕様について詳細に詰めていったりします。
その意見書も受領した発注元は再度、複数のシステム開発ベンダーの調達方式や条件について比較を行い、どのベンダーが一番要望に近いか検討することや、自分たちが新システムで実現したい要件を固めます。
RFPによるベンダー整理
RFPとは、Request For Proposalのことであり、簡単に説明すると新規システムを開発するベンダーを確定させるために、新規システムの構築内容、理解度を測るための提案書を依頼するための資料です。
RFCにより新システムで実現したいことや、業務要件などを固めた発注元は、より詳細に新システムの構築に関する要件をまとめます。
具体的には、新規システムについて
◆RFCで確定させた調達方式、条件
◆RFIではあいまいになっていた、業務要件を詳細化、明確化
◆システム開発の期限
◆システム開発プロジェクトの体制、プロジェクト運営・推進方法
◆プロジェクトマネージャーの条件
などを詳細に依頼書としてまとめます。それをRFPとして、システム開発ベンダーに提出します。
各ベンダーはRFPをもとに新システムについて「ウチの企業なら具体的にこんな機器をこんな台数使って、こんな構成とこんな技術を使って要件を実現しますよ。こんなスケジュールや体制で取り組みます。」と一つの提案書にまとめます。
そして、RFIのときよりもより詳細な見積もり費用を提出します。
その新システムに関する提案書を受領した発注元は、各ベンダーから提案書について評価を行い点数付けしていき、ベンダーの選定を行います。
提案書の選定の評価基準は主に、
◆技術内容の質
◆加点項目、減点項目による点数増減。（主に、顧客も決めかねている部分をどのような方式で実現できるかを提案できれば加点、最低限の要件が満たされていなければ減点）
◆足切り点を超えていること
◆他社における構築実績
◆提示価格
などを中心に点数付けします。
そうして最も点数の高いシステム開発ベンダーと契約を結び、これで提案フェーズの終了で、以降は要件定義フェーズになります。
ちなみに当然の話ですが、入札により案件を勝ち取るまでは契約ができていないので、顧客からお金をもらわずに稼働しています。案件を勝ち取れなければ企業にしてみれば人件費の損失でしかありません。負ければ社内でのプロジェクト体制も解除で、別の案件を担当することになります。
入札確定以降（要件定義～運用・保守）
入札により無事案件を勝ち取り契約を行ったら、次からは実際の技術・機能を固めていくフェーズに入ります。
詳しくは前回の記事でも紹介したので、ここではサラッと簡単にまとめておく程度にして、前回説明していない部分を補足しておきます。
要件定義フェーズ
要件定義書の完成のために、提案時の曖昧な箇所を明確にするフェーズです。
顧客がシステムで実現したい要件を、「どのような機器で、どのような機能・技術を利用して実現するか」を定義し、顧客と合意形成を図ることが目的です。
基本設計フェーズ
基本設計書の完成のために、要件定義で確定した「どのような機器で、どのような機能・技術を利用して実現するか」を更に追求し、「どのような機器（型番・台数・構成）で、どのような機能・技術（設計方針、概要や大まかな数値、機能の使用有無の選別）を利用して実現するか」を定義し、顧客の要望を叶える設計をすることを見せつけることが目的です。
詳細設計フェーズ
詳細設計書の完成のために、基本設計で確定した「どのような機器（型番・台数・構成）で、どのような機能・技術（設計方針、概要や大まかな数値、機能の使用有無の選別）を利用して実現するか」を更に追求し、「各機器で、どの機能・技術をどのような数値、設定を利用して構築するか」を定義し、導入機器を机上の設計まで完成させることが目的です。
構築フェーズ
システム構築のために、詳細設計で確定した「各機器で、どの機能・技術をどのような数値、設定を利用して構築するか」を記載した詳細設計書を利用して、実際の現場に機器を搬入し、設定を入れ込みます。機器同士のケーブル結線も行います。
顧客の要望したシステムの基盤構築を完了させることが目的です。
テストフェーズ
システム構築完了のために実際に構築した機器が想定通りに動くことをテストします。
下記のようなステップを経てテスト全てを完了とします。
試験計画書の作成
顧客にどのようなテストをどのようなスケジュールで行うのか説明します。
システム開発においては、テストではどのような項目・シナリオでテストを行うかをフェーズと対応させて考えるV字モデルという考え方があります。
具体的な見方としては、
提案時の顧客の要求を分析した内容を、受入試験にて確認します。
要件定義にて定義した内容を、総合試験にて確認します。
という具合に、図左側のこれまでのフェーズで考慮した内容を、図右側の試験工程で確認するように対応します。
それでは各試験内容について説明していきます。
単体試験
機器単体での単純な動作確認を行います。「電源が正常に稼働していること」、「コマンドを投入したら正常にシャットダウンされること」などのように、単純なテストです。
他の機器と接続せず、一つの機器単体で行う機能に限ったことなので単体試験と呼びます。
結合試験
機器同士をケーブル接続させて動作確認を行います。「正常に機器間でのアクセスができること」、「障害発生時に想定の機器へ切り替わること」のように、2つ以上の機器を結合した状態で利用しないと確認できない機能の確認を行うため、結合試験と呼びます。
総合試験
実際のシステム環境において、想定通りのシナリオで動作できる確認を行います。
結合試験までは顧客環境ではなく、どこで実施しても問題はありませんが、総合試験では必ず本番で稼働するシステムと同じ環境で動作ができることを確認します。
確認内容も、正常時の動作、障害時の動作、複数機器をまたいだ機能確認やアクセス確認、など様々なパターンの試験を行います。総合的な判断を行う場であるため総合試験と呼ばれます。
受入試験
構築できたシステムをユーザーが確認する試験です。要件が緩い顧客では実施しないこともありますが、厳しい顧客の場合は試験ログから試験結果一覧表の数値まで細かくチェックが入ります。
ここで顧客の出した要件・要望がきちんとシステムに反映されていることを顧客が確認し、問題がないことを顧客が了承したらテストフェーズ終了となります。
運用・保守フェーズ
テストが完了すればシステムの稼働が始まります。システム稼働が実際に始まることを運用と呼び、運用期間中になにか問題があれば対応することを保守といいます。運用保守と一緒に扱われます。
システム開発企業の多くでは、システム稼働までの構築とシステム運用・保守の担当を分けていることが多いため、実際にはリリース前に運用保守への引き継ぎが行われます。
顧客は運用期間中になにか問題があれば構築を担当した人ではなく、保守窓口に連絡をとることになります。保守の形態は契約内容に紐づくので24時間365日対応ということもあれば、平日9:00~18:00まででの対応という場合もあります。どのような対応とするかは契約時に決めることです。
まとめ
案件獲得のために、提案書の提出のために他社と戦います。
案件獲得以降は、要件定義、基本設計、詳細設計、構築・テスト、運用・保守という各フェーズに入ります。
各フェーズにより顧客や協力会社と契約方式が異なる場合があるので、フェーズにより体制が少しずつ変わるのが一般的です。
PM（プロジェクトマネージャー）や設計リーダーのような重要人物は、何か問題さえ起こさなければ提案から運用までずっといるでしょう。
このようなシステム開発に関わるSEの入門書をKindleから出版しました。kindle unlimitedであれば無料で読むことができます。
ブログ内の内容と基本は同じですが、ちゃんとした流れで記載しているので理解しやすいかと思います。
Kindle Unlimitedとして出版しているので、加入している人は無料で読むことができます。「ちゃんとした順序で読みたい」「電子書籍でスキマ時間に読みたい」「無料だからとりあえず読んでみる」といった方はぜひ読んでみてください。
