JSUG Spring in Summer 〜 夏なのにSpring に参加してきました

　今週は久々に平日2回目の勉強会参加となりました（夏休み2発目で、平日休めたので）
　
　お題の通り初参加（？）のJSUGになります。正直最近Javaから離れてるので
リハビリの為に色々話を聞きたいな、という若干残念な動機ですが(^^;;

　さて、場所は東京駅すぐ隣の東京八重洲 グラントウキョウサウスタワー、
前回来たのはAgileSamuraiBaseCampのお手伝いの時なので、今回2回目となります。
（ココのエレベータの23階まで上がるヤツが壁がガラス張りで上昇スピードも
早くて、若干ゾクッとくる感じなんだなー）

　さて、プログラム（タイムテーブル）は下記の通りでしたが、

http://www.springframework.jp/summer/timetable

自分は、R1-1.オープニングセッション、R1-2.MSAの設計、
で、ホントはR2-3に参加したかったけど、トイレで並んでたら
休み時間終わってて戻った頃には既に始まってたから途中参加は諦めて
ココで早めの昼食。41Fの休憩室からぼんやりと新宿の方を眺めながら
日本で一番売り上げが上がっているとかいう33Fのセブンイレブンで買った
おにぎりなどを食べて午後に備えました。
で、折角なんでR1-4.超高速開発ツールWagbyの技術基盤 の話を聞いて
R1-5.キーノート The Macro of Microservices、
R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に？
R1-7.The Bootiful Application
R1-8. 【前半】 Spring Framework/Boot/Data徹底活用〜Sprnig Data Redis編〜
【後半】 Spring適用のアンチパターンとベストプラクティス（仮）
R1-9.The Bootiful Microservice
てな感じで、午後からは結局Room1の一角に陣取ってずっと最後までそこにいた感じでした。

　と、長い前フリはこれ位にして内容を書こうかと思うのですが、
全部書くとなると相当長くなるので、個人的に一番興味があり、面白かった
R1-2.の鈴木雄介さんのセッションの内容についてメモ書きを。

　⇒　既に資料もアップして下さってるので、それと合わせながらなら
　　　少しくらいは内容（ライブ感）が伝わるかな、と。

講演資料は http://www.slideshare.net/yusuke/jug2015 に。

（以下、「⇒」の部分は僕の私見等です）

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

【マイクロサービスアーキテクチャ（MSA）の設計】

P.3（Agenda)
・MSAは去年位から流行り出した言葉だが、今年も広がっていくと予想している。

P.5（MSAとは？）
・MSAという言葉自体はファウラーのブログに紹介されたのがキッカケでブレイクした。
　⇒　http://martinfowler.com/articles/microservices.html のことではないかな、と。

P.6（MSAの２つの側面）
・MSAには9つの特徴があるが、大きく「技術面」「文化面（姿勢・態度等）」の2つに分類できると考えている。

P.7（MSAの技術面）
・これまで「開発」では「コンパイルが通った（ソフト・機能を作る）」という事が、ある意味ゴールになっていた。
　それと比較して「サービス」は「機能を提供し続ける」ことである。
　「機能」は成功しているが、「サービス」では失敗している、ということもある。例えば
　遅すぎて使えない、等の場合である
・「機能」＝「ファンクション、フィーチャー」、「サービス」＝「○○ビリティ（非機能っぽい考え方）」
　言い換えると「機能を提供し続ける為の考え方」とも言える。
　そして、サービス自体がその裏側のサービスによって構成されているというのがMSAの考え方である
・昔はシステムを止めてデプロイ、という手段が取れたが、最近では「稼動しているシステム
　（サービス）に対して」（そのサービスを動かしたまま）システムを追加していく、という状況になっている。
・システム開発が「静的なもの」から「動的なもの」へ移り変わってきている。
　言い換えると単純にシステム同士を繋ぐ、という考え方から「動いているサービスを（動かしながら）
　協調動作させる」という考え方に変わってきた。
・そこで重要になってくるのが、協調動作させる為のメッセージ・ルール、いわゆるプロトコルである。
・また、それらのサービスをどうやってマネージするかも重要。今までと違い、「Aというサービスは
　○○という機能を提供してるので自由に使って下さい」というスタンスになるので、Aというサービスは
　自分自身に対しては責任を持てるが、（外部アクセス等に対しての）リソースのコントロール等は難しい
・だから、（サービスをマネージしていく為には）サービスを継続的に稼動監視・障害検知していく事が重要になってくる。
　また、Aサービスが勝手にVerUpしてしまうと、利用者がついていけなくなってしまうので、如何に
　過去のサービスのインタフェースを維持しながら新しいサービスを提供するか、も工夫がいる

P.8（MSAの文化面）
・「開発」から「サービス運営」への考え方のシフト。
　単に機能を提供すればよい、では無く「サービスを運営していく」ことが興味の関心事となってきた。
・「ドメイン毎の自主性を認め、標準化を否定する」。つまりドメインに応じた考え方を取る、ということ。
　ファウラーも「標準フレームワークは必要ない」という事を書いている。
　⇒　固有のドメイン（例えば会計システムと在庫管理システムとECサイト）では、それぞれ必要とされる、
　　　適した技術が違うのが当然であり、それぞれ（のドメイン）にあった技術を用いればよい、ということ。
　　　そして、それを上手く連携させていくかがキモだ、という風に理解しました。

