達人プログラマーの読書感想自分のエンジニア人生と重ねて

書籍「達人プログラマー」の第2版をざっと読了しました。

社会人1年目の頃に先輩エンジニアから、「いい本だよ。思想的な部分が中心だけど。」という話を聞いたり、第1版のころから多くのエンジニアに支持されている書籍であることは認知していました。

当時は、「すぐに役立つとかじゃなく思想的なものであればひとまずいいか。」と手をつけていなかったのですが、2020年に改定された第2版の日本語訳版が発売され、紹介を見かけることが増えてきたので読んでみました。

総評

これは確かに素晴らしい。多くの人を魅了したことが納得できると感じました。

特に良いことが書かれているなと思ったのが、新人時代にさほど重視していなかった思想的内容が記載された章「達人の哲学」、「プロジェクトを始める前に」、「達人のプロジェクト」あたりです。

駆け出し時代は学習の時間を使うとなると、言語の体系的な知識、便利な関数、フレームワークの利用方法などすぐにでも手を動かせるものを求めがちでした。

しかし、実際の業務でのシステム開発はこの本にも記載されているとおり、複雑で抽象的な問題、未知の課題、プロジェクトメンバーが誰も気付いていない落とし穴など混沌としたものです。

この複雑で袋小路に迷い込みそうな世界を進んでいくには、表層的なテクニックや知識だけでなくベースとなる思考方法、マインドセットが不可欠であると今では思っています。

そういった意味ではこの本は強力な実用書となります。

私のエンジニア人生

2006年に新社会人として今の業界に入りました。

学生時代に友人関係のつながりで開発プロジェクトの手伝いや、Webサイト制作のアルバイトなども行っていたので、それらも含めるとおおよそ20年ちかく今の仕事をしていることになります。

それでも今なお、プログラム、ソフトウェア開発は難しいと感じています。

問題への解決が十分にできているか、進むべき方向が間違っていないか、必要最低限の知識を持ち合わせているか、顧客へ説明可能か、要求を満たせるか、常に不安を抱え、時には自分の力量に落胆し、この仕事が向いていないのではないかと考えることがあります。

そういった不安や畏怖のなか、なんとかプロジェクトを進めてきた経験の中で培われた知見、他のメンバーに伝えたいと考えていることと本書の内容が多く結びつきました。

特に強く共感した部分と、私が社内のメンバーに対して、何度も同じ話を繰り返し伝えていることと重複する内容について一部紹介したいと思います。

TIPの紹介

Tip 4 いい加減な言い訳よりも対策を用意すること

「2 猫がソースコードを食べちゃった」では、「責任を持つこと」についてなど、少し厳しいことが書かれています。

完了できない、納期に間に合わない、壊れているといったことを誰かに報告する前に、いったん立ち止まって自分自身の言い分に耳を傾けてください。机の上に置かれているゴム製のアヒルちゃんでも猫でも構わないので、まず話しかけてみてください。あなたの弁解は筋が通っているでしょうか？あるいはばかげたことを主張しているのでしょうか？あなたの上司にはどのように聞こえるでしょうか？

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

ゴム製のアヒルちゃんは、この本に幾度となく出てきますが、私もラバーダック・デバッグについてチームメンバーに紹介することがあります。

自分以外の誰かに説明をしてみるのは、問題を整理するのに役立ちます。それがゴム製のアヒルだったとしても。

トラブルは検知できるはずがない、予想できないところで起きることもあります。

プロジェクト担当者になったその日に前任者の残した問題によって緊急招集されることもあるでしょうし、自分のコントロールできる範囲外での出来事に巻き込まれることもあるでしょう。

感情的に筋の通らない話をクライアントや営業担当にぶつけるまえに、問題解決のための道筋を前向きに考えることが重要です。

経験上、多くの場合は、責任と向き合うことによってクライアントを含めた関係者は弁明したかったこと、外的要因で仕方がなかった点などは自然と理解してくれます。

もし何か言わないと気が収まらないのであれば、猫にでも言うことです。かわいいにゃんこちゃんは責任を取ってくれないでしょうけど……。

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

Tip6 変化の触媒たれ

「4 石のスープとゆでガエル」で石のスープの民話を初めて知りました。
この本の中で一番おもしろいと思った一節で、まさにプロジェクト進行の重要なポイントだと思います。

