2013/3/22(金) 「java-ja.ddd」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/1934/Togetter
http://togetter.com/li/463570恐るべき人気。申し込み開始初日で200人くらい一気に埋まったんじゃないでしょか。
かくいう私も補欠30番目くらいに並んでて、当日なんとか繰り上がって参加できました。
場所は六本木ヒルズ森タワー、GREEさんです。参加者は150人くらい？でしょうかね。
ちなみにGREEさんから無料のビールとピザまで振舞われました。GREEさん流石！ありがとうー
この日のテーマが「ドメイン駆動設計」ということで、前々から楽しみにしていました。
というのも、先日のGOOS勉強会で和智さんや参加者さんからも以下の書籍をオススメされたのです。
ということで、ちょうど買って読んでる最中でした。
ちなみにGOOS読書会に参加したときに書いたブログはこちら。↓
以下、自分用に取った講演メモ。
■第一部 ざっくり DDD 入門！！・発表者 : 和智 右桂さん
■最近、「組織パターン」という書籍の翻訳をやっている。発売は6月くらいになるかも。
■今日のDDDは、実践部分は増田さんが話すので、和智さんはエッセンス部分を話す予定とのこと。
■書籍「ドメイン駆動設計」の前書き：「ソフトウェアは複雑だ」
・2003年に英語版をエリック・エバンスが書いた。
・日本語版の翻訳版が長いことでなかった。２０１０年くらい。
・サブタイトルに「ソフトウェアの複雑さに立ち向かう」とある。
・まえがきに「複雑なのはドメインそのもの」とある。
・テクノロジーの難しさはあるが、業務の複雑があるだろう、というのがドメイン駆動設計。
■業務知識とは？
・いろんな側面がある。ではシステム開発をする上で必要な業務知識とは？
- どういうデータが流れているんだろ？
- どんなルールがあるんだろ？
- どんな演算がされているんだろ？
- システム間連携でどういうやりとりをしているんだろ？
・これら業務知識を学ばねばならない
■自社ならまだマシ。お客さんの業務を学ぶのは手探りになる。
■自分が手がけたシステムで、「このシステムのことがわかった！」と思った工程はいつか？
・和智さんは結合テストが多いとのコトで、コードをガリガリ書いている時はよくわからなかったとのこと。
・お客さんの視点に立てるのはけっこう後の工程。
・ちょっと怖いなぁと思うのは、よくわからないままソフトウェアを作ってること。それで本当に大丈夫なの？
■業務知識を反映させることで、ソフトウェアを柔軟に変更したり拡張したりできるようになる。
■業務知識をそれほど反映しないソフトウェアとは？
・8割くらいはトランザクションスクリプト（※１）で書いている。
・モジュール化は処理の種類に行われるので構造が安定する。
・でも、その中で何をやってるかは、コードを読まないとわからない。
・ただ構造が安定するので30～40人くらいだと、ガバナンスが利き易いメリットはある。
・ただしこれだと重要なドメインが埋もれてしまう。
■※１
「トランザクションスクリプト」という単語を知らなかったのでググってみた。
このへんの記事が参考になると思った↓。
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」
http://d.hatena.ne.jp/higayasuo/20080519/1211183826[ソフトウェアアーキテクチャ][PofEAA]トランザクションスクリプト
http://d.hatena.ne.jp/asakichy/20120612/1339451426■例：
・ホテルは満室でも、キャンセルを見込んで予約を止めない。
→ オーバーブッキングを見込んで多めに予約を受け付ける。
・これをトランザクションスクリプトで描くと、このようなIF文がかかれる。（DDD本のP.18あたりのコード参照）
・重要なロジックなのに、他のコードに埋もれる。いろいろな些末なロジックに埋もれる。
・これじゃあ業務知識を反映できているとはいえない。
・じゃあどうするかというと、「制約をコードの中で可視化する。」
・オーバーブッキングポリシークラスとして抜き出し、コードで可視化する。
・ただし極限まで突き詰めるといいのか、というとそうじゃない。バランスが重要。
・バランスを考慮しない設計として、「エンタープライズFizzBuzz」というのがある。これが良いわけがない。
■あらゆるIF文をオブジェクトに変えよう、というのは正しいのか？
→ それは間違っている。柔軟でもなんでもない。
■複雑なドメインの設計は、モデルを元にしてください。
・ドメインとは、モデルの専門家によって整理され単純化された世界
・整理も大事だし、単純化も大事。
・ドメインエキスパートとモデルを共有しましょう。
・ドメインの専門家といっぱい会話して、モデルを共有しましょう。
・エリック・エヴァンスのホームページに、どうやればいいかが書いている。本には書いてない。
■Domain Language Model Exploration Process
出展：
http://domainlanguage.com/ddd/whirlpool/・Whirlpoolでシナリオから入る。どういうことをやらないといけないのか。
・そのあとモデルを描く。そのあと特殊ケースとかをシナリオに戻す。
・それを２～３日やって、コードを書きたいなぁとなったら、 「Code Probe」に入る。
・コードを使ってモデルを通してみる。
・それをやってみると、大丈夫そうなモデルが、落ちたぞとかわかる。そうやってシナリオに戻ってくる。
・それを繰り返す。
・そろそろわかってきたから、本当か確かめてみるか、みたいなノリ。
・イテレーティブかつインクリメンタル。
・これをウォーターフォールにハメるにはテーラリングが必要かも。
■モデルだけ作って後はよろしく、はダメで、それをソフトウェアに反映させましょう、というのがドメイン駆動設計。
■ところで、「モデル」と言われてどんなものを思い浮かべますか？
・とあるエンジニアは、ロバストネス図を描いていた。
・でも、ここで考えるのは業務のモデルなので、シンプルに考えるとER図になることが多い。
・それだけではなく、ルールとか重要な演算とか特別な仕様もオブジェクト指向の力を借りて表現したものとして「モデル」を考えるとわかりやすいんじゃないか。そういうのが埋め込まれたER図として考える。
■ドメインエキスパートとは
・実際に業務を回している人よりも、全体として何が起こっているかを把握している人。
■質問１：
ドメインエキスパートと会話しよう、とあったが、実際そんな人いるのか？
■質問１の回答：
・ドメインエキスパートを探すのは大変、とエリック・エヴァンスも言っている。そんな人はきっと忙しいだろうし。
・でも、そういう人はいる。どうやって探すかは和智さんもいい方法は知らない。
・システムの運用が回ってればそういう人は見つかりやすいかも。
・運用をアウトソースしてると、見つからなかったりするかも。
■質問２：
業務のキーマンだけどシステムに詳しくない人はドメインエキスパートとは呼べないか？
■質問２の回答：
・コードは書けなくても、データの構造は少なくともわかってたりする人とかはドメインエキスパートと言える。
・本の中だけでいうと、何を作るかの先に、作ったものがどれだけ価値をもつか、という話がある。
→ そういう話はドメイン駆動設計からは外れてしまう。
・いわゆるオブジェクト指向のクラス図が、先ほどいったER図のようなもの。
■質問３：
ドメインエキスパートは複数いるのか？
■質問３に対する回答：
・プロジェクトマネジメント観点からいうと一人に絞りたいというのはある。
・でも業務によるが、これはこの人、というのがある。なので複数の場合もある。
・ドメインエキスパートはプログラム書く人と別の人、とあるが、同じ場合もある。
・ドメインエキスパートはその業務の専門知識をもつ人。その人がJavaやDBのエキスパートのこともありえる。
■質問４：
そもそもドメインが整理されていない会社があって、整理しましょうとなったら、誰にやってもらえばいいのか。
■質問４に対する回答：
・DDDの本でいうと４部に戦略的設計というのがあって、複数のドメインをどうすれば良いかが書かれている。
・具体的に誰が意思決定をするのかは一概に言えないが、ある概念が同じ意味を持つのはどこまででしょう、
というのがポイントかも。
・「Conwayの法則」というのがある。
→ 「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
・システムは人の集団の構造に似てしまう。大きな会社では部署が分かれているので、部署がドメインの境界になるのもありえるのでは。
■質問５：
ドメインエキスパートがいる時点でブルーオーシャン（※２）ではないのでは？
（※２）ブルーオーシャンとは：
2005年2月に発表されたフランスの欧州経営大学院教授のＷ・チャン・キムとレネ・モボルニュの著書
『ブルー・オーシャン戦略』により提唱された市場の定義。
まだ誰も参入者がいない競争のない新たな市場空間のことを指す。
出展：
http://d.hatena.ne.jp/keyword/%A5%D6%A5%EB%A1%BC%A5%AA%A1%BC%A5%B7%A5%E3%A5%F3■質問５に対する回答：
・そうかもしれない。
・なにか新しいものを作る時、何を作るかを当然考える。
・複数人で考えるときは、議論をする。
・その議論の過程を結果として残しつつ、ソフトウェアに反映していくのが健全だと思う。
■参加者からの発言
・ドメインを考えるとき、物流より図書館を想像するようにしている。
・物流だとゴツイおっさんが無理なことを言ってくるイメージ。
・図書館だとかわいい司書さんがいてヤル気でるなぁ、みたいな。
★休憩時間に和智さんからDDD本にサイン貰いました～
和智さんは人柄がとても穏やかで、物腰も丁寧です。私が尊敬するエンジニアの一人です。
第二部 ガッツリ DDD 実践編！！・発表者 : 増田 亨さん
■みなさんが持ち帰れる話でないかも。。。
■トランザクションスクリプトを越えてリッチなドメインモデルを作ろう。
・キレイ事じゃないので上手くいかないことがある。
・名前とか言葉が気になっている。そこの捉え方が上手くいくと、仕事も上手くいく。
■ちなみに、DDD本の原著は「ドメインエキスパート」はほとんど複数系になっている。
■「DDD難民」という言葉もあって、「DDDは分かり難い」と言われていた。
・でも、私はそう感じたことがなかった。
・それは、前提となる経験とか知識がDDD難民の方と違っているんだな、と気づいた。
・P.3の前提書籍の知識がないと、読んでもピンとこない。
→ オブジェクト指向でソフトウェアを作る話がこれらの本にあって、それで初めてDDDがわかる。
・DDD本だけ読んで素晴らしいことがわかる、ということはない。
・前提書籍も嗜み程度には触っといたほうが良いのではと思っている。
■私がドメイン駆動設計への道を歩んだ過程
・最初は、大きな泥団子。
・このプロジェクトが火を噴いた。
・そこに呼ばれて「なんとかしてくれ」と言われたのがドメイン駆動設計を必死に勉強するきっかけだった。
■リッチなトランザクションスクリプト
・非常にシンプルなドメインモデルにしただけで、どこで何をしてるのかが見やすくなった。
・型安全の恩恵を受けれるようになった。
・でも、「ドメイン駆動設計」を読んでると「なんか違うな」と思っていた。
→ いろいろやってみようか。
■リッチなドメインモデル
・これが今日のテーマ。
・業務の言葉で組み立てる。
・小さなオブジェクトを大事にする。
・ただ、「そういうふうにしないとうまくいかない」と言うつもりはない。
■なぜこうしたかと言うと、お客さんが泥団子をメンテするコストを払えなくなったから。
■ドメインモデルの開発
・モデリング
・プログラミング
・リファクタリング
■イテレーティブというより、毎日やっている。
・過去のコードは絶対汚い。
・どうせ弄るんだったら、こうやれば保守しやすくなるなあ、と一日に何回もそれを回す。
■名前に違和感がある、という感覚が改善されてくると、ドメインオブジェクトもよくなってくるなぁ、と感じた。
■プログラミングは名前探し
■コードを書くとなると、嫌になるほど名前を考えないといけない。
・これを業務の言葉で埋め尽くす。それにどれだけこだわれるか。
・ソフトウェアのネイティブな感性でなく、業務に如何にこだわって合わせるかが、ドメイン駆動設計。
■ぶっちゃけ、ドメインエキスパートなんていやしませんよ。
・でも、自分より業務を詳しく知ってる人はたくさんいる。
・情報源としてのドメインエキスパートはいる。その人と仕事をしないとうまくいかない。
・ただし、彼らの言うとおりに作っただけでは、良いものはできない。
■業務の言葉をオブジェクトで書くのは、技術屋としては難しい。
・でも、これを「面白い」と思えないならドメイン駆動設計はやめたほうがいい。
・ソフトウェア開発であれば必ずドメイン駆動設計でやれ、とは思っていない。
・でも、お客さんに価値を届けたいならやったほうがいい。しかし自分に合うかどうかは別問題。
■基本データ型を１個１個ラッピングしていく。例えばlong型フィールドだけもった番号オブジェクトを作る。
■聴衆からの質問： 日本語で名前つけるか？
・増田さんの回答：全部英語です。
■基本的にはかなり小さいオブジェクトにして、ルールとか情報をラッピングする。
・すごく小さい単位。そういうオブジェクトをたくさん作っていく。
・ファンダメンタルなオブジェクトを如何にうまく整備して育てていくかが、良い仕事ができるポイント。
■設計パターン
・一番走るメインのルーチンはトランザクションスクリプトのようなものとなる。
・そこにたくさんのロジックを書くのではなく、委譲する。そのようなトランザクションスクリプトとする。
■やりとりするオブジェクト
・出来事（イベントオブジェクト）
・記録
・通知（記録しただけじゃなく、通知する）
・参照（エンティティパターン； 識別番号でたぐっていくと、識別番号でタグづけされた情報を取得できる）
■オーバーブッキングポリシーは業務でそのままつかってるから、ポリシーとして抜き出すのは設計としてアリ。
・そうじゃなく、業務側がそういう認識をしていない場合は、、ポリシーパターンとして抜き出すとたいてい失敗する。
・ムリに抜き出すと、仕様変更とかタイミングがずれる。そこでヘタに共通モジュールにしてると変更が大変になる。
■コードの重複を避けるのに共通化するのはよくあるが、業務として本当に必要かは、こだわってほしい。
・言葉は、業務とか会社で違ってくる。これを如何にオブジェクトとしてソフトウェアにするかが超重要ポイント。
■役に立つドメインオブジェクトとは？
・だいたい共通の性格がある。
★良い名前
★小さく作ってある
★ばらばらにする
→ これらを意識してやるようになってから、仕事が楽になった。
■良い名前の見つけ方
(1) 語彙を増やす
・子供が言葉を覚えるように、エンジニアも調べたりして語彙を増やすこと。
・人とのインタラクションを持たないと語彙は増えない。
・プロジェクトの初日に、ぜったいに語彙を見つけにいくべき。
・例えば、サービスについて解説している入門編、ガイドブックとか、ヘルプ画面とかから探す。
・パッケージ開発なら、類似のパッケージソフトのカタログから語彙を探すのも有効。
・これらの語彙を英語名にする。初日に、この英語版を探すべき。
・良い語彙を見つけてしまえば、クラス名とかに苦しむことは減る。
・初日にクラス名とかの有用な情報を手に入れるために、その分野の解説書とか入門書を読みなさい。
→ 初日に丸一日かけてもよいからやるべき。
・英語力はそれほど必要ない。
・自分がクラス設計するのに便利なものを見つけたいが、便利なものは山ほど見つかるので活用してほしい。
・人と会話するのが良い。出てくる言葉の頻度とか、会話に興味を示してくる人とか、関心度とかが分かるので。
・人は、そういう濃淡で仕様変更を言い出すに決まっている。なので、その人が何に興味があるかを早めにに知る。
・初めてのドメインでも早めにキャッチアップするのが大事。銀の弾丸まで行かないがが、凄く役に立つ。
(2) 正しく使う。
・これは難しい。
■こういう調査はチーム作業。対人は苦手なのでプログラミングだけやります、という人はNG。
・でも適材適所はある。全員がこれをやるべき、とは言うつもりは無い。
・相手の表情の変化に気づかないエンジニアがいる。そういう人とは仕事やりたくない。
■小さく作る
・クラス： 50行以内
・メソッド： 3行以内
・パッケージ： 10ファイル以内
これを越えたら分割を考える
そうはいっても、メソッド3行は難しい。。。実際にやってみると大変。
でも、この世界を味わってみることは絶対プラスになる。
■ドメイン層でtry-catchが起きるのは、ドメインモデルとしてはおかしい。
■3行メソッド
・メソッドを業務の言葉、業務の流れで書いていると、導いてくれる。
→ 追いかけるのが凄く楽になる。
■コンピュータのパワーアップとIDEの進化の恩恵にあずかる。メソッドの呼び出し元と呼び出し先を行ったり来たりとかは、今の開発環境だとわりと簡単にできる。
■実践の小技
・HowよりWhat。汎用部品を専用部品にする。
■dayOfFinalAlertというメソッド名の例：
・業務で言ってくる仕様とリンケージさせてメソッド名を付けるべき。
・その際、メソッド名を汎用的に「finalAlert」としようとするエンジニアと戦わなければならない。
・でも、「day of」が業務を的確に表すならば、「finalAlert」じゃなく「dayOfFinalAlert」とすべき。
・1日から1週に仕様変更になったら、「day of alert」から「week of alert」にメソッド名をを変えるべき。
■汎用部品を専用部品に
・Stringとかの汎用データ型をラッピングして、クラスにする。
・何でも屋を、目的特価・業務固有にする。再利用を目指すんじゃない。
・業務の根幹となるものは、他に持っていけるのはおかしい。
・「再利用」のための部品化ではなく、「業務」のための部品化を考える。
■enum
・タイプごとに振る舞いを持たせられる。
・業務的にはenumで押さえておくことが非常に多い。
■if ○○=nullとかの代わりにMissing Objectパターンを使う
■Map, Set
・パターンマッチをかけにいって、keyからvalueを取り出すようにするとifの必要性が減る。
■JavaのBean Validatorはすごく強力。
・IFをきれいさっぱり無くすことができる。
・仕組みさえわかってしまえば有効。
■コードでNULLが飛び交うことはあり得ない。その前提でコードを書きましょう。
・契約による設計、を意識する。
・AsertでNULLが来ないことを表明しておき、IFとかでチェックしない。
・このやり方は是非取り入れた方がいい。
■Collectionはそれ単独でオブジェクトに詰め込む。
・ファーストクラスコレクションだけでもやってみる価値がある。
■CollectionフレームワークのAPIは便利になっている。VMのバージョンが変わるたびに便利になっている。
■一手間かければforやifは大分減らせる。でも、なんでもかんでもやればいいわけではない。
■setterを使わない
・setterで状態を変えるな。コンストラクタで最初に情報は指定しておけ。
・そもそもsetやgetは業務の言葉じゃない。
・setterやgetterは必要なときに作る。（全フィールドに一律用意しない）
例えば、フレームワークでsetterが無い、と怒られてから作る。
■getterを使わない
・getしてデータを取ってきてから何かを処理するんじゃなく、そのオブジェクトに処理をまかせるべき。
・ロジックとデータを分けるな。
■パッケージ階層はフラットに
・構造がわかってない初期にパッケージを切ったり階層を作ってしまうと、あとで大変。
・役割分担が変わっても他に影響が少なくなるようにする。
・ドットつなぎになるコードは、その階層構造に依存してしまう。
・名前で見つけにいけるようになると、階層構造は鬱陶しくなる。
→ できるだけバラバラにしておいたほうがいい。
■継承は控えめに
・継承したほうが楽そうだから、というのはけっこう痛い目にあう。
■パッケージスコープを好む
・import文も少なくすべき。
・ドメイン設計だとそれほど呼び出す必要がないはず。importが多いと、「設計がおかしいのでは」と思うべき。
■第三部 俺にもちょっと DDD 喋らせろ！！発表者 : @t_wada さん, @j5ik2o さん
LTです。22時から開始でしたが、こちらも興味深いお話でした。
t_wadaさんは書籍「SQLアンチパターン」から「マジックビーンズ」を取り上げ、DDDに結び付けていました。
先日のDevloveで和田さんの講演を聞いて、この書籍を買いました。まだ全然読めてないので今後読む！
あと、最後の5分で増田さんが関数型言語についてトークされてました。
私もHaskellの勉強会に2年くらい参加してて、いろいろ思うトコありですが、それはまた今度。
★感想：さすが一瞬で満員になるようなイベントだけあって、質が超高い。話の内容が濃い。
DDD本の最初の方しかまだ読んで無い私でさえ、DDDの良さを十分に感じられる内容に纏まってました。
あとは、この書籍をきちんと読みたいと思います。しかし分厚いなぁ。。。
一人だとつらいので、読書会とかあるといいのになぁ。。。
最後に発表者さま、会場提供のGREEさん、java-jaスタッフさんはじめ関係者さん、大変有意義な場を提供いただきありがとうございました。
2013/3/21(木) 要求開発アライアンス 3月定例会『アジャイルとスクラム、要求開発に必要な実践知リーダーシップ』に参加してきました。
DoorKeeper（告知サイト）
http://redajp.doorkeeper.jp/events/2876場所は東新宿の日本総合システム株式会社さんで、参加者は40名くらいでしょうか。
ちなみに私、要求開発アライアンスは初参加です。
単純に、平鍋さんがアジャイルとスクラムのテーマで話すということに興味があり、参加申し込みしたのです。
以下、平鍋さんの口頭説明を中心に、自分用メモ。
■日本の中にある良いものが海外で抽象化されて、ソフトウェア開発に使われている。（トヨタのカンバンとか）
・でも、当の日本人はアジャイル開発が進んでいない。
・それが悔しくて、「日本にはこんな面白いコンセプトがあってアジャイルが生まれたんだ」と言いたい。
・日本に自然にあるコンセプトで日本人が得意としていることを言いたくて、本を書いた。
・１回目はインドで話してきた。日本で話すのはこれが始めて。
■今日のアジェンダ
1. Scrum
2. SECIモデル （これについては、野中先生と同じくらい熱く語れる）
3. 要求開発と実践知リーダー
■アジャイルソフトウェア開発スクラム
・最初のスクラムの本。読んだことある人少ないかも。
■6/38ページ
論文「The new new product development game」
・newがなぜ２回つくか → 2個目のnewは、Productにかかる。new [new Product].
・
バトンを渡すリレーのようなのはダメで、ラグビーのスクラムのようにやりましょう。■7/38ページ
Phaseの絵
・Type A： フェーズゲートを設けている。開発フェーズがきっちり分けられている。
・Type B： 開発フェーズの境界の凹みが少ない
・Type C： 開発フェーズが重なって、一体化している。
■8/38ページ
・楽天の川口さんが書いた絵「Agile and Lean」
・左の方にはトヨタ生産方式がある。
・Scrumは「The new new product development game」から引用している。
→ 野中先生の論文がScrumに影響を与えている
・XPもScrumもPatternsコミュニティから影響を受けている。
→ Scrumも最初、パターンの形でかかれている。XPも明らかにパターン言語。
→ 建築のパターンをソフトウェア開発に持ってきたのがケント・ベック。
・右側はアメリカとイギリスが中心の流れ。
・日本は強い影響を持っている。でも、日本人はコンセプトをコンセプトとして表現するのが苦手。
・英語でコンセプトを作り上げるのが大事。
■9/38ページ
・ジェフ・ザザーランドは空軍の経験がある。野中さんも海兵隊の本を書いている。互いに近い。
■10/38ページ
・左が野中さんの言葉で、右がソフトウェア。
・1991年 知識想像企業
・1994年 スクラムマスターという言葉をつくって役割を作った。ただ野中さんの方にはそういう言葉はない。
・2001年 アジャイルマニフェストの年。スクラムの最初の本が出た。
・2012年 Software in 30 days という角さんの本が出た。経営者向けの本。
■11/38ページ
野中先生
・Scrum： リレーからラグビーへ
・SECIモデル： 知識は、暗黙知と形式知の変換活動のスパイラルの動きである。
・第三の知 = 実践知
■13/38ページ
SECIモデル
・知識想像は暗黙知と形式知の相互変換作業である
■14/38ページ
・言葉にできなくても人間は知識を得ることができる → 暗黙知
・自転車ののり方なんかは暗黙知の典型的な例。あと畳水泳とか。
・一緒にその活動をしないと伝わらないのが暗黙知。
■15/38ページ
・言葉に書くことができる知識 → 形式知
・数学は形式知の典型。人類が作り上げた究極。コンテキストを越えて正しいことを伝える。
■16/38ページ
・会社にクレーム処理が上手な人がいるとする。それは紙にかけるものもけっこうある。
→ 紙にかいてノウハウ集にすると形式知になる。
・知らない人がそれを読んでやってみて、身に付ける。これが形式知から暗黙知の変換。
→ これが回っている。
・人間は形式知よりも圧倒的に多くの暗黙知を持っている。
■17/38ページ： 組織知識想像の行為
・この4象限の絵が今日のキー。
■17/38ページ： 共同化(S)
・暗黙知を暗黙知に変換する。
・経験とか実践によって、人に何かが伝わる。
・一人が活動することによって複数人に伝わる。
・共感、みたいなもの。もらい泣きとか。
・SocializationのS。
■17/38ページ： 表出化(E)
・ひょうしゅつか、と読む。
・暗黙知を形式知にする。
・言葉にすることによって伝える。
・ExternalizationのE
■18/38ページ： 連結化(C)
・形式知から形式知へ
・２つのアイデアを混ぜ合わせたりとか、それで新しい言葉を産み出す。
・編集したりとかして新しい知を産み出す
・CombinationのC
■18/38ページ：内面化(I)
・Internalization
■18/38ページ
・S→E→C→I。これで一周して自分に戻る。このループ。
・軸としては個人と多数。それと暗黙知と形式知の軸。その4パターンで定義されている。
■19/38ページ
・松下ホームベーカリの物語
・田中郁子氏（ソフトウェアエンジニア）の例
・パナソニックで、複数の事業部が合体して、電化調理事業部が出来た。
→ 自動パン焼きができないか、と考えた。
それで「私にやらせて」と会社に言った。この言葉が重要。・
秀逸なのは、パンで有名なホテルに自ら修行に行って、暗黙知を吸収してきたこと。 → 生地をこねるだけじゃなくて、ひっぱる動作が重要だと気づいた。
・パン焼き名人の暗黙知を形式知にした。
・知識の想像活動が起こった例と言える。
■20/38ページ 「SECIモデルとアジャイルプラクティス」
■Socalization
・Sprint Demo
- ジェフ・サザーランドは「デモしないなら死んでしまえ」とまで言っている。それほどデモは重要。
- 暗黙知を目で見えるようにする。
・Visit Users
-
実際のお客さんの現場を必ず見学しなさい。訪問して一緒に仕事しなさい。 - これが最近重要なプラクティスになっている。体験して、暗黙知を暗黙知として理解する。
・Pair Programmingはかなり弟子入りに近い。
・Sit Together
- XPに入っている。お客さんと一緒の部屋でやりましょう。
■Externalization
・アジャイルでは「Story Writing」は薄く薄くする。必要なら会話せよ。
・XPのプラクティス 「Coding Standard」
→ みんなが持っている暗黙知を書いてしまいましょう。
・Daily Standup
→ みんなの暗黙知、もんもんとしたのを出して形式知にする。
・Retrospective（振り返り）
１スプリントやってみて、良かったこと、悪かったことを話す。
■Combination
・書かれたものを集めてスプリントプランニングする。
■Internalization
・学習に関するものはすべてココ。
・なにかを自分の体で学ぶこと。
■SECIモデルを使うと、アジャイルの多くのプラクティスがいろんなレベルで起こっていることがわかる。
■21/38ページ
・本の結論の１つ。「アジャイルは知識想像マシンである」
・知識とは
- 製品とかユーザに関する知識
- ソフトウェアの作り方に関する知識（成長するチームを作る）
・アジャイルとは
- 動くソフトウェア
- その知識を内部に蓄えたチームができること。
■23/38ページ
・SECIモデルを回すリーダーシップが、実践知リーダーシップ。
■フロネシス ＝ 実践的知恵
■25/38ページ： アリストテレスの３つの知
・エピステーメー ＝ 形式知
・テクネー ＝ 暗黙知
・どちらにも当てはまらない知 ＝ フロネシス。エピステーメーとテクネーを往復する
■26/38ページ： 実践知リーダーシップの６能力
・６能力の中で一番大事なのは「②場をタイムリーに作る能力」
■28/38ページ：
対象に棲み込む・野中先生がいつも言っていること。
・地面に手を当てて、ライダーの気持ちになる。
→ ライダーがこのカーブで何を感じているかを手で感じ、暗黙知として持って帰る。
■29/38ページ； その場で概念（コンセプト）を紡ぎ合う
・掴んで持って帰ってきたものを、エンジニアと一緒に腰を下ろして絵を描く。
・会議じゃなく、その場でやっている。急にやってきてアドリブの中でやる。■30/38ページ： この開発フェーズの図で伝えたかったこと
・Type Aのフェーズの切れ目で、会った事が無い人に作業を放り投げて上手くいきますか？ということ。
・最後まで関われ。設計や開発だけでなく、販売までやれ。・これがスクラムのプロダクトオーナーの仕事なんだ。
・決して、書いて渡すな。一緒に走りきれ。■31/38ページ
・考えることと、やることを分けてはダメ。
・doとthinkが一体となってやることが実践知。・オチ → 「知的体育会であれ」
■32/38ページ： コタツモデル
・考える人とやるひとが一緒にいないとダメ。
・その場で、いまここで、話をする。これをやれるかどうかが実践知リーダーの要件。
■35/38ページ
・海兵隊は、常に陸・海・空の３つの要素を組織レベルでもっている。中隊でも小隊でも。
常に３要素を持ち合わせている。3人の場合でも。
・新製品開発でも、一緒。顧客・技術・経営の３つを繋ぐ必要がある。
・異なった視点を持った人が集まってチームになるのが重要なんだ。
・プロセスじゃない。人を乗り物にした知識の伝達活動。
・壮大な伝言ゲームを紙に書かずに人に運べ。■37/38ページ
・ジェフサザーランドと野中さんの初対面の場にて。
・そこでQ&Aが行われた。
・Q:「ステークホルダーがたくさんいる中で、考えをまとめてバックログにするにはどうしたらいいか？」
→ ジェフはその回答を野中さんに振った。
→ 野中先生はA:「合宿をしなさい」と言った。スゲー言葉だと思った。
■PDCAはダメ。
・PLANは書かれたものだろう。書かれたモノを持っていっても、誰も共感しないだろ！
・PからじゃなくてS（SECIモデルのS）から始めろ。
■ディスカッション約1時間の平鍋さんの講演の後、10分休憩。そのあと40分ほど質疑応答の時間が取られました。
Q1:
SECIモデルについて。ぐるぐる回る中で、なぜSがここにあるか。
A1 by 平鍋さん:
知識想像がポイント。IからEに結んでしまっても共感が得られない。
個人のデータでなく思いを他人に伝えることから始める。正しいかどうかは関係ない。
信念があれば良い。それがないと新しいものはできない。
---
Q2:
暗黙知を形式知にするところで、Eを越えてCのところまでのものを作っちゃいそうな傾向があるのでは、
と思っている。
A2 by 平鍋さん:
SECIモデルはすっきりはまるものではない。なるほどなぁ、と思えればいいのでは。
経営の計画を作るときに、紙に書かず、付箋とホワイトボードに書くのが好き。
まだ書かれていないものを紡ぎ出していく、その場を共に作るのが好き。
---
Q3:
アイデア主導なのか戦略主導なのか。
モデルにアイデアが無いものは、モデル同士をいくつ組み合わせてもダメ。アイデアは暗黙知から始まる。
アイデア主導だとやりやすいが、会社だと戦略主導でやらざるをえない場合もある。
根本的に間違ったヒヤリングをやると、要件が爆発する。
物事を決めたりするとき、アイデア主導なのか戦略主導なのか。
A3 by 平鍋さん:
野中さんはアイデアと呼ばず「思い」と言っている。
価値を手探りしながら価値を言葉で表現していくのが大事だと感じている。
表出化することによって価値が共感、実感できると考えている。
みんなに響く言葉を作ることは大きい価値。
---
Q4:
アジャイルは進化しているか。
A4 by 平鍋さん:
進化していない。
最近はUXとかモチベーションとか、組織にどう組み込むかとか、そういう概念が増えている。
明らかにあるのは、スケールさせる、ということ。
スクラムオブスクラム、とジェフ・サザーランドは言っている。
結局、どこかで不整合がおこる。その接点が上に移動している。
仮説が検証されなければ、それは価値として認識されない。
■
・人間は30歳台に経験した衝撃的なことは一生やる、というのがある。平鍋さんはそうららしい。
・戦後の、トヨタやSONYの経営者の成功モデルは、今だと違うものになっていると思っている。
★感想：すげー心に響く言葉がいくつかあった。上で太字にしている箇所。
改めて再認識したこともあったし、新たに気付かされたことも多かった。
というか平鍋さん、深い知見に基づいたトークと進行で、プレゼン上手いなぁ、と改めて思った。
大変有意義な時間を過ごせて、参加してよかったなぁと思いました。
今後もチャンスがあれば要求開発アライアンスとか平鍋さんのセッションを聴講したいと思います。
2013/3/19(火) 横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2912Togetter
http://togetter.com/li/474247以下の書籍をターゲットとした読書会なのです。
場所はいつもと同じ、横浜のアットウェアさんです。参加者は25名くらいでしょうか。
今回は特別編ということで、@hageyahhoo さんによる講演＆ワークショップが行われました。
その名も「Domain-Specific Language としての魔法少女まどか☆マギカ入門」！
・・・最初、このタイトルが横浜道場の懇親会で告知されたとき、ザワ・・ザワ・・・な状態でした。
ちなみに私、「魔法少女まどか☆マギカ」というアニメの存在は知っていたものの、一度も見たことがありませんでした。
こんなの ⇒
http://www.madoka-magica.com/index2.htmlただ、評価が高いアニメということはなんとなく知っていたので、予習を決行することにした！
1話が約30分として、12話あるので30分×12話＝360分＝6時間！ ・・・なにやってんだか。
見始めて知ったんですが、脚本はFate/Zeroのシナリオライターでもある虚淵玄なんですねー。
去年かな、リアルタイムで見ていましたが、かなり名作だったと思います。書籍も買ったし。
あと、@hageyahhoo さんの発表は何回かこれまで聴講したことがありまして、ブログにもいくつか書いた覚えがあります。
・
ブログ： 2012/9/15 「XP祭り2012 〜 ソーシャルチェンジ！ 〜」に参加しました・
ブログ： 2012/10/19 「Agile Conference Retrospective」に参加しました主にAgile Conference 2012の話ですね。とても印象に残ってます。
■本題 ■「品川アジャイル」という勉強会を主催でやっているとのこと。
http://www.facebook.com/groups/279969248771231/Mike Cohn さんの著書「Succeeding with Agile（洋書）」の読書会らしい。知ってれば最初から参加したかったなぁ。
■アジェンダ
１．円環の理：まどマギ概論
２．魔法少女になるって、そういうことよ：まどマギ実践
３．砲火後ティータイム：ワークショップ
■１．円環の理：まどマギ概論■まどマギの最初のイメージ
→ プリキュアみたい。キャッキャウフフ～
→ ・・・3話ごとに俺の嫁が死にます orz
■まるで要件定義書と実装のよう。
・要件定義： プリキュアみたい。キャッキャウフフ～
・実装： 3話ごとに俺の嫁が死にます orz
■まどマギのストーリー
connextra format
・as a [stakeholder]
・I want [feature]
・so that [benefit]
■まどか
・not 魔法少女
・as a [QB helper]
■ほむら
・as a [QBキラー]
■さやか
・as a [まどかの友達]
魔女があらわれて、ピンチの時にまみさんが出てくる
■マミ
・as a [先輩]
・二人を助ける
■２話の時点で壁ができる。
ほむら ＞＞ まどか、さやか、マミ
■多くの人が３話で心が折れる。。。（マミ死亡）
→ プロジェクトと同じ。
■杏子
・as a [横槍]
・まみさんがいたところの領域を荒らしにくる
→ 杏子とさやかが闘う（このへんで5話くらい）
→ 杏子がさやかを好きになる
■（まどマギの）知識があれば、各キャラの頑張りがわかる。
→ 特定ドメイン
■特定ドメインとは
共通の語彙や概念を使って会話をするテクニック
■由来
ちなみに私、ちょうど先日この書籍を買ったばかりで今読んでるトコです。
GOOS本の読書会で和智さんはじめ参加者さんにオススメされたのです。
■とある社内の２年前
・DDD本が流行り、ドメイン知識・ドメイン言語が流行った。まどマギの話題が8割。
→ まどマギって特定言語なんじゃね？
■ここで参加者に、どのキャラが好きのアンケート
・マミ： ５
・さやか： ２
・杏子： ７
・まどか： ０
・ほむら： ４
ちなみに私、挙手できませんでした。どのキャラが好きかまで考えたことなかったなぁ。。。
にしても、まどかの扱いが酷くてワロタ。
■アジャイルを社内でやろうとして、「概念」で押すと失敗する。「実体」で行くべき。
→ これは以下のようなことであろうと個人的に理解した。
・概念で押す： 「アジャイルやりましょう」とプラクティスありきで導入しようとする
・実体で行く： アジャイルという名前を前面に出さないまでも、その良いところの実体（本質）から導入しようとする
■アンケートで各キャラを推した理由
・杏子 → 強い子が好き
・マミ → すごく・・・大きいです
・ほむら → 失敗を繰り返してもチャレンジする
■これだけまどマギについての共通認識が参加者の中にあれば、特定ドメインについて話せるよね～
■2. 魔法少女になるって、そういうことよ： まどマギ実践■システム開発あるある（P.23）
→ P.23の図はどうやら「オレゴン大学の実験」のまどマギ版らしい。
→ P.23の図を業務で使ったことがある。。。
→ マネージャとスムーズに会話ができるようになった
■解決策（P.24）
・アイデアがあって、ビルドして、計測して、Learn（学び）
・このループ
■ジェフ・パットン氏が来日して５月にスクラムマスターの認定教育をやるらしい。
■２．無理をしすぎたら（P.25）
・残業が多いと判断をミスってて失敗しがち
・それで成功すると、もっとできるよね、となってしまう。
（残業が多い状態で達成した成果より上を目指さざるを得ない状況になる）
・じゃあ、どうするか？
■ask for help
「Fearless Change」という書籍のP.104に書いてあるらしい。「助けを求める」
■大人がお酒を飲んでいい理由（P.28～）
・このシーン泣ける・・
・まどマギは人生
・正しいことをやろうとすると現場が反発することがある。
・まどかの母は「上手に間違えろ」と言っている。
・失敗するのが難しいってのは確かにある。
・でも、間違えが学びになる。
■ウォーターフォールは仕様の誤りを「失敗」と見なす
アジャイルは仕様の誤りを「学び」と捉える
■まどマギはジェフ・パットンと同じことを言っている！
■３．砲火後ティータイム■例１：ペルソナ
・ペルソナのように架空の対象作るのは大変。
→ 例えば、「まどマギの既存のキャラにしようか」とすると纏まる。
・実際、ペルソナで「マミさんでいいでしょ」と言ったら一致団結した。
→ 共通の知識があればこのとおり～
■例２： Global Communication
・ジェフ・パットンの一言「Do you the QB？」
・エントリピーを求めるもの＝お客さん
・Corpとはまどマギで繋がった
■例３： CSM研修でまどマギが題材に使われる
・ガンダムとかジョジョとか、特定ドメインを使ってディスカッションとかできるのでは。
■砲火後ティータイム（ワークショップ）
１．付箋に書き出す
仕事を振り替えって自分がどのキャラににているか。どういう状況にあるか
２．KJ法で整理する
３．一番ソウルジェムが濁っているチームを発表して、みんなで助けよう
■ウチのチームのホワイトボードはこんなカンジ。
■まどかはトリ。ブタじゃない。
・トリ： 産んだ卵は食べられるが、自分は食べられない
・ブタ： 自分が食肉として食べられる
まどかは自分が魔法少女に成らずに、外から見てるだけ。。。
■ほむらはチームで学んでない。
→ 時間を繰り返すほどに悪くなっているんじゃないか？
■Homework
・「キュウべぇはポケモンか」という質問に、酔った勢いで「Yes」と答えてしまった。。。
→ ジョナサンの誤解を訂正してほしい
★感想：まどマギ12話、予習しておいて良かった。ほむほむ、とついていくことができたし。
というかアニメ自体も面白かったし、一石二鳥です。
見る機会を与えてくれたことにむしろ感謝。
それにしても、参加者の9割くらいはまどマギを見たことがあるとのことで、すごい人気です。
このネタだったからこそ参加した、という参加者さんもいらっしゃったようで。
周りがこーゆう状態なら「まどマギ」が共通ドメインとして振舞えるんですね。
ちょうどドメイン駆動設計の書籍も読んでいるところだし、ドメインについてもう少し学んでみよう思います。
こーゆうブッ飛んだネタの特別会、今後もやってほしいなぁ。
あとビアバッシュでもとても有意義なお話を聞けました。教えてもらってばかりでしたが、感謝。
最後に @hageyahhoo さん、道場主さん始めスタッフさん、参加者さん、ありがとうございました。
2013/3/13(水) 「実践反復型ソフトウェア開発読書会 -反復1-」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/3018会場は日本オラクルです。@yokatsuki さん、いつも会場提供ありがとうございます。
参加者は12名くらいでしょうか。
以下の書籍をターゲットとした読書会なのです。
先日もDevloveでこの書籍に関するイベントがあり、それにも私、参加してブログに書きました。↓
2013/2/20(水) 「ビルド中心の開発 - タイムボックスと継続的インテグレーション -」に参加してきました。http://makopi23.blog.fc2.com/blog-entry-51.html今回は、先日のイベントの元ネタとなっている書籍の読書会という位置づけです。
今日は１～３章がターゲットでした。
1チーム3名くらいで参加者をチーム分けし、チーム毎にディスカッションというのを2回やりました。
2回目はメンバ交代で。
以下、チーム内ディスカッションや、共有の時間に他チームから出た意見のメモ。
■この書籍は教科書的な役割を果たすが、具体的にどうやるかは書いてない。
→ 具体的なやり方はこの読書会で話したらよいのでは。
■この本では、タイムボックスとフィーチャーボックスの２種類がある、という紹介がある。
→ やっぱタイムボックスでやりたいよね～
■テストエンジニアって、結構いないけど重要だよね。
→ TISの鈴木三紀夫さんは、テストエンジニアとしては強烈、との話が出た。
■Rubyとかのスクリプト言語だと、明示的にコンパイルしないので、ビルドという感覚があんまりない
■図1.3の進化で、自分のやってるブランチが正しい方向に向かっているかをどう判断するか？
・進化を管理するためには、ブランチもきちんと構成管理しないといけない
・多様性を残すために、あえてブランチをマージせず残しておくこともアリでは。
→ あるブランチがうまくいかなかったら、うまくいって残しているブランチに戻るとかできる。
・むりやりマージするとかダメよねー
・特定顧客向けにブランチを切ることはあるのでは。→ 役目を果たしたら途中で捨てちゃう。
・スマホ対応家電とかはいきなりドクロに向かうブランチなのかも（笑
・Webサービスだとリリースは１つなので、基本はブランチ切ったらマージされることが多い。
・マージして１つのマスタにしてしまったら、試行錯誤の経路が失われる。
→ ブランチを残しておくのもありでは。
・ドクロへ到達する期間が短いブランチはありえるのでは。数日とか。
→ 例えば、経営層に見せるためのバージョンをブランチで作って、ダメなら捨てるとか。
■開発が始まってからテスト自動化の仕組みを作り始めるのは遅い。
→ プロダクトコードがない段階、スケルトンの段階からテストの仕組みは作り始めるべき。
（この書籍で言うと、ゼロ機能リリースに該当するかなぁ）
■ドキュメントを作るのは、開発範囲を明示することで自分の身を守るためであることが多い。
■派生開発だと、その仕様になった「理由」を重視する。理由に迫ることで本質がわかる。理由は安定度が高い。
■見積りをストーリーポイントでなく時間で見積もると、精度が上がった。
・この人はこの日は休暇を取得するとか、この日のこの時間は～～やる、とか、稼働時間がいくらになるかを詳細に詰めていくと見積りの精度が上がったとのこと。
→ アジャイルは相対見積りで正確性はあまり推奨していないが、こーゆうやり方もアリ。
■リリースプランニングをあまり意識しないまま進めると、マイルストーンの最後の方になって、ぜんぜん間に合わないことが初めてわかる。。。
→ リリースプランニングを意識してイテレーションを進めていくことで、それらを改善できた。
■ウォーターフォールバリバリのプロジェクトにテスト工程から途中参加するエンジニアに対するアドバイス
・テストでは、業務要件だけ満たしていることが確認できれば良しとする。
（コードがぐちゃぐちゃのプロジェクトに途中参加する場合は、それしかできないのでは）
・勉強会をやろう、と言うと拒否反応を起こされるので、コードレビューという名目で勉強会をやる。
■BMWでは、600人規模でアジャイル開発をやっているらしい。
→ チーム毎にPO（プロダクトオーナー）を立ててスクラム的に開発し、スプリントレビューの場では各チームのPO自身がデモするんだとか。
実に興味深いです。
■チャンピオンやドライバに相当する人が自発的に出てこないとマズイ。
★感想：うーむ、書籍の内容というよりか、反復開発をテーマにざっくばらんに議論してしまった感があり、ちょと反省。
でも、こーゆーのもありかなーと思っている部分もあります。
あと、この書籍は私がこれまで読んできたアジャイル系の書籍と違って、だいぶ風変わりに感じました。
チームの組み方にしても、ビルド中心の回し方にしても。
コンプリートとフリーズの概念とか、テストエンジニアやテスターが開発者と分離された状態のロールとして定義されていたりとか、興味深いです。
また書籍名の一部に「ソフトウェア開発」という単語があるように、かなーりプログラマよりな視点だなぁとも思いました。
5章とかにブランチの話とかにページ数を割いていたりと、まだ読んでませんが新しい気付きが得られそうで楽しみです。
あと、著者の津田さんが風邪で欠席となってしまった点がちょびっと残念でした。
最後に、主催の papanda さん始め会場提供の @yokatsuki さん、参加者の皆さんありがとうございました。
2013/3/5(火) アジャイルサムライ読書会 横浜道場 「イテレーションの運営：実現させる」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2911以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんで、参加者は20人くらいでしょうか。
今日は第９章「イテレーションの運営：実現させる」から読書でした。
ウチのチームは5名で、ディスカッションのホワイトボードと付箋はこんなカンジ。
以下、チームでのディスカッションした内容を中心に、自分用メモ。
■テストは開発と一緒になって進めていく必要がある。
■必要な分だけを必要なときに
■必要なときに分析する
→ ストーリーの実装を予定しているイテレーションの１つ前のイテレーションで分析する
（イテレーション(n)で分析して、イテレーション(n+1)でストーリーとして開発する）
■1つ前で分析するのは、シナリオのレベル。
→ そのイテレーションの先頭で、1つ前で分析したシナリオをタスクに分解する。
■やりすぎないことが肝心。後になって状況がガラッと変わることもよくある話。
■大事なのは創意と工夫。
■イテレーション・ゼロ
・イテレーション・ゼロで実施することを、イテレーション・ゼロの前に分析する必要がある。
（何が事前準備として必要かを、事前に検討する）
・開発環境とステージング環境をイテレーション・ゼロで合わせておく。
（後々になって環境の差異で泣かされることがないように）
・イテレーション・ゼロは最初の1回だけでなくても良いのでは。必要になったらまたやる。
（例えば本番前に、本番環境の準備として再度イテレーション・ゼロ）を設けるとか。
・↑はイテレーション・ゼロじゃなくて、スパイクを必要なときに打てばいいんじゃないか。
・テスト自動化の仕組みはプロダクトコードが無いイテレーション・ゼロの段階から準備しておく。
・イテレーション・ゼロでプロト的にストーリーを１つ実装して、お客さんに価値を届けるのもアリ。
（開発することで、開発環境や構成管理、各種プロセスの認知・共有に繋がる）
■「スパイク」という用語について
・調査用のプロトタイピングの事を、エクストリーム・プログラミングでは、特に「スパイク」と呼ぶらしい。
・開発作業の中で見積りや技術検証などに試行錯誤するタスクのことを「スパイク」と呼ぶらしい。
・早期にアーキテクチャを検証することを、アーキテクチャスパイクとも呼ぶらしい。
■受入条件を事前に明確にしておく。（Doneの定義）
■ストーリーボードとカンバンは違う。
・ストーリーボード： 11章で。
・カンバン： 以下参照。
■カンバン
・WIP（Work In Progress）に上限を設けている。
・イテレーション（タイムボックス）は必要ない。気にかけるのは作業リストにある優先順位の高い作業だけ。
・即対応が求められたり、決まった長さで作業できないような、運用・サポートのチームならカンバンのほうが向いている。
■成果を届けるための秘訣は、機能の切り口をエンドツーエンドにして薄くスライスするにはどうしたらよいかを考え抜くこと。
■手作業はDoneの定義がゆるくなる。（妥協が入りやすい）
■自己組織化に関連したものにCMMIがある、という話題が出た。
→ CMMIは成熟度を測る指標だが、監査の要素が強いのでストレスの要因になる。
■タスクは横（メソッド単位）でなく縦（機能単位）に切るべき。
（横に切ると、開発者がなぜそれが必要なのかわかりにくくなりモチベーションも上がらない、という意見あり）
★感想：あらためて9章を読み返してみると新しい気付きがたくさん得られて、ちょっとした驚きでした。
読み返して再認識し、新しい点に気付き、ディスカッションで更に深みに入るというか。
今回は4回のスプリントでちょうど9章全体を読めましたし、スコープもちょうど良い感じでした。
あと、今回は初参加の方が比較的多かったようです。
ウチのチームも5人中、2人が初参加でした。新しい風が入るのは良いですね。
あとゲーム会社のエンジニアさんとかのお話を聞いていると、作業開始からリリースまでに1ヶ月しかない、なんて話も結構あるようで、そうなるとチームのプロセスの改善やリファクタリングが後回しになってしまう状況も見られるようです。
確かにリリースまで1ヶ月じゃあ、プロセス改善の効果が染み入る前に終わってしまうので、改善作業の優先度が落ちてしまうのはある程度、納得です。
更にソーシャルゲームのように製品が短命だと、リファクタリングする効果も薄れますし。
技術的負債を解決する工数とタイミングのバランス、この辺は難しい問題だなぁ、と思いました。。。。
次回はまどマギ編ということで、それまでに全話見れるかなぁ。。。
最後に道場主さん、運営者さん、参加者の皆さん、ありがとうございました。
2013/3/3(日) 「『JUnit実践入門』写経・実践会 in 横浜 #4」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/1694/Togetter
http://togetter.com/li/463129以下の書籍をターゲットとした読書会なのです。
場所は横浜のタネマキさんです。参加者は15名くらいでしょうか。
今日は「第12章 データベースのユニットテスト」が範囲でした。
写経する時間が取れなかったので、書籍を一通り読んでサンプルコードを動作するトコまでやってから参加しました。
サンプルコードを動かす時にハマッた箇所をメモに残しておく。
（環境はWin7のEclipse3.7、他は書籍のミドル指定と同様の構成、バージョンです）
■サンプルコードを動作させるためのメモH2 Database + DbUnitを使ってUserDaoTest.javaを動作させようとすると、最初、以下のエラーが出ました。
| java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory |
ググってみると、どうやら以下のjarをクラスパスに通しておく必要があるらしい。（書籍には指示なし）
・slf4j-api-1.7.2.jar
・slf4j-nop-1.7.2.jar
ということで、以下から「slf4j-1.7.2.zip」をダウンロードします。解凍して上記２つをビルドパス追加。
http://www.slf4j.org/再度、DbUnitを使ってUserDaoTest.javaを動作させようとすると、今度は以下のエラーが出ました。
| org.dbunit.dataset.DataSetException: java.net.MalformedURLException |
どうやら、usersテーブルのデータセットを指定したXMLファイルが見つからないらしい。
ということで、EclipseでXMLファイルが入っているフォルダをソースフォルダーとして明示的に指定してやる。
再度、DbUnitを使ってUserDaoTest.javaを動作させると、今度はうまく単体テストできました。
んで、その後いろいろH2 Databaseの設定とかいじっていたら、単体テストで以下のエラーが出るようになってしまった。。。
org.h2.jdbc.JdbcSQLException: スキーマ "UT" が見つかりません Schema "UT" not found; SQL statement: |
どうやらH2 Databaseのデータを格納しているファイルに不一致らしき事象が生じたらしい。
んで、いろいろ調べてもわからなかったので、勉強会の場で質問してみたら、@PoohSunny さんも以前、同じ事象になったことがあるとのこと。
ということで、@PoohSunny さんから解決方法のヒントをいただきました。
んでアドバイスを参考にH2DatabaseServer.javaを以下のように修正すると、なんと解決～！感謝！
■修正前：H2DatabaseServer.javaの37行目あたり
| String url = "jdbc:h2:" + server.getURL() + "/" + dbName; |
■修正後：H2DatabaseServer.javaの37行目あたり
| String url = "jdbc:h2:tcp://localhost/db"; |
どうやらデータベースサーバへの接続URL（特にポート番号まわり）が怪しそうだったので、ポート番号を含まないURL（localhost指定）を指定してスキーマを一度作り直すよう、細工してやったのです。
上記のようにソースを1回修正し実行することで、@before により再度スキーマUTが作り直されて、以降は修正前のソースに戻してもちゃんと動作するようになりました。
■ディスカッションのメモ 以下、ディスカッションタイムに私がとったメモ。
■Web三層構造アーキテクチャ（P.200）
Seasar2は3層に分かれているが、Play Frameworkは3層に分かれおらず、パーシステンス層とロジック層が密に結合している。
→ この書籍のとおりとはいかない。
■スローテストに直面している人は参加者のうち2名くらい。
■スローテストの解決案
・単体テストはH2 Databaseを使って、速度が遅い部分はカテゴリのアノテーション使って後に回す。
・設定ファイルを分けて、単体テストと結合テストでテスト対象を切り替える。
・遅くなりそうなテストだけ纏めて抜き出す。
■Salesforceでのテスト
・テストに7時間くらいかかってて、スローテスト問題に悩んでいる。。。
・Salesforceのフレームワークが、テストで全件流さないといけない仕組みになっている。
・テストが途中でコケても途中で止められない。
・データクリアができないのでテストの時間もすごくかかる。
・デプロイの時にテストが走ってカバレージを取得し、75%以上じゃないとデプロイできない仕組みにしている。
・Salesforceの開発言語Apexはローカルでコンパイルやテストができないので、手元で確認できないのが辛い。。。。
■他の人は、スローテストになるほどテスト書いてなかったりする。。。？
■テストの工夫
・DBを単体テスト用、結合テスト用、ステージング用と複数用意する。
→ 単体テスト用は中身を空にしておいて、テスト時にコミットが実行されないようにしておく。
→ 単体テストの最初にテストデータを投入し、テストが終わったらコミットがされない（≒ロールバックされる）ので自動でデータが消える仕組みにしている。
■DBを使ったテストでハマったこと
・同じスキーマに複数の人がテストしてて、１人がデバッグでステップ実行しててテーブルにロックがかかった。
→ その結果、もう１人のテストがコケた。集中型DBのテスト環境だとよく起こる。
・一人ひとりにDB環境を作れば、このような事象は起こらない。
■データベーススキーマのバージョンを管理するツールがある。
■H2 Databaseは他のDBMSとエミュレートできるのが良い。
■groovyとyamlを使った @grimrose さんのLT。
https://github.com/grimrose/junit-boost-camp■Seasar2は開発が止まっちゃているのが難点。@Theoryが使えなかったり。。。
■レガシーコード改善ガイド
・この本は、テスト時のDBアクセスを極度に嫌っている。
→ DBをモックに置き換えないといけないと思い、頑張ったが苦しんでいた。。。
→ @t_wada に相談してみたら、t_wadaさん曰く、「DBに繋いでテストしちゃえばいいんじゃないの？」
→ 目からウロコだった。
■ @sue445 さんのLT
・Rails版
「JUnit実践入門」の「第12章 データベースのテスト」をRailsで書きなおしてみた
https://bitbucket.org/sue445/junitbook-study-rails・Seasar2版
「JUnit実践入門」の「第12章 データベースのテスト」をSeasar2で書きなおしてみた
https://bitbucket.org/sue445/junitbook-study-seasar2■@PoohSunny さんによるLT
■おまけ今日はジョジョ2巻の途中まで読んだ。次回はもうちょっと早めに行って、たくさん読むんだ！
★感想：今日もディスカッションが活発で、大変有意義でした。
スキーマUTが見つからない、というエラーも解決できたことだし。
惜しむらくは、写経の時間が十分にとれなかったこと。
次回はもうちょっと早めに予習することにしよう。
最後に、主催者さん、参加者さん、皆様ありがとうございました。
2013/3/2(土) 「第n回GOOS（日本語版）読書会」に参加してきました。
zusaar（告知サイト）
http://www.zusaar.com/event/520003以下の書籍をターゲットとした読書会なのです。
場所は新宿の某所で、参加者は主催者さん入れて5名でした。
小規模ですが、議論しやすい人数です。しかも翻訳者の和智さんまで参加！
でも私、途中でSUICAを駅に落として取りに戻ったため、30分ほど遅刻してしまいました。。。
ちなみにDevlove2012でも和智さんによるGOOSのセッションがありましたが、私も聴講してブログに書いてます。
「DevLOVE Conference 2012」に参加しました ～其の壱～http://makopi23.blog.fc2.com/blog-entry-35.html以下、みんなでディスカッションした際にとった、自分用メモ。
第Ⅰ部 導入■インタフェースとモデルはウォーキングスケルトンを作成する前に決める。
■テストコードはプロダクトコードが無い段階で書き始める。
・当然、Eclipse上では赤アンダーラインでエラーが出るが、それで良い。
プロダクトコードがまだ無い（からエラーになっている）、という状態がわかるので。
・逆に、空コードを用意して既にあるものを使ってしまうと、その制約にひっぱられてしまう。
（プロダクトコードの適切なクラス名やメソッド名も、テストコード書いてる時に気づいたりするので、変えれるようにしておいたほうが良い）
■クライアント側が読みやすいように、テストコードから書いて、呼び出され側も書く
■モックは、外から中に流れていく作り方で使う。使う側から作る。
■どうしたいかを書いていく。何をしたいか、を考えて書く。読みやすくないといけない。
■メッセージパッシングのテストをやろうとするとモックを作らないといけない
■著者のNat PryceがDIをdisってるブログがある
・
http://www.natpryce.com/articles/000783.html ・モック化する対象はP.56の「依存、通知、調整」
・大きな責務の関係性と実装レベルの分割があって、DIを使うと見えなくなってしまう
→責務を意識しないとダメなんだよ
■マーティン・ファウラー による、「モック」と「スタブ」との違いに関する説明
http://martinfowler.com/articles/mocksArentStubs.html 日本語訳：「モックとスタブの違い」
http://d.hatena.ne.jp/devbankh/20100210 ■スタブ：
・テストの間の呼び出しに一時的な回答を返すもの
・そのテストのためにプログラムされた値じゃないものは返せない
・スタブは実態がある
■モック：
・期待値をプログラムすること
・戻り値として返されるものがモック
■モックを使ったテストで和智さんがよく書くもの
・バックエンドでDBがいくつかあり、DbUnitでテスト作るのが面倒くさい場合に、
「ロジック→DAO→DB」の最初の矢印のトコにモックを置く。
■昔のJMockはAPIをベタ書きする必要があった。
→ JDK1.5でジェネリクスが出てきて、Expectationでメソッドを書けるようになった。
■JMockの作者は、GOOSの著者と同じ。
■モックはロールをモック化するべき。
スタティックメソッドとかモックにする。
■テストを書いている間に、振る舞いの結果に対してフォーカスがあたる。
モックを使うと、そのユースケースがテストコードに書かれる。
■DI
・XMLを見るだけで関係性が追える。
・アノテーションで書いちゃうと関係性が追えなくなる。
■WebのテストではSeleniumよりもcucumber-junitの方がお勧め。
第Ⅱ部 テスト駆動開発のプロセス■発芽（P.64）
・「顧客コード」という概念を表現するのに、普通だとString型フィールドで用意しがち。
→ 主キーなので、DAOに渡したりするが、単にString型という属性しか付いていないと、なんでも渡せてしまう。
→ その対策として、「顧客コード」をStringじゃなく「顧客コード」というクラスに抜きだす。
・DAOには「顧客コード」というクラスを渡す制約にすると、それしか渡せなくなるので型安全にできる。
・その他に、「顧客コード」の3桁目に特定の意味を持たせたりとかも、クラスにすると表現できる。
・顧客コードは「右埋め」みたない意味を持たせたりもできるので、クラスにしておいたほうがいい。
・普通に考えるとオブジェクトになりにくいものをクラスにしちゃう。
・プレースホルダー ＝ 場所を予約する（クラスとして）
■GOOSの前提として「エリック・エヴァンスのドメイン駆動設計」という書籍がある。
・1部→3部→4部→2部の順に読むと良い。まず1部だけでも読むべし。
■インタフェース（P.67）
・他のオブジェクトに何かを提供するサービスは、インタフェースにしましょう。
・GOOSでも、１つのクラスの中にインタフェースを持って、中で同一クラス内のインタフェースを呼び出す設計になっているところがある。
・第Ⅲ部では、インタフェースの考えがキモ。
→ 図12-1とかの図が、以降どのように変化していくのか、インタフェースの使い方と実装・設計の変化を追うべき。
ちなみにこの議論しているときに、図13-2が間違っていることが発覚。
図13-2で正しくは、auction sniperから下向きに、Auctionというインタフェースを介して「？」に矢印が伸びる。
■イテレーション・ゼロ（P.88）
・TDDは、アプリケーションとテスト基盤を同時に作らないといけないのでは大変。
→ それを避けるために、イテレーション・ゼロでTDDの基盤を回すための仕組みを作っておく。
(cf)P.36 「まずは動くスケルトンをテストする」
・GOOSだと、11章がウォーキングスケルトンに該当する。（図9-4のTo Doの１つ目）
・データベースもウォーキングスケルトンの段階で入れておく。
第Ⅲ部 動くサンプル■分割とか発芽を実践する。
■第Ⅲ部の写経は苦しい。GOOSは写経しても幸せになれないかも。
・遠めに文章を読んで、これってどういう意味だろう、とコードを探ってみる読み方が良い。
■各章のTo Do（図9-4とか）を隣に置いて、オブジェクトの関連図（図11-1）を見て、なぜその設計になったのかを考える。
・各章で、これを意識して見ていくことが理解の早道。
（図11-1 → 図12-1 → 図12-2 → 図13-1 → 図13-2 → ・・・と、インタフェースとオブジェクト関連の設計の変化に着目）
・設計の変化は、テストコードが起因になってることが多いかも。
第Ⅳ部、第Ⅴ部■第Ⅳ部、第Ⅴ部は読み物として纏まっている。第Ⅲ部と独立してるのでココだけ読むのもお勧め。
■テストを書く事で、テストからわかることある。
→ 設計の改善の余地がわかる。
■22章の序論の第２段落がおもしろい。
■「テストコードにも愛情をそそぎましょう」
■P.273のソースコードで、hatandcapeが既に用意したテストで、but()メソッドを介して、その内のある条件だけ抜くことができる。
■第Ⅳ部のテーマ：「テストを綺麗に書く」
■第Ⅴ部のテーマ：「テストで苦労する時にどうすべきか」
ご参考■今日の参加者の一人、たのっちさんのGOOS書評。
@IT
http://el.jibun.atmarkit.co.jp/bookshelf/2012/11/post-a409.html■たのっちさんが書いてくださった今日のメモ
★感想：参加者は5名でしたが、少ないからこそ濃い話ができました。翻訳者の和智さんもいらっしゃいましたし。
私、第Ⅲ部の写経を頑張ってたのですが、写経をしても幸せになれないかも、という話でした。
この発想は驚きでしたし、そーゆー考えもあるのかー、と気づきを得られました。
第Ⅲ部にコード満載なので、写経はするもの、という考えでいましたが、ちょと見方を変えてみよう。
きっと、第Ⅲ部で挫折した人って多いんじゃないかなーと推測してますが、上のような考えで第Ⅳ部以降を先に読むのも全然アリそうです。
あと、第Ⅲ部は各章のオブジェクト関連図とインタフェースの使い方の変化に着目して読むべし、ってのもGOOSへのとっつき方法として気づきの１つでした。
プロダクトコードが無い段階でテストコードを書く、という点についても、今日の議論でもやもや感が晴れた感じがしました。
これまでと少し違った観点で、もう一度GOOSに取り組んでみようと思います。
最後に今日参加された皆様、ありがとうございました。とても良い気づきが得られた一日でした。
-->
