はじめに
この記事について
Robert C. Martin の「Clean Craftsmanship」を読んだので感想をメモ。技術書は英語学習も兼ねて英語で読むようにしているので、引用は原著からになってます。
（上記リンクは日本語訳版です）
本書の概要
This is a book about working well. This is a book about doing a good job. This is a book that describes the disciplines and practices that every programmer should know in order to work fast, be productive, and be proud of what they write every single day.
Martin, Robert C.. Clean Craftsmanship (Robert C. Martin Series) (p.xxiii). Pearson Education. Kindle 版.
意訳すると、プログラマーは、いい仕事をし、自分の仕事に誇りを持ちたいのであれば、本書で述べる規律と習慣を身につける必要がある、ということです。
"craftsmanship" とは日本語で「職人技」です。本書では、職人技を発揮するための基礎となる考え方や価値基準について、著者の考え方や価値基準にもとづいて述べられています。
1章で Craftsmanship について述べ、2章以降で「規律」「基準」「倫理」の三部構成で、それぞれ詳細に解説しています。
ここで各項目については触れませんが、テスト駆動開発、生産性、継続的デリバリー、チームワークなどが挙げられています。
本書の書かれた動機
推測ですが、本書の書かれた動機の一つとして、著者が持つ以下の問題意識があります。
To make matters worse, the number of new programmers entering the field doubles every five years or so, keeping the ratio of experienced programmers far too low. The result has been that most programmers never learn the disciplines, standards, and ethics that could define their craft.
Martin, Robert C.. Clean Craftsmanship (Robert C. Martin Series) (p.9). Pearson Education. Kindle 版.
日本でもITエンジニア人口が緩やかに増えているようで、それ自体は喜ばしいことですが、相対的に経験者から教わる機会は減っている、あるいは減っていくのではないかと思われます。
技術に関しては、書籍、オンラインの学習コンテンツ、プログラミングスクールなどで学ぶことができますが、規律・基準・倫理に関してはあまり学ぶ機会がないと思われます。
職業としてソフトウェアエンジニアを始めた場所が、最初に規律・基準・倫理を学ぶ場所になり、最初に学んだそれらの骨子が、それ以降のキャリアにおいても核になっていく可能性は高そうです。
もちろん、行く先々で異なる価値観を学び、良いものを取り入れてアップデートしていくことになるでしょうが、
マインドセットの大切さ
本書に書かれている規律・基準・倫理には、マインドセット（考え方・判断基準）が関係しています。
具体的にいくつか例を挙げると、
- テスト駆動開発を行うこと
- チームメンバーとはお互いを支え合うこと
- 学び続けること
などです。
テスト駆動開発がマインドセット？と思う向きもあるかもしれませんが、プログラミング工程の順番を変える（テストを先に書く）のは正しくマインドセットの切り替えと思います。
過去の経験から、テスト駆動開発の採用ができない（あるいはやりたがらない）人は少なくないと推測しますが、技術的な問題もあるにしろ、やはりマインドセットの変更を伴うことが原因なのではないかと思っています。
技術的な向上よりもマインドセットの変更のほうが、ハードルが高いと感じています。人は長く馴染んだものの考え方や判断基準を変更するのを嫌がるものです。
ちなみに、マインドセットに関しては、以下の書籍に詳しいです。
技術とマインドセットの関係について、私は下図のように捉えています。
ピラミッド内の3つの要素はいずれも経験からフィードバックを受けて変化していきますが、ピラミッドの下に行くほど変化させにくく、上に行くほど変化させやすいです。
技術は学習によって向上しますが、学習も経験によるフィードバックです。経験的に、同じような量と質の経験を与えられたときに、得られる学習効果に個人差がある感じていて、ある人は爆発的に成長しますが、別の人はほとんど成長しない、みたいなことが起こることがあります。
いくつか要因があるでしょうが、観察していて感じるのは、本人の成長意欲や知識欲（知的好奇心）も関係あるだろうということです。
たとえば、なんらかのトラブルシューティングをすることになったとき、とにかく早くその状況から脱したいという気持ちだけで対処する場合と、原因を突き止め二度と同じ過ちを繰り返すまいとして、トラブル回避後も事後検証を怠らない姿勢で臨む場合では、明らかに成長具合に差が出ます。
技術的な向上はマインドセットに支えられていて、経験によるフィードバックから受け取るもの（あるいは吸収するもの）を左右するのでしょう。
マインドセットの変化に関しては、単純に「考え方の変化」→「行動の変化」の一方向のみではなく、「考え方の変化」と「行動の変化」がお互いに行ったり来たりしながら徐々に変わっていくものと考えています。きっかけとなるような小さな変化を起点とし、行動を変えながら徐々に馴染んでいくのがいいのではないかと思います。「騙されたと思ってやってみる」ということです。
そういう意味では、本書がそのきっかけになってマインドセットを変えられる人は、とりあえずやってみる精神を持っている人、ということになるでしょうか。
価値基準は環境に依存する
本書に書かれていることは、個人的には素晴らしいことが多いと感じますが、本書を読んでマインドセットを変える人がどれほど生まれるか、という点についてはあまり楽観的になれませんでした。
筆者のように元々近い価値観を持った人が読めば、うんうんそうだよな、と感じるでしょうが、正反対の価値観を持った人が読んだとき、180度考え方を変えるでしょうか？
現状の自分の仕事が評価され、自分でも満足していて誇りを持てる、ということであれば、マインドセットを変える必要はないですし、本書に書かれていることと正反対のことをやっていても別にネガティブな気持ちになる必要もないでしょう。あくまでも本書に書かれていることは例でしかないと思います。
また、マインドセットは個人のものですが、個々人のそれが組織や集団の中でも有用かというと話は別で、なにを良しとするかの基準が組織とずれている場合には、無用どころか害になることもあります。
テスト駆動開発にしても、異なる価値基準を持つ上司にテスト駆動開発をやっていることが見つかると怒られたりします（テスト駆動開発は時間が余計にかかる割に得るものが少ない、などと考えている場合）。
他人を変えるより自分を変えるほうがずっと簡単です。
上のような場合「アンクルボブだってこう言っていますよ」と上司に突っかかったとしても、火に油を注ぐことになりかねないので、もし組織全体のマインドセットを変えたいのであれば、忍耐と慎重さが必要でしょう。
要は、自分を取り巻く環境や周囲の人たちの存在を無視してマインドセットは語れないだろう、ということです。
自分と組織の価値観がずれている場合、個人が取れる選択肢の中では、リーダーや他のメンバーの価値基準を無理やり変えることよりも価値基準の合致する組織に移動することが早く確実でしょう。
逆に、組織のリーダーは、価値基準に合致するメンバーを集めるために（あるいはメンバーに変化を促すために）「私たちが大事にしている価値基準はこうです」というのを示す必要があると考えます。
おわりに
本書を読んで感じたことをだらだらと書き連ねましたが、まとめると、以下のような感じです。