すべての情報や要求を適切でないタイミングで広げると相手は萎縮し、理解への道筋をたてれずうまく協力を得ることが難しいこともあるでしょう。

こちらのイメージしている完成物に近づくよう相手の解像度を少しずつ向上させ、可能な要求から少しずつ引き出すという進め方はとても理にかなっていると思います。

人は万事うまくいっていることには簡単に参加できるのです。未来を少し垣間見せるだけで、みんな集まってくるのです

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

プロジェクトを牽引する立場や会社の一員として、良い変化をもたらす触媒になれたら、なんと素晴らしいことでしょう。

Tip12 伝えることがらと、伝える方法は車の両輪だと考えること

聞き手の興味や能力を理解して話をするのは当然のことながら、タイミングや伝える手法、情報量なども望ましいかたちがあります。

多忙な上司にメールで相談事項を送付し、空いた時間に返信を下さいと記述していてもその空いた時間は一生来ないかもしれません。

そんな場合でもA4用紙に箇条書きで相談したい事項を印刷して席までいって10分お時間くださいと言うと快く応じてくれることもあります。

より効率的で保守しやすい仕様に変更したくなった場合でも、クライアントに動作確認できる状態になっていますという期日を過ぎている場合は仕様変更の交渉をそのタイミングで行うことは難しいです。

また、クライアントに負荷のかかる強い協力をお願いする場合（費用感、社内稟議など）は、我々に与えられた業務を滞りなく進め、評価を得てからが良いでしょう。

「7 伝達しよう！」の内容は、add moreの行動指針として定められている下記にもつながる内容でした。

目の前の仕事だけでなく、そこから繋がるチームの仕事、お客様の仕事を意識し大切にする。
常に相手の立場に立って考え、コミュニケーションは細やかに丁寧に行う。

Tip18 最終決定などというものは存在しない

すべての決定が石に刻まれたものであると仮定してしまい、不慮の出来事が発生した際の準備を怠るところに過ちがあるのです。決定は石に刻み込まれたものではなく、砂浜の砂に描かれたものであると考えましょう。今すぐにでも大波がやって来て砂ごと持って行かれてしまうかもしれないのです。

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

残念なことですが、ここで書かれているとおり最終決定などというものは存在しません。出来ることは、ここまでに決めた決定事項を覆す場合は時間と費用の再調整が発生しますという合意形成くらいです。

そして、自分のコントロールできる範囲外の事象により、前提や方針が覆ることは決して珍しいことではありません。

変更しやすい設計やコード、変化を受け入れる心を持ちましょう。

Tip75 自らが欲しているものを正確に認識している人などいない

私も日頃から何度もいう言葉です。

クライアントは解決したい問題・課題と業務への理解はあるものの具体的な術や、最終的にどのようなシステムが出来上がればよいかは知るよしはありませんし、我々も初期の段階では精度の高い答えを持っていません。

しかしそれは、現実の世界ではあり得ない話です。現実世界は乱雑で、矛盾に満ちあふれ、未知の事柄がそこかしこに散らばっています。そういった世界できっちりとした仕様を作り出すことなど、不可能とは言わないまでも極めて難しい話なのです。ここでプログラマーの出番がやってきます。我々の仕事は、人々自身が欲しているものを自らで気付いてもらえるように支援することなのです。

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

このセクションでは、送料を例にした具体的な例が挙げられています。

50ドル以上の注文で送料は無料にします。
ここでちょっと立ち止まって、その意味を考えてみましょう。まずどういったことが考えられるでしょうか？
以下のような疑問が出てくるはずです。
・50ドルは税込み価格で考えるのか？
・50ドルは送料込みで考えるのか？
・50ドルは紙の出版物の値段なのか、同時に購入する電子書籍の価格を含めるのか？
・どの発送形態をとろうとしているのか？通常便？それとも速達便？
・発送先が海外の場合はどうするのか？
・50ドルというしきい値は、どれくらいの頻度で変更されるのか？

David Thomas,Andrew Hunt. 達人プログラマー熟達に向けたあなたの旅第2版 (Japanese Edition)

上記のような課題はシステムを設計・構築するうえで必ずついて回ります。

複数の要求がお互いに矛盾することもありますし、テクノロジーとして敷居が高く、与えられた予算や人員、納期が現実的でない、達成したいことと手段が噛み合っていないこともあるでしょう。