Google Web Toolkit

Google Developer Day 2008 Japan - Google Web Toolkit と AJAX

普段使っているJava IDEで開発、デバッグ、UnitTest可能。

デバッガの理論と実装

デバッガってどうやって動いているの？と聞かれて正しく答えられなかったので。

デバッガの理論と実装 (ASCII SOFTWARE SCIENCE Language) Jonathan B. Rosenberg 吉川 邦夫 アスキー 1998-02 売り上げランキング : 59943 Amazonで詳しく見る by G-Tools

琴線にふれたところ。

ソースコードが直接実行されているかのような錯覚を与えることにある。そうするためのトリックは、ソースコードに関して、また、それがどのように機械語命令にマップされているかについて、コンパイラに徹底したデバッグ情報を提供させることである。

Microsoftなどのベンダーは、デバイスドライバ開発者のために、OSを2種類提供している。その1つは市販のバージョンで、完全に最適化され、デバッグ用のシンボル情報を持たない。もう1つは、Microsoftが「チェックされた」ビルドと呼んでいるもので、最適化を外すかそのレベルを下げるかした、完全なデバッグシンボル付きのビルドであり、デバッグ中に詳細なスタックトレースや主要な変数の調査ができるようになっている。

ハードウェアによるデバッグサポート

• ブレークポイント
• シングルステップ実行
• 例外の検出
• ウォッチポイント
• マルチスレッドの制御
• マルチプロセッサの制御

シングルステップ実行

デバッガは、現在のプロラムカウンタの位置にある命令をデコードし、正確にその次の命令の位置にブレークポイントを設定し、デバッギを通常どおりに実行させることによって、シングルステップをシミュレートすることができる。

ウォッチポイント

プロセッサにベースとリミットのレジスタを持たせ、それらで開始アドレスと範囲を指定する方法である。こうすればプロセッサ自身が、このアドレス領域内でのデータの書き換えをストップし、その書込みが行われる前に実行を停止することができる。

Win32のデバッグAPI
フラグを立ててCreateProcess()または、既存プロセスにDebugActiveProcess()
各スレッドのレジスタ値はGetThreadContext()、状態変更はSetThreadContext()
ブレークポイントやコードのパッチはReadProcessMemory()、WriteProcessMemory()
デバッギの状態変化をWaitForDebugEvent()で待つ。

Adding a Google Translation Shortcut to Firefox

http://blogoscoped.com/archive/2008-12-09-n59.html

If you often translate bits and pieces using Google Translator, here’s one way to quickly access it:

英語→日本語の場合は
http://translate.google.com/translate_t#en%7Cja%7C%s
でよさそう。

Eric Sink on the Business of Software

Geek向けの起業指南本。

