日々の破片

_ 鶏のハツ

四谷の丸正に行ったら100gあたり128円という切りが良い数字で南部鶏の心臓を大体200g単位でパックしてあるのを売っていた。

子供が食べたいというので、適当にフライパンで塩振って乾煎りすれば良いだろうと買って帰って、一応調理法を調べるかとぐぐると、2つに切って残った血を洗えとか上についている脂肪を落とせとかある。

血のほうはもっともだと思ったので、脂肪は面倒だからそのままでどんどこ2つに切って行くと、なるほど、大体は血抜きできているが心房の位置関係か塊になった血が残っているのがある。

とすると一見無いように見えても奥の方に固まっている可能性はある。

しょうがないので、全部2つに切って、流水で親指の爪を入れてこそぎ落としていく。面倒だな。でも確かにこれだけ塊が入っているとそのまま食べたら不味そうではある。

で、終わったあと濯いだ元のトレイに入れて塩振って、フライパンに火をかけた。

トレイにたまった水を流して、えいやとフライパンに入れたら（メイヤーのやつなので油は引かなかった）思ったよりも水が残っていて、乾煎りではなく煮ている状態になって不安になる。

鶏である以上は火を完全に通さないと怖い。

しかし火を通し過ぎると水が抜けきって（収縮するから）固くなる。それもいやだ。

とか考えながら3分くらい菜箸でかき混ぜながら炒めるというか煮てから蓋して、タイマー3分に設定した。

そしたら2分過ぎたあたりからパチパチ言い出した。

水が抜けて、溶けた脂肪で揚げ物状態に変わったのだった。

なら固くなる心配はほぼ無い。

で蓋を外して油の中を転がしながら残り1分、中まで火が通ったのを確認して、さらに塩を少し振っておしまい。

1つ1つ半分に切って血を洗うのがくそめんどうだが、それを除けば、とても良いものだった。脂肪はほぼ揚げ油と化していたので、取る必要はなかったし、かえって一部とはいえ表面がカリッで中が心臓のふしゃふしゃ状態でえらく美味かった。

_ Clean Agile 基本に立ち戻れ 読了

アスキーの鈴木さんからもらって金曜日に着いたので3日かけて読了。

おもしろかった！

雰囲気としては、Clean Architectureの末尾の蛇足の発展型っぽく、筆者のロバート・マーティン（ボブおじさん）が、これまでのソフトウェア開発者、アジャイル組織者（2001年のアジャイル宣言オフ会はロバートマーティンがアリスター・コーバーン（Crystalの人）と一緒に集めたメンバーで宣言された）などなどの経験と知識から、アジャイルとは？ について放言する、に近い。

要はかっちりとした本を読むというよりは、ロバート・マーティン講演会でおじさんの思い出話や知見や考えを聞いている感じだ。がちがちの技術書ではないだけに、アジャイルっぽい（最近耳にしなくなった言葉だが）生き生きとした読書体験を得られた。

つまり、本書を読むということは、ロバート・マーティン講演会を楽しむという体験だ。

そのため、（読者によるだろうが）、はて、おれはこのような場合はどうしていたかな？ とか、そこはディスアグリーとか、こちらの思考を実に広げてくれる。おもしろいなぁ。

本文は7章と結論からなる。

各章は、以下だ。

第一章 アジャイル入門。アジャイル宣言前夜（もっと長いけど）からアジャイル宣言までの思い出話から、そもそもアジャイルとは何かについて、本質を語る。

本質は意外と単純なことだ。動かないソフトウェアは製品ではない。ソフトウェア開発者の仕事は発注者が求めるソフトウェア（最初の文から動くこと）を提供することにある。そのためにはどうしたら良いか？ だ。ここで重要なのは、いかにソフトウェア開発者がビジネスに寄り添うか、にあると読んだ。ビジネス価値を提供できるか？ と言っても良い。

そのために、確実にソフトウェアを動かすための方法を分解して求めていく。

ビジネスには期限がある。ただしく見積もるためには、ただしい判断材料が必要で、判断材料の粒度を揃える必要がある。実際に開発して必要となった時間を調べ、そこから全体を見積もっていく。机上の戯言ではない着実な方法はどのようなものか？ （計画ゲーム）

