第3章 米国政府支援SDP（Software Design and Productivity）研究開発の動向
[OSSPによるソフトウェア開発の特徴]
OSSPによるソフトウェア開発方法の特徴を以下に示す。
① OSSPの開発組織
・地域的な広がり
国際化、標準化に優位性を持つ。
・万人が認めるリーダの存在
LinuxではLinus Torvaldsの存在
・巨大な数の貢献者集団
Linuxではコード提供者200人以上、バグ修正者1000人以上
・金銭的動機ではなく、余暇に開発に貢献する個人集団
（ただし、商業版Linuxが登場して変わりつつある）
② OSSPが成功する開発運営方法
・インターネットの共働技術を駆使
メーリングリスト、ニュースグループ、Web
・共通の目標
「UNIXを作り直せ」＝＞方向性を明確にし、開発チーム全員の意思決定
（「すばらしいOSを作ろう」といったあいまいな目標はダメ）
UNIXの経験＝＞何がうまくいって、何がうまくいかないかが分かる。
・共通の経験、スキル
UNIX/gnu＝＞参入障壁を低くし、参加できる開発者を増やす。
・並列競合開発とコンポーネント化の枠組み
コンポーネントの枠組みを確立し、複数の小チーム、個人が個別に開発。
競合した場合は、最もいい実装を選択。
・並列デバック
誰かが問題を見つけ、たいてい別の人がその問題を理解してそれを直す。
デバックは、プロジェクトに参加する人の数に正比例して効率が上がる。
これが、ブルックスの法則（開発者の人数を増やしても、管理、調整作業が増大して効率が比例して上がらない）から逃れる鍵
・紛争解決
Linuxでは、「やさしい独裁者」モデル
Linus Torvaldsがプロジェクトのリーダ。
大きなコンポーネントを信頼できる副官に移譲。
副官は、サブコンポーネント開発者に移譲。
Apacheは、共同開発者による議決委員会方式。
・動機づけ
開発者の個人的な悩みを解決
自分のエゴの満足とハッカー社会での評判
ハッカーの社会は、贈与文化。
ものが豊富な社会（ソフトが自由に共有される社会）では、競争的な成功の尺度は仲間内の評判
ノウアスフィアの開墾
未開の土地を開拓し、自分のものにすること
弱者の反発（反マイクロソフト）
・コードの分裂の回避
万人が認めるリーダの存在：Linus Torvalds
GPLライセンス（派生したものはフリーにしなければならない）
ハッカー社会での評判が低下する恐れ
[OSSP開発を効率化する法則]
Linix上のfetchmailを開発したレイモンドは、そのOSSPを実践した経験から、OSSP開発を効率化する法則を「伽藍とバザール」[19]に書いている。その法則を以下に列挙する。
①よいソフトはすべて、開発者の個人的な悩み解決から始まる。
②何を書けばいいかわかっているのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかっているのが、すごいプログラマ。
③捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるのだから（フレッド・ブルックス『人月の神話』第11章）
④まともな行動をとっていれば、おもしろい問題のほうからこっちを見つけだしてくれる。
⑤あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
⑥ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグの一番楽ちんな方法。
⑦早目のリリース、頻繁なリリース。そして顧客の話を聞くこと。
⑧ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
⑨賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
⑩ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
⑪いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
⑫もっとも衝撃的で革新的な解決策が、自分の問題のとらえかたがそもそも間違っていたという認識からくるということはよくある。
⑬「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
⑭ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
⑮ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
⑯自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
⑰セキュリティシステムのセキュリティは、そこで使われている秘密の安全性にかかっている。見かけだけの秘密は要注意。
⑱おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
⑲開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。
[OPPSの強み]
指数関数的性質
・OSSPはインターネットと共に成
・OSSPでは「勝者がすべてをかっさらう」
・開発者は最大のOSSPプラットフォームに貢献したがる。
・大規模なOSSPプロジェクトのほうがもっとたくさんの「目先の問題」を解決する。
長期的な信用
・バイナリは死に絶えるがソースコードは永遠なり。
・コード分裂の不在が長期的信用につながる。
並列デバック
並列開発
完璧なAPIとドキュメンテーション
頻繁なリリース
[OSSPの弱み]
OSSPプロジェクトを始めるのは難しい。
OSSPを信用させ、開発に貢献するには以下のことが基準を満たさないといけない。
大きな将来のノウアスフィア
大きな悩みを解決する
まずは問題のそこそこの部分を解決せよ
飽和点に達した後の開発
飽和点に達すると、OSSPが成功する要件である「共通の目標・スキル」、および「大きなノウアスフィア」が薄れてくる。これをどう克服するか。
非専門家からのフィードバック
OSSPは、「開発者の個人的な悩みを解決」が動機付け技術水準の高いユーザ向けシステムのなりがち
（2）エクストリーム・プログラミング（XP）
エクストリーム・プログラミング[20]とは、Kent Beckらによって提唱されているソフトウェア開発方法であり、略してXP（eXtreme Programming）と呼ばれている。
XPは、コミュニケーション、シンプルさ、フィードバック、勇気に価値を置く開発手法である。その特徴は、変化を容認（Embrace Change）するとの思想に立ち、その変化に対応できように、初期設計はシンプルに行い、リファクタリングによる再設計を重視し、また、変更コストが時間とともに増大しないように、テストを自動化するなどプログラミング、テストを重視している。また、チームに責任と権限が与えられ、メンバがプロセスを最適化していくセルフオーガナイズされたチームを目指し、人間であるプログラマに大切にする思想に立っている。
[12のプラクティス]
XPは、これらの思想に立脚し、次の12のプラクティス（経験に基づいて有用性が立証された実践項目）を示している。
① 計画ゲーム（The Planning Game）
ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。
② 小規模リリース（Small Releases）
シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。
③ 比喩（Metaphor）
どの様に全体のシステムが機能するかを示すシンプルな喩え話（メタファー）をメンバが共有することで全ての開発を導く（ガイドする）。
④ シンプルデザイン（Simple Design）
いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。
⑤ テスティング（Testing）
プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。
⑥ リファクタリング（Refactoring）
2重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を換えることなくシステムを再構成する。
⑦ ペアプログラミング（Pair Programming）
全てのコードは2人のプログラマにより一台のマシンで書かれる。
⑧ 共同所有権（Collective Ownership）
誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。
⑨ 継続的インテグレーション（Continuous Integration）
システムを一日に何回もインテグレードしビルドし、テストを 100% パスさせる.
⑩ 週40時間（40-Hour Week）
週40時間以上仕事をしてはいけないのがルール。
⑪ オンサイト顧客（On-Site Customer）
現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。
⑫ コーディング標準（Coding Standards）
プログラマは、コーディング標準に従って全てのコードを書く。