基本設計に必要なのは全体視点 情報システムをまとめる基本設計とは?
基本設計とは情報システムを作る工程の一つで、情報システム全体を機能単位に分割して、それぞれの機能がどういうものか、どういうことができるものか、機能同士がどうつながるのか決めていく作業です。基本設計を行うタイミングは、要件定義の後、詳細設計の前になります。
基本設計とはどういうものか…については、全ての関係者が納得する一つだけの答えはありません。なぜなら、情報システムを作る作業には、法律や業界団体などで決められた、決定版ともいえる手順や成果物がないからです。情報システムを作る人、プロジェクト、会社、方法論ごとに作業の仕方が違うのです。
それでも、広く共通しているのは、基本設計は情報システムの具体的な姿を、全体的な観点で考え始める工程だということです。要件定義で決められた、情報システムで実現しなければならないことを、どうやって具体的な画面・帳票・バッチ処理・データベースで実現するかを、みんなで考えるのです。
この記事では、基本設計とはどういうものかを、情報システム構築の初心者向け、情報システム構築に興味がある方向けに、分かりやすくお伝えします。
１．基本設計では情報システムの全体像を考える
１-１．基本設計は何をどう作るかを決めるもの
基本設計は、情報システムを実現するために何をどう作ればいいのかを決める作業です。情報システムを作る作業の中では、要件定義の次にある作業です。
基本設計では以下のようなことを行います。
- 情報システムの画面や帳票、バッチ処理などの作るべき機能を全て洗い出す
- それぞれの機能が、どういうことをする機能か明確にする
- 機能の間の関係性、特に入出力するデータを明確にして、情報システム全体で業務をどう行うか決める
- 情報システムで持つデータを、どういう形式・項目として扱うか決める
- 連携先の既存情報システムとどんなデータをやり取りするかを決める
- どんなハードウェアやミドルウェアを組み合わせれば、要件が実現できるか考える
１-２．基本設計のインプットとアウトプット
基本設計のインプットは要件定義書です。情報システムを作る工程の最初は要件定義で、そのアウトプットが要件定義書です。基本設計のアウトプットは、その後の詳細設計のインプットになります。
基本設計は、要件定義書にある情報システムとしてのあるべき姿を実現するために、どういう方法で具体化するのか、どういうものを実際に作らなければならないかをプログラムを作り始める前にしっかりと決めて、アウトプットとして形にする作業なのです。
基本設計は情報システムとしての大枠、全体像、アウトラインとも言えるものを決める段階ですから、どのようなモノを使って実現されるか…例えばどのようにプログラミングされるかとは、少し距離を置いた抽象的なポジションで考えます。
１-３．基本設計はお客様と完成形をすり合わせる最後の機会
基本設計は、お客様がSIerに注文した情報システムがこうなるはずだという姿を、お客様自身が確認できる最後の機会であることが多いものです。
基本設計が進んでいく中で、画面の流れや帳票のイメージ、それらを使った業務の流れが分かるようになった時点で、お客様にレビューをしていただきます。レビューでのお客様からの指摘事項や情報システムへのご要望は、基本設計のアウトプットに反映して再レビューします。こうして認識のずれを防ぎます。
なお、お客様がIT企業の情報システム部門など、情報システムの知識がある人たちなら、詳細設計以降のアウトプットを都度確認することも普通です。でも、ITの知識がないお客様だと、情報システム構築の知識がないことが当たり前なので、詳細設計以後のアウトプットを理解することが難しくなっていくのです。
１-４．外向けの設計と内向けの設計
知っておいていただきたいのは、基本設計は情報システムが形作られるべき姿を、情報システムの外から眺めたものと、内から眺めたものの二つの観点から作るものだということです。
外から眺めたものとは、例えば画面のデザインや画面間の遷移、出力される帳票のレイアウト、関連する情報システムとのデータのやり取り、そして情報システムを使った業務の流れです。ですから、情報システムが形になった後、お客様がこういうように使えるようになるはずだ、というものでもあります。
内から眺めたものとは、情報システムの作られ方に関係するものです。お客様が使う画面の裏には、画面を表示するためのプログラムやデータを保存するデータベース、そしてシステムとしてそれらがどう組み合わさるかという、いわゆる「アーキテクチャ」があります。基本設計はそれを決めるものでもあります。
２．基本設計のアウトプット
基本設計で作るアウトプットは、大体は以下のように分類されます。もちろん、現場やSIerにより呼び方が違いますし、どんなやり方で情報システムを作るかで、作る必要があるものも変わってきます。例えば、オブジェクト指向分析がベースの開発方法論なら、これ以外にも作るものがあります。
基本設計では、要件定義書の内容から、情報システム全体を機能に分割・分類して、それらの機能レベルで情報システムではどういうことをどう行うかを考えます。同時に、情報システム上でデータをどう持つか、連携先のシステムとはどう連携するか、どういうハードウェアやネットワークとするかも考えます。
そして、基本設計の時点では、各機能や処理にはどういう入力があり、どういう処理が行われ、どういう結果が得られる…という「流れ」を重視します。ですので、基本設計では処理の詳細までは踏み込まず、「この機能はこういうことができる」という観点で設計を進めていきます。
２-１．システム全体の機能を一覧化し、流れをまとめる
アウトプット：機能一覧、業務フロー図、データフロー図、入出力関連図など
基本設計でまず作るものは、情報システムを形作る機能の一覧です。基本設計が終わった時点では、情報システムで作るべきモノが全体でいくつあるのかが、具体的な数字でわかるようになります。この機能の一覧は、基本設計の作業の進み具合や、情報システムの規模を正確に把握するためにも欠かせません。
この「機能」の単位はいろいろです。画面、帳票、バッチ処理、APIなどの同じモノの単位で一覧を作ることは普通ですし、もっと上位の「業務」とでも呼べるものでグループ化した上で、その中にはどんな画面、帳票、バッチ処理、APIなどのサブ機能があるのか…という風にまとめることも普通です。
前述したとおり、機能の一覧は基本設計の最初に作り始めますが、最初から全ての機能を一覧にはできません。要件定義書を見ながら、「この業務はこれとあの画面を使ってこうやるから…」とか「このデータを作るにはこの処理が前にあって…」という検討や試行錯誤をしながら、だんだん育てていくものです。
２-２．画面の役割と画面のつながりを業務視点で考える
アウトプット：画面一覧表、画面遷移図、画面設計書、項目定義書(画面)など
情報システムの「顔」がいわゆる画面です。基本設計では、どういう画面があるのか、その画面では何ができるのか、その画面にはどういう項目があってどう表示されるのか、画面間の繋がりはどうなのかという設計を行います。要件定義である程度作られている画面を、さらに明確にすることも普通です。
この作業では、画面のレイアウトや、例えばボタンをクリックした時には情報システムがどんな動きをするのか(表示の更新、データ保存など)を決めます。そして、情報システムは複数の画面を持つことが普通ですから、それらの画面遷移がどういう条件でどういう時に行われるかなども明確にしていきます。
そして、画面は情報システムを使うお客様がいつも使うものですから、どういう画面にするかでお客様の情報システムへの印象が大きく変わります。ですので、ユーザインターフェイス(UI)の専門家や、最近はユーザ体験(UX)の専門家も交えて、喧々諤々な議論が行われることもあります。
２-３．どんな帳票をいつどうやって出すかを考える
アウトプット：帳票一覧表、帳票設計書、項目定義書(帳票)など
情報システムに欠かせないのは帳票です。前述した画面も広い意味では帳票の一種だと言えますが、ここで言う帳票は受注伝票や入金伝票などの業務上必要になるものや、PDFやExcel、CSVなどで売上高などの集計値を提供したり、お客様がデータをダウンロードして二次活用できるようなもののことです。
基本設計で考える帳票設計では、いつ、だれが、どんな情報を、どういう形式や書式で、どこから出力するか決めていきます。帳票は画面で入力する検索条件やデータベース設計にも密着していて、関連する機能を一緒に考えながら徐々にブラッシュアップしていくものなので、最初から決定版は作れません。
基本設計で帳票を考える時は、まだこの時点では動くモノはないので、基本的には全て机上の紙や設計者の頭の中で考えます。どうやって帳票を作るのかのロジックはもちろん考えますが、画面の入力条件がこうで、こういうテーブル構造ならこの帳票はこう作れるだろう…という「予想」の元に作業が進みます。
２-４．バッチ処理をシステム全体視点で考える
アウトプット：バッチ処理一覧表、バッチ処理フロー図、バッチ処理設計書など
情報システムでは、画面や帳票以外の処理、いわゆるバッチ処理があります。バッチ処理は情報システムの裏で動き、お客様の目には直接触れませんが、画面や帳票を情報システムが提供するには欠かせません。さらに、バッチ処理がうまく流れるかは、情報システムでの業務が上手く流れるかとイコールです。
基本設計では、どういうバッチ処理があるか、それぞれのバッチ処理ではどういう情報を入力として何を出力するか、どういうタイミングで動くのか、バッチ処理同士の前後関係、連続するバッチ処理が途中で異常終了したらどうフォローするか…などを決めていきます。
バッチ処理を考える上で大事なのは全体視点です。一つ一つの処理は入出力や処理がわかりやすいように上手に分割して、それをうまく組み合わせて大きな一つの処理結果をどうやって作っていくかを考えます。ですので、細かいことを考えて組み合わせるのが好きな人は、バッチ処理が面白いかもしれませんね。
２-５．データベースで持つデータを考える
アウトプット：テーブル一覧表、テーブル設計書、ER図、CRUD図など
今まで説明してきたのは「処理」でした。でも、処理だけでは情報システムは作れません。情報システムで扱うデータをどう保存し、必要に応じて検索結果としていろいろな処理へどう提供するかを考えなければなりません。ここで行うのは、いわゆるデータベースの設計です。
基本設計でのデータベースの設計は、どのような種類のデータベースを使うのか、使うと決めたデータベースでどのようにデータを管理するのかを決めます。最近はリレーショナルデータベース以外のプロダクト(いわゆるNoSQLなど)も普通に使いますので、その関連知識も基本設計では求められることがあります。
例えば、一般的なリレーショナルデータベースを使うなら、要件定義から抽出したデータからテーブルを考え、どのような項目を持つか、インデックスにはどの項目を使うのか、テーブル間の関係がどういうものかなどを決めます。大きな情報システムなら、全体で数百以上のテーブルになることも普通です。
２-６．システムの要件を実現できる構成を考える
アウトプット：システム構成図、運用設計書など
情報システムは、今までお伝えしてきたアプリケーション側の領域と、サーバ・クライアントPCなどのOS・ハードウェア、ネットワークなどのインフラストラクチャ(Infrastructure、いわゆるインフラ)側の領域の二つから作られています。どちらが欠けても、情報システムは動かせません。
基本設計では、インフラ側の担当者がアプリケーション側の担当者と一緒に、どのようなハードウェアやネットワークの構成にすれば、要件定義で決められた処理性能や可用性や運用性などのいろいろな要件・非機能要件を満たすことが出来るかを考えます。それらにかかるコストも、欠かせない検討項目です。
処理速度やデータを保存する領域の余裕をどのくらい持つか、情報システムの将来の拡張性はどう確保するか、ハードウェアの故障が発生した時はどうするか…など、インフラに求められるほぼ全てを基本設計の時点で予測し、対応方針を決め、必要なものを確保・発注するのです。
関連記事
２-７．考えたことがきちんと全てつながるかを考える
ここまでの記述で、「全体視点」という言葉が何回か出てきました。基本設計を行う上では、作業を行う人にこの全体視点があるかがとても大事です。何かの機能に偏った狭い視野ではなく、情報システム全体視点での広い視野が、基本設計でのアウトプット間の矛盾を見つけ出すのに必要となるのです。
基本設計では、まだプログラムとしての形が何もない時点で、最終的に出来上がる情報システムを想像しながら、全てが最後には一つにつながる前提でいろいろなアウトプットを作ります。なので、業務知識、予測能力、想像力、論理的思考能力、問題領域の把握能力というようなものが、担当者には強く必要です。
しかも、情報システムの規模が大きくなればなるほど、全体像の把握は急激に難しくなります。そのような情報システムの基本設計を取りまとめるには、大変な労力が必要になるのです。
３．要件定義と基本設計と詳細設計の違い
この章では、情報システムを作る当事者以外の人、あるいは当事者であっても混乱しがちな、要件定義と基本設計と詳細設計の一般的な違いをお伝えします。
要件定義と基本設計と詳細設計は、いずれも情報システムのあるべき姿を考えるという、広い意味では設計の作業です。そして、情報システム構築の方法論は世の中にはたくさんあり、それらの中では必要なアウトプットをどの工程で作っていくのかがずれていることも多いものです。
ですから、いくつかの現場や情報システムを渡り歩いた人は「なぜこの現場ではこのアウトプットをこの工程で作るの?」という疑問を持ったりもしますし、同じ「基本設計」と呼ばれていても、作るものの内容や記述するレベルの認識が合っていなかったりするものです。
３-１．違いは誰向けのアウトプットであるか
要件定義と基本設計と詳細設計の違いは、誰向けのアウトプットなのかという観点が最も大きいと思われます。
要件定義はお客様と情報システムのあるべき姿を合意するためにあります。ですから、お客様が理解できる言葉や図を使います。
基本設計は、要件定義の内容を情報システムの言葉に置き換えたものであり、どういう情報システムになるかを決めるものです。ですので、お客様が出来上がる情報システムを確認するためにも使いますし、SIerがどういうシステム構成にするかを明確にするものでもあるのです。
詳細設計は、完全にSIer側の言葉になります。プログラムに落とし込まれる直前の状態ですから、使われる言葉や図も専門的なものになり、プログラマが読み込んで、出来上がるプログラムがイメージできる程度にまで、情報システムが動くべき手順が詳細に書かれるものです。
３-２．小さな案件ではこれらの区別はあまりない
SIerが情報システムを作る時は、大体はこのような区別をして、工程の説明をお客様にするはずです。ただ、大規模な情報システムならまだしも、小規模なものならこれらの作業は一体となっていることがあります。お客様との「距離感」と言うべきものが近ければ、それでも十分だというケースも多いでしょう。
要件定義～基本設計～詳細設計と続く作業の流れは、ウォーターフォール型の情報システム開発の典型例ですし、批判も多くあります。ですが、「何をどう作るのか」を段階的に明らかにして、なるべく手戻りがないように進めるのは、情報システムを作る上での王道ですし、何にしろ必要なことでもあります。
結局は「何をどう作るのか」が明確になっていて、お客様と合意がされていればいいのです。開発方法の主流の一つになりつつあるアジャイルも、誤解を恐れず言うなら、お客様とSIerの距離を近くすることで認識齟齬が起きづらい開発体制を作って、素早くモノを作る、ということです。目的は変わりません。
３-３．外部設計、内部設計との関係
基本設計を外部設計、詳細設計を内部設計と呼ぶことがあります。
基本設計では、情報システムを「外」から見た時の姿や動きを決める成果物が多いからです。一方、詳細設計では情報システムの外面が決まった後に「内(なか)」がどうあるべきかを細かく決めていくので、内部設計と呼ぶのです。
ただ、繰り返しですが、情報システムを作る作業に関係する言葉は、同じ言葉でもSIerなどの文化や方法論で指すことがかなり違うので、どういう意味か有識者に確認しておいた方がいいでしょう。
４．基本設計を行う上で大事なコト
この章では、基本設計をする上で押さえておきたい注意点や心構え的なものをお伝えします。基本設計が上手くできていないと、後の工程が全て上手くいきません。これらは、そういう悲劇を少しでも少なくするために、基本設計の担当者が知り、意識しておくべき事柄です。
大事なのは、全体視点を持って作業をすること、前工程である要件定義との整合性が取れていること、自信を持って作ることができるものであることです。そして、基本設計の時点では完全無欠なアウトプットは残念ながら作れませんので、手戻りがあることを前提に作業を行うことも意識しておきたいです。
４-１．全体視点を持っていること
基本設計では、情報システムへの「全体視点」が欠かせません。この全体視点には、情報システムの機能全体を見渡し把握するための、高く広い視点の他にも、お客様の視点、SIerの一員としての視点、詳細設計・製造・テスト・構築・運用・保守をする要員の視点…という全関係者の立場での視点も含みます。
「この人の立場では、この情報システムはどう見えるだろう、使い勝手はどうだろう」という視点は、情報システムを作る最初、つまり基本設計の時点で組み込まれていなければなりません。その視点のない情報システムは、要件を形や見た目だけにただ単に反映したものに過ぎず、「使える」ものではありません。
全体視点を持つ、視点を切り替えるには意識的な訓練が必要です。そして、その立場で仕事をした経験が実際にあるなら、さらにいいでしょう。ですから、基本設計に限らず上流工程の要員は、何かの領域に熟達している以外にも、今まで情報システムに関するどういった仕事をしてきたかが、必ず問われるのです。
４-２．要件定義とずれていないこと
基本設計が要件定義とずれていないかは、とても大事なことです。基本設計に書かれていることは、元をたどればすべて要件定義のどこかの記述にたどり着く、というくらいでなければなりません。それくらいしっかりと基本設計を作って残せば、お客様も含め、後に関わる人がすべて幸せになれるのです。
今までお伝えしてきたとおり、要件定義はお客様の言葉・視点での情報システムのあるべき姿であり、基本設計はSIerの言葉・視点での情報システムのあるべき姿です。基本設計の時点で要件定義から言葉の「翻訳」が行われるので、要件定義と基本設計がずれていると、後工程の成果物が全てずれるのです。
基本設計は、情報システムで何か分からないことがあった時の拠り所です。情報システムを作る時だけでなく、運用する時も、障害が起きた時も、改修する時も、次の情報システムに移行する時も、そのすべてにおいてです。情報システムに関わる人は移り行きますが、基本設計は常にそこにあり続けるものです。
４-３．実際に作れるものであること
基本設計をする時は、まだ具体的な形がないだけに、いろいろと内容を盛り込みがちです。しかし、基本設計は「こういうことができたらいいな」ではなく、「こうすればできる」「こうしなければならない」という明確な根拠ありきで進めるものです。そうしないと、実際には作れない情報システムになります。
過去に担当した情報システムでの反省を生かして、今回は同じ失敗はしないという意識を持つことは大事です。最近は既存の情報システムの改修や統合が多くなっていて、新しく情報システムを作る機会は減っているので、基本設計をする時にそう思うのは当然ですし、前のめりにもなるのは分かります。
ですが、情報システムは基本設計をする人の私物ではありませんし、趣味や嗜好や主義で作るものでもありません。情報システムはチームで作るものです。何かの設計には必ず明確な理由・意図があって、設計・製造をする人たちの間で合意が得られていて、かつ実際に作れるものでなければ意味がないのです。
４-４．設計の手戻りがない、はありえない
情報システムを作る仕事を続けていると、手戻りの無い工程はありえないことが分かります。理想は前工程の精度を上げることですが、現実には限界があり、手戻りゼロは不可能です。実際にやらないと分からないことはいまだに多いのです。設計の工程は特に、机上や頭の中だけの考えなのでなおさらです。
手戻りがあることを前提に、取り得る選択肢や代替手段を考えておくのも、基本設計でやるべきことです。さらに設計上のリスクに関しては、基本設計の時点でお客様に伝え合意することも大事です。手戻りが発生しうるという現実に、どれだけ予測し準備できるかが、マネージャやSIerのノウハウであり実力です。
そして、基本設計後に詳細設計や製造をする際、設計上の問題を見つけたとしても、絶対に基本設計を変えてはならないわけではありません。設計は都度変わっていくものです。設計の変化に情報システムが追随するのは大変難しいのですが、避けられないことなのですから、準備はしておかねばならないのです。
４-５．設計作業にこそエンジニアのスキル・実力が問われる
エンジニアのスキル・実力が本当に問われるのは設計作業です。情報システムでもプログラムでも、何かを作り始める前には対象の全体を把握し、矛盾なく取りまとめる必要があります。それには、一つの技術領域だけ知っていても駄目で、情報システムを形作るモノをバランスよく知り、経験する必要があります。
どんな人でも情報システムを作る作業に関わる時は大抵、製造やテスト、運用の工程から入ります。これは、具体的な作業手順があったり、作るものが明確な工程なので経験が少なくても作業しやすいからですが、同時に情報システムがどういうものかを具体的に知る機会を与え、経験させるためでもあります。
いずれ要件や設計などの上流工程やマネジメントの仕事を目指したい…という人でも、実際の構築作業や運用作業の経験は、絶対にしておくべきです。その経験や知見があなたを分厚く鋭くしてくれますが、その時にはただの作業としてではなく、知らないことを何か一つでも学ぶ・知るという姿勢を持つべきです。
関連記事
５．さいごに
基本設計は、情報システムのあるべき姿をベンダの言葉で作り上げてまとめる、とても大事な工程です。基本設計がお客様と合意されれば、お客様はそれが実現されるものと期待しながら、情報システムが出来上がるのを待ちます。基本設計は、お客様とベンダとの間での最後の約束ごとだと言ってもいいでしょう。
基本設計が上手くいくかは、基本設計を行う担当者の実力とスキルと意識の持ち方次第です。方法論はそれを補うものでしかありません。基本設計のレビューを行うチームやプロジェクトやベンダの総合力も問われます。また、基本設計ができる要員がいるかどうかが、情報システム構築の成否を分けるのです。
基本設計を上手に出来る力を持つ要員を育てるには、長い時間と広い経験が必要です。長期的な視点での人材育成を我慢強く行えるかが、情報システムを提供するベンダの将来を左右する重要なことでもあります。必要になって初めて慌てて周囲を探してみても、そういう要員を見つけることは難しいでしょう。
自分の仕事の領域を、設計工程やもっと上流に進めたいというエンジニアは、普段から情報システムの設計とはどういうものか、どうあるべきかを強く意識して、普段の仕事や作業に取り組み、情報収集しましょう。設計とは、製造やテスト、運用の延長線上にあるように見えて、かなり違った領域の仕事なのです。
コメント