ソフトウェアファクトリ

6.1 はじめに

効率的なソフトウェア開発のためには，開発技術，管理技術，開発環境などの整備が欠 かせない．品質会計考案組織では，1970年代からソフトウェア開発環境や技術の整備に取 り組んできた．近年は，性能が良く使いやすい開発ツールが普及してきたこともあり，こ のような開発ツールや技術を組み合わせて，最適な開発環境を構築することが重要になっ てきた．本章では，その取り組みについて論述する．

6.2 ソフトウェアファクトリの変遷

1970年代は，ソフトウェア規模が急激に増大したため，それにともなってさまざまな問 題が発生するようになった時代である．特に，ソフトウェアのバグ対応費用の増大は深刻 であり，ソフトウェア品質問題は経営課題となった．いわゆるソフトウェア危機と呼ばれ る状況である．このソフトウェア危機に対応するために，NECは1981年にSWQCを開始 した[3-6]．SWQC（SoftWare Quality Control）とは，ソフトウェアの総合的品質管理活 動であり，ソフトウェアに対する品質管理活動を全社的に展開する実践としては世界初の 試みである．「ソフトウェアは，手工業や家内工業ではなくエンジニアリングや製造業に近 いやり方で作られるべきだ」（元日本電気副社長・水野幸男博士）との考え方が基盤となっ ている．SWQCの理念は，「品質を追求しよう．生産性は後からついてくる」であり，その 目的は「ユーザに喜んで買っていただき，しかも社会の発展に貢献するソフトウェアの実 現」である．SWQC は，経営トップからのトップダウン的アプローチと，小集団活動を中 心とするボトムアップ的アプローチの両面による活動である．現在では，SWQCはSWQC コミュニティという形式で，社内組織を超えたソフトウェア開発者交流の場として継続し ている．

SWQC 活動を開始するとともに，ソフトウェア開発に関するさまざま研究にも取り組ん だ．ソフトウェアファクトリもその１つである．有識者を招いての定期的な勉強会のなか で，「ソフトウェアの『生産工場』と称するものが，単に同じ建物の中で『職人』達が机を 並べて仕事をしているだけという状況を脱して，品質の良い製品を作り出す『ノウハウ』

を蓄積し，したがって生産性も高い，近代的な工場に発展してゆくための起爆剤になって ほしい」（東京大学名誉教授・森口繁一博士）との発言が記録されている．これが，ソフト ウェアファクトリへ取り組むきっかけである．

図6-1は，品質会計考案組織におけるソフトウェアファクトリの進化の経緯である．全社 的なSWQC 活動の高まりとともに，1980 年代には，設計技術・レビュー技術・テスト技 術といった開発技術の整備と，品質会計をはじめとする管理技術の整備が行われ，それら のツール開発によって整備が進んだ．これらは，すべてメインフレームコンピュータが主 流だった時代に実施された．

1980 1990 2000

工程管理

品質管理 開発技術 再利用

分散開発

工程管理へ着手

SWQC活動（全社活動） ⇒ コミュニティ活動へ 組織的改善

開発

プロセス定義

設計技術の整備 レビュー技術の整備 テスト技術の整備

テスト工程品質会計

部品・リポジトリ化

上工程品質会計 工程管理

マルチ生産拠点化（生産マップ整備）

オフショア開発

（開発管理ツール） SPCS PROMIS Chiaro iChiaro

分散開発対応

～1970 2010

ソフトウェア ファクトリ

標準化・自動化・

再利用・

マネジメント強化 年代

図6-1 ソフトウェアファクトリ進化の経緯

1990年代に入ると，ネオダマと呼ばれるパラダイムシフトが起きた．ネットワーク・オ ープン・ダウンサイジング・マルチメディアの頭文字をとって表現したのがネオダマであ る．性能の良いPC上で動作するツールが次々と生み出され，ソフトウェア開発は良い意味 でも悪い意味でも大きな影響を受けた．作成したソフトウェアはすぐに実行可能になった ため，「詳細設計は不要」，「単体テストは不要」といった誤った考え方が広まった．メイン フレーム時代は，高価なメインフレームを使う時間の制約が厳しかったために，できるだ け机上での確認が必要だったが，オープン化の時代に入って安価な実行環境が整備される と，むしろその実行環境を利用することに重点が置かれるようになったのである．

2000年代に入り，オープン化の影響による弊害が出てきた．製品毎に最適化したソフト ウェア開発環境をもつようになったため，組織的なエンジニアリング施策の実行が難しく なった．例えば，統一的なツール導入を図るには，製品毎のソフトウェア開発環境へ，各々 開発ツールのインストール作業が必要になり，大幅な労力と時間をかけなければならない．

グ領域での組織的な検討が弱点」との指摘が契機となり，当該組織ではソフトウェアファ クトリの構築検討を開始した．本著者は，検討のリーダとしてソフトウェアファクトリの コンセプトおよび基本設計の確立に寄与した．ソフトウェアファクトリの構築開始以降は，

