Robert C. Martinの『Clean Coder』を読んだ。読んだのはだいぶ前。引用メモが残っていたので記事に。
実践し続ける、学び続ける
おおアーキテクトよ、コーディングをやめてしまうとはなにごとだ。すぐに自分たちが重要ではなくなったことに気づくだろう。おおプログラマよ、新しい言語を学ばないとはなさけない。いずれ自分が業界から取り残されるのを目の当たりにすることになるだろう。おお開発者よ、新しい規律や技法を学ばないとはふがいない。いつか同僚に置いていかれることになるだろう。（42）
これは訳者が工夫したのだろうか・・・。新しい言語を学ぶ、というのは『達人プログラマー』でもアツく推奨されていたが、仕事で使わないものを自力で学ぶのはモチベーション的にも機会的にも難しいなぁと感じている。あと、「学ばない人間を置いていく同僚」がいない環境は本当にダメ。
「ノー」と言う
プロは権力者にも真実を伝える。プロはマネージャに「ノー」と言う勇気を持っている。どうすれば上司に「ノー」と言えるのだろうか？なんたって上司だぞ！上司の命令には逆らえないんじゃないのか？それは違う。プロなら違うんだ。奴隷は「ノー」と言うことを許されていない。労働者は「ノー」と言うことをためらうだろう。だが、プロは「ノー」と言うことを期待されている。実際、優れたマネージャは「ノー」と言ってもらいたがっている。それ以外に何かを成し遂げる方法はない。（49）
「上司が余計な仕事を取って来やがる」という愚痴はしばしば耳にする。そこに「ノー」と言ってやるのがプロなのだ。しかし上司が「ノー」と言ってもらいたがる「優れたマネージャ」である保証はないのである。ダメなマネージャがのさばる会社からは、プロがいなくなっていくことになるのかもしれない。
「試しにやってみる」の甘え
試しにやってみるというのは、力を温存していたと認めることだ。試しにやってみるというのは、温存しておいた力を使えば目標が達成できると認めることだ。さらに言えば、温存していた力を使って目標を達成すると約束することだ。つまり、試しにやってみるというのは、成功を約束すると言うことなのだ。「試しに」やってみて、望ましい成果につながらなかったときは、失敗したということになる。（55）
この次の章（「イエス」と言う、ことについて議論されている）に寄稿されているロイ・オシェロフの「約束の言葉」（オシェロフ自身の『ELASTIC LEADERSHIP』で「コミットメント言語」として紹介されている）との関係で、上の記述を読んだ。原書あたっていないが、おそらくtry doing（できることを、実際にやってみる）なのだろう。日本人が「やってみます」というときのニュアンスは、try to do であることもあるような気もする。try doingの場合は、とにかく成果物を一度提出するから、そこで判断してください、という感じ。
早すぎる詳細化
ビジネスもプログラマも「早すぎる詳細化」の罠に陥りがちだ。ビジネスは、プロジェクトを承認する前に、これから手に入れるものを正確に知りたいと思う。開発者は、プロジェクトを見積もる前に、これから開発するものを正確に知りたいと思う。どちらもできるはずのないことを詳細化しようとして、コストを無駄にしているのだ。
詳細化されていたと思ったら、あとからコロコロ変わるんですよね。顧客の目があらかじめ入っていないときは特にそうなんだろう。ちなみに、不確実性ということについては、広木大地さんの『エンジニアリング組織論への招待』で、焦点を当てて論じられていた。意思決定を遅延させることによってコストを減らせないか？
緊急時に規律をやめてはいけない
緊急時になれば、自分が何を信じているのかがわかる。規律を守っていれば、その規律を本当に信じていると言うことだ。逆に言うと、緊急時に普段の行動を変えてしまえば、その行動を信じていないと言うことだ。平常時にTDDの規律を守り、緊急時にそれを守らないとすれば、TDDの効果を心から信じていないということだ。平常時にコードをクリーンに保ち、緊急時に乱雑にするのであれば、乱雑が速度を落とすことを信じていないのだ。平常時にペアを組まず、緊急時にペアを組むのであれば、ペアのほうが効率的だと信じているのだ。緊急時に安心して守れるような規律を選ぼう。そして、それを常に守ろう。規律を守ることが緊急時から逃れる最善の方法である。ピンチに陥っても行動を変えてはいけない。規律が最善の方法であれば、緊急時になっても守るべきである。（156）
この部分は実際のところどうなのか（『ELASTIC LEADERSHIP』のいう「サバイバルモード」「学習モード」「自己組織化モード」の分類とはどのような関係に立つか？）。とはいえ、ペアでやった方がミスが少ない、と考えて普段ペアプロやっている人が、障害対応で単独プログラミングしてバグを仕込む、とかは実際にありそうな話。
職人気質
我々は「職人気質」という言葉の意味を考える段階に来ている。これはどういう意味だろうか？その意味を理解するために、「職人」という言葉について考えてみたい。この言葉からは、熟練の技・品質・経験・能力などが思い浮かぶ。職人とは、急がずにすばやく仕事をして、適正な見積もりでコミットメントを果たす人のことだ。職人は、「ノー」と言う場面を知っているが、できるだけ「イエス」と言おうとする。職人は、プロである。
職人気質とは、職人の持つ考え方である。職人気質は、価値・規律・技術・態度・解答を運ぶミーム（情報遺伝子）である。
だが、職人はどのようにこのミームを身につけたのだろうか？どのようにすれば、このような考え方を手に入れることができるのだろうか？
職人気質のミームは人から人に伝えるものである。年長者から若者たちへと教え伝えられる。仲間同士で交換する。年長者が若者たちを観察するなかで再発見する。職人気質はウィルスのように精神に伝染するのだ。他者を観察してミームを手に入れることで、それを自分に根付かせることができる。
職人になれと誰かを説得することはできない。職人気質のミームを受け取れと説得することもできない。議論をしても効果はない。データは重要ではない。事例は無意味だ。ミームの受け入れは、論理的ではなく感情的なものである。非常に人間的なものなのだ。
職人気質のミームを身につけてもらうにはどうすればいいのだろうか？ミームは伝染することを思い出して欲しい。ただし、観察できなければいけない。つまり、ミームを見える化すればいいのだ。そのためには、自分がロールモデルとして振る舞えばいい。自分が職人となり、職人気質を見せてやるのだ。あとはミームがやってくれる。（179-180）
職人気質のミームがそもそも存在しない組織には、まず職人気質を身につけた人が必要なのかな、と思う。その最初の一人を得るためには、採用するか、外に一度出して感染させてから内に戻す、ということしかないだろう。
感想
みんな大好きボブおじさんの本。ジョークに満ちていて面白いし、やや過剰では・・・と思うくらいに要求が高くはあるものの、非常に重要なことが散りばめられている。この本を読んで「うるせえ」としか思えなくなったらプログラマとしては引退した方がいいのかもしれない。
