長谷川 裕行
（はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB
Magazineなどにも多くの記事を提供している。 |
業務分析によって資料を集め、開発するアプリケーションが対象とする業務の概要が把握できたら、それを元にして仕様書を作ります。文字、表、図などを用いて文書を作る作業は、一見プログラミングとは無関係のように思えます。しかしこの段階から、既に開発作業は始まっているのです。
どんなに優れた技術を持った大工さんも、設計図なしでは家を造れません。犬小屋なら可能でしょう。しかし人間の住む家は、犬小屋とは違います。同じようにアプリケーションも、人間が使う道具です。当然、それなりの構えが必要です。
ターゲット（開発対象）となる業務の調査を終えたら、それを元に仕様書を作ります。ここでもう一度、仕様書がどれほど大切なものかを説明しておきましょう。
- 「プロに任せろ」は昔の話 -
10年ほど前までのシステム開発は、以下のような流れで進められていました。
| (1) |
ユーザーがシステムエンジニア(SE)に要件を伝える |
| (2) |
SEがユーザーの要件に従いシステムのデザインを行う |
| (3) |
プログラマーがデザインに基づいてプログラムを作成する |
ユーザーは使う側、SEとプログラマーは作る側で、さらにSEは設計と全体の管理、プログラマーは実際の開発作業…と、仕事の分担が明確だったのです。簡単に言えば、「ユーザーは要望を伝えるだけで、後はプロに任せなさい」という形です。
しかし、深い専門知識なしでも扱えるVBという開発環境の登場で、事情は大きく変わりました。システム作りのあらゆる場面に、エンドユーザーが参加できるようになったのです。
- ユーザーの意志が明確に伝わる -
最近では、画面や入出力仕様、基本情報のコード体系といった部分にとどまらず、内部データの扱いなど「プログラムの一部」と言える部分にまで、ユーザーが意見を述べ、ときには自ら手を下したりするようになってきました。
もちろん、高度な技術を要する部分は専門家にお任せ…となるでしょう。しかし、ユーザーの作成したレコード記録済みのテーブルと入力用フォームを元にしてアプリケーションを作る――といった状況が、日常的になってきています。
ときには使い物にならない設計もあるでしょう。しかし、画面や帳票、基礎データといった土台の部分のデザインが、使い手の側から――それもソースファイルとして――提示されているという状態は、開発効率の面から非常に有利です。
それに少し手を加えれば実用になることもありますし、仮に直接利用できなくても、ユーザーの望むインターフェイスを知る手がかりになります。
- 仕事の数だけ仕様がある -
「販売管理」などと一口に言いますが、商品を販売する処理１つとっても、実際の仕事の進め方は業種・職種によって実に様々です。どの企業でもどのような職場でも、すべて同じ方法で仕事をしてくれていたら、システム作りは非常に楽な作業となるでしょう。
受注方法、伝票のデザイン、出庫手続き、入金方法…などなど、基本的な部分はどこでも同じように見えますが、細部は微妙に異なっています。そしてその異なりをカバーすることが、非常に重要なのです。
結果的に、業種の数、会社の数――細かく見ていけば担当者の数だけ――異なる仕様があると言っても、過言ではないでしょう。
- 「ユーザー＝開発者」も当たり前の時代 -
現在のシステム開発では、それぞれの分担が明確でなくなってきています。VBのように誰もが気軽に手を出せる言語では、ユーザーと開発者、SEとプログラマーの境界線もあやふやです。
特に、開発の初期段階で出来上がりの画面や帳票デザインなど外枠だけを提示する「プロトタイプ技法」が一般的になっているため、ユーザーの手が入る機会はますます広がっています。ユーザーが直接フォームのデザインを変更することもあり得ます。
組織運営の根幹に関わらない程度の処理なら、現場担当者が自力で開発――要するに「ひとりで開発」「ユーザー兼依頼者兼開発者」ということも、当たり前になってきました。
- １人開発なら仕様書は不要？ -
「ひとりで開発」「分業のステップが少なくなる」ということは、間に介在する人間が少なくなる（またはいなくなる）ということです。仕事を伝えるための書類も少なくなります。
伝言ゲームと同じで、仲介者が減れば減るほど情報は正確に伝わります。しかしその半面、「仕様書がない」あるいは「最低限の書類しか残らない」ということになりやすいのも事実です。1人で開発する場合には、「必要な情報はすべて私（開発者）の頭の中」ということもあります。
特にVBのようなRADツールでは、非常に感覚的にアプリケーションを構築していけるため、アプリケーション内部の詳細なメカニズムを論理的に記述することが、極めて難しくなります。
その結果、動作が間違っていればその場で修正――という、場当たり的な方法を採ることが多くなり、悪いことに、それでも何とか開発できたりします。
- １人開発なら仕様書は不要？ -
「ひとりで開発」「分業のステップが少なくなる」ということは、間に介在する人間が少なくなる（またはいなくなる）ということです。仕事を伝えるための書類も少なくなります。
伝言ゲームと同じで、仲介者が減れば減るほど情報は正確に伝わります。しかしその半面、「仕様書がない」あるいは「最低限の書類しか残らない」ということになりやすいのも事実です。1人で開発する場合には、「必要な情報はすべて私（開発者）の頭の中」ということもあります。
特にVBのようなRADツールでは、非常に感覚的にアプリケーションを構築していけるため、アプリケーション内部の詳細なメカニズムを論理的に記述することが、極めて難しくなります。
その結果、動作が間違っていればその場で修正――という、場当たり的な方法を採ることが多くなり、悪いことに、それでも何とか開発できたりします。
- 仕様書もプログラムの一部 -
しかし、こうして作られた「仕様書のない」または「わずかな資料しか存在しない」システムが、後々面倒を引き起こすことは目に見えています。組織は常に変化し、それに伴ってシステムの仕様も変わっていきます。
既存のシステムに手を加えようとしたとき、その手がかりとなるのは仕様書です。2000年問題を見れば分かるように、手を加える対象がどのような構造なのか分からなければ、修正のしようがありません。
開発担当者がいなくなってもシステムの中身が別の人物に把握できるよう、「どんなに小さなシステムでも、必ず仕様書を残しておく」ことが重要です。開発者は（特に優秀な人ほど）忙しく、書類作成にまでなかなか手が回りません。「私の本業は作ること」という気持ちは分かりますが、「書類作成もまた『作ること』の一部」と理解し、正確な仕様書を残すようにしましょう。
アプリケーションごとに仕様書の中身は異なっています。一口に「仕様書」と言っても、その実体は様々です。一般的な仕様書の概要を紹介しておきましょう。
仕様書は、大きく分けて以下のような７種類の書類から構成されます。
| ・ |
システム構成図
システムを構成する機器の配置やネットワークの構造を記述した図
|
| ・ |
システムを構成する機器の配置やネットワークの構造を記述した図
基礎データ、加工途中で必要なデータ、処理の結果生まれるデータなどを細かく分類した表
|
| ・ |
ER図
アプリケーションを構成する複数のデータ群が相互に関連する様子を示した図
|
| ・ |
コード体系一覧表
基礎データ識別用コードの意味や構成を詳細に明記した表
|
| ・ |
データ更新表
画面や帳票とテーブルの関連、データを更新するための要素などを示した表
|
| ・ |
画面仕様書／帳票仕様書
入出力用の画面や帳票を中心に、データの加工方法などを記述したもの
|
| ・ |
試験仕様書
プログラム単体および複数のプログラムを関連づけたテストの方法、チェック項目などを記載したもの
|
アプリケーションの規模や種類によっては、不要な書類や上記の他に必要になる書類もありますが、業務用アプリケーションでは、おおむねこれらの資料が必要です。最後の試験仕様書はほぼパターン化でき、それ以外は業務分析の結果を元に作成できます。
以下に、各書類の具体的な内容と、作成時の注意などを紹介しておきましょう。仕様書のサンプルは、PDFファイルとして保存してあります。併せて参照してください。お分かりとは思いますが、サンプルの項目やレイアウトはあくまで一例です。内容も帳票名も、このとおりである必要はありません。
スタンドアロンの場合は重要ではありませんが、ネットワークを前提とした場合、後々のシステム拡張やトラブル時の原因追求のためにも、ハード／ソフトの両面から全体像がわかるシステム構成図は重要です。
図1：システム構成図
| ・ |
ハードウェア構成
サーバーとクライアントのCPU、メモリ搭載量、ハードディスク容量、ルータやハブなどの関連機器とそれらの設定、設置状況、資源の共有状況など。
|
| ・ |
ソフトウェア構成
サーバーとクライアントのOS、コンピュータ名、ユーザー名、プロトコル、データベースエンジンとデータベースの位置など。TCP/IPネットワークの場合は、IPアドレスも明記しておきます。
ネットワーク環境では、1つのデータベースを複数のアプリケーションで共有することになるため、特にその構成を明確に記述しておきましょう。
|
サンプルを見れば、前回紹介した調査資料の「データ項目一覧表」と同じ構成だということが、お分かりいただけるでしょう。
調査段階ではユーザーからの調査結果をまとめることが目的でしたが、仕様書作成の段階では、調査結果を元にしてデータベーステーブルを設計するための資料となります。
テーブル設計を行うなかで、忘れてはいけない作業のひとつに「正規化」があります。細分化された項目を分類してテーブルにまとめ、それらを関連付けて意味のある形に仕上げていく作業です。つまり正規化とは、無駄のないテーブルデザインと合理的なリレーション設定を行うことです。
データ項目一覧表は、その際に役立ちます。以下のような形で重複項目の抽出などを繰り返せば、正規化が行われます。そうして生まれた資料を元に、テーブルとリレーションの設計を行えば、合理的なデータ構造ができあがります。
| (1) |
標準項目名の策定
調査結果を元に項目内容を判断し、異なるデータ集団に同じ意味の項目があれば、統一した項目名――標準項目名――を命名します。ここでいう項目が、テーブルのフィールドに該当します。
項目名を標準化しておくと、リレーションシップの設定も楽になります。また、設計者以外の開発者が、異なるテーブルの２つのフィールドを「同じ意味・同じ用途のデータ」であると判別することも容易になります。
|
| (2) |
項目のグループ化
１品１葉の伝票ならデザインは非常に簡単ですが、たいていの伝票は明細を複数行持つものです。経理では、１葉で貸方・借方それぞれに明細項目を複数行持つ――といった複雑な構成の伝票もあります。
このような伝票で、それぞれ複数回繰り返される同じ項目をグループとしてまとめたり、同じ意味合いを持つ項目を集めたりすることによって、一定の意味をなす情報のかたまりを作成していきます。
さらにこの作業を進めてグループを整理すると、ある程度テーブルとリレーションの基本型が出来上がってきます。ワープロの表作成機能や表計算ソフトを使えば、試行錯誤しながら検討を重ねられます。
|
| (3) |
参照項目の検討
商品や得意先の情報群は、たいていコード化されて管理されています。従って伝票上の商品名や得意先名も、コードを元にマスターテーブルを参照することで導き出されるようになります。日々の業務を記録するテーブルにはコードさえ記録されていればよく、名称などの具体的な情報は不要となります。
また、伝票の合計金額などのように計算結果によって導き出される項目も、演算フィールドで対処できるのでテーブルには含めなくて構いません。こういったコード(ID番号)などレコードを参照するために用いられる項目を「参照項目」、計算結果など自動的に導き出される項目を「導出項目」と呼びます。
参照・導出項目を検討することによって、項目の重複を防ぎ無駄な項目を排除できます。
|
データ項目一覧表をAccessなどのデータベースで作成すると便利です。調査の過程で拾い上げたたくさんの項目の名前と役割、データ型などを、テーブルに逐一記録していき、上記の検討過程をデータベース上で行うのです。
項目数の多い複雑な処理では、データベースの検索や集計機能を利用することで、重複する項目や関連する項目が簡単に見つけられます。
“ER”とは“Entity Relationship Figure”の頭文字をとったもので、「実体関連図」と訳されます。一部の専門書籍では「E-R図」などと表記されている場合もあります。
データベース関連雑誌や書籍でもよく紹介されているので、ご存じの方も多いでしょう。「個々の情報群を相互に関連付けて、１つの実体を表した図」のことです。
- Accessでも作れる -
少し形は異なりますが、Accessの「リレーションシップ」の表示もER図の一種だと言えます。
ER図の目的は「テーブルとテーブルの関連を明確にすること」ですから、データベースをmdbファイルとする場合は、AccessでER図を作ることも可能です。そうすれば、自動的に実際のリレーションもできあがってしまいます。
ただ、この方法には矛盾もあります。AccessのリレーションシップをER図代わりとして仕様書に使うということは、その前にテーブルのデザインとリレーションの設定が終わっているということです。つまり「仕様書が出来上がる前にアプリケーション（のデータ部分）を作り始める」ことになってしまいます。
このあたりは、関連する各種作業を同時進行的に進めながら、テーブル設計を見直してはリレーションを変更する――といった形になるでしょう。
ER図では、テーブルの配置を整理して結合線ができるだけ交錯しないようにしましょう。
図2：Accessのリレーションシップウィンドウ
|
|
- データの流れも示す -
本来のER図は、データの発生順に「右から左、上から下」へと、業務と情報の流れに従って作成するのが基本です。しかし、Accessのリレーションシップウィンドウでは単にテーブル間の関連が明らかになるだけなので、時系列的な処理の流れは明示できません。
そのためAccessを使う場合は、「どの処理でどのテーブルとどのテーブルの関連が必要となるか」「処理と処理のつながりはどうなっているか」といったことを、別の図として作成する必要が生じます。
要するに、データの流れと変化の様子を示すデータフロー図を、別途作成することになります。本来のER図をうまく作成すれば、そのデータフロー図の担当する情報までカバーできる訳です。
- コード体系一覧表 -
商品や社員などを識別するためのコード番号（IDフィールドの値）は、一般的な規則はある程度統一されているものの、実際の付定段階では組織によって運用方法がまちまちです。
- コード体系の独自規則 -
商品コードは一般的な市場流通品ならPOSで用いられるバーコードをそのまま利用できますが、業種や処理内容によっては、独自の規則・体系に基づいて付定される場合もあります。通販カタログに掲載されているメーカー独自の商品番号などは、メーカーごとにその付定規則が異なっています。
また商品や社員などの他に、アプリケーション内で用いる内部処理コードも必要となる場合があります。「現金は01、手形は03…」といった入金／支払区分、「光熱費は032、新聞図書費は039…」といった科目区分などです。これらには一応の基準はありますが、内部処理だけに用いる場合は必ずしも基準に従う必要はありません。特に過去に作られたアプリケーションを作り直すような場合、コード番号の独自規則に悩まされることもあります。
- コードの不統一は混乱の元 -
項目一覧表は、利用するコードのデータ型や桁数、意味などを説明するものですが、コード体系一覧表ではそれぞれのコードの構成要素・意味・有効範囲などを記述し、項目一覧表の説明を補足する仕様書となります。
社内の部署別分類や科目区分などのように固有の既定値を持つコード体系を設計する場合は、既定値とその意味も明記します。
これらは、すべて開発前に明確にしなければなりません。あいまいなままアプリケーションの開発に入り、必要になったら随時コードを付定する――といったやり方では、途中で混乱して訳が分からなくなることもあります。最終的に、完成したアプリケーションのバグとなることもあるでしょう。後々の仕様変更時にも苦労します。共同開発する場合、コード番号の統一は特に重要です。
- 将来の変化も見越しておく -
またコード体系は現状だけではなく、将来的な変化・変更も考慮しておかなければなりません。「得意先が少ないから得意先コードは３桁で構わないだろう」と思っていたら、１年後にユーザーの企業が大発展を遂げて得意先が1万件を超えてしまった――といった場合、内部処理どころかマスターテーブルへの登録さえ不可能になってしまいます。
効率的で余裕のあるコード体系を考えておきましょう。もちろん、現場ユーザーの声をしっかり聞くことが重要です。
- 桁数が多いと覚えられない -
通常、コード番号はドロップダウンリストの項目からユーザーに選択させる形となるでしょう。しかしユーザーが慣れてくると、主なコード番号は記憶しており、キーボードから直接番号を入力する方が効率的になります。
それを考慮し、あまり桁数の多いコード番号を設定しないようにしましょう。人間が主立った値を相当数記憶でき、違いを瞬時に識別できるのは６桁～７桁程度が限界です。８桁を超えると、途端に記憶件数と一瞥して識別できる件数が減り、作業効率が低下します。
そのため、１つの情報を表すコードを複数に分割することも考えなくてはなりません。例えば、顧客コードを８桁とする場合、地域コード、性別コード、生年など複数の値を組み合わせるようにすれば、ユーザーの負担を軽減できます。
単なる連番の場合：30024856
複数のコードに分割した場合：
地域コード＝30、性別コード＝02、生年＝(19)48年、連番＝56
VBでは、画面設計はフォームデザインそのものですから、いちいち別書類として作成せず、直接フォームデザインに入ってしまう人も多いでしょう。帳票も、帳票デザインツールを使えば同じです。
- 変更記録を残しておく -
画面と帳票を画面上で設計すれば、実際の処理画面（のダミー）や印刷プレビュー画面をユーザーに見せ、意見を聞きながら設計する際にも役立ちます。しかし、最初の設計が次第に変化していくことも十分あります。そのため、できるだけ書類として残しておくようにしましょう。
「検討と試行錯誤を繰り返した結果、最初の案に戻ってしまった…」ということもあり得ます（よくあります）。そのような場合に、過去の案を一望できるようになっていれば、無駄な試行錯誤の過程を省略できるでしょう。
- 画面コピーを仕様書に貼り付ける -
VBのフォームデザインや帳票設計ツールを使った場合、設計の都度画面をコピーし、画像ファイルとして保存しておくようにしましょう。画面キャプチャツールを使えば便利ですが、単にアクティブなウィンドウの画像を撮るだけなら、[Alt]+[Print Screen]キーで、クリップボードにビットマップ形式の画像データが取得できます。これをペイントなどで画像ファイルにし、仕様書の画面に貼り付けるだけです。
その際、各画面や帳票のデザインと共に、最低限の処理の概要と注意や特記事項などを書き記しておくようにします。さらに、クエリの構造やSQL文を追加しておけば、「どのテーブルのデータをどう加工してどこに持っていったか」が明確になります。
それぞれの処理と関連するテーブルをとりまとめ、データが加工される様子を一覧できるようにしたものです。ER図はテーブルの関連を知る上で有益な資料ですが、各処理とテーブルとの関連はER図だけでは把握できません。そこでデータ更新表によって、必要な処理と関連するテーブルをとりまとめます。処理を整理するという意味で「処理マトリックス」とも呼ばれます。
データ更新表を用意しておけば、開発時のテストや稼動後のトラブル発生時にも、原因となるデータがどの処理から発生したかをすばやく判断できます。
さらに、この表を画面・帳票・更新仕様書と組み合わせれば、データの加工されていく様子が時系列的に把握できるようになります。
以下のような手順で、先に大枠を作ってから詳細を書き込むようにするとよいでしょう。
| (1) |
流れに従って処理を記述する
ER図の説明でも述べたように、データの流れる順に処理を記述しましょう。規模の大きなシステムでは、受注、発注、仕入…などとサブシステムごとに区切ります。
|
| (2) |
処理内容を記述する
詳細な処理内容を記述する必要はありませんが、一目で何を行っているかが把握できる程度には記述しましょう。
|
システムが大規模になればなるほど、様々な落とし穴が発生します。それらをすべて設計時に予測することは困難（ほとんど不可能）です。そこで、開発途中や完成時に、システムが予想したとおりに動作するかを調べる作業が必要になります。
試験仕様書は、システムの動作が正しいかどうかを調べるための手引きであり、同時に試験結果のレポートともなります。
- 動作テストは重要 -
画面や帳票単位でのデバッグ(不具合の発見と修正作業)は、どんな開発でも必ず行われますが、システム全体を通してのデバッグは実施に手間がかかり、なかなか実施されないこともあります。
開発規模が大きければ大きいほど、テストにはしっかりとした計画を立てる必要があります。人間は、自信があればあるほど、あるいは「早く終わらせたい」という気持ちが強ければ強いほど、「この部分は大丈夫だ」という思い込みを抱くものです。メンバーが多くなれば、「大丈夫だと思い込まれた箇所」も多くなります。そうやって、見落とされた不具合が蓄積されるのです。
- 単体試験と総合試験 -
動作テストには、システムを構成する個々の機能単位で行う「単体試験」と、システム全体で行う「総合試験」があります。小規模なシステムでは総合試験だけでも構いません。
| ・ |
単体試験書
画面や帳票ごと、あるいは「受注」「入金」など、一定の小さな処理単位ごとに試験仕様書を作成します。
試験の内容は、かなり細かな事柄にまで展開した項目を記述し、１つ１つの動作とともにインターフェイスに関する部分までチェックします。正常に動作するかどうかだけではなく、使いやすさや見やすさといったユーザーインターフェイスや、タブオーダーの問題などもチェックしておきましょう。
|
| ・ |
総合試験書
単体試験書とは異なり、それぞれ個別のプログラムを処理の流れに従ってリンクした状態でのテスト項目を記述します。つまり、実際の使われ方にかなり近い状態での動作テストとなります。
単体試験では一時的なデータを作成しテストを行えばよいのですが、総合試験では上流の処理から下流の処理へと、あるステップでの出力が次のステップでの入力となるような「実際の処理の流れ」を確かめなければならないので、それなりに「本番に近い」テストデータを用いる必要があります。
このテストでは細部にこだわらず、「入力したデータが目的に沿った形できちんと出力されるか？」といった全体的な処理の流れに着目します。
|
- 修正履歴を付ける -
テストを終え問題点が発見されたら、それを修正します。修正後にまた同じテストを行い、問題点が解決されたか確認します。これを繰り返して、最終的な完成となります。
試験結果と併せて、措置内容も必ず記録しておきましょう。また、修正の履歴も必ず残すようにします。気が付くと、同じエラーと同じ修正を繰り返していた…ということもあります。問題点の修正は、特に履歴を採っておくことが重要です。
業務分析と仕様書の作成という、パソコン書籍ではあまりお目にかかることのない作業について、その一般的な進め方、取り組み方を紹介してきました。まとめとして、調査・分析と仕様書作成で気を付けておきたい点を挙げておきましょう。
- プロトタイプを活用する -
プロトタイプとは完成見本のことです。内部処理が未完成のまま、取り敢えずユーザーインターフェイス部分だけを仮に仕上げ、出来上がりのイメージと操作感などをユーザーに提示するために用いられます。
一般的にプロトタイプは、仕様書の作成後、実際の開発工程に入る前に、最終的な仕様確認のために作成されます。しかし、VBのようにユーザーインターフェイスを簡単に設計できる開発環境を使う場合は、仕様書作成の前――つまりインタビューと資料収集を終えて業務を分析し、開発者の頭の中に完成したアプリケーションのイメージが沸き上がってきた時点――で作成し、ユーザーに提示する方が効率的でしょう。
仕様書の作成後、開発の途中にプロトタイプを提示してユーザーに了解を得る必要もあります。要するに数回に分けてプロトタイプを作り、何度も確認をするのです。
VBなら、ユーザーに見せたその場で要望を取り入れ、修正することも可能です。何段階にも分けてプロトタイプを見せ、ユーザーの意見を取り入れていけば、ユーザーの要望に沿ったアプリケーションを作れます。また、ユーザーに安心感を与えるという効用もあります。
- 全体を見越して設計する -
大規模で複雑な業務をアプリケーション化する場合、いきなりすべての機能をユーザーの要望どおりに実現することが、時間的にもコスト的にも無理な場合があります。機能と開発工数は、１つ機能が増えれば開発工数が数倍になる――という、等比級数的な関係です。
そのような場合、「最初はひとまず基本機能だけを実現し、ある程度運営してから徐々に機能を付け足す」という形で開発を進めることもあるでしょう。すると、仕様書は必要な機能だけを盛り込んだ「取り敢えず」のものとなります。しかし、業務分析の段階では、その先の追加された機能までを見越しておく必要があります。
「現時点での仕様」を満たしていても、先々の仕様変更に耐えらるとは限りません。大き過ぎる器を縮めることは簡単ですが、小さな器を広げるのは難しいものです。
「いずれ機能拡張される」ということを最初の段階で見越しておくかおかないかで、後々の手間の大小が大きく左右されます。ひどいときには「これ以上機能拡張するなら、いっそ頭から作り直した方がまし」といった状態になることもあります。そういった無駄を省くためにも、初期段階の設計が非常に重要だと言えます。
- 変更箇所は必ず記録する -
特に複数のメンバーで作業する場合、変更箇所の記録は必須です。初期段階の仕様書は作っても、途中で変更した箇所は記録されていない――という場合が非常に目立ちます。その仕様書は「仕様の原形」「仕様書らしきもの」でしかありません。
仕様書は設計図であるだけではなく、後々の保守や改造にとっても必要です。特にたくさんの機能を盛り込んだ複雑なシステムでは、一部の小さな変更が他の処理に影響する可能性も十分あります。オブジェクト指向だ、コンポーネント化だと言葉は飛び交っていますが、大がかりなデータベースアプリケーション、ましてネットワークがらみともなると、他から完全に独立した機能を矛盾なく組み上げることなど、およそ不可能に近いワザです。
仕様書作りと変更箇所の反映も「仕事のうち」だということを、全員に徹底しておきましょう。
３年にわたって続けてきた「業務アプリ構築法」も、今回で終了となりました。最初の頃の記事は旧バージョンを対象としたものですが、「VBでデータベースを利用した業務用アプリケーションを作る」という観点から見れば、どれも現在十分に通用する情報です。
すべてを通してお読みいただければ、VBの基本からデータベースの扱い、フォームのデザインからプリンタ制御まで、一通りのテクニックと考え方がご理解いただけるものと自負しています。是非もう一度、最初から読み直してみてください。
長い間ご愛読くださり、ありがとうございました。近いうちに、またお目にかかれることを期待して、筆を置きます。
2001年４月 長谷川裕行
 PDF形式の仕様書の
ダウンロード（Ex36.LZH）
(LZH形式 810KB) |