P.9（MSAの背景）
・良くAmazonの仕組みが例として出される。いまやそこらのエンタープライズよりも巨大で複雑な
　ウェブサービスになっている。
・物流は（倉庫があるので）あまり変化しない（できない）が、フロントは顧客に合わせて変化する。
　なので、それぞれ個別にサービスを再構築していく必要がある。
　それが必然的にMSAに向かわせた。
　⇒　向かった結果、MSAになったという風にも言えるかな、と。

P.10（MSAの背景）
・クラウドや仮想化技術もAmazonが（彼ら自身が必要とした結果）、作り出したサービスである。
　コードでサービスが管理できるということも大きな変化である
　⇒　仮想化技術を利用して、かつChefやAnsibleとかでサーバ・インフラを準備するということかな、と。
・APIの組み合わせによる動作構成パターン（例えばクラウドパターンとか）の代表例がパブリッククラウドサービス。

P.11（MSAとは）
・結局MSAは理想論（理論）としての結果ではなく、現実解として出てきた結果である。
　⇒　デザインパターンの成り立ちとも共通するところがあるなー、と。
・ただ、言葉になったことによって、（過去に「アジャイル」がそうであったように）理想論的になりつつあるので
　皆さんはそれに流されないようにして欲しい。
　
P.13（MSAを理解する）
・（鈴木さん的理解では）MSAは技術論というよりも技術管理論である。
　「MSAという優れた技術があって、それを使えば皆ハッピーになる」、ということではない。
　
P.14 （MSAを理解する）
・「マイクロ」ということに惑わされず（＝粒度ではなく）、「関係性」に注目するのが大切。
　要は「複雑化してしまっているものをどうやって管理するんだ」ということ。
　
P.15（SOAとMSA）
・SOAは理想（こうあるべき）。
　MSAは現実解（結果、こうなった。部分最適の結果）。ある種の諦め、割り切りともいえる。

P.16（システム統治としてのMSA）
・MSAへの流れを政治の流れと重ねると面白い。（各個別のシステムの）乱立〜SOA〜MSAの流れ。
　SOAを成功させるためには企業全体を見渡して全体最適化が出来る人が必要。そういう人がいて、
　尚且つ安定したビジネス領域であれば上手くいく。
　そうでない場合、そういうアーキテクトがいない、もしくはビジネスが激しく変化するという場合では
　中々上手く行かない。そこで出てきたのがMSA。
　ただし、「有識な市民」がそれぞれの場所に必要。

P.17（MSAの適用）
・単純にMSAの方がSOAよりも良い、というわけではない。それはアジャイルと同じ。
・また、「ウチのシステムはExc●lで動いているんだ」とか「APIアクセスには申請が必要」とか
　「協調していく」という姿勢じゃないシステム・人に囲まれてしまうと上手く行かない。

P.18（MSAと開発プロセス）
・昔は技術の方に柔軟性が無かった分、イテレーションに分割して開発するなどのプロセスに
　柔軟性を持たせて対応してきた（＝都度考え直す事で、誤った選択をできるだけ避けるように工夫してきた） 。
・大きな全体を作っていく場合に、部分から作っていかざるを得ない（から、イテレーションで細かく区切って作っていこう）
　という考え方がアジャイルのアプローチだった。
・MSAではそれにプラスして、技術的に判断を遅らせる事が可能になったのでWFのアプローチも取れるようになってきた。
　例えばキャパシティプランニングは昔は悩ましい事の一つだったが、今なら悩まなくて済むような技術的
　選択肢を選べるようになってきた。
　⇒　AWSとかのクラウド、仮想化技術、ですね。
・厳密にアジャイルをやろうとすると、結構大変。むしろWFよりも堅苦しくなったりする。
　予想可能な領域や、（変化しにくい・させにくい）他システムとの連携部分であったり、マスタ関連の話は
　むしろWFの方が適している（合理的）。
　⇒　禿同ってヤツですね。個人的にアジャイルの方向性・考え方は好きだけど、「アジャイルだったら何で出来る」
　　　なんてのは、贔屓の引き倒しになるんじゃなかろうか、と。
・この10年くらいで技術面と文化面が相互に影響しあいながら出てきた結果がMSAと考えると良い。

P.20-21（MSAのデザイン）
・（省略）

P.22（ドメインの発見）
・DDDの罪と言えば罪になってしまうが、「ドメインというものがある」という前提で始めてはダメで、
　色々探した結果「ドメインを発見する」という結果形と考える方が良い。
　ドメインがあるからそれに従って管理していきましょう、というのは間違い。
　⇒　↑でも出ましたが、デザパタ的な考え方なのかな、と。
・ドメインの境界を探すということについて、例えば車を例にしてみる。
　「タイヤ」は（地面と車の境界だが、取替えのきく）「ゴム」で出来ている。何故なら
　（走れば走るほど）削られていく為である。昔の馬車などは
　木で車輪と車軸が一体で作られていた為、交換しようとしたら丸ごと交換する必要があった。
　言い換えると「変化の境界」をそこに見出し、（取替えのしやすい）適したアーキテクチャを適用したと言う事。
・とは言うものの、（システム開発における）変化の境界というのは大体の場合、不明確。
　ただ、一度線を引いたらそれがずっと続く（維持する圧力が内外からかかってしまう）

