オブジェクト開発の神髄

最先端のソフトウェア開発
最先端のソフトウェア開発として以下について概説している。
!最新の開発技術
以下の技術について長所と短所を評価している。
*オブジェクト指向
*XML
*RDB
*Webサービス

!最新の開発手法
*アジャイルソフトウェア開発
ウォーターフォールモデル、オブジェクト指向ソフトウェアプロセス(object-oriented software process:OOSP)、ラショナル統一プロセス(Rational unified process:RUP)の問題を経て、Agile Allianceはソフトウェアを成功させるための拠り所となる基本的な常識を形成する４つの価値と１２の原則を定義。
本書では、アジャイルモデル駆動開発(agile model-driven development:AMDD)アプローチとそれをサポートするテスト駆動開発(test-driven development:TDD)について説明している。

*UML
広く普及して一貫したモデリング記法を提供しているが、UI表記などUMLの範囲を超える場合がある。

*統一プロセス(unified process:UP)
具体的なソフトウェア開発プロセスを作り出すためのプロセスフレームワーク。例としてラショナル統一プロセス(Rational unified process:RUP)がある。RUPは方向づけ、推敲、作成、移行の４つのフェーズからなる。

*モデル駆動型アーキテクチャ(model-driven architecture:MDA)
OMG(Object Management Group)が定義したソフトウェア開発フレームワークで、モデリングを中心に開発作業を進める。1→2→3に変換していく。
1.プラットフォーム独立モデル(platform-independent model:PIM)
2.プラットフォーム特化モデル(platform-specific model:PSM)
3.コード
非常に精巧で複雑なため、本書ではアジャイル駆動開発(agile model-driven development:AMDD)で、UMLと組み合わせて適用することを勧めている。

!!オブジェクト指向概念の基本

!!フルライフサイクルオブジェクト指向テスト(FLOOT)
エクストリーム・プログラミング(XP)はフィードバックループが短縮されるのでプロジェクト後期でも変更コストが大きくならない。そのひとつがテスト駆動開発(TDD)による。

""

フルライフサイクルオブジェクト指向テスト(full lifecycle object-oriented testing:FOOT)方法論とは、オブジェクト指向ソフトウェアの検証および妥当性確認を行うためのテストおよび検証手法を集めたものです。
逐次的に行う必要はなくアジャイルのプロセスに適用可。

!回帰テスト
アプリケーションに対する変更が既存の機能に悪影響を及ぼさないことを確認する作業

!品質保証(quality assurance:QA)
プロジェクトの納品物や作業が、組織で採用している適切な標準やガイドラインやプロセスに準拠していることを検査および監査する作業。

!モデルのテスト
*利用シナリオテスト　シナリオをレビューしてモデルをその場で更新
*プロトタイプレビュー／ウォークスルー　ユーザが一連の利用シナリオに沿ってユーザプロトタイプがニーズを満たしていることをテスト
*ユーザインターフェーステスト　
*モデルレビュー　同僚同士でモデリング作業を批判的に検査する確認手法

!コードのテスト
*ブラックボックステスト　内部の動きを知らないまま期待される機能についてテストケースを作成する
*ホワイトボックステスト　プログラムコードをもとにテストコードを作成
*境界値テスト　異常な状況や極端な状況を処理できることを確認
*単体テスト　ここまでが単体テスト
*結合テスト　
*カバレッジテスト　コード内のすべてのコードパスをテストする一連のテストケースを設計する手法。ホワイトボックステストケースを集めたもの。
*パステスト　コードすべてのカバレッジテストに加え、ロジックのすべてのパスもクリアする

オブジェクト指向のテスト手法
*メソッドテスト
*クラステスト
*クラス結合テスト（コンポーネントテスト)
*継承回帰テスト　新しいサブクラスによってエラーが持ち込まれないことを確認

コードインスペクション（コードレビュー）

!システム全体のテスト
*機能テスト
*インストールテスト
*運用テスト
*ストレステスト
*サポートテスト　サポート担当者を対象

!ユーザによるテスト
*アルファテスト　まだ広く配布するレベルに達していないソフトウェアを小数の顧客に渡して問題を報告してもらう
*ベータテスト
*パイロットテスト　アルファテストの「社内」版
*ユーザ受け入れテスト(user-acceptance testing:UAT)

