私は、ソフトウェア開発の仕事とは何か？という点について、「プログラミング技術を活用した問題解決の仕事」と考えています。その仕事には再現性はなく、画一的なプロセスを定義するよりも、個人の力を発揮しやすくすることに腐心するマネジメントを心がけています。そうした仕事は、職人の仕事だと常々語ってきました。
本書は、2002年に翻訳された書籍で、既に新書としては手に入れることの出来なくなってしまった本ですが、そこに書かれていることは、まさにソフトウェアの本質を見抜き、ソフトウェア開発をソフトウェア職人気質（Software Craftmanship）として再定義しています。久しぶりに読んでみたのですが、今、改めて読んでも通用する話ばかりだと感じました。
目次
ソフトウェア開発の正体
ソフトウェア開発は、工学（エンジニアリング）なのでしょうか、それとも、技芸（アート）なのでしょうか。多くのソフトウェア企業において、経営者はソフトウェア開発に工学を求めてきました。果たして、それは正しかったのでしょうか。本書が出てから10年以上が経った今も多くの現場で問題が起きている現状を見るに、それは正しかったとは言いがたいと思わざるを得ません。
本書では、ソフトウェア開発の本質は、効率的なシステム調達を目的とした、芸術、科学、工学の創造的な調和である、と述べています。こうした考えかたを語るためのメタファとして、「ソフトウェア職人気質」を使うというアイデアを披露しています。
その考えの背景にあるのが「ソフトウェアに対するすべての要件は、人から出てくるもの」という考えです。ソフトウェア開発では、プロセスを定義することは出来ないし、反復可能ではない、つまり再現性がないと考えているのです。そうした場合に、工学としてのアプローチだけでは解決できないのです。
ソフトウェア職人気質で求められるのは、技芸としての美術的および芸術的な観点になります。作られるソフトウェアのために重要なのはプロセスではなく、それを実現する人である、という考えかたに基づくのが職人気質の考えかたです。だからといって、すべてを人が行う訳ではないのです。道具や環境は、日々進化していくものです。ただ、ソフトウェア開発の本質的な部分が「人」にあるのです。プロセスさえあれば、人代替可能であるということはありえません。
本書のエピローグから少し引用しましょう。
とどのつまりソフトウェア開発というものは、芸術、科学、工学を絶妙に配合した技芸という名のスキルなのです。これは一日にして成るものではなく、情熱の対象となり得るものなのです。プロセスを向上させるために私が理解したことを記述して、本書を締めくくることにします：
ソフトウェア開発はたのしくなければなりません。そうでなければ、そのプロセスは間違っているのです。
この一文に共感を覚えた方は、ソフトウェア職人気質の素質があると私は考えます。
ソフトウェア工学に対する強烈なアンチテーゼ
本書では、これまでソフトウェアを工学として扱ってきた考えに対する強烈なアンチテーゼを示します。本書を読んで考えることで、もしかしたら、これまでの業界の慣習や当たり前だと考えてきたことが崩れていくかもしれません。ここでは、私が気になったところを引用しておきます。
ソフトウェア職人気質に共感できる人ならば、そこにどんなことが書かれているか、すぐに想像がつくかもしれません。詳しくは古書になりますが手に入れて読んでみてください。
p.11 ソフトウェア開発は体系化かつ定量化することが可能なのか？
p.20 ソフトウェア開発において作業の分担は有効なのか？
p.34 職人気質の本質は、熟練度を向上させるということなのです。そうです、人は作業の一部分だけであれば比較的短時間に学習できるのですが、完全な熟達はすぐには達成できないものなのです。
p39 資格制度は幻想である
p42 ソフトウェア開発の問題は要員不足ではなく要員過剰にある
p52 素晴らしいソフトウェアには署名がある
p60 顧客は、平均的なプログラマを30人以上雇用するよりも、2〜3人の熟練職人を雇用すべきです。こういった職人には、平均的なプログラマ全員に払っていたのと同じくらいの金額を支払います。
p61 どのようにしたら開発者が本当に優れているかどうかを判断できるのか？
p65 顧客とソフトウェア職人の関係は長期に渡るものとなる
p70 ソフトウェア職人は下働きではない・優れた開発者は管理者よりも価値が高い
p95 フィードバックなき実践は、単なるエラーの積み重ねでしかないのです
p98 アプレンティス（弟子）は安価な労働力ではない
p152 開発者とユーザは、アプリケーションが絶対に「完成」しないこと、ビジネス・ニーズに合わせるために共同作業を行ってアプリケーションを進化させていくこと、そういった進化を止める理由は何もないことに気付くわけです。
p153 保守チームは粗悪なアプリケーションの受け取りを拒否すべきである
優れたソフトウェア職人の育てかた
私たちソニックガーデンでは、新卒の社員の採用も行っています。よく中途採用だけだと思われがちなのですが、もちろん会社を設立した当初はそうでなければ成り立たないため、そうでしたが、今は新卒の採用も行っています。もちろん経験は未熟でも優れた素質をもった人を採用しています。（もし興味があればぜひお問い合わせください。）
業務や技術について未経験であるというのが新卒の特徴です。私たちソニックガーデンにはキャリアとしては「プログラマ」という選択肢しかありません。よって、必然的にプログラマとしてのスキルをゼロから身につけてもらうことになります。
１人前のプログラマになるためには、プログラミング言語を駆使してプログラムを書くことは大前提として、そのソフトウェアをどう作れば良いかという設計をすること、お客さまと話をして何を作れば良いかという設計をすること、安定して動き続けることを実現する運用することなど、身につける技術やスキルは多岐にわたります。私たちソニックガーデンでは、すべてが出来て初めて１人前として扱われます。
その道のりは厳しいものですが、それを超えたからこそお客さまにとって価値のある存在になることが出来るのです。私たちは新卒社員に対する教育は「徒弟制度」で行っています。それはまさしく本書で書かれていたソフトウェア職人の育てかたなのです。
p34. 伝統的な技芸には、徒弟制度というものがありました。その制度では、弟子が簡単かつ平凡な作業を引き受け、観察や職人の監督下で行う実践を通じて、より難解で複雑な作業を実行する上で必要となる暗黙の知識を吸収するという「状況学習」の場が提供されていました。
人月や派遣で商売をしている多くのソフトウェア企業では、新卒社員を労働者として扱います。ベテランに比べて単価の低い労働者です。なので、教育もほどほどに現場に放り込まれます。それは、その労働者としてのコストを賄わせるために行われているのです。それが果たして本当にお客さまにとって価値をもたらしているのでしょうか。私はそうは思いません。
新人2人あわせたら、熟練した職人に匹敵するでしょうか。新人を3人だったら、4人だったら・・・どれだけ人を入れたとしても、熟練の職人には匹敵しないのです。頭数の問題ではないにも関わらず、多くの現場ではそういったことがまかり通っています。それは、ソフトウェアを技芸として考えない人たちの発想なのです。
私たちソニックガーデンでは人月も派遣も行いません。１人前に育つまで時間はかかりますが、労働者としての勘定ではなく、将来の１人前になるための投資として教育を行います。アプレンティス（弟子）本人も大変ですが、それにかかるコストを負担する企業や師匠にとっても大変です。しかし、それが重要なのです。
p87. ソフトウェア開発の技芸に熟達するには、少なくとも15年、あるいはそれ以上かかるはずです。（中略）ソフトウェア職人気質は必然的に、プログラミングのみではなく、様々なことも伴っているのです。才能と熟達は同じものではありません。（中略）ソフトウェアの熟練職人になることは、認定を受けたり試験に合格することほど単純なものではありません。
ソニックガーデンでもそうですが、ソフトウェア職人気質の世界では、キャリアパスという考えはありません。ある年次が経てば、別のキャリアが用意されているというようなものではなく、ソフトウェア職人として「熟達」していくということしかないのです。そこに終わりはありません。
そうして、ずっと高みを目指し続けることがソフトウェア職人としての生き方になります。私たちソニックガーデンではその努力をしていくことが企業の価値に直結していくようなビジネスモデルの会社にしています。
余談ですが、以前にコンサルタントの人たちに若手の育てかたを聞いたことがあります。ある人の答えは、コンサルタントの世界でも徒弟制度を採用しているということでした。コンサルタントのようなナレッジワーカーの仕事では、師匠となる先輩について学ぶことでしか熟達の道はないのかもしれません。そう考えると、ナレッジワーカーの仕事とは、現代の職人と言い換えてもいいのかもしれません。
ソフトウェア開発はナレッジワークであり、ソフトウェア開発のすべてを担うプログラマはナレッジワーカーであるという私の主張とも繋がってくるように思いませんか。ソフトウェア職人気質の世界を目指したい方は、ぜひ読んでみると良いと思います。
