『ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード』
https://images-na.ssl-images-amazon.com/images/I/51H3S4SVHZL.jpg
ソフトウェア職人気質はソフトウェア工学の代替ではなく、それを補完するものです。ソフトウェア工学は、航空管制システムのような、巨大で何年もかかるシステム開発プロジェクトが引き起こす問題を解決するために作られたものです。ソフトウェア職人気質では、それよりも小規模なアプリケーションを開発する上で必要だったのは、数人の優れた開発者にアプリケーションを構築させるということだけであったと認識しています。そして、ソフトウェア工学をより規模の小さいプロジェクトに適用することは、職人気質のアプローチをより規模の大きいプロジェクトに適用することと同様に難しく、かつ不適切であると言えるのです。
（p.105）
『Clean Agile 基本に立ち戻れ』で、アジャイルは小さなチームでうまくやるための方法であって、大規模プロジェクトについてはソフトウェア開発以外の分野で培われてきた知見を使えばいいという話をしていたのと相似しているように感じる。koma.icon 本書は武装命令なのです。自分たちのために、もしくは自分たちとともにシステムを構築する場合、開発者を信頼する前に、彼らが自身の技芸を熟知するように声を大にして要求しなければならないのです。
（p.35）
人は、個人的な推薦によって職人を選びます。こういった点でも、ソフトウェア職人気質はソフトウェア工学の対極にあると言えるでしょう。つまり、法人の認定制度や資格制度によって開発者を選ぶのではなく、固有の能力と長所を持った各個人によって開発者を選ぶのです。
（p.37）
ある開発者が他の開発者を推薦する場合、彼は自身の名声を賭けてそれを述べているのです。どこかの団体が「この開発者は認定試験に合格しました」と言うのとは、まったくシナリオが違っているわけです。認定団体は、何も賭けていないのです。
個人的な形態を用いることで、ソフトウェア職人気質は推薦が軽い気持ちで行われないことを約束するわけです。こういった1対1の推薦によって、関係者すべてが常により良い開発者になるよう、向上を目指すことにつながるのです。
（p.38）
経験豊富な優れた開発者をチームに配属したのであれば、この問題の大半をすでに解決したことになります。後は、チームのメンバに対して毎週、通常作業を離れて何かを学習する時間をいくらか与えてください。毎週、週の半ばの1〜2時間を割いて、何らかの形で現在のアプリケーションに役立てることができる、ソフトウェア開発のスキルを向上させるアイディアを試すよう、開発者に告げるのです。
目次
まえがきxiii
訳者まえがきxvii
第1 部ソフトウェア工学に対する疑問1
第1 章ソフトウェア工学とは？ 3
1.1 ソフトウェア工学のパラドックス. . . . . . . . . . . . . . . . 4
1.2 現代におけるソフトウェア工学の定義. . . . . . . . . . . . . . 6
1.3 ソフトウェア工学は，あなたのプロジェクトに向いているか？. 8
第2 章ソフトウェア工学の問題9
2.1 ソフトウェア開発は体系化かつ定量化することが可能なのか？. 11
2.2 十分によいソフトウェアというアプローチの落とし穴. . . . . 13
2.3 ソフトウェア工学に代わるものとは？ . . . . . . . . . . . . . . 14
第3 章ソフトウェア開発を理解する17
3.1 資本としてのソフトウェア. . . . . . . . . . . . . . . . . . . . 18
3.2 ソフトウェア開発において作業の分担は有効なのか？ . . . . . 20
3.3 何にでもフィットするようなフリーサイズは存在しない. . . . 21
3.4 ソフトウェア工学よりも適用可能性のあるメタファを探る. . . 23
第4 章ソフトウェア工学よりも優れたメタファを探る25
4.1 ソフトウェア開発における技芸. . . . . . . . . . . . . . . . . 26
4.2 伝統的な職人気質との類似点. . . . . . . . . . . . . . . . . . 28
4.3 ソフトウェア開発における技芸の復権. . . . . . . . . . . . . . 28
第2 部ソフトウェア職人気質31
第5 章ソフトウェア開発に人を呼び戻す33
5.1 職人気質はソフトウェア開発を改善するものである. . . . . . . 34
5.2 職人気質によって優れたソフトウェアの記述が開発者に奨励さ
れる. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 武装命令. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
第6 章資格制度の対極に位置する職人気質37
6.1 個人に基づく職人気質. . . . . . . . . . . . . . . . . . . . . . 37
6.2 資格制度は幻想である. . . . . . . . . . . . . . . . . . . . . . 38
6.3 個人に着目した職人気質. . . . . . . . . . . . . . . . . . . . . 41
第3 部ソフトウェア職人気質がもたらすもの45
第7 章職人気質がシステムのユーザにもたらす変化47
7.1 ソフトウェアは簡単にコピーできるため，ソフトウェア職人気
質が有効に機能する. . . . . . . . . . . . . . . . . . . . . . . 48
7.2 職人とユーザの関係. . . . . . . . . . . . . . . . . . . . . . . 50
7.3 素晴らしいソフトウェアには署名がある. . . . . . . . . . . . . 52
7.4 職人には注文の多いユーザが必要である. . . . . . . . . . . . . 53
7.5 ソフトウェア職人気質によって共同開発がもたらされる. . . . 54
第8 章顧客と職人の関係55
8.1 現実的なリリース日の設定. . . . . . . . . . . . . . . . . . . . 55
8.2 十分によいソフトウェアの虚偽を暴く. . . . . . . . . . . . . . 56
8.3 ソフトウェア職人に，自身の仕事に対するクレジットを与える. 59
8.4 開発者間の生産性の違いを利用し始めること. . . . . . . . . . 59
8.5 しかし，どのようにしたら開発者が本当に優れているかどうか
を判断できるのか？ . . . . . . . . . . . . . . . . . . . . . . . 61
8.6 顧客は職人選定時にコストと品質のトレード・オフを行う. . . 63
8.7 顧客とソフトウェア職人の関係は長期に渡るものとなる. . . . 65
8.8 顧客の利益はソフトウェア職人の利益と一致する. . . . . . . . 67
第9 章職人の管理69
9.1 ソフトウェア職人は下働きではない. . . . . . . . . . . . . . . 70
9.2 優れた開発者は管理者よりも価値が高い. . . . . . . . . . . . . 70
9.3 ソフトウェア職人と管理者の関係. . . . . . . . . . . . . . . . 71
9.4 優れた開発者を管理することは喜びであり特権である. . . . . 72
9.5 ソフトウェア職人はアプリケーション作りが嫌いではない. . . 73
9.6 ソフトウェア職人の管理は異なったものとなる. . . . . . . . . 75
9.7 ソフトウェア職人は，自らが必要なものを得ようと努める. . . 76
第10 章ソフトウェア職人になる77
10.1 ソフトウェア職人気質は，極端な役割分担を否定する. . . . . 77
10.2 職人気質には献身が必要. . . . . . . . . . . . . . . . . . . . . 79
10.3 ソフトウェア職人になるには？ . . . . . . . . . . . . . . . . . 79
10.4 伝統的な技芸は何世紀も生き続けてきた. . . . . . . . . . . . . 81
第11 章技芸の熟達83
11.1 ソフトウェアの熟練職人とはどのようなものか？ . . . . . . . . 83
11.2 古株の採用. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.3 技芸の熟達とは安定したテクノロジの使用を意味している. . . 85
11.4 技芸の熟達には時間がかかる. . . . . . . . . . . . . . . . . . 87
11.5 熟達は技芸の伝承に対して責任を持つことを意味している. . . 88
第12 章アプレンティス89
12.1 開発者教育における品質の低下を打開する. . . . . . . . . . . 89
12.2 アプレンティスになるのは重大なステップである. . . . . . . . 93
12.3 徒弟制度は生涯学習を根付かせる. . . . . . . . . . . . . . . . 95
12.4 アプレンティスの役割. . . . . . . . . . . . . . . . . . . . . . 96
12.5 徒弟制度は時間と努力に対する有意義な投資である. . . . . . . 99
第13 章ジャーニーマン101
13.1 技芸におけるジャーニーマンの位置づけ. . . . . . . . . . . . . 102
13.2 ジャーニーマン開発者. . . . . . . . . . . . . . . . . . . . . . 102
13.3 ジャーニーマンはアプリケーションの調達に注力する. . . . . 103
13.4 ジャーニーマンはソフトウェア職人気質の重要な役割を担って
いる. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
第4 部ソフトウェア工学の位置づけを再評価する105
第14 章ソフトウェア工学に則ったプロジェクト107
14.1 ソフトウェア工学は巨大システム・プロジェクトに対して用意
されたものである. . . . . . . . . . . . . . . . . . . . . . . . 108
14.2 ソフトウェア工学に則ったプロジェクトは多種多様で変化に富
んでいる. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
第15 章ソフトウェア工学メタファの危険性113
15.1 低予算でソフトウェア工学を実行することはできない. . . . . 113
15.2 ソフトウェア工学は科学的管理法を奨励している. . . . . . . . 115
15.3 ソフトウェア工場：ソフトウェアの流れ作業. . . . . . . . . . 117
15.4 長期の再利用は危険である. . . . . . . . . . . . . . . . . . . . 118
15.5 ソフトウェア開発の標準プロセスという神話. . . . . . . . . . 119
15.6 ソフトウェア工学は個人というものを忘れさせる. . . . . . . . 122
15.7 開発プロセスに必要なものは統合化ではなく，多様化である. . 124
第16 章ソフトウェア工学からの教訓127
16.1 規模と複雑さが重要となる. . . . . . . . . . . . . . . . . . . . 127
16.2 アプリケーションはうまく構造化する必要がある. . . . . . . . 129
16.3 余裕のない変更は高価なものとなる. . . . . . . . . . . . . . . 129
16.4 チーム内，およびユーザとのコミュニケーションの重要性. . . 131
16.5 正確な見積もりはとても高くつく. . . . . . . . . . . . . . . . 132
第5 部土壇場になって行うこと135
第17 章経験?プロジェクトを成功させる秘訣137
17.1 ソフトウェア職人を評判に基づいて選ぶ. . . . . . . . . . . . . 137
17.2 職人を評判とポートフォリオで評価する. . . . . . . . . . . . . 139
17.3 ソフトウェア職人の選定. . . . . . . . . . . . . . . . . . . . . 140
17.4 ソフトウェア職人に開発チームの他のメンバを選定させる. . . 141
17.5 共同開発. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
17.6 最先端のテクノロジはできる限り避ける. . . . . . . . . . . . . 144
17.7 経験に対して支払う. . . . . . . . . . . . . . . . . . . . . . . 145
17.8 驚くべき成果. . . . . . . . . . . . . . . . . . . . . . . . . . . 148
第18 章テストと保守のための設計151
18.1 プロジェクトではなく，アプリケーションのことを考える. . . 151
18.2 保守チームは粗悪なアプリケーションの受け取りを拒否すべき
である. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.3 保守のための設計. . . . . . . . . . . . . . . . . . . . . . . . 154
18.4 ソフトウェア職人気質は独占されていないオープンソース・ツー
ルを好む. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
18.5 優れたソフトウェアはグローバル対応している. . . . . . . . . 158
18.6 ソフトウェア職人は計画的陳腐化と戦う必要がある. . . . . . . 159
18.7 優れたソフトウェアには優れたユーザ・インタフェースが必要
である. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.8 保守可能なソフトウェアは簡単に診断できる. . . . . . . . . . 161
18.9 アウトソーシングの危険性. . . . . . . . . . . . . . . . . . . . 162
18.10 アプリケーションを構築する際に外部の職人を用いる. . . . . 164
18.11 保守はアプリケーションの寿命を支える最重要部分である. . . 164
18.12 すべてのソフトウェアが保守可能である必要はない. . . . . . . 166
18.13 テストと保守のための設計はロケット工学ではない. . . . . . . 166
第19 章永続的な学習169
19.1 学習環境を作り上げる. . . . . . . . . . . . . . . . . . . . . . 169
19.2 ソフトウェア開発における技芸の熟達. . . . . . . . . . . . . . 171
19.3 訓練コースは細心の注意を払って選択すること. . . . . . . . . 172
19.4 ソフトウェア開発コミュニティ内で目立つことを奨励する. . . 174
19.5 内省的な実践者になる. . . . . . . . . . . . . . . . . . . . . . 175
エピローグ177
謝辞179
索引181
hr.icon