!テスト駆動開発(TDD)
テストファーストプログラミングあるいはテストファースト開発のこと。

!!アジャイルモデル駆動開発(agile model-driven development:AMDD)
コーディング前にアジャイルモデルを作成して構築対象のものを理解する発展型アプローチ。

モデリングはUMLだけでなくユーザインターフェースフロー図やデータモデル図などさまざまなモデルがある。ビジュアル化できないモデルもある。

AMDDはモデル駆動開発(MDD)のアジャイル版。MDDは逐次的な開発アプローチだが、RUPなど反復的な方法でMDDを行うこともできる。AMDDはソースコードを書く前に詳しくモデルを作りこむのではなく、かろうじて役に立つ程度のアジャイルなモデルを作成する点が異なる。設計モデルとコーディングを交互に行う。

最初の一定期間で、サイクル０の「初期モデリング」を行う。初期モデリングは、大雑把な要求とリリースの対象範囲を明らかにする「初期要求モデリング」と動く可能性の高いアーキテクチャを見つける「初期アーキテクチャモデリング」を行う。その後、サイクル１から反復的に、要求について調査し細部まで設計を進める「詳細モデリング」と「実装」を行う。

!情報収集スキル
*インタビュー
*観察
*ブレーンストーミング

!アジャイルなドキュメント
ホワイトボードの活用。加工して見やすくする。95%は消してよい。残りはモデリングツールに書き写す。



!!利用モデリング
システムをどう使うか調査するためのユースケース、ユーザストーリー、ユーザ機能という利用モデリング(usage modeling)手法

!!ユーザインターフェース開発

!!補足要求事項
補足的なモデリング手法について。

!!概念ドメインモデリング
エンティティとその関係を調査する手法

!!プロセスモデリング
利用モデリングを補足するプロセス検討の手法。

!!アジャイルなアーキテクチャ
アーキテクチャをアジャイルに作成する方法。

!!動的オブジェクトモデリング
オブジェクトの振る舞いの側面を検討するモデリング手法。

!!構造設計モデリング
ソフトウェアの構造を定義するための手法。

!!アジャイルなオブジェクトプログラミング手法
TDDやリファクタリングなどアジャイルプログラミング手法。

!TDD
４つの基本ステップ
*簡単なテストを追加
*テストを実行（コードがないから失敗する）
*テストが成功するようにコードを書く
*テストが成功する

TDDとAMDDはどちらもコーディングの前にじっくり設計を考えるが、違いはTDDはテストを行うがAMDDは図やカードなどモデルを作成すること。テキストと図の違いはチームによってどちらが効率的か変わる。筆者はモデリングと組み合わせるはTDDはより有効。

!!アジャイルデータベース開発手法
データベース開発アプローチ。

!!今後の進み方
最新のソフトウェア開発についてさらに学ぶには。
*ゼネラリスト化したスペシャリストになる
*学習を継続する

ピープルウエア

ソフトウェア開発に従事している人なら、この本は間違いなく面白い。読み物として楽しいのでスラスラ読めてしまう。

第１部　人材を活用する
「25人年以上を注ぎ込んだプロジェクトのうち…25％が完成しなかった」(p3)
原因の多くは技術的問題でなくプロジェクトの社会学、人に関する問題であるとし、本書のテーマとなっている。

「頭脳労働者が時々ミスを犯すのは極めて自然で…少々の間違いを大目に見ることだ」(p7)
間違いを許さない雰囲気が社内にあると、担当者は消極的になり、失敗しそうなことには絶対に手を出さなくなる。

スペイン流管理(p15)
この世には二つの価値観があり、一つはスペイン流の考え方で地球上には一定の価値しかないので植民地などから搾取する。もう一方は価値は発明の才能と技術で創造するもの。
ソフトウェア開発はイギリス流であるべきだが管理者は往々にしてスペイン流の価値観を持っている場合がある。
→１時間あたりの賃金からどれだけ多く搾り取れるか？スペイン流の管理ではサービス残業させたほうが見かけの生産性があがる。

「部下をできるだけ長く働かせ、納期を守ることがどんなに大切かを部下の頭に叩き込む」
「残業代がつかないサラリーマンに残業をさせることは、おろかな管理者が考え付きそうな幻想だ」
などとバッサリ。部下はバランスをとるため無業の時間が増えるので最終的には生産性は上がらない。

