情報システム学会 メールマガジン 2011.4.25 No.06-01 [6]

連載 ベテランSEの要件定義ノウハウを形式知化した企業情報システム機能選定方法論(FUSE法:Methodology of Functional Selection for Enterprise Information Systems)の紹介

第4回 企業情報システム機能選定方法論の使い方 その2

筑波技術大学大学院教授(筑波技術研究所代表取締役) 隈 正雄

1.【ステップ5】企業の業務処理レベルに配慮したシステム機能要件にチューニングする
(1)4つの業務運用能力
 先の段階でまでで、当該企業に理想的なIT機能要件を選択できるようになる。すなわち、業務の効率化だけではなく、経営管理や経営戦略を踏まえた要件定義ができるということである。しかしながら、これだけでは要件定義は終われない。情報システムの実現可能性を確保することである。ステップ5では、実現可能性を確保すべく、企業の業務処理レベルへの配慮について述べる。本方法論では、業務処理レベルを4つの業務運用能力として捕らえている。これと次に説明する「企業風土」ついては、既存のシステム設計技法ではあまり取り上げられていないので、少し詳しく説明する。
<1>業務標準化能力
 企業情報システムの設計には、業務の標準化やルール化等のアルゴリズムが前提となる。人によりあるいは場合により処理方法が異なっては、企業情報システムの設計は困難である。従って、企業情報システムのIT機能要件によっては、業務がある程度標準化されているか、または標準化できる必要がある。業務実態に合わないルール化を行い、そのルールを前提にIT機能要件を選定しても、運用で混乱しかねない。企業情報化の前提となる業務の標準化レベルも企業能力の1つといえ、これを「業務標準化能力」と呼ぶ。
<2>業務遂行能力
 企業情報システムは、単に現状業務をシステムとして置き換えるものではない。そこには、何らかの課題を解決するという目的がある。その課題を解決しようとすると、新たな業務が発生する。また、企業情報システム開発を契機に業務範囲の拡大や管理レベルの高度化が図られることあり、従業員は新しい業務に適応しなくてはならない。
 一方、販売、生産、物流といった多くの従業員がかかわる基幹業務は、大部分の従業員が短期間の訓練で遂行できるレベルのものでなくてはならない。これらの業務が停滞することは企業活動が停止することを意味するからである。
 従業員の業務運用能力は、一挙に高めることは困難である。高度な業務に対応するには、ある程度の業務処理レベルに達している必要がある。つまり、企業には、従業員の能力に応じた運用可能な業務のレベルがあるということである。従業員が遂行できる業務のレベルを「業務遂行能力」と呼ぶ。
<3>業務情報化能力
 業務における企業情報システムは大きな比重を占めるようになった。企業情報システムの活用には、手作業による業務の処理とは異なる知識やノウハウが必要とされる。従って、従業員が企業情報システムを活用し、業務をこなせるレベルも能力といえる。これを「業務情報化能力」と呼ぶ。
<4>管理データ活用能力
 企業情報システムから提供される管理データの活用は、業務の処理とは異なる。業務の処理機能については、一般的に目的は明確である。従って、どこまで適切にできるかは別として、何をなすべきかという点については明らかでる。
 しかし、管理データについては、より複雑である。一般的に、提供される管理データは単に提供されたということだけでは効果が出ない。その情報から問題点を把握し、その原因を追求し、改善に取り組んで初めて有効となるものである。分析者の権限や知識の範囲外に原因や解決策があり、改善が極めて困難なケースもある。従って、ある程度の分析の方法や新しい切り口や考え方を展開できる能力が必須となる。能力を超えた管理データは使用されない。さらに、管理の方法を明確にせず新管理データに基づく評価方式を導入しても、現場が混乱してしまう。この能力を「管理データ活用能力」と呼ぶ。
 管理データの活用については、企業の経営管理の発展段階に応じて要求度が高くなる傾向がある。特に、株式上場により公的企業となると、株式上場企業としての高度な管理データが要請される。また、昨今では内部統制により管理レベルが問題となる。管理は、それ自体が価値を直接生み出すものではない。原則として、必要最低限であることが望まれる。従って、業務改善の情報提供は、当該企業の外部環境や組織内部の状況による必要最低限度の管理が下限となり、情報を分析、活用できる限度が上限となる。

