開発工程

③ 上流と下流

上流ほど「何を作るか」に近く、下流ほど「どう作るか」に近い——この向きを押さえてください。

④ 誰が担当するか

⑤ ユーザ企業が関わる工程

上流と最下流にユーザ企業が関わり、真ん中はベンダが担当する——という形です。

⑥ 上流・下流という言葉の意味

川の流れにたとえた言葉です。

上流での誤りは、下流すべてに波及します。だからこそ、上流工程が重要とされます。

⑦ 「対象が分割され、詳細化されていく」

大きなものから、だんだん小さな単位へ——この流れが「分割され、詳細化される」ということの中身です。

⑧ 手戻りの費用

工程が進むほど、さかのぼって直す費用が大きくなります。

なぜこうなるのか

上流で誤りを見つけることが、費用を抑える最大の手立て——これが次節で学ぶ開発モデルの議論につながります。

⑨ この工程は何のモデルか

この6工程は、次節で学ぶウォータフォールモデルの工程そのものです。

多くのシステム開発で、この工程が基本形として使われてきたため、他の開発モデルも、この工程を土台に説明されます。

プログラミング完了後に気づいた場合

稼働後に気づいた場合

半日が34.5日になる

約70倍です。しかも、稼働後の修正では業務への影響という、工数では測れない損害も生じます。

だから上流工程に時間をかける

「急がば回れ」——システム開発では、この格言が数字で裏づけられます。

誰が関わるかという観点

ユーザ企業が手を抜いてはいけない工程

「専門家に任せておけばよい」は通用しません。業務を知っているのは、使う側だけだからです。

中小企業でありがちな失敗

診断士としては、「この工程には必ず時間を取ってください」と伝えることが、具体的な助言になります。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　システム構築フェーズは、上流工程から下流工程へ段階的に進み、工程が進むにつれて対象が分割され詳細化される。

> b　内部設計とプログラミングは、ユーザ企業が主に担当する。

> c　基本計画と外部設計は、ユーザ企業とベンダが共に担当する。

解答　a：○　b：×　c：○

• b：×……内部設計とプログラミングは、ベンダが主に担当します。ユーザ企業が共に担当するのは、基本計画・外部設計・テストです。

「要求」と「要件」の違い

「在庫を正しく把握したい」という要求を、「入出庫を倉庫単位で記録し、リアルタイムで照会できること」という要件に翻訳する——これが要求分析と要件定義の作業です。

③ 要件定義書のイメージ

④ 要件定義書の構成を読み解く

「現状 → 課題 → 機能」という流れになっています。機能から書き始めないのが要点です。課題が明確でなければ、その機能が本当に必要かを判断できません。

⑤ 資源とスケジュールの計画

システム開発に必要な資源（ヒト、モノ、カネ）の配分計画、スケジュール計画を策定します。

第10章で学ぶ見積りとプロジェクト進捗管理は、この計画を精緻化する話です。

⑥ 外部設計（概要設計）

システムやソフトウェアをユーザ側の視点からとらえ、主に「コンピュータへの実装を意識しない設計」を行います。

システムに必要な機能を洗い出し、システム全体をサブシステムに分割します。

また、論理データ設計、画面や帳票などの入出力設計を行い文書化（仕様書・設計書を作成）します。

⑦ 外部設計で行うこと

⑧ 内部設計（詳細設計）

システム開発側の視点から、「コンピュータへの実装を想定した設計」を行います。

サブシステムに必要な機能を洗い出し、機能・プログラムを定義、サブシステムを詳細化します。

⑨ 外部設計と内部設計の違い

⑩ 「実装を意識しない／想定する」の意味

外部設計の例

「顧客の一覧を表示し、氏名で検索できる画面を作る」——どんなデータベースを使うか、どんなプログラムを書くかは決めていません。

内部設計の例

「顧客テーブルを氏名で検索するSQLを実行し、結果を一覧に表示するプログラムを作る」——具体的な実装方法まで決めています。

⑪ 第3章の3層スキーマとの対応

外部設計で外部スキーマと概念スキーマを、内部設計以降で内部スキーマを扱う——第3章で学んだ枠組みが、開発工程に対応しています。

⑫ なぜ2段階に分けるのか

「ユーザが判断できるところまで」が外部設計——この区切り方が、2段階に分ける実務上の理由です。

② モジュールとは

モジュールとは、プログラムを構成する部品のことです。

第8章で学んだオブジェクト指向の「部品化」や、第7章のSOAの「サービス」と、発想は同じです。大きなものを、扱える大きさの部品に分ける——という考え方です。

③ 実装・コーディング

プログラミングは、実装やコーディングともよばれます。

第8章で学んだ原始プログラム（ソースプログラム）を書く作業が、これにあたります。

④ テスト

作成したプログラム、モジュールをテストします。

これまでの設計手順とは逆に、モジュールを結合しながらシステムに組み上げる各段階で、その動作や機能をテストします。

⑤ 「設計手順とは逆に」という点

ここが重要です。

設計は大きいものから小さいものへ、テストは小さいものから大きいものへ——この対称性が、第7節で学ぶV字モデルの形を作ります。

⑥ なぜ小さい単位からテストするのか

いきなり全体を動かして「どこかがおかしい」では、原因を探すだけで膨大な時間がかかります。

⑦ 運用・保守

システムを設置する環境、ネットワークへの接続環境、サーバ本体となるハードウェア、サーバ上で稼働するソフトウェアなどの維持・管理を行います。

具体的には、次のことを行います。

⑧ 運用・保守の作業を分類する

これまで学んできた内容が、運用・保守の場面で実際に使われることが分かります。

⑨ 保有から利用へ

従来はユーザ企業が自前のシステムを保有し、運用・保守を行うことが多かったのですが、近年はIT業務のアウトソーシング化が進み、ベンダのシステムの一部を利用する形態が普及しているため、運用・保守の一部またはすべてをベンダが担当することが一般的です。

⑩ 「保有」から「利用」への転換

この変化は、第12章で学ぶクラウドコンピューティングやITアウトソーシングの話に直結します。

中小企業にとっては「利用」のほうが現実的

⑪ 運用・保守がもっとも長い

費用も、開発より運用・保守のほうが大きくなることがあります。

第11章で学ぶTCO（総所有コスト）では、導入費用だけでなく、運用・保守を含めた総額で評価することが求められます。その根拠が、この期間の長さにあります。