Regional Scrum Gathering® Tokyo 2014 2日目基調講演 by Jutta Eckstein氏 #sgt2014
二日目の基調講演は、Jutta Eckstein（ユッタ・エクスタイン）さんによる、「組織にアジリティを取り入れる – どうすればアジャイルになれる？」でした。
「アジリティを取り入れる」というタイトルではありましたが、アジャイルはもちろん、組織内に何か新しい事を取り入れる際に、どのようにしたらいいか、というお話で、非常に参考になりました。
私は現在、チーム内でのTDDの普及率を高めたいと考えており、そのためのアプローチとして、非常に参考になるお話が聞けました。
「変化」があるときの人の心の動き
何かが変化する際、どのような心理的変化が人にあるか、ということについて、著名な2つのモデルが有るそうです。
一つが、Elisabeth Kübler-Rossによるもので、もうひとつが、Virginia Satirによるものとのことです。
どちらも、パワーポイント2010（多分、「リボン」のことだと思う）を例に説明されていました。
※この辺までは英語で聞いてたんだけど、「難しくなってきた」＆「これは聞き逃しちゃいけない話だ」と判断したので、このへんで諦めて、翻訳機装着。
Elisabeth Kübler-Rossのモデル
- 新しいパワポが発売される。
「何このUI、使いたくねー。なるべく古いバージョンで粘ってやる」 - 「仕方ない、そろそろ最新の使うか…」
- 慣れたのでなんとも思わなくなる。
Virginia Satirのモデル
- 快適な状態。「パワポ2003使いやすくて好き！」
- カオス。2010を使ってみる。「新しいUI、使いやすくていい！」という時と、「なんでこんな使いにくいUIにしたんや！ 元の出せ！」という時がある。
- 「あー ここを変えたのはこういう意図が… 確かに使いやすい。」と腑に落ちる
- Integration & Practice. 新しいバージョンを練習して修得する。
大事なことは、誰かが組織に新しい手法（アジャイルとかね！）を持ち込もうとした場合、他の人にはこうした変化が起こっていることを理解することだそうです。
カオス期にいるような人も中にはいるので、きちんとそれをわかりましょうと。
さらに、こうした変化は一度に一つだけ起こるわけではなく、社内に同時に何本も走っているもので、周囲の人達はそういった変化を、同時にいくつも受け入れているのだということでした。
変化を導入する方法
そういうわけで、「変化をもたらす」ことはとても大変なのですが、
効果的なアプローチ手順が紹介されていました。
- Preparation （今から導入したいことを説明する）
- Retrospective （これまでの自分たちを振り返る）
- Readiness/Enabling Workshop
- (Customized) Training
- Monitoring / Coaching
- Sustaining Change
- Leassons Learned
2. と 3. は、チームレベルならこの順、部門レベルくらいだと逆のほうがいいかも…？とのことでした。
この中でも特に、おお！と思ったものをご紹介させていただきます。
Readiness/Enabling Workshop
「今から導入しようとしているもの」を以下の4つに分類するそうです。
- 既に行われていること
名前が違うだけで導入するまでもなくやっていることがあるかも。
例えばScrumを始めようとするときに「デイリースクラム」って名前ではやってないけど、オレ達もともと朝礼はやってるね。という感じ。 - 導入が簡単そうなこと
- 導入が難しそうなこと
- 会社の文化的に、どうしても導入できないこと
また、3, 4については、どうして導入できないのか、何が障害なのかということを洗い出すことも大事だそうです。
私達のプロセスにTDDを導入する場合であれば、「既に行われていること」は、「テストコードを書くこと」になりそうです。
（順番はおいておいて、テストコードを書くこと自体はされているので）
(Customized) Training
実際に新しいことを導入することが決まったあとは、練習することになります。
ただしここで陥りやすい点として、練習用の課題を設定して、それで練習すること。
それでは実際に仕事で導入しようとした時に、「あれ、練習と違う」「この場合はどうやるんだろう？」となってしまうとのこと。
そうではなく、実際の課題に合わせた、「Customized」されたTrainingを実施する必要があるとのことでした。
3つの役割
順番が前後しますが、新しいことを導入するにあたって、3人の協力が不可欠、という話がありました。
- Passinate change agent
→ 変えようというパッションを持っている人。この人がいなくては始まらない。 - Project Leader
→ プロジェクトのリーダー。かつ、管理職とも関係が築ける人。 - Architect / Technical leader
→ チームのプロダクト、技術に最も詳しい人。アジャイル（導入しようとしているもの）に詳しい必要は必ずしもない。
なるほど、と思う反面、この3つ全部、ないしは2つを誰か一人が兼任してしまうことが、実際の現場ではあるのではないかと感じました。
テクニカルリードが新しい手法を持ってきたりとか。
そこで、そういった場合、一人に負担がかかるけどどうすればいい？ という質問をさせてもらいました。
すると、
「上記の意図は、普通はこういったロールの人（プロジェクトリーダやアーキテクト）が組織内にいるものなので、その人達をどう巻き込んでいくかが重要である、ということ。」
「一方、一人が兼任しなければならないケースの場合、はじめはそれでもいいと思う。まずはやってみることが大切。
ただし、仲間はいた方がいい。」
「ちなみに、時間がないからできない！と言ってる人は、何かに余計な時間を使ってるはず。
例えばテストコードを書かずにコーディングしてるからデバッグに時間がかかってません？
そういうのを見つけてあげましょう」
という回答を頂きました。
セッションが終わってからもう一度思い返してみると、自分のチームでは、上司も、技術力がある人も、非常に協力的で（そして自分じゃなくて）、だからこそうまくいってるんだなぁ、ありがたいことだなぁ と思いました。
ということで、なにか新しいことを導入するときのアプローチの、具体的なヒントを貰うことができました。
是非トライしてみたいと思います。
Regional Scrum Gathering® Tokyo 2014 「プログラマのためのScrum」 #sgt2014
本セッションでは、日本で唯一（！）の認定スクラムデベロッパー（Certification Scrum Developer）の資格をもつ、土肥さんから、認定スクラムデベロッパーの研修の紹介や、資格を取った後、CSDとしての活動について紹介がありました。
（なお、土肥さんは認定スクラムマスターもお持ちとのことです）
認定スクラムデベロッパ研修
認定スクラムマスタや認定プロダクトオーナーと違い、CSDの研修は実施が少ないそうで、アジアではまだシンガポールでしか行われていないそうです。そこで土肥さんは、シンガポールで一週間の研修を受け、CSDを取得したそうです。
研修では実際に仮想のプロジェクトに入っての開発を行う傍ら、講義の時間もあったそうです。講義では特に、ATDD、TDD、モックの使い方、リファクタリング、設計などに時間が割かれたそうです。
ここから、スクラムガイドで示されている方法で開発を進めるためには、テストファースト、自動テストが重要であることが伺えます。
また、研修会場の天井には巨大なモニターがあり、これが常にCIの状態が表示されていたそうです。
具体的には、最後にコミットされてからの経過時間が表示されていて、コミット間隔があくと、講師から、「何時間もコミットしてないの？」と突込みがきたそうです。さらにこのモニター、テストが通らないコードをコミットしてしまうと、真っ赤な画面になり、Warning!の表示とともに音が延々となり続けたそうです。
それだけ、テストが通らない、ということは非常事態なんですね。
プログラマにとってのScrum
もともとこのセッションに参加した私のモチベーションが、
「俺はScrumがいいと思ってるので自分のチームでもみんなを巻き込んでるんだけど、実際どう思われてるんだろ？」
ということに対するひとつの回答が見つかりそうだからでした。
（もちろんメンバと対話するのが一番なんですが、ほかの意見も聞いてみたかったので）
土肥さんの経験では、ScrumによってプログラマがHappyになれる点として
- 裁量が増える
（設計などの提案をする機会が増える、とのこと） - 成長を促す
（必要なスキルが多くある） - チーム開発
（「みんなで」同じ目標に向かってがんばる） - TDDのサイクルに乗れる
（TDDって書いたコードがすぐ動かせるし、プログラマは好きなはず！）
といった点があるとのことでした。
一見、Scrumでなくてもできそうな物たちですが、スクラムの肝である「群がる」とか「透明性（タスクボードによる可視化とか）」から生まれる、チーム開発の楽しさは、私もScrumならではだとおもいます。
また、CSDの研修でも重視されていたように、テストの自動化、テストファーストの開発は、できるとScrum開発が非常にやりやすくなりますので、こういったスキルの必然性が高まるのもなるほどと思いました。
TDDやATDDなどのプラクティスは簡単に習得できるものではないですし（私も人に教えられるほどできていないのが現状です）、できなくても「プログラミング」はできるので、「何でこんなことをしなければならないんだ？」と、開発チームのメンバからは思われてしまうのかもしれません。
しかし、こういったスキルを全員が身につけたうえで、チームで「群がる」Scrum開発ができるようになれば、開発チームとして一段上の開発ができそうだと、私も一エンジニアとして改めて感じました。
Regional Scrum Gathering® Tokyo 2014 : 1A-3 「Bing開発グループはどのようにして毎日リリースをしているのか」 #sgt2014
今年もRegional Scrum Gatheringに参加させて頂いています。
参加したセッションについてのレポートを書いていきたいと思います。
まずは、マイクロソフトのヤマモトジン氏による、「Bing開発グループはどのようにして毎日リリースをしているのか」です。
2ヶ月×4の、「6ヶ月」周期
Bingでは、以下の様な開発サイクルで開発を行っているそうです。
最初のステップのデータ解析・ゴール設定フェーズでは、Bingが持つ、膨大なユーザの行動データを解析し、どのような改善を行ったら良いか、そして何を目標とするか（基本的には数値で表せる、「検索精度」を目標にするそう）を2ヶ月かけて練るそうです。
その後、4ヶ月の開発期間があり、開発締め・効率改善フェーズがあります。
ここではリファクタリングなど、開発効率向上につながる取り組みを、デベロッパが行うそうです。
また、この4番目のフェーズと、次のサイクルの1番目のフェーズは期間が重なっており、デベロッパが改善を行っている間に、製品に責任を持つプログラムマネージャは次のゴール設定を行うそうです。
既に現在のサイクルのゴールは明確になっている状態なので、プログラムマネージャは開発チームと別れて、次の案件に集中することができるそうです。
Daily Shipping
上記のようなサイクルで開発は行われていますが、企画開始から6ヶ月、ないし8ヶ月後にようやく機能がリリースされるわけではありません。
Bingでは常時新しい機能をリリースし（100％のリリースではなく、基本的にABテスト）、ユーザの反応を見て、さらなる改善につなげる、ということをしているそうです。
Dailyとは言っても、次の日に引っ込めるようなことをするわけではなく（そりゃそうだ）、大体2週間ほどデータを集めた後、専門のビッグデータ解析部隊によってデータ解析に回されるとのことでした。
Daily Shipping を支えるインフラ
セッション後に、リリース周りの仕組みや準備／オペレーションのコストについて質問してみました。
曰く、デプロイ作業自体はコンフィグファイルにABとかプロダクションとか的なことを書くだけで切り替え可能とのこと。
専門のオペレータもいるそうです。
また、検索ということで多くのサーバを使っており、さらにDCも分散されているため、全てのDC、全てのサーバにデプロイされたことを確認するのが大変で、様々なノウハウが有るとのことでした。
現在はこのノウハウは、Azureの運用部隊に引き継がれているそうです。
（この辺、AmazonからAWSが生まれてきたのと似ていると感じました）
ただし、こういったシステムは元からあったわけではなく、Bing開始当時は少ないサーバで自動デプロイしていたこと、その後時間をかけて現在の仕組みが構築されてきたことを聞くことが出来ました。
さて、私・我々は何をするのか
このセッションで聞いて、ぜひ取り入れたい、自分たちのプロセスを改善したい、と思ったのは、
- 膨大なサーバ群に対して簡単にA／Bテストや本リリースが行える、リリースの仕組み化
- 明示的なリファクタリング期間の設置と、効率改善が評価されている
の2点です。
どちらも昨年から取り組んでいるもので、本年も計画的に行っているものではありますが、引き続きトライしていきたいと思います。
前者に関しては、今まで野良的に行われてきたものが、今年はいよいよ組織化されそうなので、うまく協力して、いい方向に持っていけるようにしたいと思います。
後者は、昨年末試しに一週間、集中して改善だけ行う期間をとってみましたが、細切れにやるよりこちらのほうがいいと感じましたので、またどこかで同じようなことをしてみたいと思っています。
2013年振り返り
今年も一年、大変お世話になりました。
年末ということで、飲み会なども諸々ありましたが、そう言った場で、直接・間接的に一緒に仕事をしている人や、同じ会社・業界の様々な人と話すことができて、
改めて、素晴らしいメンバーや環境に囲まれてお仕事をさせていただいていることを感じることができました。
できたこと
さて、今年もは1月に、二つの目標を立てていました。
「強いプロダクト」は作れたのか
前者は、改めて見返すと、（若干年末に駆け込んだものの）以下のことがチームとして達成できました。
・手持ちの各プロダクトのデプロイスクリプトができた
これまでかなり時間がかかる＆面倒だったリリース作業がだいぶマシになりました。
※実際はスクリプトを作ったあとも、プロダクトが抱えている問題のせいでなかなか自動デプロイができなかったのですが、11月にようやく解決しました！
・自動コンポーネントテストの基盤ができた
- コーディング前に「動作するテスト」を作成できるので、コーディングする人のゴールを明示的にできる
- マージ後や、本番デプロイ直前の最終確認なども安全・かつ高速・かつ小さな手間で行うことができる
- UTと分離したので、Jenkins上でのビルドの高速化につなげられる
- 定期的なリグレッションテストができる
といったことが可能になりました。
なお、こうしたツールは、私…というよりは、一緒にチームを組ませてもらっているメンバーの皆さんが主に手を動かして作ってくれていて、本当に感謝です。
いつも言いたい放題ばっかりですみませんｗ
いつも言いたい放題ばっかりですみませんｗ
「プログラマ／エンジニア」として学べたのか
昨年は、自分の興味がプロジェクトマネジメントとか、チームマネジメントとかに偏りすぎていたかな、という思いがありました。
そこで、もう一度、技術者としての立ち位置を探すために、こういった目標を立てていました。
まず、上記に書いたような改善は、エンジニアとしてのバックボーンがあってこそ、理解して推進できたことだと思いますし、若干、手を動かす機会が足りなかったものの、
TDDブートキャンプや、システムテスト自動化カンファレンスなどの外部勉強会や、書籍などでまずは自分が学んで、そこからチームのメンバーに協力してもらう、ということはできていたと思います。
また、言語面では、JavaDay TokyoやJavaOneへの参加をはじめ、コードの書き方の本を読んだりだとか、Javaという言語にある程度向かい合う時間を意識してとることができました。
新規で使うフレームワークの勉強などはしていましたが、言語そのものにここまでフォーカスしたのは初めてだったかもしれません。
結局、「自分の立ち位置が見つかったのか」というと怪しいのですが、現在または今後にぶち当たる問題を解決するための、「引き出し」はある程度見つけられんじゃないかと思います。
スクラム
スクラムに関しては、
私、スクラムを分かってませんでした 〜Jim Coplien氏のScrum Master 研修を受けて 1〜
に書いたとおり、この研修が非常に衝撃的でした。
この研修の後、（これまでもそうでしたが）チームのメンバーに協力してもらって、ちょっとずつ、案件の進め方を変えてもらって、より、これまで以上に、「群がる」開発にシフトしてきました。
振り返りでは、「チームワークが発揮できた」という意見がメンバーからも上がり、ある程度の効果が出せているのではないかと思っています。
できてないこと・これからやること
上記、「できたこと」に書いたことでも、できていないことはまだまだあります。
リグレッションテストはようやくフレームワークができたところで、これと「群がる」開発を組み合わせることで、仕組みとして機能しだします。
…が、一筋縄ではおそらくいかないでしょう。
リリースの自動化はまだまだ、安全性・信頼性・準備の簡単さなどの面で改善すべき点が多くあります。
ちょっとずつ、時間をとって改善する必要があります。
プログラムは、ふと気付くと、ここ数年Javaばかり（それも、ろくに書いていない）ので、久しぶりにまっさらな状態で別の言語を学んでみようかと…。
遅ればせながらScalaあたり狙ってるんですがどうなんでしょう… Groovyも気になります。
…などなどあるんですが、この記事を書くにあたって、今年一年のブログを読み返したところ、（薄々気付いてはいたものの）改めて、まるでできていない、大変なことが2点あることに気付きました。
- 積読本が多すぎる
- 「続きを書きます」といった記事の続きが書かれていない
もうこれね、ひどすぎる。
積読本に関しては、手をつけない、というより、読みかけの本が多すぎるんですよね。もともと隙間時間を見つけて本を読むのが下手なので、継続して読めない人で…
ちょっと意識して、週に一度でも、ゆっくり本を読む時間と場所を見つけたいと思います。（技術書って、単に読むだけじゃなくて整理とか写経とかするので時間と場所が必要なんですよね… みんなどうしてるんだろ）
とりあえず、未読了の本の、たな卸しします。年内、って言うか今日。
2.の、ブログが続かないのも、おおよそ1．と同じ理由なので、やはり意識して自己研鑽の時間をとりたいと思います。
今後、自由な時間が減ることはあっても、増えていくことは恐らく無いので、来年の目標の一つは、自分にあったインプット・アウトプットの方法を見つけること としたいと思います。
ではよいお年を。
GroovyでJUnit用のテストフィクスチャを宣言する を試してみたのだけど
結論から言うと、思ってたのとは違ったかも。
こちらの後半で触れたとおり、テストフィクスチャの外部セットアップをした場合、
可読性があまりいけてないという問題を現在抱えておりまして、その解決法として、Groovyがよさそうだという事でTryしてみたいと思っていました。
で、私、ひとつ勘違いしていまして、GroovyのクラスをJavaのクラスのインナークラスとして宣言することで、1ファイル内で宣言もテスト実施もできるもんなんだと思っていたのですが、Javaのクラス内にGroovyのクラスは宣言できないのですね。（この点間違っていたら、どなたか突っ込んでください）
となると、結局JsonファイルかGroovyクラスかの違いで、別のファイルに定義するのには変わりないと。
一応クラスなので、Eclipseの補完機能が諸々使えるアツいのです（リンクをたどってクラスまで飛べたり、リネームがちゃんと効くのは確認）が、
プロダクト自体がJsonで入出力するAPIのため、Jsonファイルでテストフィクスチャを定義しておいたほうが、何かと便利なのでした。
どっちかっていうと、Reflectionを使わずにPrivateフィールドにアクセスする、とかの方が利用用途が高いかも。
なお、実施に当たってはこちらを参考 というか、ほぼそのままパクらせていただきました。ありがとうございました。
