基幹システムはエッシャーの「滝」のように作れ：IT Oasis（2/2 ページ）

後戻りできない状態になってから初めてテスト画面を見せられても、エンドユーザーは満足のいくＩＴ活用ができない。外部設計段階では必要に応じてプロトタイプ画面を確認できる作り方が適している。

[齋藤順一，ITmedia]

エンドユーザーが知りたいこと

　技術計算や会計処理などでは情報そのものを扱うので情報処理も複雑になる。こうした業務におけるＩＴ導入ではウォーターフォール・モデルは適している。

　これに対して基幹業務では財の提供や価値の創造が主要業務となる。課業や工程で業務遂行とともに情報が増加、蓄積、利用される。

　生産現場やサービス現場での情報の流れを考えてみると、どこかの工程で後工程あるいは後日使用するデータを入力し、記憶装置に蓄積し、そのデータを主に意思決定のために必要とする工程で読み出し、必要に応じて加工して活用するということの繰り返しである。

　画面などからのデータ入力、入力データのデータベースへの書き込み、データベースから条件を付けて読み出し、画面表示または帳票出力ということの繰り返しである。

システムを業務に中で運用するエンドユーザーが知りたいのは、データ入力をどのように行うのか（これには誤入力対策などが含まれる）、ということと、必要なデータをどのように見せてくれるのかということだけである。データベースのテーブル構成などはユーザーの興味の範囲外である。十分に迅速なレスポンスが得られて、堅牢であれば十分なのである。

プロトタイプで確認していく

　ＲＦＰで要求事項が明確になっていれば、要件定義はＲＦＰの確認をベースに比較的短時間でまとめることが可能である。要するに要件定義はベンダーがプロジェクト案件を理解する場となる。

　その後の外部設計においては、完成イメージが確認できる実際の入出力画面あるいはそれを模した紙資料や帳票を使って、ユーザーが動作状況や取得情報の確認をしていった方が能率的である。つまりその都度プロトタイプを作成し確認していくわけである。こうすれば、後々ユーザーからテスト段階で、意志疎通の食い違いによるクレームが出る可能性も少ない。

　つまり、見えないＩＴはできる限り早い段階で目に見えるような形にしてあげることが、後々、ユーザーとのあつれきを生まない秘訣ということである。

　ウォーターフォール・モデルはFortranやCOBOL時代の手法であり、パッケージでのシステム提供やWebインタフェースが主流の今日には時代にそぐわないアプローチと言えるのではないだろうか。

　千葉県の鋸山（のこぎりやま）は江戸時代から採石が盛んに行われたところで、山腹に刻まれた石造は日本一の石の大仏と言われたが、自然の風蝕による著しい崩壊があり、昭和になって復元工事をしたそうである。

　石の大仏でも時とともに風化し、形をとどめなくなるのである。

　Dog Yearで進化するＩＴの世界においては頻繁に手法の見直しをする必要があるだろう。

PlanITトップはこちら

過去のニュース一覧はこちら

プロフィール

さいとう・じゅんいち　未来計画代表。NPO法人ITC横浜副理事長。ITコーディネータ、 CIO育成支援アドバイザー、上級システムアドミニストレータ、環境計量士、エネルギー管理士他。東京、横浜、川崎の産業振興財団IT支援専門家。ITコーディネータとして多数の中小企業、自治体のIT投資プロジェクトを一貫して支援。支援企業からIT経営百選、IT経営力大賞認定企業輩出。