その分散システムは、正しく作られているか？――開発後の検証・受け入れを考えよう：戦う現場に贈る分散システム構築−情報部門編（6）（2/2 ページ）

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

検収作業時の適格性確認テスト

　これと合わせ、開発後の検収作業、及びその中で実施するテストの難しさがある。本時点からすれば相当先の話ではあるが、（意外と思われるかもしれないが）要件定義がこの適格性確認テストの鍵となる。なぜならば、適格性（どう動けば正しいと看做されるのか）というのは、その要件次第だからだ。

　つまり、適格性確認を行うにしても、何をチェックすべきかは要件定義時にすでに決まっていて当然である、ということになる。冒頭で蔵田がいいたかったのは、ここだ。発注するための受け入れ作業まで視野に入れた作業が必要となると、経験則的に警告していた訳である。

　豆成くんは、発注するための作業という目前の作業だけに気を取られすぎて、その後まで見据えた段取りや作業を行っていなかったのだ。

図2　適格性を満たすか否かは、要件定義で定まる

　要件定義は大まかに分けて機能要件（実現している各機能に関する事項）と非機能要件（各機能に直接関係なく、純粋に動作するための仕組み）に分けられる。検品時にはこの両者をチェックする必要がある。どちらが欠けていても、本来期待していた動作とは異なる残念な結果を招きかねない。

　しかも、分散システムの場合はこれが複数存在する。当初の設計どおりの動作が行われなければ、複数の業者から納品されたあと、組み合わせた際に正常動作しない事態が想定できる。設計の正確さも当然重要ながら、その後の確認作業についても重要度は高いのだ。

「こんなものだ」とあきらめるべからず

　また、豆成くんの一種あきらめにも似た、納品時のもめごとに対しての姿勢もあまり褒められたものではない。失敗することを前提に達観してしまうと、そのために支払われる犠牲（つまり追加コスト）が積み上がる。これでは、もともとのお題であったコスト削減に真っ向から逆らう結果にもつながる。

　「コスト削減のために企業内で聖域なき改革が行われ始めた」――これは本連載の前提であり、開始当初からの一貫したテーマである。従来、暗黙の文脈で語られてきた「開発作業なんてこんなもんだよ」というような、最初から改善努力を放棄するかのような言動は、巡り巡って自分自身や自らの組織、自らのプロジェクトの首を絞めかねない。

　慣れとは恐ろしいもので、何度かの開発作業を繰り返してきた熟練者であればあるほど、変に達観して現状に甘んじることがある。これがよい意味での力の抜き方具合であれば問題ないだろうが、プロジェクトチーム全体に影響を及ぼすような、プロジェクトを推進する立場ともなれば別である。やはり数々の改善を積み重て、この重いテーマに立ち向かう必要があるだろう。

---

　さて蔵田からの指摘で問題に気付き、来たるべき納品時のチェック項目を整理していた豆成くんのところに、蔵田が息を切らしながら飛び込んできた。

　「おい豆成、大変なことになったぞ。社長がその気になって情報システム子会社を設立することになったみたいだ！」

　「えっ、子会社？ 情報システムの？ われわれはどうなるんですか？」

　「噂ではキーパーソンが数人出向して、今回のプロジェクトの開発作業を請け負う形になるようだ。その筆頭に豆成、おまえの名前が挙がってるようなんだ……」

　豆成くんは絶句した。まさか自分が発注する作業を、自分で実行する羽目になろうとは！ ますます逃げられなくなった自分の立場を改めて思い知らされた。今後起こるであろう、泥沼の開発作業、深夜に及ぶテスト、納品時の叱責、無限に続くかのような保守作業――。それらを考えただけでも気が遠くなる思いがした。しかし、同時にそれだけ自分が評価され、期待されている裏返しとも思え、胸の熱くなる思いが沸いてきた。

　豆成くんの苦闘は続く。

筆者プロフィール

岩崎 浩文（いわさき ひろふみ）

株式会社豆蔵 BS事業部。ITコンサルティング会社にて商用フレームワーク設計・構築およびITアーキテクトとして多数の企業システム設計・構築に携わる。その後、サーバ製品ベンダにてSOAコンサルタントを担当したのち、2005年より現職。現在、方法論「enThology」（エンソロジー）の策定とSOA型システム設計支援の主任担当として多くの現場へ支援を行っている。

株式会社豆蔵

「戦う現場に贈る分散システム構築」バックナンバー

• 既存システムという制約とアーキテクチャ――どうつなぎ、うまく再利用するか
• システムアーキテクチャとSOA製品選定――分散するシステムをつなぐ製品について
• 悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために
• これから始めるサービス指向型設計――単独システムとは違う世界へようこそ
• その分散システムは、正しく作られているか？――開発後の検証・受け入れを考えよう
• ここが核心！ 各サービスの抽出とサービス統合――SOAサービスの切り出し方とその統合方法
• 理想像と現実のフィット＆ギャップを知る――業務分析の成果をシステム統合に活かす
• システム統合になぜ業務分析が必要なのか？――作業の理由とITガバナンス
• システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について
• 緊急課題！ 点在する複数のシステムを統合連携せよ――問題山積！ 乱立する情報システムの解法とは？