前のページへ サイトマップへ ホームへ
 
DOAコラム一覧へ次のコラムへ
                         システム開発
DOA Evangelist:小見山 昌雄

 1.ビジネスシステムの要件

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

 2.ビジネスシステムの業務要件

 業務要件は機能要件と非機能要件に分かれます。
 従来、非機能要件と言われているものの範囲がはっきりしませんでしたが、独立行政法人 情報処理推進機構(以下、IPA)から、非機能要求グレード利用ガイドが提供され、その中の「システム基盤の非機能要求に関する項目一覧」に非機能要求の詳細な体系が説明されているので参考にすると良いでしょう。⇒IPAサイトへ
 「システム基盤の非機能要求に関する項目一覧」は機能要件と合わせて、業務要件の抜け漏れを評価する場合のベースラインとして業務設計やシステム設計のレビューやシステム開発プロジェクトのシステム監査などでの活用が期待出来ます。
 さて、業務の機能要件は、ビジネスシステムを導入する目的を実現する重要な部分ですが、機能要件を明らかにする段階で、整理しなければならない情報は大きく4つに分かれます。
 機能要件の情報カテゴリ  情報の概要
 機能構造(またはプロセス構造)  機能またはプロセスの階層構造で、機能・プロセスの抽象的な概念をを具体的なワークフローまで細分化する
 ワークフロー【注1】  ユーザインターフェースを利用してビジネスシステムのねらい【注2】を実現する一連の具体的な操作手順
 ユーザインターフェース  サーバー間、サーバークライアント間の通信電文を含むユーザインターフェースの仕様
 データ構造  ビジネスで使うデータ項目の整合性を整理したデータモデルと検証・導出などの関係の定義
 【注1】:ワークフロー
 ここでは、ユーザインターフェースを使う作業の手順を表現したものと言う単純な意味で使っており、いわゆるワークフローソフトウェアーの利用や処理手順の自動化を指している訳ではありません。
 【注2】:ねらい
 ここで「ねらい」とは「目的」と一対の表現で、その意味は問題解決技法「MIND−SA」の用法に従っています。
 「目的」とは、その行動で直接実現しようとする成果、「ねらい」は、目的を達成することで間接的に実現しようとする成果です。 (目的・ねらいの詳細な説明については、システム企画研修株式会社様のサイト⇒こちら をご覧ください。)
 ここでは、ビジネスシステムの目的を、ビジネスシステムが直接実現する成果、ビジネスシステムのねらいを、ビジネスシステムの目的が実現されることで間接的に実現が期待される成果と言う意味で使っています。
 具体的に言うと、ビジネスシステムで直接実現出来るのは、ビジネスを進める中で発生し、又は認知したデータを記録し、Aつ用に応じて編集・加工して提供することだけなので、その目的はユーザインターフェースの実現までであり、それを有機的に連携操作して「在庫の削減」や「配送の迅速化」から「シェアーアップ」・「売上の拡大」や「利益の増加」など、ビジネス上の成果(ビジネスの成果=ビジネスシステムのねらいと考えています)を実現するためには、ビジネスシステムからデータの提供を受ける側に居る人たちの具体的なアクションが必要になると言うことです。
-----------------------------------------------------------------------------------
 この四つの情報の内、機能構造とワークフローはプロセスに関する情報、残りはデータに関する情報と考えれば良いでしょう。
 なお、この順番は整理の手順や順番を意味している訳ではありません。
 では、以下、順番に整理の要領とポイントを説明します。
 

 3.プロセスに関する情報整理

