makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DDD Alliance! 3週連続DDD 第2週」に参加しました

2015/09/10(木) 「DDD Alliance! 3週連続DDD 第2週」に参加してきました。

DoorKeeper
http://ddd-alliance.connpass.com/event/18961/

Togetter
http://togetter.com/li/873126

先週行われた第1週も参加しました。そんとき書いたブログはこちら。
2015/9/2(水) 「DDD Alliance! 3週連続DDD 第1週」に参加しました

今回は台風の影響でどうなることやら、と思いましたが、無事開催されてよかったです。
でも、大雨で日本あちこち大変だったようですね・・・

というわけで、今回も自分の復習のため、口頭説明部分を中心に当日取ったメモを書き起こしてみる。


第2週(8章~13章)深いモデルの探求
3週連続ddd その2 深いモデルの探求 from 増田 亨


第1週のおさらい

■ 抽象データ型/段階的な抽象化人間の発想に近づける (P.7)
  • 人間の発想に近づけるというのは、今日の第3部でもポイントになる。 
  • 汎用的なLocalDateクラスじゃなくて、誕生日に限定した独自定義クラス(DateOfBirth)まで持っていく。

■ 俯瞰 (P.9)
  • 第1部 ドメインモデルを機能させる 
    • ドメインは大切だね、じゃなくて、エヴァンスはもっと極端なことを言っている。
    • ドメインモデルを中心にすべてを組み立てる。
  • 第2部 モデル駆動設計の構成要素
    • 第2部は基本スキル。必要最低限。でも、いくら第2部を実践してもDDDのメリットや効果は出てこない。
    • 3週連続でしゃべろうと思ったのは、この辺を話そうかな、と思ったから。第2部に時間をとられて話せない部分を話したかった。
  • 第3部 より深い洞察へ向かうリファクタリング
    • ドメインモデルが現場に役立つのは、第3部を頑張った結果として出てくる。
    • 第2部でリポジトリとか実践しても、ぜんぜん恩恵はない。

■ 主題:モデルを活用する (P.11)
  • この図がDDDのキモ。
  • 膨大な技術を噛み砕く、自分から集めていく。集めるだけでなく、鋭く説明するにはどうすればいいんだ、に切り込む。

■ ドメイン (P.12)
  • ドメインモデルは、要約したもの。本当に重要な語彙に絞ったものがドメインモデル。
  • ドメインモデルがコードになってるのは、ドメイン層の5%とかのコア。ちゃんと要約しにいかなければならない。
  • ドメイン層全体がドメインモデルというわけではない。
  • 狭い範囲を深堀する、という考えは前提知識として持っていたほうがいい。

■ ドメインとソフトウェア (P.13)
  • 自分たちは右下の「ソフトウェア」に関心がいく。
  • 「ソフトウェア」の左上の境界に現れる画面設計書とかにドメインの言葉が出てくる。
  • でも、それ以外の活動でどう関心事が出てくるか、自分から外に出て、取りに行かなければならない。
  • なぜその人が活動しているか、その目的とか経緯とかまで思いを馳せることが重要。
  • 外に広げれば広げるほど楽になる。
  • ここまで知れば楽になる、じゃなくて、どんどん外に行って、動機とか背景まで知りに行ったほうがわかりやすくなるかなと思っている。

■ モデル (P.14)
  • 大変なのは本質的でないものを削る力。判断できるようになるには、相当知識がないとできない。
  • どちらかを選ばないといけないのに選べない、という状況は、自分の知識不足なだけ。
  • 何が重要かを追い求めるが大事。
  • 厳密に組み立てる力は、ソフトウェアは厳密にしないと破綻するので、ほっといてもフィードバックがかかるはず。それよりも削る力の方が難しい。

■ 第2章 コミュニケーションと言葉の使用 (P.17)
  • ドキュメントを書くくらいなら、聞けばいいじゃん。
  • ただ、残しておいたほうがいい情報はドキュメントにすることはある。
  • ただ、それは厳選する。大事な情報はソースコードに表現されているはず。
  • ユビキタス言語は、「いつでも、どこでも、だれとでも」。エンジニア同士の会話でさえも、お客さんと使うような共通言語を使うべき。