(2)業務運用能力によるIT機能要件のチューニング
 業務運用能力は選定したすべてのIT機能要件をチェックする必要はない。前システムですでに類似のIT機能要件が稼動している場合は、不要である。なぜならば、すでに運用されていることで、運用能力は実証済だからである。ここで、問題となるのは、業務改革等で新たに導入するIT機能要件である。これについては、運用できるか分からない。
 一定の業務運用能力が必要とされるIT機能要件には、「FUSE知識ベース」のIT機能要件に必要とされる業務運用能力が記載されている。また、すべてのIT機能要件には、運用の難易度も記載されている。
 前ステップまでで選択したIT機能要件に業務運用能力が記載されている場合は、その条件を満たしているかどうかを確認しなくてはならない。満たしていない場合は、同詳細業務のIT機能要件の中から、運用が容易で業務運用能力を満たし、かつ、効果が上がる次善のIT機能要件に変更(チューニング)する。これにより、新しいIT機能要件による業務の運用の実現可能性が保障される。
 「業務効果」と業務運用能力に関しては、業務運用能力を満たすIT機能要件への変更が優先される。しかしながら、「経営効果」と業務運用能力に関しては、「経営効果」の重要度により、業務運用能力を無視することもある。つまり、経営戦略にかかわるIT機能要件や、内部統制や株式上場で必要とされるIT機能要件は、その重要度に応じて業務の運用で混乱が生じても、導入すべき場合があるということである。

2.【ステップ6】企業風土に配慮したシステム機能要件にチューニングする
(1)4つの企業風土
 情報システムの実現可能性を確保するもう1つの視点として「企業風土」(経営者のポリシーや従業員の行動パターンなど)がある。ステップ6では、「企業風土」への配慮について述べる。
<1>経営者のポリシー
 人間はさまざまな行動要因を持っている。経営者も企業経営について独自のポリシー(経営者にとってのあるべき姿)を持つことが数多く見られる。情報化に伴う業務改善がいかに適切でも、経営者のポリシーを侵す改善は支持されない。この企業情報システムに影響する経営者の考え方を「経営者のポリシー」と呼ぶ。これらに関連する業務改善に際しては、経営者のポリシーを十分把握し、よく考えたうえでIT機能要件の選定に取り組まなければならない。
 「経営者のポリシー」は次のような機能に表れる。

・重要な取引先との仕組みの改革の方向と経営者のポリシーとの整合性
・商品供給の基本的な仕組みの改革の方向と経営者のポリシーとの整合性
・内部管理の基本的な仕組みの改革の方向と経営者のポリシーとの整合性

<2>従業員の革新度
 従業員はさらに複雑な行動要因を持つ。企業の発展に寄与するように業務改善に積極的に取り組む人もいる。また、企業の現状に危機感を持ち、業務改善に協力する人もいる。一方、現状に安住し、変化を好まず自己保身に走る人もいる。企業情報システムによる業務改善により既得権を失うような場合、徹底的に改善に抵抗する人もいる。また、所属部門の利益に固執し、全社的な視点の改善に反対する人もいる。
 企業情報システムは業務改善を伴うものであり、従業員の協力が不可欠である。これらの企業情報システムに影響する従業員の行動要因を「従業員の革新度」と呼ぶ。これらの業務改善に際しては、「従業員の革新度」に配慮して、支持が得られるIT機能要件を選定する必要がある。時には、従業員の反対を押し切ってもIT機能要件を導入する場合もあるが、原則として「従業員の革新度」を踏まえて、丁寧な説明やトップの支持を受けて行わなくてはならない。
 「従業員の革新度」は次のような点に表れる。

・新しい業務の仕組みへの納得感
・業務の制限への納得感
・新しい管理事務の必要度への納得感
・新しい管理事務による作業負担増加への納得感
・業績評価転換への納得感

<3>経営者の許容限度
 企業情報システムの効果は経営者にはわかりにくいものである。ハードウエアの処理速度の向上やオペレーションの容易性には経営者はあまり関心がない。さらに、業務が改善されて従業員の仕事が楽になっても経営者は満足しない。経営者は、経営に直接影響する月次決算の迅速化や統計データの入手が容易になれば、一定の満足感を持つ。
 しかしながら、経営者が企業情報システムに期待した在庫削減や納品リードタイムの短縮等の経営課題は、簡単に解決できるものではない。一般的に、企業情報システムは業務改善を支援するツールを提供するにすぎず、企業情報システムが自動的に解決できる課題はあまりない。従業員が企業情報システムを活用し、業務改善活動を継続して、やがて解決できるものである。課題の解決にはタイムラグがあり、企業情報システムの稼動時には明確とならないことが普通である。
 経営者が企業情報システムを評価するのは、一般的に問題が発生したときである。つまり、どの程度問題がある企業情報システムであるかということである。経営者も企業情報システムの導入が困難で、トラブルが多く発生するものであることは認識している。しかし、経営者にとっても企業情報システム導入の混乱がいつまでも続くことは苦痛である。中でも、企業の信用を損ねるような対外的なトラブルに至っては、経営者の許容能力を超え、情報化への支持を失うことも生じる。この経営者の行動を誘発する限度を「経営者の許容限度」と呼ぶ。
 これらに関係するIT機能要件に関しては、経営者の情報化への支持を維持するために、システム稼動に伴うトラブルを防止するように、IT機能要件の品質の選定に特段の配慮が必要となる。
 「経営者の許容限度」は次のような機能によく表れる。