1.プロセス構造
 ビジネスの機能や処理プロセスに着目した階層構造は、手順や流れで対象を把握することに慣れている人には分かり易いので、システム・サブシステム・ファンクション・タスク・アクティビティ(ファンクション以下の名称の順序は適当です、何か決まった順序や法則をご存じに方は教えて下さい)とビジネスを階層構造で表現したものが良く作られます。


 EA(エンタープライズアキテクチャ)で有名になった機能構成図(DMM-Diamond Mandara Matrix)やデータフローダイアグラム(DFD-Data Flow Diagram)も処理機能やプロセスを整理しています。
 販売管理システムには、受注・発注・在庫管理・入出庫などのサブシステムがあり、受注サブシステムには、顧客管理・受注登録・商品管理・受注変更のファンクションがあり、受注登録ファンクションには、顧客の確認タスクがあってという具合です。
 機能やプロセスを「販売管理」「在庫管理」などと表現していたのでは、いずれも抽象的・概念的で、具体的に何を行うのかはっきりしません。
 ビジネスシステムはプログラムを作り、ユーザインターフェースを実現し、具体的なワークフローとして作業手順を構成することでビジネスを支援するので、具体的なプログラムの仕様を確定しないことには、開発作業が前に進みません。
 そのため、階層的に細分化することで、抽象的な概念を具体的な仕様へと結び付けて行きます。
 機能・プロセスを構成する要素としては、プログラムとユーザインターフェースはほぼ同じ粒度と考えられますが、ワークフローは複数のユーザインターフェースを組み合わせた手順として認識されるので、プログラム・ユーザーインターフェース・ワークフローの中では、最も粒度が大きなものとして認識されます。
 ということは、とりあえず具体的なワークフローのイメージが描ける単位まで細分化を行う必要があると言うことになります。
 例えば、取引先情報登録・受注受付・在庫引当など、現行システムの中に存在するワークフローなどに辿り着くと一安心です。
