前回に引き続き、EPM（Empirical Project Monitor）手法やVDM（Vienna Development Method）手法など、システム構築における工学的アプローチないし、ネオ・シグマの動きを追い続ける。シグマプロジェクトから以後も、SI業界ではほぼ5年おきに「ソフトウェア工学」が浮上しては忘れられた。だがここにきて、ネオ・シグマを実践して成功した企業が登場し始めている。従業員が100人に満たない小さなソフト会社が、錐もみの一点攻撃主義で取り組んだ設計手法や開発環境。それは特殊な事例ではなく、ソフトウェア工学の理に適った取り組みでもある。（佃均（ジャーナリスト）●取材／文）

工学的アプローチに成功例が

ビジョンとして掲げる

　東京・港区に、フォービスという小さなソフト会社が本社オフィスを構えている。資本金5500万円、従業員17人、売上高3億6800万円の企業だ。会社名はラテン語の「扉（FORIS）」と「世界（ORBIS）」を合成し、「世界への扉」の意味を持たせている。

　社長の家永慎太郎氏はITエンジニアとして大手SIerに勤務していたが、契約の形式は請け負いでも実態は限りなく派遣に近い人月単価型の就業体制に疑問を感じ、1995年9月、仲間と一緒にスピンオフした。目指すのはユーザー企業に提案ができ、システム構築の企画段階から開発まで一貫して受注する「本当のシステムインテグレーション」だ。

　「誰だって、たった17人やそこいらの会社ができるのかと思うでしょう。ですが、当社は独自に練り上げた手法をユーザーに訴えて、大規模システムの上流工程を受注しているんです。目指すのはフォービス流のシグマです」と家永氏は断言する。

　設立当初は「やむを得ず」派遣型だったが、インターネットの普及で需要が高まったWebベースの流通管理システムに着目した。人材を流通管理系のECサイト構築案件に集中したことでノウハウが蓄積され、それをもとにXMLベースのWebアプリケーション構築用サーバーソフトを「FORBiS DYNAMIC SERVER」の名で製品化した。

　さらにシステム構築のプロセスを分解して、プロセスごとに必要な知識と技術、技術者のスキル要素をまとめていった。並行してアプリケーションの機能、リソース、ロジックを分解し、マトリックスに体系化した。そこにパッケージを開発するなかで得た汎用化のノウハウが加わった。ソフトウェアの機能モジュールは具体的にどのように作るべきか、そのためにはどのような作業をしなければならないかをエンジアたちが理解していった。

　「少人数で効率よく仕事をこなし、最適なチーム編成を行う必要があったから」

　と説明するが、まさにシグマプロジェクトもしくはシステム構築における工学的アプローチを地で行ったことになる。

　「気がついたら、それがフォービス流の開発方法論になっていた」

　現在、同社の主なユーザーは通信販売会社やECサイトの運営会社だ。中間に大手のSIerが入ることもあるが、Webサイトのアプリケーション開発については同社が責任を持って受け持つ。その結果、

　「例えば当社の社員8人で400人月のプロジェクトを動かしている」

　という。つまり同社が上流工程とプロジェクト管理を行い、その下で多くのソフト会社が外注として実務を担う構造を作り上げている。少数精鋭の設計事務所といっていい。

チーム全員で情報を共有

　東京・世田谷区に本社を置くアトリス。正社員は約15人、常時使っている協力会社従業員を加えると70人になる。年商は10億円超なので、フォービスと比べれば規模は大きいが、業界全体では小さな存在だ。社長の安光正則氏はサン・マイクロシステムズ日本法人を経て04年に同社を設立した。

　「UNIXベースのアプリケーション開発に慣れていた。長年、構造化プログラミングが当り前の世界でやってきたので、ウォーターフォールモデルのことになるとサッパリ分かりません」

　安光氏は苦笑する。

　会社を設立して真っ先に取り組んだのは、プロジェクトにかかわる全員が共有できるリポジトリの開発だった。チームに参加しているエンジニアであれば、誰が・いつ・どのプログラムを作り、誰がどのように手を加えたかが一目瞭然に分かる。このためデスクには1人2台の割でディスプレイが並ぶ。1台は開発用、1台は情報共有用だが、2台を連携して大きな図面を見ることができる。

　「普通、システム設計は文章で表現された仕様書としてエンジニアに提示されます。ところがそれだとシステム全体の資源配置や重み付けが分からない。そこでUMLによる図式化手法で、独自の図面を作る手法を開発したのです」

　現在の情報システムは、何台ものサーバーにデータベースとアプリケーションが分散している。それぞれに運用管理者がいて、ハードウェアもソフトウェアも重複していることが少なくない。1か所のメンテナンスがどこにどのように波及するか、それを正確に把握しておかないと、全体の設計ができない。それを解決するのが独自のパターン分析手法とアプリケーション開発フレームワークだ。

　会社設立から1年ほど経った時、ふとしたことがきっかけで、あるインターネットサービス会社の経営者に開発方法論を話すことがあった。その会社は、必要に応じて次から次にサーバーやストレージを増設した結果、こんがらがった糸のようにシステムが複雑になっていた。

　「試しに図面化してくれないか」

　と依頼され、安光氏は3か月で現状分析をやってのけた。模造紙を貼りあわせた畳4枚ほどの大きさの紙に、ネットワークの線を引き、色の違うピンを立てた。サーバーは青、データベースは赤、アプリケーションは緑、保守管理要員は黄色といった具合だ。

　それはシステムの可視化が可能になったことを意味していた。UMLはユーザー（発注者）と受注者の間で要求仕様を共有化するシステム可視化手法だが、安光氏はそれを紙の上にリアルな形で具現化したのだ。システムの機能、性能、非定義要件などは、コンピュータ上に構築した階層型の独自ツールに書き込み、エンジニアは常にそれを参照してプログラムを作っていく。

　結局、同社が新システムの基本設計とプロジェクト管理を行い、大手コンピュータメーカーが実務を担うことになった。設立から22年目、協力会社のエンジニアを含めて70人の小さなソフト会社が、コンピュータメーカーに代わって上流工程を受託したのだ。

「小さいからこそ」可能に

　フォービスやアトリスのケースは、まだまだ珍しい部類に入る。ただ、規模が小さく臨機応変に動けること、大規模案件を受託する体力がないので上流工程を目指したこと、目先の売上高にとらわれず、開発環境の整備に取り組んだことなどの共通項がある。

　周到に計画された戦闘機の波状攻撃が、大艦巨砲時代の代名詞でもあった戦艦大和を東シナ海に葬ったのと同じように、ソフトウェア工学の実践は「小さいからこそ」可能なのかもしれない。