THE HIRO Says

2016-09-10

Agile2016の参加レポートを公開しました

f:id:hageyahhoo:20160725215918j:image:w360


今年(2016年)7月末に、オリンピックCNN で有名なアメリカアトランタで開催された Agile2016 に参加してきました。その社内向けレポートを公開しても良いことになりましたので、共有させていただきます。

お伝えしたいことは極力このスライドに詰め込みましたが、スライドだけでは説明足らずの箇所も多々あるかと思いますので、可能な範囲で追加説明をしてみようと思います。



1. カンファレンスのここ数年の変化

f:id:hageyahhoo:20160725203047j:image:w360

キーノートスピーカーの Jurgen Appelo さんとともに。

ちなみに私は、Agile2014 以来の参加だったのですが、その間でも多くの変化を見て取ることができました。


(1) 参加者数の増加

今回は、42か国から2,500名以上の参加者がアトランタに集結しました。

Agile2014・Agile2015 ともに2,000名程度だったので、着実に増加傾向にあると言えます。


(2) 登壇者の変化

これまでは、有名な書籍の著者やレジェンドが大量に集結していたのですが、今年は例年以上にレジェンドクラスの登壇が減っていました。

一方で、これまでボランティアや一般参加者として参加し続けていた人たちが、一念発起してサブミッションを通して登壇するという例が非常に増えていました。

例えば、Agile2013で知り合ったカリフォルニアの友人がコーチングワークショップを開催していたり、ずっとボランティアをしていた日本人が論文を2本投稿してどちらも採用されたり。一方で、一人で3本も論文を投稿してダメだったという人もいたりなど。

これまでの「有名な人のお話を伺いに行って友達になる」カンファレンスから、「参加者みんなで意見をぶつけ合ってお互いを高め合っていく」カンファレンスへ変わってきたな、という印象です。


(3) 日本からの参加者数の減少

今年は、日本からの参加者が私を含めて6名でした。

Agile2012で30名程度、Agile2014で20名強だったので、急激に減少してきていますね。

アジャイルへの興味が失われつつあるのか、それとも自力でできるからもう十分になったのか?ちょっと原因を知りたいですね。



2. 議論の傾向

以前ご紹介した Agile2014の参加レポートでは、メトリクスに関する議論が出始めていると説明させていただきました。

それでは、Agile2016 ではどのような議論の傾向があったのか?その辺りをまとめてみます。


(1) メトリクス

今回の Agile2016 では、メトリクスを題材にしたセッション5つもあるなど、もはやメトリクスは当たり前のものとして説明されていました。

また、どのようにメトリクスを扱うべきかについても、下記のようにある程度共通認識が生まれつつありました。

f:id:hageyahhoo:20160910173358p:image

一方で上記の最後にある、「チーム・プロダクトの成長を促すためのもの」としての視点は、ほとんどの人が持っていませんでした。この点については、私がその重要性を多くの人に説明して回っていました。それがアジャイルカンファレンス


(2) DevOpsとメトリクス

DevOps については、次のような議論の傾向がありました。

  • DevOps の技術面は、既に前提条件として扱われている。
  • DevOps にメトリクスを組み合わせて、DevOps のプロセス面を改善しようという議論が活発になりつつある。

DevOps に関するメトリクスについては、ある程度共通化が図られ始めています。従いまして、新たにメトリクスを考案しなくても、ある程度このリストを再利用することができます。

f:id:hageyahhoo:20160910173356p:image


f:id:hageyahhoo:20160910173357p:image

それらに対する改善策も、ある程度分かってきています。というよりも、DevOps の各プラクティスを実施すれば、各メトリクスが改善して結果 DevOps が成功する、という流れになっています。


(3) 戦略的にコードを消せ!

f:id:hageyahhoo:20160727150503j:image:w360

レガシーコード改善ガイド』の著者の Michael Feathers さんによるセッションが、なかなか興味深かったです。その名も、『戦略的コード削除術』!