2.ワークフローの明確化
 続いては、現行システムのユーザインターフェースを思い浮かべながらワークフローの具体的な手順を作る作業に入ります。
 受注を受け付けたら、まず、取引先確認画面で取引先であることと、未払い・督促・係争などは無く、取引継続可能な良好な関係であることを確認した上で、商品の注文を聞き、商品の存在を確認したら、引き続いて在庫状況を確認し・・・などという手順です。
 業界毎、企業毎に独特の表現や符牒があるので、部外者に検討しろと言われると困りますが、普通は現行業務の経験者が直接分析や設計に当たるか、レビューを行うので、ここまで来れば後は現行システムを引き写して大した混乱もなく、作業が収束して行きます。
 ワークフローを具体化する中で、個別作業に使われるユーザインターフェースが明らかになるので、ここでめでたく、プロセスとデータの情報整理が融合します。
 後は、ユーザインターフェースの仕様を更に明確にしてプログラム仕様として、いざコーディングへということになるのですが、これは今までと同じ従来のシステム開発なので、データ中心指向としては及第点は貰えません。
 ここで、業務要件整理の後半、データに関する情報整理に行く前に、ビジネスシステムの目的について、改めて考えてみたいと思います。 

 4.ビジネスシステムの目的

 ビジネスの業務要件の節の【注1】でビジネスシステムの目的とねらいについて説明していますが、再度確認すると、ビジネスシステムの目的、すなわちビジネスシステムの目的は、(開発・プロダクツの購入・アウトソーシングなど、導入の形式に関わりなく)ビジネスの中で日々刻々と発生するデータを記録し、記録したデータをニーズに応じて提供することです。
 提供を受けたデータを如何に活用し、ビジネスにどのような効果を生むかについては、ビジネスシステムのねらいの話になります。
 昨今のデータ利用環境の充実から、データ利用の方向が、日々のビジネスの円滑な実施から、蓄積されたデータを分析・加工することで、ビジネスの方針・計画・戦略などに関する示唆やヒントを得ようとするものの比重が増しつつあることは、皆さんご存知の通りです。
 確かに、データは集積度を上げて行くに従って、戦略的な要求に答える可能性は高くなりますが、データを如何に加工するか、データから何を読み取るかは、あくまでも利用者の能力やセンスの問題です。
 そのため、ねらいのバリエーションに依らず、ビジネスシステムの目的は、データの記録と提供に収斂します。
 最近では、銀行口座間の取引や株券の電子化による株取引など、サーバー間の電子的なデータ交換だけで処理が完結するケースが増えています。
 今後も、お金や株券など、本来概念的存在である価値とか権利とかの証票として作られていたものは、どんどん電子情報に置き換わることになるでしょうし、デジタル化で音楽や映像など、以前は物理媒体を介して取引されていたものまで電子情報に置き換わっています。
 そのようなケースでは、ユーザが人ではなく、取引先のサーバーになるので、ユーザインターフェースという表現自体が不適切な印象はありますが、個々のシステム別には、顧客からの依頼内容を記録した上で、取引先・銀行・証券取引所などのサーバー向けに、出力ユーザインターフェースとして電文を送信することで、振り込みや引き落としや株の売買を依頼する次工程のイベントにデータを提供していることに変わりはありません。
 以上、ビジネスシステムの目的が、「ビジネスの中で発生するデータの記録と提供」に収斂すると言うことは、ビジネス自身に特段の変化が無ければ、少なくとも、ビジネスシステムの、ビジネスで発生するデータを記録する機能の部分は、現行システムと何ら変わりが無くて当然です。
 また、データを提供する機能部分においても、データを提供することでなにがしかの行動を誘発し、最終的には取引先や顧客など社外の存在に対して、商品の配送やサービスの提供など、何らかの働きかけをすることでビジネスが成立していることを考えれば、社内システムを再構築したという理由で、大きく対応内容が変わる訳もありません。
 つまり、業務機能要件的には、基幹システムの再構築とは言っても、日常継続的に発生する保守要求以上の変化は起こりようがありません。
 即ち、業務機能要件的には代り映えしないビジネスシステムしか出来なくて当然ということになります。
 良くシステム再構築に際して、「将来にわたるニーズの先取り」などをスローガンに掲げることがありますが、ほとんどの場合無駄な投資に終わる【注3】ことを見ても、変更が必要な場合に迅速に対応出来る仕組み作りは必要ですが、業務要件自体は、現在確定している内容を手堅く引き継ぐことをベースラインと考えることが正解のようです。
 ここで無理をするおかげで、何時になったら決まるか分からない業務要件を見切り発車する事態が起こります。
 では、今まで何のために、その代り映えしないシステムを何度も再構築して来たのでしょう。
 次節では、その訳を考えてみます。
 【注3】:無駄な投資
 筆者の経験では、単なる無駄で終われば幸いである。
 多くの場合、使いもしない架空のデータ項目がファイルやデータベース、ユーザインターフェース、プログラムを蝕み、テストや移行の難易度を上げ、それがプロジェクト失敗の原因となる事すら珍しくない。
 しかも、プロジェクトが外形的には成功し、何とかシステムが運用されてしまうと、そのシステムの運用期間に亘って、それら少なからぬ負荷が係るので、保守の生産性を大きく下げる事になる。
 

 5.システム再構築の必要性

 ビジネスシステムをリリースして3年も経つと、そろそろ次期システムの再構築の検討を始めて・・・などという話が出てきます。
 システムは「一定期間保守していると劣化するので、再構築する必要がある」などと言う言い方をすることがありますが、劣化が意味しているのは、保守性の低下です。
 システムの保守作業に対して「時間をかけても整合性を損なわないよう十分注意すること」が要求されることはまずありません。
 ほとんどの場合「とにかく急いで対応する」ことしか求められないので、開発者の判断で、中間ファイルやローカルマスターの設定が許される環境では、それらのデータが急増します。
 データは、物では無いので、いくら使っても減ったり無くなったりすることはありません。
 そのため、本来一つ有れば良い(因みに、それをデータベースと言います)のですが、日常的に更新が存在するシステムでは、自分の希望するタイミングのデータを保持するための常套手段として、今、保守しているサブシステムやファンクション、タスクなど、担当している保守単位へのデータ取り込みが起こります。
 同じデータが二つあると、システムを保守するためには、その関係を調べなければなりません。
 その関係がデータの複写であれば、今回の保守内容を複写先にも適用する必要性を判断しなければなりません。
 データの型・桁の変更は反映するし、処理タイミングの変更は、欲しい値が処理前か後かで切り分け、導出ルールの変更の場合、再計算処理を行っているなら、導出ルールの変更が必要となりますが、値を複写しているだけなら対応の必要はありません。
 適格な状況判断と対応の切り分けが求められるので、保守作業は、新規開発に比べて地味な評価の割には随分と気を使う作業です。
 データが三つあると関係は三つ、四つあると関係は六つ、五つに増えると関係は十です。
 もちろん、すべての関係でデータの遣り取りが行われている訳ではありませんが、関係「無い」と判断する為には結局全ての関連性を評価しなければならないので、調査の負荷は等比級数的に増えて行きます。
 気を使わなければならない作業が、この調子で増えたのではたまりません。
 たちまち保守作業自体より、調査や調整の工数がはるかに多くなり、保守性は見る間に低下【注4】していきます。
 そこで、起死回生の秘策として打たれるのが、システム再構築ということなので、データの継続的一元管理の機構を持たないビジネスシステムでは、この「システム再構築」と言う奴は、宿命的な作業であると言うことが出来るでしょう。
 ビジネス自体には大きな変化が無いにも関わらず、それを支援するビジネスシステムだけが、短いサイクルで再構築しなければならないというのは、良く考えてみればおかしな話です。
 最近は景気が悪いので本格的なIT投資は先送りだとばかりに、補助的なサーバーシステムを付加する形式での機能拡張や、メールや電子化された文書情報などの非構造化データの対応に終始しているところを見ると、基幹ビジネスシステムの再構築は、先延ばししようと思えば、何とか出来るものなのかという気もしてきます。
 しかし、それは生産性の低下が可視化出来ていないための錯覚で、基幹システムでの生産性低下は、着実に進行して行き、メール・メモ・営業日報など、非構造化データ処理のクランド化やビッグデータなどとはしゃいでいる間にも、保守担当者は必要最小限の保守案件対応ですら徹夜や休日出勤が続いてしまいます。
 どの程度、保守の生産性が低下するかと言うことが、きちんと把握できている企業は少ないと思いますが、私の手元にある貴重な実績資料では、4年間でシステム規模が40%増加するシステムで、保守工数を1800人月/年から3400人月/年に増やしても、工数当たりの作業量が低下したために全体の作業量が減っていく状況が確認されています。
 この事例では、保守の生産性は4年で1/2に低下している見当です。
 生産性低下のペースが同じだとしても、8年経つと1/4、12年経つと1/8に低下するのでは、最低限の保守要件に対応することすら難しくなって来ます。
 おまけに、システム自体が複雑になって行くので、生産性低下のペースは早くなる上、出なくても良い障害まで発生し、更に作業の生産性を低下させます。
 基幹業務システムの再構築は、先に延ばせば延ばすほど、保守の生産性が低下するという仕掛けなので、実績を把握し、再構築着手のクリティカルポイントをコントロールする必要があるという訳です。
 しかし、システムの大規模化・業務に疎い委託先・現行業務精通者の退職などのために、再構築でデータの整合性を完全に回復することが出来ないケースも頻発しており「じゃあ、再構築すれば良いんだろう」と言う開き直りすら通用しなくなると言う辛い現実がありますが、このコラムには直接関係ないので、その説明は別の機会に譲るとし、ここでは、現在、一般的に行われているシステム開発の方法では、定期的なシステム再構築が、構造的に避けられないものなのだと言う結論で次に進みましょう。
 【注4】:保守性は見る間に低下
 保守作業の特徴として、要件の集中があります。
 例えば、総ステップ数の1割が変更されたと言う場合、均等に変更が入る訳ではありません。
 多くの場合、業務的に最も注目されているホットな箇所が、集中的に変更されることになり、いわゆるシステムの劣化と言う奴が急激に進んでしまいます。
 また、保守性の低下を数値で可視化して把握していない企業では、その現象の原因を、システム部門の能力低下だと思い込んでいる節があります。
 思い込みのまま「当社はITの会社ではない」とばかりにシステム部門を切り捨て、アウトソーシングやベンダー依存に傾く企業がありますが、システム部門が弱体化すれば、要件の取捨選択や社内調整、アウトソーサーやベンダーとのコミュニケーションなどに支障を来たし、時間経過と共に着実に押し寄せる保守性低下の前で動きが取れなくなってしまいます。
 最も顕著な現象は「何時まで経ってもプロジェクトが終わらない」です。
 何年もプロジェクトやってる貴方、まあ普通2回も延伸したら気が付くでしょ。
 この単元の内容を良く読み返して、そろそろ真の原因を明らかにしないと会社が持ちませんよ。

 6.データに関する情報整理