・重要な取引先との仕組みのトラブル
・商品供給の基本的な仕組みのトラブル
・内部管理の基本的な仕組みのトラブル
・情報化投資の明らかな無駄

<4>従業員の許容限度
 一般的に、従業員はシステムが稼動するまで、システムを具体的には理解できない。また、その効果は容易には実感できない。ただし、担当業務がスムーズになることには満足感を示す。しかしながら、企業情報システムの真の狙いである業務改革に成功した時点では、すでにシステムはインフラとして当然のものとなっており、あらためて評価することはあまりない。
 従業員がシステムを評価するのは、一般的にシステム導入の負担が過度となったり、自己の担当業務で深刻なトラブルが発生したときである。企業情報システムの導入時には、通常、従業員は従来の業務と新システムを使用した業務の二重作業となる。さらに、プログラミングのミスによるトラブル、新業務やシステムと現実がかけ離れているためのトラブルなど、従業員にかかる負担は非常に大きなものとなる。従業員のシステム導入負担に耐えられる程度も行動要因の1つといえる。この従業員の負担限度を「従業員の許容限度」と呼ぶ。
 これらのIT機能要件に関しては、従業員の情報化への支持を得るために、システム稼動に伴うトラブルを防止するように、IT機能要件の品質の選定に特段の配慮をする必要がある。
 「従業員の許容限度」は次のような点に表れる。

・手作業からシステム処理に変更したが、かえって不便になった
・システム導入に伴う新業務のルールが実態と合わず、業務が混乱した
・システムの自動制限により業務が混乱した
・基本的で重要な業務のシステムのトラブルが発生した
・管理志向が強い業績評価制度を導入した
・管理のための新たな業務の運営負担が過大である

(2)企業風土によるIT機能要件のチューニング
 配慮が必要なIT機能要件には、「FUSE知識ベース」のIT機能要件に必要とされる「企業風土」が記載されている。また、すべてのIT機能要件には、運用の難易度も記載されている。「企業風土」のチューニング方法は基本的には「業務運用能力」と同様であり、説明は省略する。

3.方法論の今後の展開
 ベテランSEは、個々の要件定義に際し適切な判断が下せる。その判断は、この場合はこのようにすべきというものである。しかしながら、それを理論的、体系的に説明することはできない。なぜならば、ベテランSEの要件定義ノウハウは暗黙知だからである。中には理論的に捉えられるSEもいる。しかし、SEは多忙である。理論を組み立てている余裕はない。さらに、自己のノウハウを他人に容易に明かすものではない。そのようなことをすれば、自己のカリスマ性を低めてしまうからである。
 本方法論の特長は、このベテランSEの要件定義ノウハウを見える化したことである。ベテランSEが頭の中で判断していることを、その思考方法を理論化し、かつ具体的にIT機能要件の何処にどのように影響するか見える化したことである。
 もう1つの本方法論の特長は、見える化したベテランSEのノウハウを短期間で習得できるようにしたことである。つまり、ベテランSEのノウハウを「FUSE知識ベース」として見える化したことにより、誰でも実務で活用していくことができるようになった。従って、膨大な分野の業務を学習し、長年にわたる実務経験を経なくても、「FUSE知識ベース」を使いこなすことにより、比較的短期間でベテランSEのノウハウを自己のものとすることができるようになれるということである。
 「FUSE知識ベース」は、SEが5年から10年かけて取得する業務知識やノウハウをすべてカバーしている。それをそのまま解説しては1000ページを超えてしまう。そこで「FUSE知識ベース」ではノウハウを圧縮し、70ページ程度に収録した。そのため少し分かりにくくなっている。
 そこで、詳細な解説の代わりとして研修を用意した。研修では事例企業概要を説明のうえ、各ユーザとの様々なヒアリング資料を元に、「FUSE知識ベース」を活用して7つの演習をこなす形で実施する。この研修により、「FUSE知識ベース」の考え方や使い方を容易に把握できるようにするものである。
 今後は、本方法論を活用し現実のシステム開発に取組みたい。本方法論に関心があるITベンダーは連絡して欲しい。本方法論を説明のうえ、本方法論を使用し、要件定義段階で支援したい。1社限定で実施するが、今回はテストケースとして無償で支援したい。
 また、本方法論に対する意見等もお寄せいただきたい。