社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

開発工程(要求定義)

開発工程の中の要求定義の説明です。

1.要求定義でやること

企画がとおるといよいよ次は要求定義です。要求定義は、ユーザー部門がやりたいことをまとめる工程です。

ただ実際には「要求定義書」もシステムのドキュメントの一つなので、ユーザー部門だけではまとめられないので、システム部門がユーザー部門からヒアリングをしてまとめます。要求定義書に記載する内容は、主に以下のものになります。

①機能要求(目的や背景含む)
②非機能要求
③プロジェクト期間/納期
④役割分担/体制図
⑤予算

①がユーザー部門からの要求です。「こんなことをやりたい」というユーザー部門の要求をまとめたものが機能要求です。改修レベルの案件の場合、機能要求だけ記載することが多いです。

②は性能やセキュリティー、可用性、クラウドかオンプレかといったサーバー環境、保守性等の要求です。新規でシステムを構築する場合には非機能要求をきちんと提示しないと、まともに動かないシステムが出来上がる可能性があります。

③と④はRFPとしてまとめる場合が多いです。④は特にデータ移行や教育、マニュアル作成、受入テストの支援、本番稼働直後のサポートといった開発そのものでないものについて、どこまでベンダーに依頼するのかを明確にします。

⑤は予算をベンダーに伝えることは少ないですが、公開していい場合には「この予算内でできるシステムを提案してくれ」といった形で提示します。公開しない場合でも、非公式では予算感を候補のベンダーには伝えることが多いですが。

またある程度の規模の場合には、「要求定義書」の他に「要求一覧」も作成します。要求一覧を作ることで、要求が構造化されるため、後々の管理(特に品質管理やスコープ管理のトレーサビリティー)で大きく役立ちます。

2.RFPとの違い

RFPはベンダー選定をするために、ベンダーに提案を求めるためのドキュメントです。

RFPには、ベンダーが見積り含めた提案をするために必要な情報と、発注者側がベンダーを選定するために必要な情報の大きく2種類の情報が含まれます。

前者は、基本的には要求定義書が該当します。ただし、発注者の業務や現行システムを知っていることが前提の要求定義書(既存ベンダー向け)と、知らない相手に出す要求定義書では後者の方がボリュームは多くなります。

後者は、要求定義書に記載すること以外の情報で、主に以下のようなものを提案書に盛り込むように要求します。

①類似システムの他社での構築実績
②プロジェクトメンバーのキーマンの経歴
③プロジェクト体制(委託先の会社名含めて)
④想定している開発手法やプロジェクト管理の方法

ベンダーの提案に良いことばかり書いてあっても、本当にそれを実現できる実力のある会社や体制なのかを、こういった情報で評価します。

3.民間と官公庁の違い(余談)

余談ですが、このRFP、民間と官公庁とでは位置づけが異なります。

正確には官公庁の場合(政府資本の入っている会社の場合)、RFPに相当するものは「調達仕様書」と呼びます。

RFPとの大きな違いは、受託したベンダーは調達仕様書の内容を実現する義務がある、ということです。

民間のRFPの場合、ベンダーが受託後に準委任契約で要件定義を実施し、そこでスコープと費用が確定して基本設計以降の請負契約という流れになります。つまりRFPで提案したことは必ずしも実現する必要はありません。もちろん、受託するために出来もしないことをRFPに書いてしまうと要件定義で揉めることになるので、通常は全て実現するつもりでベンダーも提案はしてきます。

それに対して調達仕様書の場合には、ベンダーの提案書が契約書の一部になります。要件定義以降の工程を請負で契約するため、ベンダーは落札した金額で、提案書に記載したことを実現する義務が生じます。要件定義をやる前に費用が決まってしまうので、ベンダーはリスクをかなり多く乗せて入札することになります。税金の無駄遣いです。

4.要求定義の例

紙で回付している稟議書のワークフロー化の要求定義を考えてみます。

システムで実現したいことを記載します。ほとんどの場合には、今やっている

あるいは、これからやろうとする運用を記載することになります。

・機密区分(社外秘、機密、厳秘)の選択ができる
・社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能
・機密は、稟議を回付した人だけが参照、ダウンロード、印刷が可能
・厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可
・稟議を起案したタイミングで稟議番号を発番する
・起案した稟議は稟議整理簿で、年度ごとに管理できる
・稟議整理簿には、稟議番号、件名、起案者、起案日、決裁者、決裁日、機密区分を出力する
・稟議整理簿の件名は、厳秘の場合には空白とする
・決裁する金額によって、自動で部長決裁、担当執行役決裁、社長決裁が決まる
・回付ルートは、起案者の所属と決裁者によって自動で決まる
・各所属の管理者のみ途中承認者をスキップできる
・承認者は、承認、否認、差し戻しの3種類が可能な
・承認者は、個人、組織、組織+役職の3パターンの設定が可能な
・承認者が複数の場合、全員の承認が必要なパターンと誰か一人の承認で良いパターンの2種類が選べる
・起案者は起案後に、決裁前であれば引き戻しが可能
・起案者は引き戻し後に再申請か廃案が可能
・保管期限は起案者が5年、7年、10年の中から選択できる
・保管期限が過ぎた稟議は、自動で削除する

上記の記載は、要求一覧のイメージです。要求定義書は、これらの情報が表形式で記載されたり、フロー図で記載されたり、イラストで記載されたり、様々な表現方法で記載されます。

【振り返り】

今回は要求定義の説明でした。次回は要件定義の説明をしていきたいと思います。

①戦略・企画
②要求定義
③要件定義
④基本設計
⑤詳細設計
⑥製造
単体テスト
結合テスト
⑨総合テスト
⑩受入テスト