Eric Sink on the Business of Software (Expert's Voice) Eric Sink Apress 2006-03-27 売り上げランキング : 19952 Amazonで詳しく見る by G-Tools

訳本はこれみたい。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 青木 靖 翔泳社 2008-09-11 売り上げランキング : 3946 おすすめ平均 Amazonで詳しく見る by G-Tools

内容は著者のMSDNの連載をまとめたもので、著者のブログも引用されていました。
http://www.ericsink.com/
WHINING BY A BARREL OF ROCKS > The Importance of Barrel Research

業界をよく表現している。

Software niches are a bit different from traditional markets. Software generally does not respect geographic limitations, especially now that the Internet is everywhere. Products like concrete and lumber tend to be extremely regional, but a software niche might be global.

STARTING YOUR OWN COMPANY > Know Thyself

Myers-Briggs Type Indicator (MBTI)が紹介されていた。

One way to increase your self-awareness is to take a standard personality test. There are several such tests, but my favorite is the Myers-Briggs Type Indicator (MBTI).

http://www32.ocn.ne.jp/~emina/
私は「ＥＮＦＰ型：余計な苦労をかってでる」でした。
http://www32.ocn.ne.jp/~emina/typebox/enfp.html

コミュニケーションスキル
1.聞き手上手。80%は聞き役にまわる
2.e-mailを出す前に読み直す
3.e-mailは感情的になりやすいので落ち着いて書く

STARTING YOUR OWN COMPANY > Choose Your Product

ソフトウェア産業は成熟産業。horizontal marketsには大企業がいて勝負にならないから、vertical marketsで勝負せよ。(表計算が"industry leaders in bowling software,"で、「"industry leaders in bowling software,"」が"industry leaders in bowling software,")

STARTING YOUR OWN COMPANY > Make the Numbers Add Up

ISVのはじめ方。社員に40時間アルバイトさせて残りの40時間で本来の製品を開発する。

実際に、自分でISV立ち上げの実験してみた記録が興味深い。(Winnable Solitaire experiment)

Joel on Software

ジョエルテストが有名。今の開発現場では当たり前かもしれません

ジョエルテスト
1.ソース管理してる？
2.ワンステップでビルドできる？
3.デイリービルドしてる？
4.バグデータベースはある？
5.新しいコードを書く前にバグを直してる？
6.アップデートされているスケジュールがある？
7.仕様書はある？
8.プログラマは静かな環境で作業している？
9.手に入る最高のツールを使っている？
10.テスタはいる？
11.採用面接のときにコードを欠かせてる？
12.ユーザビリティテストはしてる？

9.やさしいソフトウェアスケジュール

5.タスクの粒度を細かくすること

タスクは、日単位ではなく、時間単位で計測すべきである。

面倒くさがって大きな塊のタスクを選択した場合、何をすることになるのか実際には考えていないだろう。

9.スケジュールにデバッグの時間を入れる！

たぶん、最初にコードを書くのにかかった時間の100%から200%の時間をデバッグで使ったことだろう。

データを収集する
短くて要点をついた自動クラッシュレポートダイアログを表示させる。
私たちが自動的に収集しているデータ
*製品の正確なバージョン
*OSのバージョンとInternet Explorerのバージョン
*クラッシュが起きたコードのファイルと行番号
*エラーメッセージの文字列
*そのタイプのエラーに固有の数値コード
*ユーザが何をしていたかについてのユーザの記述
*ユーザのe-mailアドレス

Win32 APIの構造化例外処理(UnhandledExceptionFilter)

ソフトウェア見積り

!!第1章　見積もりとは
!見積もり、ターゲット、コミットメント(p4)
見積もりとコミットメントは同じではない。
:見積もり:プロジェクトにかかる期間やコストを予測すること
:ターゲット:実現したいビジネス上の目標を明文化したもの
:コミットメント:定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束

!確率論としての見積もり(p7)
""

パーセント角度とシングルポイントの見積もりの値とを併用して、「24週間のスケジュールで完了する確度は90%のように用いる

!「良い」見積もりの実務的な定義(p15)
""

良い見積もりとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積もりである。

!!第3章　正確な見積もりの価値

!パーキンソンの法則(p24)
作業は使用可能な時間を使い尽くすまで拡大する

!過大見積りと過小見積もり(p27)
過大見積りはパーキンソンの法則に起因する直線的な不利益（工数、コスト、スケジュール増）だが、過小見積もりの不利益は直接的でなく限界がないので深刻。

!ソフトウェア業界の構造的な問題(p30)
業界のデータから、ソフトウェア業界には過小見積もりの問題がある。

!正確な見積もりの利点(p31)
*状況の可視化が進む
*品質が向上する
*ソフトウェア以外の業務部門との連携が良くなる
*予算が良くなる
*開発チームに対する信頼が向上する
*早期にリスク情報が得られる

!予測可能性の価値(p33)
経営陣はコスト、スケジュール、機能を知りたい。
実現する機能を数パターン検討してコミットできるスケジュールのばらつきを比較できるように図示することで、ばらつきの少ない選択肢を承認してもらいやすい。

!!第4章見積もり誤差はなぜ起きる？

!不確実性のコーン(p40)
プロジェクトスコープ（工数、コスト、機能）の見積もりにおけるばらつき（最大見積もりと最小見積もりの区間）は、初期コンセプト、製品定義の承認、要求の完了、ユーザーインターフェース設計の完了、詳細設計の完了、ソフトウェアの完了と時期でばらつきが狭まってコーンの形を作る。

プロジェクトからバラつきの原因を取り除いてコーンを狭くしよう。

!不確実性のコーンとコミットメントの関係(p45)
見積もり誤差が２０％以内であればプロジェクトを完了に向けてナビゲートできる。コーンが初期の広い部分では、有意義なコミットメントは不可能。コーンを狭くする作業を終えるまでコミットメントを遅らせる。

!不安定な要求(p47)
要求が安定しない場合は不確実性のコーンは狭くならない。要求変更はトラッキングされないことが多く、再見積もりすべきなのにされない。要求が安定できない状況では反復型、スクラム、XP、DSDMなどの開発手法を検討する。

!アクティビティの見落とし(p49)
*セットアップ/インストールプログラム
*データ変換ユーティリティ
*サードパーティやオープンソースソフトウェアを使うためのグルーコード
*ヘルプシステム
*配置モード
*外部システムとのインターフェース

!!第6章　見積もり技法入門

!プロジェクトの規模(p85)
:小規模:5人以下。実際に作業を行うここのメンバーが作成する見積もりを元にプロジェクトの見積もりを作成するボトムアップ技法が最適。
:大規模:半年から一年以上継続する25人以上。初期はトップダウン技法、中期以降は組み合わせ。
:中規模:5人から25人。

!!第7章　数えて、計算して、判断する
見積もりの基本は数えること。数えられない場合は計算する。それもできないときのみ判断する。

!何を数えるか？(p91)
p93表7-1に以下の数えたデータの使用例がある。この表のデータを収集することで、過去のデータとして工数の見積もりなどの計算に使うことができる。
*初期
**マーケティング要求
**機能
**ユースケース
**ストーリー
*中期
**エンジニアリング要求
**ファンクションポイント
**変更要求
**Webページ
**レポート
**ダイアログボックス
**スクリーン
**データベーステーブル
*後期
**書きあがったコード
**欠陥指摘数
**クラス
**クラスタ

*見積もり対象のソフトウェアの規模と関連性が高いものを探す
*開発サイクルの早い時期に手に入るものを探す
*統計的に意味のある（数が大きいもの）平均値を出せるものを探す
*何を数えているのか理解する
*最小の労力で数えられるものを探す

!!第8章　補正と過去のデータ

!収集するデータ(p101)
*規模（コード行数など）
*工数（人月）
*時間（カレンダー月）
*欠陥（重要度によって分類されたもの）

!規模の測定方法を決める必要がある
*コードの数え方（リリースコードだけかどうかなど
*再利用コードの扱い
*ブランク行、コメント行
*クラスインターフェイスを数えるか
*データ宣言

!工数の測定方法を決める必要がある
*時間の単位
*1日何時間か？
*サービス残業を数えるか
*休日、休暇、ミーティング
*どんな種類の工数を数えるのか（要求、設計、調査、
*複数のプロジェクトの数え方
*過去のリリースのサポート時間
*展示会などのサポート時間
*移動時間
*下準備のあいまいな時間、

!プロジェクトが終わったらできるだけ早くプロジェクトの過去のデータを収集する
進行中にも収集する。規模と工数と欠陥について１～２週間ごとにデータを収集すると有益。

イノベーションと競争優位

「優れた産業技術を開発し、それを装備した製品をいち早く市場に出しても、イノベーターの競争優位と利益の獲得につながらない、あるいは獲得したはずの利益が継続しないことが多い。」
この問題について薄型テレビ、DVDプレイヤー、HDD、携帯電話、デジカメなどのデジタル機器の競争と戦略を議論している。


本書の目的は、「イノベーションを利益に結びつけ企業成長につなげるという課題解決のための方策を明らかにする」こと。

原因は、（１）経済全体のグローバル化、（２）製品アーキテクチャが摺り合わせ型からモジュラー型への変化、（３）企業ドメインが日本企業の統合型ドメインからデルのような特化型ドメインのように多様化していることによる。

それらにより、製品がコモディティ化して価値獲得に失敗している。

!!付加価値創造(p16)
ものづくりを付加価値や利益に結びつけるには、価値創造と価値獲得の視点が必要。

!価値創造
技術的イノベーションで顧客価値の高い商品を創造。
価値創造プロセスで高品質、低コスト、スピードを実現する。

!!製品アーキテクチャ
デジタル商品がモジュラー化して過当競争が起きている。
自動車は、日本企業が得意なインテグラル型で摺り合わせに高い技術が必要なため強い。
一方、PCやDVDなどは製品アーキテクチャがモジュラー化されているため他国企業に勝てない。要因としては、コスト、グローバルな仕組みづくり、プラットフォームリーダーになれないこと。

!!コモディティ化(p24)
コモディティ化の定義「参入企業が増加し、商品の差別化が困難になり、価格競争の結果、企業が利益を上げられないほどに価格低下すること」
モジュラー化はコモディティ化を促進する。

!!日本企業の価値獲得戦略

モジュールでの価値獲得とは部品やモジュールでもうけること。継続して利益を得るにはプラットフォームリーダーになることが重要。

アセンブルでの価値獲得は、中国で製造してもコスト優位性で競争するのは難しい。
デルはグローバルサプライデマンドチェーンを構築して成功しているが日本企業の成功例はない。
機能的価値でなく意味的価値により大きな付加価値を有む。iPodなど。

よって、モジュールとアッセンブルの組み合わせが有力。独自性の高いモジュールを高度に摺り合わせて付加価値の高い製品を創出。

商品ライフサイクルの最初は摺り合わせ戦略が有効だが、モジュラー化していき利益やシェアが減っていく。

!!統合型企業のジレンマ
完成品メーカーがキーデバイスを重視しそれを内製化するのは勝利の方程式だが、部品生産の利益を上げると社内需要の規模を上回るため、外販する必要があり、モジュラー化、コモディティ化するというジレンマがある。

!!松下のPDP
垂直統合型。グローバルウィナーを目指す戦略。価格競争にも勝つ。

!!デルのBTO
デルはコモディティ化を積極活用している。SGA（原価以外の費用）は１０％以下。日本企業は３０％程度。また、キャッシュフローを重視。部品コストの低下をリアルタイムに取り込んで製品価格を下げる。利益が大きくなりすぎたら価格を下げてコモディティ化を促進。

!!光ディスク
技術流出でなく、積極的に技術移転を行って自らコントロールして協業する。

!!中国やアジア地域の海外投資
低賃金労働力の利用ではなく、本国では到達できない量産規模を海外で達成させ、確実にスケールメリットを獲得すること。

!!サムスン、LG
日本の技術を後追いして投資競争で勝ったわけでなく、学会発表件数などで逆転していた。

オブジェクト開発の神髄

最先端のソフトウェア開発
最先端のソフトウェア開発として以下について概説している。
!最新の開発技術
以下の技術について長所と短所を評価している。
*オブジェクト指向
*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より短い時間内で成功したプロジェクトはほとんどない

ピープルウェア

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

お勧めしている。