アーキテクトを目指すITエンジニアのための「システム分析」
先回は、問題分析についてお話しました。今回は、システム構築の上流工程「システム分析」についての概要をお話します。今後数度に分けて、その中のステップである「要求分析」、「データ分析」、「機能分析」と、話を進めていきます。
システム分析でのアプローチは、大きく分けて「帰納法」と「演繹法」があります。
いろいろ説明の仕方はありますが、簡単にいえば「帰納法」は現状肯定型、「演繹法」は現状否定型でしょう。つまり、現状に修正を加えて「新」とするか、現状にとらわれずあるべき姿を「新」とするかという違いです。
次の図は、ジェームス・マーチンやデマルコ社でから公開されているさまざまな手法を組み合わせて、1つの流れにしたものです。わたしがある日本のメーカーに在籍していた時に、第1号ユーザーに適用する上において、現場サイドの観点で改良に改良を加えました。
左上の「現行システム」は、コンピュータ化されたものも含めた、現行の業務プロセスを指しています。それを現状調査しモデル化していくというのが、「機能分析」に当たります。
その現行システムが、何らかの課題を持っていて、解決策を施した上で新システムにしたいという要求があり、システム構築を進めることになります。そのシステム要求をまとめてモデル化するのが「要求分析」です。先回、「問題分析」とは裏表の関係になると話しました。
さらに、現状調査した中からデータ項目を集め、正規化手順をベースにデータモデルを作り出すのが「データ分析」です。機能分析や要求分析の進み方に関らず、データ項目さえある程度揃えることができれば、作業を進めることが可能です。
以前述べたように、現状調査は組織の枠の中で進めることになりますが、システム化の前提となるのは、組織の枠を取り払ったものになります。
仕事は組織で分断されていますが、システム化するには、業務プロセス本来のスタートからエンドまでを対象とします。したがって、システム分析者が全体をつかむためには、組織の枠を取り払って抽象化する必要があります。これが論理モデルとなり、現行システムの機能モデルを「現行論理モデル」と呼びます。
システム要求は、ロジックツリーの手法を用いて、目的／手段で階層化しておき、機能モデルに対して変更要求として当てていくことになります。その結果右側に登場するのが、新機能モデルとなります。
この新機能モデルからData Flow Diagramを書き起こし、新システムのモジュールの設計や、さらに業務プロセス設計に落として行くことになります。ここでデータモデルを利用してデータフローやデータベース設計を進めるという具合です。
ERPを適用する場合は、この新機能モデルとERPの持つ機能のギャップ分析を進めることになります。
この一連の手順は、先に述べた「帰納法」になります。現行システムをモデル化し、システム要求による変更を加えて新システムモデルに持っていくという、典型的な「現行システム＋修正＝新システム」の考え方です。
しかしながら、この方法を習熟することで「演繹法」にも活用することができます。つまり、新論理モデルから作成していくという流れです。しかし、システム要求をモデル化しておかないと、新システムが要求を満足しているか検証することができません。
また、データモデルを作成する場合も、ある程度現状調査しなければ、データ項目を集めることができません。新システムを構築しても、データは旧システムから移行します。このようにデータ(群や項目)には、「新」も「旧」もないのです。もちろん、データ量は増えていくものではありますが、それは種類が増えるのではなく、あくまで量が増えるということです。
したがって、演繹法の場合は現行論理モデルを作成する必要はありませんが、要求分析もデータ分析も実施することになるのは、言うまでもありません。
「帰納法」の考え方を習得すれば、それをベースにして「演繹法」にも対応できるということです。
次回は、システム分析の1番目のステップである「要求分析」についてお話しましょう。