勉強会のテーマについての記事以外に、留意事項や補足的説明も折々に書いていこうと思います。
これまで、業務システムの抱える問題ということで構造上のいくつかの課題を指摘しています。そこで、この構造の問題、あるいは構造化について考えてみましょう。
構造的に問題があるという場合、今が悪構造になっているからそれを｢構造改革｣する必要があるということになります。
しかし、このとき気をつけなくてはいけないのは、構造化されていないものをいくら改革しても意味がないのです。ですから、まずは適正に構造化して、それに対して今の構造とギャップがあるので、それを変えていくというアプローチになるはずです。
ここは重要なところで、ちゃんと構造化したものを見せなくてはどこが問題なのかよくわからないことになります。
例えば、小泉構造改革は、構造化した姿を国民の前に提示して、その中のこの部分を改革するということをしなければいけなかったのですが、それが十分やられていなかったからいまの揺り戻しのようなことがおきているのではないでしょうか。
ですから、繰り返しますが、まずはきちんと構造化できれば改革のターゲットがあぶりだされてきて、おおかたの目的が達成できてしまうように思います。
それでは「構造化する」とは、どういうことでしょうか。下記のように定義してみました。
こうした観点からながめてみると、業務システムが対象にしている業務そのものも性格の違った要素から成り立っています。基幹系業務とか情報系業務とか言われたりしますが、それだけではなく、定型的なのか非定型なのか、日常的なのかプロジェクト的なのかといった、さまざまな区分にわけることができます。
もちろん、そうして分解された業務に対して、適用すべきシステム技術やソリューションが変わってきます。業務の特性に合致したものをもってこないと使いづらいシステムであったり、無理が生じてしまいます。
また、そのシステム構造についてもただ対象アプリケーションだけを見るのではなく、システム間の連携だとか、システムが動くプラットフォームにおける機能・プロセス・データの分離といった「構造化」の視点が大事になってきます。
そして、次に重要なのは、その構造をどうながめるか、ギャップを掘り起こすかといった分析眼になります。
よく行なわれるのが、2次あるいは3次元的な見方です。2次元というのは、適正なスコープであるかどうか、簡単なところでは、4象限の図を思い浮かべるといいかもしれません。3次元というのは階層を見ることです。要するに縦横の面で切るということを指します。
ところがそれだけでは不十分なような気がします。4次元的な見方も必要になるのではないでしょうか。4次元的というのは時間軸としてリーズナブルなのかといったことです。この観点は意外と忘れがちで、未成熟な技術を今は使わないとか、人材を育成する時間がいるとかといった分析が重要です。
おわかりいただけたでしょうか、システム構築を考えるとき、構造化する意味はここにあります。従来ではひょっとすると構造化の必要はなかったかもしれません。どーんと一気に大きなシステムを作ってしまうやりかたであったわけで、そうなると構成要素はどうであれ、全体として動けばいいやという思想になってしまいます。
ＳＯＡやＢＰＭの概念が出てきたのもそういうやり方のアンチテーゼであったわけです。ですから、こうした概念を具現化するための前提は「構造化」であると言っているのです。
適正な構造化ができれば、部分的（2・3次元的）かつ段階的（4次元的）構築ができるのです。この恩恵は非常に大きいと思うのですがいかがでしょうか。
