悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために戦う現場に贈る分散システム構築−開発現場編(8)(1/2 ページ)

中堅メーカーの複数システムを統合するプロジェクトで開発チームの主力に祭り上げられてしまった若手技術者の豆成くん。そんな豆成くんに先輩の蔵田は“アーキテクチャ”を決めろというのだが……。

» 2009年09月28日 12時00分 公開
[岩崎浩文,豆蔵 BS事業部]

 システム開発子会社から中堅メーカーのマメックス工業(仮名)に転職した豆成くんは、入社早々点在する複数のシステムを統合する大役を押しつけられてしまった。

 統合システムの要件をまとめたRFPを作成したところで、新設のシステム子会社に出向し、そこで開発の実務まで行うことになってしまった。先輩の蔵田に業務知識を補完してもらいながら進めることになったものの、独立した単体システムのみの開発経験しかなく、業務知識もシステム統合技術も持たない豆成くんは、無事プロジェクトを成功させることができるのだろうか?

豆成くん、自問する

 開発業務は、機能要件は蔵田が、非機能要件は豆成くんが担当することに決まった。しかし、豆成くんの心中は穏やかではなく、興味と不安が入り乱れていた。

 「蔵田さん、今後どうやって進めるつもりなんですか? 業務要件はRFPの付録に書いたとおりだとは思うんですが……」

 「うむ、俺はその中身は理解しているつもりだ」

 蔵田は振り向きながら、自信たっぷりに答えた。「だが、それをこのシステムにどうやって落とすのかは、システム開発のブランクがある俺では無理だろう。その辺は豆成、よろしく頼んだぞ」

 「え!」

 嫌な予感がした豆成くんは、おそるおそる聞いてみた。「とりあえず、ぼくも手伝うとして、どうやって要件から設計まで進めますか? 決まったやり方があれば、あとは集団の力技(ちからわざ)で何とかなりそうですが……」

 「これを見てくれ」

 蔵田は古いファイルを棚から取り出して豆成くんに見せた。

 「このファイルは俺が現役のプログラマだったころ、社内標準だった手法なんだ。このころはちゃんと社内のやり方を決めてやろうという風潮があったんだが、オープン系の開発が主流になってからは有名無実化してしまってな。いまじゃ若手には教えてないんだ」

 蔵田は懐かしむようにページをめくっていった。

 「そうそう、これだ。俺たちは昔、こうやってたんだ……」

 蔵田は、そう言ってあるページの図表を指した。「このやり方の根本の考え方は変わってないと思う。豆成、これを見てどう思う?」

 豆成くんは図を恐る恐る眺めた。そこには定義された処理の流れと、そこで取り扱う情報の構造、そしてそこからプログラム構造に落ちるまでの流れが、イラスト入りのポンチ絵で分かりやすく描かれていた。

 「うーん、なるほど。これなら理解できます。要するに業務フローとかの処理がプログラムのメソッドに落ちて、情報構造がデータベースやプログラムのデータアクセスオブジェクト(DAO)などに落ちるというルールなんですね。」

 「これでまず、システムで実現しなきゃならん内容を詳細化して表にまとめてしまうんだ。まだプログラムには落ちないんだが、まあいわゆる論理的な設計図に相当する内容を作ってしまう予定でいるわけだ。コンピュータなんて、しょせん扱うデータ構造と、それをどうするか、っていうのを決めれば自ずとやるべきことは決まるもんさ」

 ここで蔵田は豆成くんの目を見て言った。「だが、具体的なシステムのアーキテクチャが決まってないと、この机上設計から先には進められん。特に今回は分散システムだしな。豆成にお願いしたいのは、そのシステムのアーキテクチャを早く決めて欲しい――ということだ。非機能要件は豆成、おまえの分野だからな。期待してるぞ」

 不安だった蔵田の進め方が分かったいま、次は豆成くん自身の今後の進め方が問われる段階に至ったようだ。豆成くんは自問した。自分が担当する領域は、一体どう進めればいいのだろうか……?

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