The HIRO Says

If you smell what The HIRO is cooking!!!

RSGT2017で二刀流に挑戦してきました


しれっと真ん中に収まる私。


2017年1月12日(木)と13日(金)に大崎ブライトホールで開催されました、Regional Scrum Gathering Tokyo 2017 (RSGT2017)に参加してきました。
今回は、スピーカーとしての登壇に加えて、スポンサーブースの運営担当の二刀流に挑みました。


1. スピーカーとして


中邑真輔新日本プロレス時代の入場曲「Subconscious」に乗って入場。(Supported by 及部 敬雄さん

※入場シーンの動画を、永瀬美穂さん開原 隆弘さんに撮影していただきました!
https://www.facebook.com/miholovesq/videos/1367363473327310/

この資料を作成した背景
  • 2014年にメトリクスに関する多くの発表をさせていただき、その知見を深めて多くの人の役に立てられる体系化したものにしたいという願望が生まれました。
  • 2015年は転職があったため、正直手が回りませんでした。
  • 2016年にAgile2016SQiP2016に参加し、自分の中に納得のいくものができあがりつつあったので、これを機にアイデアを整理をすることにしました。
  • プロダクトオーナー祭り2016で、POに役立つメトリクスについてのお話をさせていただける機会があったので、そこでの発表をさらにスクラムに関わる人全体に使えるように拡張してみました。


平鍋 健児さんからも、ありがたいフィードバックをいただくことができました。


そのあと


私にメトリクスの多くを教えてくださった細谷 泰夫さんと、私がメンターとして勝手に仰いでいる原田 騎郎さんから、これをアジャイルメトリクスパターン(言語)」にまとめられるのでは?という提案をいただき、現在少しずつパターン化しているところです。
今年2017年3月のAsianPLoPに投稿できればと考えています。→投稿しました!(2017年1月15日)


2. スポンサーブースの担当として


弊社は昨年もスポンサーとしてブースを出させていただいたのですが、正直ノーアイデア・ノーアクションで、ブース運営が非常にしょっぱかったという反省がありました。
そこで今年は、私を含めたメンバー同士でアイデアを出し合い、OpenJamを実質運営しながら、そこでチラシやノベルティを配るという作戦を実施するに至りました。また、スポンサーチケットを配った有志にも、ブース運営を手伝ってもらいました。

お揃いのTシャツを作成して、万全の体制の図。

毎朝、参加者の皆さんが来場される前に会場に来て朝会を実施して、その日にやることをしっかり共有。

2日目のオープニングでも、見事な宣伝を敢行。(漫才扱いされていましたがw)

ちなみに、弊社のコワーキングスペース「LODGE」は、土日も営業しています!



で、実際にやったOpenJamは、以下の通りです。

スマートフォン開発におけるフィーチャーチームとコンポーネントチームについて(藤村 新さん安井 力さん木村 卓央さん荒瀬 中人さん

アジャイルにおけるパターンについて(オージス総研 原田 巌さん

※写真が見つからなかった orz

SAFeやDtoDについて(オージス総研 藤井 拓さん

ブースを工夫した成果

事前に用意したノベルティやチラシを、9割方捌くことができました!
これも、ブース運営・OpenJam運営に協力してくださった皆様、そしてそれを観てくださり弊社に興味を持ってくださった皆様のおかげです。
本当にありがとうございました!


今後の予定

中村 洋さんが、CSPを取るそうです。


How to acquire CSP/『「認定スクラムプロフェッショナル」の資格を取得する方法』をベースに、そのサポートをさせていただければと思ってます。増やすぞCSP!


我々は皆様を、新たなスクラムの地平にいざなおうと考えております。
その地平とは、一体どんなものか?
その答えはもちろん、トランキーロ!あっせんなよ!!


どうもありがとうございました〜。


参考資料

今回の目玉はこれです〜

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント


前書きを書かせていただきました。

アジャイルコーチング

アジャイルコーチング


入場に使用した「Subconscious」が入っています。

病院の元日2017


元日の午前中から、救急車で病院へ搬送され、診察を受けていました。いきなり2017年クライマックス。

ことの経緯

前日の2016年12月31日のこと。朝起きてから、痰に明らかな血が混じるようになりました。また、痰自体の量・頻度も多い。はじめのうちはそうでもなかったのですが、徐々に喉と胸に痛みを感じるようになり、14時頃に散髪から帰ってきた頃には、もう起きていられないほどに消耗していました。熱も37度ちょっとの微熱に。結局血痰の量は、15回前後に及びました。

病院へ行くまでの葛藤

さすがに出血の量がおかしいので、病院に行くことを考えたのですが…時期が時期だけに病院がやっていない。
救急外来も考えてみたのですが、以前非常にぞんざいな扱いを電話でされた挙句対応を拒否をされたことがあるので、これも嫌。

しかし、Facebook で友人たちから「とにかく病院行け」「救急外来だ」「119番だと対応が丁寧だぞ」と大量のリプをもらったこと、また今までで一番の鮮血を出してしまったことから、119番を選択。
ちなみに何とか自力で歩行は出来たので、画像のような搬送のされ方はせず、歩いて救急車に乗車して、「あーこうやって一般車に避けてもらうのね」とか思いながら病院へ向かいました。

診察結果

喘息と気管支炎の悪化で、大量の咳をし続けてしまったことによる、気管支などの裂傷とのことでした。風邪は万病のもと。
当初は結核も疑われたのですが、それは大丈夫とのこと。
あと…もしかしたら最近身近にインフルエンザに罹っている人いませんでした?と聞かれました。私は心当たりがないのですが、ここ数日私と会った人は注意が必要かもです。

ふりかえりと今後の対策

  • 病院を毛嫌いせず、行くべき時には勇気を持って行くこと。
  • でも病院は選べ。ダメなところは本気でダメだから、良い病院を探そう。
    • インターネットでの口コミも、ないよりははるかにマシ。
  • 休日に病院にかからねばならぬ時は、119番が大変親切。
  • 喘息対策に、ダイソンだけでは限界。空気清浄機も買うべし。
  • 喘息の病院を、今回診察してもらったところに変えたほうがよさげ。
    • 今まで診てもらっていた病院で血痰の話をしたら、「気のせい」で済まされたのです。

最後に

健康には色々と工夫をしているのだけれども、まだその度合いが低いのか、それとも厄年のせいか、着実にカラダが弱ってきていることを感じています。残念ながらこれは事実で否定のしようがない。それでも、「あいつカラダ弱いよね」とか言うのは本気で止めてください。そう言われて心身が回復することは絶対にありません。場合によっては実力行使もやぶさかではありません。
心身ともに弱っているので、適度に労ってください。

2016年の活動報告

これで全部ではない気もしていますが、覚えている範囲で。

2016年1月18日(月) Regional Scrum Gathering Tokyo 2016

大雪に見舞われて、自宅から車で20分程度の会場に2時間以上かけて到着したことが印象深し。
あと、英語資料を日本語で説明するのは、練習していても何気にムズい。


2016年7月6日(水) DevOps Summit 2016のキーノートスピーチ

無料で台湾に行けるという理由であっさり快諾したキーノート。思いの外反響があり、海外でのキーノートってすごいのだなと今更ながら実感。
ちなみに台湾ウィスキーのKAVALANは飲むべし!


2016年9月1日(木) Agile2016の社内レポート

ブログにも書いたけれども、びっくりするほど反響がなかったことを記憶している。もうAgile Conferenceの情報とか要らんのか…?


2016年9月24日(土) XP祭り2016

1) Agile2016の報告

2016年10月頃 モダンアジャイル

平鍋 健児さんのおかげで関わらせていただけたプロジェクト。
これがきっかけでJoshua Kerievskiさんと繋がれたのは大きな財産。


2016年11月26日(土) プロダクトオーナー祭り2016

これまでずーっと書きためていた、メトリクスについてまとめたプレゼン&資料。
分かりやすいという意見をいただけた反面、事例が少ないという指摘もいただいた作品。


2016-12-17(土) HDIfes#05「IT業界とゲーム業界、それぞれのDevOps」

英語の資料を日本語で説明しても、通じる人には通じるのだと分かった良い機会。


2016年を振り返って

7月のDevOps Summit 2016の話を社内の有識者が拾ってくれて、多くの人に広めてくれたことが、結果として2016年を生き抜くポイントになった気がします。
おかげさまで、ヤフー株式会社の黒帯になることもできました。(この後が大変そうw)

正直カラダにガタがきていますが、以下のことを目指していこうと思っています。

  • CEC(Certifies Enterprise Coach)を取得する!
  • Agile2017に参加して、人脈を広げる!
  • 生きる!

正直不安の方が先に立っていますが、2017年も生き抜いていこうと思っています。

ITとはプロレスである10の理由

Finally, The HIRO has come back to this blog!


皆さんこんにちは。
さて、PCモニターないしスマホ画面で各種Advent Calendarをご覧の皆さん!何かが足りないような気がしませんか?


そうです!今年のAdvent Calendarには、プロレスが足りないんです!


そこで今回は、役に立つ情報も含めながら、炎上上等でITとプロレスの話を書き尽くしてみようと思います。


1. 技術力しかないエンジニアは「しょっぱい」

プロレス界には、アマチュアレスリングや柔道など、格闘技界で活躍した人たちが入門してくることが多いです。しかし、往々にしてそのような選手たちは、プロレス界に入ってから伸び悩む傾向があります。なぜならば、格闘技の「強さ」は見せられても、プロレス的なお客様を惹きつける「魅せる」動きが(すぐに)できないことが多いためです。(ちなみにこのように、お客様に「魅せる」動きができず、お客様を満足させられない様を、プロレス用語では「しょっぱい」と表現します。)

翻って、IT業界に目を向けてみましょう。技術力は突出しているけれども、コミュニケーションなど他の能力には興味を示さない/伸ばそうとしないエンジニアたちを、よく目にしませんか? 後述しますが、仕事においてお客様を惹きつけることやステークホルダーを喜ばせることは、エンジニアにも求められることです。特に、アジャイルやDevOpsが広まり、ITとビジネスとの距離をより短くすることが求められている昨今では、よりその傾向が強くなってきています。

強さ・技術力は大切です。しかしながら、それしか見せられるものがないのであれば、お客様・マネージャー・チームメンバーらにとっては、「しょっぱい」存在でしかないのです。強さ・技術力以外にも、お客様らに「魅せられる」能力を身につけることが肝要です。

※まれに、強さ・技術力だけで「魅せられる」人もいますが、これは例外ということで(^^;)


2. お客様にお金を出してもらえるエンジニアこそが評価される

プロレス界で「評価される」レスラーとは、どのような存在でしょうか? 幾つか要素があるのですが、その中でも重要なものに、「チケットを売れる」というものがあります。

これは先述の「しょっぱい」の話とも関連しますが、お客様の印象に残る動きができ、お客様に「またこのレスラーを見たいな」と思わせる存在こそが、プロレス界では重宝されます。なぜならば、お客様にお金を出してもらっているからです。

翻って、IT業界。「クールなコードを書きさせすれば評価される」・「技術の分からないマネージャーが自分を評価してくれない」などと思っているエンジニアはいませんか? 残念ながらそのような態度では、評価されることはあまり期待できません。なぜならば、お客様にお金を出してもらえていないからです。

エンジニアの皆さんにはぜひ、「技術力が全て」とは思わずに、ステークホルダーやマネージャーらとよく話をして、彼らが一体何を求めていて、どのように売上・利益をあげようとしているのか、一度しっかりと確認してみてください。そして、どうしたらそこにエンジニアとして貢献できるかを考えてみてください。そこに、自分がより評価されるようになるためのヒントが転がっているはずです。


3. 自分たちを適切に「みせよう」

これまで説明してきたように、プロレスラーは、お客様を惹きつけ、「またこのレスラーを見たい」とお金を出してもらうよう振る舞うことが必要です。すなわち、いかに自分を「魅せられるか」がポイントです。それでは、レスラーがどの程度お客様を惹きつけているか、すなわち人気があるかということを、どのように判断すれば良いのでしょうか? 具体的な評価軸としては、以下のものが挙げられます。

  • 大会・興行の観客動員数
  • グッズの売上金額
  • チケットの販売枚数(レスラー自身がチケットを販売する場合)
  • イベント開催時の参加人数
  • Twitterのフォロワー数


一方でIT業界。特に昨今のアジャイル界隈では、「メトリクス」(KPIとほぼ同義)というものを活用して、プロダクトおよび開発プロセスの良し悪しを「見える化」する動きが、世界的に広まりつつあります。
メトリクスに関する具体的な魅せ方や活用方法については、以下の資料が参考になります。

プロダクト開発活動およびリリースしたプロダクトがどの程度お客様を惹きつけているか。どの程度「魅せているか」をメトリクスで「見える」ようにする活動は、多くのプラスの効果があります。もしまだメトリクスを採用していない方は、これを機に採用してみてはいかがでしょうか。


4. ステークホルダーマネジメントは重要

レスラーは、試合だけをしていれば良いわけではありません。地方での大会・興行のために営業に出たり、保育園や老人ホームなどを慰問したり、テレビに出たりと、大会・興行を成功させるために日々さまざまな活動を行っています。
例えば、新日本プロレス棚橋 弘至選手(@tanahashi1_100)。その圧倒的で旺盛な営業活動は、オーナーをして「もう営業に回るところがない」とまで言わしめたほどです。
棚橋選手のリング内外での活動ぶりについては、ぜひ下記書籍をご覧ください。

IT業界も同様です。プロダクト開発やチームを支援してくれる出資者・マネージャー・他部署の関係者・協力会社などなど、挙げればきりがないですが、こうした「ステークホルダー」との良好や協力関係を築くこと、情報のやりとりを円滑化すること、期待値を適切にコントロールすることなど、ステークホルダーマネジメント」はプロダクト開発の成功に必須です。

ぜひ、あなたのプロダクト開発を成功させ続けるために、IT業界の棚橋選手を目指して行動してみてください。


5. プロレスは「プロセス」

ダジャレじゃないですよ?(-ω-;)

プロレスとは、アスリートとしての圧倒的な運動量、および試合の流れと間によって、独特の高揚感をお客様に伝えるスポーツです。単純に技を出すだけではダメで、例えば試合序盤は関節技の攻防でじっくりお客様の目を慣れさせてリングに注意を惹きつけ、中盤から大技を出し始めて場の転換を図り、終盤は必殺技とその切り返しの応酬で魅せるというような、「試合の流れ」が重要になってきます。

これは、IT業界における、適切なプロダクトを作るための「プロセス」を整備・運用することに似ていませんか?
ウォーターフォールでもアジャイルでも良いです。そのプロダクトを開発するための適切な「プロセス」があり、メンバーステークホルダーらに認知・共有されており、それを活用して実際に適切なタイミングでプロダクトを提供できていることが肝要です。
昨今適用が広がってきているCI/CD・DevOpsは、ここぞというときに必殺技よろしく最新のプロダクトをリリースできるようにしようというプロセスです。あなたのプロダクトにあったプロセスを整備して、あなたもIT業界でベストバウトを狙ってみてください。


6. 良いチームがお客様を喜ばせる

プロレスラーだけでは、大会・興行を成立させることはできません。
チケットを売ったり会場を押える営業、グッズ売り場の担当者、音響や照明などのスタッフ、大会・興行に適したカードと試合順序を決めるブッカーら、多くの人たちが協力しあって、大会・興行を成り立たせ、お客様を喜ばせています。
一方で、この協力関係がうまくいかない場合は、興行が不成立となったり、お客様が離れてしまい、結果会社が倒産してしまうということもあります。

IT業界も同様です。お客様に喜ばれるプロダクトを作り続けるための「良いチーム」を作り運営していくことが、成功のために必須です。営業・企画の方のアイデアを適切にすくい上げ、プロダクトに落とし込むこと。デザイナーやQAと良好な関係を気づき、手戻りを減らすこと。運用担当者と協力し、迅速にプロダクトをリリースできる体制を構築すること。適切なステークホルダーマネジメントを行うこと。などなど。

自己組織化され、価値に向かって一直線に進める「良い」プロダクト開発チームが、最終的にお客様を喜ばせます。


7. 日々の鍛錬がお客様を喜ばせる

せっかくプロレスを見るならば、カッコいいカラダのレスラーをみたいですよね。また、肉体的にも技量的にも研ぎ澄まされた選手の動きを見て満足したいものです。
昨今のプロレス界では、特にボディービルダー並みにカッコいいカラダを作り、良い試合をするために徹底的に節制している人が増えてきています。先の棚橋選手が、その最たるものでしょう。あのカラダで今年40歳です。

それでは、IT業界と関連するポイントはどこでしょうか。それは、勉強することを欠かさないことでしょう。ただしこれは、常に最新の技術を追い続けることだけではなく、適材適所のソリューションを提供できるよう選択肢を増やすことも含みます。レスラー同様、引き出しは多い方が良いです。
また、アジャイルでは、「持続可能」に仕事をし続けることが重要とされています。したがって、無理せず仕事を続けられるよう、適度な運動をすることも役に立つでしょう。

日々の鍛錬。これは、業界問わず必要なことでしょう。


8. プロレスは共通言語として仕事を円滑にする

コミュニケーションを円滑にすることは、プロダクト開発を成功させるための重要な要素です。
プロレスの用語や決めゼリフを共通言語として活用すると、うまくいくことがあります。これは、メンバー間やステークホルダー間の認識の差を埋めるために、DDD(Domain-Driven Design)の「ユビキタス言語」や「DSL」(Domain-Specific Language)を活用することに相当します。
以下に例をあげます。

  • トランキーロ:焦らずゆっくり振る舞って欲しい時に使いましょう。
  • 特にありません:おそらく3つくらい言いたいことがあるはずです。質問して聞き出してあげましょう。
  • どうしよっかなー?:難しい選択を迫られた時に使いましょう。緊張した空気が弛緩します。
  • たぎる:リリース間際など、感情が高ぶってきた時に使いましょう。
  • イヤァオ!:感情が高ぶり言語化できなくなった時に使いましょう。どんな場面でも使える万能の言葉です。

9. Matzはプロレス好き

Rubyの父として有名すぎる、Matzことまつもとゆきひろさん(@yukihiro_matz)。ある日、宴席でご一緒させていただいた際に、「プロレスのミーム(決めゼリフ)が好き」というお話を伺いました。そこで私は、当時は新日本プロレス、現在は現在はWWEで活躍中の中邑 真輔選手(@ShinsukeN)の決めゼリフ「イヤァオ!」をお教えしました。そして、その宴席を一緒に「イヤァオ!」で締めました。

ITはやはりプロレスであることの証明ではないでしょうか?w


10. 筋肉は裏切らない

多くは語るまい。

筋トレが最強のソリューションである マッチョ社長が教える究極の悩み解決法

筋トレが最強のソリューションである マッチョ社長が教える究極の悩み解決法



最後に

私の趣味は、スポーツナビというサイトで、プロレスを含むスポーツ全般の情報を日々追うことです。


ぜひ、あなたの目で、あなたの手で、最新のプロレスの情報を収集し、日々のプロダクト開発活動にその知見を生かしてみてください。

超兄貴?兄貴のすべて?

超兄貴?兄貴のすべて?

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


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

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


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


キーノートスピーカーの 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つもあるなど、もはやメトリクスは当たり前のものとして説明されていました。

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

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

(2) DevOpsとメトリクス

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

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


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



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

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


『レガシーコード改善ガイド』の著者の Michael Feathers さんによるセッションが、なかなか興味深かったです。その名も、『戦略的コード削除術』!
プロダクトが成長するとどうしてもプログラム(プロダクション・テスト双方含む)が「汚れて」くるので、戦略的に不要・不必要なコードを「削除」して、テストし易いプロダクトに保つべし!というものでした。

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

アメリカでの影響力の大きさか、SAFe(Scaled Agile Framework) の一人勝ちのような情勢でした。(SAFe だけで3セッションありました。)
一方で、LeSS(Large Scale Scrum)Nexus Framework についても、着実に言及はされていました。これらについて知見をお持ちの方は、来年の Agile2017 へ登壇するチャンスなのではないかと思います。


3. モダン・アジャイル

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

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


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

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


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


4. 私の Next Action


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

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

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


また、ご希望があれば、同レポートをベースに社外報告会を開催しようとも考えています。ご希望の方は、それとなく私に教えてください〜
未来の日本/世界のアジャイルについて、お互いに語り合えれば。


参考資料

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn))

Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn))

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

 

