tips
programming

『プログラムは技術だけでは動かない』を読んだまとめ

More than 3 years have passed since last update.

『プログラムは技術だけでは動かない』を読んだまとめ

『プログラムは技術だけでは動かない』を読みました。

この本で書かれていることがあたかも一般的な処世術や絶対解でないのは当然ですが
(むしろそう感じでしまうことは怖い気がする)、他人のプログラマとしてのキャリアや経験談から
学ぶ、他人の失敗・ストーリーから学ぶということは大きな勉強になります。

個人的には、現場に出て諸先輩から学んだことが随所随所にちりばめられていて、
「どこでも求められている資質は同じなのかな」と感じました。
実際にプロジェクトに加わって、「コードを書けるだけではプログラムはできるけど、喜ばれるプログラムができるとは限らない」ことを
日々実感している自分にとって、今は他のプログラマの方のいろいろな形での経験談(成功メインも失敗メインも)も
参考になります。

本書は、最初の章の「なぜ、技術力はあるのにいつまでも仕上がらないのか」と
「付加価値の高い仕事を得るには」が、特に面白く読めました。

当たり前のことを言われているような気もしますが、そのひとつひとつの「当たり前」をいかに
丁寧に積み重ねていくか、焦らずひとつひとつ実現していくかが大切なのかなと勝手に想像をふくらませていました。

なので、書評というより、今の自分にとって学びになるであろう箇所を抜粋してまとめてあります。
細かい点や他の章は本書を参考にしてください。
あくまで、気になった観点を主観的にまとめてあるだけですので、一部本書と異なる可能性もあります。

プログラマの仕事は「要求仕様」から始まる

仕事としてのプログラミングとは、「技術自慢をする」のではなく「依頼者・利用者の要求を満たしてあげること」です。

「設計書が正しければ、コミュニケーションなど不要では?」
そう思うかもしれませんが、そこまで完璧な設計書は見たことがありませんし、
最近は時代の変化が速いため、システム構築にもスピードが求められ、
「きちんと設計書を仕上げてからプログラミングをする」というパターンが
すべてではなくなりつつあります。

現実は泥くさい例外の塊

「美しい構造が悪い」と言いたいのではありません。
「現実は意外と泥臭い」ということです。
美しい構造で仕上がるよりも、依頼者としては「応用性が高いプログラム」のほうが嬉しいものです。
さらに、せっかくの美しい構造も、度重なる仕様追加・変更でどんどん崩れてしまいます。
最初からある程度ゆるく作っておくほうが、仕事では喜ばれることもあるのです。

重要なのは「できるかどうか」ではなく「解決できているかどうか」

プログラマとして重要なのは、「依頼者の課題を解決できているかどうか」です。
自分自身が自己満足できているかどうかではありません。
依頼者の課題を解決することに対して対価を頂くわけですから。
技術的な自己満足が悪いわけではありませんが、それを優先させては本末転倒です。

時間が経つほど、相手の要求水準は高くなる

「自分で完璧と思える段階に仕上げて見せる」方法のデメリットはまだまだあります。
それは、「時間が経つほど、相手の要求水準は高くなる」という点です。

「これだけ時間をかけて出てきたのだから、当然、テストも十分な状態で仕上がってきたのだろう」
となるわけです。

さらに、相手は時間的に暇になりますので、いろいろと考えます。

「やっぱり、こういうこともやっておこう」という感じに、まずはそれほど重要でもないことまで
考えが進んでしまいます。

とっとと見せてしまうほうが、相手も同じ意識に巻き込むことができますし、
相手の考えも随時把握できるので、実はつくり手としても安心なのです。

外に出るほうがこれだけお得

自分を知るためには、多くの人から客観的に評価をしてもらうのがいちばんです。
さまざまな人と話をすれば、自分が取り組むべきテーマが見えてきます。
部屋にこもって作業をしていても、そのようなヒントは得られません。

日中、会社にこもってプログラミングを続けてばかりいるよりも、
どんどんお客さんや販社さんなどに会い、
いろいろな情報を得たり、現場を見たりするほうが得なのです。

信頼性と保守性を高めるポイント

信頼性

・ソースは書いた時点ですぐ動作確認する
・すでに実績があるソースをできるだけ使い回す
・メモリリークはツールを使って調べておく
・排他処理でのデッドロックには十分注意する
・必ずターゲットの規模で動作確認(特にメモリ使用量・動作速度)をしておく
・自信がないソースは使わない
・凝りすぎいない
・冗長構成に対応する

保守性

・シンプルなソースが一番
・ログは十分に出力する。ログの量が速度に影響する場合はログのレベルを切り替えられるようにしておく
・サービスを可能な限り停止せずに、プログラムを入れ替えられるように考えておく

「自分たちの製品を作ろう」として失敗するパターン

・理想はいろいろ出てくるものの、具体的なアイデアが出てこない
・回を重ねるにつれて、毎回同じような理想論に飽きてきて、いつの間にかミーティング自体が自然消滅
・なんとかよさそうなアイデアが出てきたので、実際に開発をスタートしてみたとしても、いつまで経っても完成せず、これまた自然消滅
・一応完成したと思っても、だれも見向きもしてくれない製品になってしまった

プログラミング的に難しいことは少ない

製品化を進める中で、プログラマとして一番大事なことは「すぐに作って、動くものを見てもらえる状態にすること」だと
私は考えています。

検討するときに、動く状態を見せながら議論ができないと、意識合わせが難しく、なかなかまとまらないからです。

そのうえで、次に重要なのは目的の品質に仕上げることです。

心のなかで「作ればいい」と思っていませんか?

「作ればいい」ではなく、「使ってもらってなんぼ」という考え方に頭を切り替えることが大切です。

「ソースコードが綺麗かどうか」とか「構造が優れている」といった次元ではなく、
「ユーザーの課題を解決できるかどうか」がポイントなのです。

もちろん、そのために技術や知識の裏付けが必要なことは言うまでもありませんが、
それだけではダメです。

「自分が何を得意か」を知ってもらう

新しいビジネスまで自分で考える力があるかどうかは別として、
「自分の力を必要としている人に、自分を知ってもらえるかどうか」はとても大事なことです。

自分が好きなこと、やりたいことを開示することは、
時には自分の未熟さを暴露することにもつながり、
厳しい指摘を受けることもあるでしょう。

しかし、指摘してもらえるのは、とてもありがたいことです。
自分一人では相当時間が立たないと気づかないようなことを、
すぐに知ることができるからです。