理想像と現実のフィット＆ギャップを知る――業務分析の成果をシステム統合に活かす：戦う現場に贈る分散システム構築−情報部門編（4）（1/2 ページ）

業務分析の結果は、実装独立の業務モデルとして描き出される。この既存業務モデルをSOA型アーキテクチャに結び付けていく段階に大きな問題が潜んでいるのだ。

[岩崎浩文，豆蔵 BS事業部]

　SI会社からユーザー企業に転職した若手技術者の豆成くんは、入社早々に社内に点在する複数システムの統合という大役を押し付けられてしまった。

　前回は業務現場の担当課長からの厳しい追及もあったが、それを何とかかわし、やっとの思いで現状業務の割り出しが終わりつつあった。しかし、開発経験は独立した単体システムのみで、業務知識もシステム統合技術も持たない豆成くんは、無事プロジェクトを成功させることができるのだろうか？

豆成くん、猛烈に悩む

　現場から不意の突き上げを食らった豆成くんだったが、問題となった既存業務の分析作業も紆余（うよ）曲折はありながら、何とか収束しつつあった。ここで豆成くんの心配は、既存（as-is）の業務分析の後の話――、つまり将来像（to-be）の設計に移っていた。

　通常の単体アプリケーションであれば、ここでプロトタイプを作って擦り合わせを行いながら、開発になだれ込んでいくスタイルが一般的だ。豆成くんもそうした単体アプリケーション開発に関しては前職で十分経験を積んでいる。

　しかし、現実はそう甘くはない。豆成くんの眼前には、既存システムの山々がそびえ立っているのだ。それらは、豆成くんが見たことも聞いたこともないような、多種多様な“レガシー”だった。豆成くんは既存システムの調査を進めるうちに、膨大なレガシー群が業務分析結果とはまったく異なることを知り、猛烈な不安に襲われるようになった。

　すでに大きな労力を掛けて、業務分析も行っている。ここまで来て、広げた風呂敷を折り畳むことができるのだろうか？ 豆成くんの心は不安に揺れていた。

　先輩の蔵田がそんな豆成くんの狼狽（ろうばい）ぶりを察してか、帰宅時にちょっと一杯、と誘ってくれた。

　「業務分析はおかげさまで順調に進んでます。ただ、その後をどうすればいいのか……」と、豆成くんは蔵田にお酌しながら打ち明けた。

　「おいおい――」

　蔵田は、豆成くんがここまで悩んでいるとは想定していなかった。

　「業務分析が必要だからって言うから、お付きのベンダをお役御免にしたんじゃないか！ 君がしっかりしてくれなきゃ困るよ」

　「でもボクも困ってるんです。本当に困ってるんです」

　豆成くんは泣きそうになりながら蔵田に訴えた。

　「業務内容はほぼ整理がつきました。でもその後の将来像や方式設計にどうやって効率的に結び付けたらいいのか……、正直見当が付きません。」

　「うーん……」とやや険しい表情をして、蔵田は豆成くんに問い掛けた。

　「君がここにいるのは、どうしてだい？」

　返答に窮する豆成くんの目を見据えて、蔵田は続けた。

　「君が技術者だから、だろ。技術力を見込まれて社員として入社した。それでいま君は、ここにいるんじゃないか？」

　おれができるのはここまでだよ、とでもいうように蔵田は目をそらし、そして言った。

　「プロとして頑張ってもらうしかない」

　豆成くんの脳裏には“失敗”の2文字が浮かび、冷たい汗が次から次へと流れ出すのが分かった。《最大のピンチ》という言葉は、この時のためにあるのだろうか。豆成くんには、返す言葉がなかった。

　「とはいえ――」

　蔵田は辛抱強く続けた。

　「――おれらは運命共同体であることは間違いない。豆成に全部押し付るわけにもいかないし、な。及ばずながら、おれも明日からそっちに直接参画できるよう、部長と交渉してみるさ」

　蔵田は硬直した豆成くんの背中をポンとたたいて、酒を飲み干した。

業務分析を活用する方法は

　さて、物語では豆成くんが最大のピンチを迎えているが、筆者の経験でもここでプロジェクトが詰まるケースが後を絶たない、というのが正直な印象である。

　大規模なシステム開発においては、ここで登場した「業務分析」をきちんと行うケースが多い。無論、これは間違った方法ではなく、当然行われるべき作業であることはいうまでもない。ただ、その結果をどう実装につなげるのか、そこまで考えが及ばないことが少なくないのだ。

　これが分散システムともなれば、分析した結果をSOA型アーキテクチャに結び付けていくのか、世の中に定式化された手法が存在しないといっても過言ではないだろう。要するに、どうやって業務と既存システムからSOA流の「サービス」を抽出する（切り出す）のか。そこがぽっかり抜けているのである。

　この連載で何度も話題にした、合目的性やトレーサビリティ（追跡可能性）という観点は、分散型システムを構築するうえでは必須の考え方である。つまり、完成したシステムの理由をさかのぼれば、必ず業務要件につながっている必要がある、ということだ。

　となれば、この分析結果を基に合理的に将来像（to-be）の導出や方式設計（Architecture Design）を行わなければ、何のために業務分析をやったのか分からなくなる。役に立たないのなら、最初からコストと時間を割いてやるべきではない。前回で大江課長が指摘したのは、このことだった。問題はここである。