タイトルのとおり、何かシステムを作ろうとなった際、
工程（フェーズともいう）というものがあり、
この工程ではどういったことをして、
その結果として、どういった資料を作るのかなど、
ある程度決まっているので、覚えておくとよいかなと思います。
また、結果的にアプトプットとなるものは
成果物と言われることが多いです。
成果物を簡単に言うと、
学校の夏休みの宿題で算数ドリルをやりきる
という宿題があったとして、
やりきった算数ドリルが成果物となります。
その行動をした結果、出来上がったもの
それが成果物です。
では、さっそく、簡単にわかりやすく
工程の説明をしていきます。
要件定義
まず、欠かせないのがこの要件定義
これは何かというと、要件を定義するということです。
仕事ってなんであると思いますか？
誰かがこういったことをしたい
というWantがあって仕事になります。
ざっくりサラリーマンというと、
スーツを着て会社に行く人、
そして、会社から給料をもらっている人と
想像がつくかと思います。
じゃ、会社にスーツを行くだけで給料がもらえるかというと
そうではないです。
会社に行き、仕事をすることで、その仕事をしたということに対して
会社から給料が支払われます。
では、その仕事とはというと、
社長（創業者）が〇〇をしたいという理由で立ち上げた会社の
〇〇をしたい（Want）ということを叶えるために、
仕事という形で手伝いを求めることで発生しています。
その、要求（Want）が何かを聞き出し、まとめ、定義することこそが
要求定義となります。
社長がしたいことを各部長が取りまとめ、さらに各課長に割り振り
そこから、細かい仕事として各従業員に作業という形で依頼が来て
仕事となります。
会社という規模が大きい話になってしまいましたが、
それを、システム開発という視野に絞って具体的に考えてみると、
スマートフォンで動かすアプリで、計算ができるアプリを作ってほしい
という要件（Want）を詳細に詰めていくことが要件の定義となります。
当たり前と思うかもしれないですが、
計算ができるアプリということで、
あぁ、電卓ねと思ったかもしれませんが、
その思い込みをしてしまうと、大事な要件を聞き漏らしてしまうので、
あまり先入観を持たないことが良いです。
例えば、あまりにも電卓過ぎるので、
四則演算ができることと思いこんで確認しないで進めた場合、
実は社長が割り算が嫌いで、割り算はできないようにして欲しい
という要件を聞き漏らす可能性があるということです。
これは、あくまでも例を大げさに言っているので、
実際にはあり得ないとは思いますが、先入観を持つことで、
思い込みが発生し、重要な聞くべきことを聞けていなかった
ということにならないように注意が必要です。
ボスに近づくもの全てが敵と思えと、
ノストラードファミリーに入ったクラピカも怒られるほど
思い込みはやっかいな場合があります。
思い込み自体は一つネタとしても面白いので、
また別の機会に書きたいと思います。
つまり、要件を定義する、要件定義とは、
何をしたいのかを聞き出しそれをまとめるということです。
お母さんが晩御飯を作る時に、
子供に今日何食べたい？
と食べたいものを聞きだす、それが要件ヒアリング、
聞き出して何を作るかを決めるのが要件定義と思ってよいでしょう。
基本設計
システムの基本的な構造や機能を設計（定義）します
要件定義である程度、顧客がどういったものが欲しいのか
という点が明確になったので、それを実現するために
どういった構造にするのか、どういった機能や性能が必要なのか
を定義します。
先ほどの例で、割り算なし電卓を作るとなった場合、
計算結果を表示する画面はどうするのか
ボタンの大きさ、形、色、
ボタンに記載される数字の大きさ、形、色
割り算のボタンは用意するが押せないようにするのか
表示すらしないのか
電卓は画面いっぱいに表示するのか、否か
などなど、要件を満たしつつ、どういったパーツがあれば
その要件を実現でき、形作れるのか
という点を定義します。
つまり、基本設計とは、要件を満たせるよう、
どういった機能があればよいのかを設計（定義）するということです。
お母さんが晩御飯はハンバーグと決めた場合、
ハンバーグを作るのに、必要な材料を想像して、
材料を決めるという点が、基本設計と思ってよいでしょう。
ただ、この際に要注意なのが、ご飯は食べるのか、
スープは何かなどの要件を聞いていない場合、
ハンバーグだけ出された息子は、要求が満たされていない
となりクレームにつながるので、
要件定義のタイミングで、ご飯なのかパンなのか
コーンスープなのか味噌汁なのか
など要件をきちんと聞き出しておくことが大事になります。
次は詳細設計移行を書いていこうと思います。
