例え１）一級建築士のような仕事…今までにも、システム構築と注文住宅建築を対比して語ってきましたので、イメージは解っていただけると思います（詳細省略）。

例え２）映画監督のような仕事…顧客ヒヤリングは、相手の種類も多く（注文住宅なら、注文主家族だけですが、システムだとたくさんの関係者が出てきます）、回数も時間も限られる事が多いので、聞きたい（確認した）事すべてを頭の中でばらして、相手ごとに集中してヒヤリングする事になります。まさに、映画監督が一本の映画の最初から最後までの全ショットを頭の中で分解しておいて、何回も行けない海外ロケでは、最初のシーンとラストシーンをまとめて撮影して帰ってくる様なものですね。

例え３）地図を文字で書くような仕事…友人と待ち合わせる場所を言葉で説明するのは骨が折れます。「ｘｘ駅のｙｙ改札口をでて、大きな道路を渡ってズット言ったら酒屋があって、そこを右に曲がって…」と説明しても、「大きな道路」じゃ無く中ぐらいの道路を進んでしまうし、こちらは5分くらい進むつもりで「ズット」と言っているのに２分歩いただけでしびれを切らして曲がってしまったり、…はざらです。こんな時は図面を送ると誤解も無く伝わりますが、設計書は、どうしても記述しないと行けないものが多いので、色々な表現方法を駆使する必要があります。

この辺りについては、次稿以降で順番に説明したいと思います。

a)要求分析＝顧客が何を望んでいるのかを整理する作業です
…家族構成、趣味、生き方（陶芸をする？家でpiano教室を開く？喫茶店を開く？）、好み（和風？洋風？）、等を聞き出して顧客の要求を整理します。顧客が気づいていない要求もあることを理解しておく必要があります。また、大風呂敷を広げすぎる（何でも頷いてしまう）と、後で予算や敷地形状などの制約から多くを断念しなければいけなくなるので大枠を見切っておく必要もあります。

b)要件定義＝聞き出した要求を実現した時の姿を模型、間取り図、等で見せる作業です。
…「できる事（例：お風呂はご要望通りの大きさを確保しました、…）」ばかりでなく、「できない事、我慢してもらう事（予算や敷地形状などの制約で削除した要求）」も、きちんと説明しておく必要があります。

c)外部設計＝顧客が納得した模型、間取り図から、詳細な（技術的な）設計図に落としていく作業です。
…部材の荷重制限等の物理的制約だけでなく、動線とドアの開く方法が逆になっていないか？生活する人と壁紙の色柄は合っているか？等々の使い勝手にも配慮する必要があります。また、各種法規則や町内ルールにも準拠する必要があります（顧客が知らないことも多いです）。

d)内部設計＝設計図に書かれている各種構成物（ドアとか窓とかキッチンとか）を、部材に展開（ブレークダウン）していきます。どこまで展開（ブレークダウン）するかは、部材ごとに異なります。ドアであれば、枠+ガラス＋ノブ＋…となりますね。キッチンなら、シンク＋水栓＋給水管＋配水管＋…です。また、部材選定に自由度があり、共通部材が使えるのであれば、それを使うようにします。

ウォーターフォール型開発プロセスは、一般的に下記プロセスから構成され、下記流れで進行していくと定義されます。
「要求分析」⇒「要件定義」⇒「外部設計」⇒「内部設計」⇒「製造」⇒「テスト」⇒「運用」
（「外部設計/内部設計」の組み合わせは「概要設計/詳細設計」の組み合わせで説明される事があります。この相違点も後で整理します。）
（「テスト」プロセスは、開発規模などによって、「単体テスト→結合テスト→総合テスト」に分割される事があります。）

では、各プロセスの内容をざっと定義していきます。
a)要求分析…どんなシステムを作るのか（何を実現したいのか）を整理する。現実的には、最終決定のために、予算や開発期間なども併せて整理する事になります。

b)要件定義…要求分析で明らかになったニーズを、システムに対する機能要件として明確に（何をどうすると）定義します。人間系で対応する事柄も、その旨を明記して併記しておく方が良いです。

c)外部設計…前プロセスで定義された機能を、想定しているコンピュータシステムの前提条件（Web型処理とするのか？クライアントサーバ処理とするのか？等）や制約条件を考慮しながら写像を作ります。一般的には、ＵＩ（UserInterface＝画面、帳票）設計、データベース設計、処理設計、運用設計、等を行います。

d)内部設計…外部設計の成果物を元に、想定しているコンピュータ上に実装するための具体的な設計をします。

e)テスト…この稿では省略
f)運用…この稿では省略

「外部設計/内部設計」vs「概要設計/詳細設計」…前者は、何を作るのか（What）を整理するプロセスと、どう作る(how）を整理するプロセスを明確に（前後に）分けて進める時に使います。後者は、具体化する作業をらせん階段状に進めていく時に使います。最近は、顧客を時間的な制約から早く解放するために、また、内部設計以降の開発作業を外部委託するために、前者のプロセス組み立てを採用することが多いです。

ソフトウェア工学が扱う対象物は「プロセス」と「プロダクト」です。
・プロダクト…エンジニヤリングの過程で作り出される中間製品や文書を含めたすべての成果物を指す
・プロセス…プロダクトを生み出す工程を指す

ソフトウェア工学では、「ソフトウェアのライフサイクル」という概念に基づいて、プロセスを整備する事に重点を置きます。
ここで、ライフサイクルは一般的な用法通り、ソフトウェアの誕生～消滅までの全過程を意味します。
また、プロセスを整備する目的は、
a)標準的な作業手順を定めて作業者をガイドする事、
b)開発作業を管理する仕組みを組み立てる事、
c)使用するツールや環境などを決めるための指標を提供する事、にあります。

