企業情報システムの開発は容易に成功しない。その要因は様々であるが、要件定義に最大の問題があることは周知のことであろう。要件定義に対しては多様なシステム設計技法がある。最近では特にＵＭＬが注目を集めている。しかしながら、ＵＭＬを活用することにより、企業情報システムの要件定義の品質が向上し、企業情報システムの開発に成功するようになったとはあまり聞かない。
企業活動をとらえるにはＵＭＬは非常に優れている。しかしながら、ＵＭＬは、ＳＥが認識できたものを的確に表現するのに優れているということである。ＳＥが認識できないこと、知らないことも表現できるわけではない。つまり、ＳＥがＵＭＬで的確な要件定義を行うには、【豊富な業務知識】とビジネスを分析する視点を持っていることが前提なのである。
生産管理システムは非常に複雑な情報システムである。そして、部品展開や負荷の山崩し等、それなりの知識が必要である。さらに、生産管理システムは事務処理ではなく、製造業務を支援するものである。従って、製造現場ができること、できないことを踏まえてシステムの設計を行う必要がある。これらの前提知識なしで、いかにＵＭＬを駆使しようと的確なシステムは設計できない。
業務知識はユーザが持っている。従って、ＵＭＬで正確にユーザから知識を吸収すればいいという考え方がある。ユーザが適正な業務知識を持っていればＵＭＬで解決できる。しかしながら、ユーザは本当に適正な知識を持っているだろうか。ユーザは業務を処理しており、処理方法は知っている。しかし、その方法は従来から行っている方法である。形骸化したり、無駄や非効率なものも含まれている。これらについては、ＵＭＬが活躍する。現行業務を可視化し、非効率業務を改善することはできる。しかし、それだけである。ユーザが知らない新たな仕組みは、現状分析やユーザニーズを分析しても出てこない。現状の延長を超える業務改善は、出来ないということになる。
企業情報システムの役割は、単なる業務の効率化だけではない。【経営管理面】でも重要な役割がある。例えば、上場企業では株式公開の実質基準を遵守しなくてはならない。当然のことながら、実質基準を充足するには、情報システムのどのＩＴ機能がどのように働かなければならないかの知識が必要である。これらの視点が抜けた情報システムは完成しても、大規模な修正が発生するであろう。
今日では、情報システムの適正な支援なしに経営戦略の実施はおぼつかない。戦略とシステムは切り離せない。では、業務を効率化したシステムが、経営戦略を支援するシステムなのであろうか。そうではないであろう。では、ＵＭＬでどのように経営戦略を支援するシステムを構築すればいいのであろうか。
ユーザである経営層から漠然とした経営戦略を聞き出すことは可能である。例えば、過剰在庫を抱えながら欠品が生じる企業も多いであろう。経営層から、在庫削減と欠品防止を支援できる情報システムを求められたとしよう。このあいまいな戦略を有効に支援する情報システムは、いくらＵＭＬを駆使しても作成できない。【経営戦略】という漠然としたものを、情報システムのＩＴ機能という多くの従業員が日々の行う業務処理に、【ブレイクダウン】しなくてはならないからである。
さらに難しい課題がある。現状を分析し、業務を改善し、理想的な情報システムを設計したとしよう。ところが、現実に情報システムを使用し改善した業務を実行すると、業務処理が難しく運用できず、動かないコンピュータとなることがある。これは、従業員の【業務処理能力】が、情報システムが前提とする業務処理能力を充足していないからである。ＵＭＬ等により理論的な思考で設計したものは、現実の従業員の業務処理能力への配慮が薄く、乖離することが多い。
従業員の業務処理能力以上に難しい問題がある。また、多くのシステム設計技法では、あまり考慮されていない問題である。それは、企業風土、すなわち、企業を構成する経営層や従業員の行動や思考パターンである。情報システムは、システムが自動的に業務処理を行うのではなく、あくまでも人間活動を支援するものである。従って、人間が協力しないシステムは動かない。その人間には感情や固有の行動パターンがある。人間が集まったものが企業であり、企業も固有の行動パターンを持っている。それが企業風土である。ただし、企業の構成員でも、経営層と一般従業員では行動パターンが異なる。
経営層では、固有の【経営ポリシー】を持つ者が多い。いかに適切な業務改革でも、経営ポリシーに反する改善は容認されない。経営層がそれに気がついた時点で、システム設計は変更となる。
従業員はさらに複雑である。情報システムは、日々慣れ親しんできた業務処理方法を変更するのである。また、新たな方法を学ばなくてはならない。特に、標準化等により属人的なノウハウや既得権が失われる場合は、強力な抵抗を示す。個人だけではなく部門でも同様である。これらの【従業員の持つ行動パターン】を無視した業務改革は、強い抵抗を受ける。従業員が協力しない情報システムは運用ができない。しかも、これらの企業風土は、現状分析やＵＭＬの分析からは容易に把握できない。また、従来のシステム設計技法では、ほとんど取り上げられていない。
動かないコンピュータの原因を分析すると、従業員の業務処理能力と企業風土への配慮不足が多い。企業情報システムの開発に携わっている読者であれば、実感があるのではないだろうか。
ＩＴベンダーでも、ＳＥに要件定義に関する教育を行う。簿記等の業務知識研修やＵＭＬ等の分析手法の教育を行う。しかしながら、初心者ＳＥは適切な要件定義ができない。何度も設計変更や追加が生じる。稼動しても修正の連続となる。しかしながら、ベテランＳＥの要件定義は異なる。設計変更の頻度も低い。また、稼動後比較的短期間で安定稼動となる。確かに、初心者ＳＥは経験が少なく業務知識も十分ではない。しかしそれだけではない。先に説明した部分で差異が生じ、それが要件定義の品質の差異を大きくしているのである。
先の説明からベテランＳＥと初心者ＳＥの差を下記に示す。
(1)豊富な業務知識
(2)経営管理の視点
(3)経営戦略の情報システムへのブレイクダウン
(4)業務運用能力の視点
(5)経営者のポリシーの視点
(6)従業員の行動パターンの視点
ベテランＳＥは永年に渡る開発経験を通じて、「(1)豊富な業務知識」を蓄えて行く。また、様々な開発を経験し、「(2)経営管理の視点」や「(3)経営戦略の情報システムへのブレイクダウン」の視点をつかんで行く。さらに、システム開発の失敗経験から、「(4)業務運用能力の視点」、「(5)経営者のポリシーの視点」、「(6)従業員の行動パターンの視点」への配慮が重要なことを体験して行く。
しかし、すべてのＳＥがベテランＳＥになれるわけではない。常に経験から学び、努力する者に限られる。また、ベテランＳＥになるには、10年、20年といった歳月も必要となる。
筆者はコンサルティングファームで12年間に渡り、要件定義段階を中心とするシステムコンサルティング業務に従事した。この時も、課題で説明したような失敗の連続であった。その苦悩から、適正な要件定義の方法論を模索した。しかしながら、多くのシステム設計技法では、前述の課題解決には至らなかった。
その後、大学に移り、以来13年にわたり要件定義の方法論の研究に従事した。5年前には理論を構築し学位論文にまとめた。その後、方法論の実用化に取り組み、著書として発刊した。また、方法論の普及のため大学発のベンチャー企業も設立した。
方法論では、ベテランＳＥと初心者ＳＥの差である先の６つの課題を解決できる方法を提供している。また、初心者ＳＥでも使えるように６つの課題への対応知識を、「企業情報システム機能選定知識ベース（ＦＵＳＥ知識ベース：Knowledge Base of Functional Selection for Enterprise Information Systems）」として提供する。これを利用すれば、初心者ＳＥでも比較的短期間でベテランＳＥに成長できるものである。
次回は、方法論の中核である「ＦＵＳＥ知識ベース」について説明する。なお、本方法論は、ＵＭＬ等のシステム設計技法に置き換わるものではない。既存のシステム設計技法が扱わない部分に焦点を当てた方法論であり、既存のシステム設計技法を補完する位置づけのものである。