ただ、データモデルを描くことでデータの整合性を、業務分析などプロジェクトの早い段階で確立するなどの、データ中心指向の特長による直接的な効果は、いわゆる上流工程の範囲にその多くが集中しています。
そのため議論が上流工程中心に成りがちですがが、上流工程のまとめ方に話を進める前に、良く、「データ中心を言う連中はデータモデルさえ完成すれば、システムが完成した様な気で居る」と言う批判をかわす意味で、先ずは、システム開発という作業が全体として、いかに多岐にわたる情報を必要とするものかということを俯瞰しておきます。
ビジネスシステムを導入しビジネスの中で使って行くためには、センター設備、プラットフォーム、ミドルウェアー、ネットワーク、実装方法、要員育成など、実に様々なことを検討し決定し実行し、継続的に運用しなければなりません。
主な検討要素は「業務要件」以外に「設備・環境要件」・「運用要件」・「実装要件」などです。
設備・環境要件は、センター設備やプラットフォームの機器と基本ソフト、ネットワーク設備や、データベースを含む各種ミドルウェアなどです。
業務運用や開発環境などにクラウドを使うなどもこのカテゴリで検討することになります。
運用要件は、システム運用の形態や体制、データのバックアップ・リカバリの方式やタイミング、スケジュール管理、運用監視、自動運転、要員訓練などで、本番業務に移管されたソフトウェアーの管理と移管時の受け入れ試験も運用の範囲に含みます。
実装要件は、実装手段の検討で、使用言語やジェネレートツールから、プログラムプロダクツ・ERPなど、要求される機能を実装する方法について、一連の開発環境や技術者の動員と専門家の支援などと合わせて検討します。
|
例えば、プラットフォームのOSを特定すれば、そのOS上で稼働可能なミドルウェアーから必要な機能を調達しなければなりませんが、反対に、特定のデータベースマネジメントシステム(以下、DBMS)を選定するなら、そのDBMSが利用可能なOSでプラットフォームを構築する必要があるという具合です。
また、開発要員が習熟している言語やジェネレータ・開発環境などの実装要件を中心にして、他の要素を選択することも一つの考え方です。
教育や習熟と言う要素は、発展著しいハード・ソフトの機能仕様に幻惑されて軽視しがちですが、いかに素晴らしいシステムも、開発者、運用者、そして何よりも利用者に、それを使いこなす知識や技術や習熟が無ければ期待通りの効果は上がりません。
単純な操作の省力化から、管理・計画・戦略へとデータ利用の範囲が広がって来れば尚更です。
ああもあろう、こうもあろうと導入した高価なDWHやBIシステムが遊んでいませんか。
色々と複雑で込み入った要求に何とか答えたと思ったシステムは、結局ほとんど使われていないって事はありませんか?
以前は、管理資料を一方的に用紙で配布していたので、システム部門は、その利用率には知らん顔が出来ましたが、今はサーバーの稼働状況として毎月報告されるので、放置しておく訳にも行きません。
しかし、良く考えてみると、ディシジョンサポートシステムやインフォーメーションマネージメントシステムから、データベースマーケティングやデータウェアハウス、ビジネスインテリジェンスと続く管理・計画・戦略系のシステムに本気で効果を期待しているなら、景気の悪い時こそ、何とかそれらのシステムに戦略的に投資してでも、業務の拡大と利益確保を目指すべと言う選択を行うべきなのでしょうが、不況によって、一斉にIT投資が削減され、業界の潮流もクラウドや仮想化などビジネスシステム自体としては何らの発展性もない、ハードウェア周りの倹約指向一色になるということは、IT業界が喧伝しているような効果は、最初から誰も本気で信じていないということでしょうか。
効果が無いのか使いこなせていないのかは意見が分かれるところでしょうが、ここにビジネスシステムの評価の難しさがあることは間違いないでしょう。
話が逸れてしまいましたが、ま、世間で思われているほど、世の中オープンな訳ではないし、次々と新しい良いものが提供されて来ているので、しばらくは定番と言うものが定まりそうにも無いので、状況に応じた適宜の判断を続けていくしかないでしょう。
では、システム開発に必要な情報は、業務要件だけでは無いと言うことを確認したところで次に話を進めます。
なお、ビジネスシステムを運営していくには、いろいろと考えなければならないことがありますが、その大部分は専門家に委任することが可能です。
最近はお任せ流行りで、所有から利用だとばかりに、アウトソーシングだクラウドだと使い方に合わせた各種サービスが提供されていますが、セキュリティやBCMを十分考慮した上で利用できるものは利用すべきでしょう。
但し、任せるのはあくまでも専門家へなので、少なくともそれぞれの専門家を見分ける目を持っている必要はあるようです。
筆者の専門は、業務分析・データ分析・ERD・データベース・プロジェクト管理と言う範囲なので、不調プロジェクトの調査依頼に対しては、もちろん一番にERDを検証するが、「こりゃ、ERD納品の段階で既にプロジェクトの失敗は約束されたようなものだな」と言うケースの多い事にはあきれます。
あきれる程ファニーなERDを納品したベンダは当然として、納品物を検証すべきユーザや、それを支援すべきコンサルタントなど一連の関係者の中に、誰一人専門家と言うレベルのエンジニアは居なかったと言うことなので、金さえ積めば何とか成ると言う問題では無いようですので気を付けましょう。