1.データ構造
 ここで言うデータ構造とは、ビジネスの中の存在や発生する行為・出来事およびそれらの間の関連を整理し、データモデルで表現したビジネスのモデルです。
 ビジネスのモデルなので、システムの作りや機能に関わらず、ビジネス自体が変わらない限り変化しません。
 ビジネス自体の変化とは、ビジネスを構成する要素の増加や要素間での新しい関係の発生、及びビジネス要素から新しく収集するデータ項目の増加などです。(普通は商売の拡大に伴って、増加する一方ですが、もちろん縮小・減少する場合もあります)
 例えば、拡大する支店網を、本社一括で管理するのが難しくなって来たので、地区毎の特性を配慮した営業施策を打つ上で、新しい管理階層として地区本部を設ける場合は、地区と言う新しい概念の増加になります。
 また、販売代理店へのインセンティブとして、売上高に応じたリベートを新たに設定する場合は、支払いと言うイベント系のビジネス要素に、新たに月別リベート金額と言うデータ項目が追加されると言う具合です。
 しかし、それらは、ビジネス要素やデータの総量から見れば、微々たる数【注1】なのでビジネスのモデル自体に与える影響は知れています。
 そのため、一般的に現行システムを分析したデータ構造は、新しいシステムでもそのまま通用可能です。
 ということは、データ構造の整理という作業に限っては、ビジネスの内容さえ明らかであれば、システム開発のタイミングを待つまでも無く、任意のタイミングで着手可能だということになります。
