プログラミング。最も基本的な仕事は、やりたいことをコンピュータに伝えること。
しかしプログラマーは実のところ、聞き手、アドバイザー、翻訳者、独裁者と、実にさまざまな役割を使い分けて仕事をこなしていきます。それは、毎日小さな奇跡を起こすかのごとくです。
そんなプログラマーは、どのようなマインドを持って作業にあたるのでしょうか。書籍「達人プログラマー」から紐解きましょう。
『達人プログラマー』とは
書籍『達人プログラマー』。エンジニアの間では、必読といわれる名著です。
初版はもう20年以上も前です。しかし内容は色あせません。プログラマーの本質は時代によらず変わらないからです。
それでも技術は日進月歩です。現在では、新装版として内容が見直された第２版が出版されています。本記事は第２版をもとにしています。
達人プログラマーで語られる、プログラマーの５つのマインド
『達人プログラマー』では、プログラマーが心がけるべきことが100のTipsでまとめられています。これらをまとめると、プログラマーの持つ５つのマインドが見えてきます。
- 誰も（自分も）信用しない
- 全力で楽をする
- 他人事のように見る
- 突き進む（でも慎重に）
- 変化しないことを恐れる
その１：誰も（自分も）信用しない
プログラマーは、誰のことも、自分のことさえも、信用のおけない存在として捉えます。
人間不信なわけではないです。人はみんな間違える、と考えます。
さらにおもしろいことに、間違えないように意識する、ということではなく、
- にくくする仕掛けをつくる
間違えることを前提に考えるのです。
この世の中に、完璧なソフトウェアなど存在しないし、自分が史上初の作成者となることもない。プログラマーはまずこの事実を受け入れます。
ではどうするか？ことを防衛的に進めるのです。トラブルが発生する前に兆候を見つけ、予期しない出来事の先を見越し、脱出できない状況に陥らないようにします。
プログラマーは、契約による設計や、エラー処理設計などを駆使し、間違えてもすぐに気付くような仕掛けを施します。
「割れ窓理論」という有名な理論があります。
美しく清潔に保たれたビルも、１枚の割れた窓が長期間放置されると、ゴミが撒き散らされ落書きがされて荒れ放題になります。美しさを保つためには、たとえ１枚で割れた窓を放置しないことが肝心です。
ソフトウェアも、１つの欠点があるだけで崩壊していくことがよくあります。で、クリーンで機能的なシステムが、たった１つの割れた窓で腐っていくのです。
プログラマーは、クリーンで美しいコードを汚さないよう、細心の注意を払います。
その２：全力で楽をする
「面倒くさがり」な人は、プログラマーに向いていると言われます。
例えば、10,000個のデータをひたすらタイプしたり、会計情報を電卓ですべて計算したり…プログラマーは面倒な仕事が大嫌いです。
- 面倒なら、全力で楽をする方法を考える
退屈で面倒な仕事を、すばやくかつ正確に行う、それこそがプログラムです。
バージョン管理とは、ソフトウェアを変更した履歴を記録するためのものです。新しいバージョンのソフトウェアは、ビルドしテストしリリースする必要があります。
ビルドからリリースまでの手順は面倒です。楽をしたいプログラマーは、バージョン管理に新しいソフトウェアを登録すると同時に、ビルド、テスト、リリースを自動的に行うような仕掛けを作るのです。
テストは、バグを取り除くため、網羅的に行う必要があります。
バグの洗い出しは、網で魚を捕ることに似ています。ありとあらゆる魚を、逃さないように捕まえなくてはなりません。
魚をいちいち一本釣りしていたら、労力の割にあわないし、取り逃しも大きくなります。テストという網を、即座に何回も自動的に放ることで、バグという魚を、最小限の労力で捕りつくすのです。
その３：他人事のように見る
プログラマーは、設計をしたりコーディングをしたりテストをします。
コーディングはひとりでやりますが、「コーディングをしている自分」と「それを横で見ている自分」のふたりがいる感覚を持ちます。
- 自分の作業を冷静な目で見つめる
つまり、自分のしていることを客観的に眺めています。
プログラマーは常に、見聞きするものごとについて批判的な考え方で接します。
インターネットの検索エンジンで真っ先に返してくる結果、書籍の特設棚に置かれる書籍、それらが有用であるかを分析し、みずからの知識をアップデートしていきます。
ソフトウェアにバグが発生すれば、それを直すためにデバッグをします。
デバッグはとても感情的になりやすい作業です。このバグを埋め込んだのはだれだ？そのエラーを発生させているライブラリはどこのベンダーのものだ？
でも、プログラマーは知っています。バグを仕込んだ容疑者への非難にエネルギーを使うのは、ムダであることを。
挑む相手は問題そのものであり、デバッグとは単なる問題解決のことを意味するのです。
その４：突き進む（でも慎重に）
ソフトウェア開発では、作っているものが直接目に見えません。ビルや橋の建設とは違う、やっかいな点です。
まるで、ゴールも見えない暗闇の中のマラソンです。ただ走ってもゴールには辿り着けません。目標はどう定めればよいのでしょうか？
- 先の道筋を確認しながら進む
プログラマーは、やみくもに事をすすめません。必ず行く先を照らしながら進むのです。
曳光弾（えいこうだん）とは、機関銃に装てんする特殊な弾丸で、発射すると光の筋が描き出されます。これで通常弾の照準を調整するのです。
曖昧な要求事項、不慣れなアルゴリズム、開発技法、言語、ライブラリーなど、未知の世界をつきすすむとき、まずは光弾を使います。
要求の段階で、システムの最終形態となるイメージを迅速かつ目に見えるかたちで作る。これが曳光弾となります。
さらに何度も直して提示できるものとしておきます。これを使って、リスクを分析し、機能を追加し見直していくのです。
その５：変化しないことを恐れる
平和のうちに進むソフトウェア開発。明確な要求、手慣れた設計技術、実績のあるライブラリ。まるでなにも問題がないかのよう。
プログラマーは、こんな変化の少ない平和なときにこそ大きなリスクが潜むことを知っています。変化がない、というのは怪しむべきことなのです。
- 変化がないときこそ怪しむ
「ゆでガエル」という話があります。
熱湯の中にカエルを入れると。びっくりして飛び出します。しかし水の入った鍋にカエルを入れ、徐々に熱すると、温度変化に気付かずにゆであがってしまうそうです。
カエルのようになってはいけません。周りだけ見て変化がなくても、疑いましょう。常に大きな視線で、なにが起こっているかを注視するのです。
今度は「石のスープ」の話です。
戦地から帰路へ向かうはらぺこの兵士。ある村へたどり着くも、村人たちは家の扉を固く閉ざします。
兵士は一計を講じます。鍋にいっぱいの湯を沸かし、石を沈めました。
不思議に思った村人。表に出てきて尋ねます「具はそれだけかい？」。兵士は答えます。「そのとおり。しかしいくらか人参を入れると味が引き立つだろう」。村人は、人参を持ってきて鍋に入れます。
「これで終わりですかい？」「イモが数個あると味がどっしりとするな」。別の村人がイモを持ってきて鍋に入れます。
そして、ほかほかしたスープができあがりました。兵士は石を取り除き、村人たちと充実した食事を楽しみました。
兵士は、村人をうまくひっかけた、と言えます。
しかし大事なことは、その石がきっかけとなって、村人たちが団結して食べ物を出し合うという相乗効果を引き起こした、ということです。
ソフトウェア開発が停滞したときには、「それなりに動くなにか」という石を放り込むのです。そしておもむろに「～を追加するともっとうまくいくんだけど…」とつぶやくのです。未来をすこし垣間見せれば、みんなを動かすことができるのです。
まとめ
プログラマーには、実にさまざまな知識と能力が求められます。アーキテクチャー、コミュニケーション、スケジューリング…。高度な仕事をこなすのは大変な労力です。
でも、プログラマーには、世の中を変える力を持っています。パソコン、スマートフォン、家電、自動車…ありとあらゆるところに存在するプログラムは、プログラマーが作り出すのです。
プログラマーには、大きな責任も伴いますが、未来をこの手で作り出す力があるのです。
『達人プログラマー』は、以下のTipsで締めくくられています。
コメント