部品化はその粒度が大きくなるに従って難しくなる。様々な要素が加わって、オプションがどんどん増えていくからだ。特に、ビジネスロジックに至っては、その組織ごとに昔からの「やりかた」があり、システムは、それに合わせる形で作られてきた。
ＩＴが補助的な、つまり省力化の役割しか持たなかった時代はそれでよかっただろう。しかし、いまや、ＩＴがなければ不可能な仕事も多い・・・・、というよりＩＴをいかに使いこなすか、ということが会社の生命線にもなりつつある。
ビジネス環境の変化はどんどん加速していく。それはあくなき利潤追求という資本主義の本質と結びついている。他より効率よく、どんどん新しいことを進めていかないと会社は生き残っていけない。ＩＴはそれを支えてきたのだが、いまや、ＩＴ化をどんどん加速しなければ環境の変化についていけない主客転倒な時代になってしまったようだ。
そんな中で、システムのライフサイクルはどんどん短くなり、かかるコストもどんどん膨らむ。そんな状況下では、業務とＩＴを別々に考えているわけにはいかない。人とＩＴを含めた全体を「システム」と考えることが必要になる。これは、ＩＴを仕事にあわせることでも、仕事をＩＴにあわせることでもない。仕事全体の最も効率のよい形を考え、その中で人とＩＴの分担を決めるのだ。つまり、業務全体に対する見直し（ＢＰＲ)が必須になってくる。これは簡単ではない。ともすれば、ＩＴ屋は人の側をシステムに合わせようとする。いわゆるパッケージ文化はシステム開発は効率化しても、往々にして人にストレスをもたらす。パッケージが提供するモデルは、あくまでその業種の標準的なモデルであり、その組織によって適合度が違う。だったら業務をパッケージに合わせれば・・・と思うのがＩＴ屋のあさはかさ。業務の流れは、長年のノウハウでもある。多くの会社は漫然と同じやり方を続けてきたわけではなく、それなりに自分たちの仕事に合った形を確立させている。したがって、双方の歩み寄りは必須だ。この歩み寄りを合理的に行うために、業務全体の見直し（ＢＰＲ）が必要になるわけだ。これをきちんとしないと、結局、システムへの不満が残ったり、過剰なカスタマイズが発生したりする。
仕事のインプットとアウトプットを明確にしたうえで、その間のプロセスを細分化していくと、複数の業務で類似の作業の存在が見えてくる。これら類似の業務を「手間を増やさずに」どう共通化するかというのがポイントだと思う。共通化したことにより、作業の手間が増えてしまっては本末転倒だ。手間を減らす方向で考えられるかどうかがポイントである。
この共通作業の部分をＩＴ化して効率を上げれば、複数の業務の効率を上げられる。また、逆に、似て非なる処理を作りこむ必要もなくなり、ＩＴコストの削減にもつながる。
言うのは簡単だが、実際には難しい問題が多いのも事実。こうしたＢＰＲをコンサルタントにたのむ会社も多いのだが、多くの場合、「まる投げ」が発生する。結果として、コンサルタントは、その会社のすべての部門を相手にして、ヒアリングやらとりまとめやら、ひどい時には部署間調整までやらされるハメになってしまう。これではコンサルタントはそれに見合う費用をもらうか、どこかで線を引いて「腰が引けた」作業に徹するかのいずれかを選択するしかなくなってしまう。少なくとも、会社側にも取りまとめ役、それもある程度ＢＰＲのやりかたについて知識、経験と必要な権限がある人間が必要だ。自前で全部やれればいいのだが、一般の会社で、ＩＴまわりの最新情報をフォローしていくことはなかなか難しいから、その部分はコンサルタントにまかせ、業務まわりは自社で考えることを基本にすべきだろうと思う。
特に日本はこうした「まる投げ」傾向が強いように思う。世の中が、今よりゆっくりと進んでいた、古き良き時代の名残ともいえる「まる投げ」を続けていたのでは、今のグローバル化した経済の中で企業は生き残っていけないと知るべきだ。会社は、それ自身でＢＰＲのエキスパートを最低限の人数持つべきだと思う。ＢＰＲはそれ自体がひとつのマネジメントサイクル（ＰＤCAサイクル）でもある。決して一回きりで終わるものではなく、継続的に改善されるべきものだからだ。経営陣も少なくともそうした知識は持つべきだ。長年の経験は宝ではあるが、それを体系化できなければ伝承もできないし、応用もできない。そういう意味で経営者はＭＢＡくらいは持っているべきだ。特に、経営判断の基準をぶれさせない、という意味では体系化された知識は重要かもしれないと思う。もちろん、経営者特有の「動物的なカン」も必要だが、往々にしてそれは、知識によって体系化された長年の経験から生まれる。
ちょっと話が脱線気味だが、これからの話は、こうした本当の意味でのＢＰＲが前提になってくる。これなしでは、「使えない考え方」になってしまうからだ。せっかく、ＪＳＯＸ対応で業務フローを書いたのだから、一度それを全部並べて見比べながら、業務の非効率な部分を見直してみるといいのではないだろうか。その上で、今のシステム（人＋ＩＴ）の問題や足りない点、共通化できそうな点を洗い出してみるといいだろうと思う。
さて、こうした前提で、ＩＴのアーキテクチャを考えてみよう。
（続く）
コメントする