中堅メーカーで、複数システムを統合する大役に悪戦苦闘を続けてきた豆成くん。そんな豆成くんは自分が発注する作業を、自分で実行する羽目になろうとしていた!
システム開発子会社から中堅メーカーのマメックス工業(仮名)に転職した豆成くんは、入社早々点在する複数のシステムを統合される大役を押しつけられてしまった。
要件定義から方式設計までおおむね完了し、開発のためのRFPをまとめる段階まで進んだのだが、マメックス工業自身が情報システム子会社を新たに設立し、そこで請け負う後続の作業のために出向することになってしまった……。
独立した単体システムのみの開発経験で、業務知識もシステム統合技術も持たない豆成くんは、無事プロジェクトを成功させることができるのだろうか?
先輩社員・蔵田からもたらされたリーク情報のとおり、マメックス工業はその情報子会社としてマメックスシステム(仮名)を設立し、豆成くんはそこに出向することになった。焦った彼は上司に何度も何度も懇願して、先輩の蔵田も一緒に出向仲間としてもらうことになった。
「えへへ、蔵田さんも一緒に、ってちゃっかりお願いしちゃいました」
「おまえなぁ……」
蔵田は豆成くんのはにかんだ顔を見てあきらめ顔で答えた。「しょうがない、今日からお前と俺は運命共同体だ。失敗は許されん。しっかりやるぞ」
「はい。頑張ります!」
豆成くんは先輩を引き込んでしまったことに多少の後ろめたさを感じつつ、しかしそれに代わる方策がないこともまた事実として飲み込んだ。「で、今後の話ですが、体制や期間などなど――、どうなるんですか?」
「うむ、子会社の設立は多少前から水面下で進めていたらしいんだが、それでも設立までまだ少しだけ時間がかかるみたいだ。それまでの猶予(ゆうよ)期間中に、今後の体制ややり方をまとめておくのがよいだろうな」
蔵田はコーヒーに手を掛けながら豆成くんを向いた。「ここから先は豆成の前職経験が生きてくるんだろう? 設計・開発ならお手のものって話だよな?」
「え?」
ドキっとした豆成くんの眼が泳いだ。「いや、ぼくは確かに開発作業はやってましたけど今回と規模が違うし、何よりシステム間連携が絡む複数システムの設計実装とか、製品選定などはちょっと……」
「ううむ――」
蔵田はコーヒーを口に付けてうなった。「――実際、そうかもしれん。だが、この状況ではそのいい訳が通用するとも思えん。知ってのとおり、俺らのリソースは限られている。唯一の経験者であるお前がしっかりしてくれる以外、解決策はなさそうだぞ」
「……分かってます」
「まあ、俺はうちの業務内容はほぼ分かってるんだが、逆にシステム技術の方が分からん。お互いさまってところだ。豆成がシステム横断の仕組みを、俺が各システムの機能を担当すればいい。俺が直接参加したんだ、そんなに心配すんなよ。運命共同体っていっただろ?」
蔵田の心遣いが逆に不安を煽る。豆成くんは多難な前途に目まいを覚えた。開発プロジェクトはまだ、始まってもいないのだ……
前回まで豆成くんが行ってきた作業は、大まかには「要件定義」といってしまってよいだろう。既存システム群の継続的利用を前提として、実現すべき将来像をまとめたものである。
この要件定義は大きく、機能要件と非機能要件の二面に分類される。機能要件はシステムが実現すべき各機能、つまり各画面やバッチ処理と、そこから呼び出されるビジネスロジックとデータベース処理である。この部分は業務で行う作業そのものであるため、入社から日が浅く業務を知らない豆成くんが最も苦労した部分である。この部分は業務そのものからシステム化を導き出す必要があるため、その業務ドメインに精通した技術者が必要となる。
これに対して非機能要件は業務処理とは直接的にはあまり関係のない、システムが担保すべき品質にかかわる個所を指す。これはISO/IEC 9126-1で定められており、国内規格としてはJIS X 0129-1に詳しい。ここでは大きく6つの要素として「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」が挙げられている。この連載で豆成くんがこれまで奮闘してきた結果、この2つの要素が要件定義書に明示され、開発が可能となった段階と考えてよいだろう。
しかし、この要件定義書で明示された内容というのは、あくまで発注側が「こうしたい」「こうして欲しい」という論理的かつ(システム化するためには少し)漠然としたな要件で構成されている。それをもって即時に請負契約を締結して開発作業を行うことは一般に不可能であろう。
Copyright © ITmedia, Inc. All Rights Reserved.