-------------------------------------------------------------------------------
 【注1】:微々たる数
 一般的に集計項目や対前年同月比などの比率や係数など、主に管理業務やマーケティングの用に供するために新たな導出式によって作られるデータ項目は多数存在しますが、それらは、データ構造の対象外なので、急激に増加したとしてもデータ構造の形に影響することはありません。
--------------------------------------------------------------------------------
 実際問題として、新しく習得した技術・技法・ツールなどを業務で効果的に活用するためには、十分な訓練を行った上で、OJTなどで経験を積むことで習熟し、自信を付ける必要がありますが、データ中心指向の中核技術であるデータ分析やデータモデリングは、先行着手することで、開発の本番までに十分習熟しておくことが出来るという強みがあります。
 しかも、トレーニングの対象として使う現行システムの分析結果は、基本的にそのまま新システムに引き継げるので、訓練のための訓練とは違い、緊張感のあるトレーニングが無駄なく行えるという訳です。
 なお、システム開発は当然ながら最終的にシステムの実装を行うため、データ構造の形成には関係しないデータ項目も管理しておく必要があるので、リポジトリ(などの管理機能で)で名称、導出ルール、型、桁、存在単位などを管理しておくことになります。

2.ユーザインターフェース
 ユーザインターフェースは、入力と出力でその仕様の決定ロジックが全く異なります。
