読書メモ/「プログラムは技術だけでは動かない - プログラミングで食べていくために知っておくべきこと」

自分たちでソフトウェア製品・サービスを開発している著者が、人間的なスキルや考え方をリアルに照らし出してくれる絶好の良著。

注意点としては、自分たちでソフトウェア製品を開発している、というポジションからの話になっている点。
大規模システム開発のヒエラルキーや、動きの速いWebサービス開発、GoogleやMicrosoft, Appleなどの巨人達の開発現場の話では無いので、そうした現場に特有のノウハウは少ない。
しかしながら、内容的にはエンジニアが陥りやすい思考の罠や、実際に著者が体験したソフトウェア開発での成功談、失敗談など、普遍的なものが多い。
技術ではなく、人間としてどうソフトウェア開発を生業としていくかを考える際に、参考書として一読しておきたい書籍である。

以下、これはと思った箇所を引用して、自分なりのコメントをしてみました。

28p, 「現実は泥臭い例外の塊」

あまりにも汎用化・共通化をやりすぎてしまうと、例外的な処理を後から加えにくくなってしまうことがあります。
(中略)
最初からある程度ゆるく作っておくほうが、仕事では喜ばれることもあるのです。

「あるある」過ぎる。
プログラミングを真面目に勉強してると、「似てる処理は共通化」とか「汎用的な関数/構造体/クラス/メソッド設計」をやりすぎてしまうんですよね～。
特に十分ユースケースが揃ってない開発初期の時点でこれをやってしまうと、あとから、「え、そんなユースケース、この共通関数、想定してないよ～(T_T)」ということになってしまい、当初の「美しさ」はどこへやら・・・となりがちです。
かといって、数百～数千行単位で「1行しか違わない関数/メソッド」があっても後々のメンテナンスで＼(^o^)／ｵﾜﾀしますので、バランス感覚が求められるところですね。
ソースコードにアクセスできる人数が制限されてる、数人で開発しているのならまだしも、ある程度の人数や役割分担が始まる中規模以上の開発だと、一旦作ってしまったものは中々動かせないというのもありそうです。

これに対する教育プランとしては、やっぱり「一度は火傷してみる」ことは重要かなと。自分で「しまった、これは凝り過ぎた・・・。現実的じゃなかったんだ・・・。」となり、次回以降に役立ててもらうことがバランス感覚を育ててくれそうです。
あとは、例えば似たような処理が出てきても焦って共通化したりせず、一旦コピペ＋テストコードを書いておく。これにより、後々「やっぱりこの処理は共通化できる」となった場合でも、テストコードにより共通化するまえの処理と同じことを保証でき、共通化することによるエンバグに効果的に対応できます。

37p, 「自分が考えているほど、相手は気にしない」

ここの部分も自分は「あ～、あるある」と大いに頷いてしまいました。
わりとソロ(あるいはピン)で直接クライアントと仕事してると、プログラミングや技術的な精緻さを狙うよりは、妥当な時間でクライアントが望む最低限度のものを提供したほうが良かった、というケースがあります。
ただ一点、注意事項があって、突貫工事したあとはちゃんと整理しましょう、あるいは、整理する余裕が無ければ、メンテナンスを意識したシンプルなコードにしておきましょう、という点が注意事項だと思います。
あまりにもオレオレ流儀だったり、場当たり対応詰め込んだ突貫工事のソースコードだったりすると、後のメンテナンス（運用・保守フェーズ）で泣きが入ります。
そのためにも、コメントやテストコードなどで、後で自分以外のエンジニアが保守するときにもある程度思考の道筋をトレースできて、ブラックボックス化を防げるような施策を打っておくことが大切かと。
結局、これは「お客の時間」と「技術的な妥当性」と「運用・保守のコスト」のトレードオフやバランスになります。「今回はこっちを重視したので、そっちがおろそかになった」という歴史・物語・文脈をどこかに保存しておき、後で別の人が振り返って納得できるような施策だけは打っておきたいところです。

60p, 「理想はすべて詰め込んだ、けれど完成しない・・・」

これも「あるある」で、というのは、これ、「人月の神話」に出てくる「セカンドシステム症候群」そのまんまなんですよね。
システムの「二代目」を新規に開発する際は、「初代」からのフィードバックを全部取り込もうとしたくなる気持ちはよくわかります・・・。
しかし、それをやろうとすると大体、初代からのソースコードが使えなくて結局スクラッチからになり、初代で得たフィードバックを組み込もうとすると結局どんどん汎用性を求めることになり、プログラムも、ソフトウェアの使い勝手もどんどん複雑化していき、最終的にお客が求めるものは完成できなかった・・・という・・・。

多分、こういうケースでは初代からのフィードバックに真正面に取り組むのは悪手で、むしろ「なんでこんなフィードバックが得られたのか？それは○○な機能があったからだ。じゃぁ、そもそもその機能を削るか、別の機能で代替できないか？見せ方を変えられないか？」てきな検討が必要なのかもしれません。

87p, 「なぜ、コミュニケーションがうまくいかないのか」

（中略）

原因はじつはたった1つしかないと考えています。