正しく動くソフトウェアは正しさを検証可能な単位で行う必要があり、これも粒度の問題となる。（小さなリリース）

ではリリースのためには何が必要か？ もちろん動くソフトウェアだ。動くとは？ （受け入れテスト）

で、誰が作る/製品に責任を持つのか？ （チーム全体）

と詰めていく。

それがアジャイルである。

2章はアジャイルにする理由。きわめて簡単だ。ソフトウェアをリリースするため、だ。で、一体それはどういうことだ？ ということを行動指針（開発者の権利章典）として示す。とはいえ、お前ら開発者はビジネスのことはわからんだろうから、マネージャがどういう思考方法をして、どういう期待をしているかを知ることで、どうしなければならないかの秘伝を教えるという章。

3章はビジネスプラクティス。計画ゲームってわけがわからないのはおじさんにはわかっている。その説明。開発者とビジネスを一体化するためにはどう振る舞えば良いかについて。

4章はチームプラクティス。きわめてわかりにくいメタファーについての説明から始まる。絶対、日本語で「例え話」としたほうが良いカタカナ用語だ。

で、結論は、まじめに仕事してまじめに休んでちゃんと食って寝ろ。

5章はテクニカルプラクティス。TDD、リファクタリング。テストなくしてデリバーなし。ペアプロもするでよ。

6章はアジャイルになる。ここはボブおじさんの独演会。

大規模アジャイル？ ばかじゃないの？ 人類8000年の歴史は大規模で何をするかとっくにわかってるじゃん。ピラミッド作ったのは人類、第2次世界大戦みたいなビッグプロジェクトを成功させたのはおれたち（ボブおじさんが主語）アメリカ人、どやどや。そういうビッグプロジェクトをこなせるおれたちが大規模ソフトウェアプロジェクトで失敗するってどういうことでしょう？　答えは簡単、それは無理ということなのだ。（でっかな羽を両腕に括り付けて羽ばたいて崖から落ちて死屍累々のあとに、ライト兄弟がプロペラをつけた乗り物で空を飛ぶことに成功することを、おれは思い出した）

だから、小規模に分割する。各プロジェクトは5人くらい。ほらできた。

コーチ？ ばか？ そんなもの不要に決まってるじゃん、とか散々放言してちょっと考えたのか、別の人のコーチングについての別視点の論考を入れたりしている（この論考の結語をロバート・マーティンが書いているのだが、額面通りに読んで良いのかどうかわからん）。

7章 クラフトマンシップ。ボブおじさんが最近提唱しているらしき仕事への取り組みフレームワーク（雑なまとめだが、そういうものと取れる）を別の人が書いている。まあ、大規模についての、そんなの無理に決まってるじゃんから導かれるソフトウェア開発の姿を人類史に探せば、ドイツマイスター（徒弟制度）や、日本の大工や料理人（目で盗み腕で覚える）とかに近いものになるのはわかる。ただし、そのあたりの連中と違ってコンピュータが使えるのがこちらの強みなので、別の姿も浮かび上がってくるとも言える。

で最終章にあたる「結論」おしまい。

途中、80:20の法則が出てくるが、アジャイルも同じだ。各大きなプラクティスの下の個々のプラクティスの20%を実行するだけで80%の効果は得られるだろう。おれが考えるには、柔軟に運用できる計画ゲーム、TDD+リファクタリング（ただし、おれはスタートダッシュというアプローチが実は良いのではないかと考えている。スタートダッシュでは一切何も考えないでコースだけを突っ走る。当然ペアも無し、テストコードも無し）、継続的デリバリ（ビルド時に常にテストスイーツを実行しソフトウェア全体が壊れないように管理する）、テストスイーツ（自動化）、デプロイツール（おれの場合だと板前）、SCMシステム（というか現時点ではGit一択だろうし、CircleCIとの統合などを含めればGithubと言い切っても良いのではないか）が最重要と思う。

というわけで読みながら自分の来し方を再点検したのは大きなポイントだった。

いずれにしても、読み物として抜群におもしろい。特に、アジャイル原理主義というかアジャイルドグマを持ってしまった人にお勧めしたい。重要なのは基本であって、教義ではない（原理というのは基本ではなく、誰かが作った教義だよ）。

Clean Agile 基本に立ち戻れ(Robert C.Martin)