» 【第77号】業務アプリケーションのユーザ要件定義

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第77号】業務アプリケーションのユーザ要件定義

DRI通信77号「業務アプリケーションのユーザ要件定義」 2003.2.3
厳冬の中にも、梅がほころび、日が少し延びて、春の近いのが感じられます。ひどい風邪にやられている人が目立ちますが、皆様いかがですか。
情報システムの世界にも流行があるのでしょうか、一時ERP、OOなどに押され気味だったDOAが、このところB2B、EAI、WEBサービスなどの広域統合問題解決の鍵として、再び注目されるようになったように思われます。先週行われたK2W勉強会では、新会社メタジトリの丸山則夫、松本聰両氏から、アパレル業界のデータ流通のためのリポジトリ応用の紹介がありましたが、これも鍵はXMLのタグの標準化のためのデータ項目の標準化というDOA問題でした。
ちょっと蒸し返しと思われるかもしれませんが、今月はこのテーマ「業務アプリケーションのユーザ要件定義」を選びました。業務アプリケーションを考えるときのスタートポイントを決める重要なテーマですが、その内容が人によって意外に違っていて、困ったからです。
■ユーザとは
まず「ユーザ」の捕らえ方ですが、「ユーザ会」などのイメージから来るのでしょうか、ハードメーカやSIベンダーなどですと、SEなど情報システムの専門家が含まれていたりすることがあります。この人たちを「業務アプリケーションのユーザ」と考えるのは妥当ではないでしょう。


また、一見「業務アプリケーションのユーザ」に見えるかもしれませんが、たとえば受注入力担当者も、真の「業務アプリケーションのユーザ」ではないと思われます。彼らはオペレータであって、その役割はテープを架け替える運用担当者とあまり変わりがないからです。その証拠には、EDIになればその仕事はなくなります。彼らにインタービューしても、オペレーションしやすいためのHOWに関する要件−これはこれなりに重要ですが−は出てきても、WHAT/情報に関する要件は出てきません。
したがって、真の「業務アプリケーションのユーザ」とは、その情報にもとづいて、顧客に対する付加価値を速く安く提供することに携わるユーザ、たとえば、生産計画担当者、購買担当者、出荷指図担当者、見積もり担当者、採用計画担当者などであると考えます。彼らからは、その業務遂行のために、どのような情報がどんなタイミングで必要かがでてくるはずです。情報システムの設計はこれに基づいて進められるべきでしょう。いわゆるパーフォーマンスやコストも考えなければなりませんが、これは目的ではなく制約として考えるべきものでしょう。
■情報要求
一般に「要件定義」と言うと、作り手の立場から、上記のHOWもWHATも混在して考える傾向がありますから、WHATに限定するために、「情報要求」という言葉を使うことにしましょう。この場合、情報要求には2レベルあるように思われます。オペレーショナル/戦術レベルのものと、マネジメント/戦略レベルのものとです。生産計画・指図、購買、出荷指図、見積りなどは前者、採用計画、設備投資計画、商品開発計画などは後者と言うことになります。原則としてそこには、生産計画数量、購入先、購入数量、納期、出荷数量、見積金額、採用人数、投資金額、など意思決定データが含まれています。極論ですが、これらがタイムリーかつ的確に決められていれば、たとえコンピュータが使われていなくても、企業はそこそこまわっていくもののように思われます。
■コードの使用
企業は、その効率的運用のために、組織をつくり分業体制をとっています。そして他からの依頼/指図、これにもとづく実行予定や結果に関するする回答/報告などが、組織間でやり取りされます。これはイベントレコード、いわゆるトランザクションレコードの形式をとり、一般にイベントの種類、識別子および5W2H(Who, Whom, What, Where, When, How, How many/much)のパラメータを含んでいます。コンピュータ化の場合は、このうちのHow many/much以外には、一般にコードが使われています。
他と全く無関係に運用される組織はありませんが、コンピュータ化の初めは、他との関連は、取り敢えず無視して、当該組織の業務のみを対象に、コンピュータ化が進められました。このためHow many/much以外の5W1Hのコードは自給自足でした。処理の自動化に焦点があてられ、「機械計算課」などが作られた時期です。
■ばらばらなコード
その場合は、コードの設計、発番・保守が大変なばかりでなく、営業は営業の、また製造は製造の見方でコード化を進めますので、本来同じであって欲しいコードが別であったり、別のコードであるべきものが同じであったりすることになります。コードとは
  文章:単語=イベントレコード:コード
の関係で示すように、文章における単語のようなものですから、コードとその内容がいろいろあるということは、広辞苑が同じ会社に何種類もあるようなものです。
組織間でのコミュニケーションに際しては、これらまちまちなコードを何とか変換しながら繋いでいくことになりますが、それは分断された高速道路から降りて一般道に出、渋滞に耐えて、また高速道路に乗ってドライブするような、非効率が発生します。このような変換だらけの企業がまだたくさんありますが、これに気づいていない/気づかされていないトップもすくなくないように見受けられます。
部分最適でなく全体最適にして、「資金も、在庫も、人も最小限にしたい、リードタイムの短縮された、Agileに経営ニーズに対応するシステムにしたい」となれば、同じ意味のデータは同じ形式と値を持つ、コードが統一され変換不要の、いわゆるシームレスなシステムとしなければなりません。
■コード統一作業の難しさ
しかしこのコード統一の作業は、コードの意味内容を吟味しなければできない高度な知的作業です。1対1にうまく変換できるのは幸運なケースで、そのコードの範囲(注1)や粒度(注2)が違うと簡単ではありません。情報システムに長く携わった人でも、処理中心・プログラム中心でやってきた人は、「コードに適切な名前をつければ、それで意味は規定できるはず」と考え勝ちなので、要注意です。
(注1)品番と言っても、部品や、包材が含まれていたり、いなかったりします。取引先と言っても運送業者や銀行・官公庁が含まれていたりいなかったりします。
(注2)品番と言っても、色、サイズ、包装形態が含まれていたり、≒≒いなかったりします。取引先と言っても、法人レベルだったり、事業所レベルだったりします。
■広域統合システムの情報要求定義
全体最適を実現する業務アプリケーションの情報要求は、このような標準化されたデータによって、はじめて正確に記述されることになります。自給自足のローカルなシステムでは、情報要求定義作業に占めるデータ標準化のウエイトは微々たるものですが、広域統合システムにおける情報要求定義作業は、そのほとんどがデータの標準化ではないかと思われるほど大きなウエイトを占めることになります。すなわち大規模システムにおいては
  情報要求定義≒データ標準化
なのです。したがって、大規模な場合は、これをシステム開発の上流工程というより、データインフラ整備の独立したプロジェクトと位置づけた方が良い、と言うことにもなります。
標準化とは現状を調べ、統一できるコンポーネントを見つけ、調整によって統一してゆくボトムアップの人間にしかできない作業です。根気と時間のいるマネジメント作業です。これをこなす力は、情報システム関係者、あるいは企業の「文化」によって大きく異なるように見えます。ERP導入においてもこのような標準化が要求されますから、この「標準化の文化」を持っているところは成功し、そうでないところは苦戦していると、一般論的には言えるように思われます。