読者です 読者をやめる 読者になる 読者になる

三流プログラマが脱三流するために書くブログ

PHP, オブジェクト指向プログラミング, デザインパターン, リファクタリング, DDD, 関数プログラミング, etc.

2. 「達人プログラマー」70のヒントから学んで脱三流を目指す

前回 ひとり振り返り会をやってみて、問題点が少しずつ理解できてきました。2回目の今回は、それを補うために、私の好きな本の一冊であり、日本でもベストセラーにもなった不朽の名作「達人プログラマー」について書こうと思います。

動機

この本を最初に読んだのは、15年くらい前ですが、たぶんここに書かれていることをまだ十分咀嚼できていないのではないか、という思いがあります。 もちろん、三流から脱するにはこの本に書かれていることだけをやればいいわけではないとは思いますが、守破離の教えに従い、とりあえず本を読み返しながら現状チェックをしてみたいと思いました。本分に散りばめられた「ヒント」(ぜんぶで 70) が巻末にまとめてあるので、それぞれ実践しているかどうかを 4つを満点として、自己評価していきたいと思います。

これを機に、英語版も購入したので、ところどころ原文も交えて書いていきます (多少ニュアンスの違うところがあるので)。 ニュアンスが違う、と言えば、そもそも、"pragmatic" は 「実用主義的な」とか「実践的な」とかの意味なので、「達人」はちょっと言い過ぎかと…。 たしかにかっこいい訳だとは思いますが。

■ 基本的な5つの性格

  • 新しい物好き (early adopter/fast adapter)
  • 研究好き (inquisitive)
  • 批判的 (critical thinker)
  • 現実的 (realistic)
  • 何でも屋 (jack of all trades)

達人プログラマーに必要な基本的な性向というか、態度というか、思考や行動の原則みたいなものが書いてあります。

自分ではわりとどれも当てはまっているように思いますが、「研究好き」は足りないかな…飽きっぽい性格なので…

「新しい物好き」に関しては、和訳だと後半の "fast adapter" が抜け落ちてますがけっこう重要だと思っていて、 新しい物事に対してはすぐに適応し、評価を下せるようになる方がいいです、次のステップに早く進めるので。

これらの行動原則を組み合わせると、以下のようなかんじになるんじゃないかと思います。

新しい物をとりあえず試す → よいところも悪いところも批判的に分析する → 現実的に判断して取り入れるかどうか見極める → 取り入れると判断したら徹底的に研究する → 取り入れないと判断してもとりあえず軽く使えるようにはしておく → 結果的に何でも屋になる

というわけで4点満点で自己採点してみます。

  • 新しい物好き
  • 研究好き
  • 批判的
  • 現実的
  • 何でも屋

■ 達人プログラマーなるための70のヒント

70 もあるので、さすがにぜんぶは載せられないですが、個人的に大事だと思うのとかまだまだできてないなぁというのを中心に 10 個ほど、列挙してみたいと思います (先頭の数字はヒントの番号、括弧内はページ数)。

2. あなたの仕事について考えること! (xiii)

「漫然と仕事するのではなく、意識して仕事する」 (Turn off the autopilot and take control) ということなんですが、いやぁ、意識はしてるんですけどね、まだ足りないというか、"take control" できてないというか、思考の先に行動がつながるような "THINK!" でありたいな、と思います。

5. 変化の触媒たれ (8)

「未来を垣間見せ、その実現に参加できるよう手助けする」(show them how the future might be and help them participate in creating it.) ということで、未来を示すことができてないなぁと思います。これ、私にとっては大きな課題です。

10. 伝える事柄と、伝える方法は車の両輪だと考えること (22)

伝えるの難しい…。

15. 目標を見つけるには曳光弾を使うこと (49)

曳光弾は "tracer bullets" で、発光することで弾道を示す特殊な弾丸という意味みたいですが、要するに、曖昧な要件、不慣れな技術などの要因から、正確な見積もりが立てられない状況では、今後の方向性を見定めるために早めにひとつでも機能を実装してしまい、以降の状況に応じて素早く肉付けを行えるように準備しておく必要がある、というわけです。

