みなさん、突然ですが“IT業界”と聞くとどんなイメージでしょうか？
- みんなバリバリプログラミングできる、、
- 下請けが元請けの会社に納期を迫られ、残業続き、、、
- お客さんの要望をシステムにすると全然違うものになってる、、、
- 働く人たちみんなドライ、、、
などなど、あまり明確なイメージがない人が多いのではないでしょうか？？
今回は、現在金融機関向けのソフトウェアを開発している会社に勤める筆者が、企業レベルでのシステムの作り始めからリリースまでの流れを解説し、IT業界の全体像を出来るだけ具体的に解説したいとおもいます。
この記事では次のような人をターゲットに書いています。
- IT業界にこれから就職しようと思っている人
- 既にIT業界に就職しているが、全体像があまり見えていない人
こうした人はこの記事を読むことで、システムができるまでの全体の流れがわかり、あなたがやりたい事をするにはIT業界の中のどの部分に当たるか理解できるようになります。
システムができるまでザックリ解説
具体的な話をする前に、まずはシステムができるまでの流れを大まかに説明します。
システムができまで通常は次の流れがあります。
- 超上流
- 提案工程：お客さんに技術力などをアピールして契約を締結する。（営業活動）
- 上流工程
- 要件定義：提案時の内容を具体的にどうやって実現するかをお客さんと擦り合わせる。
- 設計工程：要件定義した内容でシステムを作るために、詳細なドキュメント（設計書）を作成する。
- 下流工程
- 開発工程：設計書に記載してある内容を満たすようにプログラミングする。
- テスト工程：開発した内容で問題ないか確認する。
そして、IT系の会社はよく「上流」と「下流」で分かれており、入社した会社によって担当する工程が決まってしまうことがあります。
ちなみに、筆者のいる会社は超上流から下流まで全てを行う”一気通貫”の企業に勤めています。（そのため、全工程での経験があります。）
そのため、IT業界に就職する場合、企業選びの前にまずどの工程で働きたいのかを明確にする必要があります。
以降ではそれぞれの工程の特徴をやや強調しながら具体例を持って説明していきます。
今回は提案フェーズにフォーカスして説明していきます。
提案工程
提案工程は、とにかく自由で、全部の工程の中で最もシステム開発の総合力を試される工程です。
システム開発ではまずお客さんが、RFPと呼ばれる要望を記載したドキュメントを提示します。
RFPとは、Request For Proposal の略で直訳すると「提案依頼書」となります。
RFPは、システムを開発して欲しい会社が作成して、システム会社に提案書を作成してもらうためのインプットとなるものです。
RFPにはシステム化する背景や制約事項、スケジュールなどが書かれており、システム会社はそれを受けて提案書を作成して、他の会社より優れていることをアピールするのです。
それに対して、システム会社各社が、「そのシステムをうちがやったらこんな感じでできますよ！！」と言うのをお客さまに提案して、各社の提案の中から選ばれたら契約できるというのが大まかな流れになります。
実際に提案書を作成するときは、次のような内容を考える必要があります。
- システム開発する上での制約事項や前提（見積もり前提）
- 実際に作るシステムの工数の見積もり
- 大まかなスケジュール（マイルストーンなどの設定）
- プロジェクトメンバーの確保
上記の内容を考えた上で、顧客に合理的、かつ、魅力的に資料を使って伝える必要があります。
また、顧客の関係各社に密なコミュニケーションをとって友好的な関係を築くこともとても重要です。
どうでしょうか？細かい説明は次にしますが、結構大変そうだぞ、、と思った方も多いのではないでしょうか？？
それはその通りで、システムのスキルだけでなく、ビジネススキルが高いレベルで求められるのがこの提案工程であり、その分決まったやり方はなく、各自が自由に考えることができるとってもクリエイティブな工程です。
提案の制約事項、見積もり前提を考える
提案だけではなく、要件定義の工程でも重要なのですが、顧客と話す時に重要なのは「開発するシステムがどんなものか」ではなく、「開発するシステムでできないことは何か」をどれだけ明示的に伝えられるかなのです。
結局のところ、顧客はRFPを出して、どういうものが欲しいのかある程度纏まっているわけですから、その要望に対して、何ができる、というより、何ができないと伝える方が大切なのです。
そうしないと、実際に見積もってもいない機能があると思われて、要件定義の難易度が急上昇します。（最悪の場合、機能追加に無償で対応なんて事も、、）
例えば、私が生命保険会社のシステム開発の提案した時のことを例に挙げると、次のようなことを提案前提としていました。（詳細な内容は機密情報のため、ぼかして記載しています）
- システムで対応する範囲は、XXXとし、XXXは含まない（システム化する業務の範囲を定義）
- システム構成は、弊社想定とし、XXXは想定していない。（システム構成定義）
- アプリケーション上で、XXXする際には必ず事前にXXXを実施している前提とする。（譲れないアプリの制約事項）
- スケジュール・コストの都合上、要件定義は事前に資料を弊社より送付し、貴社が事前に資料を確認している前提で説明を実施する。（スケジュール上の制約事項）
こう見ると少しわかるかもしれませんが、制約事項や見積もり前提は、開発する上でのシステム会社からの「要望」を表しています。
こうしたことを伝えずに提案してしまうと後々、「どういう前提で提案してたの？？」となってトラブルの原因となってしまいます。
システムの見積もり
提案の前提が整ったら、その前提に基づいて、実際に見積もりを行っていきます。
とは言っても、インプットがどのようなものかで見積もりの方法が変わってしまうのも事実なので、ここでは画面遷移図がインプットにあったとします。
画面遷移図とは、システムのいわば俯瞰図で、各画面がどのように繋がっているか（どの画面がどの画面に遷移するか）を図で示したものです。
実際の画面を貼って線で繋いだものや、文字で遷移条件を書いているものなど、いろいろなパターンの画面遷移図があります。
さまざまな画面遷移図がありますが、基本的には画面遷移図から読み取れる情報には以下のようなものがあります。
- 画面の全量（どんな画面があるか）
- 画面間のつながり
ここから、想像を膨らませると次のことがわかってきます。
- 顧客が想定している業務の流れ
- システムのもつ機能・特徴
画面名は基本的に画面の持つ役割や機能を表すことが多いです。その為、画面名から各画面の機能を推測することが可能です。
そして、機能を推測したら、各画面間のつながりから、実際の業務がどのように実施される想定なのか、想像力を使ってイメージしていきます。その際、既に存在する他社事例があるとなお、イメージが湧きやすいです。
そして、開発するシステムの画面数、機能などを推測したら、後はその機能を実現するために必要な以下の要素を洗い出していきます。
- 外部接続先には何があるか（外部IFの洗い出し）
- 定期的に実行する必要があったり、データをまとめて処理する必要のある機能があるか（バッチの洗い出し）
- 実際にデータを紙に暗示する必要があるか（出力する帳票の洗い出し）
こうなると、後は簡単です。画面、機能（API）、外部IF、バッチ、帳票それぞれに対しての工数を見積もることで、システム開発に必要な工数を算出することができます。
システム開発の現場では、よく見積もりを工数という概念で表現します。
工数とは一言で言うと、「要件定義〜リリースまでにかかるマンパワー」のことを言います。
マンパワーの為、単位はよく「人月」（人が何ヶ月働くと開発できるか）が使われます。
例えばA機能を作る時に、「3人月かかる」と言うときは、従業員1人が3ヶ月付ききっきりで開発すると機能が作れると言うことを表します。（そのため、例えば3人が同時にA機能を作る場合は、1ヶ月でできることになります。）
そして、「1人月あたりいくら」と言う形で別途金額が決められており、実際の金額に算出し直すのです。
スケジュール・人張りを考える
見積もりまでできたら、最後はスケジュールを考えます。見積もりまでできていれば、あとは人がどれだけそのプロジェクトに参画できるかに応じて、期間が決定されます。
ただ、PJによってはデッドラインが決められており、そこに間に合わせる為に色々帳尻を合わせることが多いです。
また、いくら人がいるとしてもどうしても依存する工程が存在し、これ以上短くできないというようにスケジュールは単純ではありませんが、基本的には総工数と参画人数で決定されます。
そして現実問題として、誰がそのPJに参画するかリソースを現実的に当てられるかを検討する必要があります。
リソースの抑え方は会社によってまちまちですが、筆者のいる企業では人事部のような部署が誰がそこに配属されるのかを決定しています。
おわりに
以上が、提案工程の具体的なイメージでしたが、いかがでしょうか？
思ったよりクリエイティブで、総合力が求められることが伝わったら嬉しいです。
次回は要件定義フェーズを中心に説明していこうと思います！