プロダクトが成長するとどうしてもプログラム(プロダクション・テスト双方含む)が「汚れて」くるので、戦略的に不要・不必要なコードを「削除」して、テストし易いプロダクトに保つべし!というものでした。


(4) 大規模スクラムスクラムのスケール

アメリカでの影響力の大きさか、SAFe(Scaled Agile Framework) の一人勝ちのような情勢でした。(SAFe だけで3セッションありました。)

一方で、LeSS(Large Scale Scrum)Nexus Framework についても、着実に言及はされていました。これらについて知見をお持ちの方は、来年の Agile2017 へ登壇するチャンスなのではないかと思います。



3. モダンアジャイル

3日目のキーノートスピーカーの Joshua Keriefsky さんモダンアジャイルが、今回のカンファレンスで一番インパクトがあったと思います。

セッションの概要は InfoQ にも翻訳されていますが、要は今の時代に即したアジャイルを「再定義」して、より良いソフトウェア開発を実現すべきではないか?ということです。

f:id:hageyahhoo:20160910181534p:image


そこでポイントになるのが、この4つの要素。

f:id:hageyahhoo:20160725220144j:image:w360

このロゴの日本語版を、角征典さんが作成してくださっています。下記サイトからダウンロード可能です。

http://modernagile.org/


この「モダンアジャイル」によって実現すべき未来。このアイデアに正直滾りました。詳しいことはレポートに詰め込みましたので、ぜひ見ていただきたいです!

f:id:hageyahhoo:20160910173359p:image



4. 私の Next Action

f:id:hageyahhoo:20160726205439j:image:w360

海外カンファレンスに出たら、それをできるだけ多くの人にフィードバックするのが参加者の務め!

というわけで今年は、こんな活動を実施しています/実施予定です。

  1. 同レポートにもとづく報告会を、2016/09/01(木)に自社内で実施しました。
  2. 「Pin the Tail」という、カンファレンスで実施されていたメトリクスのワークショップを、自社内で実施しました。
  3. 2016/09/24(土)の XP祭り2016 で、Agile2016 参加者同士のパネルディスカッションを実施予定です。

また、ご希望があれば、同レポートをベースに社外報告会を開催しようとも考えています。ご希望の方は、それとなく私に教えてください〜

未来の日本/世界のアジャイルについて、お互いに語り合えれば。



参考資料

2016-07-08

DevOps Summit 2016 に、キーノートスピーカーとして登壇してきました。

f:id:hageyahhoo:20160705093037j:image:w360 f:id:hageyahhoo:20160705134334j:image:w360

2016年7月5日・6日の2日間、台湾「DevOps Summit 2016」というカンファレンスが開催されました。

そのカンファンレンスに今回、キーノートスピーカーとしてオファーを受けて登壇してきました。

ちなみに、登壇者の中で私だけ中国語ができなかったため、英語で60分お話してきました。



そもそも DevOps Summit とは?

f:id:hageyahhoo:20160705084825j:image:w360 f:id:hageyahhoo:20160704161525j:image:w360

台湾2015年から年1回開催されている、DevOps に関する国際的カンファレンスです。昨年は Google・Chef、今年も Google百度Red Hat といったところが登壇されていました。参加者は約350人で、香港アメリカからも参加者がいました。

主催が「iThome」という新聞社であるところが、ちょっと面白いです。



なぜ声をかけられたか?

Agile Japan 2015 に登壇した際、せっかくなので海外の人たちにも資料を読んでもらいたいと思い、英語版も作成・公開していました。それが iThome の DevOps Summit 担当者の目に止まったそうで、メールで直接オファーをいただきました。

海外からオファーを受けたければ、積極的に英語でスライドを公開しておきましょう。これ、マジ。



あれ?去年…

台湾の「DevOps 2015 Conference」に、キーノートスピーカーとして登壇してきます