生産性と退職の関係(p20)
スペイン流の管理で生産性をあげても退職されると高い犠牲を払うことになる。退職コストは高い。日本では退職率がアメリカほど高くないので状況が異なるかもしれない。

品質
「大抵の人は自尊心を自分の作った製品の品質と強く結びつける傾向がある」(p23)
開発者は「厳しい納期に間に合わせるには、作業場の制限が多すぎる。納期通りに完成するために、プロジェクト資源をやりくりする自由もない。例えば、もっと人を投入するか、実現する機能を削るかという選択権がない。犠牲にできる唯一のものは品質である。」

→管理者は品質を犠牲にして納期を優先させようとする。

開発者を満足させる品質基準は、マーケットが望む品質よりずっと高い。「マーケットは品質なんか気にしない」
→開発者は品質を犠牲にしはじめる。

「ユーザーは、開発者に比べると、製品品質を必要とするレベルが低い…低品質によって市場浸透力が低下した分は、製品の売り上げ上昇分が補って余りある」(p26)

つまり市場の求める品質基準まで下がってしまう。これを「「品質第一主義からの逃避」と呼ぶ。」とのこと。

しかし、本書では次の教訓を示している。
「エンドユーザーの要求をはるかに超えた品質基準は、生産性を上げる一つの手段である」

「価値と品質はトレードオフの関係にあるという考えは、日本には存在しない…」
日本の論文から引用している。本当にそうなのだろうか。確かめるために論文を読んでみたいものです。

「管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである」

第2部　オフィス環境と生産性
プログラマーの個人差
プログラミングコンテストのデータを分析した結果。
「最優秀者の測定値は、最低者の約１０倍である」
「最優秀者の測定値は、平均的作業者の役２．５倍である」
「上位半分の平均測定値は、下位半分の平均の２倍以上である」
関連した予見、
「企業におけるプログラマーの能力差は１０倍であるといわれている。しかし、企業自体の生産性にも１０倍の開きがある」

１人による作業３０％、２人による作業５０％、３人以上による作業２０％
７０％は騒音を出す側
騒音、割り込みはプログラマーの生産性を低下させる。

オフィス環境を測るために、環境変数というものを導入していておもしろい。
E係数＝割り込みなしの時間数／机の前に座っていた時間

音楽を聴きながらの生産性の実験
音楽を聴きながら作業すると、作業自体は進むが創造性やヒラメキが低下する結果になる。

有機的秩序
長い年月をかけてゆっくりと出来上がった村落のようなもの。
作業空間はすぐに完成しない。建築学のパターンを使うなど。

第３部　人材をそろえる
管理者は最初に人材をそろえることが最も重要
優れた人材を選ぶ能力

エントロピーは組織内では常に増加する
平準化が進みエネルギーや仕事を生み出す可能性が減る

退職の隠されたコスト(p138)
従業員の退職は、目に見える部分だけで全人件費の２０％のコストを費やす。

会社が個人自己形成に投資をすれば、従業員は、長く勤めることが期待されているという雰囲気を決して見逃さない。

ホーソン効果(p156)
「人はなにか新しいことをやろうとしたとき、それをよりよくやろうとする。」
生産性向上はホーソン効果によるところがある。

第４部　生産性の高いチームを育てる
「チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。」
このようなチームの特徴は、退職率の低さ、アイデンティティ感覚、選ばれたものとしての感覚、生産物共有意識、明らかな楽しさ、とのこと。

チーム殺し(p172)
チーム形成を崩壊させる方策を逆説的に紹介している。
*自己防衛的な姿勢
部下の無能力から自分を守る。チームが結束するために部下を信頼すること。

*品質低減製品
製品を短時間で出荷するやり方は低品質になり、開発の誇りを失う

スカンクワーク
経営者が中止したプロジェクトを従業員が正しい判断で無視。部下は管理者が裃を脱ぐことを期待。自己防衛的な管理者は孤立する。

「優れたチームでは、～時に応じてリーダーシップを発揮し、誰もが恒久的なリーダーではない」
異分子が少し入っていると、結束したチームを作るのに大きな助けとなる。ハンデキャップや学生など。

