2011年05月23日

システムの再構築について

大企業のシステム開発において、これまではよく、システムの再構築案件が多くありました。
これからはクラウドを企業が取り入れていくことも多いでしょう。その場合、これまでの基幹業務システムの再構築とは一風変わったシステム開発になるかもしれません。
これからお話しするのは新しいことではなく、むしろ古いシステムの再構築についてです。

システムの再構築においては、現行システムをホストからオープン系に変えることが多いと思います。個人的にはオープン系という言葉はあまり好きではありませんが、ここではオープン系と表現します。

その変更において、オープン系にするのは色々と理由がありますが、多くは運用保守費用の低減があると思います。ホストよりもハードウェアやミドルウェアの制約が少なく、階層型DBのようなシステムの改変がややしにくいものよりも、仕様変更に強いという魅力をSIerは提案しているはずです。
また、その際にSIerは出来る限りの仕様変更を取り入れることも提案していることでしょう。
つまり、この再構築は、現行運用を踏襲しながらもオープン系に切り替えることと、オープン系にした際に合わせて仕様変更を行う2つの目的が含まれています。

話はそれますが、要件定義では要件を決めること以上に大切な事があります。
それは顧客のその案件の目的を明確にし、顧客がそれを理解するということが大切です。
目的が決まっていない案件は、話が収束しません。もし現行の再構築であれば、まずはそれを優先していかなければ、そもそもの目的すら遂行できないことが多いと思います。そして、それがプロジェクトの失敗につながります。
要件定義では顧客からの要求分析結果を元に、顧客の抱える問題からシステム開発を行う目的を明確にすべきなのです。その上で、顧客のビジネス上の効果が表現されます。ただし、このビジネス上の効果は私たちSIerが提案や可能性を考えることはできますが、実現するのはSIerではなく、顧客自身であることも明確に顧客に理解させる必要があります。
1億円で開発したシステムだから1億円以上の利益が出るかどうかは、使う人と使い方次第です。
これは私たちSIerが無責任にシステムを作ることとは無関係で、要は顧客もシステムを作っているという責任があることを示しています。
よって、顧客もシステムを作る上で利益や効率性を考えるのであれば、つまり目的や狙いを達成していくのであれば、顧客自身もシステムを開発する立場に立ち、運用要件や業務用件、性能要件を積極的にSIerに提示し、要件の達成を求めたり、交渉する必要があります。

もう1つ異なる話をします。
目的は2つ以上あると、よく失敗します。それが結果的に同じになる目的であれば1つと見なせるでしょう。2つある目的は必ず方向性の違いや、さらに運が悪いとプロジェクトの方向性を見失わせます。
よって、目的が2つ以上あるのであれば、どちらを優先するのかを1つに絞らなければなりません。
2つあっても必ず優先度を立て、最優先の目的を1つだけに絞らなくてはいけません。
これは出来る限りSIerがあるべき姿を提案できると、素晴らしい提案になることでしょう。業界をよく調査し、その企業をよく勉強し、その企業のためになることを提案しているのでしょうから。。。
ですが、そんなことは大概は難しいどころか、その企業の人間が決めるべきことです。
要件定義フェーズで顧客は、必ず目的を1つに絞ることが求められるべきです。

話の脱線を簡単にまとめると、要は目的をしっかり1つに決めなさいということです。
さてここで、この脱線も踏まえて話に戻ります。


もしシステムの再構築を行いたい場合は、私は2フェーズにプロジェクトを完全に分けるべきだと考えます。
第1フェーズではオープン系に現行を完全に切り替えるという目的を立てます。その切替が運用に乗ったあとに第2フェーズで仕様の変更を取り入れる修正を施すべきです。
これは顧客にとってはビジネスチャンスの喪失も意味することは分かっています。
ですが、多くの場合はこのために顧客は通常よりも暗に多くのリスクを受容させられています。
SIerは必ず現行と新仕様との齟齬を簡単に吸収できないリスクを金額に載せています。そしてその金額は高いものです。
もしオープン系にしているならば、仕様変更は簡単だと言いながらも同時に行うと実は高いケースがほとんどです。
逆に言えば、仕様変更や保守費用が安くなるはずなのに第2フェーズでの開発費用が高いのであれば、そもそもおかしくありませんか?
よって、フェーズを分けた場合と分けない場合のそれぞれについて、顧客はRFPのタイミングでSIerに見積もりを出させるべきです。
おそらくSIerはより多くの条件と縛りを提案書に載せてくるでしょう。
でも、フェーズを分けたならば、最初は現行通りになり、後は運用保守費用が下がる方法なのですから、顧客から見れば縛りも金額も必ず下がらなければ、おかしいと思います。

期間が延長されることはあるでしょうが、運用保守フェーズという位置づけである程度の新機能を吸収できないのであれば、そのオープン系の効果は嘘でしょう。
また、人が必要というのであれば、再構築によりシステムの最適化がおかしくなっているはずです。
さらには、同時に2つの目的を達成するということで、できないと言われる仕様や最初から要件に話が出てきていないじゃないかと言うSIerはおかしいことを言っていると分かります。

私たちSIerはすでに、今までのシステム開発のやり方ではこれからは顧客からは選択されなくなると思います。
それこそクラウド上で簡単にシステム開発できる環境まであります。そうなれば、顧客は時間をかけるよりも内製で済ませるでしょう。

私たちはWin-Winの関係と大きなことを言います。私の会社でも大きく言っています。
でも、もうその関係性のいくつかの嘘を、是正すべき時期に、見直すべき時期になっています。むしろ、これからではもう遅いでしょう。。。



さて、私の会社は生き残れるのでしょうか。。。
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/45437976
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック