文部科学省の次期学習指導要領（2020年度実施予定）で、小学校でのプログラミング教育が必修化されるようで、今後この分野もどのように進むか注力して行きたいですね。
そうなると、実際の現場ではどの様なやり取りがされているか気になりますね？
お客様（ユーザー）の要望をヒアリングしプログラム仕様に落とし込み、プログラム（コーディング）してお客さまに渡るまでのリアルを弊社の事例を交えてシリーズ化して見ます。
全てのソフト会社が同じかと言うとそうでは有りません。
あくまでも弊社の事例ですので、細かなツッコミは無しでお願いします。
基本、得意分野も含めシステム屋で受けられる内容は限られています。
弊社の基本はWebアプリ、Windowsアプリで企業系システムのシステムに特化されます。
なので、突拍子の内要望は受けられません・・（ゲームアプリ作って などは無理です）
今回のモデルシステムは話題のIoTに関しての、参照系アプリの事例を述べてみます。
【前提条件】
装置や測定器の情報収集は完了しているものとして、既にデータがPC又はクラウドDBに準備されている所からスタートします。
【はじまりはじまり】
・ユーザーとのヒアリングでシステムの目的や、やりたい事の要望を聞き出します。
・ヒアリング内容を私を含めたエンジニアでまとめます。
・ヒアリング内容を基に提案書を作成します。
システム構築の主旨（目的）
お客様の求める機能、案件定義
システム構成
概算工数とスケジュール（仕様、プログラム、デバック、ドキュメント作成、導入）
見積金額策定
ここは、範囲や期間、見積り金額・・・経験がものを言うので説明が難しいですが。
・システム提案書（企画書）を説明し商談
・商談成立後にお支払条件を確認（小規模であれば引渡後、中規模であれば着手金請求）
ここからが実際のスタートになります。（このスタイルは弊社独自かも知れません）
・システム仕様の具体的な打合せ開始です。
基本はINPUT/OUTPUTをベースに要望を伺いながらニーズを探ります。
今回の事例はIoTの仕組みの見える化なので、OUTPUT側に注力します。
何を管理したいかを伺いながら、OUTPUTイメージを膨らませ、検索項目や表示項目を決めて行きます。
この部分が案件定義（仕様）になります。
・案件定義書（仕様）を基に、DB設計を行います。
この部分が一番重要で神経を使う部分です、ここを誤ると後からの要望や追加作業で根底のDB設計からやり直す羽目になります。（なのでDB設計は充分時間を掛けます）
・OUTPUTイメージからDB設計が完了しますと、画面設計（画面遷移）になります。
出力項目が決定（FIX）されれば、画面設計はレイアウトになりますので多少の変更は後からでも可能です。（見た目の位置変更や色変更）
・この内容の確認をお客様と数回打合せをしながら内容を決定し、プログラム仕様書（DBテーブル構造、画面設計書（画面遷移）、検索条件）を作成します。
・案件定義書とプログラム仕様書が決定した段階でプログラム開始になります。
・・かなり簡単に書きましたが、システム開発の７割はこの仕様で決まりますのでかなり重要で神経を使います。
今まで何度も仕様OKを頂いた後に、追加要望の後出しじゃんけんが有り泣いています。
経験の数がモノを言う世界です。（かなりの冒険も有り神経を使います）
次はプログラミング（コーディング）に入ります。