昨年も iThome さんからオファーをいただき、↑のようなエントリーを書いていたのですが、急遽病気で参加できなくなり、戦友の直井和久さんに代役をお願いした次第です。

(このくだりは、『アジャイルの魂2016』の直井さんの記事に書かれています。)


しかし今年、再び iThome さんが、昨年と同じ内容でオファーをしてくださいました。その心意気にどうしても応えたくて、今回登壇した次第です。



キーノートスピーチの内容

海外カンファレンスで何とキーノートを張られたYahoo! 伊藤さんの資料。凄い!そんなの平鍋さん以来じゃないだろうか。

尊敬する牛尾剛さんからのメンション。キーノートってそんなにすごいことだったのか!?と今更気づく。


いつもの発表と同様、実際に現場の業務で試した知見をベースとしていますが、今回は DevOps の今の流れに、あえて「テスト自動化CI を先にやれ」という波紋をぶち込むことを意図しました。

  • テスト自動化CI だけでも、十分変えられることがあることを伝えたかった
  • テスト自動化CI もやらないで、いきなりデプロイツールだけで DevOps を語ろうとする連中に釘を刺したかった
  • テスト自動化CI も面白いことを伝えたかった

また、2013 年頃から持論としている、「自動化技術を基盤にしてプロセスを改善する」という点は、何度も強調しておきました。

本当は Chef での CD とかも業務ではやっているのですが… その話はまたおいおいしていきます。



DevOps に関するインタビュー

f:id:hageyahhoo:20160705122749j:image:w360 f:id:hageyahhoo:20160705135422j:image:w360

iThome は新聞社なので、インタビューも受けました。

私が受けた質問は次の2つ。私がアジャイルスクラムのことを知っているということで、特にそれらと DevOps とを絡めた回答が欲しいとのことでした。

  1. アジャイルに DevOps は必要か?
  2. DevOps をやるために、アジャイルは必要か?

インタビューの内容は、後日公開予定です(★公開され次第 URL を付記します★)。



カンファレンスの締めのパネルディスカッション

f:id:hageyahhoo:20160705085751j:image:w360 参加料?のいろはす(多分)

初日の朝に突然オファーを受けて、「翻訳つけるから大丈夫」との声に乗せられ、興味本位で受けてしまいましたw

内容は、参加者からの質問に各自が思うことを回答するというものでした。

ちなみに私への質問と回答は、以下の通りです。

  • Q) DevOps を効率的に進めるためには、どうすれば良いか?
    • A) まずは自分たちのプロセスを計測してみよう。時間が掛かっているところがあれば、そこが改善の出発点だ。
  • Q) テスト自動化を効率的に進めるためには、どうすれば良いか?
    • A) プロダクトをテストで壊そう。壊せるということは、効率的にテストを出来る証左でもある。
  • Q) Dev を Ops にするには、何が必要か?
    • A) Dev に Ops の仕事をやらせよう!


セッションの傾向

f:id:hageyahhoo:20160706121602j:image:w360 f:id:hageyahhoo:20160706121610j:image:w360

2日間、中国語が分からないなりにセッションを聴いてみての、私なりの所感を簡潔にまとめます。

  • Docker はもはや当たり前に。
    • 発表者のほとんどが、デモで使用していました。
  • ChatOps や Kubernetes など、簡単に「オペレーション」を実施できるものがトレンドになりつつある。
  • Kubernetes のように、設定を常時 GUI で表示しておくツールも便利にみえる。
  • Test Kitchen & serverspec への関心が極めて高い。
  • 発表されている内容のレベルは、日本のカンファレンスのものと同等。
    • こと DevOps については、日本と台湾に特別な差はない。


結論

f:id:hageyahhoo:20160705124857j:image:w360 f:id:hageyahhoo:20160705120426j:image:w360

もしあなたが、海外とのコネクションを確立したいと考えているならば、スライドなりプログラムなり、積極的に英語で情報を公開しておきましょう。

きちんと拾ってくれる人がいます。


