irasally

新年あけましておめでとうございます。
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 ○○ と敵をつくらない」「全員がシステム全体を理解しながら進むべき」というのは、今読んでいるアジャイルサムライの中でもチーム像として書かれていることでした。

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

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

11月28日(月)に行われた、達人プログラマー読書会@札幌に参加しました。
テストの話やプロジェクトの話など、今も大切だとされていることが10年前に書かれていたことに驚きました。

34. テストしやすいコード

• テストによりコンポーネントの信頼性を高めることができる
• コードの実装を開始する前にテストを作成することでインターフェースのテストをしている
• テストは手近なところになければ使われない
• テストは繰り返し実行されなければいけない
• テストは技術というよりも文化

この短い章の中に、ユニットテスト・テストの自動化・CI・TDDなどの重要性がすべて書かれていました。
これらのことが重要である、とこの頃から言われていることにまず驚きました。すごい本だ。
「場当たり的にデバッグでテストを済ませない」であるとか「プロジェクトにテスト文化を植え付ける」であるとか、今、まだできていないことがたくさんあります。
テストの書き方にもまだまだ悩みます。
「テストは文化」とは、まさにそうだなと思います。
今のプロジェクトにはテスト文化を広めてくれる指導者がいます。おかげでさぼらずにテストを書く、テストから書くという習慣（思考の変化）ができてきました。
これからも精進したいと思います。

35. 邪悪な魔法使い（ウィザード）

新人〜2,3年目の自分に読ませたかった章。
何となくソースコードが書けるようになってきた頃に陥りがちなこと、それは
「フレームワークが何となく使えてればコードが書けている気になる」です。
でも、それだと自分が何を書いているか（どんなバグを埋め込んでいるか）ちっともわかってないのですよね。

• 作り出されたコードの意味が本当に理解できていなければ、自分自身をだましていることになる
• 生成されたコードが理解できないようなウィザードを使うということは、自身のアプリケーションのコントロールを放棄することに等しい

昨今は開発を加速化するため、便利にするために作られた素晴らしいフレームワークやウィザード形式のコード生成ツールなどがたくさんあります。
それらのコードをすべて理解しなければ使うな、ということではなく、

1. 何が起こっているか（少なくてもどんなソースがどこにできているか）を理解しておくこと
2. いざとなったらきちんとソースを解析できること
3. 自分がそのソースコードに手を加える際に適当になんとなくコードを書かないこと

これらを意識しておくだけでも「自動生成コードに振り回されない」プログラマになれると思います。

36. 要求の落とし穴

ここから第7章「プロジェクトを始める前に」に入ります。
お客様の要求を捉える、掘り起こすという、ちょうどアジャイルサムライ読書会でも行っているテーマでした。
どちらも同じことを言っていました。

• 要求が表面上に現れていることはほとんどない
• 最終的な目標はお客様のビジネス上の問題を解決すること
• 要求の掘り起こしは、ユーザーとの親密な関係を築いていく始まりの時
• 要求とは設計ではなくニーズそのもののこと

一つニュアンスがアジャイルサムライ（アジャイル開発）と異なるなと感じたところは
「お客さんは何もわかっていないから開発者がすべてのお客様のニーズをうまいこと引き出す必要がある」
という立場が達人プログラマの方が強めに書かれているなというところでした。
アジャイルサムライでは「お客様がプロジェクトチームの一員となる」ことの重要性が説かれています。
「ユーザーと親密にならなければよいものは作れない」という考え、目指すところは同じですが、アプローチの方法が若干違うなぁと思いました。

名前大事

この章の後半に書かれている「プロジェクト用語集」は本当に大切で、しかし、往々にしてプロジェクト途中で空中分解してしまうもの、です。
プロジェクトの終わりの方には全然更新されてない「（参照してはいけない）用語集」がサーバーに残っていたり・・・。
wikiを使うのも一つの方法かもしれないし、SVN管理することで自分のアクセスしやすい場所においておくこともできるのかな、と思いました。
そして、なにより、開発者間、開発者とユーザー間で「名前大事」という感覚そのものを共有することが大切なのだな、と感じています。

みんなに知らせる

wikiの重要性。2年前だったら言っていなかったと思うこの言葉。「wiki大事。」
使ってみなければわからないとはまさにこのことだよなー、とこの1年ちょっとで実感しております。

だいぶ、本の終わりが見えてきました。
最後まで頑張ります。