さて、今回もシステムリフォームの話を続けたいと思います。
システムリフォームを請け負った場合に、最初に調べなければならないことを、175号のメルマガでお伝えしました。
そこでは、OSやミドルウエアや言語、特にソースプログラムが最新かどうかに一番注意しなければいけない。と言いました。
また、その次の号で企業独自のビジネスロジックは、プログラム言語ではなく、データベースにストアドプロシジャとして一元化しておくことが望ましいとお話ししました。
これを読んで「あれ？」と変に思われた方もいらっしゃるかと思います。
もしこれが、システムリフォームではなく新規のシステム開発であったとしたなら、一番最初に必要な調査分析は「業務フロー」であり「システムをどのように運用するか」であるのではないかと思うはずです。
もちろん、システムリフォームといえ、それはその通りであり、業務フロー図がきちんと存在していれば、非常に役立つのです。
しかし、実際のところ、例えば5年以上使われ続けたシステムが、今でも5年前に描いた業務フロー通りそのままに運用されているということがあるのでしょうか？
それは、数少ないと思うのです。
業務フローをSEが作成するのは、システム開発の一番初期の頃です。
現状の業務フローをヒヤリングして、図解して作成します。
次に設計、開発の後、ユーザーがそのシステムを使い出すのです。
そこから5年以上経ったとき、
すべてのシステム機能が使われているのかどうか？
システムの業務フローは設計したSEが意図したままで行われているかどうか？
SEは次の新しいシステムに移っていく為、確認できないことがあるのです。
ある部分は、まったく使われていない。ということがあるでしょう。
そして、明らかにSEが意図した使われ方をしていない部分も出てくるのです。
実は、ユーザーから質問が来ないからという理由で、当然、すべてのシステムを使っているはず、と思い込んでいるSEも多くいるのです。
しかし、実際には、ユーザーはその機能がよく分からず、もしくは面倒だからとその機能を使わずに運用で逃げてしまっていることもあるのです。
実は、私も、同じような経験が何度かありました。
業務に携わる現場は、本当に驚愕すべきことが多くあります。
「えっ、そんな風に使うと思わなかった」ということさえよくあるのです。
SEがどんなにがんばってヒアリングして考えて業務フローを作っても、どう使われるのかは分からないのです。
また、使うまで分からないことも幾つもあるのです。
そういう理由で前の号では初期に作った業務フローについては触れなかったのでした。
もちろん、システムリフォームを行う場合に、現在の業務フロー、運用ルールがどうなっているかをヒアリングすることは、必須事項です。
ただ、実際には、ヒアリングよりも先に現状のシステムを掘り起こし、現状のシステムのあるがままを理解するところから始めるSEが多いと思うのです。
なぜなら、お客様から本当の実態、真実のビジネスモデルを聞き出すには多大なスキルとコストがかかるからです。
私も、システムリフォームでは、現状のシステムを分析し、システム側からみた業務フローをまず頭に叩き込んでからお客様にヒアリングすべきだと考えています。
システムリフォームから業務フローを考えるとき、
まず、現状システムの理解を行い、次に現状の運用フローのヒアリングを行う。
という順序になります。
Vol.00180