TOPプロジェクト管理> 設計

だからあなたの会社のシステムは動かない
〜システム発注担当者の悩みを解決します〜

第2回:システム開発の流れ

著者:システムクリエイト  田中 徹   2004/11/26
前のページ  1  2
設計

  システム化する範囲、機能が決まればいよいよ設計段階に入ります。設計はまず全体的な設計を行い、データベースや共通ファイルなどの設計、各機能ごとの設計、プログラム単位の設計と進んでいきます。開発会社が設計を行うときには、発注側と蜜にコミュニケーションを図りながら行います。発注担当者が意見を言うときはこのときです。積極的に要望を伝えてください。

  たとえば、検索機能について「どんな検索があるか使ってみないと分からないので、柔軟性を持たせて欲しい」と言うのと「特定のパターンでしか検索しないので簡素化して欲しい」と言うのでは、データベースの設計が違ってきます。言うべきことはどんどん言いましょう。ただし、要望がすべてシステムに反映されるというものでもなことは知っておいてください。

  使いやすいシステムかどうかという評価は、ユーザーインターフェースに左右されることも少なくありません。いくら優れた機能を持っているシステムでも、操作性が悪かったり、見づらい画面では、使う人の評判が良くありません。特に操作画面では共通性を持ち、使う人に合わせたものが良いでしょう。不特定多数の人が使う画面と、専用のオペレータしか使用しない画面では、「使いやすさ・分かりやすさ」の意味が違ってきます。発注側からの要望は出せば出すだけ開発側はありがたいものです。

  こうしたヒアリングを経て、「基本設計書」「外部設計書」「環境構築」「開発環境」「コード体系」「データベース設計書」「プログラム設計書」と呼ばれる設計書を作成します。これらをまとめて仕様書と呼びます。発注担当者がいきなり設計書を見ても書いてあることが分かりにくいかもしれませんが、経験を積めば分かってくるものです。遠慮なく担当SEに聞いて、何が書かれていて、どういう意味なのかを知っておいてください。

  システム(=プログラムの集合体)という目に見えないものを買うわけですから、目に見える設計書は理解しておきましょう。
仕様書の作成
  仕様書というと、「専門家がつくる専門家のためのもの」と思いがちですが、それは間違いです。「専門家が作る普通の人が理解できるもの」であるべきです。ですから、発注担当者が理解できないような仕様書は「良い仕様書」とは言えません。分からないことはどんどん聞いて、必要があれば修正してもらいます。開発会社に「あの会社はドキュメントに関しては非常にシビアだ」と思われるくらいでちょうどいいのです。システムの規模が大きければよりドキュメントの重要性は増します。

動かない理由


製造

  設計が終われば、製造工程(プログラミング)に入ります。プログラマはプログラム仕様書を元に作成するわけですが、特に最近のプログラム開発環境では、プログラム設計書もなしでいきなりプログラミングを始めることもあります。そういう場合でも、後追いで必ずプログラム仕様書は作成してもらうようにします。これがないと後々非常に困ることになります。



テスト

  設計書通りプログラムがすべて作成され、データベースや環境設定も構築できるとシステムテストを行います。テストも段階的に行います。まず、プログラム単位でのテスト(単体テスト)は製造工程で行います。次に機能ごとのテスト(結合テスト)を行い、最後にシステムテストとして全体的なテストを行います。システムテストは可能な限り、本番と同じ環境を用意して行うことが望ましいです。

  テストにあまり時間をかけないプロジェクトをよく見かけますが、出来る限り時間をかけ十分なテストを行ってください。ある機能について、一通りテストが終われば、繰り返して行う耐久性や、複数ユーザテスト、時間帯を変えて行うなど、様々なケースを想定して行います。システムテストを行うためには、テスト仕様書と呼ばれるものを開発会社が用意して行います。発注担当者としては、そのテスト仕様書が適正であるかどうかをチェックしなければなりません。開発前に作成した用件定義書が活きてきます。最低限、用件定義書に書かれたことについてはテスト仕様書になくてはなりません。
テスト仕様書の作成
本番開始前

  本番開始前には、社内でシステムに一番詳しくなっているのは、発注担当者でしょう。発注担当者の音頭で社内教育を行います。開発会社に依頼して協力してもらうことも可能ですし、操作マニュアル、教育マニュアルなども開発の一部として作成してもらうことも必要なことです。運用マニュアルに関しては、実務的とシステムの両面が関わってきますので、発注側と開発側の協力で作成することが多いようです。
操作マニュアル、教育マニュアル、運用マニュアルの作成
この連載は、ユーザ企業のシステム発注担当者向けのものです。発注担当者の方で、悩みを抱えられている方は、編集局までメール<info@thinkit.co.jp>でご相談ください。この連載を担当している田中徹氏がその解決法をお答えします。
※全てのご相談にお答えできるわけではありません。予めご了承ください。
前のページ  1  2



著者プロフィール
システムクリエイト有限会社  田中 徹
代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート(金融業)、表・グラフ描画(財務系)などのシステム開発を行う。 社内人事管理(勤怠・人材活用)、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中


INDEX
第2回:システム開発の流れ
  ドキュメントの必要性
設計