これはなかなか、言うは易く行うは難し、というところで、手探りで新しいことにチャレンジしなければならない状況はあれど、そのような用意周到な準備はできていないです。

これも経験を積み重ね、不確定要素の多い状況にどう対処すればよいか、という知見を溜めていくしかないのかもしれません。

24. 非難するのではなく、問題を修復すること (91)

「自分事化」というのはわりとできているとは思うんですが、それでもときどき見て見ぬ振りをしてしまうことがあるので、自戒を込めて。

27. 仮定せずに、証明すること (98)

基本的には、実際にコードを動かして仮定した結果が得られることを検証するようにはしていますが、時間がかかることだったり、大量のデータを用意しないといけないことだったりっていうのはおろそかにしがちなので、常に意識していきたいです。

38. 抽象概念はコード上に、詳細はメタデータ上に置くこと (150)

これも、ちょっと気を抜くと詳細をコードに書いてしまうので、気をつけたいです。

44. 偶発的なプログラミングを行わないこと (179)

これも一緒ですね、分かったつもりになって書いたコードが不具合の原因というのがよくあります。反省。

45. アルゴリズムのオーダーを見積もること (185)

最近はコンピュータリソースが潤沢になってきたせいで、以前よりパフォーマンスを気にしなくてもよくなってきたのは事実で、パフォーマンスより可読性だ、みたいに思ってるところがあります。でも、可読性のためにパフォーマンスを犠牲にした、ということを理解しているかどうかは、今後チューニングが必要になった場合に間違いなく迅速な対応につながるので、常に意識していきたいです。

51. 要求は拾い集めるものではなく、掘り起こすものである (206)

「要求は、仮定、誤解、政略といった層に深く埋められているものである」(政略=politics) ということで、政治めんどくさいと常々思ってるわけですが、要件を掘り起こすためには突破しなければならない関門であるわけです。「9. 見聞きしたことを批判的な目で分析すること (16)」にも通じるところがありますね。表面だけを見て仕事をしないように心がけていきたいです。

56. 心の声に耳を傾け、準備ができてから開始すること (219)

曳光弾のヒントと通じるところがあります。「ソフトウェア開発は未だ科学的なものではありません。本能をあなたの能力に貢献させてください。」という提言は、ソフトウェア開発以外の領域でも、直感や無意識の行動によって正しい状況判断ができた経験 (むしろ直感や無意識に頼ったことで正しい判断ができた、のかもしれません) があると思うんですが、そういう感性は常に磨いていきたいと思います。

62. 早めにテスト、何度もテスト、自動でテスト (241)

CI が当たり前になっている現在、あまり意識する必要もなくなってきたわけですが、コンピュータが勝手にテストコードを書いてくれるわけではないので、気を抜かないようにしたいです。

69. ユーザーの期待をやや上回ること (260)

「それよりも少し良いものを作る」(deliver just that little bit more) というのは、日本語版では少しポイントがぼやけているかな、と思いますが、「やや」という表現も、原文では "gentrly" となっていて、さりげなくとか刺激的でないていどに、という補足をしたいと思います。

期待を上回ることは大事だと思いますが、上回りすぎてもいけないし、押し付けがましくてもいけないし、さりげなくほんの少しだけ、相手が無意識に満足感を覚えるような上回り方がベストなのかなぁ、と。

フリーランスでやっていると、失職の恐れからついつい過剰サービスになってしまいがちなので、意識しておきたいヒントのひとつですね。

というわけで 70 個すべてに点数をつけてみました

平均点は 2.1 / 4.0 という結果でした。

このスコアが 3 以上になるよう精進していきます。

まとめ

  • 伝える技術を磨くこと
  • 自分のコードには万全の配慮と責任を持つこと
  • 一歩先行く仕事をすること