・入力ユーザインターフェース
 入力ユーザインターフェースが扱わなければならないデータ項目は、データ構造から自明です。
 例えば、受注エンティティがあれば、受注と言うイベントが発生した場合には、受注エンティティの識別子に設定されている受注番号を採番した上で、属性として設定されているデータ項目を入力させつつ、関連が設定されているエンティティについては、関連元の識別子が入力された段階で、対応インスタンスの有無を確認し、導出項目の導出を行い、検証結果が良ければデータベースに登録するところまで、処理する内容は決まって来ます。
 つまり、入力ユーザインターフェースに関しては、データモデルを描いた段階で、その業務要件のほとんどが決まっているので、データモデルをきちんと読めるエンジニアであれば、業務要件について、一々プログラムの仕様を文書化する必要もありません。
 残りのデザインに関しては、ユーザインターフェース設計基準、セキュリティ上の制約事項に関しては非機能要件、運用上の制限に関してはワークフローの検討で設定することになりますが、業務要件の中心となる、ユーザインターフェースで扱うデータ項目の組み合わせについては、ER図に描かれた内容からプログラムの仕様を読取ることが可能です。
 ちなみに、世に言うCASEツール(なつかしい表現ですね)やソースジェネレータの類は、この理屈を前提にしているのでER図を描くことでプログラムソースを作ることが出来ます。(それらのツールも幾つか紹介されていますが、逆にER図が、きちんとビジネスを反映したものになっていないと、ソースジェネレータに個別にパラメータを設定するようなものなので、「これって言語のコード化と何処が違うの?」と言う事になります。 身に覚えのある方、それは使い方を間違えてますよ。)
・出力ユーザインターフェース
 それに引き替え、出力ユーザインターフェースは、定まった形がありません。
 何を見たいか、どんなデータが必要かというのは、そのユーザインターフェースによって、どのようなアクションを誘発しようとしているかによって様々に変わって来ます。
 同じ受注データを見ても、目的が受注した商品の配送であれば、商品の種類や個数と取引先の所在などが中心になりますが、来月の仕入れを計画するための傾向分析では、必要とする項目も見方も変わります。
 入力側のユーザインターフェースが、システム開発プロジェクトの早い段階で明らかになるのとは逆に、ビジネスの仕様の細かい変化やワークフローの組み立て方に影響されるので、出力ユーザオンターフェースは常に変化します。
 そのため、全てのユーザインターフェースが確定してから次の段階(多くの場合、その次の段階と言う所にデータベース設計を位置付けると言うミスを、犯している開発プロジェクトが多くあって困ってしまいますが)の設計に入ろうという段取りで作業を進めていると「なかなか要件が決まらない」ということになってしまいます。 

 7.システム開発要素の関係

 プロセス構造・ワークフロー・データ構造・ユーザインターフェースは、相互に関係があります。
 簡単に言うと、概念的で抽象的なシステムから、プロセスをサブシステム・ファンクション・アクティビティ・タスクと細分化して、階層構造を整理していくと、具体的な設計対象となるワークフロー・ユーザインターフェース・プログラムなどが順次明らかになっていき、ワークフローは、ユーザインターフェースで構成され、ユーザインターフェースはデータ構造で定義されたデータ項目で構成されるという関係です。
 ちなみに、それぞれの情報を具体的に整理し表現した文書情報の一般的な名称を表で説明しておきます。
 情報カテゴリ  文書名 備考 
 プロセスモデル  ・業務構造図
・業務機能一覧
・表現はDFD・DMM・BPMNなど多様
・階層別の業務機能の説明や定義 
 ワークフロー  ・システム概念図
・事務処理手順
・機能別U/I一覧
・表現は業務フローや表など多様
・文章による補足説明
・ワークフロー別の利用U/I
 データモデル ・データモデル
・データ項目一覧
・データ項目定義
・ERD+リポジトリなど
・データ項目の名称一覧
・導出ルールや形式など
 ユーザインターフェース ・U/I一覧
