Planet EZO

1月25日(水)に行われた、達人プログラマー読書会@札幌に参加しました。
本日が最終回。最後まで参加して、本を読み通す事ができました！（途中2回休んだけど）
最後の2つのセクションが心に響きました。

43. 容赦ないテスト

「早めにテスト、何度もテスト、自動でテスト」
というヒント62に尽きるね、という話になりました。
テストの大切さ、そしてそれがなかなか現場で実践できていない事、今も昔も変わらない。
根本的なところは変わらないけれど、TDDの流れの源流（テストのテストをするための破壊工作など）を感じる部分もありました。
テストそのものよりも、テストデータを作る事が大変な事が多いのだけど、スクリプトを作ればもう少しうまくやれる事が多いのかもしれないという気づきがありました。

44. すべてはドキュメント

いらないドキュメントをたくさん作るのではなく、コードとドキュメントを一体化させる事。
ドキュメントの原本は1つにする事。
マークアップ言語を使えば原本から様々な状況に適したドキュメントを生成できる事。
コードはドキュメントであり、コメントはとても大事な事。

昔、プログラムを始めた頃の自分のコメントは酷かったなあ。
今は、もう少しまともに書けている気がする。でも、まだまだだ。

未来の誰かがソースコードを読んだ時に「？」と引っかかる部分に対するメッセージをコメントとして残しておけるような、そんな書き方がしたい。
「コメントは”何故”を書く、目的やゴールを書く」
忘れないようにする。（ああ、最近TODOコメントが多い・・・）

45. 大きな期待

とてもよいセクションでした。
「達人プログラマ」の”プログラマ”的技術向上の話ではなく、「お客さんと向き合ってものをつくる」という事に対する心構えの話。
「ユーザーの期待をやや上回って、お客さんに嬉しいサプライズを与える」ような仕事がしたい！
アジャイルサムライでも書かれている「期待のマネジメント」について
「特権的な立場ではなく、ユーザーと一緒に作業をすることで期待とその実現方法をお客さんとチーム全体が共有していく」
と書かれていました。
「お客さんと一緒に」仕事をする大切さ。・・・そして難しさ。
読んでいて、ハッとさせられる事が多かったです。

46. 誇りと愛着

達人プログラマは自分の作った物に誇りと愛着を持つ。匿名で逃げてはいけない。
匿名性により、コードに責任を持たなくなり、ソースコードがどんどん酷い事になるプロジェクトを体験した事があります。その時は正直自分も「とりあえず動けばいいや、私に責任はないし」と考えていた事を告白します。
きちんと名前を書いて自分のコードに責任を持つ、責任を持てるコードを書けるようになる事を大切にしていけるプログラマになりたい。

「私はこれを記述した、そしてこの仕事の後ろには私がついている」

それがお客さんに対する品質の保証となれるような達人プログラマ目指して、これからも頑張っていきたいです。

最後に

昨年の7月から開始して計13回。
主催した@onjiro_mohyahyaさん、本当にお疲れさまでした！読了おめでとうございます。
隔週で同じ場所で読書会をやっており、勉強になるところがたくさんありました。
輪読のセンテンスの区切り方はかなり参考にさせていただいていました。
これからも勉強会などなどでお会いすると思いますので、よろしくお願いします！

新年あけましておめでとうございます。
2012年1回目の勉強会は1月10日(火)に行われた、達人プログラマー読書会@札幌でした。
「チーム」という最近ずっと興味を持っていることについてまったりと語らいました。

第8章 達人のプロジェクト

この章では、達人プログラマがプロジェクトに入ったら、どうなるか、どうすべきか、という事が書いてあります。
達人が集まるプロジェクトチーム、最強だなあと思います。
また、チームとして集まる事で、達人だけではなく達人「なりかけ」の人の力もたくさん引き出していけそうな（引き出させてもらえそうな）。

「成功とは見る人が判断するもの、プロジェクトの場合見る人はスポンサー、だから、スポンサーの大きな期待に応える事が大事」

心に留めて読み進めていきます。

41. 達人チーム

達人の技法が集団としてのチームにどう適用できるのか。
よくも悪くも染まりやすい自分としてはうなずく事がたくさんありました。

• 品質を気にかけないチームに配属されると、どんなに優秀な開発者でも面倒な問題を修正する情熱を維持しづらく感じる
• プロジェクト開発における環境全体の温度に気をつける、ということは難しい
• チームも組織の一員であり、他の世界と情報交換しあわないといけない
• しっかりと準備されたパフォーマンスがチーム全体を心地よくする

この辺りのチームのあり方、気持ちの持ち方、モチベーションについて、ずっと誰かに引っ張ってもらってきた（幸いにも良い形のチームである事が多かった）ところです。
これからは、自分がこのようなチームを作り上げていく力の一つになりたいと思う。

また

• 機能によってチームを分ける事で二重化を減らす
• プロジェクトの諸活動（分析、設計、コーディング、テスト）を別のものとして独立させることは問題を発散させてしまう事につながる
• 実際のユーザーから2〜3階層離れたプログラマーは、自分たちのコードが実際に使用される際のコンテキストについて、あまり注意を払わないようになる

