BIGLOBEでは,現場で培った方法で独自のソフトウエア・ファクトリーを実現している。その特徴は,プロダクト(開発するシステム)中心であること,プロダクト・アーキテクチャを標準化していること,ビジネス・ルールを標準化しアプリケーション実装のギャップを少なくしていること,プロダクト・アーキテクチャを前提としたプロセス標準を作っていること,文章でなく図表を中心に設計図を作成していること,適切な分業体制と専任体制を採っていることなどである。

 BIGLOBEは,インターネットのサービス・プロバイダである。サービス・プロバイダ業は,ソフトウエアを作って完了ではない。サービスとしてソフトウエアの機能をユーザーに届け,日々維持運営するまでがワンセットとなっている必要がある。その観点で取り組んでいるファクトリー化について説明する。

 BIGLOBEのソフトウエア・ファクトリーは,従来のシステム開発がなぜうまくいかないのかを,自動車や家の設計製造と何が違うのかという視点から考えるところから出発した。足りない部分やできていない部分をどう実現するかということを考えながら,試行錯誤と現場での成功体験を積み上げながら,徐々に強化と拡大を進めてきた。

 BIGLOBEで開発現場のファクトリー化を進めようというきっかけになったのは,従来型ソフトウエア開発に対する疑問である。ファクトリー化する前に感じていた,八つの疑問を説明する。

【疑問1】なぜこんなに改造に時間とお金がかかるのだろう?
【疑問2】なぜ見積もり工数の妥当性を判断できないのだろう?
【疑問3】なぜスーパーSEがいないと大規模システムはできないのだろう?
【疑問4】なぜ“ソフトウエア業界”と呼ぶのだろう?
【疑問5】なぜ技術やノウハウが蓄積しないのだろう?
【疑問6】なぜコンポーネントの粒度がまちまちなのだろう?
【疑問7】なぜ仕様が文章で書かれているのだろう?
【疑問8】プログラミングが本当に必要なのだろうか?

【疑問1】なぜこんなに改造に時間とお金がかかるのだろう?

 最初の疑問は「なぜこんなに改造に時間とお金がかかるのだろう?」ということである。ソフトウエアの図面や仕様書は,開発するプログラマにしか分からない。しかも,お金がかかる理由を聞いても「チェックするデータ項目が分散している」「モジュールがばらばらに配置されている」といった,開発したプログラマの都合でそうなった処理ロジックの話ばかりが出てくる。設計者としてのポリシーも,開発会社としてのノウハウも全く無いという状況だった。

 しかも,仕様変更時の見積もりには問題があると感じることが多い。「新規入会申し込みを登録するときのチェック仕様を変更する」といった簡単なケースであっても,2カ月かかるといった見積もりが平気で出てくるのである。2カ月かかる理由を聞いても,プログラマが語るのは自由に作った処理のロジックの話ばかりで,そこにシステムの構造やコンポーネントの話は全くなかった。家に例えるなら,どう釘を打ったか,どこをどう削ったかといった説明ばかりして,この家の形がどうなっているのかを説明してくれてないのと同じだなと感じることが多かった。

 筆者は今,BIGLOBEのシステムを統括する立場にある。だが,もともとはネットワーク・サービス関係の仕事をしていたため,プロトコル・スタックのレイヤー・モデルやノード間のプロトコルに慣れている。システム全体を図面でブロック図的に描いたり,アーキテクチャやインタフェース仕様を検討,設計したりするというのは普通だと思っていた。

 BIGLOBEが開発するシステムは大規模なので,一戸建てというより,高層ビルである。アーキテクチャや設計なしでプログラマが自由に作れるものではないというのは,すぐに分かったが,ソフトウエア開発の世界は,アーキテクチャや設計不在で作るという癖がまん延している状況だった。開発するシステムのアーキテクチャをあらかじめ標準化し,毎回それに当てはめて設計をさせないと駄目だと考えた。

【疑問2】なぜ見積もり工数の妥当性を判断できないのだろう?

 次に,見積もり工数の問題がある。住宅では,二階建ての家の費用は素人でもだいたい検討がつく。坪単価50万円で40坪であれば,2000万円で家が建つ。金額に差が出るのは,木材の質,柱の太さ,壁や柱の数,窓の数,工法,風呂やキッチン,サッシや床といった設備や材料のグレード,職人の単価など。しかも,そういったもので贅沢をしても,金額の増減はだいたい予想がつく。

 これに対しシステムの値段は,まったく予測不可能だった。「こんな機能だったら,だいたいいくらくらい」という経験値で見積もっているだけで,何をどれくらい作るから,これだけかかるという説明がなかった。入会申し込み機能の改造のケースでも,結局「今あるソースコードで,何行くらい修正が入るだろう」という見積もりになっており,機能や仕様の複雑性からの妥当性は全く存在しなかった。

 本来,実現するシステムの複雑さは,利用者から見たシステムの動きの複雑さで測るのが妥当である。利用者が,この画面から,こういう入力をした結果,画面がこう表示されたり,メールでこういう内容の通知が来たり,管理台帳(DB)を更新したり,といった一連の動きで複雑さは決まるべきだと考える。

 我々は,この一連の動きをユースケースと呼んでいる。どの程度の複雑さのユースケースがいくつあるのかが分かれば,論理的にシステム規模の説明ができるし,要求側もユースケースだと量や質,範囲がよく分かるので,要求者と開発者のズレもなくなると考えた。そして,誰にでも分かるようにユースケースを分析し,図面のように記述できる方法が必要だと考えた。