・画面変遷
・U/I定義
・U/I別データ項目一覧
・U/Iの名称と概要
・論理的画面と物理的構成
・U/Iの目的・機能・操作など
・U/I別関連データ項目
 実際のシステム開発プロジェクトでは、実に多様なドキュメントを作成します。
 (見ていると、何の目的で作っているのか理解していないのではないかと、心配になってしまう事がありますが、幾ら手順書やマニュアルに作れと書いてあっても、必要無いものは作らなくても良いので、要不用はきちんとプロジェクト毎に判断して行かないと、無駄な作業をする事になりますよ。)
 プロジェクトの運営自体のために作成するドキュメントも多いので、何をやっているのか訳が分からなくなる事もありますが、最終的に整理しなければならない目的情報はこの程度のものなので、分析・整理の中間生成物とは分けて生産性や進捗の指標とすることも可能です。
 なお、データ構造の情報は、データベースに、データ構造とユーザインターフェースの関連情報は、プログラム仕様に、また、ワークフローの情報は事務取扱手続きのマニュアルや運用設計の基礎資料となり、実装作業へと継承されて行きます。
 最終的には、これら4種の情報を全て整理することになりますが、その順序については、何れから着手するのが最も適切であるかについては議論が分かれる所でしょう。
 引き続きシステム開発の手順について考えて見ましょう。 

 8.システム開発の手順

 さて、システム開発のために整理しなければならない情報を4つのカテゴリに整理しましたが、一般的には、作業をプロセス側の情報整理から始めるケースが多いようです。
 プロセスを細分化する中で、ワークフローを特定し、その手順を具体化する中でユーザインターフェースを明らかにし、ユーザーインターフェースを設計する中でデータ項目を設定すると言う手順です。
 この手順でシステム開発を進める場合は、ワークフローまでを業務設計工程で具体化し、ユーザインターフェースやデータ項目の具体的な設計や定義はシステム開発工程で対応することが多いようです。
 しかし、システム開発に当たっては、唯一、利用者との接点になるユーザインターフェースや、合理化省力化の焦点となるワークフローには、工夫や要求が集中するので要件がなかなか安定しません。
 これに対して、データ側の情報から整理すると、現行システムの分析から、データモデルを描き、エンティティを特定することで、エンティティごとの入力ユーザインターフェースとそれら登録作業に関するワークフローは、容易に明らかとなる上、滅多なことでは変わりません。
 その上、入力ユーザインターフェースと入力作業のワークフローを特定するまでの作業には、新たな要求や作業上の工夫が入り込む余地は少ないので、停滞や手戻りがありません。
 また、データモデルを描くためのデータソースは現行システムから収集するので、現行システムでの実装情報を関連付けることで、データ移行の裏付けのあるデータモデルを作る事も可能です。
 これらの仕組みを上手く組み合わせると最も合理的な手順が見えて来ます。
