12月13日(火)に行われた、達人プログラマー読書会@札幌に参加しました。
この日は、仕事でかなりやられていて絶不調でした。
しかし、参加してそんな絶不調の原因を知ることができたのでありました。
37. 不可能なパズルを解く
「制約を認識すること」と同時に「自由度を認識すること」。
”それは本当にだめなことなのか？制約なのか？”・・・・ハッとしました。
その日、まさに「もっと簡単な方法があるはずだ」という発想の転換をせずに、ひたすら”この方法しかない”と信じ込んで、そして、疲弊していたのです。
218ページに書いてあった自分への問い
- 簡単な手段は存在するのか？
- 正しい問題を解決しようとしているのか、それとも末端の問題に迷っているだけなのか？
- 何故それが問題なのか？
- 解決を難しくしている真の原因は何なのか？
- この手段でやり遂げなければならないのか？
- 多少なりともこの方法でやり遂げなければならないのか？
この問いは、常に”あれ、なんかおかしい”と思った時に自問すべきだと思いました。
ちなみに、自分の場合どん詰まりになっていた原因は、技術的問題や制約ではなく、元を正すと環境が整備させていないが故に手段が限られてしまうというものでした。
環境の整備を同時に働きかけることで、どん詰まりから抜け出せたのは翌日、翌々日の話です。
38. 準備ができるまでは
なんとなく、思い当たる節があり、うなずきながら読んでいました。
その日、疲弊していた事柄についても（面倒だという気持ちをのぞいて）なんだか進んでよいのか、迷いが生じていたのですよね。
その迷いを、ただの怠慢だと片付けずに、本能に耳を澄ませることの必要性が書いてあり、勇気づけられました。
「本能をあなたの能力に貢献させる」。まずは、本能を研ぎすませたいですね。
また、不安材料を洗いだすためにプロトタイプを利用する方法も書かれていました。
ちょっとした簡単なコードを書いて手を動かしてみることで解決できる、見通しが立つことはびっくりするくらい頻繁にあります。
最初の1歩に迷った時に、小さなプログラムを書いて自分の進むべき道を見つけてあげる、そのくらいのプログラムは呼吸するように書ける、気持ちよく仕事をするために、身につけたい技術です。
39. 仕様の罠
設計を言葉にすることの難しさ、そして何より
「完璧な設計書を作成すれば、1mmも頭を使わずにプログラミングできるというのは間違いである」
という強いメッセージを感じたセンテンスでした。
- プログラミングには必ず人間の解釈が必要
- コーディング担当者に解釈の余地を与えない設計というのは良い設計とは言えない
生産的な仕事をしたい、と思っている自分には力強い言葉でした。
また、設計（仕様を策定すること）と実装は切っても切りはなせないものであり、きちんと境界なしに流れていくべきものである、という部分にも大いに納得しました。
40. 丸と矢印
「形式的方法論の奴隷になってはいけない」
この章はこれがすべてですね。
ちょうど10年前と言えば、UMLがでてきて
「UMLでプログラミングのすべてを表すことができる！」
「UMLとオブジェクト指向でコードを自動生成できる、生産性があがる！」
という話が一部で出てきた頃だったんじゃないかな（そういう本を読んだことがある）と思い返していました。
そういう考えによる弊害、もっと考えなければならないポイントについて、たくさん書かれていました。
特に、形式方法論は専業化を奨励してしまい、コミュニケーションの定価と努力の無駄遣いにつながりやすい、という話はなるほどな、と一番納得しました。
この本で書かれている「VS ○○ と敵をつくらない」「全員がシステム全体を理解しながら進むべき」というのは、今読んでいるアジャイルサムライの中でもチーム像として書かれていることでした。
ただ、形式的開発方法論を学ぶ必要がないというのではなく「とらわれずに道具箱にはいれておく」、知った上で良い使い道を見つける、それが達人プログラマなんだなあ、と。
一通りきちんと学んだ上で、取捨選択できるプログラマでありたいと思いました。
今年の読書会はこの回で終了です。
来年もよろしくお願いします。