この辺りはまさに「大規模開発をやっている職業プログラマ」時代に思い当たるところがたくさんありました。
コードのコンテキストについての意識は常に持っていたい。

42. どこでも自動化

今、業務で「Maven」を使用している事もあり、自動化の重要性、便利さ（そして使いこなすまでにはちょっと苦労する事）などを感じていたところでした。

「プロジェクトの整合性と再現性を保証」するためには、なるべく手動の手続きは入れない方がよい。
ただ、細かい部分の自動化にどこまで時間を使うか、は判断を迷う時が結構あります。
（最近だと、Excelにコピーしてデータ量順にソートして終わりにするか、ソート用のプログラムを作るか、など）

自分は細かい部分（自分だけの作業）だと、手動でゴリゴリやりがちなので

「コンピューターの方がうまくやってのけるような繰り返しや俗っぽいことはすべてコンピューターに任せてしまう」

ようにしていきたいと思います。
そして、労力をかけずにそうできるようになりたい。

次回で達人プログラマ読書会は終了（予定）です。
約半年間、あっという間だったなぁ。
最終回もきちんと出席したいです。

12月13日(火)に行われた、達人プログラマー読書会@札幌に参加しました。
この日は、仕事でかなりやられていて絶不調でした。
しかし、参加してそんな絶不調の原因を知ることができたのでありました。

37. 不可能なパズルを解く

「制約を認識すること」と同時に「自由度を認識すること」。
”それは本当にだめなことなのか？制約なのか？”・・・・ハッとしました。
その日、まさに「もっと簡単な方法があるはずだ」という発想の転換をせずに、ひたすら”この方法しかない”と信じ込んで、そして、疲弊していたのです。
218ページに書いてあった自分への問い

• 簡単な手段は存在するのか？
• 正しい問題を解決しようとしているのか、それとも末端の問題に迷っているだけなのか？
• 何故それが問題なのか？
• 解決を難しくしている真の原因は何なのか？
• この手段でやり遂げなければならないのか？
• 多少なりともこの方法でやり遂げなければならないのか？

この問いは、常に”あれ、なんかおかしい”と思った時に自問すべきだと思いました。

ちなみに、自分の場合どん詰まりになっていた原因は、技術的問題や制約ではなく、元を正すと環境が整備させていないが故に手段が限られてしまうというものでした。
環境の整備を同時に働きかけることで、どん詰まりから抜け出せたのは翌日、翌々日の話です。

38. 準備ができるまでは

なんとなく、思い当たる節があり、うなずきながら読んでいました。
その日、疲弊していた事柄についても（面倒だという気持ちをのぞいて）なんだか進んでよいのか、迷いが生じていたのですよね。
その迷いを、ただの怠慢だと片付けずに、本能に耳を澄ませることの必要性が書いてあり、勇気づけられました。
「本能をあなたの能力に貢献させる」。まずは、本能を研ぎすませたいですね。

また、不安材料を洗いだすためにプロトタイプを利用する方法も書かれていました。
ちょっとした簡単なコードを書いて手を動かしてみることで解決できる、見通しが立つことはびっくりするくらい頻繁にあります。
最初の1歩に迷った時に、小さなプログラムを書いて自分の進むべき道を見つけてあげる、そのくらいのプログラムは呼吸するように書ける、気持ちよく仕事をするために、身につけたい技術です。

39. 仕様の罠

設計を言葉にすることの難しさ、そして何より

「完璧な設計書を作成すれば、1mmも頭を使わずにプログラミングできるというのは間違いである」

という強いメッセージを感じたセンテンスでした。

• プログラミングには必ず人間の解釈が必要
• コーディング担当者に解釈の余地を与えない設計というのは良い設計とは言えない

生産的な仕事をしたい、と思っている自分には力強い言葉でした。

また、設計（仕様を策定すること）と実装は切っても切りはなせないものであり、きちんと境界なしに流れていくべきものである、という部分にも大いに納得しました。

40. 丸と矢印

「形式的方法論の奴隷になってはいけない」
この章はこれがすべてですね。
ちょうど10年前と言えば、UMLがでてきて
「UMLでプログラミングのすべてを表すことができる！」
「UMLとオブジェクト指向でコードを自動生成できる、生産性があがる！」
という話が一部で出てきた頃だったんじゃないかな（そういう本を読んだことがある）と思い返していました。

そういう考えによる弊害、もっと考えなければならないポイントについて、たくさん書かれていました。

特に、形式方法論は専業化を奨励してしまい、コミュニケーションの定価と努力の無駄遣いにつながりやすい、という話はなるほどな、と一番納得しました。
この本で書かれている「VS ○○ と敵をつくらない」「全員がシステム全体を理解しながら進むべき」というのは、今読んでいるアジャイルサムライの中でもチーム像として書かれていることでした。

ただ、形式的開発方法論を学ぶ必要がないというのではなく「とらわれずに道具箱にはいれておく」、知った上で良い使い道を見つける、それが達人プログラマなんだなあ、と。
一通りきちんと学んだ上で、取捨選択できるプログラマでありたいと思いました。

今年の読書会はこの回で終了です。
来年もよろしくお願いします。