No,  作業名  作業概要 備考 
 1  データ分析  現行システムのユーザインターフェースからボトムアップ分析で概念データモデルを描くと同時に、現行システムの実装情報からデータ項目ごとに移行元を特定する  データ管理者の育成とデータ管理体制の整備運用
 2  データベース設計  運用要件を反映してデータベースの物理設計を行います  モデルベースのDB管理体制整備
 3  移行設計  現行システムと新規データベースの関連から初期移行と並行運用のデータ変換仕様を決定し開発  データ変換ロジックは共用
 4  データ移行  データベースを設定し、現行データを新システムに移行  
 5  入力U/I設計開発  新システムの入力ユーザインターフェースを設計、プログラム仕様を確定して開発  
 6  入力ワークフロー設計  ユーザインターフェースとセキュリティや運用管理要領を反映し、入力ワークフロを設計  
 7  並行運用  現行システムからの同期制御システムと新システムの入力システム並行運用  同期制御データで入力データ作成
 8  情報系入力切替  情報系システム・DWHなどマーケティングや戦略・計画系など、データに神経質な同期やタイミングが要求されないものに対するファクトデータの供給を同期制御中のデータベースに切換える  連携・変化システム
 9  出力検索プロセス設計開発  一連の出力検索処理単位でユーザインターフェースを設計・開発し、並行運用データベースを使って試験
 情報系・DWHなどの入力
 
 10  本番運用  新システムの出力利用、入力システム切り替えなどを組み合わせて数段階の移行手順を設計し、段階的に移行  
 この手順は、安定して変化の少ないところから開発実装し、並行運用しながら可能なところから順次本番運用に移行するものです。
 個別のユーザインターフェースの開発に当たっては、並行運用データベースをそのまま試験環境として使うことで、完成度が向上し障害の発生を抑制します。
 また、変化や希望の多いユーザインターフェースについては、プロトタイプ(そのまま本番に使うつもりで作るのでプロトタイプと言うよりはRADと表現する方が良いかも知れません)での合意形成が出来るので、利用者の満足度向上も期待できます。
 さらに、出力検索系のシステムに於いても、完成したユーザインターフェースから順に業務利用することが出来るので、システムの投資効果の面で、ターンアラウンドを短縮することも可能です。
 組織的にも、一度にまとめて行う開発量は抑制出来るので、信頼できる開発部隊への順次発注が可能で、プロジェクトの所帯が小さくなる分、運営は容易なので、管理のための作業負担も大幅軽減が期待出来ます。
 以前は、並行運用を前提にすることは設備・機器の手当を始め負担が大きく、移行設計の俎上に上ることも有りませんでしたが、機器が安価で小さくなった上に、クラウドなど一時的なニーズを満たすには都合の良い手段も充実して来たので、システム開発環境と合わせて並行運用の環境を調達することも十分可能です。
 第一、ここまでシステムの運用に社会的責任が伴って来た現在、一か八かの一括移行など無謀以外の何物でもありません。
 プロジェクトから一括移行案が提示されたならば、経営者は直ちに、そのプロジェクトリーダーを更迭しなければならないでしょう。

 9.データ中心システム開発

 従来の、プロセスからワークフロー、ユーザインターフェース、データ項目と情報を整理していく手順では、データ項目に関する情報整理が後回しにされてしまいます。
 プログラムに従属したデータをプログラムが使いやすいようにローカルマスターや中間ファイルに作り込んでいた時代はそれで良かったでしょうが、少なくとも、データは一元管理して全体で共用しようというデータベースを使うとなると、先ず、データに関する情報整理から着手し、データ管理者がプロジェクトの全局面を通じて、作業をリードしていかなければなりません。
 そのためには、最初にデータ分析に着手し、ビジネスのデータ構造を把握する必要があります。
 従来の開発アプローチでは、プロセスの細分化すら十分でない段階で、データ項目の情報を整理出来る訳が無いと言うことになってしまいます。
 しかし、データモデルをビジネスのモデルと位置づけると、ビジネスの構成要素は安定しており、現行システムから次期システムへと再構築されたとしても、それ自体には何ら影響は無いので、現行システムのデータモデルを描けば良いと言うことが分かれば、前節のようなプロジェクト展開が見えて来ます。
 データ中心と言うからには、データの把握・データの設計・データの実装が他に先行して確立されなければならないでしょう。
 これまで、データ構造からシステムやプログラムの仕様を導くデータ中心指向の特長が、上手く生かせなかったのは、データ中心指向技術が、業務分析者やデータベース設計者など専門家の専有物と見られていたことに原因があります。
 もちろんデータ管理者のスキル向上を進めることも必要ですが、データ管理者を孤立させたのでは、せっかくのデータ中心技術も宝の持ち腐れです。
 データ管理者のスキルアップに並行して、関係者へのデータ中心指向の普及、つまり、データ中心と言う考え方への周囲の理解を得ることで、データ中心技術を生かしたシステム開発、データ中心技術を生かしたプロジェクト運営が実現すれば、データ中心アプローチのねらいである情報システムの保守性維持や長寿命化が実現することでしょう。 
 孫子に、「勝兵は先ず勝ちてしかる後に戦いを求め、敗兵は先ず戦いてしかる後に勝を求む」とあります。
 とにかくなるべく早い段階でプログラム開発に着手して、プログラムを具体化することで何とかそれを組み合わせてシステムの完成に持って行きたいと言う漠然とした期待で、プロジェクトを進めていませんか。
 その進め方は、偶然の勝利を頼む敗兵のやり方ですよ。
 先ず勝とうと思ったら、データ中心指向のアプローチしか無いでしょう。

ページトップへ