このブログエントリーを読んで滾って、「私も登壇してきました!」という人の報告を、是非とも聞いてみたいです!


2016-03-13

『組織にテストを書く文化を根付かせる戦略と戦術』の再演に参加してきました

2016年3月11日(金)に、『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 +α』というイベントに参加してきました。

@t_wadaさんの下記スライドが、今まさに自分がやっているテスト自動化支援・アジャイル支援のヒント満載だったため、どうしても直接お話を伺いたく参加した次第です。

『組織にテストを書く文化を根付かせる戦略と戦術』

http://www.slideshare.net/t_wada/test-strategy-and-tactics


以下、個人的に気付きがあった点のメモです。



戦略編(6-19ページ)

7ページ目
  • 導入を目的にしてはいけない。
    • ついやりがち。
    • 現実を見せ、現実に即した解決策で改善していくことになる。(伊藤)

11ページ目
  • 文化を変えるのには、2-5年はかかるとのこと。
  • 環境は変わり続けるので、コードに触れないわけにはいかない。

13ページ目
  • AS-IS & NotToBeから始める。
  • 人は自分の速度でしか成長できない。
    • プロジェクトについても、同様のことが言える。(伊藤)
      • 早過ぎてもダメ、遅過ぎてもダメ。
      • 自分の支援しているプロジェクトの進め方は妥当だったか?

14ページ目
  • 人を知る
    • メンバーが何によってモチベートされるかを考えてアクションすべし。

15ページ目
  • リファクタリングのジレンマ(独立タスク化すると、却って行われなくなってしまう)
    • ビジネス価値を提供していないように見えてしまうため。

17ページ目
  • 全ては変化する

18ページ目

19ページ目
  • テストは品質を上げない
    • 品質は分かるようになる
    • 品質を上げるのは、設計とプログラミング
    • テストを作って既存プロダクトを「壊す」ことで、プロジェクトに改善の必要を気づかせることは可能。(伊藤)


戦術編(20-33ページ)

21ページ目
  • どこからやるか?
    • 不具合駆動
    • マネーパス etc.

22ページ目
  • テスト指針(Lean from the trenches)

23ページ目
  • 誰とやるか?
    • 全員でやるのではなく、できる人を少しずつ増やして行く方が良い。
    • 教えられる人を増やす。
    • ペアプロでひとりずつ。
      • いつも「遅すぎないか」というジレンマに襲われているけれども、これでいいのだという安堵感を感じた次第。(伊藤)

24ページ目
  • 最初から全部やろうとはしないこと!

25ページ目
  • こだわるべきところ・優先度
    • repeatability
    • independent

27ページ目

29ページ目
  • コードレビューだけでも、改善につながる。
    • 誰かに見られる → 改善

30ページ目
  • 実装を変えることを後押しするテストをつくるべし。

31ページ目
  • (テストの)サンプル・デモは大事。
  • 動かして初めて実感してもらえる


所感

現在PHPのテスト自動化支援を主にやっているのですが、必ずしもユニットテストにこだわらなくても良いのかな、と感じた次第です。というのも、PHPにはstaticベースのフレームワークが多くて、モックを差し挟んで…といったレガシーコード改善ガイドチックなテクニックがほとんど使えない。で、それでも無理矢理テストを書こうとすると、DBAPIを直接叩くものになってしまい、そこがビルドを壊す脆い点になってしまうのではないかと…

しかし今回の講演で、出来るところから確実に改善すべしと伺い、別にそんなテストでも無いよりまし、プロダクトの改善につながるのであれば良いのではないかと。

そういう気付きを得られたという意味では、@t_wadaさんに感謝です。



参考資料

2015-12-02

プロジェクトメトリクスのワークショップ at プロダクトオーナー祭り2015

去る2015年11月28日(土)に、『プロダクトオーナー祭り2015 〜世界を変えるのは俺たちだ!〜』というイベントに参加し、プロジェクトメトリクスのワークショップを開催してきました。