ソフトウェアのライフサイクルにおける開発フェーズに対応する開発プロセスには下記の様なモデルがあり、プロジェクトの特性や適用フェーズに応じて使い分けられています。
a)落水型モデル（ウォーターフォールモデル）
b)プロトタイピング型モデル
c)逐次進化型モデル
また、ベンダー各社からこれらのモデルに対応した開発手順論や開発ツールが提供されています。

次稿では、ウォータフォール型モデルを例にとって内部過程とその（上級ＳＥにとっての）留意点を概説していきます。

これに対して「伝統工芸」と言う言葉で説明される製品がありますが、作り手や作っている環境などで、思いもかけない結果をもたらす製品です。

システム構築で、時として「伝統工芸」的なシステム構築過程を見かけますが、繰り返し実行可能で結果が等しくなる手順でないと「エンジニアリング」とは呼べません。

前稿で整理したように、上級ＳＥに期待されるのは、「顧客の要望を聞き出し咀嚼し整理し、構築する情報処理システムの姿を明らかにする（設計する）する技術者」としての役割、および、「システム構築プロジェクトを運営していく管理者」としての役割です。
その役割を遂行するのに必要な資質は、一言で言い表すと「システム化対象（業務）に関する深い理解」と「ソフトウェア工学に関する知識と、その適用力」です。

「ソフトウェア工学」の定義は、IEEE std 610-1990　によると、
①ソフトウェアの開発・運用・保守にたいする系統的で統制され定量化可能な方法（工学 engineering）の適用
②その（上記①）の研究\r\nと定義されています。
従って、上級ＳＥとしての役割を全うするためには、(1)システム構築（ソフトウェア開発）手法に関する知識、(2)システム運用に関する知識、(3)システム保守に関する知識　が求められます。

また、システム化対象（業務）についても、表面的でない知識が求められます。以下に、少しだけ例を挙げておきたいと思います。
（例１）売掛金管理
　　請求額＝支払われる金額ではない
　　分割払いされる事もあるし、手数料・金利等が差し引かれる事もある。
　　また、クレーム等で値引きをする（勝手に値引きされる）場合もある。
　　消費税も明細で計算するか合計で計算するかで端数が違ってくる。
　　外貨建ての決済の場合は、為替レートや期末洗い替えの考慮も必要である。
　等を（整理する必要があることを）理解しておく必要があります。

（例２）在庫管理
　　管理対象は、現物在庫なのか経理在庫なのか？自社在庫だけでなく、預け・預かりも管理するのか？
　　管理単位は？ケース管理とバラ管理は？
　　注文との個別紐つけ要否？
　等を（整理する必要があることを）理解しておく必要があります。

対象業務についての深い理解については、すべてをとても書ききれませんので、これくらいにして、次稿以降では、ソフトウェア工学について整理していきたいと思います。

「情報処理システムを構築する」とは、顧客の要望に基づいて、その期待する結果を自動的に導き出す仕組み（これを「システム」と言います）を作ってご提供する事です。
ここで注意が必要なのは、「顧客の要望をそのままプログラム（≒固定的な処理方法）に置き換える」のではなく、顧客の要求を吟味し、捨て去る物は捨て去り、プログラムにしない（人間系が柔軟に対応した）方が良いと思われる物は人間系に委ねる事です。
この事は、情報処理システムを構築するときの、かなり大切なポイントなので別稿でもう一度取り上げたいと思います。

また、情報処理システムは、殆どが目に見えない物（プログラム等）で構成されているので「構築する」と言う作業のイメージも掴みにくいですが、「注文住宅」を作る事に置き換えてみるとイメージが掴みやすいと思います。
「注文住宅」は、①顧客の要望を聞く　②設計図を書いて外観や間取りや予算などを確認する　③資材や職人を手配する　④手順に従って組み立てていく　⑤色々な検査をする　⑥顧客に引き渡す　と言った手順で作られます。
「情報処理システム」もほぼ同じ手順を辿ります。手配する職人が大工さんなのかプログラマなのかの違い、手配する資材が壁板なのかプログラム部品なのか、と言った違いだけです。

また、「上流工程」と言う言葉は、今日の所は「実物その物ではなく、その概念を整理する過程（注文住宅の例では①②の作業）」と定義しておきたいと思います。

従って、上級ＳＥとは、「顧客の要望を聞き出し咀嚼し整理し、構築する情報処理システムの姿を明らかにする（設計する）役割を担当する技術者」だと言えます。

現実の上級ＳＥは、こんなに狭い範囲だけではなく、情報処理システムを構築するという「プロジェクト」を運営していくという（管理的な）役割を担っている事が多いので、技術者としての側面と管理者としての側面を持っています。
暫くは技術者としての側面に重心を置いて整理を進めていきます。

ＳＥ（SystemEngineer）と言う言葉を構成する単語の意味を再確認してみると、
・System–>特定の目的を達成するために組み立てられた（このブログでは情報処理のための）仕組み
・Engineering–>自然科学的な発想を土台に、どうやってシステム（このブログでは情報処理のための仕組み）を作っていくのかを研究する事
と言うことができますので、
ＳＥとは、「自然科学的な発想をもって、情報処理の仕組みの作り方を考える人」と定義できます。

情報処理の仕組み（以下では「情報処理システム」と言います）を作る作業には、多数の役割を持った技術者が登場します。
ProjectOwner、ProjectManager、ProjectLeader、…
業務ＳＥ、ネットワークＳＥ、データベースＳＥ、…
サイトデザイナ、プログラマ、コーダ、テスタ、ライブラリアン、…

★当ブログでは「情報処理システム構築の上流工程を担当する」各種技術者にスポットを当てて行きます。