2013/10/17(木) SQLアンチパターン読書会 「サーティーワンフレーバー」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/6643以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は10人かな。
おなじみの顔ぶれです。
実はDoorKeeperのタイトルが「
サーティーワンフレーバー」となってますが、正式には「
サーティワンフレーバー」。
私も今まで、「サーティーワン」だと思ってましたが、違った。。。
ちなみに書籍はちゃんと「サーティワン」となってます。
サーティワンアイスクリームと言えば、子供のころ、スイミングスクールの帰りにオカンによく買ってもらったなぁ。
と、昔のことを思い出してとても懐かしくなりました・・・
生まれてから小学校3年生まで、愛知県春日井市というトコに住んでたんですが、その町の一番のショッピングモールにスイミングスクールも、３１アイスクリームもあったのです。
ということでGoogle先生で検索してみたら、まだあった・・・！
サーティワンアイスクリーム アピタ高蔵寺店超・懐かしい！
makopi23はこの後ブログ書くのしばし放置し、Googleストリートビューで懐かしき故郷を探検したのであった。。。
■アジェンダ今回は @tkfuji さんがスライドを作って説明してくださいました。
スライドが大変充実していて、とても勉強になると共に小ネタも多くて笑いありｗ
あと、今回のスライドを作るために３１アイスクリームを実際に店に買いに行ったそうです。素晴らしい！
ちなみに @t_wada さんも書籍執筆時に３１アイスクリーム買いに行ったそうなｗ
■ディスカッション今回もディスカッションしたいネタを付箋に書き出しました。
■サーティワンフレーバーをやってしまう場合・そもそも、サーティワンフレーバーな設計を考える前に、10.5の解決策を思いつくのが普通では。
・キーレスエントリー（4章）な設計をしている場合はサーティワンフレーバーは有り得るのでは。
→ そうともいえない。例えキーレスエントリーだったとしても参照テーブルを用意すればINNER JOINで使うことで恩恵を受けられる。
・ENUMとかCHECK制約とか駆使してサーティワンフレーバーな設計をして足元をすくわれるのは、DB信仰者が多い。
・逆にキーレスエントリーな設計をする人は、DBMSを信用してない人たちが多い。
■ドメイン（DOMAIN）やユーザ定義（UDT）による制約・DOMAIN やUDTは、UMLが出始めた時から出始めた。
・ドライバが高機能になってきたC/S時代は使用が多かったかも。
■アンチパターンを使ってもよい場合（10.4節）・相互排他的な場合でもダメな場合がある。
→ 例えばISO 5218では「性別」の標準規格として、「不明」「男性」「女性」「適用不能」の4種類を定義している。
→ コード値を勝手に振るのは最後の手段とすべき。
（ISO 5218：
http://ja.wikipedia.org/wiki/ISO_5218）
■ENUMデータ型・ENUMデータ型を指定したカラムには、値ではなくインデックスが入っている。
→ ソートした時に文字列順にならない。
・しかもインデックスが0始まりじゃないので、罠でしかない！
→ 「0=男性、1=女性」のような割り当てをアプリ側でしていると、DBのENUM列とズレが発生する。
→ データ移行の際に問題となることが多い。
→ というのもENUMデータ型を指定したカラムの中だけ見ても、中身はインデックス値が入っているので気づかない。。。
■値設計・データ中心アプローチを実践しているエンジニアは、値設計を3種類に分けている。
(1) フラグ
(2) 区分
(3) コード
・値設計はそんな単純じゃない。
・どういうライフサイクルを持っているかを考えて、設計する必要がある。
・そう考えて設計すれば、ENUMデータ型になるカラムはだいぶ減るはず。
・フラグとして使えるBoolean型はSQL標準じゃない。
・勝手に採番すると、国際化対応で破綻することになる。
■値の廃止（10.5.3節）・BugsテーブルのstatusカラムにDEFAULT 'NEW'と設定し、かつBugsStatusテーブルのstatusカラムに外部参照制約を付与した場合、BugsStatusテーブルのstatusカラムから'NEW'を消したり更新したらどうなる？
→ たぶんDBMSが参照を管理してて、変更出来ないんじゃないか。
・DEFAULT値の変更自体は、ALTER文で行ける。
→ ロードバランシングして、リネームテーブルを用意して本物と偽物を一瞬で入れ替えるとかで対応可。
→ ただ、ALTER文はロックが掛かるので一瞬DBが止まる。
■「プログラマのためのSQL 第4版」のP.70の注釈・↑が凄い BY @t_wada さん
■サーティワンフレーバーとこれまでのアンチパターンとの類似性・サーティワンフレーバーって、これまでの１～９章のどれかと似てる気がする。。。
・固定情報を割り当てるという点では、8章の「メタデータトリブル」に似てるかも。
・5章のEAVに一番似てるかも。
★感想：サーティワンフレーバーを最初読んだとき、この設計は無いわー、と私は思いました。
というのも、ふつーに第三正規系を思い浮かべると、この設計にはならないなぁ、と。
CHECK制約とかENUMとか思いつく方が珍しい気がする。
んでも、この日の読書会でいろいろな話を聞いて、このパターンを取りえる場合もあるのだなぁ、とあらためて勉強になりました。
あと、DBMSっていろんな機能をデフォで持ってるんやなぁ、と改めて気付かされた。
DOMEINとかCHECKとかENUMとか、これまで使ったことないし、存在さえ知らなかった。
上手に使えば、なんか使い道ありそうだ。
主催者の @natsu_nanana さん、参加者の皆さん、ありがとうございました～
★オマケ勉強会の後、みんなでアイスクリームを買って帰るの巻。
2013/10/10(木) 「第４１回 すくすくスクラム Team Geek Into Darkness」に参加してきました。
DoorKeeper
http://sukusuku-scrum.doorkeeper.jp/events/5847以下の書籍をターゲットとした勉強会？なのです。
場所は新宿のグロースエクスパートナーズ株式会社さんです。
参加者は30人くらいでしょうか。
この書籍、もともと興味あったんですよね～
あと、継続的デリバリーやDevOpsについての社内WGに参加しているんですが、そこのリーダーも読んでました。
今年のJolt Awardsを受賞した書籍でもあり、読まずにはいられない！
ということで、当日取った個人メモからダラダラと書き起こしてみる。
■本日のタイトル「Team Geek Into Darkness」タイトルにある「Into Darkness」は、やはりあの作品からでした。
映画『スター・トレック イントゥ・ダークネス』！
わたしもちょうど夏休み、公開初日に観てきました。面白かった！
角さんのスライド曰く、「すべてはスター・トレックにつながるのである」だそうなｗ
「日本の "ジョジョ" とかと同じで、海外では "スター・トレック" は常識」らしい！
そういやSQLアンチパターン読書会でも @t_wada さんが同じこと言ってたなぁ。
スター・トレック、恐るべし・・・
■Team Geekとアジャイル・「スクラムガイド2013」の翻訳をやった。
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf・Team Geekはアジャイルの本じゃないけどアジャイルっぽい
■アジャイルまでの歴史・IBM System/360 (1974)
→ コンピュータが世に広がる
・ソフトウェアの危機 (1968)
→ ソフトウェアの供給と需要のバランスが崩れ、需要が増えた。
→ これを受けて構造化プログラミングが登場した。
・構造化プログラミング (1970s)
・同時期に Winston W. Royceによる論文 「Managing the Development of Large Software Systems」が発表。
→ イテレーションのあるウォーターフォール。
・オブジェクト指向設計 (1990s)
→ ２つのパラダイムがある。
①アラン・ケイのオブジェクト指向
②C++のオブジェクト指向
→ 今回は①が対象。
■オブジェクト指向からアジャイルへ・「オブジェクト」を「人」に置き換えたのがアジャイル開発である。
・お互いにメッセージを遣り取りしながら仕事をしていく。
・「オブジェクト」のメッセージを「人」のメッセージに置き換えて考える。
・【結論】：「アジャイルは、オブジェクト指向を組織的に再現したもの」
■ハッカーとアジャイル・ハッカーとは、誰に頼まれるわけでもなく、好きなものを作る人たちのこと。
・UNIXができた70s以降に登場してきた。
■ハッカーとアジャイルの関係・「伽藍とバザール」の著者であるエリック・レイモンドの言葉：
→ 「ハァ？そんなの当たり前じゃん！でも、よくまとまっている・・・（妙訳）」
http://www.artima.com/weblogs/viewpost.jsp?thread=5342・ハッカーから見たアジャイルの感想↑
・マーチンファウラーが上手く纏め、「リファクタリング」と命名した。
・アジャイルに繋がる流れの１つにハッカー文化がある。
・纏めると、「アジャイルはオープンソースハッカーの振る舞いを再現したもの」
■アジャイルなチームの作り方(1) アラン・ケイの「オブジェクト指向」のような自己組織化した緩やかなつながりをしてもらいたい。
(2) ハッカーがオープンソースプロジェクトで見せるような「流儀」を踏襲してもらいたい。
→ そこで「Team Geek」を読んでもらいたい！
■ソフトウェア開発はチームスポーツである・Subversionの開発者でもあるTeam Geekの著者からの言葉。
■三本柱（HRT）１．謙虚（Humility）
２．尊敬（Respect）
３．信頼（Trust）
・結局これが大事なんだよね、と「ハッカー」が言っている点がポイント。説得力がある。
■HRTという３本柱のワークショップ
■(1) 運・運、ってなかなか難しい。良いチームが作れないのは、運が悪いから？
・でも、書籍の5.4.4節には、「運は鍛えることができる」 と書いてある。
→ ワークショップでやってみよう！
■ワークショップ「幸運のスコア」以下の問に対し、自分に点数を付ける。
・Q1. レジや銀行の列に並んでいて、知らない人に話しかけるときがある。
・Q2. 人生にあまり不安を感じない。
・Q3. 初めての料理や飲物に挑戦するなど、新しい経験が好きだ。
→ 点数が良い人ほど、「運のいい人」らしい！
ちなみに私は15点満点中、ロースコアで「運が悪い人」に分類された・・・
■運が良い人の傾向・運のいい人は、知らな人に積極的に話しかけて、新しい経験を喜んで受け入れる。
・とはいえ、それができれば苦労しない・・・
・新しいことした方が運よくなるっていう仮説は、ほんとう？
■「運」の話をし続けるワークショップということで、次に参加者でチームを作って、自己紹介せずに「運」の話をし続けるワークショップをやりました。
いろんな意見が出て面白かったです。
「レジや銀行の列では話しかけないけど、秋葉原でゲーム買うための列とかにいると、話しかけたりするよね」
「共通の目的で並んでいる人たちの列だと、話題も共有しやすいから話しかけやすいよね」
「たしかに知らない人に話かけた方が、思っても見ない新しい知識を得られたりというチャンスはあるよね」
個人的にも、たしかにQ1～Q3のスコアと運には関係性があるなぁ、と感じました。
■(2) 信頼・「信頼」も結構、難しいよね。
・例えば「納期を守る」とか、良いことをして「信頼貯金を増やす」というのがよく言われる。
・Team Geekでは、「弱点のある人は信頼デキル！」と言っている。
→ チームなんだから、弱いところを見せた方がいいよ。
・弱点がないのは危険
→ 「もう全部あいつ一人でいいんじゃないかな」と思われる。
■根本的な帰属の誤り・例えば鍵が見つからないと、自分の場合だと環境のせいにする。
・でもそれが他人だと、「アイツはバカだな、注意力がないな」などと、内面に帰属してしまう。
・そうじゃなく、「根本的な帰属の誤り」を前提にすることが大事。
・見せた弱点を克服する必要はない。チームで補完すればよい。
・なぜか怪我の話は盛り上がる。
→
格好悪い話は会話のきっかけとして最適。弱点を言い合うのは、チームビルディングとしていいのでは。
■ワークショップ：「みなさんの自己紹介」・テーブル毎に「最近失敗した嫌な思い出」を絡めた自己紹介をしました。
・実際やってみて、「格好悪い話は会話のきっかけとして最適」というのを実感した。
→ やっぱ、和むんですよね～。人間らしさが出るというか。クスッと笑いあったりとかｗ
■フード理論・ご飯を食べている人は、良い人。
・例えばTVで、家族で食事とかしてる場面は和むよね。それだけで家族団欒というか。
・Team Geekでは「チームで昼食を食べればいい」と書いている。
・飲み会に時々行くより、定期的に昼食を食べるようにした方が上手くいく。
---
この「フード理論」っていう概念、私、初めて知りました。とても納得。
たしかに、笑顔で美味しそうにご飯食べているシーン見るだけで、暖かい気持ちになれるというか。
ご飯を美味しそうに食べている人に悪人はいない、とまで思えてくる。
それが家族で団欒しながら、となると、なおさら。
■(3) 尊敬・「respect」を「尊敬」と訳しているが、「尊重」のほうがしっくりくるかも。
・モノとか価値観も含まれる。
・「尊敬」がなぜ重要かというと、Team Geekでは「チーム文化は自己選択的である」と言っている。
・著者がSubversionのチームをいったん離れ、数年後に戻ってきても同じ文化だった。
→ 文化が長続きしているのは、自己選択的にチームは作り上げられていくからなんだ。
→ これは、自分たちのチームが何を尊重するのかを最初に挙げておかなければできない
■ハッカーから尊敬されるためにできる５つのこと１．オープンソースソフトウェアを書く
２．フリーソフトウェアのテストやデバッグを手伝う
３．有用な情報を公開する
４．インフラが機能し続けるように手伝う
５．ハッカー文化そのものに貢献する
■技術的スキルよりも文化の適合・技術的スキルは学習できる。
・でも、文化が合っていない人がいると、生産性がマイナスになる。
・リコーUCSの事例：
→ 「プロジェクト大原則」を最初に作ることで、チームで尊重することをチームでわかってもらって、すごく便利だった。
■ワークショップ「尊敬できる人」・このチームで一緒に働きたいのはどんな人か？「技術的なこと＋文化的なこと」の両面で考えてみる。
・付箋紙に列挙してみましょう。
■付箋紙の正しい貼り方・自分の意見を１つずつ、付箋紙に書いて、
声に出してから貼る。
■付箋紙の正しい剥がし方・めくるのは素人。めくって貼ると、付箋が反り返る。
・達人は引っ張る！
・この貼り方を間違えると、付箋を頻繁に使うアジャイル開発では「アジャイルの素人」と思われるｗ
・あと、付箋を横から剥がすのは「古い」アジャイルの人ｗ
ということでチームで書き出し、バックログ形式に優先順位をつけて並べ替えをやりました。
ウチのチームでは、「一緒に働きたい人」の上位10位は以下のとおりでした。
１．楽しそうに仕事をする人
２．やさしくて明るい人
３．価値の高いものからつくる人
４．理想を語れる人
５．自分が知らないことでも積極的にやろうとする人
６．抱え込まず「みんなで」解決しようとする人
７．一緒に悩んでくれる人
８．ソフトウェアをつくる人
９．プログラミングが好きな人
１０．反対意見を言ってくれる人
ちなみに一位の「楽しそうに仕事をする人」は、私が書いた付箋でした。
みんなもそう思っているようで、ヨカッタ！
並び替えをやったあと、優先順位の上位にあるものの傾向をチームで考えたんですが、ここで気付いたのは
「技術スキルよりも人間的な要素を重要視している」という点でした。
また、これらの分析の後にチームでミッションステートメントを作成しました。
ウチのチームは、
「我々のチームは、ポジティブな行動に価値を置く」と定義しました。
他のチームのミッションステートメントとしては、以下のようなものが挙がりました。
・我々のチームは、ギークになることに価値を置く
・我々のチームは、未知なことの学習に価値をく
・我々のチームは、より良く楽しく目指すところに到達することに価値を置く
・我々のチームは、オープンに価値を置く
■(4) 謙虚・Team Geekでは、謙虚とは何か、という点にあまり触れていない。
・サーバントリーダーという考え方が大事なのではないか。
■サーバントリーダー・キリストが弟子の足を洗っている絵がある。
→ だからといって、玄関マットになるわけじゃない。自分の意見は言ってもいい。
・自分のエゴじゃなく、チームに貢献することなら言っても構わない。
■謙虚でも自分の意見は言う！・チームのためなら衝突も健全。衝突のないチームは不健全。
・謙虚であるけど、スクラムマスターは「悪魔の代弁者」となって衝突を作り出す。
悪魔の代弁者：
http://ja.wikipedia.org/wiki/%E6%82%AA%E9%AD%94%E3%81%AE%E4%BB%A3%E5%BC%81%E8%80%85・衝突後に後腐れがないように、これまで培ってきた信頼とかが重要となる。
■トーマス＝キルマン衝突モデル・衝突をどう解消するかを考えるためのモデル。
・4象限のうち「協調的」が目指すべき場所だが、そこに行くまでに時間がかかる。
・どれが良い/悪いかは状況によって違う。必ずしも「協調的」がいいわけではない。
■ワークショップ「衝突を解決する対立解消図」・LinuxのMLでは、リーナスは「感情を忠実に」表現するために、あえて厳しい意見を厳しい口調で言う。
・Team Geekの著者が所属するSubversionのMLでは、「謙虚を大切に」意見を出し合う。
・互いの共通目的は「チームを良くする」という点。
・これを解決するための対立解消図を作成してみましょう。
①対立を協調的に解決しようとすると時間がかる。
②妥協すると簡単に回答は出るが、それが良いとは限らない。
③まず、「共通目的は一緒だよね？対立してないよね？」と確認してください。
ということで、チームで対立解消図を作成しました。いわゆるTOCとかクラウド図という奴ですかね。
私、これやったの今回が初めてでして、お勉強になりました～
(5) 有害な人に対処する最後に、「有害な人」をチームから追放せざるを得ない場合の対処についてワークショップを行いました。
ウチのチームで出た意見を上位から並べると、以下のようなカンジ。
１．その人が役に立つプロジェクトを見つける
２．上司の力を借りて、それらしい理由をつけて異動させる
３．ヘッドハンターにプロフを渡す
４．その人が何を大事にしているか聞く
５．人でなく行動を指摘する
６．逆恨みされないようにする
他のチームからは以下のような意見が出ました。
・辞めさせる人をケアする。
・ローテーションでシステム的に追い出す。
・「有害な人を追放すればいい」という空気がチームで当たり前にならないようにする。
・その人が「辞めたい」と言った瞬間を見逃さない。
ローテーションで追い出す、というのは面白いですね。これだと自然に追い出せるのかも・・・
■まとめ(1)
運は鍛えられる
(2)
信頼は弱点を見せて獲得する
(3)
尊敬できるものを決めておく
(4)
謙虚であっても衝突セヨ
(5) 有害な人にはしかるべき対処をセヨ
■最後に物事はシンプルに考えよう。他のことは忘れても、
HRT（謙虚・尊敬・信頼）だけは覚えて欲しい。
ハート様は偉大だと再認識いたしました。
★感想：この書籍にもともと興味があったこと、講演者が角さんということで高いクオリティが期待できることからこのイベントに参加しましたが、とても勉強になりました。
特に、以下の概念に感銘を受けた。
・運のいい人は知らな人に積極的に話しかけて、新しい経験を喜んで受け入れる
・フード理論
・格好悪い話は会話のきっかけとして最適
・衝突を解決する対立解消図
ワークショップも、とても考えさせられる内容で、とても勉強になりました。
まだ書籍、全部読んでないので、引き続き読み進めたいと強く思いました。
惜しむらくは、著作権の関係で、スライドが一般公開されてないことｗ
ハート様、残念です・・・
あと休憩時間に流れていたBGM、あれ、FF6ですよねー。私が大好きな作品です。
「子供のころ一番好きだったテレビゲームは？」と聞かれたら、迷いなくFF6と答えるであろう！
今でも実家にSFCが残ってて、去年かな、帰省したときに8周目をクリアした。
今でもFF6の曲はMP3プレイヤーに入れて聞いてます。
SFC時代のFFは神だと思っているが、FF6のインパクトは今でも忘れない。
最後に主催の角さん関さん、参加者、関係者のみなさん、ありがとうございました。
2013/10/5(土) 「TDD Boot Camp 横浜 3rd」に参加してきました。
DoorKeeper
http://tddbc.doorkeeper.jp/events/5751Togetter
http://togetter.com/li/572791場所はアジャイルサムライ横浜道場で毎度おなじみ、アットウェアさんです。
参加者は30人くらいでしょうか。非常に高い出席率からも、TDDBCの人気の高さが垣間見えます。
実は私、TDDBCは7月に引き続き、2回目の参加です。
今回は連続になるので、申し込み時はちょと躊躇しました。
なので、もし定員がいっぱいになったらキャンセルして、他の人にお譲りするつもりでした。
ただ今回は欠員募集もあったりと比較的余裕があったので、そのまま参加させていただくことにしました。
前回、とても楽しかったし、すごく勉強になったし！枠が開いているのに見送る理由が見当たらない。
ということで、とても楽しみに当日の朝を迎え、起きたら既に9時20分・・・
はぎょぉぉぉ！半泣きになりつつ急ぎ身支度して出発。なんとか10分程度の遅刻で済みました。
■基調講演講師： 安井 力さん
やっとむさんと言えば書籍「アジャイルな見積りと計画づくり」が真っ先に思い浮かびます。とても名著。
今回の基調講演、いつもの @t_wada さんではない点がポイントなのです。
安定のクオリティ、やっとむさん。
講演内容は7月のTDDBCと被るところが多いので、今回は書くの省略。内容についてはコチラ参照↓
今回はやっとむさんがTDDBCに対する思いを述べられた部分のみ、メモ。
■by やっとむさん・やっとむさんがTDDをやり始めて10年。
・TDDをやろうと思ったのは、面白そうだったから。
・TDDをやる前は、自分の見れる深さに限りがあることに気づいた。
・TDDをやれば、もっと深い綺麗ななところに辿り着けることに気づいた
・TDDにより、脳味噌の想像力を超えた設計に到達できる。自分の能力を拡大することができる。
やっとむさんが今回講師を引き受けた思いは、ブログにも述べられています。良いですね～
■ペアプロ・TDDデモ次は @PoohSunny さんと @terahide27 さんによる、ペアプロ・TDDデモです。
お2人とは横浜道場やJUnit写経会などで顔なじみです。TA、いいなぁ。。。
このデモは参考になりましたねー。前の2人の進行に合わせて私も一緒に手を動かしてました。
Quick JUnitとか、前回のTDDBC以来の使用で、久々に思い出したよ。。。
あと、ToDoリストって大事だよね、と改めて気づかされました。
■昼食タイム同じテーブルのメンバーとTDDやプログラミング言語などの話をしながらお弁当を食べました。
こーゆうのも楽しいですねー
あと、グリーンバンドが頒布されていたので私も買いました。
これ、ずいぶん着け心地が自然なんですね。
着けるとけっこう違和感とか感じるのかな？とか思ってたんですが、ぜんぜん気にならない自然なカンジ。
これならプログラミング中はずっと着けていても良いかも。
挫けそうになったら左手のグリーンバンドを見て、「プロなんだからテストを書かなきゃ！」と思うことにする！
■TDD&ペアプログラミング 実習 / コードレビュー午後はペアプロタイムです。
今回は、SQLアンチパターン読書会でいつも一緒の方とペアを組み、課題に取り組みました。
お題は「Javaの奇妙なバージョン」！
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C3rd%2F%E6%BC%94%E7%BF%92いやー、とても勉強になった。
やっぱ実際にペアプロを実践する時間が多く確保されているのはTDDBCならではです。
実際やってみて、とても頭を使って悩んだりハマッたりして、いろいろ考えさせられた。
ウチのペアが途中まで取り組んだEclipseプロジェクト一式、Githubにアップしておきました。
https://github.com/makopi23/java_junit-masterあとコードレビューの時間も大変参考になります。
自分トコのペアだけじゃなく、他のペアがどう取り組んだのか、TAはどう考えたのか、等々。
■質問コーナー参加者の質問にTA陣が応える質問コーナーです。
ペアプロをやった後にこーゆう時間があるのもTDDBCは良いですねー。
実際手を動かしてみたら、けっこう疑問って出てくるもんだと思います。
あと、スタッフ自身が質問を書いて自分でそれに回答するスタイルとか、斬新すぎるｗ
■振り返り、クロージング最後にKPTを参加者みんなで書きました。
KPTはスタッフの @shinyaa31 さんが文字に起こしてくださいました。感謝！
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C3rd%2FKPT
■懇親会ピザやビールを食しながらの懇親会です。ここからが本番といっても過言ではないっ！
社外のいろんなエンジニアさんとお酒飲みながら、TDDやプログラミングの話に花を咲かせるのは楽しいです。
つーか、LT大会、カオス過ぎｗ
飛び込みのLTとかも多かったし、クオリティも高かったし。
いやー、とてもよく笑ったｗ
★感想：ホント有意義な時間を参加者のみんなで共有できて、今回参加できてよかったなぁ、と思います。
講師やTAをはじめ、スタッフさんの素晴らしい運営にも感謝！
TDDBC、是非エンジニアさんには参加してほしいイベントだと思います。得るものが非常に多い。
そして何よりも、楽しい！
この日学んだTDDを、ぜひ業務に活かしていきたいと思います。
講師、TA、スタッフ、参加者の皆様、ありがとうございました。
2013/10/1(火) 横浜道場 特別編 「まつじゅんの現場で使えるコーチングとファシリテーション」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/5948以下の書籍をターゲットとした読書会なのです。
とはいっても書籍を読む通常会は終わってしまったので、今回は特別会。
テーマは「コーチングとファシリテーション」で、講師はプロジェクト‐ファシリテーター協会の理事長、松本潤二さんです。
場所はいつもの横浜、アットウェアさんです。
参加者は25人くらいでしょうか。特別編はいつも参加者多いですね～
■講演スライド講演スライドは横浜道場のFacebookにアップロードされています。
そのURLをGoogle Docs Viewerに渡すとブログに埋め込めるらしいので、やってみる。
このGoogleのサービスは良いですねぇ。
■講演＋ワークショップ以下、個人メモを復習用にダラダラと書き起こしてみる。
■１．プロジェクトファシリテーション■プロジェクト・ファシリテーション（PF）とは？・チームに対してなんか働きかけをして促進すること。
・リーダーシップ・コラボレーション型で、有機的に人が動くようにする。
■なぜPFが重要か・移り変わりが早いのに追従するため。
・コミュニケーション能力が高い人材って大事だよね。
・システムを企画から運用にまで持っていく段階で、全体の80%くらいがコミュニケーションで、残りがプログラミングとかが占めているのが実情である。
・PFが重要なのは、健全なプロジェクト運営がしたいから。
■PMとPFの関係(1) PM（Project Management）＝ 動脈 ・管理、教えるイメージが強い。
・力強くPJを進めていく。
(2) PF（Project Facilitation）＝ 静脈 ・血液がめぐるようにする
---
(1)' PM的視点・明確な指示命令系統。
・いわゆるWBS。目標と現状を最短で結ぼうとする。
(2)' PF的視点・今から見た時に、こんなふうに変わっていくんじゃないかな、という視点を持ってやっていく。
・PFの方にいると、メンバーと近くなる。
・メンバーの可能性とか成長を期待して、関わっていく。
・柔軟に目標すら変えていく。
・チームに凄く一体感がある。
---
・悪いプロジェクトというのは、上手くいってないときに口を出すPMがいる。
・目標は変えたくない、という立場なので、チームが疲弊する。
・大事なのは、PMもPFも両方必要だということ。
・ただ、今多くのプロジェクトの現状を見る限り、PMが8割くらいでPFが少ない。
・なので「PFもっとやろうよ」がミソ。
■PFの価値・対話
・行動
・気づき
・行動
・笑顔
■PFの原則・見える化
・リズム
・名前づけ
・問題 vs 私達
・カイゼン
■２．プロジェクト・ファシリテーターへの道のり■ファシリテーションとは・促進する、助ける、円滑にする、場を作る
・個人の能力を100%以上発揮するチームの場作り（相乗効果で100%より上に持っていく）
■ファシリテーターのスキル・状況に合わせて色々ある。
①ホワイトボードの使い方、机の並べ方
②司会進行、アイスブレーキング
③などなど
■どうやったら参加者を解きほぐせるのか？・アイスブレークをする時は、これからやることに意図を向けてアイスブレークすべき。
・例えばこのあと議論をする場合には、参加者が口を開くアイスブレークをする。
・「声を出しましょう」じゃなくて「隣の人と会話してみましょう」という風に持っていく。
■ワークショップ１： 自己紹介＆他己紹介・各テーブルでまず「自己紹介」をする。
・その後、「ちゃんと自己紹介、聞いてましたよね？」と言って、次に「他己紹介」をさせる。
→ 「左隣の人の自己紹介を思い出して、あなたがテーブルのメンバーに左隣の人を紹介してみましょう」
・「他己紹介」をさせる効果として、「人の話をちゃんと聞こう」という気持ちが強くなる。
・その後のワークショップで周りの話を聞いてほしいなら、こういうワークショップを最初にを入れる。
★実際コレやってみて、なるほどなぁ、と思いましたね。
■ワークショップ２： 右隣の人の良いところを紹介する・最初の「他己紹介」と、場の様子が違っていた。
・「他己紹介」の時は、左隣の人の自己紹介内容を思い出すのに一生懸命になっていた。
・今回のワークショップは盛り上がる。というのも、隣の人から自分の良いところを言われるので、まんざらでもない気持ちになる。
・このようなワークショップをやることでメンバーの気分が高揚して、感覚的なところから入っていけるようになる。
★このワークショップも実際やってみて、納得です。
■ステルスファシリテーター・ファシリテーションは「隠れてやる」のが大事。ステルス。
・ファシリテーターが目立つのではなく、趣旨は「場が最大限に良い状態になる」こと。
・PFが必要ないくらいに変化をもたらすことが出来るのが良いとされる。
■コーチングとは・「教え」たり「指示」せず、「質問」を通して自分で考え選択し決定することを促すこと。
・一般的にはこう定義されることが多い。でも、質問することがコーチではない。
・「認知・承認」という言葉は、コーチ業界ではよく使われる。
・「私はあなたのことをちゃんと見ているよ」という関わり方が「認知」。
・プロジェクトでは「認知・承認」がすごく大きい。
・仕事は丸投げでもいいけど、「あなたがちゃんとやってくれているのを私は知っているよ」とすると、相手のモチベーションが上がる。
■フィードバック・自分のことなのに、よく知らないことが多い。それを「他己紹介」などで気づかせたりさせる。
・言葉と感情が離れている時は、フィードバックしてあげたほうが良い。
・例えば相手の表情をきちんと見て、「君、やるって言ったけど、嫌そうな顔しているよ」とちゃんと仕向ける。
・相手が失敗してから「君、以前、自分でやるって言ったよね？」とするのは最悪な対応である。
・そういう声をかけてあげられるかが大事。
・コーチはクライアントの鏡である。クライアントとの信頼関係が重要。
・一方向に捉えない。コーチとクライアントとの関係性をコーチングとする。
■チームメンバのパフォーマンス・「こいつをどうにかして仕事もっとさせてやりたい」とか「この上司をどうにかしてやりたい」というのはよくある。
・より良くしよう、という気持ちを相手に押し付けると辛いだけ。上手くいかないケースが圧倒的に多い。
・「人は思い通りに動かない」、「人は自分の思ったとおりにしか動かない」ということが分かった。
・なら「やりたいな」自ら思うようにしてあげればいい。無理やり「やれ」はダメ。
・やる気が芽生えれば、その人は放っておいてもやるようになる。
・やる気のない人間に対して「やれ」と言うとパワーがいるし、相手に反抗されるだけ。
・自らやりたい、となるような環境を作って、そういう関わり方を相手にしてあげるようにすること。
■そもそも、人なんだからブレがある・金と時間と能力をかけて、5%の能力を上げるのはすごく大変。
・でも、気分がノッていれば、すごく良いものが作れたりする。
・良いチームを作れば、チームのパフォーマンスを10%上げるなんて、楽勝。
・でも、元々良いチームに対して、そこから10%上げるのは難しい。
■人間的なコミュニケーション・「意味的コミュニケーション」と「情動的コミュニケーション」の2種類がある。
・「意味的コミュニケーション」というのは、情報を正しく伝えましょう、ということ。
→ これは普通にちゃんとやればいい。
・大事なのは「情動的コミュニケーション」である。
・自分がイラッとしたら、「私はイラッとしています」と声に出して言うこと。
・そうすることで受け取り側が「あ、こいつ怒っているな」と分かることが重要。コレ、とっても大事。
・結局、ほとんどの場合において、何を伝えたいかは、「情動」。
・「意味」は渡せば伝わる。そうじゃなく、わざわざコミュニケーションをとるのは「感情」を伝えたいため。
・そこをちゃんと受け渡せるコミュニケーションをしましょう。
・「情動」がちゃんと出てもいいよ、という場作りをファシリテーターはすべき。
・鬱憤を話すことによって、消えてなくなることはたくさんある。なので、話を聞いてあげること。
・「意味」も「情動」も、両方大事。相互補完的に必要である。
■Co-Active Coachingとの出会い・CTI Japan（コーチ養成機関）には「４つの礎」がある。
①「人はもともと想像力と才知にあふれ、欠けるところのない存在である」
・人はもともと、その可能性を持っている。何かが欠けている人だ、と見ないようにしましょう。
②「今この瞬間から創る」
・チームのメンバとして動く際に、「今この瞬間ベストだ」ということに意識を向ける。
・「場」は生き物。この瞬間に乗っかって何かをやっていくことが重要。
・例えば、3分前に笑いを取れたとしても、それは後には繋がらない。
・会議で「それはどうかな？」と思った場の雰囲気を流して、その1分後に、「さっきの雰囲気は良くなかったですよね」と言っても、その感覚が参加者は既に薄れているので、「そうだっけ？」となってしまう。
・なので、その場でまた新たに作ってしまう。
・そのムードが漂っている瞬間に言うと、それは大事なインパクトになる。
・その空気を皆が共有している、というのを信じてほしい。その瞬間に声を出してみることが重要である。
・それで、皆が「そうじゃないよね」と言えば、それは本当に「そうじゃない」となる。
・そうなると、その場ですぐに流せる。それができるのは、その瞬間は皆が雰囲気を共有しているから。
・1分後に過去のものを持ってきて、「さっきこうでしたよね」と主張しようとすると、ひっこみがつかなくなるだけ。
■今のままでOKを前提に・ダメっていう評価をよく下すが、生き物は悪い方のチョイスは絶対できない。
・感覚的に正しいと思うことしかできない。
・その瞬間にとってベストのチョイスをとる。その積み重ねで今がある。
・なので、自分は結果としてベストチョイスの上にいる。なのでOKと捉える。
・後悔もあるが、今の自分から見ると、より良いチョイスを今は知っている、という成長と捉える。
・こう考えるようになってから、後悔はあまりしなくなった。
・何かを決めるときに、自分の感覚に聞く。どちらを取りたいかを聞く。
・過去を振り返った時、自分の感覚はこっちをチョイスしてた、というのは否定できない。
・それは後悔のしようがない。だって、どうやっても選べない。
・自分の思った方と逆を取って結果的に良くても、「あっちの方が良かったかなぁ」と絶対に後悔する。
・なので、出来る限り、感覚的なチョイスをしてほしい。
■環境面からのアプローチ・環境を操作することで、人の行動は変わる。
・例えばアジャイルだと、貼り物によってどうなるか、みんなすごく考える。ここは赤ペンで書くべきか、とか。
・自分が一番と思うことをやって、周りの反応を見て、それで変えてみる。
・そうすると、環境が変わる。すると、なにかしら影響を受ける。
・その人にとって良いか悪いか、生きるか死ぬか、が大事。
・そういう自然の動きは人にインパクトを与える。
・例えばホワイトボードのフレームに意識向ける人はいない。それは均一で変化しないから。
・手書きは大事。かんばんも手作りが良い。貼りモノのほうが、明らかにインパクトがある。
・他と違うところに注意を向けるのは生き物の習性。それをちゃんとやりましょう。
・ただ、やりすぎると魂胆が見えるので逆効果になる。
・良くなる方向に向かう感覚は、けっこう鈍感。逆に、危機に対する感覚は鋭い。悪意はすぐにバレる。
■ワークショップ３： 俯瞰的に人を見るコーチングのワークショップ・情動的な表現ってみなさんどのくらいできるかな。
・感情に関する言葉をできるだけたくさん出してホワイトボードに書いてみましょう。
（ここで1分くらい時間を取る）
・言葉が出てくると、その感覚がわかる。
・あんまり書けなかった人は、「知っているけどできない」という、よくある状態になっている。
・まず、言葉を使うこと。使えば書けるようになる。
・さらさら書けるようになると、そのニュアンスのタイミングでその言葉がすっと出るようになる。
・極の振れた言葉を２つ３つしか持ってないと、微妙なニュアンスを伝えられないので、コミュニケーションミスが多くなる。
■ワークショップ４： お悩み相談室(1) ルール・まず３人組になり、各人に役割を振る。
①コーチ役
②クライアント役
③オブザーバ役
・まずクライアント役がコーチ役に対し、「今、気がかりなこと」について1分間、話をする。
・それを聞いて、コーチ役が「あなたの大事にしていることはこれですか？」と聞く。
・オブザーバ役は、コーチ役がクライアント役に問いかけた際の、クライアント役の表情の変化を読み取る。
(2) ワークショップの趣旨・コーチ役がどれだけクライアント役の心に響くコメントができたか、オブザーバ役は観察をする。
・どういうコミュニケーションが良いのか、このワークショップから学ぶ。
(3) 注意する点・コーチ役は、クライアント役が「大事にしていること、願っていることはなんだろう？」と思って話を聞くこと。
・人に興味を向けて質問を向けましょう。
・相手の本当の願いはなんだろう？と思いを馳せながら話を聞いて欲しい。
---
★このワークやってみたんですが、じっくり相手の表情を観察する、という機会は中々貴重ですね～
やっぱ、感情は表情に出るので。
どういう問いかけをすれば効果的なのか、考えさせられる機会になりました。
オマケ：講演の一場面
★感想：ファシリテーション、というのはヒューマンスキルとして、重要ですよね。
例えばスクラムマスターの役割って、まさしくファシリテーション、そのまんま！
自分の感情をちゃんと表情に出して相手に伝える、とか、この瞬間の自分の判断が「ベスト」なんだ、という考えとか、グサッと来ましたね。
非常に勉強になりました。
あと懇親会で、講師のまつじゅんさんと @terahide27 さんと3人でしばらく会話してたんですが、ファシリテーションのオススメ本とかを教えていただきました。
ただ、まつじゅんさんは、「本から得るよりも実際にやってみるほうが良い」と強調されてました。
ちなみにこの時にオススメされた書籍、10/5(土)のTDDBCで @terahide27 さんが貸してくださいました。感謝！
講師のまつじゅんさん、参加者のみなさん、ありがとうございました。
★オマケ：
この特別編の3日前、9/28(土)に横浜道場のメンバでBBQやってきました。楽しかった～。
サンマ、頑張って焼いたけど美味しくてよかったです。
主催の @natsu_nanana さん、参加者のみなさん、ありがとう＆お疲れ様でした～
2013/9/30(月) 豆ナイト Presents 「DAD はアジャイル開発の決定打となるのか？」に参加してきました。
こくちーず
http://kokucheese.com/event/index/109869/以下の書籍をターゲットとした勉強会なのです。
DAD本に関するセッションを聴講するのは、これが３回目です。
初回はDevsumiで江木さん、次はDevloveで岡さんと藤井さん、そして今回の中佐藤さん。
ウチの会社も某・巨大SIerで、アジャイルを推進する立場にある私にとってDADの考え方には大変興味があります。
あと、DevloveのDAD本読書会にも参加してますが、この日も読書会の方が数名参加されてました。
顔見知りもチラホラと。
こーゆうイベントや勉強会でDADがもっと広がるといいですね～
というわけで、当日メモした内容を復習用にダラダラと書き起こしてみる。↓
■あしたの反復のために、その１
～ タイムボクシングのおさらい ～講演者：津田義史さん（Microsoft IPX Team）
この日の講演スライドは公開されていないようですが、先日のXP祭りのスライドが参考になりそう。
トヨタのかんばんに学ぶバックログ管理術http://www.slideshare.net/YoshifumiTsuda/ss-26194950あと、津田さんの以下の著書も参考になります。
■タイムボックスとは・タイムボックスとは、開発プロジェクトの期間を表す箱で、入り口と出口が付いている。
・作業とか機能とか修正するバグとか、時間を使うものはすべて箱に詰める。
・箱に詰めることを「タイムボクシング」と言う。
■作業が箱に入らない場合どうするか？１．無理やり押し込む
２．箱を大きいものに取り替える
３．全部入れることを諦める
・正解は３。
・１は、残業とか休出とか作業の品質を落としたりとか、酷い品質で出来上がった挙句、チームが疲弊する。
・２は、結局箱が足らなくなる。いつまで立っても終わらなくなる。
・３は、本当に必要な作業から詰める。
・本当に必要な作業を詰めていく事で、苦痛を和らげる（mitigation）ことができる。
・不要なものを追い出すことでリーズナブルな値段で開発できるようになる。
■トレードオフ１．品質
２．納期
３．範囲
・それぞれトレードオフだが、３を調整しましょう。
・タイムボックスの適切な長さは、入れたい作業の大きさによる。
・そうはいっても、大きすぎる箱は使いに行くい。その場合は、箱の中に箱を入れて入れ子にする。
・箱から溢れたものは次の箱に入れるのがタイムボックスの戦略。
■スコープボックスとは・スコープ固定でスケジュールを動かすこと。フィーチャーボックスとも言う。
・これはデスマになりやすい。
■バックログとは・残作業のこと。
・タイムボックスの入り口でバックログを作成し、タイムボックスの出口までに全部やる。
・「全部やる」とすると、タイムボックスとスコープボックスで何が違うか？
→ 計画の立て直し方が違う。
・スコープボックスは、スケジュールを延ばす。
・タイムボックスは、作業の範囲を減らす。入らないものは先送りする。これを「パントする」と言う。
・作業をパント（延期）することで、次のタイムボックスの中にいる誰かにキャッチしてもらうことを期待する。
・バックログはタイムボックスの「計画」である。無理な計画は立て直す。溢れそうな作業は早めにパントする。
・ポイントは、「早め」にパントすること。タイムボックスの出口で「できませんでした」はNG。
■ソフトウェア開発における在庫とは・ソフトウェア開発に置ける在庫とは、スプリントバックログのこと。
①スプリントバックログ：このスプリントでやる作業
②プロダクトバックログ：次以降のスプリントでやる作業
・「バックログ」はスクラムの専門用語ではない。「バックログ」を辞書で引くと、以下のように書いてある。
１．残作業
２．在庫
３．着陸できない滞空中の未処理分
・飛行機は、着陸できない場合は上空で旋回する。
■バーンダウンチャート
（出展：
トヨタのかんばんに学ぶバックログ管理術 P.55）
・グライドパス：理想的な滑空経路を表す。直線。
・フライトパス：実際の飛行経路。ジグザグ。
■在庫とは・工場の在庫とは、出荷してない部品のこと。
・ソフトウェアの在庫とは、バックログの中にあってまだ完了していないもの。
■不良在庫とは・工場だと、「出荷できずに抱え込んでいる在庫」のこと。
・ソフトウェア開発だと、スプリントの出口までに完了できる見込みがないもの。
・ソフトウェア開発の不良在庫を減らすには、バグ報告表やタスクかんばんの枚数を減らせばよい。
・では、どうやるのか？
→ パントする。これが今日のオチ。
■適切な在庫量を維持する・適切な在庫量は、グライドパスが目安を教えてくれる。
・グライドパスとフライとパスが乖離していると安全に着陸できない。
■在庫のまとめ・在庫(backlog)を計画的に完成(done)して出荷(deliver)する。
・在庫量を適切に保ちましょう。
■タイムボックスの本質・パントの是非について。「パントって問題の先送りでしょ」って思う人がいるのでは。でも、そうじゃない。
・先送りしてはいけない問題と、先送りすべき問題がある。時間は有限である。
・そもそも前提として、パントしなくて済むように実現可能な計画を立てることが大切。
・もし溢れそうになったら
１．無理やり詰め込む。
→ 残業をして見込みがあるなら、残業するオプションがある。
２．箱を大きいものに取り替える。
→ これは止めるべき。ズルズルいくと、優先度を見失っていつまでも終わらなくなる。
３．全部入れることを諦める。
→ これが「パントする」ということ。
・建てた計画が無理と分かったら、作業の「品質、納期、範囲」のどれかを諦める必要がある。
・ここで諦めるのは「範囲」である。今やるべきことと、今やるべきでないものを正しく分けること。
・正しく２つにわけることで、納期を守り、箱をいっぱいにして、すべての箱で全力疾走しましょう。
■パントのまとめ・現実的な計画を維持する。
・アジャイルも計画駆動である。無理と分かった計画は、「計画」ではない。
・優先度の低い作業をパントして計画を立て直す。
・設定したゴールにalignするように優先度を判断する。
・何度もパントしなければならないような状況なら、何かが間違っている。
・「パント」と言うと、ちょっとカッコイイ！「先送りする」というと、ネガティブな感じになる。
■DAD のエッセンス講演者：中佐藤麻記子さん
2013/12/11 スライド追記
■DADについて・IBMのRationalの仕事をしたのが、DADに巻き込まれたキッカケ。
・DADは原著よりも少し薄くなっている。これは珍しい。
・DADの話は本の中に全部入っている。今日はエッセンスを拾って話す。
・先日のDevloveで岡さんがDADの講演されていたが、以外なエッセンスの引っ張り出し方をしていた。
・翻訳者でさえ人により何をポイントとして語るかが違う。今日は中佐藤さんが感じたエッセンスを話す。
■特徴１： エンタープライズアジャイル ≠ 大規模アジャイル・「エンタープライズ」って何よ？となると、大体想像されるのが、「大規模システム」。
・DADは大規模システムだけじゃない。小さいシステムも含まれる。
・ここで言う「エンタープライズ」とは、「普通の企業システム」を指す。
・エンタープライズアジャイル ＝ 普通の企業システムのアジャイル
・「継続的デリバリー」はWebアプリのゲーム開発とかのイメージがあり、一般企業システム開発のエンジニアにとっては「ウチとちょっと分野が違う」と思う人がいる。DADは、こういう人のためのもの。
・DADは「普通のアジャイル＋α」がある。企業システムが対象である。
■特徴２： 現実直視(1)
・DADの前書きの１行目に「プロセス戦争は終わった、そしてアジャイルは勝利を収めた」と書いてある。
・前書きにあるように、「やっぱアジャイルは効果を出しているよね」というのが実際。
(2)
・スクラムだって、スプリントを始める前に準備作業したり、移行作業もしてるよね。
・なら、「はっきりとそう言おうや！」
・DADはその結果としてフェーズ分けをしている。「方向付け」、「構築」、「移行」の各フェーズ。
・フェーズ分けは非常に難しい。「それってウォータースクラムフォールじゃね？」と誤解されかねない。
・これを如何に伝えるかが重要。まず本の読み方として、「ケーススタディ」を読んでください。
・ケーススタディを読むと、一番手っ取り早く、そのフェーズで何をするかが分かる。
・移行フェーズが、ウォータースクラムフォールの「フォール」じゃないことがよく分かる。
■特徴３： ゴール指向・それぞれのフェーズにゴールが決まっている。
・「この成果物を作ったら終わり」とかじゃなく「このゴールを満たせれば終わり」としている。
・例えば方向付けフェーズのゴールの１つに「ビジョンを特定」と書かれているが、そのやり方は本に書いていない。
・DADは抽象的に書いてある。抽象度を１つ上げている。
・「このゴールを満たしなさい」という徹底的なゴール指向。
・では「ビジョンを特定」をどうやるか？結論は「自分たちで選びましょう」。
・DADは、その選択肢がたくさん書いてある。
７つのプロセス
６０のプラクティス
３７の戦略比較表
１９５の戦略
（岡さんが数えてくださった！）
・DAD本にはこれだけ載っている。ここから好きなの選んで！という方針で書かれている。
・これを聞いて「なーんだ」と思われるかもしれない。でも、DAD本の21章にはこう書いている
「あなたが直面している固有の状況に、最も効果的にアジャイルを適用する方法について、あなた方に正確に伝えられるような本を我々が書くことができると仮定するのは、おこがましいことだろう」
・DAD本の翻訳者の半分はIBMの社員。私も、IBMの方からの一言が今でも支えになっている。by 中佐藤氏
・その一言とは「Think」
・これが一番大事な言葉。DAD本は21章の文章にもあるように、「自分で考えていただきたい」と行っている。
・その考える方向付けをするのがDAD本の役割である。
■お気に入りポイント１： 「時々、妙に細かい」・例えば15章の「日時調整ミーティング」には、以下のように書いてある。
"「私は、今日はほぼ終日ミーティングです」という発言だと、「あっそう」で終わる。
そうじゃなく、チームに対し、自分が今日何をするかを具体的に話すこと。
例えば「今日はDBAと30分ミーティングをして、～して、さらには～して～します」と言ったほうがよい。
そうすると、チームとの情報のやりとりが発生する。"
ここまで書いてあって、妙に細かいｗ
■お気に入りポイント２： 「時々、妙に嫌味ったらしい」・本の帯に「初期に詳細に要件定義された要求は、詳細に定義された憶測にすぎない」と書かれている。
・時々、妙に嫌味ったらしいｗ
■お気に入りポイント３： 「そう、それ！」・8章に「本当の価値は作成されたモデルではなく、モデリングという作業そのものにあることを認識すること、これを重要な思想として採用すべきだ」と書いてある。
・要するに、作ったユースケースに意味があるというよりも、ユースケースという道具を使って、チームで議論して認識が一致することが重要である、と言っている。
・「アジャイルな見積りと計画づくり」という書籍でも、「計画が重要なのではなく、計画づくりが重要なんだ」と言っている。
・できたもの「そのもの」じゃなくて、「それを使ってチームで合意がとれること」が重要である。
DAD本には「そう、それ！」と思えるようなことが書いてある。
■（自称）アジャイラー（アジャイリスト）へ(1) 先人の多くの知恵の上に、アジャイルが存在していることを認めましょう・CMMIやRUP（Rational Unified Process）/UP（Unified Process）も、ちゃんと使えばガチガチなものではない。
・非難する人は、使い方を間違えただけ。
・RUP/UPは反復なんだけど、重いということでアジャイラーから目の敵にされる。
→ とんでもない。アジャイルを知っている人ほど、軽く使えるはず。使えない「人」が問題なんだ。
・アジャイルサムライの「インセプションデッキ」の中身は、RUPの「開発構想書」というドキュメントそのもの。
(2) ほとんどの開発（企業内システム）では、「その他の利害関係者」が重要であることを認めましょう・反対派が目につく。アジャイルはロールをあまり決めていない。
・でも既存システムとかは、「その他の利害関係者」がすごく重要。
・DADのターゲットはエンタープライズであり、既存のシステムとの関わりの中でシステムを立ち上げなくちゃいけない。
・いろんな制約や人の中でどうやるかをDADはターゲットにしている。
(3) 設計手法抜きにアジャイルは語れないことを認めましょう・スクラムというフレームワークは、作業の回し方のみ定義していて、設計手法の話はしてない。
・でも、設計手法の話は必要である。「設計せずにモノ作ればいいんだろ」は誤解である。
・設計しないと、とてもスプリントなんか回らない。ちゃんと設計手法ありきのアジャイルをやりましょう。
■アジャイル（実質）否定派へ(1) そろそろ言い訳をやめませんか①契約
②品質管理
③人
・よく言われるのが、「自立性がある人がいないとダメなんだよね」
・でも、それって本当か？自立性が無い人と思い込んでプロジェクトを作っていないか？
④日本固有の環境
・一番大嫌いな理由。言い訳以外の何者でもない。アジャイルの手法はWFでも取り入れることはできる。
・「ウチの会社・業界は特殊だから」という言い訳。
・そもそも、すべての会社はすべてユニーク。
・その中でいかに改善できるかを考えるのにアジャイルを検討すべき。
(2) そろそろ現実を見ませんか・本当に、一括請負でスコープ調整はしていませんか？
・本当に、最初に要件定義、設計したとおりに最後まで作っていますか
・本当に、プロセス・テンプレートがあれば誰にでも作れますか？
・アジャイルの標準プロセスを作りたい、とよくおっしゃる。
・会社で標準を作って、「これを使え」と言えば誰でもいけるか、というと無理。
・そうじゃなく、教育と両輪で考える。教育を先行させる必要がある。
・優先順位を間違えている会社が多い。テンプレートを作れば誰でもいけるか、というとそうじゃない。
・ウォーターフォール以上に、アジャイルは教育に力を注ぐべき。
■パネルディスカッション：「アジャイル開発の行方」・モデレータ：羽生田さん
・パネリスト：津田さん、中佐藤さん、山田さん、藤井さん
■書名の「ディシプリン」ってなんなの？・翻訳チームが一番揉めたのが「Decipline」の翻訳。翻訳者が11人もいると、用語集を作るので揉めるｗ
・用語を決定する基本は、売れている本に合わせる。例えば「アジャイルサムライ」とか。
・文化的な背景から思い浮かべるイメージは実際と異なる。
・「規律」と聞くと、上からやらされるイメージになってしまう。
・翻訳者で「丸々２時間、ディシプリンについて語る会を開こう！」
→ でも、その会に監修の藤井さんが来なかった。。。
・結果的にディシプリンは「規律」と訳すことになった。
・津田さんの著書「実践 反復型ソフトウェア開発」では、「ディシプリン」は「職種」という意味で使っている。
→ それは職種によって従う規律があるから。
・「ディシプリン」という意味には「体系化された知識」という意味がある。
・アジャイルはほっとくと気ままにやられるイメージがあるので、整理して体系化するという理由で「ディシプリン」とした。
・DADは「お行儀の良いアジャイル」。ディシプリンに絡んで、「作法（さほう）」という言葉を使うことがある。
■DAD本の使い方・方向付けの章は、ゴール指向とかが纏まっている。あれをチェックリストがわりとかで使える。
・必要な部分を選んで、お試しスクラムの中でやったりしている。
・「方向付けフェーズ」が一番大事で、あの表が一番つかえるなぁ、というのが実感。
・始めてアジャイルをやる企業さんは「で、最初に何したらいいの？」とよく言われる。
→ DADはそのリファレンスに役立つ。コンサルのネタ本として使える。
・開発チームのメンバなら「アジャイルサムライ」とかを読めばいいと思うが、DAD本が今までのアジャイル本と違うのは、ステークホルダーが敵対していたりとか、どこから手をつけてどう進めるのがベストに近いのか、とかのヒントを与えてくれる点である。
・DAD本はアジャイルのコンサルや、経営者の説得をする人の役に立つ。今までのアジャイル本とは系譜が違う。
・DAD本は、アジャイルの環境をアジャイルと関係のない人を含めてエコシステムとして記述しようとしている点が新しいとこかな、と思う。
■エンタープライズと大規模開発について・XP祭り2013の著者パネルディスカッションでも書いたが、「エンタープライズアジャイル＝大規模開発」を想像してほしくない。
・DADは大規模アジャイルをやる手法ではない。
・DADは「Scaled Agile Framework(SAFe)」とは別物である。
・Developers Summit 2013 Summerで「エンタープライズとDevOps」というパネルディスカッションがあったが、エンタープライズの定義を誰も説明しなかったｗ
・大規模の前にディシプリンのステージがある。
・大規模でもアジャイルはできると思っている。できないのは、アーキテクチャとかちゃんとしてないだけ。
・エンタープライズアジャイルはしがらみ。そこはシステムの規模の大小じゃない。
・リーンスタートアップのように、１から新規開発というのはほぼ無い。
・周りの人的環境がまったく違うのはエンタープライズの論点。
・自分たちが置かれた他社との関係性について、DAD本は表にたくさん書いてある。
・それをユーザと見て、どれを採用するかを決めていけばよい。
・タイムボックスを大規模プロジェクトに導入する時に「タイムボックスで同じ期間を繰り返す」というのは本質ではない。
・いつものスプリントは４週間だけど、今回６週間でやろう、というのもある。
・規模が大きくなればなるほど、出口を共有するのは不可能。その場合はサブチームでタイムボックスを切ってもよい。
・大きなタイムボックスの出口をメンバーで共有するのが大事。
■DADを現実ラインに落とすには■Question・DAD本は分厚い。現場で危惧しているのは、DADと別物ができてしまうのでは？という点。
・このくらいで十分だよ、とか現実ラインに落とすのが大事だが、どんなふうに落としていこうと思われるか？
■Answer・これは一概に言えない。一つの会社でもプロジェクトによって違う。
・アジャイルのアンチパターンでさえ、あるチームには有効だったりする。
・３人ペアプロとかうまくいった事例とか、朝会を毎日１時間やる上手いミーティングを見たことある。
・ここで絶対忘れていけないのは「コンテキスト」という言葉。「何が優先か」というとコンテキスト。
・３人ペアプロとか１時間朝会がなぜ上手くいったのか、の「なぜ」を考えることが重要である。
■品質保証(QA)のエンジニアさんへのお願い・プロセスを標準化して品質を上げようとする考え方を、少し違う方向に向けていくべき、と考えている。
・というのも、あるQAエンジニアから「DADの区切りを標準化したいんです」という相談がきたことがあった。
・その時は「一概には無理です」と回答した。
・その人に何を薦めたかというと、「スクラムをやってるチームを実際に見に行ってください」という点。
・現場によって求められているものが違うので、現場を見て、もう一度、線引きを考えてみてほしい。
■チームのルール・プロジェクトの規模が大きくなればなるほど、ルールを厳密にする必要がある。
・プロジェクトが小さくても、守るべきルールはある。例え小さくても守るべき。
・まずは絶対に守ってもらえるルールから入る。
・開発の段階でもルールは変わる。
・プロジェクトが進むに連れて、ガイダンスをチームに出してやっていく。
・そうすると、上手くいかなかったルールを外すこととかができるようになる。
■お客さんから指標を求められたらどうするか？・お客さんは決められないので、こちらから指標は出すようにしている。
・品質保証部門のエンジニアは、手順を決めてガイドを出すことが仕事だと思っている。
・本たくさん読むくらいなら手を出しなさい。そこから理解が深まっていく。
・何をもって自分たちのものが成熟するのかを考えること。
・プラクティスを足すにも、足すとどうなるのかをきちんと考えること。
■アジャイルと契約・アジャイル開発をやるから契約をこうします、とお客さんに言えたら、それはラッキー。
・でもRFPに「アジャイル開発を一括請負で」と書いてあれば、それは受け入れるしかない。
・じゃあどうするかを考える。
・でも、今までウォーターフォールでスコープ調整ってしてないか？というと、実際はやってるでしょ。
・それをやりやすくしましょう、と言っているのがアジャイル。
・契約は開発チームからはどうしようもないところで決まる。
・アジャイルでやる時に、結果的に契約がどうこうだから上手くいかなかった、というのは経験がない。
・消去方法でいったら準委任契約が良い。
・でも、結局は契約とか品質とか、互いにどうやればいいか、という点に尽きちゃう。
・アジャイルだからどうこうじゃない。
・ウォーターフォールのプロジェクトは失敗に慣れているから、言い訳がつくだけ。
・でもアジャイル開発は慣れてないから、契約で失敗するとdisられる。
・何のためにお金を使うのか、という根本が考えられていないから、契約の話に行ってしまう。
・契約を口にだすのはウォーターフォールでも出来ないんだ。
■アジャイルの普及について・「アジャイル、アジャイル」、もうウルサイ！
・そうじゃなく、アジャイルが当たり前になってほしい。
・アジャイルがあたりまえになるのは、オブジェクト指向があたりまえになるより圧倒的に早い。
・アジャイルは「合理性の追求」という言葉が一番しっくりくる。
・そういうマインドがない限り技術のトレンドに確実に置いてかれる。
2013/12/11追記
ブログを書いた後、Youtubeに動画が上がっているのを知ったので貼り付けておく。
★感想：皆さんのお話を聞いてて、「なるほど、やっぱそうだよね～」と思うことが何度かあって、大変参考になりました。
中佐藤さんの「そう、それ！」みたいな感じｗ
あと、翻訳者の江木さん、岡さん、中佐藤さん、藤井さん、それぞれポイントに挙げている点が異なるのも面白いですね。
こーゆう生の声を、複数人の翻訳者から聞けるというのは大変貴重です。
いろいろ気付かされて、反省するハメになりました。大変ありがたい。
関係者の皆様、ありがとうございました。
2013/9/26(木)「BPStudy#73」に参加してきました。
connpass
http://connpass.com/event/3353/Togetter
http://togetter.com/li/569383場所は代々木研修室です。
参加者は50人くらいでしょうか。
BPStudyは始めての参加でした。
今回のテーマが増田さんの「ドメイン駆動設計」と和智さんの「組織パターン」の2本立てということで、両方とも非常に興味があったので、ちょうど良い機会ということで参加したのです。
ちょと日が空いてしまいましたが、個人メモを復習用に書き起こしてみる。
■第１部 ドメイン駆動設計入門 発表者： 増田 亨 氏（Twitter:@masuda220)
■１．ソフトウェアの核心「ドメインモデル」■業務システムの基本構成・業務システムの場合は、お客さんが使うとこと、他社とのデータ連携などバックがある。
・ドメインモデルを中心に作る、ということは、画面アプリとか連携アプリとかがあり、そのど真ん中に業務のデータとかロジックを集めたドメイン層があって、それを画面から使うことになる。それに拘っていく。
・問題領域に関わるモデルをソフトウェアでまず作る。
■ドメインモデル・データと業務機能をコードで表現する時に、データと機能を１つのクラスに集約していく。
・データと、それに関連するロジックは一塊にする。さらに、それをビジネス層に集約する。
・データと機能をクラスにまとめる、これに拘る。
・「データ中心アプローチ」と「プロセス思考アプローチ」があるが、DDDでは両方を見ながら固めていけばいい、という発想になる。
・データを考えはじめたら最後までそれやる、とかではなく、「データ」と「機能」を互いに行ったり来たりしながら設計する。
・クラスにカプセル化し、データと機能を結びつける。
・データと機能の関係に注目していくのがDDDの基本中の基本。別れちゃうのはDDD的にアンチパターン。
■関連するデータと機能はクラスにまとめる(1) 氏名クラス・氏名オブジェクトがあるとする。そこに「旧姓も知りたい」という要件がある。
・例えば女性が結婚すると苗字が変わるので、苗字はあまりあてにならない。
・そこで、苗字を取得するメソッドとしてoriginalFamilyName()を氏名オブジェクトに持たせる。
・最近は漢字を見ても読み方が良くわからない名前があるので、名前の「カナ」が重要になる。
・その場合は、氏名オブジェクトのキーは「カナ」にし、取得用のnameKana()メソッドを用意する。
(2) 住所クラス・どの沿線に住んでるかが重要になることがある。そのため沿線を取得するline()メソッドを住所クラスに用意する。
・「駅」じゃなくて「沿線」を気にするドメインにおける設計。
(3) 連絡手段クラス・曜日や時間によって連絡先を切り替えたいというドメインがあるとする。
・その際は、夜はこの連絡先、土日はこの連絡先、と決め細やかに設定できるようにしたい。
・Firstchoice()メソッドは、曜日とか時間でリターン値が変わってくるメソッド。
(4) 連絡履歴・連絡履歴というのは仕事上ですごく重要になる。
・例えば連絡を取った直近3人を知るためのメソッドとしてlastThreeContents()を用意したりとか。
このように段々と成長させ、見つけてはクラスとしてプログラムしていくかのがDDDである。
■ドメインモデルをみんなで使う・業務のデータとロジックはビジネス層に集約させ、それを画面アプリケーションから呼びだす。
・同じドメインモデルを複数のアプリから使って実現していく。
■作る順番(1) ドメインモデル・まずドメインモデルを最初に書く。どこの層にも依存させず、独立性の高い形で作る。
(2) データベース・次にデータベースを作る。モデルからDBを扱えるようORマッピングを行う。
(3) サービス層・次にサービス層を作る。
・ユーザを登録したいとか、機能要求を実現するための簡単なファサードクラスを用意する。
・各用途ごとに使いやすいようにするサービスクラスを作る。
(4) 機能テスト・この段階で機能テストする。それより小さいテストはしない。
・ドメインクラスレベルではなく機能レベルでテストを書く。
・ドメイン駆動にはテスト駆動開発は馴染まないと思っている。
・ドメインを探索しているフェーズでは、テストから駆動はありえない。何をテストしていいかわからない。
・それよりも、分析とか思考に力を割いて、落ち着いてからテストを書くようにする。
・ドメイン層のテストには力を入れていない。
・でも機能のテストは自動化に力を入れたい。現状は上手くいってない。
・考え方としては、サービス層まで来たらテストを行う。
(5) アプリケーション ・そのあと、アプリケーションを作る。
・ここではロジックをゴリゴリ書くことは少ない。
---
・ただ、お客さんと話すときはモック画面は早い段階で作るし、デモもする。
・でも、全体の組み立てる順番は(1)～(5)な感じでやっている。
■なぜドメインモデルパターンで作るのか？・それは、「コード量が減る」から。
・リファクタリングしながら、機能追加しながらドメインモデルに乗せたらコード量が激減した。
・「コード量が減る」というのは、メリットとしては一番大きい気がする。
■コードが減れば１．テストが減る
２．ドキュメントが減る（もともとあんまり書かないが。。。）
３．バグ調査が楽になる。
４．変更の影響が見通しやすい
ドメインモデルで何が起きているかをトレース出来ていれば原因や場所も特定しやすい。
これらにより、不安感が軽減された。
■ドメインモデルはコードの重複を減らす・データがあるところで処理すればばいいのに、わざわざgetterメソッドで値を取得してた側で処理するのは「いやな臭い」である。
・集約しましょう。データを持ってるクラスに業務ロジックをまとめる。
・最終的に欲しい値がポンッと返せるクラスにする。
・getterメソッドをみんなが使い始めたら、間違いなくあちこちのクラスに処理が重複している。
■コードが膨張するアンチパターン(1) トランザクションスクリプト・「トランザクションスクリプト」とは、機能単位、ボタン単位にスクリプト形式でロジックを書いているようなコードのこと。
・違うボタンがあれば、また同じコードが並んでいる。
・そうなると画面が別でも日付処理が互いに重複したりする。でも日付に対する考え方は統一されているべき。
(2) 使われない共通業務ロジック・共通業務ロジックって、実はあんまり使われてない。
・ボタン駆動の時に、「共通化したもの使おう」という考えがあんまり沸かない。
・それは、画面単位で分ける設計だと「ここは共通だよね」というコミュニケーションが少なくなるから。
(3) どこでも業務ロジック・トランザクションスクリプトにさえなってないコード。
・例えばViewやControllerに業務ロジックを書いたりとか。
・例えば「1件もデータが見つからなかった場合はこちらの処理しろ」といのがControllerにあると、それは画面と流れが分離できていない設計である。
(4) SQLに業務ロジックをベタ書き・SQLのWhere句で演算をしてしまうとか。
・演算がロジックだったばあい、どういう役割分担でやるのかを考える必要がある。
・どれをDDDオブジェクトに振ろう、とかをきちんと設計する。
・SQLに埋め込む情報はDDDオブジェクトから受け取れ、とはしている。でもこれは議論の余地がある。
★ドメインモデル・ビジネス層に業務ロジックを集めましょう！■ドメインモデルの本当の価値(1) 業務知識の浸透・DDDをやると「業務の仕様としてそれはどうなんだ」という議論が増える。そういう活動が多くなる。
・結果として、システムの価値とかの知識がチームに浸透してくる。
・縦割りで機能を割り振るのに比べて、あちこちの機能の連携が理解できるようになる。
・それを2ヶ月くらいやってると、現場の肌感覚とか知恵がチームメンバの中に浸透してくる。
(2) 言語表現を超えた暗黙知が育つ・業務ロジックはプログラミング言語で表現するが、それを超えた感覚の業務知識が増えてくる。
・例えば、コツとか感どころとか。
・「言葉」としてよりも「感覚」として体に入ってくる。チームの中で暗黙で方向感が出てくる。
(3) あたりがつくようになる。---
でも、一言でこうなるわけじゃない。DDDを汗かきながらやるのが実態である。
■２．ドメインモデルとオブジェクト思考設計■個人的な話・最初はアンチオブジェクト思考だった。
・でもDDDをやる時には、オブジェクト指向のある側面は非常に役に立つ。
・DDD著者のエリック・エヴァンスが、今のメジャーのパラダイスはオブジェクト指向だ。と書いていた。
■部品化アプローチ(1) 集める・データとロジックを１つのクラスに集める。マーチン・ファウラーの本にもそう書いてある。
・パッケージの重要性もDDDをやるとすごく意識するようになった。ドメイン層設計のキモかもしれない。
(2) 目的に特化する・例えばString型には何桁でも入る。
・でもそういう汎用的なものは、プログラム書く際に、結果的に縛りをかける時に不安定になる。
・それならStringではなく「人の名前」というクラスに閉じ込める。
・ガチガチに制約が入ったコードにしておけば、安心して使える。あちこちif文で判定するも必要ない。
・書く行が増えそうだが、実際やってみると、ロジックの散在がなくなってコード量が減ってくる。
・目的に特化するのはとても良いやり方だと実感した。
(3) 業務用語の粒度にあわせた部品・DDDでいつも粒度の話がでてくるが、考え方は簡単で、「業務用語の粒度」に合わせればいい。
・単語が出てきたら、クラスにする。
・例えば「合計金額」に値と計算ロジックがあれば、クラスにすることで局所化される。
・業務用語を見つけましょう。
■区分と分岐・ifやswitchでコードを書きまくってると、仕様変更の際にバグの温床になる。
■多態：インタフェース宣言と実装クラス・実際としてアプリ開発のキモになる。
・業務のロジックを、クラスで分けてしまう。IF文で分けない。これで整理できる範囲はかなり広い。
・この辺をやるとだいぶ楽になった。
■制御構造の再利用・IoC（制御の反転）
・自分がswitch文で制御をやるんじゃなくて、フレームワークにやらせる。
・フレームワークに制御させることでコードにif文がなくなる。
■補足：パターンについて・パターンをベタで書くことは最近ほとんど無くなったのが実感。
・昔はGoFのデザインパターンを書いたが、いまはSpringとかでできる。
■３．ドメイン駆動設計のインプット■最初に手に入れるべき情報とは・最初に手に入れるべき情報は「ビジネス企画書」である。トップ向けのプレゼン資料とか予算申請資料とか。
・「なぜ予算がとれたのか？」とか、そういうのが重要。
・あとは、「ドメインのガイドブック」も最初に手に入れる。
・手探りじゃお客さんにヒヤリングしてても時間が足りない。
・3種類の本を読む。
①簡単な本
②分厚い本
③薄い英語本
・③は、クラス名とか見つけやすい。巻末のインデックスからクラス名を探す。
・あちこちからリファレンスされている用語をクラス名にする。
・クラス名で悩むくらいなら、薄い英語の本を買いましょう。
■いつも気にすべき情報・気にすべきことは「言葉」。
・ちょっとした会話でも気にしないとDDDではダメである。
・お客さんとの会話で、モデルの中の言葉で説明できるのかを気にする。
■データと機能・重要なのは「データ」と「機能」のハイブリッドなアプローチ。
・常に、「データ」と関連する「機能」を対にする。それが一番の重要ポイント。
■ドメイン駆動設計の基本スタイル・プロセス大事。繰り返さないとリズムが出てこないので、リズムを意識する。
・目的に特化したほうが楽になる。
・一発で良い設計なんてできないので、リファクタリングしながら育てていく。
第２部 『組織パターン』の読み方 発表者：和智右桂氏（Twitter：@digitalsoul0124）
講演スライドは公開されていないようで、無念。。。
ということで手元のメモを起こしてみる。
■組織パターン・組織パターンには何が書かれているのか、と言われると結構難しい。でも敢えて言えば「パターン集」ではない。
・ノウハウをすべて吸収して読もうとすると、パターン数が多くて迷子になる。
・パターン1個1個に価値はあるが、読むときはふわっと全体を掴むようにしたほうが取っ掛かりが良い。
・巨大ウォーターフォールや精鋭アジャイルといった、どちらの極にも振らないもう１つの答えが組織パターン。
・成長するチームがソフトウェアを育てる。これが組織パターンの原風景。
■パターンとは・アジャイル手法はパッケージにされる。例えば「XP」とか「Scrum」とか。これとこれをやりなさい、とか。
・James O. Coplienはそういう方法はとらない。この本を手に組織改革をしないでくれ、と書いている。
■パターンの定義・ソフトウェア開発で有名なのはデザインパターン。
・オブジェクト指向で設計する時によく出てくる問題の対処方法をパターンにした。
・パターンは繰り返し現れる。
・あるコンテキストにおける問題を解決する。
・ある問題を解決すれば別の問題がまた生まれる。その問題を解決するためのパターンが続く。
・これが組織の成長のプロセスと重なっている。パターンの繋がりがパターン言語である。
・書籍には100個くらいのパターンがあり、繋がりでまとめられてる。
・このパターンを解決すると、次にはこのパターンに続くことが多いよね、とか。
・プロセスに従っているから大丈夫だよね、という思考停止が一番問題。
■４つのパターン言語・プロジェクトマネジメント
・組織の漸進的成長
・組織のスタイル
・人とコード
■プロジェクトマネジメント目立つところを取り出すと
・スケジュールの細分化
・継続的なデリバリー
・バックログ
こういうのがプロジェクトマネジメントのパターン言語では目に引く。
スクラムの源泉。いわゆるアジャイル系。
■組織の漸進的成長(1) 小さい組織を徐々に大きく・そうするにはどうすればいいか？
・人を段階的に増やしましょう。
(2) 多様性が重要・優秀な人が集まったグループって、ワークショップの結果にブレークスルーがあまりない。
・チームに同じ属性の人が集まると、突き抜けない。
・それよりも、最初はバラバラだと思ったチームの方が突き抜けることが多い。
・多様性に富んだチームが結果を出す。男と女とか、国籍の違いとか、会社の違いとか。
・多様性はJames O. Coplienの主張にある源泉。
(3) トラックナンバーを少なく
・「トラックナンバー」とは、プロジェクトのメンバーの内、トラックに轢かれるとプロジェクトが継続困難になる人数のこと。
・トラックナンバーをなるべく少なくしましょう。
■組織のスタイル(1) 分割統治 大きいものは分けましょう。
(2) コンウェイの法則・ソフトの構造は組織の構造に似せなければいけない。これが分けるコツ。
(3) 生産者を中心に・コードを書く人に情報が流れるようにしましょう。
・指揮官が中心にいるようではダメ。価値が生み出す人に情報が流れるようにする。
■人とコード・アーキテクチャ重要
・情報共有重要
・インタフェース重要（実装は意識しなくてよいように）
■作業が内側に流れる（4.1.18節）・開発者が真ん中にいて、開発者がPMとか顧客と直接会話しましょう。
・ステークホルダーと開発者の間には防火壁を入れましょう。
■コンウェイの法則（5.1.7節）・和智さんが大好きな法則。
・オフショア開発とかは当てはまるのでは。
■現場に根ざしたノウハウ(1) 細かいリスケをしない(2) 暗黙的な要件・細かい要件はあとから出てくる。暗黙的な要件があることを見込みましょう。
(3) 常に誰かが進捗させる・何か問題がおきても、スケジュールに沿って進める人を残しましょう。全員で問題に当たるな。
■まとめ・全体感を捉えつつ、個別の話を読むのが面白いのでは。
・組織パターンで一番重要なのは、「道はひとつではない」ということ。
・すごく美しい世界が展開されているわけではない。
・自分の組織を批判する道具としては使わないでほしい。
・書籍に改善できるヒントがあれば、是非改善していってほしい。
★感想：第1部のドメイン駆動設計ですが、増田さんの講演は今回で3回目くらいです。
そういう意味では、いつもと違う切り口で話してくださって、重複も少なく良かったです。
1時間じゃ足りずに4章の実装の話がほぼ駆け足になったので、1時間半くらいあっても良かったのかも。
大変参考になりました。ちょうどDDDの読書会にも参加中のことだし。
第2部の「組織パターン」ですが、これは元々興味があった本なんですよね。
ちなみに講演者の和智さんは↑のDDD本の訳者でもあります。
んで図書館には予約を入れていたんですが、この日の講演には間に合わず。
その後、無事借りられました。（まだ読んでいませんが）
こーゆう分厚い本は漠然と読むよりは、ポイントを理解したうえで読むのが大事だと思っています。
なのでこの日の講演でその辺が聞けてよかったです。
講演者様、スタッフ様、皆様ありがとうございました。
-->