P.23-24（品質特性）
・（省略）

P.25-26（プラットフォームの利用）
・プラットフォームは動的な資産をどうやって管理していくか、ということ。
　プラットフォームは広ければ広いほど有効。
・（プラットフォームの範囲については資料参照）
　結局AWSの提供しているサービスの事。良く練られている。
　
P.27（ドメインとプラットフォーム）
・ただ、あまりにもプラットフォームで引き取りすぎるとドメイン自体のコードは減るかもしれないが
　逆にドメインの独自性がどんどん無くなっていく。
　結局その辺りのバランスが重要。
・ドメインの固有性・独立性をドコまで保障するか、みたいな点で今後のアーキテクトは悩む事になるだろう

P.29（MSAの実例）
・MSAの例として分かりやすいのはECサイト。例えばとある企業が既存システムにECサイトを追加しよう、
　みたいな話を想像してもらうと良いかもしれない。

P.30（ECサイトのドメイン設計）
・買わせるための属性（例えばどうやって商品検索するか）と売るための属性（クレジットカード情報の
　入力とか、住所入力とか）は違う。

P.31（サービス配置例）
P.32-33（ECサイトの構成）
・サービスの配置パターンは大体似てくる。また、MSAの事例としても分かりやすい。
・サービスごとに開発アプローチや技術もそれぞれのサービス・ドメインに適した形のものがある。
　それらを分割・統治するというのがMSAの考え方。

P.34（実例から実践へ）
・「正解は無い」。結果的に「MSAになった」というほうがよい。
　いいデザインをしたら結果的にMSAになるし、いいプロセスを選択していけば
　「結果的に」アジャイルになったというのと一緒で、手段を目的化しないように。

P.36（Springについて）
・ブームになってるけど、Spring Bootだけではない。

P.37〜（まとめ）
・「良識のある市民」の存在も非常に重要。いない場合、いる場所（システム）に寄せる、といったような
　対応も必要かも。
・「MSAにする」ではなく「MSAになる」のが健全。
　単にGoogleがやってるからその方法を真似したら上手く行く、というわけではない。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

開発者ギルドカンファレンスに参加しました

　夏休みの一発目取得ということで、久々に平日休んで赤坂で開催された
開発者ギルドカンファレンスに参加してきました。

　もう既に中の人のブログとかTogetterも上がってますね。

「越境から越共へ！開発者カンファレンス2015」
http://bit.ly/1eq9sYs

「開発者ギルドカンファレンスまとめ - Togetterまとめ」
http://bit.ly/1OtOSmc

　さて、当日は久々の平日休みということでちょっと早めに会場に行って
会場周りの赤坂をちょろっと歩き回ったりしましたが、あまりお腹が
減ってなかった事もあって、ちょっとイイ昼ごはんを食べるわけでもなく
結局いつも通りのコンビニおにぎり。。。orz

　ヒンソーな昼ごはんは置いといて、ちょっと会場に早めに到着。
最近勉強会関連から離れてた事もあって、コソッと着席。
会場はほぼ男性で60名超？（中の人のブログでは70名程度ということでした）

　増田さんのDDDを絡めた講演を皮切りに、前川さん、水谷さん、佐々木さん、
中村さん、そして市谷さんと17:00までこの1年、色々あって
勉強会界隈に顔を出せなくなってしまった間に色んな事があったんだなーと
シミジミしておりました。

　⇒　1年で30案件をこなす、という件に関してどういう工夫で
　　　進めていったのか、という話をもう少し突っ込んで聞きたかった気がしますが
　　　あのメンバー集まってたら、いけるかなー、というのが
　　　感想になってしまいそうですね。

　　　やっぱりIT業界は「人」に依存するところが大きいと改めて感じました。

　（後、ちょこちょこと感想書きたいけど、ちょっと今は書けないこともあるんで
　　ま、おいおい）

第十三回 アジャイルサムライ読書会 埼玉道場に参加してきました（TD

　最近、仕事でもプライベートの方でも色々忙しく、勉強会にも月イチがせいぜいな
感じで参加するのがやっとという感じで、ブログもサッパリ更新できず、、、悶々と・・・
長くなるので（略）

　さて、お題の通りアジャイルサムライ読書会（埼玉道場）に参加してきました。

（「ざっくり」とまとめたつもりが、、、エラく長くなってもた。。。orz）

「第十三回 アジャイルサムライ読書会」
http://bit.ly/1BGPIVm

今回はTDDの章という事もあり、ゲストは t_wada さんでした。
⇒　どうやら第1回目のジョナサンがゲストに来てくれた時以来の大入りで、
　　15名の方々の参加がありました。

　流れは例の如く、今回は14章のテスト駆動開発の章を音読し、
チーム内で出た疑問をふせんにまとめ、それを全体でドット投票して
ネタを厳選して議論するという流れでした。ちなみに今回は
A卓、B卓、C卓の3卓に別れ、各テーブル5名ずつで進める事になりました。

　で、以下簡単にメモからの抜粋を。

