書き手：NEO-TAKAHASHI（システムエンジニア）
どうもこんにちは。Zooops Japan（ズープス ジャパン）一のナイスミドル（を目指している）マネージャー・NEO-TAKAHASHIです。
前回はシステム開発の流れを知ってもらうためにV字モデルを紹介しました。今回は、そのV字モデルの各工程が「なんで必要なの？」という観点から、詳細を掘り下げてみようと思います。
前回のおさらい
これがV字モデルだっ！
前回は、システム開発の超超基礎というわけで「V字モデルを覚えよう！」という内容でした（忘れちゃった人は、前回の記事も参考にしてください）。
今回は、V字モデルの各工程について、少し掘り下げて話していこうと思います。
まずは「要件定義」から！
「要件定義」という言葉を皆さんは聞いたことがありますか？ 現場によっては耳にする機会が少ない人もいるかもしれません。
要件定義とは、システムを何のために作り、システムを使うことでどこがどう効率化されるのか、更にはそれによってどういった効果が得られるのか（主に金額面で）を定義することです。簡単に言うとシステムを導入する目的となります。
様々な開発手法がありますが、例えばウォーターフォール型開発（※１）でプロジェクトを進める場合、要件定義はV字モデルから見てもわかるようにシステム構築をする際、最初に行う作業です。アジャイル型開発（※１）をする場合でも小さなサイクルの中で目的を定義していくプロジェクトが多いでしょう（※１：詳しくは別の章で取り上げようと思います）。
プログラマとして参画している場合はそれほど関わる機会が少ない工程かもしれません。
要件定義は、一般的にお客さまに、作り手である我々エンジニアがシステム全体を構築する際の見積を提示した上で提案を行い、乗るか反るかを見極める「提案作業」とも密接に関わるフェーズです（提案作業と要件定義フェーズは切り分けて考えます）。
ちなみにシステム業界では、お客さまのことを「システムオーナー」、作り手のことを「システムベンダー」と呼ぶのが一般的です。
要件を決める際、両者の間では主にこんな会話が交わされます（想像盛り気味でｗ）。
システムオーナー：「こういうシステムを作って欲しいのだが」
システムベンダー：「そうすると、Webシステムにするか、クライアントサーバーシステムにするかですね。
作るのに期間として〇〇カ月。金額としては〇〇円必要となります」
システムオーナー：「リリースはなるべく早い方がいいなぁ。予算もそんなにないよ」
システムベンダー：「であれば、機能を削るか、段階的に優先度の高い機能からリリースしていきましょうか」
システムオーナー：「そうかね。ではそうしようかな」
オーナーって、ひげを生やしているイメージあるよね
大抵はお金の話も出てくるため、要件を互いに握る役は、会社の経営層や予算取りが出来る役職の人がすることが多いです。
なお、この要件を定義（最終的に文書化）するのはベンダー側のプロジェクトリーダーが多いかと思います。要件定義の文書化はオーナー側では行いません。ベンダー側の作った要件定義をオーナー側が承認する形を取ります。
次に、要件定義で決めなければいけないことには、以下のようなものが挙げられます。一言で言うと、「システムをどれくらいの期間と金額で導入するよ」という部分を決めるのです。
（１）背景：今回システム化に至った経緯。例えば法改正によって改修を余儀なくされたため、など
（２）目的・方針：背景を受けて導入する目的。例えば日々の業務を効率化したい、一元管理したい、など
（３）概要：システムの概要や構成する機器、動作環境（※２）など
（４）機能：「どんな機能を実装しますよ（機能要件）」とか、「ページングのレスポンスは何秒ですよ（非機能要件）」など
（５）システム化する範囲：機能などからここまではシステム対応。ここは運用・保守で対応などを決める
（６）UI（ユーザインタフェース）のイメージ：Excelなどで作成。今はモックを作っちゃうのが主流（!?
かも
（７）運用・保守：システムの稼働時間や、障害発生時の対応をどうするか、など
（８）スケジュール：ちなみにプロジェクト体制やコミュニケーションルール、会議体の種類などもここで定めます
（９）成果物：作成する成果物を定めます
なお、（※２）に関しては、WebシステムであればWebサーバーのスペック、セキュリティ（回線速度や暗号化、ネットワークなど）、データベース（以下、DB）と同居するか別で立てるか、DBのレイドはどうするか、などがあります。また開発言語は動作する環境に依存するので、開発環境や開発言語もここで決めてしまいます。
動作環境については、上記のようにざっくりで説明してしまいましたが、こちらはどうしてもインフラ知識を多く要するので、また別の機会に書きたいと思います。
～ここでちょっと寄道～
システムを導入するのに、経費だけがかかっては意味がありません。オーナー側もかけた経費がどのくらいの期間で回収できるか、などの回収計画もこのフェーズにまとめます。
わかりやすい例を挙げてみましょう。
例：営業事務処理を自動化するシステムの導入に900万円の経費がかかる場合
システム導入によって、今までかかっていた作業の時間を30％削減できる
↓
現在事務担当を10人雇っているので、3人分の経費を削減できる
↓
事務担当１人あたりの月給が30万円とすると、「30万円×3人＝90万円の経費削減」ができる
↓
10カ月後には、システム導入にかけた経費が回収できる。
例えばこの３人を営業に配置転換すれば案件獲得の機会が増え、結果的にオーナー側は、更に売上が上がるなどのメリットを得られるのです。
はてさて、次は「基本設計」
次に基本設計についてです。基本設計って何でしょう。皆さんはわかりますか？
言葉通りとすれば、システムの基本（基礎）となる部分の設計となりますかね。
基本設計フェーズで一般的に作成される成果物には、以下のようなものが挙げられます。
（１）業務フロー：システムフロー。言葉通り、システムを利用する際のフロー図）
（２）機能一覧：システムに実装する機能
（３）画面レイアウト・帳票レイアウト：各種レイアウト定義。デザイナーさんの本領発揮どころ
（４）画面遷移図：業務フローと近しいですが、画面に限った場合の遷移図
（５）コード一覧：DBのデータ設計をする際に考慮する。システムの寿命などにも関わってくる。考慮が浅はかなコード体系は、システム更改や移行の際はかなり厄介者。むむ。
（６）ER図：Entity Relationshipの略。DBの要素を、関係性が理解出来るように記す図
（７）CRUD図：「クラッド」と読み、システムの主要機能である「Create（生成）」、「Read（読み取り）」、「Update（更新）」、「Delete（削除）」の頭文字をつなげた用語。各テーブルの登録、参照、更新、削除を記す図
（７）インタフェース一覧：外部システムとの連携仕様など
おぉ。大分システムっぽい用語が増えてきました。
エンジニアの皆さんなら日常的に聞いたり使ったりする言葉ですね。システムを構成するために、「機能」「画面」「DB」「外部システム」の視点から必要なものの全体を、基本設計では設計します。
まず業務フローを作っていきますが、ベンダー側ではお客さまの細かな業務内容が完全にはわかりませんから、お客さまとの打合せを重ねて作っていくことになります。
業務フローが作成できたら、それを基に今度は必要な機能を一覧化し、その後の作業の足掛かりにします。
全体の業務フローが決まってしまったら、システム化を実現するためのDB設計、レイアウト設計と続いていきます。
本日のおさらい
●要件定義、基本設計ですべきことを理解する
次回は、いよいよ詳細設計、テスト工程について書きたいなと思います。
あとがき
今回は「要件定義」「基本設計」について掘り下げてみましたが、プログラマの皆さんにはあまり縁の無い内容になってしまったかもしれません。
大手の企業でプログラマやSEとして就職したら、定年まで考えなくてもいい内容なのかもしれません。ただ、自分がかかわる以外の工程にも視野を広げて、全体感や色んな考えを持って仕事ができたほうがずっとできることは広がりますし、なにより楽しいと思います（いや、本当に）。
次回は、いよいよ「詳細設計」「テスト工程」について書きたいなと思います（ようやくここまで来ることができました……）。
プログラマの皆さんにとって、出発地点となるような記事にしたいなぁと思います。
