長谷川 裕行
（はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB
Magazineなどにも多くの記事を提供している。 |
Visual Basicによる業務アプリケーションの開発技法を、一通り紹介してきました。最後に番外編として、業務分析と仕様設計の手法を紹介します。
業務分析とは、文字通り、アプリケーションの対象となる業務を分析する作業で、これによって情報の流れと加工の様子を明確にします。分析結果に基づいてアプリケーションの仕様を作成し、骨格部分を組み立てます。
この２つの作業は、実際にコーディングを行う前に必要な準備作業です。準備をおろそかにしてはいけません。アプリケーションの使い勝手やその後の保守性の大半は、この準備段階で決まってしまいます。
仕様設計とその前段階の業務分析がどれくらい重要な作業か、まずそのことを理解しておきましょう。
- 事前準備が大切 -
このコーナーでは、主にデータベースを使用したアプリケーションの開発テクニックを中心に、様々な情報を提供してきました。
「アプリケーションの開発」というと、どうしてもVBまたはその他の開発ツールを起動し、フォームのデザインやコーディングを行う場面を想像しがちです。しかし実際の開発作業では、それは全開発工程の中のごく一部であり、順序としては最後の方に位置します。
ソフトウェアに限らず、どのような製品も「事前の準備」が重要です。絵画なら下描き、建築なら設計図――これから作る「物」がどのような構造になるかを決め、作成作業の手引きとなる情報をまとめる作業です。
- 設計図に沿って作る -
事前設計もそこそこに、いきなりVBを起動してフォームのデザインを始める人もいます。しかし、どのようなものを作るかが明確にならないうちに、開発ツールを起動しても意味はありません。
個人で作成する小さなツール程度なら、頭の中に設計図を描く――というアプローチもあり得るでしょう。しかし、業務で用いる大規模なアプリケーションを、それも複数にメンバーが共同で開発するような場合、行き当たりばったりに作業できるわけはありません。
アプリケーション開発は仕様書作りから始まり、その前段として業務分析が必要となります。これらによってアプリケーションの設計図を作り、それに沿って実際の開発を行います。
- 仕事の数だけ仕様がある -
「販売管理」などと一口に言いますが、商品を販売する処理１つとっても、実際の仕事の進め方は業種・職種によって実に様々です。どの企業でもどのような職場でも、すべて同じ方法で仕事をしてくれていたら、システム作りは非常に楽な作業となるでしょう。
受注方法、伝票のデザイン、出庫手続き、入金方法…などなど、基本的な部分はどこでも同じように見えますが、細部は微妙に異なっています。そしてその異なりをカバーすることが、非常に重要なのです。
結果的に、業種の数、会社の数――細かく見ていけば担当者の数だけ――異なる仕様があると言っても、過言ではないでしょう。
- ユーザーの要望を反映する -
仕様書は、複数の開発者が意思疎通を行う際の基準でもありますが、それ以上にユーザーの要望をアプリケーションに反映する手段として、重要な意味を持っています。
対象業務の内容とユーザーの要望に添って仕様を設計し、これからどのようなアプリケーションを作るのかユーザーに提示して、了解を得なければなりません。いきなりソースコードを見せても、ユーザーは分かりません。外観はもちろん、内部構造がどうなるのかをユーザーに分かるように示す手段が必要です。仕様書にはその役割もあります。
また、完成後に手直しする場合、作業対象の構造を把握するための資料ともなります。仕様書が存在しなければ、あるいは存在しても現在の仕様と異なっていれば、手直し作業は手探り状態となります。大変なミスを誘発する場合もあるでしょう。
開発当初だけではなく、途中の変更も随時仕様書に反映し、「現在の仕様を正しく把握できる」ようにしておかなければなりません。
仕様書を作るためには、これから開発するアプリケーションの対象業務でどのような処理がなされているか、つぶさに調べなければなりません。それが業務分析です。
- 主役はユーザー -
パッケージソフトの場合、不特定多数のユーザーが相手となるため、その仕様は「最大公約数的」なものとなります。しかし、専用の業務アプリケーションでは、アプリケーションの用途は限られ、ユーザーも少数です。特に、特定企業の特定業務を対象とする場合、ユーザーの意見を直接聞いて要望に沿った機能を実現することが大切です。
操作方法についても同じことが言えます。パッケージソフトでは、Windowsの作法に則った基本的な操作方法に従う必要があります。しかし専用の業務アプリケーションでは、必ずWindowsの作法を厳守すべき――とは、一概に言えません。
汎用機やオフコンで行っていた処理をパソコンに移植した場合など、「すべての操作をファンクションキーに割り付けて欲しい」「ドロップダウンリストを使わず、[Esc]キーで項目選択画面に切り替えたい」といった要望が出てくることもあります。
Windowsの作法に従っていないからといって、ユーザーがこれまでなじんできた操作方法を無視してはいけません。最終的にアプリケーションを作るのは開発者ですが、それを使うのはユーザーです。標準でないインターフェイスを実現する必要も出てきます。
- 苦情の原因は仕様設計 -
開発したアプリケーションを実際に現場で使ってみると、以下のような苦情や要望が寄せられる場合があります。
| ・ |
現場の手続きとアプリケーションの手順が違う |
| ・ |
手作業の帳票と画面デザインが違う |
| ・ |
表示される用語が現場で使われている用語と違う |
こういった問題の第一の原因には、設計者と開発者、開発者同士などのコミュニケーション不足もあるでしょう。しかし最大の原因は、ユーザーの意思が開発者（または設計者）に正しく伝わっていないことです。
専門的なことが分からないユーザーは、「コンピュータのことは専門家にお任せ」という気分になることも多いでしょう。そんなときは、最終的に「自分たちが使う道具を作る」のだということを説明し、協力してもらいましょう。
また逆に、微に入り細にわたって注文を付けてくるユーザーもいます。「素人のくせにうるさいな」などと思わず、できることとできないことを正しく説明し、必要な情報を聞き出しましょう。
業務分析は、「実態の調査」「調査結果に基づいて資料を作る」という２つの工程に分かれます。出発点は実態調査です。
- 業務の流れと構造を把握する -
業務分析とは、開発の対象となる業務の構造を調査し、仕様書の元となる資料を作成する作業です。
どのような情報がどう処理され、最終的にどう変化するのか…を把握し、基礎データ、取引データ、帳票などのデザイン・構成とそこに至る過程を考えていきます。
そのためには、自分の足を使い「森を見てしかも木を見る」要領で全体をつかみ、そこからさらに個々の要素について、詳細に調査しなければなりません。
作成するアプリケーションや依頼主の要望によって調査する項目は異なりますが、「取引先や商品の数」「１日の取り扱い件数」「システムの稼働時間」「現行帳票類の様式」などなど、外から見ただけでは分からない様々な項目についても調べる必要があります。
- 調査前に資料を揃える -
以下の２つは、インタビューに先立って、事前にユーザー側から資料として入手しておく必要があります。
| ・ |
会社概要
他社のアプリケーション開発を受注した場合、会社概要は必須だと思ってよいでしょう。
社名、所在地、代表者名から、取扱商品、資本金、年間売上高、事業所数、社員数、決算月――などの基本事項が記載されています。既にコンピュータが導入されている企業の場合、その利用環境を把握できるかもしれません。但し会社概要は、あくまで表向きの紹介です。実態については、別途調査する必要があるでしょう。
|
| ・ |
組織関連図
いわゆる一般的な組織図です。総務セクションや人事セクションが把握しています。各部署の責任者名などが明記されているとたすかります。
業務の流れを理解する他、業務の中心となる人物（キーマン）を探し出す場合にも利用できます。 |
資料を入手したら、相手先に出向く前にこれらの資料に目を通し、概要を把握しておきましょう。
- 調査時の注意事項 -
調査時に気を付けておきたいことを挙げてみます。
| 1. |
事前に調査項目を整理する
調査をスムーズに進めるため、基本的な質問事項をあらかじめ整理しておきましょう。さらに返答によって、新たな疑問が生まれる場合もあります。予想される疑問点を事前に拾い出し、質問表を作っておくとよいでしょう。
|
| 2. |
調査の目的と方法を知らせる
ユーザーによっては、なぜ調査が必要なのか、一体何を聞き出そうとするのか…など、不審に思われる場合もあります。会社の経営情報など、外部には隠しておきたい情報もあるでしょう。
相手を身構えさせないよう、調査の目的と方法を事前に説明しておくべきです。会社の内情を知ってしまうこともあるため、守秘義務も発生します。
|
| 3. |
相手先に出向く
いくら相手の使うアプリケーションを作っているのだからと言っても、いきなり出向いていったり、まして呼びつけたりはできません。必ずアポイントメントを取り、相手の会社に出向いて調査を行います。
ユーザー側の資料が非常に重要なので、ユーザーの側に出向いていくのが一番です。社外の喫茶店などで調査すると、ユーザーが必要な資料を持ち合わせていない場合に「後日郵送します」などということになり、作業がはかどりません。
|
| 4. |
資料収集をユーザーに依頼する
取引先の件数、年間取引高、部署別社員数など、現場の担当者では把握できない情報や調査に時間のかかる情報は、あらかじめユーザーに必要な情報を示し、まとめておいてもらうとよいでしょう。
|
| 5. |
担当者と責任者から話を聞く
現場担当者は実際の業務に詳しい半面、全体的なことは分かりません。逆に責任者や管理者は全体的なことに詳しい代わりに、細部を知っていません。両者から情報を得るようにしましょう。
管理職だけに事情を聞いて作ったシステムが、現場で不評――といった話はよく聞きます。
|
| 6. |
調査結果を確認する
調査を終えてそれを整理したら、自分の理解した内容が本当に間違っていないか、ユーザーに確認しましょう。意外な勘違いが潜んでいるかもしれません。
|
| 7. |
マルチメディアで記録する
マルチメディアとは古い表現ですが、要するに文字だけでなく、画像や音声も使って調査する――ということです。
ネットワーク図や組織図のラフスケッチはもちろん、インタビューはカセットテレコやデジタルボイスレコーダで録音しておきます。
調査結果の整理で記録した内容に曖昧な点などがあったとき、「音声の記録」が役に立つことがあります。但し、録音は相手の許可を得て行いましょう（スパイではありません）。
|
| 8. |
調査結果を保存する
調査した内容は記録して、必ず保存します。アプリケーションが完成しても、捨ててはいけません。後から問題が起こった場合に、見直さなければならないこともあります。
また、過去のアプリケーションの調査資料が別の仕事に役立つこともあります。同じユーザーから新たな開発依頼がきた場合、過去の資料が流用できることもあります。
|
対象業務、作成するアプリケーションの規模、ユーザーからの要望、開発側の予備知識などによって、調査する項目は異なります。一般的なアプリケーションで把握すべき項目を、いくつか挙げておきましょう。
|
|
- 一般的な調査項目 -
| ・ |
実行環境
作成するアプリケーションが「どのような環境で実行されるか」を把握します。
スタンドアロンかネットワークか？
| → |
ネットワークならプロトコルは何か？ |
| → |
サーバーの台数と役割、クライアント数、使用OS。 |
アプリケーションを使用するユーザーの技術レベル。
| → |
初心者やパートなのか、日常的に扱い慣れているユーザーか？ |
実行マシンのスペック
いざインストールして実行すると、ディスクの空き容量が足りなかった…という場合もあります。
|
| ・ |
基礎情報の種類と構造
商品台帳、顧客名簿、社員名簿などの記録件数と記録形式、年間の最大データ件数などを把握します。
商品や顧客の管理用に割り振っているコード番号の桁数、付定規則、実際の例なども把握しておきましょう。
対象業務によって必要となる情報は異なります。関連しそうな情報については、不要だと思っても一応確認しておきましょう。
|
| ・ |
生成される情報
販売、勤怠、仕入れなどの日常業務で生成される情報や、経営分析などで使用される情報の記録形式と記録件数を把握します。
下の「帳票デザイン」とも関連しますが、これを明確にすれば「情報をどのように処理すればよいか」を把握する糸口が見えてきます。
|
| ・ |
帳票デザイン
既存帳票・伝票類の種類とデザインを、可能な限り集めます。
帳票の名称やその中の項目名、項目の並び順なども重要です。
既存の帳票だけではなく、担当者個人が予備的に使っているメモ、手製の集計表などのデザインも役に立つことがあります。
既に何らかのシステムが稼働している場合、その予備データを表計算ソフトなどで作っている場合があります。そのデザインも参考になるかもしれません。
|
| ・ |
普段の処理工程
手作業の場合の処理手順、処理データの発生から帳票・伝票類への記録、それらの整理保管方法などを把握します。
基本的に、アプリケーションの処理手順と手作業時の処理手順は同じになります。手作業では数段階に分かれている作業が、コンピュータでは一連の自動処理で片付く場合もあります。そのあたりの兼ね合いも見ておきましょう。
|
| ・ |
既存システム
既に稼働しているシステムとの関連は重要です。既存システムの出力が、これから作るアプリケーションの入力となるような場合、既存システムの側からデータを読み取ってくるような仕組みが作れるかもしれません。
また、既存システムに対するユーザーの不満や要望も、これから作るアプリケーションの参考になるでしょう。
|
- 調査用紙のひな型 -
レポート用紙やノートに手書き、あるいはワープロソフトなどを使って調査結果を記録することもできますが、調査項目を書き込むひな型用紙を用意しておくと便利です。ユーザーに調査を依頼する場合は、特にひな型が威力を発揮します。
以下に、“ひな型”として用意しておくと便利な調査用紙を紹介します。内容は手書きでも構いませんし、ワープロ文書として保存しておき、ノートパソコンを持ち込んでその場で入力しても構いません。
調査時にはレポート用紙に手書きしたり、エディタやワープロにメモを取るなどしておき、後からひな型を使って整理しながら清書する場合が多いようです。
記述し終えたら、電子データとして保存しておき、必要なときに画面で確認するのが最も効率的です。共同開発の場合は、ファイルサーバーの共有ディレクトリに保存しておきます。
ひな型の図版は、サンプルとしてPDFファイルで保存してあります。なお、図版はあくまで一例です。必ずしもこのとおりである必要はありません。
| ・ |
業務機能階層図
業務の各機能を、大きな単位から詳細な単位へと階層化した図。
会社概要や組織関連図と調査結果なども照らし合わせて作成し、業務の全体構造を把握します。
整理し終えると、アプリケーションの処理選択メニューの構成に近いものとなります。
|
| ・ |
業務フロー
開発の対象となる業務の流れを、時系列的に表現したもの。
一般にフローチャート記号を使うことが多いようですが、決まっているわけではありません。クリップアートを使ったり、文字だけで記述しても構いません。要は第三者にも業務のおおよその流れが理解できればよいのです。
ワープロの図形描画機能や、フローチャート作成ソフトなどを使うと便利です。
|
| ・ |
入出力一覧表
対象業務で用いる入力伝票や専用伝票、管理帳票などの構造を一覧表にしたもの。
手書きの伝票や台帳のデザインと、普段の作業手順などを突き合わせて作成します。
いつどのようなデータが発生し（入力）、それがどのように加工されるか（出力）を把握できます。入出力仕様の原形は、この資料でほとんど決まると考えてよいでしょう。
現物の伝票・台帳類も資料として添付しておきます。台帳や伝票は、何も記入されていない白紙のひな型と共に、実務に用いられて実際に何らかの取引情報などが記入されたもののコピーも入手しておきましょう。テーブル・クエリ・フォーム・レポートの設計に役立ちます。
伝票記入時の省略表記、必須項目と省略可能項目なども把握しておきましょう。
実際に用いた伝票などのコピーは、基本的に外部には漏らさないよう取り扱いに注意が必要です。顧客の氏名、商品の原価など、外部に漏れると不都合な部分を抹消してもらってもよいでしょう。
|
| ・ |
データ項目一覧表
管理対象となる項目の一覧表。
対象業務で扱うデータ群を整理したものです。データベース設計の基礎データとなり、アプリケーションの仕様決定に大きく影響します。入出力一覧表とあわせて、データの流れ、加工の過程を設計する資料とします。
詳細に調べると用語統一の基礎資料にもなり、テーブル設計時のフィールド名策定にも役立ちます。
|
| ・ |
基本要件定義書
消費税の計算方法(内税／外税、単品課税／総合課税)や、単価の決定方法など、データ処理上の詳細な手順や計算規則について定義したもの。
特に、その業界特有の処理、例外や便宜取り扱いなどに注意しましょう。「税込みでぽっきり価格」にするための中途半端な「裏技的値引き額」など、落とし穴はあちこちに潜んでいます。
|
| ・ |
現状の問題点および要望書
ユーザーの抱えている現状での問題点や、作成するアプリケーションへの要望など。
結構子細な要望や問題点を提示されることもありますが、それらも重要な情報です。どこで何が役に立つか分かりません。
但し、「すべての要望を受け入れられるかどうかは分からない」ということを、前もって説明しておきましょう。
|
業務分析の最大のポイントは、必要な情報をユーザーから効率的に得ることです。機械相手ではなく、人間相手のコミュニケーションが必要です。
- インタビュー術 -
机上の仕事が多いエンジニアは、会議や相談もメールやチャットで…となりがちです。相手をよく知っている場合はともかく、まったくはじめての人の場合は、できるだけ実際に会って話をするよう心がけましょう。
営業ではないので、愛想笑いやおべっかは不要です。ただ、重要な情報をスムースに聞き出すために、相手の心を解きほぐす工夫は必要です。既に述べましたが、システムが不評を買う原因の多くは、最初の段階でユーザーの意図を正しく把握できていないことです。
雄弁である必要はありません。聞き上手であることです。無駄な世間話も潤滑油として必要ですが、要点を押さえて質問し、回答を要領よく書きとどめましょう。
- 専門用語の問題 -
「専門用語」というと、開発者の側から発する技術的な専門用語だけを連想されるでしょう。しかし、実はユーザーの言葉の中にも専門用語は混じっています。どちらにも注意が必要です。
| ・ |
開発者側の専門用語
開発者の側は、専門用語の類をできるだけ平易な日常の表現に言い換えましょう。お互いにうち解けて会話が弾み、ユーザーがコンピュータに詳しいと分かってくると、ついつい専門用語やカタカナ語が飛び出してしまいます。
しかし、ユーザーはあなたが思っているほど、専門用語を厳密に解釈していないことが多いものです。一見意思が通じ合ったようでいて、結局は誤解されたままだった…ということはよくあります。
特に、雑誌の知識をなまかじりで身につけたタイプの「中途半端なマニア」には注意しましょう。何でも「はいはい」と、分かったような返事をする人も要注意です。
最近の開発では、TCP/IPネットワークやデータベース処理など専門的な概念が必要な場合が多いので、コンピュータ用語辞典などを用意しておくのもよいアイディアです。 |
| ・ |
ユーザー側の専門用語
ユーザーの言葉の中にも、専門用語はたくさんあります。コンピュータではなく、ユーザーの仕事で用いる専門用語です。実際には、こちらの方が厄介です。たとえこちらがコンピュータ用語を分かりやすく言い換えても、相手が同じように自分の仕事の専門用語や略語を言い換えてくれるとは限りません。
「見積」「仕切」「掛売」「勤怠」「年休」「天引」など、一般事務用語は知っていて当然です。経理や営業など一般事務の専門用語は、開発をこなしていけば自然と理解できるでしょう。しかし、中には非常に特殊な用語を用いる業務もあります。業界の中だけ、あるいはその会社のその部署でしか使われていない言葉もあるでしょう。
大阪のある会社で注文伝票を「ちゅうでん」と略すのを聞いて、長野県出身のSEが「中部電力」のことだと思っていた…などということもあります。会話の中で知らない用語が出てきたら必ず質問し、理解できたと思ったら相手に確認するようにしましょう。 |
- 例外処理への対応 -
日本の企業では、例えば商品の販売で、規定通りの値引率を公平に適用せず、営業員の裁量による「特別価格」などが存在します。その他、お得意さまだけに対する便宜措置などもよくあります。
こういった便宜取り扱いや例外処理の類は、その処理方法についてきっちりとした確認をしておきましょう。杓子定規な規定だけで業務が遂行できるなら、これほど楽なことはありません。多くのSEが頭を悩ますのは、この部分です。
「どのようなときにどのような便宜措置をするのか」「基本の扱いと例外ではどこがどのように異なり、結果にどう影響を与えるのか」しっかり把握しておかないと、とんでもないシステムができあがります。
- 「当然」という落とし穴 -
ユーザー側の担当者によっては、自分の会社のやり方が世間でも常識的なものだと思っている場合があります。一方あなたは、それとは違う方法を「当然」と思っていることもあるでしょう。当然という思い込みは避けなければなりません。
例えば以下のような問題で、開発者とユーザーの間で誤解が生じることがあります。
| ・ |
人事管理で、退職した社員の社員コードをどう扱うか
社員コードをそのまま年金などの管理に使うため一定期間欠番とする場合と、退職者コードを新たに割り振る場合があります。間違えると、リレーションに矛盾を生じる場合があります。
|
| ・ |
人事管理で、転勤した社員の社員コードをどう扱うか
転勤先でも同じコードを使う場合と、まったく違うコードを割り当てる場合があります。間違えると、リレーションに矛盾を生じる場合があります。
|
| ・ |
商品管理で、生産中止となった商品のコードををどう扱うか
商品がなくなったからと言って、それに関する処理まですべて消えるわけではありません。退職した社員の場合と同じで、間違えるとリレーションに矛盾を生じます。
|
| ・ |
年間集計を終えた後のデータをどこに保存するか
同じアプリケーションから参照するか、別のアプリケーションで管理するかによって、仕様が異なります。アプリケーションのインターフェイスだけではなく、他のテーブルのデザインなど、データ構造に影響を及ぼす場合もあります。
|
| ・ |
消費税の端数をどう扱うか
１つの取引ごとに生じた端数を調整するのか、月ごとにまとめて集計するのかで、結果が異なります。
|
上記の他にも、お互いが分かっているようで実は理解が違っていた――ということはよくあります。アプリケーションがある程度できあがってから間違いに気づくと、途中の手直しに時間を費やしてしまいます。意思疎通をしっかり行い、後で問題の出ないようにしましょう。
 PDF形式の業務分析用帳票
のダウンロード（Ex35.LZH）
(LZH形式 558KB) |
