第7回 「設計」作業の成果は完成品質を左右するキーワードでわかるシステム開発の流れ(1/3 ページ)

» 2008年01月31日 12時00分 公開
[高田淳志,株式会社オープントーン]

 本格的なシステム開発に初めて携わった青木室長、そして、豊富なシステム開発経験を武器に青木室長を支える部下の赤井君……。そんな、凹凸コンビの2人でしたが、社長や各部門の責任者・担当者、さらには実店舗の店員、開発ベンダなど、インターネットショップ開発・運営にかかわるすべての関係者との交渉・調整を重ねながら着実にシステム開発を進めてきました。プロジェクトがシステム設計工程に入り、後は開発ベンダにお任せ……といわんばかりの青木室長に、今日も赤井君の「ツッコミ」が入るのでした。

設計する内容は実にさまざま

 青木室長と赤井君が作成したRFP(Request for Proposal)をもとに数社から受けた提案を比較・検討し、開発委託先ベンダの選考を行った結果、システム開発手法の柔軟さや、業務システムからインターネットシステムまで幅広い開発実績を持つB社に委託することが決定しました。そして、プロジェクトリーダーを担当するのが、つい先日までアパレル関係のインターネットショップ開発案件を担当していたB社のホープ若井さんです。そんな若井さんを交え、3人で資料を囲んで議論する機会も随分と増えてきました。今回は、システム設計工程の進め方について調整を行っているようです。

若井さん 「今回は、御社にて非常に詳しいRFPを作成していただいたので、開発サイドとしては非常に助かります」

青木室長 「そうでしょう! 本当に苦労の連続だったよ(自分の手柄といわんばかりの表情)」

若井さん 「さらには、これまで青木室長と赤井さんからRFPを補うような形で多くのことを聞かせてもらいましたので、開発チームの作業としてまずは機能設計を進めていこうと思います」

赤井君 「機能設計は、すべてドキュメントだけで進めていく予定ですか?」

若井さん 「いいえ。今回は、御社にとって初めてのインターネットショップ立ち上げということで、実際に運用に携わる予定のスタッフの皆さんの中には、紙資料だけ渡されても実際の様子が想像できず、せっかくレビューの機会などを設けていただいても、レビュー実施の効果が十分に上がらないのではないかと心配しています。そこで、作業手間が多い部分や、多くの皆さんが使用する部分については、デモ版のようなシステムを用意して、実際の作業イメージをつかんでいただきながら進めようと思っていますがいかがでしょうか?」

赤井君 「“プロトタイプ”を作りながらというわけですね。私も若井さんと同じ心配を抱いていましたので、賛成です!」

若井さん 「賛成していただいてよかったです。ただし、ここ数年話題の内部統制的な側面も無視することはできませんので、設計書など必要なドキュメントもウォータフォール的な進め方をした場合と遜色(そんしょく)のないレベルで作成していくつもりです」

青木室長 「プロト……、ウォーター……。(額から汗が……)」

 「何を作りたい」から「どのように作る」という具体的なシステムの姿へとブレークダウンしていくのが、いわゆる「システム設計」工程の役割です。また、システム設計工程は大きく「基本設計」と「詳細設計」に分類されます。大雑把な説明になりますが、「システムのユーザー(システムを利用する人、システムを運用する人など)の視点で記述するのが基本設計であり、開発者(システム・エンジニアやプログラマなど)の視点で記述するのが詳細設計である」と書くと違いをイメージしやすいと思います。

 実は、これらの設計書に、海外や日本国内で標準とされている書式はありません(標準化しようという動きはあります)。各社各様、開発担当者各様もしくはシステム各様の書式で作成されることが多いのが現状です。そのため、記述されている項目タイトルが同じであっても、ある時は説明文書主体の設計書が作成されたり、またある時は図主体の設計書が作成されたりします。さらには、図主体の設計書であっても、まったく異なる図の表現方法が幾通りもあるなど、設計書の内容を詳細に確認したい発注サイドにとっては、あまりやさしい状況とはいえません。ですから、何件かのシステム発注を繰り返すなかで「これが見やすい、確認しやすい」という設計書を目にすることがあれば、次の開発時には「この形式で書いてくれ」と指示しておくといいかもしれません。

ALT 設計書の形式が統一されていると楽なのだが……

ここまでのキーワード

【基本設計】  システムの基本的な動作や振る舞いが記述された設計書を作成する工程。業務フローとの関連やシステム利用ユーザーとの対話方法(画面入力や画面出力など)、使用するデータに関する情報など、システム外部(組織や人、データなど)とシステムそのものとの関係を決定していくため「外部設計」と呼ばれることもある。

 

  この工程の成果物として「基本設計書」が作成され、本文中にもあるように、その目次は各種各様だが多くの場合は次のような内容が記述されている。

 

(1) 業務フロー設計……誰がどのタイミングでそのシステムを利用するのかを、現実の業務に適用して表したもの

 

(2) データベース設計……今回のシステムが使用する(読み込む/出力するなど)データについて説明したもの

 

(3) 機能設計……システムが行う作業の内容について、ユーザーが直接は意識しない内部的なものも含めて説明したもの

 

(4) 画面設計……画面レイアウトなどのデザインや操作方法などのイメージを記述したもの

 

(5) 帳票設計……システムから印刷やファイル出力を行う場合に、印刷やデータ表示レイアウトなどのイメージを記述したもの

 

【詳細設計】 システムの内部的な動作や振る舞いが記述された設計書を作成する工程。「内部設計」と呼ばれることもある。プログラムの構造や詳細な処理の流れなどを決定し、開発者(SE・プログラマ等)もそのまま参照して作業できるような「詳細設計書」と呼ばれる成果物が作成される。例えば、機能設計時の画面設計では入力項目を「氏名」「メールアドレス」などユーザー視点で記述するのに対し、詳細設計時は「name」「mail_address」などのように開発するプログラム中で使用する機械的な名称も決定・記述する。

 

  基本設計/詳細設計の境界も業界基準があるわけではないが、発注サイドのユーザー部門に詳細な確認を求めるのは基本設計までであることが多く、詳細設計の確認となるとIT技術に強い情報システム部門が登場しないと難しいことが多い。



       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