PR

 そもそも当社は提供するあらゆるサービスで自前主義を貫いていた。その影響もあったのか、情報システムも自前で開発するのが当たり前といった空気になっており、自社開発はあっさりと認められることになる。

 実は私自身が仕向けた面もあった。一人の技術者として、Web版の座席予約システムを自前で開発してみたくて仕方なかったのだ。今思えば、この頃が技術者として一番脂がのっていた時期だったのかもしれない。基幹系システムの再構築と機能拡充をなんとかやってのけ、「次はWebで開発してみよう」と意気込んでいた。

 「やってみたい」という理由で行動するのは社員として褒められたことではなかったかもしれない。自分がやりたいかどうかではなく、システムが会社に貢献できるかどうか、そのために自前開発がよいのかどうか、それを本来考えなければいけない。

 ユーザー企業に移り、システムの「根本的な方向を選ぶ機会が増えた」私にとって、そんなことは百も承知であったのだが、このときばかりはとにかく走り出したくて仕方がなかった。

データ中心設計とオブジェクト指向開発の“いいとこ取り”

 早速、企画書を作成した。私の熱意が伝わる内容になんとか仕上げることができた。企画書を持って役員のところを回り、概要を説明した。誰からも反対意見は出なかった。役員会の承認を経て自前で開発する方向で社内がまとまった。

 具体的にどう進めるか。開発方針を決める必要があった。当時は現在のようにWeb開発の選択肢が多かった訳ではない。限られた選択肢の中で私たちにとって最適な道を模索した。

 Web開発ということもあってオブジェクト指向開発を初めて取り入れようと考えた。一方で私としてはそれまで取り組んできたDOA(データ中心設計)を捨てたくなかった。

 業務システムとDOAの親和性は高いと確信していたし、システムの保守性が高くなるメリットは捨てがたい。DOAの結果をリポジトリに残しておくことでシステムの変更時にどのデータに影響がどう及ぶかを容易に把握できるからである。

 どうすべきか。結論はDOAとオブジェクト指向開発の“いいとこ取り”だった。

 DOAを支援するツールであるXupperの勉強会で知り合ったITベンダーが解決策を持っていた。それはDOAによる業務分析結果を、UMLによるアプリケーション設計にどう生かせばよいかを体系立ててまとめた方法論だった。

 この方法論をWeb版の座席予約システムの開発に適用することにした。開発のパートナーとして、方法論を提供してくれたITベンダーを選んだ。

 業務分析は私とITベンダーが組んで進めた。開発については、新たに作る部分をITベンダーに頼み、新システムと基幹系システムを連携させる部分を自社、つまり私とシステム部門のメンバーが受け持つことにした。

 一連の設計と開発で、情報の受け渡しにXupperを使った。疑似的ではあるが我々とベンダーでリポジトリを共有する形をとれた。例えば、RFP(提案依頼書)はXupperを使って記述した業務フローの形でベンダーに渡した。