THE HIRO Says

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


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

2015-09-23

退職。

一部の方にはお伝えさせていただきましたが、2015年10月15日付けで、楽天株式会社を退職することとなりました。

3年弱の在籍ではありましたが、自分自身のキャリアの中で一番手応えのある職場でした。入社直後から多くの難題にぶち当たりましたが、その都度手を差し伸べて下さった方たち・仲間たちがいたおかげで、この刺激的で激しい会社を生き延び続けることができました。

また、会社のニックネーム制で「The Hiro」(The Rockリスペクト)と名乗っていたのですが、それをもじって「ヒーロー」「スーパーヒーロー」といじっていただいたことは、良い思い出です。

関わらせていただいた皆さんに、心から感謝の気持ちを伝えさせていただきます。



なぜ退職するのか?

アジャイルコーチ・自動化アーキテクトとして、現場に入ってチームを指導し、最強のチームを創るということに専念したいと考えたためです。

  • 組織が色々と変わりまして、これまでのようにアジャイルコーチ専任で仕事をすることが難しくなったという背景があります。
  • 自分自身の強みをより活かそうと試行錯誤した結果、改めてアジャイルコーチ・自動化アーキテクトが自分には合っているなという認識に至りました。
  • 楽天という会社自体は、今でも好きです。

次の会社では、アジャイルコーチ・自動化アーキテクト専任で働きます。



思い出

得たもの・残せたもの

多くの先生・仲間
  • 藤原大さんからは、現場から問題点を見つけ出す目からメンバーとの接し方、生き方に至るまで、非常に多くことを学ばせていただきました。
  • 及部敬雄さんとは、最大のライバルかつ入社時からの個人的メンターとして、言い尽くせない程お世話になりました。(なお、この師弟関係は生涯続きます。)
  • 楽天技術研究所の森正弥さんには、社外発表の機会の提供、仕事で行き詰まったときのアドバイス、「スーパーヒーロー」の称号、テスト駆動開発グループの設立など、どれほどお世話になったことか。
  • 直井和久さんには、大組織でのリーダーシップの示し方、またエンジニアを成長させるための基盤整備などについて、多くのことを学ばせていただきました。また、Agile Japan 2015に共に登壇させていただいて、社外的にも成果を残せたことが、個人的には嬉しいです。

他にも、一人一人名前を挙げて感謝の念をお伝えしたいのですが、Word文書で100枚でも不足しそうな勢いですので、個別にお伝えさせていただきます。



今だから書けること-プロジェクトメトリクスの由来

SIerからServicerに移ってきて

前にいた会社・部署は、典型的なSIerでした。そこでは技術的な貢献や改善(例:自動化の推進で作業時間を9割削減など)が評価されることはまずなく、上司・プロジェクトマネージャの指示に従うことを強いられていた側面がどうしてもありました。

一方で楽天に移ってからは、自分自身の成果を自力で上司に示すことが求められました。特に数値で成果を見せることを。この点が最初のカルチャーショックでした。(この変化に最初は耐えきれず、入社1ヶ月で歯を1本折りました。)


プロジェクトメトリクスへの昇華

一方で、成果の見せ方を求められる裏に、私が最初に属した組織に次の問題が潜んでいることも分かりました。

  • 具体的な成果目標を設定していなかった/できていなかった
  • 成果を測る指標を持ち合わせていなかった
    • そのため、単純な仕事量の多さで成果としようとしており、結果多くのメンバーを疲弊させていた
  • 成果指標を次の施策に活かす仕組み・考え方が欠落していた

そのため私は、具体的な成果目標の設定・成果指標の開発・成果指標に基づいた改善施策というものを創り上げることにしました。これが、昨今私が多用している「プロジェクトメトリクス」の始まりです。


「プロジェクト」メトリクスという表現

当初は単に「メトリクス」と表現していたのですが、後にQAの方と多く仕事をさせていただくようになり、QAでいうところの「メトリクス」との混同・誤解が生じ易いことが分かりました。そこで、現場のプロジェクトで使うものだから、「プロジェクト」メトリクスと呼称することにしました。

一方で昨今では、「アジャイルメトリクス」という表現が海外で出ているようです。



最後に

今までは、「楽天の伊藤宏幸」と、会社の名前に守られている部分が多分にあったと考えています。

楽天」という会社名がなくなっても生きて行けることを、着実に証明し続けて行く所存です。いままでお世話になった方たちへの恩返しをし続けます。