■ 第3章 モデルと実装を結びつける (P.19)
  • DDDでは、モデルはコードに落とす前の作業、ではない。モデルを書いてても、常にコードを考えろ。
  • 具体的に論理的に常に考えてないから、すぐにコードに落とせないんだ。
  • コードを書く人がドメインを深く理解することが最も効果的。
  • ドメインの言葉を使ってるエンジニアのほうが、スキル優れているエンジニアよりいいものを作る。一緒にやってて安心感がある。
  • 1~3章を実践することがドメイン駆動設計。それができれば、第2部以降はHow Toに過ぎない。やりかたは他にたくさんある。

■ 【広告】DDDの3原則を体験的に学ぶ (P.21)
  • 実践のワークショップをやる。 http://ddd-alliance0002.peatix.com
  • 本の実践ではない。
  • 要約力を体験する。
  • 苦労せず楽しくドメインを学ぶにはどういうアプローチがあるか体験してみる
  • UMLとかではなく、言葉とラフスケッチを使ってモデリングする。クラス設計に練り上げる。

■ 第2部のおさらい モデル駆動設計の構成要素 (P.22~)
  • 主題は、モデルと実装の一致なんです。
  • モデルを熟知していても、コードと乖離することはよくある。非常に難しい。
  • そこが不一致になると的外れで構造がねじれたソフトウェアになる可能性が高くなる。変化に適応できなくなる。
  • とにかくモデル(主要な概念)がコード上にあらわれているようにする。それがDDD。
  • そこに切り込むのが今日の第3部のテーマ。

■ 第4章 ドメインを隔離する (P.25)
  • プレゼンテーション層とかアプリケーション層とかデータソース層に、ちょっと修正でIF文とかが入りやすい。
  • そうじゃなく、ドメイン層に集めること。
  • 大切なのは、その3層に紛れ込んでくるドメイン知識をドメイン層に徹底的に移していくこと。

■ 第5章 ソフトウェアで表現されたモデル (P.27)
  • 書籍の図5.6にValueオブジェクトのクラス図が出てくる。5章はこれが理解できるかどうかがすべて。
  • 住所という概念をクラスとして切り出す。ただし、2つで1つだよ、という集約を意識しなければならなくなる。
  • そのトレードオフを相当DDDは振り切っている。関心事ならば、クラスとして分離しろ。
  • 左のクラス図の発想でいる限り、第3部の話は理解できない。
  • 左と右のクラス図の差は非常に大きい。狙ってるのは右のクラス図なんだ。

■ 第6章 ドメインオブジェクトのライフサイクル (P.29)
  • オブジェクトをDBに入れて取り出す、というライフサイクル管理は、別のクラスに担当させることによって、ユーザの関心事をシャープに表現しやすくなる。
  • それらは外出にしましょう。
  • 本質は、ドメイン層をピュアに保つための考えの一つ、ということ。

■ 第7章 より実戦に近い練習 (P.30)
  • 第2部の理解度チェックとして、人と語り合ってみるのが有効。
  • 最初のステップで、ドメイン層を隔離するためにアプリケーション層を導入している。この1ページがキモ。
  • 「ドメイン層」の議論を「機能」視点から隔離し、注目しなければならない情報はなんだっけと考える。
  • ドメイン層にHTMLやSQLのコードが入ると汚染される。
  • そうじゃなく、アプリケーション層を導入して、こーゆう機能を実現します、という「機能」の視点から隔離する。
  • ドメイン層の視点でものを見に行こう。
  • この発想の転換は最初すごく苦労した。
  • 機能分割とか、そういう議論ではない。ドメイン層の議論は、機能の議論でもI/Fの議論でもない。
  • チームがこれを当たり前にできるようになれば、相当変わる。

■ 第2部は基礎練習 (P.31)
  • ここまでの第2部は、当たり前の内容。でも相当ハードルが高い。
  • 私はサッカーが好きなので、スライドの例もサッカーで表現している。
  • 練習の時からヘラヘラやってるのはムカつくんですよ。
  • 練習の時から、試合で90分が経過したヘロヘロの時間まで、徹底的に確実にやること。
  • 第2部わからなかったら先に第3部へいってもいいが、行ったり来たりすることを常に意識してほしい。
  • 常に行ったり来たりすることで、より良いものができていくんだ。


ここから今日の本題

■第3部 より深い洞察に向かうリファクタリング (P.32~)
  • 第1部がきっちり理解できて実践できていれば、第3部はどうでもいいかも。
  • ここまでやると本当に役立つよ、というのをチームで共有できると、もっとわかってくる。

