「上流工程」って何やるの？【SEの仕事 #2】

システムエンジニア（SE）という職業に興味がある方向けに、その仕事を主に工程別に紹介する【SEの仕事】シリーズ。
第2回目の今回は「上流工程」についてです。
＊「超上流工程」を未読の方はぜひそちらから見ていただければ幸いです。

上流工程とは

上流工程の位置付け

上流工程はウォーターフォールモデルで言うと、基本設計あたりに該当します。開発・製造の手前（基本設計〜詳細設計）までとされることもありますが、ここでは基本設計の部分のみとします。
ちなみに、基本設計・詳細設計は、外部設計・内部設計と呼ばれたり、その分け方も異なったり、一律の定義があるわけではありません。
（アジャイル開発については別の機会に取り上げます。）

上流工程の目的

上流工程の目的を一言で表すならば「詳細設計・開発に必要なものを揃えること」となります。具体的には基本設計書という形でまとめることになります。
ただし、実際考えなければいけないのは設計・開発のことだけではなく、さらにその後（テスト・移行）のことにも取り組む必要がある工程です。

上流工程の仕事（設計）

それでは上流工程では実際にどんなことをやるのか紹介していきまます。
なお、設計・開発の作業と、マネジメントの作業で毛色が異なりますので、まずは設計・開発の作業について説明します。

基本設計（外部）

上流工程を開始する段階は「概要設計が完了している」状況であり、それを基本設計書へと落とし込んでいきます。
基本設計書と言っても、通常ひとつの文書にはおさめず、様々な別紙で作ることになります。主なものを以下に挙げます。

• 機能設計（一覧）

• 画面設計（一覧・レイアウト・遷移図）

• 帳票設計（一覧・レイアウト）

• データ設計（E-R図、テーブル一覧・レイアウト、ビュー一覧・レイアウト）

• ファイル設計（一覧・レイアウト）

• 外部I/F設計（一覧・レイアウト）

• バッチ設計（一覧・ジョブフロー）

なお、ここでは、基本設計を外部と内部に分けて記載していますが、外部はユーザーに確認が必要な部分、内部は必要ない部分（システム内部の設計のため）とお考えください。

ユーザー確認は要件定義まで？
ここでは、基本設計をあえて外部と内部に分けていますが、ユーザーに確認すべき外部の部分は、前工程の概要設計・要件定義に終わらせておくべきだ、という考え方もあります。
ただ、プロジェクトの正式立ち上げ前の段階で、そこまで精緻な設計をすることは難しく、立ち上げ後に精緻化するというのが一般的です。

基本設計（内部）

ユーザーへの確認が完了したら、より内部的な設計を進めていきます。
（外部を論理設計、内部を物理設計と表現することもあります）
特に、内部設計書というものを作るわけではなく、上記の基本設計書を拡張していくのが一般的かと思います。
例えば「コード設計」「画面のオブジェクト・データ等の物理名定義」「プログラム一覧整理」などがあります。

基本設計（基盤）

上記で説明したのは、アプリケーションの設計についてです。システムには当然それを動かすためのインフラが必要になります。
一般に、システム開発部隊は、アプリケーション部門とインフラ部門は分かれていることが多く、従って基本設計書も別になることが多いです。
詳細は割愛しますが、ハードウェア、OS・ミドルウェア、ネットワークなどについて、精緻な設計を行います。

パブリッククラウドの利用
ここ数年でAWSやAzureなどのパブリッククラウドが広まり、インフラ構築のやり方が激変しました。比較的手軽に構築が可能になり、作業としてのアプリケーションとインフラの境界が曖昧になってきています。

上流工程の仕事（マネジメント）

テスト計画

上流工程で考えなければいけないのは設計だけではありません。この段階でその後のプロジェクトの進め方を詳細に決めておく必要があります。その一つが「テスト計画」です。
開発が終わると、順次UT（単体テスト）、IT（結合/連結テスト）、ST（システム/総合テスト）とテストを実施していくことになりますが、その種類や実施方法、環境、担当など詳細を計画します。
なお、前工程（超上流工程）で作成するプロジェクト計画においても、ある程度はテスト計画を定義しますが、ここではそれをより精緻にするイメージです。
主なポイントをいくつか挙げます。

• STの種類
  概要設計（要件定義）で定めだ要件を満たしているかを確認するST（システムテスト）ですが、その内容は様々です。
  例えば、「業務シナリオテスト」「性能テスト」「疎通テスト」「運用テスト」「移行テスト」など多様であり、スケジュールや環境、体制などの計画を綿密に練る必要があります。

• UAT計画
  STが完了すると、最後にユーザー（顧客）がそれを確認するためのテストを行います。本来であれば、その計画はユーザーが主体となって行うものですが、システム開発プロジェクトに不慣れなユーザーも多いため、システム側がサポートしながら進めるのが一般的です。
  ＊STと並行して実施されることもあります。

移行計画

もう一つ設計以外で考えなければならないのが、「移行計画」です。
移行（リリース）は、開発したシステムを稼働させる重要な作業です。そのため、その計画も早い段階から整理しておかなければなりません。
例えば次のような検討ポイントがあります。

• 一括移行か段階移行か
  全く新しいシステムの移行であればあまり気にすることではありませんが、一般的には既に稼働しているシステムから新しいシステムに切り替えることが多いです。
  その際、一気に移行するのか、機能等を分割して何段階かに分けて移行するのかが検討ポイントになります。

• リカバリープラン
  移行が上手くいくに越したことはありませんが、実際には様々なトラブルが発生することも想定されます。そのような場合に備えて、どの段階でどのように判断するか、中断・延期する場合に移行前の状態にどのように戻すか、などを予め計画しておく必要があります。

開発委託

自社開発（完全内製化）しているのであれば考慮不要ですが、特に日本においては、設計・開発・テストの全部または一部を外部（システム開発ベンダー）へ委託することが多いです。
契約の種類は、概ね準委任契約か請負契約の2種類があり、法的な細部はさておきざっくりとした違いは次の通りです。

• 準委任契約
  設計・開発・テストの作業を依頼します。（完成させる義務はなし）

• 請負契約
  設計・開発・テストの成果（完成品の納品）を依頼します。

準委任契約は自由度が高い反面プロジェクトの不透明感が高まります。一方、請負契約の場合は後からの変更は至難になります。
そのため、要件・設計が固まっているなら請負契約、流動的なまま進めるのであれば準委任契約となるのが一般的です。