第５部　きっとそこは楽しいところ
ブレーンストーミング、研修、旅行、学会、お祭り、冒険体験

「施設監査本部を見方にし、企業エントロピーと闘い、チーム殺し的な傾向を打破し、製品の品質をもっと重視し、パーキンソンの法則を無効にし、形式ばった作業規定をゆるめ、E係数を改善し、裃を脱ぐ」

第６部　ピープルウェアの小さな続編
第２版の追加分。
同僚の激しい競争は、仲間同士のコーチングを犠牲にする。
コーチングという行為は、自分たちが安全であると感じなければ、明らかに怒りえない。

CMM
順序づけられたキープロセスエリア(KPA)におけるスキルの熟達の度合いに基づいて５つのレベルに格付けされる。本書は否定的。
真に利益をもたらすプロジェクトは真のリスクを伴う。CMMを正当化する理由は、品質と生産性の向上にくわえ、リスクを低減すること。

人的資産(p261)
経費：使ってしまったお金
投資：資産を買うための別の資産
会社が社員に使うお金は経費で投資ではないが、投資と考えるべき。人員整理で給与と経費は削減できるが、人員に投下した投資分は失う。
「企業活動の目的は規模拡大であり、縮小ではない(p267)」。市場はリストラを歓迎するが、それは人への投資は経費の一部と考えているため。

組織学習
組織が学習能力をもてるかは、どこでやるかが重要。経営者は日々の業務を見ていない。末端は規則に縛られている。中間管理層の強力なリーダーシップが必要。

人月の神話

ソフトウェア開発、プロジェクト管理の古典でありバイブル。
本書の意義は、人月は指標として有用でない「神話」であること、ソフトウェア開発を劇的に進歩させる「銀の弾丸」のような方法がないことの２点を１９７０年代に予言したことにある。
また、ブルックスの法則がある。

遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせる

人月の神話

仕事の大きさを測る単位としての人月は、疑うべき神話なのだ(p14)

人と月は等価交換できない。スケジュールが遅れたからといって人を増員してもスケジュールは短くならないどころか教育などの負担増でより遅れる。

私は以下の目安を使用してソフトウェア開発のスケジュールに対応してきた(p17)
1/3　計画
1/6　コーディング
1/4　単体テストおよび初期システムテスト
1/4　すべてのコンポーネントを統合して行うシステムテスト

バベルの塔（大規模プロジェクト）

大規模プログラム開発プロジェクトにおけるコミュニケーション(p69)
プロジェクト手引書
正式なプロジェクトの手引書は最初から使用しなくてはならない。
プロジェクトで作成される文書はプロジェクト手引書の構成に従わなければならない。

大規模になる場合は文書を構造化して木構造にすること。必要に応じてサブツリーごとの配布リストができる。

製作主任が上司で、技術主任がその右腕となる場合(p75)
技術主任が時間を圧迫されることなく、技術的判断を下せる権限を確立してやることだ。

労力はプログラムサイズの累乗になることを示している。(p82)
労力(＝人月)＝(定数)×(命令数)＾1.5　

図では、500K行のプログラムが(500K)^1.5/(60*60*24)≒4000(人月)で計算されているみたい。

パイロットプラントと大規模化(p106)

たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物にならない。遅すぎたり、大き過ぎたり、使いにくかったりする。

試作して破棄する工程が必要と。

プログラムメンテナンスの基本的問題は、欠陥の修正が実質的には次の欠陥を生み出す可能性（２０～５０％）を秘めていることだ。(p111)

モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加する(p112)

修正を重ねるとシステムの整合性が悪くなって陳腐化する。

一回に追加するコンポーネントは一つだけにする(p138)

当たり前なことだがついつい背いてしまうという例。

パート図(p144)

クリティカルパスが明確なら、担当はそうならないようがんばるというお話。

フローチャートは、プログラム文書作成のうちでもまったく過大評価されてきたものの一つだ。(p155)
フローチャートはプログラムの判別構造を示すもので、構造の一面を示しているに過ぎない。

さらにプログラムと文書の二重管理は難しいので、ソースプログラムの中に文書を組み込むことを提案し、自己文書プログラムと呼んでいる。今ではdoxygenなどのツール一般的に使われていることと思うが、当時から言及されていたんですね。