■ 主題:実際に役にたつモデルを探す (P.33)
  • なぜこの章構成なのか、疑問があって、つかみどころがないところがある。
  • 読み直したけど、ちょっとよくわからないな、というところがある。

■ 第3部 導入 (P.34~)
  • ドメイン層の話。
  • 設計技法の話とか技術用語とか出てきても、ぜんぶ疑って欲しい。
  • エヴァンスが第3部で書こうとしてこととズレてるんじゃないか、と疑って欲しい。

■ 役に立つモデル (P.36)
  • 主要な関心事は何? それをわかりやすく表現するのはどういうこと? というのが第3部。
  • コードを相当しなやかにしておかないと、追随できなくなる。

■ コードのいやな臭い (P.38)
  • いやな臭いのTOP4を書いている。
  • コードが悪い、というのはエンジニアならすぐ分かるはずだが、それだけでなく、DDDとして一歩踏み込むこと。
  • 例えば、ドメインの概念を見つけ出して、それをメソッドとして抽出するとか。

■ 「分割」ではなく「抽出」 (P.39)
  • 「分割」ではなく「抽出」ということに気づくまで、すごく時間がかかった。
  • ウォーターフォールなら、大きい物は分割しろ、となる。抽出が分割であると誤解してた。
  • 大きいから分けるんじゃなくて、大きいなら、価値があるものが埋まってるから、それを取り出せ。
  • 小さくするんじゃなくて、大事なものを抽出するんだ。
  • 大きかったら分ければいいや、という考えでは、第3部は理解できない。
  • 隠された大切なものを発見して、それを抜き出す、という考え方は非常に重要。

■ 深いモデル (P.40)
  • ドメインの表面的な側面を捨て去る、とあるが、こーゆうものを捨て去れ、とパターンされてない。なので自分で意識してください。
  • 1章で「トポロジーを外した」みたいな話。でも第3部で具体例が出てこない。
  • でもモデリングのキモ。いかに捨て去るか。
  • 第3部に書かれているパターンをソースコードにすべて適用しようとしても、得られるものはほとんどない。
  • 深いモデルを探求するために焦点を絞っていくのが第3部。
  • どこにフォーカスして第3部の内容を徹底的にやってみるかのフォーカス決めも第3部の重要なテーマ。

■ 深いモデル/しなやかな設計 (P.41)
  • こっちよりあっちのほうが重要だよね、と一言いうのは簡単。でもコードを組み替えるのは難しい。
  • なのでコードのしなやかさが必要。そうしないとコードがついてこなくなる。

■ 「モデル」の発見のプロセス (P.42)
  • 「モデル」という言葉から、コードを書く前にする作業、という考えになるが、そうじゃない。
  • モデルは開発プロセス中で発見していくんだ。

■ 8章 ブレークスルー (P.43)
  • 「なんだ、そういうことか」、「目から鱗」といった経験。
  • 問題意識を持ち続けていれば、「あ、こうすればいいのか」と気づくことができる。
  • 凄い気づきが見つかったからハッピーだよね、じゃない。
  • 凄い気づきを元に実験して実装しなおす判断は、インパクトが大きくてリスクになる。それをどうやってチームで制御しながら取り組むかがブレイクスルーのキモ。

■ シェアとシェアパイ (P.45)
  • 協調融資によるリスク分散。そのドメインの話。
  • 最初の設計は、一回ごとに貸出するシェアと、限度額のシェア、の両方が入り組んでいた。
  • それが、「シェア」と「シェアパイ」にクラス分けることでブレークスルーが起こった。

■ 兆候と結末 (P.46)
  • 兆候に気づいたのが、ブレークスルーに至る重要な感覚。
  • おかしいな、という違和感を持ち続けて、常に疑うことが大事。

■ 第9章 暗黙的な概念を明示的にする (P.48)
  • ドメイン駆動設計のキモ。探求したかったら概念を掘り出しに行きなさい。
  • でも、現実は相当難しい。受託で納期もあるし無理な仕様変更も降ってくるなかでやるのは難しい。
  • 概念を掘り出す5箇条に取り組むこと。

■ 2.ぎこちなさを精査する (P.52)
  • ドメインの言葉で語ってみる。
  • ifとかelseとかが自分の言葉から出てきたら、ドメインの言葉で語れていない証拠。

