の考察
現状のソフトウェア開発手法および管理手法には，4．2節で述べたよう な以下の問題点がある．
（1）開発手法や管理手法がいまだに未熟である．
（2）普遍性を求め過ぎる傾向がある．
（3）巨大ソフトウェアシステムの新規開発を意図した手法が多い．
（4）過大なドキュメント作成を求める傾向がある．
（5）開発者と発注者が協力的関係でなく，敵対的関係にある．
（6）技術者の独創性を生かしていない．
本章ではこれらの問題を解決するためのソフトウェア開発手法および管理 手法について考察する．
今までの手法で特に問題になるのは，ソフトウェア開発の原点を直視して いなかったことである．大規模開発と言う側面を強調し過ぎるあまり，開発 全体の構造や組織運営に注力し，ソフトウェアとは何かの原点を見失ってき たのである．
ソフトウェアと言うのはプログラムー行一行にいたるまで，技術者の創造 性から生まれる設計そのものであり，それ故プログラムリストが究極のドキ
ユメントである．今まで，プログラマ（設計者）がその創造性のある仕事を する環境を整備することより，他の工業との類推から，管理者，分析者，設 計者，プログラマ（コーダ），テスタといった分業化を進めてきた．おのお ののプログラマ（設計者）は，全体の構造が見えない歯車として働くような 仕組みを作ってきたと言える．
いわば全体主義国家の行政・軍事・警察機構は緻密に作られているが，国 民一人一人が見えないようなものである．分業体制の中でも管理者，分析者 や設計者が上位におり，プログラマ（コーダ）が軽視される風潮があった．
本来主役であるはずのプログラマの創造性を軽視した本末転倒のことが行
われてきた．
本章では，プログラマ（設計者）が開発の主役であるような開発モデルの 幾つかを検証する．それらのモデルの利点を生かし，かつ，改善するような 新しい開発手法を提案し，それを支える開発管理手法を提案する．
管理者はあくまで開発の主役であるプログラマを支える縁の下の力持ち に徹し，プログラマが働きやすい環境を整備する役割を担うものとして位置 付ける．野球やサッカーの試合において主役はあくまで選手であって，監督 やコーチに例え命令する権限があっても試合が始まれば単なる黒子である のと同様である．テレビタレントが主役であり，彼らを管理する興行会社は あくまで黒子である．プログラマこそがソフトウェア開発の主役であるべき
である．
5．1 設計者を主役とする既存の開発手法
今まで設計者が主役となるような開発手法および管理手法が，幾つか提案 され実施されている．ここでは，その代表的な3例を挙げる、
（1）チーフプログラマ制
（2）Microsoft社のフィーチャチーム制
（3）エキストリームプログラミング
（i）チーフプログラマ制
チーフプログラマ制はMillsの提案し実践した手法で［27］，外科手術チー ムとの類推から考え出された．外科手術は，数人のチームで行われるが，実 際手術を行うのは執刀医一人だけである．他のスタッフはすべて心電図をチ ェックしたり，メスやピンセットを渡したり，執刀医の汗を拭いたりして，
執刀医の手術をサポートするだけである．
チーフプログラマ制のプログラミングチームもチーフプログラマと数人 のスタッフで構成されるが，設計やプログラミングの全権限と責任を持つの はチーフプログラマだけである．他のスタッフは，ライブラリアン，バック アッププログラマ，テスタなどとして支援作業を行う．技術的な情報はすべ てチーフプログラマに集まり，すべての決定はチーフプログラマが行い，開 発が進められる．この手法の成否は，チーフプログラマとして優秀な技術者 が得られるか否かにかかっている．
i
s彩ー ﹂
ー彩多蕩R藷蒙裟裟ーかつて構造化アセンブラの開発［15］で，ほぼ新人ばかりの4人とでチーム を組み，チーフプログラマ制に類似の手法をとったことがある．全体の方式 設計の後，各人の分担範囲や設計方法，記述方法などを決めた後，それぞれ に設計・プログラミング・テストは任せた．自からの担当部分はもちろんの こと，全員の設計・プログラムにもすべて目を通し，不具合点の指摘やテス
トの方法を指示するとともに，ユーザマニュアルの作成も担当した．
この手法は，チーフプログラマに掛かる負担が非常に大きいので，開発規 模がそれほど大きくなく短期間の開発，すなわち高々10万ステップ，開発 期間6ヶ月以内のソフトウェア開発に適用できると思われる．
（幻Microsoft社のフィーチャチーム制
Microsoft社がo伍ceパッケージの開発で用いている，個々のプログラマ の創造性を生かすソフトウェア開発手法である［6］．Officeパッケージには，
Word， Exce1， PowerPoint等が含まれるが，ソフトウェア規模は既に巨大 になっており，大勢の開発要員により定期的なバージョンアップで，機能の 追加や改良が行われている．
この手法では，プログラマとテスタのペアを単位としてチームを組ませ，
幾つかのプログラマとテスタのペアを集めてフィーチャチームとしている．
フィーチャ（Feature）とは，例えばタスクバーの機能あるいはプルダウン メニューの機能のように，一連のまとまった働きをする機能のことであり，
次に開発すべきフィーチャが決まると，その開発をフィーチャチームあるい はプログラマとテスタのペアに任せる．
各フィーチャチームには管理者がいるが，必ずしもプログラマではなく，
開発すべきフィーチャの外部仕様をVisua18asic等で記述し，どのフィー チャをどのペアに任せるかを決めるだけである．もちろん，大きなフィーチ
ャの開発は複数のペアに分担させることもあるが，開発は原則としてペアが 責任を持つ．
プログラマが与えられたフィーチャの実現方法を考え，設計やプログラミ ングをするのと並行して，相棒のテスタがテスト方法を考え，テストプログ ラムを作成し，出来上がったプログラムをテストする．プログラマとテスタ は常に協力し，そのフィーチャを完成させることになる．
開発すべきフィーチャが完成し，単独で動くことが確認されると，テスト ラボ（テストの設備が整ったテスト部門）に持ち込まれ，WordならWord の全体のプログラムに組み込まれ，機能が正しく動くか，システムダウンを 起こさないか，などの負荷テストを夕方から朝にかけて一晩中コンピュータ で行う．ペアは翌朝テスト結果を受け取り，次の開発を行うことになる．
この手法では，まず品質の保証された全体プログラムがあり，新しいフィ ーチャを組み込んで，一晩の負荷テストをしてきちんと動けば，新しい全体 プログラムが完成しているという考え方をとっている．どのペアあるいはど のフィーチャチームがどんな順に新しいフィーチャを組み込もうが，全体の ソフトウェアは常に完成の状態にあり，いつでも出荷ができる状態にある．
機能が徐々に増加するあるいは改善されるだけである．あるフィーチャが予 定していたバージョンアップの出荷に間に合わない場合でも，そのフィーチ ャは次のバージョシの開発に延期されるだけである．
大きなシステム開発では，フィーチャチームの数が増えることになる．全 体の開発期間が長期間にわたるものでも，数週間ごとの期間（フェーズ）に 区切り，各フィーチャに優先度をつけ，優先度に従いどのフェーズで開発す るかを決め，どのフィーチャチームやペアに開発させるかを決める．
この手法では，プログラマとテスタのペアは，指定されたフィーチャの開 発責任を負わされるが，開発の方法についてはすべて任され，技術者として 全精力を注ぎ込める．
分割された工程だけを担当する手法では，自分が開発ソフトウェア全体の のどの部分を担当しているのかすら分からず，ただ与えられた作業を行って いるだけであるのに比べると，開発に誇りと喜びを感じることができる．
この手法はパッケージ開発のように自社で仕様を決められる開発に向い
た手法と言える．
（皿）エキストリームプログラミング
Ken Beckらによって提唱されている開発手法で（［28L［29］参照），12 個のプラクティスと呼ばれる指針を与えている．
指針の一っに「ペアプログラミング」が提唱されており，プログラマ2人 のペアで，小規模な開発（ここでは「機能」と呼ぶ）を短期間に開発する．
開発された「機能」はシステム全体に結合される．
各「機能」をプログラムで実装する前にまず，その「機能」をテストする プログラムを開発する．プログラムを単純にするため，何度も書き換える（リ