- ホーム
- > 和書
- > コンピュータ
- > プログラミング
- > ＳＥ自己啓発・読み物
出版社内容情報
本書推薦の言葉（David Thomas 『達人プログラマー翼Vステム開発の職人から名匠への道』（ピアソ
ン・エデュケーション）の著者の1 人）
本書は難しい問題を私たちに問いかけています。
ソフトウェア工学というものは，100 人年（1,200 人月）未満のプロジェクト
に対しても有効なのでしょうか？ また，ソフトウェア工学という言葉が潜在的
に持っている意味は、正しいものなのでしょうか？ そもそも，ソフトウェア開
発を工学といった用語で表現して良いものなのでしょうか？
さらに，本書は非常に微妙な問題も問いかけています： 経験の浅い開発者に
対する報酬は多すぎるのでしょうか？ また，経験豊富な開発者には社内で並ぶ
者がいないくらいの報酬を支払うべきなのでしょうか？ 長期に渡るプロジェク
トで，市場に出て10 年未満のツールを採用しても良いのでしょうか？
そして，核心を突く最大の疑問を，本書は投げかけています： ソフトウェア
開発を成功へと導くプロセスを作り出すには，どのようにすれば良いのでしょ
うか？
本書には，賛否両論を呼ぶ答えが提示されています： そのことはつまり，私
たちが単純な真実を見失っているということを意味しているのではないでしょう
か？ ソフトウェアというものは，素晴らしい方法論や形式的な構造で作られる
のではなく，「人」によって作り出されるのです。つまり，増え続けるソフトウェ
ア開発の危機を回避するには，より優れた開発者を育てるところから始めなけれ
ばならないわけです。これを達成するため，Pete は数百年に渡ってうまく機能
してきたシステム-つまり職人気質に則った制度に目を付けているのです。
「職人気質」には，高品質な製品を表すブランド以上の意味が秘められている
のです。この言葉が持つ完全な意味に従えば，「職人気質に則った制度とは，過
去の成果によってのみ自らの地位が決められ，マスター（親方）によって仕切ら
れる，後継者育成の場を形成する自律的なシステム」のことを指します。アプレ
ンティス（弟子），ジャーニーマン（一般職人），熟練職人が互いに学び合いなが
ら，チーム一丸となって作業を行うのです。このため，顧客はチームの評判を基
にしてチーム選定を行い，チームは自身の評判を高める作業のみを引き受けこと
になるわけです。
こういった職人気質を完全にシステム化して，私たちの業界で機能させること
ができるのでしょうか？ 正直なところ私には判りません。この考え方は，多く
の保守的な利害関係と対立するからです。しかし，私はこういった徒弟制度がう
まく機能することを知っています。実際に私自身が体験したのですから。
私は幸運にも素晴らしい大学に入学し，多くの理論を学ぶことができました
（その当時までは，あまり理論を知らなかったのです）。しかし，私の経歴を本当
に輝かしいものにしてくれたのは，徒弟制度の体験だったのです。私は，ある卒
業生のもとに師事しました。彼が手取り足取り教えてくれることはありませんで
したが，優れたプログラマがどのように考えるのかということを実地に示してく
れたのです。彼の横で何ヶ月も作業することによって，どんな講義でも学ぶこと
のできない，設計，コーディング，デバッグについての実践的な知識を吸収する
ことができたわけです。
その後，私はロンドンで新規事業に加わり，新たな徒弟制度を体験しました。
新しい師匠は，ソフトウェア開発というものがテクノロジとの付き合いであると
同時に，人との付き合いでもあるということを示してくれました。彼は，開発に
おけるビジネス面を理解する上で必要な手を差し伸べてくれ，技術的な強みを核
にした素晴らしい開発によって，どのように人間関係が構築されるかということ
を教えてくれました。
こういった2 つの異なった徒弟制度を「卒業」することにより，私はずっと優
れた開発者になることができたのです。そして，こういった個人的経験に基づ
き，私は徒弟制度を信奉しているわけです。技芸を学ぶには，師匠とともに作業
することが一番なのです。
本書では，次世代の開発者を育成するためのアイディアのみが提供されている
わけではありません。本書は哲学についても論じているのです。職人気質は，あ
なた個人の持つ3 つの責任，すなわち，あなたの作業責任，あなた個人の向上
責任，あなたのプロ意識に対する責任というものも象徴しています。あなたの用
いているソフトウェア開発手法が何であろうと関係ありません。つまり，CMM
レベル51の仕事場で残業無しの開発を行っているか，100 時間残業でカフェイ
ン漬けになってクールなシューティング・ゲームを作っているかは関係ないの
です。また，ラショナル統一プロセス（RUP），エクストリーム・プログラミン
グ（XP），SCRUM を使っているか，あるいは開発手法というものをまったく
用いていなくとも関係ないのです。作業体制がどうであれ，熟練した開発者が適
切で品質の高いコードを記述し，顧客が必要とするものを調達できれば，ソフト
ウェア開発の真価というものは増すわけです。そして，こういった熟練した開発
者は，方法論によって作り出されるわけではありません。職人気質を尊び，実践
し，本書で紹介されているその他のアイディアを用いることによって，こういっ
た人材育成への道が拓けるのです。Pete McBreen 氏の難問に時間を費やすこと
で，あなた自身とあなたの経歴にも磨きがかかることでしょう。
David Thomas
The Pragmatic Programmers
まえがき
職人気質とは，ソフトウェア開発における基本への回帰とも言えるものです：
優れたソフトウェア開発者は，プログラミングというものが熟練の必要な技芸で
あることを常に理解しています。技術者が持っている神秘的かつ詳細な技術的知
識の量とは関係なく，アプリケーション開発は最後には経験と勘の世界になるの
です。プログラミング言語Java の奥義に達する詳細な技術をすべて知っている
ような技術者であっても，ソフトウェアの芸術性に対する感覚が養われていなけ
れば，アプリケーション開発をマスターすることなどできないのです。逆の言い
方をすれば，いったんソフトウェア開発の感覚が養われれば，特定の技術に対す
る詳細知識の有無などほとんど関係ないわけです。とはいうものの，優れた開発
者は常に新たなテクノロジと技術を入手し，それを使用しています。新たなテク
ノロジの学習は，ソフトウェア開発者の日課となっているのです。
「ソフトウェア工学」（Software Engineering）という言葉は，NATO の「ソフ
トウェアにおける問題」に関する協議会の設立を提唱した研究グループによって
1967 年に作り出されました。そして，1968 年にガーミッシュで行われたNATO
科学委員会主催の協議会では，“Software Engineering” という表題の報告書が
作成されています1。その報告書中で，Peter Naur とBrian Randell は，「工学
分野で伝統的に確立されてきたような，理論的基礎と実践的な規律様式に基づい
たソフトウェア製造の必要性をほのめかすため，意図的に『ソフトウェア工学』
という挑発的な表現を選択した」と述べています。
本書でも同じ精神に則り，ソフトウェア開発の技芸を実践する者が注意を払わ
なければならないことをほのめかすため，意図的に挑発的な表現を選択していま
す。ソフトウェア職人気質という言葉は，ソフトウェア工学という言葉によって
ソフトウェア開発者が想起し，追求し続けた工業品製造のメタファを払拭するた
めの重要なキーワードなのです。職人気質という言葉によって，自らの技芸修得
に熱心で，自らの作業成果に対する誇りと責任を持った熟練開発者というメタ
ファがもたらされるわけです。
ソフトウェア職人気質は，ソフトウェア工学やコンピュータ科学と対極に位置
するものではありません。むしろ職人気質は，科学や工学からの恩恵を受けなが
ら，これらとうまく共存することができるのです。近代的な鍛冶屋が，優れた道
具，材料，技術の理解による恩恵を受けてきたのと同様に，ソフトウェア職人気
質は，優れたコンピュータ，再利用可能なコンポーネント，プログラミング言語
からの恩恵を受けるのです。また鍛冶屋が，熟練と技芸によって科学や工学を超
越してきたのと同様に，ソフトウェア職人気質は，コンピュータ科学やソフト
ウェア工学を超越した優れたプログラム，アプリケーション，システムを作り出
すことができるのです。UNIX や最近のGNU Linux は，作り手の技芸，熟練，
献身によって繁栄しているシステムの最も有名な例と言えるでしょう。
ソフトウェア職人気質とは，商用アプリケーションの開発に対して，無理矢理
ソフトウェア工学を適用することから生まれる数々の問題に対する解答なので
す。そもそもソフトウェア工学は，NATO の大規模防衛システムを開発する必
要性から作り出されたものです。ところが商用アプリケーションの開発というも
のは，防衛システムや政府システムの開発と比べると，ずっとアプリケーション
の規模が小さく，納期も多くの場合は18 ヶ月未満という別種のものなのです。
商用アプリケーションの開発では，20 人以上のチームが編成されることはまれ
であり，ほとんどの場合，10 人未満のチームで作業が行われます。そしてソフ
トウェア工学は，200 人以上のチームが必要となるような巨大な開発を扱う場合
に実力を発揮するものであり，個人がチーム内で自らの技芸を磨く手段について
はほとんど何も述べていないのです。
ソフトウェア工学は，ソフトウェア開発に対して「人海戦術」2的なアプローチ
を奨励しています。ソフトウェア工学は，熟練開発者の育成という問題を解決す
るのではなく，すべての問題を要員の投入によって解決できるようにすること
で，ソフトウェア開発の単純化を図ろうとしているのです。
こういったアプローチが成功することもありますが，成果物であるソフトウェ
アは，「がらくた」になってしまうのです。つまり，遅く，巨大で，気持ち良く稼
働しないものができあがるわけです。ユーザは，グラフィックスやアニメーショ
ンに感嘆しますが，こういったソフトウェアを使いこなせるようにはなりませ
ん。ユーザはソフトウェアの学習を行うこともできず，利用可能な一部の機能の
みを使うことになるわけです。
ソフトウェアが，そのようである必然性はないのです。
アプリケーション開発チームが，ビジネス上で計り知れないほどの利益を生み
出せる，価値あるアプリケーションをリリースしました。しかし，ソフトウェア
工学のベスト・プラクティスをうまく適用しなかったというだけの理由で謝罪を
要求されるのです。こういった事例を，私は何度も見てきました。チームに対す
る本当の評価とは，うまくリリースできるかどうかという点と，その後何年にも
渡ってアプリケーションの拡張，保守が可能であるかどうかという点であるはず
です。初期リリースがタイムリーに行えるかどうかは重要ですが，より重要なの
は以降のリリースがタイムリーに行え，それぞれの新リリースでアプリケーショ
ンを改善できるかどうかなのです。
開発者を雇う場合における私の基準は，いくつかのアプリケーションをうまく
リリースした実績があり，その後，改良版や保守版のリリースを行えるだけの十
分な期間，そのアプリケーションの保守を行った開発者を探すというものです。
初期リリースを行った実績によって，その開発者には動作可能な成果物を作成で
きる能力のあることが証明できます。そして，その後のリリースまで留まってい
たという実績によって，開発者が最初に作り上げたアプリケーションの有効性を
自身で検証したことが判るのです。こういった経験が3 回もあれば，その開発
者には次回の成功をもたらす，ソフトウェア開発という技芸に必要な熟練と経験
が，十分に備わっていると判断できるでしょう。
ソフトウェア開発コミュニティにおいては，多くの人々が利益追求のため，テ
クノロジへの追随に明け暮れ，本当に重要なものを見失っている現状がありま
す。このような状況を考えた場合，ソフトウェア職人気質は新たな必須の条件と
なるはずです。ソフトウェア開発の目的は，ユーザに対して利益をもたらす，高
品質で堅牢なソフトウェア・アプリケーションを調達することです。そして重要
なのは，そういったことを実行に移せる開発者を新たに育成することなのです。
ソフトウェア職人気質によって，ユーザのためのアプリケーション構築が，楽
しく，刺激的なものになるのです。
【ソフトウェアの職人気質】
目次
本書推薦の言葉ix
まえがき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
目次
ソフトウェア職人気質
ソフトウェア職人気質がもたらすもの
ソフトウェア工学の位置づけを再評価する
土壇場になって行うこと〔ほか〕