■ 3.矛盾について熟考する (P.53)
  • 矛盾を感じたら、記憶にとどめておくこと。書き留めなくても良い。
  • 後々、「あぁ、こーゆうことだったのか!」と気づけた時に、それは矛盾じゃなくなる。その時に学習成果になる。
  • 「あー、そうなんだ」と、新しい理解として認識してしまうと、すんなり通りすぎて、学びとして残らない。

■ 4.文献を読む (P.54)
  • 新人教育のテキストがあれば、ぜひ読んでください。そいう人向けに理解させようとする何かが得られる。
  • 全部を自分で理解する必要はない。聞ける人を人脈として育てておく。自分の仕事も楽になる。
  • 文献は、全部を精読しない。
  • 目次や「はじめに」や第1章などで使われている全体図とか比較表、用語集をうまくピックアップして、それなりの感覚をつかむ。

■ 5.何度でも挑戦する (P.55)
  • 回数を繰り返すことが「概念」を発見する基本。

■ 9章の補足 (P.57)
  • 制約、プロセス、仕様、の3つ。これをオブジェクト指向で表現しようとすると大変。

■ 9章の補足:制約 (P.58)
  • 概念を掘り出すためには、なんでもString型でいいじゃん、という考えではできない。
  • 制約のなさに気持ち悪さを感じよう。

■ 9章の補足:「プロセス」 (P.59)
  • 構造はオブジェクトとして表現できるが、プロセスはオブジェクト指向で表現しにくい。
  • プロセスを表現する武器として、イベントストリームやリアクティブは非常に役立つ。
  • ただ最近の流行りとして受け止めるのではなく、ドメインとして認識する。

■ 9章の補足:「仕様」 (P.60)
  • オブジェクト指向では、やめたほうがいい・・・

■ 10章 しなやかな設計 (P.61)
  • この章を10章として独立させてるのは、開発者がドメイン層に集中するためには、こーゆう設計にしておけば楽になるよ、実験がやりやすくなるよ、というメッセージ。
  • メソッドの引数とかはValueオブジェクトにするのが望ましい。型として表現する。intとかだと、ドメインの関心事が表現できない。
  • Valueオブジェクトは5章に出てくるが、10章の実践ネタとしても非常に有効。

■ その他のテクニック (p.64)
  • 「制約」は表明を使ってコードとして表現すればソフトウェアが安定して、実験がやりやすくなる。
  • コードにどんどん制約を埋め込む。

■ 攻める角度 (P.65)
  • 「しなやかな設計」と「概念の掘り出し」は、同じ箇所に両方ないといけない。

■ 第10章のまとめ (P.66)
  • ポイントは2つ。
  • 1.技術者が「利用する人たちの関心事」に集中すための工夫
  • 2.「しやなか」なほど、実験がやりやすい
  • 10章は技術的なことなので、チームでまずここからやってもいいかも。

■ 第11章 分析パターンを適用する (P.67)
  • 11章は、語りたいことが山ほどある。
  • 今日は語り尽くせないので、DDDAllianceの別イベントでやろうと思っている。

■ 第12章 デザインパターンをモデルに関係づける (P.70)
  • デザインパターンは技術的な観点で説明されている。なのでドメインに直接役立つものが多くない。 by エリック・エヴァンス
  • ドメイン層の設計でデザインパターンを取り込むなら、ドメインの言葉でそのパターンがどういう意味を持つのか、チームで話し合って、意味があったら使おう、とするのがよい。

■ 第13章 より深い洞察に向かうリファクタリング (P.71)
  • ブレイクスルーの瞬間は大発見だし、すっきり感がある。だからといってすぐにコードを変更しよう、というのは危険。

■ リファクタリングの方向とタイミングを間違えないために (P.73)
  • どこまでリファクタリングするんだ、いつやるんだ、という方向を間違えないように。
  • ひとりでやるのでなく、選抜チームで取り組もう。
  • 偏った方向に行くのを防ごう。
  • ドメインエキスパートがピンとこないような「深いモデル」、というのはありえない。それはブレークスルーではない。
  • ドメインエキスパートから最悪、ほとんど話をきけなくても、自分たちの考えたことがドメインエキスパートの考えから突拍子なことになってないか、だけは絶対にチェックしろ。
  • ドメインエキスパートからのフィードバックは大切にしなさい。
  • いつでも会話できる、ということよりも、そちらのほうが大事。