「議論の基本や背景に関する共通認識が不十分なまま、相談を進めているため」

これも「あるある」でした。やっぱり、自分の意見の裏側には自分が体験したり獲得した背景知識・思想などが控えていて、ついつい、その点を意識できずに話を始めてしまいがちです・・・。
これに気づくには、話がこじれてきたときに「相手はなんでそういう態度を取るのか？もしかして、重要な前提知識や背景、文脈が欠けているからでは？」という思考フレームワークを使う必要があります。あったとしてもすぐに持ち出せるものでも無いんですが（反省）。
エンジニアであれば、「同じエンジニアならこれくらい知ってるよね？」というのを相手に期待しがちです。しかもその期待が裏切られると、「なんだ、これくらいのことも分かってなかったの？」という流れに陥りがちですので、そこは十分気をつけておきたいところです。そういうの、言葉の節々に出てきてしまって、結局相手の心を閉ざし、有意義な会話をできなくなる原因ですので・・・。

134p, 「付加価値の高い仕事をするための8つのポイント」
8つのポイント、概ね「なるほどなー、確かに」とうなずけるのですが、少しだけ気になる点があったのでコメントします。

周囲を巻き込みながら進める（特にテスト）

これ、こういう進め方をすること自体をネゴしておかないと、トラブルになるだけなのでそこは十分気をつける必要がありそうです。
特にある程度組織化された人たちと仕事をするとなると、相手のスケジュールや負荷、準備期間などの調整が絶対に必要になります。また、周囲へのアピールや理解も下準備しておかないと、いきなり振られても「そんなの聞いてないよー」となり、信頼関係が失われます。巻き込まれる相手に対する説明責任があることを忘れないようにしたいです。

自分で作ったものは完璧にサポートできてあたりまえ

これ、自分「だけが」サポートできる状況にしてもナンセンスです。もしそういう状況にしてしまうと、自分が休めなくなり、変に苦労や気苦労を背負い込むことになり、仕事が進んでいくとどんどん重荷になる一方です。
ブラックボックスやスパゲッティコードを放置せず、モダンな開発技法を駆使して、開発当初は自分一人だったとしても、3ヶ月後の自分を含めて、後々の運用保守で「自分だけしか」という状況を作り出さないような施策が必要そうです。

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

一応完成したと思っても、だれも見向きもしてくれない製品になってしまった。

・・・えー、その、自分もYakiBiki作りましたが、まさにこのパターン・・・。自分が唯一のユーザです・・・。

173p, 「価格設定をどうするか」

「安価なのは、安価である理由が」「高価なのは、高価である理由が」それぞれあるんだなぁ、と感じました。

201p, 「3年は種まきをして、失敗を積み重ねてはじめて見えてくる」

焦っても成果が出るものではないんだななぁ、と感じました。

223p, 「一生、プログラマとしてメシを食っていくには」

"プログラマ"というと読み手によっては想定スキルがバラつきそうですので、"ソフトウェア開発でメシを食っていくには"の方が良さそうに思いましたが、内容としては「なるほど、確かにその通り」と頷いてしまうものです。

感想というかふと思ったことですが、ソフトウェアの世界って、数年～10年前は難しいと思われてたことがあっというまにコモディティ化してしまう世界です。
ただ、コモディティ化するといっても結局値段や技術的な深さの点で、幅ができていきます。
一昔前はHTML+CSSでUIと見た目を両立させたHPデザインを行うのは、Webデザイナの牙城でした。しかし、Bootstrapなどのデザインテンプレートが台頭したことにより、それの流用である程度のデザインも可能になりつつあります。
イラストの世界もそうで、かつては限られた教育環境や制作資材の中、人間の手に依存した技能が参入障壁となっていました。しかしペンタブレットやイラスト作成ソフトの改良と、裾野の拡大による教育資料の広がり、SNSなどでの制作物の発表舞台の拡大により、イラスト製作者の絶対数や幅も圧倒的に広がっています。
ソフトウェア技術は、その時点で「難しい」「出来る人が少ない」と思われた分野を、数年～10年のスパンで「ある程度までなら簡単」「出来る人が多い」分野に変えていく性質がありそうです。
そうなってくると、「難易度が高い技術を出来ること」を売り物にしても、遅かれ早かれ陳腐化する危険があります。

そのような状況でやりくりしていくためには、いくつかのパターンが考えられます。

1. 技術の深さでは勝負せず、移り変わりに合わせて活動舞台・ツール・客層を変えていく、流動性の高い広さ重視パターン
2. コモディティ化しても、そのトレードオフとして深さが犠牲になっている。誰も到達できないほどの深さを極めて、そこで特定の分野とターゲットを狙って長くやりくりしてく、深さ重視パターン（この本の著者がそのパターンで上手く行ってそう）
3. 変化自体を引き起こし、変化のプラットフォームとなることを狙う、プラットフォーム戦略パターン
4. ITの変化それ自体は重視せず、ビジネスの道具として利活用していくパターン(自社のシステム開発など)

どれを選ぶか、むずいっすね・・・(ヽ´ω`)