Atlassian Team Playbookを自分なりにまとめてみたよ（ヘルスモニター）
Atlassian Team Playbookなるものが出てました。なんかよさげな感じはあったのですが、イマイチ頭に入ってこなかったので、自分なりの解釈を含めてまとめてみました。
まずはヘルスモニターから。気が向けば、残り2つの要素（プレイ / ゲームプラン）についてもまとめてみようと思います。
以下、[ikikko]というタグ付けした箇所が、自分がまとめたところです。
チームの関連
このガイドでは、まずはヘルスモニターというもので、チームの全体像・健全性の基準を定めようと言われてます。ヘルスモニターは、以下の3チームに対してそれぞれ定義されています。
- リーダーシップチーム
- あなたは、影響力があり長期的なビジョンや高いレベルでの取り組みに関係し、意思決定することができる。プロジェクトで実際に作業をすることはないが、メンバーをまとめる役目にある。
- プロジェクトチーム
- 新しい機能をリリースしたり、「ビジネス」をするための戦略的なプロジェクトを提供したり、新しいものをローンチさせることで、お客様のためになる素晴らしい成果を出すことがあなたの使命である。
- サービスチーム
- 技術職かそうでなくても、作業量が多くリスポンスの質が重要になる役目。あなたの仕事は、キューが必要で1日または１週間で処理できる量が限られている。
[ikikko] 3チームの関連は、ざっとこんなものかな。厳密には、一方向じゃなくフィードバックループなどもあるでしょうが、ややこしくなるので図からは割愛。
なお、この3チームの分類は、スキルセットや専門分野によるものではなく、仕事の成果や仕事を生み出す手段での分類とのこと。2018/06時点だと3チームですが、今後増える可能性はあるよと（参考：このサイトにはチームのタイプが 3 つしかありませんが、それはなぜですか?）。
各チームの説明
各チームには、「フルタイムオーナー」や「価値と指標」といった、チームに必要な8つの属性が定義されています。ただ、属性を単に眺めてても右から左に流れていってたので、無理矢理にでもまとめてみました。
[ikikko] まずは、リーダーシップチーム。「チーム」と「成果物」、あとは両方にかかる「全体」的なものと、属性を3つに分類してみました。各属性の細かい説明については、Atlassianのページを参照してください。
[ikikko] 次に、プロジェクトチーム。リーダーシップチームと属性がかぶってるやつも多く、構成は大体似たり寄ったりな感じにまとめられました。
[ikikko] 最後は、サービスチーム。これが結構迷った。特に、サービスにかかりそうな「サービス指示書」「サービスレベル」。どう違うかがイマイチわからなかったのですが、「サービス指示書」が横軸的にスコープを表すもので、「サービスレベル」が横軸に対して縦軸的にレベルを表すものとしてみました。
チームごとの属性の差分
リーダーシップチーム vs プロジェクトチーム
↑でちょっと触れたように属性が結構かぶってて、6/8は一緒でした。違うのは以下。
| チーム | チームに対する属性 | 成果物に対する属性 |
|---|---|---|
| リーダーシップチーム | チームのまとまり | 意思決定 |
| プロジェクトチーム | フルタイムオーナー | 概念実証 |
[ikikko] 以下、それぞれの差分に対する考察。
チームに対する属性の差分は、リーダーシップチームとプロジェクトチームで、構成メンバーの役割が多いか少ないか、とか？プロジェクトチームでは、プロジェクトの責任者であるオーナーだけでなく、日々作業を行ってる人などもいるはず。そういう中で、オーナーがしっかりフォーカスして役割を果たすことが重要になってくるから、必要な属性として「フルタイムオーナー」が出てくるのかなと推測しました。
成果物に対する属性の差分。これは、そのまま成果物の性質による差分でしょうね。リーダーシップチームの成果であるビジョンは、まあ「意思決定」を早くして進めることが大事ですよね。一方、プロジェクトチームの成果物はある程度具体的に見える・体感できるものになるはず。その成果物を、適切に「概念実証」を進めて顧客からのフィードバックを得ていくことが大事。
似たり寄ったりな理由は、成果物がビジョンなのかプロダクトなのかであって、どちらも成果物を創造するというプロセスは一緒だからなのかなとか思ったり。
リーダーシップチーム / プロジェクトチーム vs サービスチーム
ちょっとこれは、差分が大きすぎて比較はあまりできそうにない。その中でも大きな違いは、サービスチームでは「効果的なパートナーシップ」や「顧客中心」といった、「チーム」以外に関係者が増えるところ、ですかね（もちろん、前者2つのチームでも顧客が大事でないとは言わないけど、属性としては入ってない）
[ikikko] 「効果的なパートナーシップ」は、サービスを提供しようとなると、より広範囲なカバーとしてパートナーが必要となる場面も出てくる、ということかな。「顧客中心」については、サービスチームが最終的に顧客と一番密接に関与するから、とかかなあ。
以上、自分の頭の整理も兼ねて、Team Playbookで紹介されている要素について、まとめてみました。少なくとも自分の中では、なんとなく整理・分類できた気はします。この上で、ヘルスモニターを実施してみれば、どの系統が弱いのかがより分かりやすくなる・・・のかな。例えば、「フルタイムオーナー」や「バランスの取れたチーム」などチーム面が弱い傾向にある、とかとか。
もちろん、もっと別の適切な分類もあるとは思います。というかあるはず。特に、サービスチームについてはかなり怪しい。というわけで、こういう分類がより適切じゃない？とかあれば、ぜひぜひコメント・フィードバックください！
「カンバンによるアジャイルプロジェクトマネジメント」を読みました
「カンバン仕事術」を読みました - @ikikko のはてなブログでも読んでたのですが、カンバンはもっと突き詰めていきたいところなので、他の本で別の視点の意見も取り入れていきたいですね。ということで。
今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書
- 作者: Eric Brechner
- 出版社/メーカー: 日経BP社
- 発売日: 2016/07/14
- メディア: Kindle版
- この商品を含むブログを見る
第1章 経営陣の同意を得る
カンバンを導入する際に、経営陣の同意を得やすくするプロセスについて。幸いにも、今の自分はある程度権限を与えられているので、ここにすごく力を費やす必要はないけれども、いつもいつもそういう恵まれたケースばかりじゃないだろうから、頭に入れておこう。
印象に残った項目は、この辺。
第2章 カンバンのクイックスタートガイド
この章に限った話ではないけど、トラブルシューティングが非常に役に立つ。
問題11：一度に複数の作業項目を担当したがるチームメンバーがいる
ありそう。基本的にはWIP制限をちゃんと守りつつ、どうしてもというときにはその部分だけWIP制限を増やして試してみる、ってのが提案されてました。
あと、ここで触れられてた「1作業項目＋50%のバッファー」つまりWIP制限をメンバーx1.5倍ってのは、スタート地点としてはよさそうだと思いました。1つ待ちが入ってる間にもう1つ進められる人もいるけど、全員が全員そうではなくて、その場合は周りを手伝わないといけなくなるというので、いい塩梅っぽい。
問題12：ツールや自動化を改善する時間が取れない
これもありがち。で、回答として「作業項目が10個あるとしたら、そのうちの1つか2つはインフラストラクチャの改善であるべきです」とのこと。大体1,2割ぐらいを改善の時間ということで、これは目安として考えてたのと一致してました。
第4章 ウォーターフォールからの適応
はい、ここも最後のQ&Aから。ウォーターフォールを経験したことがある人からのFAQとあるけど、はじめてカンバンに取り組む人から出てきそうな質問ということで、自分の言葉で説明できるようになっておかないと。特に↓らへんは。
Q 小さいバッチでどのようにしてスピードアップするのか？
A 小さいバッチはいろいろな面で効果的です。（中略）要するに、小さいバッチは無駄な作業や手戻りを大幅に減らし、プロダクトの品質を向上させます。
Q では、なぜこれまで小さいバッチを使用してこなかったのか？
A 小さいバッチを使用するには、作業フローの調整が必要だからです。（中略）分析、実装、検証が同じペースで進むように調整できない場合、その先にあるのは、一括の作業、無駄な作業、バグの大きなバックログ、そして大量の手戻りです。
Q いろいろなアナリストや開発者、テスト担当者がいる中で、どのようにして作業のペースを調整するのか？
A 分析、実装、検証の作業を、それらのペースが同じになるように制限します。（中略）こうした作業の制限はよく「WIP制限」と呼ばれます。
Q 作業を制限したらペースが落ちるのではないか？
A 私たちが制限するのは人ではなく、人が行う作業の種類です。開発者があるフィーチャーでブロックされているとしたら、アナリストがさらにフィーチャーを分析したところで意味がありません。そのような場合、アナリストは開発者のブロックを解除するために働くべきです。
第8章 サステインドエンジニアリング
SE：サステインドエンジニアリング。多分カンバンが一番有効で、使いこなせたらよりよくなるんじゃないかと思ってる領域。要するに、運用保守開発で、事前に計画出し切ることが難しい・突発的に起きうるタスクが多い領域ですね。そういやスクラム現場ガイドでも出てきたので、今一度読み返しておこう。
最初に検討するのは、SE専門チームにするか、コアエンジニアリングチーム（プロダクトのロードマップを進めるチーム）が担当するか、の2択。
| メリット | デメリット | |
|---|---|---|
| SE専門チーム | コアエンジニアリングチームがロードマップを進めることに専念できる | SEチームのメンバーは、あまり意欲的でないかもしれない |
| コアエンジニアリングチームが担当 | SE業務を根本解決するモチベーションがわく | SE業務によって、チームの作業が頻繁に妨げられる可能性がある |
次は、注記から引っ張ってくるけど、この辺ははっとした。極端な話、不具合0になれば不具合分のサポート業務は減らせて、より攻めの業務に時間費やせますよね。もちろん、そこまで目指すかどうかはケースバイケースにはなりますが、頭の片隅に入れておいていい考え。
コアエンジニアリングチームの作業がそこまで遮られる理由に目を向けることが重要となります。たとえば、全体的な品質の問題に対処すれば、サポートリクエストの数を最小限に抑えることが可能かもしれません。
章末のトラブルシューティングからは、この辺かな。
問題1：コアエンジニアリングチームにカスタマーサポートからのエスカレーションが殺到し、対応しきれないほどのバックログが生成されている
問題5：エスカレーションの数が予測できないため、チームの保守計画に支障が生じている
問題1は、何が問題かを見える化してからそれに対応するという、まあ基本ですよね。場合によっちゃ、SEに入る前のプロダクトの品質に問題があるかもしれないので、品質を高める活動が必要になるかもしれない。問題5は、予測不可能だからこそカンバンが有用だよ、けどカンバンで透明性を少しでも高めてスループットやリードタイムなどから予測できるようにしようと。
第9章 さらなる方策とカンバンを超えて
カンバンに関連する理論や手法について。多かれ少なかれ知ってるのもあるし、初めて聞いたのもあったけど、頭に留めておこう。
- 一個流し
- 制約理論（TOC）
- ドラム・バッファー・ロープ
- クリティカルチェーン
- リーン開発
- 全体最適化
あえてやってるんだろうけど、同じような語り口・パターンでの説明が続いて、単調に＆ちょっと無理があるように感じた場面もちょいちょい。まあでもカンバンについて、別の視点から見るという意味でも、ちょい忘れかけてたことを再度確認するという意味でも、ちょうどいい1冊でした。
「ザ・コーチ」を読みました
購入のきっかけは、1on1などに組織的に対応するフェーズになってきたことで、今回2018年の年始目標を立てるのに読み返しました。
- 作者: 谷口貴彦
- 出版社/メーカー: プレジデント社
- 発売日: 2012/05/31
- メディア: Kindle版
- この商品を含むブログを見る
第2章 目標の達人への道
目標設定における、各言葉の定義とその関係性。細かいところはおいておいても、この図は関連を表すのにすごくわかりやすかった。合わせて、一番低レイヤの「目標」は具体化させるときには大事だけど、それだけではモチベーションがわかないので、「目的」や「ゴール」さらには「ビジョン」もセットで考える、というのはそうだよなあと。
第3章 価値ある恩恵
↑の「目的」や「ゴール」を明確にしておくと、どういう恩恵があるかどうかについて。色々触れられていたけど、この辺が今の自分にしっくりきたかな。
- 「目的」や「ゴール」に自然と意識が向くので、情報をキャッチしやすくなる・学習意欲が高まる
- 「目的」や「ゴール」に向かう過程で、選択力・決断力・集中力が増し、パフォーマンスが出やすくなる
確かに、この辺定期的に思い出さないと、すぐ忘れちゃうんですよね。
第5章 始まりの日
Q : 組織において部下にゴールを設定する時のポイントは何か？
A : 会社の目標と個人の目標の接点を見つけて共有する
Answer はもっともなことなんだけど、どこまで接点を見つけることができるんだろうというのは、ちょっと疑問にも残った。完全にトップダウンでの目標設定よりはもちろんましだけど、接点を見つけるにも見つけられないときもあるだろうし。まあそれがずっと続くようだったら、色々ミスマッチということでそもそも論になるので、そこまでいかないケースをできるだけ拾い上げるということかな。
第6章 真実が姿を現す時
行動計画表として、下記のようなものが例示されていた。こういうの、いいよね。全体像の中で、今どこまできているかが分かりやすい。今の自分はここまでは作ってないけど、機会を見て作ってみてもよさそう。
あと、目標設定時のTIPSとして、こういうのが。やった or やらないのTODOもではなく、状態を表す目標文にすべきとのこと。少し気をつけてみよう。
「たとえば、やるべきことを目標にしてしまうと、自分への問いかけは、『今日はやるべきことをやったか？』という閉じた質問になってしまいます。すると、その答えは、『やった』か『やれなかった』ということになります。これだと、発展や成長が感じられないと思いませんか？」」
「はい。確かにそうですね」
「本来の目標とは、作業を消化することではなく、効果的に行動したり、行動から学習したりするための指標です。目標を、目的やゴールに対する通過点や到達点だと考えれば、そのプロセスで自分に問いかける質問は、『今日、僕は目標に向けてどんなことをやったのだろうか？』とか『もっと効果的に進むためには、どうすればいいだろうか？』という開かれた質問になるのではないでしょうか。これこそが重要なのです。・・・」
第7章 自分に正直に生きる
<価値観を知るための言葉リスト> というのがあった。それで思い出したけど、持ち味カードというのを某コーチが使ってたのを見て、これ引き出しの一つとして使えそうだなーというのを改めて思い出したんだった。使い方見るに、1on1やチームビルディングの一環としても使えるし、採用基準作りなどにも使えそうなので、一度試してみようかしら。
最初読んだときはちょい期待はずれだったかなーと思ったけど、実践する際にはかなり参考になった本でした。タイトルにあるコーチのHowToというよりは、目標設定のやり方というのが大きなところ。これを、まずは自分の中でちゃんと消化しつつ、広げていけたらいいな。
あ、最後まで読んで、本の中で取り上げられたワークシートが公式サイトで公開されているのに気づきました。さくっと試すのに、今度機会があったら使ってみよう。
バリューストリームマッピングの本を読みました
正式名称は『トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!』ですが、言いづらいので、「バリューストリームマッピング（VSM）の本」ということでｗ
全体最適の概念をサポートするツールの一つとしての、バリューストリームマッピング。自分の立ち位置・ロール的に、個別最適ではなく全体最適を見据えて動く必要があり、ぜひとも身につけておきたいものの一つだったので、トヨタ生産方式なので製造業についてだけどこの本を購入しました。
トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!
- 作者: マイクローザー,ジョンシュック,Mike Rother,John Shook,成沢俊子
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2001/08/01
- メディア: 単行本
- 購入: 1人 クリック: 8回
- この商品を含むブログ (5件) を見る
VSMを知らない人は、こっちを読んでおくとざっくりどんなものかが分かりやすそう。DevOpsの文脈で語られてはいるけど、それ抜きにしても多分問題なく理解できる。
序文
序文から、大事なことが書いてあります。
1. チェンジ・エージェントを見つける
2. よいセンセイを見つける
3. 危機を利用して、会社全体を動機づける
しかし、ここで彼らはステップ 5 へ飛んでしまうのです。
5. 重要なテーマを選んですぐにムダ取りを始める
けれども、飛ばしてしまったステップ 4 は、実はもっとも重要なクリティカル・ステップなのです。
4. 全ての製品ファミリーについて最初から終わりまでの全体の「バリュー・ストリーム」のマップを作る
5. でのムダ取りによって個別最適な部分でのカイゼンは達成できるけど、それが全体最適につながるとは限らない。むしろ個別最適されていないところに在庫が溜まって流れがよどみ、フラストレーションを引き起こすかもしれない。なので、まずバリュー・ストリームから全体を眺める必要がありますよね、ということ。
Part III : バリュー・ストリームをリーンにするには？
つくりすぎ
「リーン開発の本質」を読みました - @ikikko のはてなブログで、『「作りすぎのムダ」＝「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがある』と紹介していたけど、ここでも同様のことがもうちょい具体例をあげて触れられています。
つくりすぎは、あらゆる種類のムダの原因になります。単に、過剰在庫とその中で眠るお金、という問題だけではありません。部品をまとめてつくったり買ったりすればそれを置いておかなくてはいけないし、置くためのスペースも必要です。置いてあれば運ばなくてはならず、そのために人も設備も必要になります。並びかえたり、修理したり、ということもあるでしょう。また、つくりすぎは欠品の原因にもなります。各工程が必要でないものをつくっているせいで忙しい、というのがその理由です。いま必要でないものをつくるのに人と設備を使っているが故に、余分な人と余分な設備能力が必要になっているのです。つくりすぎはまた、リードタイムも長くしてしまい、お客様の要求に対するフレキシビリティを弱めてしまいます。
製造業の話なので、ソフトウェア開発にそのまま当てはめられないところもありはします。在庫の保管スペース・設備とか持ち運びのコストなど、物理的なものは当てはまらないでしょう。ですが、一度着手すると完成するまでそれをメンテしないといけないとか（ステータスどういう状態になってる？とか、周辺コードの修正によるコンフリクトの解消作業とかとか）、あとちょっとで完成する他のものがあるのに今着手してるもののせいでなかなかそっちに手を出せないとか。
結局この辺も、自分の身の回りの個別最適ではなく、全体最適な視点でどこがボトルネックでそれを解消するには何が必要？を意識しないと抜け出せないので、やっぱりそこに落ち着くのかなーと。
ガイドライン #3：スーパーマーケットを使って、流れ化できない上流の生産をコントロールする
単純に流れ化できない工程において、後工程と前工程をつなぐ仕掛けとして、以下の二つが紹介されていました。
- スーパーマーケット
- 後工程がスーパーマーケット内の部品を必要なときに必要な分引き取り、前工程は引き取られた分だけ部品を補充する
- FIFOレーン
- ある程度量をしぼったキューを用意しておき、その範囲内であれば前工程から後工程に自由に出していいけど、キューの制限を超えた場合は前工程をストップする
二つの違い、正直いまいち分かってません。が、WIP の制限をつける / 後工程が pull 型でコントロールするというのは、いわゆるソフトウェア開発でのカンバンプロセスと一緒だよねという理解はできました。逆に、これやらないと、前工程の都合だけでどんどん作られて在庫が増えてしまい、作り過ぎのムダが発生するよねと。
ガイドライン #5：ペースメーカー工程で、異なる製品を少しずつ繰り返してつくる（機種ミックスを平準化する）
機種ミックスを平準化するということは、一定期間に異なる製品の生産を平らにならして配分することを意味します。たとえば、午前中にタイプAの全数を組み立てて、午後にタイプBの全数を組み立てる、ということをしないで、もっと小さな単位でAとBを繰り返しつくるのです。
この例みて、ちょっとエクストリーム過ぎると最初感じました。部分だけを見ると、明らかにまとめてやったほうが効率よくできそうに感じるので。だけど、部分最適を重視してバッチサイズを大きくしていくと、結局流れが淀んでしまってリードタイムが長くなる・全体最適に支障をきたすというのは、この本だけでなく色んなところで言われてることなので、そっち方面に倒すよう意識しないとなーと。
全般的に、製造業に対してはすぐにでも使えるぐらい細かくいい本だけど、ソフトウェア開発の文脈ではそのまま使うのはオーバースペックかもと感じました。タクトタイム*1をベースラインとして、秒単位での改善を目安としていくとかとか。ただ、全体の流れ = バリューストリームを見える化して関係者全員で共通認識を持ち、ボトルネックを解決していくというのは、ソフトウェア開発でもやっておくべきことかなと思ってます。
そういう意味では、冒頭に紹介した日本のDevOps変革を促進するバリューストリームマッピング：一般記事｜gihyo.jp … 技術評論社や、@ryuzee さんが以前ポストしていたバリューストリームマップの書き方などを参考にして、あとはやってみるぐらいから始めるのがいいのかな。コーチと自分で素振り的なのはやったことあるけど、やっぱ関係者巻き込まないと効果が薄いので、どっかでやりたいやりたい*2。
Jenkinsの診断サービス：Jenkins Advisor を試してみたよ
Jenkins Worldの1日目キーノートで発表された、Cloudbeesの新しいサービス「Jenkins Advisor」、せっかくなので試してみました。
これは、Jenkinsの稼働状況を診断して、レポートしてくれるサービスです。
設定はそんなに難しくないです。まあ大体Pluginのページに書いていますが。
- （ないならば）Cloudbees のアカウントを取得
- Pluginをいつもの手順でインストール
- 設定画面で、Cloudbeesのアカウントを入力
これだけで、あとは日次もしくは起動時に勝手にスキャンして、登録されてるメールアドレスに診断結果を送信してくれます。何かあやしいところがあれば、対応方法のリンクも一緒についてくる。動いてる状況も判断するのかな？時々だけ送信される指摘項目もあります。診断項目は、以下の4分類。
- Security
- Stability
- Performance
- Best Practice
減るものでもないし、入れておいて損はなさげな。特に、Stability / Performance などは、書籍や参考サイトだけでなく、実際の稼働状況を見ないと適切な診断を下せないこともあるだろうし、そのときの一つの参考情報として。
Jenkins World 2017 の感想
↑のブログでは伝えたい内容を絞るのと速報性を大事にして、Jenkins World自体の感想を後回しにしたので、こちらから。
主な目的
受賞式に出るというのも一つの目的ではあったのですが、それ以外では主にこの辺。
- 海外のカンファレンス（特にネットワーキングとかブースの）の雰囲気を感じ取る
- 現在の英語力を実感して、気合を入れる
どちらかというと、セッション自体はまあ少し優先度落とし目で。発表内容だけなら国内でも見ようと思えば見れるので、現地に行かないと味わえないことを中心に見てきたかった感じです。あと、僕そもそも国内でも旅行あまり得意じゃないので、観光のことはそれほど・・・
カンファレンス前日（8/29）
着いたら、まずはJenkinsコミッターのアンカンファレンスに顔出し。午前中からあってたみたいですが、僕が到着したのは16時ぐらいだったので、ほぼ終わりかけでした。
終わった後は、川口さんに話しかけると、他のコミッターを紹介するよと言われて、まずは近くにいたDocker社の人？Docker Pipeline Pluginの人？と一対一で話すことに。わーお。何話したっけな。「仕事何やってるの？どんな会社？」って聞かれたので、「ソフトウェアエンジニア時々プロジェクトマネージャー。Cacoo出してる会社で、他にはITSとかチャットとか、大体アトラシアンと似たようなサービスを提供してるよｗ」って答えた気が。で、その流れで、「ITSやチャットって何使ってる？」って聞いたら、「GitHubとかSalesforce、slackとhipchatと、あとはJenkinsコミュニティではIRCだよね、ははは」みたいな感じだった、はず。
で、「バッグとかもらった？もらってないなら持っていっていいよ」って言われて、ボストンバッグと帽子をゲットしてきました！
その後は、Blue Oceanのproduct manager？とGit？SCM APIの誰か？あまり覚えてないけど、その二人が話してるところに。「自分がメンテしてるBacklog Pluginを、GitHubやBitbucketみたいに、Blue Oceanに対応させたいんだけど、どうすればいい？」って聞いたけど、「よく分からないんで、IRCで聞いてみてよ」みたいな回答だった、多分。
で、その後は、Welcome Receptionで、スポンサーブース巡り。ブースの人英語はやーいと感じたけど、こっちがゲストなので何とか説明しようとしてくれる。なので、この機会にガンバった。なぜか、どこかのブースで昔日本の大学の英語教師をやってたって人がいたのですが、その人はさすが慣れてて、僕でも聞き取りやすく言わんとしてることも分かってくれました。
戦利品はこんな感じ。ステッカーは貼らない派なので、最低限だけしかもらってきてません。Tシャツは好きなので、なるだけ回ってきました。あとは、ハンドスピナーとかちょいちょい。
その後は、Autodeskで、国外から来た人とカンファレンススタッフの数名で、International Programに参加。日本からはテクマトリックスさんから2名きてたけど、ここで日本人で固まってもしょうがないので、到着後は基本別々に動いてました。Autodeskのギャラリー内には色々おもしろいものがあったので、それきっかけで "What is this?" "How do we use this?" って話しかけて、そこから "Where are you from?" "How many people do you use Jenkins in your team?" とか、定番の質問にもっていけたので、まだ話しやすかったです。
9時過ぎにあがって、1日目はこんな感じ。
カンファレンス1日目（8/30）
Morning Yoga が早朝6時からあったので、せっかくなので参加。5分前に行ったら先生入れて2名しかいなくて、どうしようかと焦った。結局10名弱来たけど。ホテルの中庭であって、ちょっと小雨も降ってて寒かった。写真は、今回用のヨガマット。
その後は、ちょっと落ち着いた後にbreakfastの時間。さすがというか、いっぱいあった。
で、ようやくキーノート。の前に、何かいっぱい手が込んでるCG映像が出てきた。ひとまず一つだけ。
最初は川口さんのキーノート。内容は、"Jenkins 1.0 ~ Jenkins 2.0 ~ Blue Ocean" に沿ってふりかえって紹介する感じ。
- Jenkins 1.0 : 最初は川口さんのチームで、Hudsonを使い始めるところから。まだこの時代は、特定のエンジニアの情熱ベースでCIを整備するところ。
- Jenkins 2.0 : プラグインを適切な組み合わせを自分で探してインストールする形から、ある程度プリセットされたのを提供する方式へ。複数あったFreeStyle Jobを1つのPipeline にしたり、Jenkinsを再起動しても適切な形でPipelineを再実行できたり。
- Blue Ocean : Blue Oceanのproduct managerから、非エンジニアも分かりやすいようなUI/UXを提供するものとして、Blue Oceanを提供しようとしてるよっていう説明。
その後は、CloudBees CEOのSachaのキーノート。Cloudbeesの提供してる有償のJenkinsサービスや、Accenture やらDockerやらAWSの人が出てきて話した後、CloudBees Jenkins Advisorというフリーの診断ツールがリリースされたよという報告。
あと、途中で多分VSMのこの画像が出てきて、VSMとJenkinsでのPipelineのマッピングみたいなのが紹介されてました。自分の中で二つが結びついてなかったけど、ちょっと考えると関連して考えるべきだよなーと思って、なるほどーと思った感じ。
キーノート終わったあとは、スポンサーブースをまた回ったり、セッション聞いたり。スポンサーブース回ってる途中で、ちょっとしたステージが用意されてるところで各スポンサーによる15分程度のデモが代わる代わる行われてて、それはいい設計だなあと思ってました。デモは多少離れたところからでも見えるように大画面ディスプレイが備えられていて、そのデモで気になればブースに聞きに行こうとなるので。
で、セッションの方ですが、致命的なことにほとんど聞けてません。。。時差ぼけ＆アルコール＆英語などでかなり眠くて、ちょっとセッション出てもすぐ意識が飛ぶ、疲れたのでソファに横になったら1時間以上寝てしまうとかとか。。。2泊しかしないという割りとタイトなスケジュールしか組めなかったのもあったのですが、今度からはもうちょい余裕持たないと、結局参加しても集中できずにもったいないなあという反省です。
ただ、セッションは、全体的にはそこまで国内と大差ないんじゃないかなーと、何となくな印象。サマリーとか、インフラテスト周りのセッションをちょっとだけ聞いて判断してるだけですが、日本でのユーザーカンファレンスの内容でも十分遜色ないんじゃないかなと、勝手な判断。次はぜひ日本からもスピーカー出るといいですね。
後は、2日目の終わりにまたスポンサーブースのところでReceptionという名のネットワーキング。前日とそう大差ない内容だったのと、ライブがあってうるさくて話もしづらかったので、ここではもう早めに切り上げました。こういうのがいいって人もいるだろうけど、話できないほど大音量での音楽はあまり好きじゃないんですよねー。
カンファレンス2日目（8/31）
Jez Humbleによるキーノート。どこかで聞いたことある名前だなと思ったら、"The DevOps ハンドブック"とか"リーンエンタープライズ"とか"継続的デリバリー"の著者ですね。継続的デリバリーしかまだ読んだことないけど、他の二つも読みたいと思ってたところでした。
Jez Humbleからは、Business / Engineering / Operationsという流れがあるフローの中で、Engineeringだけスクラムとかやってアジャイルになっても意味がないよ、周りも含めてアジャイルになっていかないとね、みたいなものを丁寧に説明してくれてました。この辺は、まあDevOpsとかの界隈ではよく言われてることだろうけど、それを改めて説明してくれて、知識のいい整理になった感じ。
よくまとまってたので、キーノート資料が公開されるとすごく助かるんだけど、まだ出てないみたいですね。
その後はお待ちかね、Jenkins World Awardsの授賞式です。streaming でうちの会社の人も何人か見ててくれたみたいですが、自分が初っ端でかなり緊張しました。
壇上降りてパシャリ。
その後は、またセッションとスポンサーブース巡り。セッションは、"Scaling Jenkins with Kubernetes"と"DevOps at Enterprise Scale"というやつを見に行きました。前者は、自分がついたあとはほぼデモで、何やってるか分かりやすかったけど、ちょい手際が悪く感じた。後者は、Hewlett Packard Enterpriseで作ってるALM Octaneというツールの紹介。Jenkinsと連携して動かすことができるのかな。自社ツールの紹介という時点で、ちょっと興味度が落ちました。
ブース巡りでは、Jenkinsのバスと撮るの忘れてたので、このタイミングで取りに行きました。写真待ちしてると、何人かが "Congraturations!"って言ってくれたのは、素直に嬉しかったですね。せっかくなので、"Thank you!"以外にもうちょい話膨らませられるとよかったのですが、力不足で叶わず。。
最後は、再度のInternational Programで、幾つかのテーブルに分かれてLunch食べながらフリートークをするというやつ。テーブルごとに、"Continuous deployment with Docker"とか"The Twelve-Factor Pipeline"とかお題があって、Cloudbeesの人がホスト役として各テーブルに座ってる中、興味があるお題のテーブルに座って話すというやつ。ここでは、"Plugin/upgrade stability"というテーブルに座りました。
で、これが最後の鬼門。数人でのフリートークなんて、英会話初心者にはかなりつらかった。1対1だと相手がまあだいぶ気遣ってくれてゆっくり話してくれたり何度も聞き直してくれたりするんだけど、数人で話されてると全然ついていけん。かつ、お題もちょっと難しかったので、自分が考えたこともうまく伝えられず、かなり凹みました。。。
帰り際には、グッズとして何故かサンダルをもらった。
カンファレンスは夕方まで続いてたのですが、飛行機の時間があったためにここで撤収。そういや、カンファレンス期間中、壁にペイントしていくエリアがあったのですが、帰るときにはだいぶできあがってました。
サンフランシスコの町並み
以前ハワイは行ったことあるのですが、これが初のアメリカ本土上陸でした。
JALを使ったのですが、機内でも有料のWifiサービスがあったので、その場で契約。雲の上から機内食とか撮ってつぶやいてました。一段落したら、チャット見たり先週のアクションのふりかえりしたり。まあいつも通りな感じです。
着いたら、BARTと呼ばれてる電車で、空港からホテルへ。土地勘まったくないけど、日本出国前にレンタルしていたモバイルWifi & Google Mapsの力を借りながら歩いていきます。着いた日は温度も低かったらしく、ちょっと寒いなあと感じた。写真は、BARTから撮った風景。もろボケです。
基本カンファレンスがあるホテルにこもりきり＆カンファレンスに参加してたので、ほとんど出歩く暇もなかったのですが、さすがにそれもあれかなと思って、2日目の夜にちょっとだけ出ました。サンフランシスコ、一歩路地間違うとかなり危険だよみたいな前情報があったので、かなりビクビクしながら。
授賞式のための身だしなみとしてのひげ剃りと、海外出たらその土地のソウルフードを食べたくなるのでラーメンを買い出しにコンビニへ。ラーメンが何か薄い気がしたのは、水入れすぎたかな？箸 or スプーンもらうの忘れてたので、インスタントコーヒーについてたストローらしきもので食べる羽目に。。
帰る日は、結構晴れて少し暖かった。路面電車なるものも走ってましたが、もちろん乗ってません。
空港に戻って、急遽海外に行くと決めて迷惑をかけた家族に対して、お土産購入。子どもには飛行機や電車のおもちゃを買ってきて、妻には一番単価が高いGODIVAの限定チョコレートを。こういうところで、ポイント稼ぎです。
あとは我が家恒例の、家族おそろいのTシャツ。一番下の子どもはイヤだといってきてくれませんでした＞＜
お金的なところは、ほとんどお土産になりました。ご飯はカンファレンスで朝昼晩ともにほとんど出るので、使ったお金は交通費とコンビニで、それでも多分30ドルぐらい。100ドルくらい？をなんやかんやのお土産になったので、お土産をもう少しコンパクトにできれば30ドルで暮らせた感じですね。
目的達成できた？どうだった？
すごくよかった、最高！と手放しで言えるほどではないですが、来てみていろいろ感じるものはあったなと思いました。例えて言えば、ディズニーランド的な非日常な世界を味わった感じ。
ネットワーキングパーティーやキーノートなど、カンファレンスの細部に対するコストのかけ方が違う。自分が携わったJenkinsユーザカンファレンスは基本ボランティアだったのでまあだいぶ違うし、いくつか出た日本の企業主催の大きなカンファレンスともちょっと違う気がする。もう一つ非日常感というか、スケールが違う感じ。一度こういうイベントのスタッフに携わってみたい。大変そうだけど。あと、いいなあと思ったのは、聴覚障害者のために手話で解説する人が準備されてた。
英語については、まあそうだよねというか案の定というか。カンファレンスに参加すると決めたのがお盆前ぐらいで、そっから焼け石に水程度かもとは思ったけどDMM英会話を始めたんですよね。で渡米前に10回以上レッスンやって、英語を話すことの抵抗感はだいぶ薄れてはいました。が、まあ実際カンファレンスで人と話すと、全然ついていけないですね。英会話の先生は拙い英語を聞くのもこっちに合わせてゆっくり話すことも慣れてるけど、まあ普通の人はね。
どこまでを目標とするかにもよりますが、英語はやっぱもうちょいやらんとよねと。せめて、こういう場でちゃんとコミュニケーションできるぐらいは。今後英語圏の人や文化と関わること多いだろう＆多くしていかないとだろうし。
カンファレンス自体については、Blue Ocean推しだなというのと、DevOps系のセッションがすごく多かったなという印象。自作プラグインをBlue Ocean対応させるのもやっておかんと、本体のトレンドについて行けなくなりそうだなーけどちょい大変そうだなー、という感じ。
こちらからは以上です。この勢いのまま、また勉強会とかユーザーカンファレンスもやりたいですね。他にも声があがるとより一層やるぞという決意が固まるので、やりたいーという人がいたらぜひぜひ声をあげてもらえると。
Jenkins World 2017 で日本のJenkinsコミュニティの代表として Most Valuable Advocate 賞をいただきました！
初めての海外カンファレンスとしてJenkins World 2017に参加し、何とそこで日本のJenkinsコミュニティの代表としてMost Valuable Advocateなる賞をいただきました！
Most Valuable Advocate
https://www.cloudbees.com/jenkinsworld/awards
This award is presented to an individual who has helped advocate for Jenkins through organization of their local Jenkins Area Meetup.
Your Contribution:
ikikko-san leads the Jenkins User Group in Tokyo, which is one of the largest and the most active with a long history. The group has been organizing meet-ups for more than 10 times now, and every meet-up fills up to 100% very qucikly with regular turn-out of 100-200 people. At one point the group under his leadership organized a fully volunter-run "Jenkins User Conference" in Tokyo that commanded 1000+ attendees.
Jenkins World自体については、また別途紹介させてもらうとして、ここでは取り急ぎ報告とお礼を。
( 2017/09/04 Jenkins Worldの感想を別エントリに書きました )
ikikko.hatenablog.com
今回の賞では、二度のJenkinsユーザカンファレンスを始めとして、日本のJenkinsユーザ会を取りまとめていた功績を評価してもらいました。もちろん、これは僕の力だけではなく、他のスタッフやユーザの方など、日本のJenkinsに関わる全ての方々の功績だと考えています。
思い返せば今から7年前の2010年10月。CIという概念やJenkins（当時はHudson）が徐々に知られるようになってきた状況での「日本でHudsonの勉強会をやりたいなと思うのですが」というメーリングリストへのポスト、ここから始まったのでした。
「1ダースもくれば大成功なんじゃないでしょうか」という川口さんの言葉とは裏腹に、蓋をあければ200人以上の参加！この会をきっかけに、僕も含めた日本のJenkins界隈がさらに加速したのではと、今思い返してみると感慨深いものがあります。
これからも、みんなの力でJenkinsやCI界隈を盛り上げていきましょう！みなさん、ありがとうございました！！