■ 第3部まとめ (P.75)
  • 9章を地道にやり続けること。これがDDDのメッセージ。
  • 第2部だけではダメで、第3部の内容を実践してこそ、ブレークスルーとか起こる。


★感想:
自分で本を読んでいたときは、今読んでる章に特化して視野が狭くなってしまいがちです。
でも、こーゆう風に全体を俯瞰して説明してもらえると、「あぁ、あの話は全体のここに位置していて、あの話と繋がるのか」といったような気付きが非常に多い。
自分の考えが整理されて一歩進む感じですね。これがまさしく、8章のブレークするーなのかも。
第3週のイベントも楽しみです。

増田さん、関係者の皆様、ありがとーございました。

スポンサーサイト

「XP祭り2015 “俺も!!”」に参加しました

2015/9/12(土) 「XP祭り2015 “俺も!!”」に参加してきました。

公式サイト
http://xpjug.com/xp2015/

こくちーず
http://kokucheese.com/event/index/324682/

Togetter
http://togetter.com/li/872910

場所は早稲田大学 西早稲田キャンパスです。
参加者は200人弱くらいでしょうか。
今年で私、初参加から4年連続の参加になります。過去に書いたブログはこちら。


というわけで私にとって、毎年恒例の楽しみなイベントになりつつあります。

今年も会場に着くと、協賛の出版各社様からの献本がズラリ。
20150912_xujug1.jpg
毎年、最後のクロージングで参加者にプレゼントされるので、楽しみの1つなのです。

この日、私が参加したセッションは以下のとおり。


今回は講演系ばかりの選択になりました。でも、ワークショップの方も魅力的だったので、両方とも参加したかったなぁ・・・


ということで、自分の復習も兼ねてブログにメモを書くのである。


A-1 オープニング (Agile仙人) – 10:00~10:30
毎年恒例、オープニングを務めるのはAgile仙人お二人による漫才。
このセッションはゆる~く、メモとかは取らずにのんびり楽しみます。
今年は、これまでのXP祭りを振り返る、という内容でした。
私がXP祭りに参加するようになったのはここ4年くらいですが、XP祭りはもう15年くらいの歴史になるようで・・・
でも、長いようであっという間だったのかもしれません。


A-3 XP lives, XP dies, XP lives again!! (角征典さん) – 10:30~11:30
XP matsuri 2015 keynote from Masanori Kado


素晴らしい講演でした。大事なことはスライドに書いてあるので、口頭説明の部分のみ、メモ。

■ XP lives (past) (P.2)
  • XP白本の第2版が出た2004年くらいまでは、XPは生きていた。2008年まではXPは辛うじて生きていた。
  • でも、この後の時期くらいからXPは死んでるんじゃないか。

■ XP dies ... and Scrum lives (P.4)
  • XPがなんで死んだか?原因は無い。ただ、Scrumが台頭してきた。
  • XPの分かりにくかった部分をシンプルに書いて、フレームワーク化したのがスクラムガイドだった。

■ Scrum lives ... (P.5)
  • 認定スクラムマスター(CSM)の取得者が2006年で30000人だったのが、2年くらい経って2009年に60000人と倍になった。
  • この時期がXPが死んだ時期と重なっている。
  • スクラムガイドの著者が「CSMは金儲けの道具ではない」と主張したら、自分が作ったScrum Allianceから、自分もスクラムガイドもscrum.orgに追い出された・・・

■ Agile is Dead (P.8)
  • 書籍「達人プログラマー」で有名なデイブ・トーマスが、アジャイルカンファレンスに向かうバスの中で、二人のアジャイルコンサルタントの会話を聞いて激怒した。
  • そのイベントの基調講演のタイトルを急遽「Agile is Dead」に変更し、帰ってからも怒り心頭でブログを書いた。
  • http://www.infoq.com/jp/news/2014/11/pragmatic-dave-agility

■ GROWS (P.12)
■ デイブ様からのご提案 (P.15~P.22)
  • これらの提案はNo!
  • なぜなら、「一方的に与えるモデル」ではダメだから。自分で掴んでいくモデルじゃないといけない。

■ プリクエル (P.31)
  • (「プリクエル」という単語の意味を知らなかったのでググってみたら、「文学・映画作品などの)前編」とあった。)
  • アジャイルの歴史、つまり以前に何があったかのを知らないと、理解が進まない。