2016年7月5日・6日の2日間、台湾で「DevOps Summit 2016」というカンファレンスが開催されました。
そのカンファンレンスに今回、キーノートスピーカーとしてオファーを受けて登壇してきました。
ちなみに、登壇者の中で私だけ中国語ができなかったため、英語で60分お話してきました。


そもそも DevOps Summit とは?

 

台湾で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 に関するインタビュー

 

iThome は新聞社なので、インタビューも受けました。
私が受けた質問は次の2つ。私がアジャイルスクラムのことを知っているということで、特にそれらと DevOps とを絡めた回答が欲しいとのことでした。

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


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


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

 参加料?のいろはす(多分)

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

内容は、参加者からの質問に各自が思うことを回答するというものでした。
ちなみに私への質問と回答は、以下の通りです。

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

セッションの傾向

 

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

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

結論

 

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


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


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

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ページ目
  • 全ては変化する
    • 仕様・理解・スキル・技術 etc.
18ページ目
19ページ目
  • テストは品質を上げない
    • 品質は分かるようになる
    • 品質を上げるのは、設計とプログラミング
    • テストを作って既存プロダクトを「壊す」ことで、プロジェクトに改善の必要を気づかせることは可能。(伊藤)

戦術編(20-33ページ)

21ページ目
  • どこからやるか?
    • 不具合駆動
    • マネーパス etc.
