使えるシステム構築を！
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
くまさんの「システム構築のススメ」
- 第 3 号 -
発行日：2007年3月15日
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
『要件定義していますか？』
前回は仕様書作成を行う上で最も基本となる「目的設定」の話をしました。 目的設定が
終わったら次は「要件定義」です。 要件定義は受注者側のSEさんがやってくれる場合も
ありますが、それは「費用見積に必須」だから行うのであって、その費用も含めて見積が
出てくるのです。 従って、安くて使えるシステムを作りたいのならば、本来は自分達で
行うべき内容なのです。
では「要件定義」とは何をすればよいのでしょうか？
SEさんが行うような「システム設計」に直結するような要件定義は、我々ユーザーにはな
かなか書けるものではありません。 でも、「システムを使って、どのようなことをした
いのか」という事であれば我々ユーザーにしか書けません。
そうなのです。 「どのようなことをしたいのか」を書き出していくのが、即ち要件定義
となるのです。 これであれば、しっかりとエンドユーザーとコミュニケーションを取れ
ば簡単に書けるのではないでしょうか。 ただ、これを全て文章で書くとなると大変な作
業になるでしょうし、頭でイメージしたことを「相手に伝わるように」文章で書くという
のは非常に難しいことなのです。 そこで出てくるのが「業務フロー」となります。 業
務フローはシステム屋の共通言語と言っても良いくらいに相手に思いを伝えやすい道具な
のです。
恐らく先の目的設定の為に現場ヒアリングや、エンドユーザーとのコミュニケーションは
十分に取っていると思います。 出来れば、その段階で現状の業務フローを一度起こして
みましょう。 そうすると、「自分達が如何にムダな作業をやっているのか」とか、「何
故、ここの部分はシステム化していないのだろうか」とか、様々な問題点が見えてきます。
見えてきたらしめたもの。 目的設定と要件定義が一気に出来てしまいます。
現状の業務フローに現状の問題点を書き加えてみましょう。 そして、そこを理想とする
業務に置き換えてみましょう。 そうすると、今回導入しようとするシステムの最終形が
だんだん見えてくるのが判ると思います。 その「最終形」の業務フローが出来上がった
ら文章で相手に伝えやすい部分は文章で、伝えにくい部分は見易いフロー図で置き換えて
みましょう。 そうすれば、もう完成です。
え？ 判らない？
では、もう少し詳しく書いてみましょう。
どのようなレベルのシステムを求めるのか（例えば24×365のシステムなのか、平日9-18の
システムなのか）とか、その上で特記すべきハードウェア条件やソフトウェア条件は箇条
書きにして相手に伝えることが可能ですので、大まかに箇条書きで列挙します。 使用す
るOS等に制限があれば、それもこの中に記載します。
次に運用想定の概要を書きます。 どんな運用を行って、どんな業務改善があって、どれ
だけエンドユーザーが幸せになれるのかを文章にして記載します。 概要ですので、大ざ
っぱに相手に伝わればよいレベルですが、自分達の業界のことを相手が全て知っているわ
けではありませんので、業界特有のことがあれば記載しておくと良いでしょう。 後々、
手戻りするような事態を避けることができます。 今回導入するシステムが、何らかの規
格に従っていなければならない場合には、その旨も明記しておきます。
そして、より詳しい運用想定案として最終形の業務フローを添付します。
勿論、エンドユーザー向けの機能ばかりではなく、自分達システム担当者が使用するよう
な機能（管理機能とか監視機能とか）が必要な場合には、その点についても言及しておき
ます。
以上で要件定義は完了です。 要は受注者側が見積もりを出すために必要な内容が網羅さ
れていれば十分と言うことになります。 余り詳しく書きすぎると、開発過程に於いてそ
こが足かせになる可能性もありますので注意が必要です。 自分達で作った仕様書で自分
達の首を絞めることになりかねません。 曖昧さを残しつつも、重要な部分（コアとなる
部分）については詳細に書いておきましょう。
では、例として、以前、私が書いた仕様書から要件定義の部分を抜き出してみます。
-----
「ハードウェア的要件」
ハードウェア的要件は以下の要件を満たすことが必要である。
1. 将来の拡張性を考慮した上で、42Uのラック1本に将来拡張分も含めて全て収容可能
であること。
2. 床耐荷重の関係から、ラック重量も含めた総重量は400kgに納めること。
3. 電源はCVCF等で保護された系統ではないため、不足の停電に備えた構成にすること。
（※ 以下、合計で11項目に言及）
「ソフトウェア的要件」
現行運用している○○システムは以下のような機能を持っている。 本仕様書はこれらの
システムの更新に関する仕様という位置付けなので、現行システムが持っている特徴的な
機能は維持する必要がある。
（※ 以下、現行機能の列挙）
これとは別に、以降の運用想定概要に記載されている要件を満たす必要がある。
なお、各機能の画面遷移や個々の画面の動作に関しては、管理するデータ量の増加が操作
のレスポンスに影響を与えず、いかなる場合も高速に動作することが必要である。
システムを構成するアプリケーション、及び開発言語、データベース等に関しては特別な
指定はないが、オペレーティングシステムに関しては可能な限りMicrosoft社のWindows系
OSは避けること。
ユーザーに提示される各画面はW3CのTechnicalReportsに則ったHTML4.01又はXHTML1.0及び
CSS1、CSS2を用いて構成され、端末側OS及びブラウザに依存することのない形で提供され
ること。
「運用想定概要」
各ユーザーはブラウザを立ち上げたときに出るポータルサイトのログイン画面に向かって
、ユーザー名とパスワードの入力を行う。 入力されたユーザー名とパスワードを元に統
合ユーザー管理・認証システム（※ 同時に構築）にて認証を行い、そこで事前に設定さ
れている情報を元にユーザー用の画面を展開する。 同時にアクセス可能な範囲と権限の
情報も取得される。
以下ではポータルサイト（※ イントラの更新です）として一般的な各機能の運用想定に
関しては特に明記しない。（※ 一般的なものはイチイチ書かない） ○○の手順に関し
てのみ記載する。
（以下、続く）
-----
いかがでしょうか？ 書いてある文言は難しく感じますけど、内容的には大したこと無い
ですよね。
「どのような運用を想定しているのか」という点をしっかり書いて、あとは特別に記載し
なければならない「ハードウェア的な条件」とか「ソフトウェア的な条件」とかを列挙す
れば、費用見積や設計にぶれが発生しない、よりしっかりした要件定義が出来ることがお
判りになると思います。
なお、実際に作った仕様書などに関しては後日アップロードして、本メルマガにアドレス
を記載しますので併せて御覧ください。
次号では、「業務分析」に関して深く掘り下げてみたいと思います。
------------------------------------------------------
◆メルマガ登録・削除をご希望の方は...
http://kumasanda.jp/profile/contact/mailmaga/
にて、メールアドレスを指定することで行えます。
◆バックナンバーはこちらで御覧になれます。
http://kumasanda.jp/mailmagazine/
◆本メルマガは、修正を加えない限り
転送・引用は自由になっております。
◆本メルマガは等幅フォントを利用して御覧ください。
フォントの設定を
Windowsは「MSゴシック」、Macは「Osaka-等幅」
等としていただきますと見易く御覧頂けます。
------------------------------------------------------
私は、この本を読んで起業しました！
━━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
一人起業完全マニュアル （鏡味 義房）
価格：￥ 1,575(定価：￥ 1,575)
http://www.amazon.co.jp/dp/4756908470/ref=nosim/?tag=officekumasan-22
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━[PR]━━━
発行者：おふぃす・くまさんだ（北海道札幌市） 代表 熊谷 克則
ウェブサイト：http://kumasanda.jp/
お問い合わせは、http://kumasanda.jp/mailform.htmlからどうぞ。
━━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
★ メールを読んでクリックするだけ！ GetMoney!
⇒⇒ http://dietnavi.com/?id=1157217
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━[PR]━━━