■ Q.「アジャイル」を提案したのは誰?
  • 角さんからの質問に対し、聴講者の1人「マイク・ビードル」 ⇒ 角さん「No」
  • A.「マーティン・ファウラー」です。なぜなら、「アジャイル」の発音がイギリス式だから。
  • アメリカ英語だと「アジル」。最初、みんなが「アジャイル」と発音できるか不安だった。
  • 「アジャイルマニフェストの歴史」のページにちゃんとそう書いてある。(まこぴも読んでみたら第2節に書いてあった!)

■ ぶりきじゃ( Martin Fowler's Blikiの日本語翻訳サイト)
■ Conversational (対話) (P.39~)
  • マーティン・ファウラー 「Conversational が最近のアジャイルでは失われているのが嫌だ」
  • Conversational がなぜ大事なのか、XP白本には書いてない。
  • ケント・ベックのうまく表現できないことを、マーチン・ファウラーがいつもうまく表現してくれる。
  • マーティン・ファウラーは、まとめ職人としてすごい。
  • 有名な「トヨタウェイ」も、マーチン・ファウラーのまとめとほぼ一緒だった。凄い。

■ 科学的管理法
  • XP白本の18章に「テイラー」が出てくる。
  • 科学的管理法により、人間性が失われていった。科学的管理法は人間を歯車的な使い方をする。
  • 生産性を上げようと考える人を立てて、それ以外の人が何も考えずに働く。
  • ただ、人は怠ける可能性があるので、後工程で品質をチェックする人を配置する。
  • このような管理が、科学的管理法である。でも、我々はモノではない。

■ モノの証明(認定) (P.54)
  • XP白本の21章に「認定とか認証は良くない。金儲けしてるだけだ。」と書かれている。
  • XPは、認定とかは作らない。「XP dies」、XPは死んだ、と言われても、認定を作っていない。
  • (認定を行っているScrumとの対比)

■ バートランド・ラッセル
  • 数学者はお爺さんになると、哲学者になるw
  • ラッセルの言っている「個人の独創性」と「社会的結合」の組み合わせる話と、XPは同じことをやろうとしている。
  • クリエイティブなことも必要だし、一緒に働かないといけない。
  • ラッセルの言いたいことが1章冒頭の一文「XPはソーシャルチェンジである」と、簡潔に表現しているw

■ 新しいソーシャルチェンジ (P.59)
  • 誰とでも上手くいくわけではないので、まず最初にTeam Geekを読んでもらう。
  • Team Geakには、個性が強い人たちをどうチームとしてまとめるかの話が書いてある。

■ 三本柱(HRT) (P.60)
  • まず「HRTの文化」を作る。HRTは好き嫌いに関わらず、まず最低限は守ってもらうようにする。
  • (ちなみに私、Team Geekに関する角さんの以前の講演でこの絵を見せられて、HRTと聞くといつもコレ思い出す・・・)

(「北斗の拳」のハート様)


■シンプリシティ (P.68)
  • こんまり先生は、片付けの先生として有名。
人生がときめく片づけの魔法
近藤麻理恵
サンマーク出版
売り上げランキング: 153


■ こんまり流片付け術 (P.71)
  • 「捨てるモノ」ではなく「残すモノ」を選ぶ。
  • それまでは断捨離が流行っていた。ものを捨てていくと生活が荒んでいく実感があった。なので方針転換した。
  • こんまり先生いわく、「それはときめくか?」
  • 方法論としては革新的だった。それは、教えることができないから。
  • ときめきは個人的。教えるものではない。最強のツール。

■ なんか聞いたことがある! (P.73)
  • クリストファー・アレグザンダーは、デザインの美しさとか心地よさとかをデザインに反映しようと考えていた人。
  • 結局はこんまり先生と同じことを言っている。

■ ときめく♥プラクティスを選ぶ (P.78~)
  • XP白本の23章「時を超えたプログラミングの道」は、ときめきの道なんだ。
  • XPをやる時は、ときめく必要がある。ときめくプラクティスを選ぶんだ。
  • XPは「価値」とか言ってるけど、そんなの届けた後にしかわからないじゃないか。
  • 「無駄」とか「価値」じゃなくて、「ときめき」なんだ。
  • ときめき駆動開発。TDD!

■ XPが目指している(いた?)もの (P.82)
  • このグラフは、時間が進むにつれて変更工数は指数的にに増えることを表してる。
  • 時間が経っても変更コストは一定にできる、という下側のグラフがXP白本の第2版にあった。

■ できることを増やすプラクティス (P.83~)
  • ケント・ベックが本に書いたこの例について、マーティン・ファウラーがまとめ職人として上手く表現している。
  • 変更工数推移のグラフを平らにするにはこの3つをやってればいいんだ。
  1. テスト(自動テスト)
  2. 継続的インテグレーション
  3. リファクタリング

■ バリー・ベームからの反論 (P.85)
  • いや、それだけでもダメ。小さいプロジェクトならいけるかもだけど、大規模プロジェクトだとダメ。

■ アーキテクティングは前もって行う必要があるのか? (P.86)
  • 良い設計と悪い設計があって、ちゃんと設計してないと時間が経つについれて機能追加する速度が落ちていく。
  • スタミナ仮説のグラフで、「No Design」と「Good Design」の線の交差点よりも期間が短いPJは設計しなくてもいいかもだけど、そうじゃないなら設計しましょう。
  • そうしないと、技術的負債に落ちていく。
  • 交差点までの期間は、数週間くらい。

■ 技術的負債の四象限 (P.90)
  • マーティン・ファウラーが提唱している。(ぶりきじゃ: http://bliki-ja.github.io/TechnicalDebtQuadrant/
  • 4象限の左半分は無鉄砲で救いようが無いので、捨てても大丈夫w
  • 考えないといけないのは4象限の右下。容易周到にやってるのに不注意。ここをどうするかがソフトウェア開発の関心事。
  • XP白本の14章で扱っている。
  • 経験をベースにした設計が大事。熟考でも、早すぎてもダメ。経験してから設計する。

■ 「経験」してから設計する (P.92)
  • セットベース開発が現実的。
  • 複数案を実装してそこから選ぶとあるが、ブランチ1個で開発したりとか、現実ではやられていない。
  • でも、やってみたらいいんじゃないかな。

■ 可逆性を確保せよ (P.93)
■ モブプログラミング (P.116)
  • モニターとキーボードは1つ。ドライバー1人に対して、他の人はみんながナビゲーターとして見ている。
  • ただ、WIP制限が1なので効率的じゃないよ、とKanban in ACTIONが書いてるけど・・・・

■ ラズベリージャムの法則 (P.132)
  • 「広げれば広げるほど薄くなる」という法則。
  • いろんな人に伝わった結果、よくわからないものが広まっている。それを飲み込むのじゃなく、自分で考えることが大事。

■ イチゴジャムの法則 (P.133)
  • 「粒があれば、どこまでも薄くはならない」という法則。
  • ここで言う「粒」は、人間性と適応性。


■ 昼休み (11:30~13:00)
お昼休みは1時間半と長く、外に出て食事するには十分です。ですが私は・・・


あと、昼休みに出版社さん提供の書籍を手にとって読んでみたり、配布資料に目を通したり、知り合いのスタッフさんと会話したり。
先週買った角さん翻訳の白本をまだ読みきってなかったので、それを読んだり。

そんなこんなで、今年もゲリラLT(野良LT)が始まります。


野良LTお馴染み @take3000 さん、今年はクラスメソッドでの採用活動がLTのテーマでした。
他にもLT司会進行役の侍レッドさんのXP祭り音頭(?)の生演奏があったり。
重音楽戦士特攻隊長の戯言(公開版)~XP祭り2015~ from Samurai Red

今年は聴衆も多くて盛況。のんびり楽しいヒトトキを過ごしました。


A-4 “俺も” XP入門 (木下史彦さん) – 13:00〜13:45
俺も エクストリームプログラミング入門 from Fumihiko Kinoshita


アジャイルで名高い永和システムマネジメントの、アジャイル事業部の事業部長をされているとのこと。
事業部長というと年寄りのイメージがありますが、木下さんはとても若く見えました。何歳なんだろう・・・

■ XPシリーズの書籍
  • ピンクの「導入編」: 具体的なやりかたが書いてある。白本は書いてない。
  • 黄色の「アドベンチャー」編: ピンクのと同様、具体的な進め方が書いてある。
  • 緑の「実行計画」編: 計画づくりのフォーカスしている。
  • 紫の「適用」編: XPを実践した人のコラムがある。
  • オレンジの「実践」編と赤の「ウェブ開発」編: 1つのプロジェクトにフォーカスして説明している。
  • 黒の懐疑編: XPを批判的な視点で解説している
  • 全部絶版なので書店で買えないAmazonで中古が売っていて、8刷全部買っても、合計111円!

■ XPとは
  1. 恐れに対処する
  2. 変更コスト曲線を平らにする

上記をテーマに、書籍で紹介されていることをベースにした解説でした。
私、白本しか読んだこと無い(しかもまだ半分くらい)なので、白本以外の書籍に関する情報はとてもありがたかったです。


A-5 アジャイルとアンラーニング (渋川よしきさん) – 14:00〜14:45
アンラーニング from Yoshiki Shibukawa


角さんと木下さんのスライドが約130枚なのに対し、渋川さんのスライドは全部で20枚!
社内SEとしての取り組みについて、XPを交えてシンプルに纏めらています。

「社内専用のライブラリやフレームワークは誰も使いたがらない。自分のキャリアに役立たないので。」という言葉は刺さりますね・・・
私も自社で技術開発支援的な部門にいるのですが、この辺はきちんと意識してツール開発とか支援をする必要があると思います。

あと、「アンラーニング」という言葉。既存のやり方を捨てて、新しいやりかたを学ぶ。
この辺は、天野さんのLTのテーマだった「老害」にも少し関連しそうだな、と思いました。
新しいフィードバックを得て、自分で経験をして、やりかたを変えていくの大事。


■ C-6 ユーザーストーリーマッピング入門 Agile2015版 (川口恭伸さん) – 15:00~15:45
(スライドが公開されたらココに貼る)



2009年のアジャイルカンファレンスでJeff Patton に合って感銘を受けたのが、以下の本の翻訳にも繋がったそうです
ユーザーストーリーマッピング
Jeff Patton
オライリージャパン
売り上げランキング: 98,666


セッションでは、ユーザーストーリーマッピングのポイントや利点などを紹介されてました。
あと、セッションの中で協調ワークショップについて紹介されてました。
ステークホルダーとか予算出す人を入れて、共通理解を作っていく話や、現在ユーザはどういう問題をかかえていて、どういうところを辛いと思っているか、をワークショップで明らかにするという話がありました。
事前に調査をやっておき、知っている人がいる状態でやることがポイントだそうな。

スライドがまだ公開されてないので、纏めは後で追記予定。


C-7 ユーザーストーリー ネクストジェネレーション (懸田剛さん) – 16:00〜17:00

(スライドが公開されたらココに貼る)

ユーザーストーリの話に始まって、会話の重要性、テンプレートゾンビ、ゴールデンサークル、デザイン思考、NVC、M♡P、狩野モデル、Happy Startuup Cambus、沢田マンション、輝ける大地、etc・・・

非常に多岐に渡る壮大な講演でした。結論的なものはたぶんこれに集約される、でいいのだろうか・・・w





・・・スライドが公開されたらメモを起こす予定。


A-8 LT祭り – 17:15~18:30

毎年恒例、XP祭りの最後を飾るのはLT大会。今年もレベルの高いLTが繰り広げられました。
20150912_xujug2.jpg

LT大会の打順。


現時点で公開されているスライドを貼っておく。

エンドツーエンドテストを自動化したらチームがすごく良くなった@XPまつり2015LT from Taichi Watanabe




俺も!「老害」 公開版 from ESM SEC


"総務も!!"アジャイルプラクティス! from pupupopo88


Xpとシステム思考のシナジー 「8の字を見つけよう」 from Ieda Ryo


いやー、今年のLTも大変楽しめました。


★感想:
純粋に楽しかったし、気づきも多く得られたし、来年もまた行きたいな~と思うのでした。

奮闘してくださる当日スタッフさんが講演をほとんど聞けないのはなんか申し訳ないので、Ustremeの録画&配信とか来年からやってみるといいんじゃないかな~と思うのでした。
そうするとスタッフさんも、後でUstと公開済スライドを見ながら、講演を聞けるようになるので。
同時セッション数も多いので、参加者も自分が参加できなかった裏番組を後で聞けたりする恩恵もあるでしょうし。
もちろんUst配信はそれなりに大変だと思うのですが・・・

登壇者さん、運営のスタッフさん、会場提供の早稲田さん、関係者の皆様ありがとーございました。

FC2Ad