22ページ目
  • テスト指針(Lean from the trenches)
    • リスク
    • 手動テストのコスト
    • テストの自動化コスト
23ページ目
  • 誰とやるか?
    • 全員でやるのではなく、できる人を少しずつ増やして行く方が良い。
    • 教えられる人を増やす。
    • ペアプロでひとりずつ。
      • いつも「遅すぎないか」というジレンマに襲われているけれども、これでいいのだという安堵感を感じた次第。(伊藤)
24ページ目
  • 最初から全部やろうとはしないこと!
25ページ目
  • こだわるべきところ・優先度
    • repeatability
    • independent
27ページ目
29ページ目
  • コードレビューだけでも、改善につながる。
    • 誰かに見られる → 改善
30ページ目
  • 実装を変えることを後押しするテストをつくるべし。
31ページ目
  • (テストの)サンプル・デモは大事。
  • 動かして初めて実感してもらえる

所感

現在PHPのテスト自動化支援を主にやっているのですが、必ずしもユニットテストにこだわらなくても良いのかな、と感じた次第です。というのも、PHPにはstaticベースのフレームワークが多くて、モックを差し挟んで…といったレガシーコード改善ガイドチックなテクニックがほとんど使えない。で、それでも無理矢理テストを書こうとすると、DBやAPIを直接叩くものになってしまい、そこがビルドを壊す脆い点になってしまうのではないかと…
しかし今回の講演で、出来るところから確実に改善すべしと伺い、別にそんなテストでも無いよりまし、プロダクトの改善につながるのであれば良いのではないかと。
そういう気付きを得られたという意味では、@t_wadaさんに感謝です。


参考資料

レガシーコード改善ガイド

レガシーコード改善ガイド

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営