サブリーダの立場で関与している．

6.3 構築の考え方

ソフトウェアファクトリの構築にあたって，世界の有名ソフトウェア企業のソフトウェ ア開発環境をベンチマークした．その結果に基づき，ソフトウェアファクトリをモデル分 類したのが表6-1である．ソフトウェアファクトリのもつべき機能の配置状況に基づき，[A]

完全中央集約型，[B]中央＋一部分散型，[C]中央＋ローカル分担型，および[D]分散型の 4 種類に分類した．このうち最も進んでいる形態は[A]完全中央集約型である．この形態をも つソフトウェア企業では，世界中に分散する技術者が物理的に１つのソフトウェアファク トリにログインして開発する．昨日は米国で開発し，翌日は欧州でその開発の続きをする といったことが，現実として行われていた．開発資産はすべて１箇所のソフトウェアファ クトリに集約されているため，開発状況の把握や開発資産の管理，ツールの入れ替えなど が非常に効率的に実施できる．

表6-1 ソフトウェアファクトリのモデル分類

[A]完全中央集約型 [B]中央+一部分散型 [C]中央+ローカル分担型 [D]分散型

特徴

・全ての機能はセンター集約

・全ての開発者はセンター ファクトリ上で作業

・基本的な機能はセンターに 集約

・テストの一部は各開発拠点 で作業可能

・管理機能はセンターファクト リに集約

・その他の機能はセンターと ローカルで分担

・機能・資産・環境とも分散配 置

開発資産 ・センターファクトリ一括保有 ・センターファクトリ一括保有

・センターファクトリとローカル ファクトリで分担保有

・最終資産はセンターファクト リに集約

・センターファクトリとローカル ファクトリのどちらかに保有

・最終資産はセンターファクト リとローカルファクトリのどちら かに保有

開発環境 ・センターファクトリ一括保有

・基本的な機能はセンター ファクトリに集約

・テストの一部は各開発拠点 で作業可能

・センターファクトリとローカル ファクトリで分担保有

・センターファクトリとローカル ファクトリのどちらかに保有

・適用ツールはプロジェクトに より異なる

管理データ ・センターファクトリ一括保有 ・センターファクトリ一括保有 ・センターファクトリ一括保有

・センターファクトリとローカル ファクトリのどちらかに保有

・適用ツールはプロジェクトに より異なる

当時の品質会計考案組織は，[D]分散型であった．製品毎にソフトウェア開発環境を運用 し，開発資産はセンターファクトリまたはローカルファクトリのどちらか，または両方で 管理していた．開発ツールは製品の特性に合わせて選択していたため，組織的に見るとば

らばらだった．実は，1980年代のメインフレーム時代には，品質会計考案組織のソフトウ ェアファクトリは[A]完全中央集約型だった．高価なメインフレームを製品毎に保有するの は事実上不可能だったため，中央集約にならざるを得なかった．それが，オープン化によ り，製品毎に少しずつ開発環境，開発言語，実行環境，サポートするプラットフォームな どが異なるようになり，さらにオフショア開発など分散開発の進展につれて個別最適化が 進み，[D]分散型に変化したのである．

この調査結果に基づき，品質会計考案組織のソフトウェアファクトリは[B]中央＋一部分 散型を選択することにした．[B]中央＋一部分散型とは，基本的な機能はセンターファクト リに集約し，テストの一部のみ分散開発拠点で実施可能とするモデルである．IT 製品向け のミドルソフトウェアという開発製品の特性を考慮すると，多種多様のストレージやネッ トワーク機器に対する実機テストが必要であり，それらをすべてセンターに集約して実施 することは，オフショア開発を含む分散開発体制をとっていることから，事実上不可能な ためである．

6.4 ソフトウェアファクトリの狙い

ソフトウェアファクトリとは，ソフトウェア開発方法論，ツール，環境を統合したシス テムをいう．ソフトウェアファクトリの目的は，ソフトウェア開発の品質・生産性の大幅 な向上である．ソフトウェアファクトリの目的を達成するための狙いを表6-2に示す．狙い は 4 つあり，標準化，自動化，再利用，およびマネジメント力向上である．標準化，自動 化，再利用は，この順番で取り組んでいる．

表6-2 ソフトウェアファクトリの狙い

狙い 内容 主な実施項目

標準化

開発のあらゆる場面の標準化を進 めることにより，究極の標準化を実 現する．

・プロセス，環境，ツールの更なる標準化

・開発付帯作業の切り出し，集約化

自動化 自動化が可能な範囲において，適 切な自動化を推進する．

・プロセス，環境，ツールの更なる標準化

・ビルドサイクルのデイリー化

・オートメーション化推進

再利用

アーキテクチャ，ソースコード，ド キュメントを部品化し，再利用を進 める．

・アーキテクチャ，設計，ソースコードの部品化，再利 用

・設計仕様書，マニュアルの構造化，再利用

マネジメント力向上 ソフトウェアファクトリの効果を最大 ・指標管理の高度化

・情報漏えい防止の強化