ありがたいことに、ワークショップ参加者は21名の満員でした。また、プロダクトオーナー祭り全体でのワークショップ満足度No.1にも選んでいただきました。参加していただいた皆さん、場を提供してくださった関さん初めスタッフの皆さんに感謝です。

ワークショップで使用した資料は下記になります。

内容的には、以前開催した「ゆるぎー」「DevLOVE関西」のものとほぼ同じですが、参加者同士でフィードバックを与え合う機会と、それを反映する機会とに時間を多めに割くようにしました。

参考までに、参加者の作成したプロジェクトメトリクスたちをご紹介させていただきます。

f:id:hageyahhoo:20151128191256j:image

f:id:hageyahhoo:20151128191606j:image

f:id:hageyahhoo:20151128191613j:image

f:id:hageyahhoo:20151128191810j:image

f:id:hageyahhoo:20151128192013j:image

f:id:hageyahhoo:20151128192230j:image


所感

参加者が既にプロだったこともあるせいか(?)、お題とその考え方・進め方をお伝えさえすれば皆さん自律的にチームを組み、私から指示をしなくてもフィードバックを与え合う姿勢が既に出来ていました。一方でプロジェクトメトリクスには、そうした自律性やチーム学習を促す側面で、私の想像以上に効果があるのかも知れないと思った次第です。

今後も、プロジェクトメトリクスについて調査・研究・実験を繰り返して、皆さんのプラスになる知見をより提供できれば幸いです。

2015-10-04

Nexusフレームワークについて簡単に調べてみた

RyuzeeさんTwitterで、InfoQの『スクラムのためのNexus Guideを公開』という記事を教えてもらったので読んでみました。

Android開発の記事かな?と思ったら、『スクラムガイド』で有名なKen Schwaberさんによる、スクラムをより大きなプロダクト・チームで活用するためにスケールするための新しいフレームワークなんですね。

既にNexus Guide』を公開しているということだったので、実際に読んでみました。ちなみに『Nexus Guide』は、https://www.scrum.org/の右下の「HOW DO YOU SCALE SCRUM?」をクリックすると閲覧することができます。



ポイント

基本は、スクラムをベースとしたフレームワークです。但し、以下の点に特徴があります。
  • 3-9チームで、1つのプロダクト/ソフトウェアを開発するケースを想定しています。
  • 1スプリント毎に、各チームの成果物(ソフトウェア)を統合します。
    • これを実現するために、「自動化」の必要性が言及されています。


複数チームで1つのものを作るので、以下のものを各チーム間で調整・統合する必要が出てきます。

これらを調整するために、既存のスクラムの上に以下の「調整・統合の場」的なイベントと、Nexus Integration Team」という調整チーム(スクラムチームとは別)とを設けています。

  • Nexus Sprint Planning(各チームで行うものとは別に行う)
  • Nexus Daily Scrum(各チームで行うものとは別に行う)
  • Nexus Sprint Review(全チームで一緒に行う)
  • Nexus Sprint Retrospective(各チームで行うものとは別に行う)
    • 次のトライをどう「見える化」してトラックするか(≒メトリクスを取るか)といったことにも言及されています。
  • Refinement


依存を如何に扱うか?

3-9チームで1つのプロダクト/ソフトウェアを開発し、スプリント毎に統合するため、各チーム間での依存関係をどう扱うかが鍵になります。依存関係の解決方法として、次の3つが言及されています。

  • 依存を洗練する
  • 依存を取り除く
  • 依存を極小化する


スクラム色が濃い

以下の点は、スクラムの影響が濃い、もしくは同一だと言えそうです。

  • Transparency(透明性)
  • Inspection(検査)
  • Adaptation(適応)
  • Definition of Done(DoD)


「スケール」という次のメインテーマ

Nexusの他にも、近年スクラムをスケールするためのフレームワークや方法論が多く提唱されるようになってきました。


いよいよ、「スケール」について広く真剣に考える時が来たのかも知れませんね。