銀の弾丸などない(p165)
ソフトウェア開発作業における本質的な部分として以下を提案している。

購入できるものをあえて構築しないようにするための大市場の利用
ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的(系統的)に成長させること
若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。

そして、当時から10年間で、技術、管理手法の両面で、生産性、信頼性、容易性を飛躍的に改善させる銀の弾は存在しないことを予言している。（そしてそれは予言どおりの結果になった。）銀の弾とは、民話の狼人間を魔法のように鎮めることができることから引用している。

ソフトウェア構築において困難な部分は、この概念構造体の使用作成とデザインおよびテストにあって、表現することやその表現に忠実かをテストすることではないと考えている。

数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出すが、ソフトウェアは複雑性が本質的な性質であることため、同様の方法を使えない（p169)

ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来する

ソフトウェアの場合、土地には地図、シリコンチップには回路図、コンピュータには結線図という具合に、幾何学的表現が整っているわけではない。

ソフトウェアの構造は複数の一般的な有効グラフで構成されていて、お互いに重なり合っているため、その構造を本質的に視覚化できていない。
そのため、グラフの結びつきを取り除き、ソフトウェアの構造を制限したり単純化したりすることで、複数の階層構造図になるように努力している。
強力な概念上のツールが必要。

銀の弾を期待して(p174)
銀の弾となる可能性があるものとして次をあげて評価している。
*Adaとその他の高水準言語の進歩
*オブジェクト指向プログラミング
*人工知能
*エキスパートシステム
*「自動」プログラミング
*ビジュアルプログラミング
*プログラム検証
*環境とツール
*ワークステーション

ソフトウェアパッケージの一般化(p185)
ソフトウェアのコストは開発コストのため、複数の利用者がｎ個のコピーを使用することで開発者の生産性がｎ倍になる。
ソフトウェアパッケージの一般化することで低価格化されると、給料支払システムのようなカスタマイズされたソフトウェアでも、自分の給料支払い方法の方をソフトウェアに会わせて使用するようになる。

インクリメンタル開発(p187)
ソフトウェア開発は建築要素のメタファーを有用に使ってきたが、概念構造体が複雑すぎて、根本的に異なるアプローチをとらなくてはならない。
インクリメンタル開発によって、まず動くように作られるべき。動くことでやる気を促す効果がある。


第17章(p193)
増訂版で追加された補足。約十年間で主張が間違っていないことを検証している。

大量の語彙を学習する(p212)

現在では大規模なライブラリをもった結果、プログラミング語彙が大きくなり、語彙習得が再利用を妨げる要因になっている。例として、メンバーが3000を超えるクラスライブラリで各々10～20のパラメータ、オプション変数が指定が必要とある。

*人々は文脈の中で学んでいくので、部品ライブラリだけではなく、構成した製品の実例をたくさん公表する必要がある。
*人々は綴り以外暗記しない。構文と語義は、文脈の中で使用しながら少しずつ学ばれていく。
*人々は構文クラスによって語構成規則をグループ化するのであって、互換性のあるオブジェクトのサブセットによるのではない。

第19章(p243)
二十周年記念版で追加。

多くの人間によってデザインされていながら、利用者という一人の頭脳からみたコンセプト上の統一がとられていなければならない。

アーキテクチャとインプリメンテーションの分離。一人を製品アーキテクトに任命するという主張を強めている。

（間違っててもよいから）利用者群を定義してその特性を推測して機能を絞り込むこと。あれもこれも機能を詰め込むと使いにくくなる(p250)

コンセプトの完全性を持った例としてWIMPインターフェースを上げている。（WIMP：ウィンドウ、アイコン、メニュー、ポインティングインターフェース）
実際の机と同じであるデスクトップメタファー。

ベームのモデルとデータ「ソフトウェア工学の経済学」(p265)

最初の出荷までのコスト最適スケジュール時間T
T=2.5×(人月)^(1/3)
月数で表した最適時間は、予想された人月労力の立方根に比例する
投入された要員の人数には関係なく、計算された最適スケジュールの3/4より短い時間内で成功したプロジェクトはほとんどない

ピープルウェア

「主要な問題は、本質的には技術的というより社会学的なものだ」

お勧めしている。