［実践編］トラブルが起きた個所を指で指してほしい

　ソフトウエア・ファクトリーの肝の一つは，製造業がラインでものを製造するように，ソフトウエアもラインで開発できる仕組みを作ることである。ラインでものを作るには，その製造物の構造や作り方を，毎回考えて作るという方法は適していない。業務システム，Webシステム，Webサイトといったそれぞれの特徴に最も適したアーキテクチャを一つ決定し，その構造に沿った作り方を確立し，それに合った最適な開発ラインというものを作ることが必要である。

　多くのソフトウエア開発の現場では，そういったことをSE個人やチームで検討して決めている。BIGLOBEでは，これを組織単位で検討して決めることにした。検討する際に考慮した六つの視点を説明する。

【視点1】トラブルが発生した場所を指で指してほしい
【視点2】同じフォーマットで設計図を見たい
【視点3】開発工程と図面の関係をはっきりさせたい
【視点4】業務要件定義の手戻りを無くしたい
【視点5】要求と実装のギャップをゼロにしたい
【視点6】プログラミング言語を使いたくない

【視点1】トラブルが起きた個所を指で指してほしい

　まず，必要だと考えたのが「プロダクトのアーキテクチャ」である。プロダクトとは，これから開発する情報システムを指す。

　例えばトラブルが起きたときに，システムのどこに問題が発生したのかを把握しなければならない。開発・運用の責任者は，一体どこかどう問題なのかを知るために，システムがどういう構造になっていて，どこがトラブルの原因なのかをエンジニアに確認する。ところが，多くのエンジニアはトラブルが起きたプログラムの処理の説明をするばかりなのである。

　こちらとしては，図面を指で指して「この部分がおかしい」と言ってほしいのに，そうしてくれない。どうしてこのようなコミュニケーションのギャップが生まれるのかを考えた結果，どうもプログラマは，プログラム言語からものを見ていて，全体の構造図でものを見るということが苦手らしいという結論に至った。

　これを解決するには，システム全体の構造を設計し，個々のコンポーネントを組み合わせてシステムを構築する世界を作る必要があると考えた。そのためには，アプリケーション・アーキテクチャをあらかじめ用意しておく必要がある。プログラムでものを見ている限りはどこまでいっても処理なので，システム構造論にはならないので無理だと考えたのである。

【視点2】同じフォーマットで設計図を見たい

　次に必要と考えたのが「設計図の標準」である。家の場合，基礎や土台，柱，梁という決まった構造でどんな家でも作る。こういった基本的なアーキテクチャを標準化し，システム全体の設計図も標準化しようと考えたのだ。

　設計図の標準があれば，システム全体の中で個々のコンポーネントの位置が分かる。図1は，分析したユースケースと，それを実現するコンポーネントを表形式で図式化したものである。これによって，問題の把握も容易になる。また，図で書くことで関係者への共通理解が早くなり，個人差も出にくくなる。他者への引き継ぎ，第三者による問題指摘も容易になる。

図1●ユースケースとそれを実現するコンポーネントを記載する図面の例

【視点3】開発工程と図面の関係をはっきりさせたい

　工場のラインでは，各工程完了時の成果物が明確である。これに対し，ソフトウエア開発では，工程と図面があいまいなケースが多く，どこまでいっても仕様書という文章での表現が多用されている。これではファクトリー化は不可能だと考えた。

　文章による仕様書の問題としては，せっかく分析や設計を完了しても，次の工程の人がそれを理解するのに，解釈が必要であり，労力がかかり，ミスや勘違いが混入するということだ。さらに，工程完了後の成果物のレベルが規定しにくい。どこまでが前工程の責任で，どこからが次工程の責任なのかも分かりにくいという問題がある。

　ファクトリーには，プロダクトラインがあるわけなので，各工程の明確なミッションと工程ごとの成果物責任が明確でなければ，ラインにはなりようがない。そこで必要になってくるのが「工程ごとの図面標準」である（表1）。