2003年くらいから，日本でも多くの大学で始まった「MOT（Management of Technology＝技術経営）」。米国で始まった教育カリキュラムだが，1980年代以降に，米国メーカーが日本のメーカーに追い付き追い越すために，日本のメーカーが現場で実践していたことを学問として体系化していったカリキュラムも多い。これは，日本の製造業の強さを示すエピソードの1つである。トヨタに代表される日本の製造業の強さは今でも健在だ。
翻って，日本のソフトウエア産業を見てみると「『家内制手工業』にとどまっており，ほかの製造業のように『近代化』されていない」と嘆く声は多い。具体的には，プロジェクトごとに利用する開発ツールや開発プロセス，プロジェクトマネジメント手法などがばらばらで全社的に共有できていない，プロジェクトに関する定量的なデータの収集（定量化）ができていないので品質や生産性の改善につながらない，多重下請け構造の中で協力会社も含めたしっかりしたプロジェクトマネジメントができない…，などなどだ。
企業情報システムを受託開発するベンダーも，自社のシステムを開発する情報システム部門も，「何か新しい手段が必要になっていることは間違いない」(コンサルティング会社一の大槻繁副社長COO専任コンサルタント）。9月14日に経済産業省の産業構造審議会が発表した報告書「情報サービス・ソフトウェア産業維新～魅力ある情報サービス・ソフトウェア産業の実現に向けて～」でも，「多重下請け構造，人月工数主義という旧態依然としたビジネスモデルは許されない，国際競争に勝ち抜くためにも改革が待ったなし」としている(コラム参照）。
では，どうすればいいのか。改革の具体的な手段の一つとして，最近よく聞くようになったのが「ソフトウエア・ファクトリー」である。Googleでの検索結果数も100万以上に上り，注目度は増している。
Microsoftの発表が流行のきっかけ
日本でソフトウエア・ファクトリーという言葉が流行るきっかけになったのは，米Microsoftが2004年に発表した開発方法論Software Factoriesである。この方法論は，「ソフトウェアファクトリー」（日経BPソフトプレス）として書籍化もされている。
MicrosoftのSoftware Factoriesは，「ソフトウエア・プロダクトライン開発」のコンセプトがベースになっている。ソフトウエア・プロダクトライン開発とは，製造業における「製品系列（プロダクトライン）」(機能や形状が似た派生製品群）の考え方を手本にしたソフト開発手法のことだ。共通のコア・アセット（ソフト部品）をあらかじめ用意しておき，それをベースに，機能が類似した複数の異なるアプリケーション（製品系列＝プロダクトライン）を，できるだけ効率的に(自動的に）開発する。もともと，米カーネギーメロン大学のSEI（Software Engineering Institute）が提唱した考え方である(ホームページ参照）。
なお，ソフトウエア・プロダクトライン開発に関しては国際会議「Software Product Line Conference」が毎年開催されている。今年は2006年8月にボルチモアで開催された。2007年は，京都で開催される。
話をMicrosoftのSoftware Factoriesに戻そう。Software Factoriesでは，まずプロダクトライン（製品系列）を定義する「Software Factoryスキーマ」を作成する。このとき，アプリケーションのどこが固定部分（変わらない部分）で，どこが可変部分（変わる部分）かも決めておく（可変性分析）。次に，モデリング言語のDSL（Domain Specific Language）やパターン，フレームワーク，開発ツールなどを用意する。これらのセットのことを「Software Factoryテンプレート」と呼ぶ。Software Factoryテンプレートは，できるだけソフトを自動生成できるように作成しておく。
ここでDSLとは，ある領域(Domain）に特化したモデリング言語のこと。例えば，UML（Unified Modeling Language）もMIDI（Musical Instrument Digital Interface）もシステム構成を表す図も，すべてDSLである。同社の開発環境である「Visual Studio 2005 Team System」では，このDSLを独自に定義することができる。
最後に，Software Factoryテンプレートを利用して，ある特定領域の個別のアプリケーション(製品系列の一つ）をできるだけ効率的に開発する。
Software FactoriesはMicrosoftが発表したものだが，日本のマイクロソフトも，米国発のSoftware Factoriesと財団法人・京都高度技術研究所顧問の松本吉弘氏による「ソフトウエア・セル生産方式」などのアイデアを組み合わせた，独自の方法論に沿ったコンサルティングを始めている。
ちなみに，ソフトウエア・セル生産方式とは，製造業のセル生産方式をソフト開発に適用したもので，開発要員や成果物，プロセスを「セル」としてグループ化する。ソフトウエア・セル生産方式に関しては，「ソフトウエア・セル生産方式を検討し，日本のお家芸であったソフトウエア・ファクトリーの現代版を世界に向けて発信していく」ことを目指して，アジャイルプロセス協議会が「アジャイル・ソフトウェアセル生産WG(ワーキンググループ）」を立ち上げている。
MicrosoftのSoftware Factoriesについては，「Visual Studio 2005 Team Systemのプロモーションに過ぎない」，「業務や企業戦略に深くかかわる『可変性分析』に関する現実的な方法論がない。本当に可能なのか」といった懐疑的な声も聞く。Microsoftの¨本業”はソフトウエア製品の販売であり，コンサルティングではない，このため，こうした懐疑的な声が出るのはある面，やむを得ない。だが，こうした意見のせいで「ソフトウエア・ファクトリー」がベンダーの「セールストーク」，つまりこれまでも現れては消えていった「バズワード」の1種とみなされてしまってはもったいない，と記者は考えている。
ソフトウエア産業を救うキーワードの1つ
記者は，「ソフトウエア・ファクトリー」は日本のソフトウエア産業を救う重要なキーワードになり得る，と考えている。ただし，ここで言うソフトウエア・ファクトリーの意味は，MicrosoftのSoftware Factoriesよりも広い。要するに「製造業の工場を見本にしたソフトウエア開発」である。冒頭で述べたように，日本の製造現場＝工場の競争力はいまだに強い。だとしたら，これをお手本にしない手はないと思うのだ。
実は，こうしたコンセプトのソフトウエア・ファクトリーは，1970年代のメインフレーム時代，日本に存在していた。例えば，先述した松本吉弘氏らが構築した東芝府中事業所内のソフトウエア工場では，リアルタイム制御システムに対象を絞り，ソフトウエア再利用を徹底して実践。担当者には作業指示書が渡され，まさに製造業の工場のようにソフトウエアを開発していた。MicrosoftのSoftware Factoriesも，そのアイデアは70年代の日本のソフトウエア工場から来ている。
では，製造業の工場の何を手本にすればいいのか。1つは，製造ラインの構築である。ソフトウエア開発で言えば，開発ツールやフレームワーク，ソフトウエア部品，開発プロセス，マネジメント・ツールなどを標準化して集約し，それをすべてのプロジェクトで利用することにほかならない。2つ目は前述したソフトウエア・プロダクトライン開発である。これは，さまざまなアプリケーションを受託開発するベンダーよりも，開発するアプリケーションの範囲がある程度限られるユーザー企業のほうが実践しやすいだろう。そして3つ目が，計画を作成して作業指示書を出し，進捗を管理する生産管理の考え方だ。
70年代の日本のソフトウエア工場は，それぞれのメインフレーム・メーカーが開発ツールからミドルウエア，ハードウエアまで提供していた。このため，ソフトウエア・ファクトリーは今よりも構築しやすかったと言える。だが，90年代以降，オープン化に伴い開発ツールやミドルウエア，ハードウエアが急激に多様化。これらを標準化して集約することが難しくなった。
しかし，90年代に始まったオープン化の技術も成熟してきた。ようやく，開発ツールやフレームワーク，ソフトウエア部品，開発プロセスなどを標準化・集約しやすくなったため，“現代流”ソフトウエア・ファクトリーの“復活”を目指す動きが活発になってきたと言える。
実は，製造業の工場のようにソフトウエアを開発する，というコンセプトで自社のソフトウエア開発環境の整備を始めた大手システム・インテグレータがある。新日鉄ソリューションズである。同社は「次世代分散開発支援環境」と呼ぶソフトウエア・ファクトリーを構築。この10月からパイロット・プロジェクトに適用し，2007年にも実運用を開始する。
同社のソフトウエア・ファクトリーでは，ソフト開発に必要なすべてのリソースを1カ所（リソースセンター）に集約する。構成管理やドキュメント作成，コード・ジェネレータ，自動テスト・ツールなどの「開発支援ツール」，「プロジェクトマネジメント・ツール」，「コミュニケーション支援ツール」，「知識・情報共有ツール」，さらにコード・ジェネレータに入力するテンプレート（ソフトウエアのひな型），全社共通のソフト部品などだ。これは工場の製造ラインに当たる。
このリソースセンターを，すべてのプロジェクトのメンバーが，ネットワーク経由でWebブラウザから利用する。工場の生産管理システムと同様，利用者の画面には作業指示書も表示される。プロジェクトの成果物やテスト結果などのプロジェクト・データは，すべてリソースセンターのデータベースに蓄積されていく。
すべてのプロジェクトがリソースセンターを利用することで，最新の開発ツールやテスト・ツールの恩恵を受けられる。このため生産性や品質が上がり，開発手法の標準化も図れるので保守性も向上する。加えて，プロジェクト・データがリソースセンターのデータベースに蓄積されるため，これを見ることでプロジェクトの状況も把握しやすくなるし，様々なデータを分析することで，リソースセンター(製造ライン）自体の「カイゼン」も可能になる。
新日鉄ソリューションズの取り組みが，うまくいくかどうかはまだ分からない。システム・インテグレータが全社的にソフトウエア・ファクトリーに取り組むには，多額の投資も必要になる。改革の手段も，ソフトウエア・ファクトリーだけではないだろう。
しかし，これくらい思い切ったことをやらないと，日本のソフトウエア産業は改革できないのではないだろうか。今のままで何の手も打たないと，産業構造審議会の報告書が指摘するように，日本のソフトウエア産業の競争力は落ちる一方であることは間違いない。ソフトウエア・ファクトリーは，少なくともソフトウエア産業の競争力を強化する手段の1つになる，と記者は考えている。