【チーム内で出た話】
「お題：不慣れな言語でTDDを始める時はどうすればいい？」
　⇒　・RubyならRuby、JavaならJavaで書き方にクセやセオリーがあるので
　　　　良いお手本になるようなソース（例えばOSSとか）を読んだら良いと思う。
　　　・いきなりTDDを始めようとすると（本にもある通り、TDDは色々な技術の
　　　　集大成的なところがあるので）ハードルが上がるので、まずは
　　　　デバッグ的に始めてみるのはどうだろう。

【全体で議論した話】
「お題：TDDを習慣化させるコツは？」
「お題：ユニットテストを書く時や書かないときのムラを無くす為には？（メンタル的・技術的に）」
「お題：テストコードを書かない職場の雰囲気を変えるには？」

　⇒　参加者の皆さんから幾つかの回答が出ました。
　　　・TDDが始まった時のキッカケは、お金に直結する部分でバグが出て
　　　　大騒ぎになったから。
　　　・設計が整理できて、コードを書く時間がトータルで見ると減った。
　　　・リファクタリングが躊躇無くできるようになった。
　　　・全部に対してテストコードを書こうとしない。
　　　・テストファーストにこだわらない。
　　　・2人目の自分を作る
　　　・デプロイメントパイプラインを作ってテストコードを書かないと
　　　　コミットできないような仕組みを作る。
　　　
　t_wadaさんのまとめ
　　⇒　ざっくりまとめると、「1．TDDを導入するまで（キッカケ）」と
　　　　「2．TDDを導入した後の継続」の2つのフェーズに分かれる。
　　　　
　　　　1．については参加者からも話があったが、
　　　　某Coo●●ad社も以前はテストコードがゼロだったが、一度
　　　　お金に関わる部分でバグを出し、それから書くようになった。そういう
　　　　「痛い目に遭って」改善されるというパターンがある。
　　　　
　　　　2．については、リファクタリングのタイミングが分かりやすくなる
　　　　というメリットが継続のモチベーションに繋がる場合がある。
　　　　また、2人目を作るのは重要。その時は「TDD」ということだけではなく
　　　　「変化」に対して共感できる人を募るのが重要。
　　　　
　　　　技術についてはペアプロが一番伝達しやすいのでは。
　　　　ただ、2割位の人は「ペアプロ」が出来ない、という研究結果もあるので
　　　　要注意。（強制はダメ）。
　　　　そもそもペアプロはスゴク疲れるので、例えば新規機能の実装時のみ、
　　　　月曜はペアプロの日、バグが出た時にその改修だけ、という具合に
　　　　実施するポイントを決めるというのが良いかも。
　　　　
　　　　それと（TDDを伝える場合）相手にとって「刺さる」もので伝える事が大切。
　　　　「（品）質」を気にする人には「（品）質が上がる」であるとか、
　　　　「損得勘定で動く」人には「ペアプロがどれだけ得になるか」とか。
　　　　
　　　　後、エライ人に薦める場合、技術等が分かる人であれば話は通りやすいが
　　　　分からない人には論文からの引用データで説明するという手がある。
　　　　
　　　　で、ちょっと質問したのですが「ダマテン（エライ人には黙ってやる）での
　　　　実践は？」ということに関しては、
　　　　「基本的にはお奨めできない。けど、事例はたくさん聞く。
　　　　　その場合、徹底するのであればリポジトリにテストコードをコミットせずに
　　　　　完全ステルスでやったという話も聞いた」
　　　　参加者の方からは「分からないように、Frameworkのテストコードの中に混ぜた」なんて話も(^^;;
　　　　
　　　　また、t_wada さんから「質を下げれば納期が早まる」というような
　　　　「（品）質」と「納期」をシーソーにかけたような考え方が未だに
　　　　横行しているが、これは誤りである、という話もありました。
　　　　⇒　「質」を高める事で「結果的に（ソースの解析・作成・テストの）スピードが高まり」
　　　　　　納期も早まる、という考え方の方が正しい、と。
　
　で、ココで一旦休憩。
　
　続いて、
　「お題：本の中で「危ないところ」に対してテストする、というのがあったが、「危ない」というのは
　　　　　その人によって違うのでは？」
　「お題：全部が危ない場合のテストは？」
　「お題：危ないという事を決める人は？」
　「お題：全て（テストする）、と危ないところ（をテストする）の違いは？」
　「お題：危なっかしい、というところの見つけ方は？（特に自分の専門外の分野の場合）」
　
　というネタが議論の土台に上がりました。会場の時間の都合（と続く懇親会の時間の都合）の為
　「巻き」で進めたので、早速 t_wada さんのまとめ。
　
　　⇒　まず、前提として「危ない」という感覚は個人の主観に委ねられる所が大きく、定量化もしにくい
　　　（ので、昔から議論の対象になってきた）。
　　　　そのため、例えばチームで仕事をする場合、「一番リスクに敏感な人のレベルに合わせる」とか
　　　　「チームメンバの意見を平均化する」とかいうルールを決めて進めるのが良さそう。
　　　　
　　　　t_wada さん自身は例えば「カバレッジレポートと自分の感覚を突き合わせてそのズレを確かめる」
　　　　ということを継続していて、それによって「危ない」という「感覚」がどれ位確からしいかを
　　　　見ているそうです。
　　　　
　　　　自分の専門外の分野の場合、静的なコード解析結果なんかも利用して「危なそう」な所を
　　　　見つける工夫もされているそうです。（動的なテストを書ききれないような既存コードの場合も）
　　　　
　　　　要は「自分の感覚を磨き続けて、「危なさ」に対しての嗅覚を研ぎ澄ませておく」という事が
　　　　重要ということなんではないでしょうか。
　　　　
　　　　後、話の中で「原文では確か【break】という単語が使われていて「壊れやすいコード」という
　　　　意味である、という補足もありました。
　　　　
　　　　そこで、個人的には「危ない」という意味は腹落ちしていたんですが、「壊れる」という
　　　　意味がイマイチ理解できてなかったので、質問をぶつけてみました。
　　　　
　　　　
　　　　「危ない、というのは個人の感覚的なもので、割と腹落ちできたが、「壊れる」という
　　　　　事はどういうことでしょう？コードは（それが完璧な物かどうかはともかく）変更しなければ
　　　　　そのまま同じ結果を吐き出し続ける（＝良くはならないけど、壊れもせず変化しない）と思うんですが？」
　　　　
　　　　回答としては「確かに「コード自体」は壊れないが、【環境】は変化していく。その結果として
　　　　そのコードが正しくない答えを返してしまう。そういう場合に「壊れる」と表現しているのではないか」
　　　　ということでした。
　　　　「（そんなものが世の中に存在しているか、存在できるかは別として）もし100%完璧なコードと言う物が
　　　　　存在していたとして、そのコードと比較した場合に「壊れている＝正しい答えを返さない」コード」
　　　　　という意味で「壊れている」という意味でしょうか？」という追加質問したら「Yes」ということだったので
　　　　個人的には納得。
　　　　
　　　　
　　　　また、「たくさん書き換えられているコード（＝リビジョンがやたら上がっているクラスとか）」は
　　　　「危ない」と考える事も出来る、というお話もありました。
　　　　
　　　　結局、↑の通り、「危ない」という定義自体がフワッとしている分、周りで測れる（計測できる）モノがあれば
　　　　それを測って、定量化（客観化）していきましょう、という事でした。
　
　t_wada さんの悩み(ﾜﾗ
　
　　後、余談ですが、議論のネタ付箋の中に「テストコードを書いているけど、TDD出来ていない」というものがありましたが
　　最近良く「TDDできてないんですよ。。。」と申し訳無さそうに t_wada さんに話しかける人が多いとの事。
　　結論から言うと、「気にしなくていい！」という事でした。
　　
　　ある意味「TDD」という単語がキャズムを超えて一般化した単語になったという一例なのかもしれませんが、
　　ちょっと「宗教化」してきているようで、個人的には「。。。」という感じだそうです。
　　
　　⇒　それについては主催の inda_re さんからも意見があって、結局 本（アジャイルサムライ）の始めに書いてある
　　　　「大きな問題は小さくする」とか「ちゃんと動くソフトウェアを届ける」といった事を実現する為の
　　　　「やり方」の一つとして「TDD」に取り組むのは良いが、「TDDをやる事」が目的になるのはどうだろう、
　　　　という事でした。
　　
　　後、TDDには狭義のTDD（ボブ・マーティンが言ってるようなTDD）と広義のTDDがあるが、
　　狭義の意味では「TDDを始める時の養成ギプス」としてはいいかもしれないが、それに捉われすぎると
　　ついこの前の「TDD is Dead（http://bit.ly/1rcEdPB 日本語訳はやっとむさんが http://bit.ly/1rcEhij に）」とかいう話に
　　いってしまうのではないか、という事でした。
　　
　　結局「TDD」をやってない事に引け目を感じる事は無いし、逆に「TDD」やってるからバグは無くて完璧だ、
　　何て思い込みも危険だよ、というお話でした。
　　
　　最後に、 t_wada さんの補足として、「テストコードとプロダクトコードを書く時間的タイミングが近いこと」
　　というのが「TDD ができているか、いないか」の違いではないか、という事でした。何故かというと
　　テストコードがプロダクトコードに（良い）影響を与え、設計が改善されるからという事でした。
　　なので、テストコードを先に書くか、後に書くかはそれほど大きな問題ではなくて、
　　「テストコードを書くことでプロダクトコードが改善されていない＝TDDではない」ということになるかな、と。
　　
　　⇒　最後に inda_re さんから、参加していた常連の某氏にムチャ振りがあったんですが、その方が仰っていたのが
　　　　「（TDDに限らず、チームを変化させようとする場合）全員を相手にしない」という事です。
　　　　やはり、1人や2人は乗ってこない人がいるので、そういう人を納得させる為にエネルギーを使うより
　　　　↑に出ていたように2人目を作って（巻き込んで）、その他のメンバーに伝えていくのが良い、という事でした。
　
　ってなワケで、本編終了。
　
　続いて懇親会なんですが、電車的都合により、開始から1時間位で先に上がる事になったんですが、
　スペシャルゲストに某スクラムマスター登場（やっぱりか！ﾜﾗ）。
　
　残念ながらちょっとテーブルが離れてしまってたので、今回はあまり話せてなかったんですが、
　変わりに道場常連の方と某てら●でさんと話をして、今丁度悩んでいるC# でのテスト方法について
　いいヒントをもらう事が出来ました。
　⇒　ってか、丁度JJUGに応募したネタだったとか。とりあえず今回のPJTで試してみて
　　　何かFBかブログにまとめようかな、と。あ、そう言えばSessionStateServerで大ハマりしたこととか
　　　WinRMにヒドい目にあったこと、まとめてねぇな。。。
　
　そういや、今年のデブサミで t_wada さんに質問して、腹が括れて取り組んだ
　前プロジェクトの PL/SQL でのテストの件（※）とか結果だけでも報告したかったなぁ。。。
　
　⇒　結論から言うと、何とか上手く行ったみたいです。と、いうのも自分は結局
　　　リリースまで立ち会う事が出来なくて、その後の話をつい先日チームリーダから聞いたんですが。
　　　（とりあえず僕が担当して、その方法を実践した箇所についてはバグは殆ど
　　　　出なかったらしいんですが、、、まぁ、色々合って結局遅れた話とかは置いといて（ﾜﾗ）
　
　　　（※）PL/SQLを上手くテストする方法（既成のフレームワークとか）が見つからなくて、
　　　　　　「JavaとJ-UnitとDBUnit辺りを組み合わせて作ったら？」みたいなアドバイスもあったんですが、
　　　　　　結局、（作成・検証する時間・工数がなかった。作った後でメンテできそうな人がいなかった等の理由で）
　　　　　　「Excel に前提条件（と期待値）作成して、それをそのままSQL文になるような数式だけ書いて、
　　　　　　　PL/SQL実行前に流し込んで、対象のPL/SQL実行。その結果をSQLで引っこ抜いて、
　　　　　　　準備していた↑のExcelに貼り付けて「○・×」で検証する」という、、、
　　　　　　　これ、俺のTLに流したら非難轟々になるんだろーなー、という方法でやっつけてしまいました。。。
　
　っと、まだまだ雨の勢いが強いなぁ。。。（今日は台風18号の為に、午前半休にしてこのブログ書いてたりして）
　さて、今の仕事の仕組みを考えてみるかなー。

新人君へのアドバイス集（その１）

　2月半ばから本社を離れ、（一応数ヶ月の約束で）別の現場の方にヘルプに出てます。
そこで今年の4月で2年目を迎える新人君と、今年で4年目（？）位だけど
今迄全く開発に携わる機会が無かったメンバー2人と仕事をする事になり、
老婆心ながらこの二人に何とか自分の持ってる知識の一部でも伝える事が出来ればと思い、
日々アドバイスやらレビューバックした事をメモして、月一回それぞれに振り返りの為に送る
なんて事をしてました。

　結論を言ってしまうと、残念ながら前者の2年目君については、、、これ以上の
続行が難しいと判断して、自分の中で終了としてしまいました。。。。

　ただ、それ迄に記録した事がムダになるのも勿体無いので、業務とか現場に特化したような
知識とかは（守秘義務的な観点からも）載せる事が出来ないので
一般的な話に絞ってアップしてみようかな、と。

　⇒　正直なところ、周りの同期からみても既に遅れが見え始めている彼に対して
　　　勝手にこっちが「焦り」を覚えて、少々キビシ目に言っていたという事もあって
　　　それがプレッシャーになり、反発を招く事になってしまったようです。

　と、いつまでもボヤいてても仕方ないので、本題へ。

（※）以下、2年目君と4年目君にそれぞれしたアドバイスを特に区別せず
　　混ぜこぜに挙げてます。
　
　
【彼がファシリテートしていた会議が終わった後にしたFB】
　・議事メモは（提出を求められていなくても）取るようにしておいた方が良い。
　
　・今回の会議の目的はそもそもどういうものだったのか？
　　⇒　「情報共有？」「何らかの決定？」「相談・依頼？」
　　　　参加してて何がしたかったのかが良く分からなかった。
　　　　また、「出席者が次にどういうアクションを起こしたら良いのか？」は
　　　　明確にしておいた方が良い。

【ソースと単体テストのレビュー後にしたFB】
　・テストで大切な事は？
　　⇒　テストは「バグを見つけること」が目的。バグが見つけられないテストケース、
　　　　テストコードは極論すればゴミ。

　　・今回の（単体）テストの「ポイント」は？
　　　⇒　今回は設計書に書かれてることが間違いなく（＝過不足無く）実装されていることを
　　　　　確認するためのテストケース（すなわち設計書と1対1）でないとダメ。
　　　⇒　例えば異常系のテストが記載されていないが、（設計書に載っている以上）
　　　　　それもやる必要がある。
　　　　　今回であれば、同じ処理を2回繰り返せば一意制約エラーが簡単に起こせるので
　　　　　異常系テストケース確認はそれでやれば良いのでは？

　　・ソースはシンプルに。
　　　⇒　ソースのバージョン管理をしておけば、不要なコードをコメントアウトして残す
　　　　　みたいなことはしなくて済む。
　　　　　そういうものも含めたソースのゴミは極力減らして、シンプルに書く事。

　　　　　半年後の自分から「なんだこのコードは？」というツッコミが来ないように
　　　　　メンテナンスを意識してシンプルに書くようにした方が良い。

【質問があった時の（設計）課題に対しての考え方についてのFB】
　・設計に関して課題が見つかった時、どう解決していくか？
　　⇒　まず、自分でその課題に対して「どうあるべきか？」を考えて、
　　　　レビューを依頼する。もしくは有識者に確認するというのでも良い。
　　　　いくつかの方法はあるが、要は結局「自分で考える事」が重要。

　　　　⇒　今回なら、A案、B案、複数の方法があると思うが、
　　　　　　どれを選択するか？についても頭を使う必要がある。
　　　　　　また、その選択に関して（レビュアー等に確認する時は）
　　　　　　「根拠（とか何故そのように判断したのかの理由）」を示しながら
　　　　　　聞くのが良い。

【システム設計の考え方についてのFB】
　・各処理の前提条件を押さえている？
　　⇒　全体の流れの中で、その処理がどの位置に存在するのか？

　　　　例えばワークテーブルのデータ削除はそのテーブルを利用する処理が
　　　　動く直前に行うことが多いが、それはなぜか？（直後に動かさないのはなぜか？）

【レビュー後にFBした事】
　・レビュアーは完璧ではない
　　⇒　レビューのレベルはレビュアーのレベルに依存するので、
　　　　残念ながら100%の間違い・漏れぬけの指摘が出来るわけではない。
　　　　（ハッキリ言ってしまえば、レビュアーのレベル以上の指摘は出来ないし、
　　　　　逆にあまりにも下らない誤字脱字等が多ければ、それらの指摘だけでレビュアーの
　　　　　集中力・時間が割かれてしまって、レビュアーが指摘できる
　　　　　設計についての注意点等の指摘が半分も出来ないかもしれない）
　　　　
　　　　レビュアーの指摘にインスパイアされて、レビュアーの
　　　　指摘の漏れに自分で気づくことが大切。

　　　　また、指摘点が100%正しいわけではない。
　　　　勿論それなりの観点・根拠でレビューの指摘が上がってくるハズだが
　　　　その指摘自体が妥当かどうかについても自分で一度考えてみる。
　　　　妥当でない思ったら、その根拠を明示してレビュアーに
　　　　逆質問して、認識を合わせていく必要がある。

【作業の仕方についてのFB】
　・SVNへのコミットはこまめにするべし。もしくは最低限ロックをかけて作業する事。
　　（※）残念ながらこの指摘はこの後毎月のように指摘する事になったのですが。。。
　　
っと、まだまだ1/3にもなってないけど、長文になりそうなんで、一旦区切りますか。
　　

AgileSamurai 埼玉道場に参加してました

　今年に入ってプライベートでも仕事でも色々あって
すっかりブログを書く、ということから遠ざかってしまってました。。。orz

　と、いうわけで短めですが、久々に（？）勉強会に参加したんで。
　
「第11回 アジャイルサムライ読書会 埼玉道場 - PARTAKE」
　http://bit.ly/1lrlJvQ
　
　当日はちょっと早めに出発してこれまた久々にアキバに寄ったりなんかして
USB扇風機やらを仕入れつつ、今回は赤羽ではなく王子の会場へゴウ。

　初参加の方も2人ほどいる中、3人3人のテーブルに分かれて例の如く
今回はユニットテストの章の音読と議論を開始。

　各自疑問に思う事とか議論のネタなんかを付箋に書き出しつつ、進行。
今回はワークショップは無く、章が短かった事もあり20〜30分ほどで
本は読み終わって後は議論でたっぷり2時間くらい？

　個人的に印象に残った話は、いんだれさんのAgileに対しての考え方。
WFが「系」の考え方を重視して整理・整頓して進める方向なのに対して、
Agileは「プロダクト」という枠を「TDD」「Scrum」「かんばん」等々で
埋めていくイメージである、というお話。

　⇒　陣取り合戦とか、塗り絵っぽいのかな、と。ご本人はまだしっくりきてはいない、
　　　ということを仰っていましたが面白い考え方だなーという事で
　　　新しい発見でした。
　　　
　後、みほらぶさんの「全体は部分の総和ではない」というお話。
こちらについては、個人的には大体理解できたつもりだけど、まだ腹落ちしきれて
ないかな、と。

　⇒　異論・反論がある、とかでは無くて、基本的に合意・同意なんだけど
　　　自分の中で他人に対してキッチリ説明できるロジックが構築できてないと言うか
　　　自分の言葉で説明できない感じかなぁ。

　と、いうわけで、今回は（引っ越して千葉になってしまったために）
懇親会はちょこっとしか参加できませんでしたが、いつものように
有意義な時間を過ごす事ができました。
どうも有り難うございました m(O)m

　あ、そういえば先日参加した新宿道場の方、まだアップしてなかったな。。。

記録的な大雪！

　げ、気付いたら去年から更新してなかったのか。。。
　
　今日の東京地方は記録的な大雪で、朝から（正確には昨日の深夜から）
降り始めた雪が未だに降り続いてて、道路はもう20cm以上の積雪になってるみたい。。。

　いや、結局今日は近所の整体に行っただけで引きこもってたんで
特に何ということは無いんだけど、あまりの雪だったので書き留めておこうかな、と。

　これは1週間くらい雪残るなぁ、多分。。。

「XP祭り2013 〜 XP 〜」に参加しました

　1年ぶりのXP祭り参加、ということで今年は去年途中からになってしまった
オープニング漫才（？）を始めから見ようと、ちと早めに出発、、、
したら、まだ開場準備中のタイミングで着いてしまいました(汗)
　
　ちなみに当日のまとめはこちら
　
　「『XP祭り2013 〜 XP 〜』のまとめ #xpjug」
　　http://bit.ly/1eTSpuc
　
　午前中の漫才にはいつものお二人だけでなく、kawaguti さんも加わって
レッツゴー三匹状態でXPについての解説を。

　で、引き続いて kawaguti さんから
「高度12,000フィートからの Agile と Lean」のお話。
http://bit.ly/167ZPlU

　個人的には資料途中で話されていたバーンダウンチャートの
「昇龍拳」と「かかと落とし」が面白かったなぁ、と(^^)

　で、例の如く（？）若干押し気味で、次の鷲崎先生にバトンタッチ。
　
　鷲崎先生からは「SEMAT」の内容についての講演がありました。
途中、チラッと呟いたんですが、AgileやらリーンやらDevOpsやらWFやら
色々ソフト開発に関する話（だけでも無いけど）がゴチャゴチャしてる
状況を整理しようとする試み自体は個人的に興味あります。

　が、確か自分の記憶ではOOの設計手法についてまとめようとして
結果的に纏まりきれずに、とりあえず記法だけでも統一するべ、
ってなって生まれたUMLの話と同じような事にならなきゃイイけどなー、と
思ったりします。

　お昼ご飯はコンビニおにぎりでチャチャっと済ませて、
（ちょこっとだけゲリラLT覗いて）昼イチのアジャイルセンター試験に参加。

　意外と参加者が少なくて（自分はすぐに満席になると思ってたのに）
結局自分入れて20人位だったかな？

　セッション中の静かな事（ﾜﾗ）
こんなに静かなセッションってのも初めてでは無かったでしょうか(^^)

　40分程度で39問、しかも半分は（センター試験だけど）記述式という
結構ハードなものでした。自分は試験やる時のクセで、問題用紙に回答を
書き込みながらそれを解答用紙に転記するという手間のかかるやり方で
取り組んだこともあり、結局3問程度空白のまま提出する事になってしまいました（残念）

　解いている最中、思わず吹き出すような問題（選択肢）とかありましたが、
こちらとしては時間的なものもあり、一杯一杯になってしまってボケる余裕も殆ど無く。。。orz

　とりあえず、何とか終了。疲れたー。
　
　で、続いて、やっとむさんの「宝探しゲーム」のワークショップに参加。
以前から幾つかのイベントで開催されているのは知ってたんですが、
どうもタイミングが合わず、今回ようやく初参戦。

　開発側とビジネス側が協力して如何に他のチームより
ユーザを獲得するか、というゲームなんですが、色々と示唆に富んだ内容でした。
（因みに4人チームで２人ずつビジネスとITの担当に分かれますが、
自分はビジネス側でゲームに臨みました）

　結果としては残念ながら4チーム中、最下位という結果でした。
ただ、戦略的には「追い込み方式」で「見せ場」は作れたと思うので
個人的には結構満足でした。

　⇒　負けた原因を分析すると、１．サイコロ運、２．最後のターンの
　　　仕掛けタイミングが1手だけ早かった、ということかなーと。
　　　１．のサイコロ運については、どうしようもないですが、
　　　２．の仕掛けタイミングはコントロールできたので、
　　　ビジネス担当として申し訳ないことをしちゃいました。。。
　　　それが上手くいってたら、多分トップ獲得も十分可能性があったかな。

　とはいうものの、何より良かったのは、ゲーム中にビジネスと開発が如何に協力・
ゴールの共有ができるかが、重要だという事が実感できるWSだった事です。

　市場の不確実性（変化）への対応や、ビジネスとITの協力、他チームの
動向を踏まえた戦略等々、こういう内容のWSを新人研修なんかでも取り入れられないか
チト検討したいですね〜。

　で、続いて、昼イチのアジャイルセンター試験の解説セッションに。
古文の先生っぽい（勝手なイメージ(ﾜﾗ））和服姿のマチ子先生、
ジャージを着た体育の（飲んだくれ？）nawotoセンセイ、
用務員のオジサンのm_pixyさんという3人が解説に。

　答案用紙の返却で中々名前を呼ばれず、「ヤバ、お前追試！というオチ？」と
若干ドキドキしてましたが、なんと結果は2位。自分でもちょっとビックリ。
平均は64.3点だったようですが、自分は何とか78点取る事が出来てました。

　ただ、個人的にはボケ切れなかった所がスゴく反省。。。解説中、
オモシロ回答を前で発表してたんですが、唯一取り上げられたのは
「旅に出る」という回答だけ。
もっと他にも色々ボケ方あったやろ、と・・・orz

　来年はキッチリとボケられるように修行を積んできます。。。

　で、最後はLT祭りにクロージングと続いて、今年の僕のXP祭りは終了となりました。
（懇親会の方、カード決済ができなかったので、参加を諦めたんですよね〜。
　まぁ、多分実行委員の人に掛け合えば現金払いとかでも良かったと思うんですが、
　余計な手間を増やすのも悪いんで、今回は素直に帰ることにしました）

　と、いうわけで1日充実した時間を過ごす事が出来ました。
スタッフの皆さん、登壇者の皆さん、並びにWSで同じチームだった皆さん
そして参加者の皆さん、どうも有り難うございました。