「ザ・コーチ」を読みました
購入のきっかけは、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界隈を盛り上げていきましょう！みなさん、ありがとうございました！！
「ファシリテーション・グラフィック」を読みました
ミーティングの内容が同じところを堂々巡りしてたり、結局何を話してたんだっけってなったりで、なんとなーく空中戦が多いなと感じてたので。空中戦を避けて、議論を見える化するための引き出しの一つとして読んでみました。
ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)
- 作者: 堀公俊,加藤彰
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2006/09/01
- メディア: 単行本
- 購入: 22人 クリック: 124回
- この商品を含むブログ (117件) を見る
うちは拠点が分散してるのもあって、ホワイトボードを使うことは少なく、代わりにデジタルなツールを使うことが多いです。その辺は、下記のスライドでも紹介してました。距離が分散してる場所でも使えることや、ある程度定形のフォーマットがあるミーティング（例えば、ふりかえりのKPTなど）、きれいに整形して記録として残しておきたい・コピペ的な流用が多い場合は、デジタルツールはやはり便利ですね。
ただ、やっぱデジタルだと使うのに一手間かかることも多く、柔軟性がない。具体的には、フリーハンドでグリグリ書いたり何かと関連づけたりが、どうしても1テンポ遅れて、なんか思考に直結しないというのを感じてました*1。で、結局ツールを使うのにもたもたしてる間に、口頭で話進んでいって、しばらくすると空中戦になったりーの。
その辺を打開すべく、お世話になってる関西弁のコーチがよくホワイトボード使ってるのを見て、自分もやってみようと思ったのがきっかけ。まだまだ試行錯誤してる段階ですが、最近ではビデオ会議システムでホワイトボードを映して、僕がホワイトボードに話しながら書くのを別拠点の人に配信するというやり方もちょいちょいやってます。結局参加してるみんながホワイトボードに書くわけではないことが多いので、このやり方でも結構うまくいきますね。
第1章 基礎編 議論を書けば話し合いが変わる
発言の中の言葉を活かす
よくある失敗は、体言止めを使って一般的な用語に置き換えてしまうケースです。たとえば「そもそも、この商品が持っている機能が、狙っていた顧客層になっていないのではないでしょうか？」という発言を「商品コンセプトの問題」と要約してしまうのです。
...
なるべくメンバーが使った言葉をそのまま使い、キーワードをうまくつなげて要約文をつくりましょう（例：機能がユーザーに合っていない？）
あ、これ前までよくやりがちでした。きれいにまとめようとして、いい感じの言葉に置き換えようとしてしまうんですよね。けど、この箇所を読んでから、ちゃんと発言そのまま活かして、疑問形ならば「？」をつけることで表すようになりました。
Column-3 準備してきたものを手放す勇気を持とう
ファシリテーターともなれば、前もって議論の展開を考え、使えそうなツールを思い描いて場に臨むのは当たり前の話です。だからといって、それを会議が始まるなり押し付けるのは、あまり関心しません。
...
事前の準備は大切ですが、用意してきたものを使うかどうかは、場の状況を見て決めるものです。人はどうしても準備してきたものを使いたくなりますが、それを潔く手放す勇気を持ってください。
これも、最初のほうは自信のなさからよくやってた気がします。が、今はある程度経験を積んだのをふまえて、頭の中に思い描いた道筋はあるものの、まずは相手の疑問や話したいことを話してもらうというのをやれるようになってきました。相手が特に話したいことがなかったり、自分が思い描いたものと同じ方向性ならば、準備どおりに進められるし、別の方向にいったのであればそれはそれで有意義な方向なのでそれを尊重しつつ議論を進めるように（頭の中はかなりフル回転してますが）。
第2章 技術編 ファシリテーション・グラフィック上達の6つのポイント
この章はテクニック的な話。いくつかあるのですが、知っておくだけで簡単に活かせるのは、この辺かな。
見やすい字を確認は、ゴシック体を意識して書くのがコツです。四角のマスに字を埋めていくつもりで書いていくのです。大半の人は四角ばった文字を書くと安定した感じになります。
...
ペンの太いほう（太字角芯）を使って字を書くようにしてください。
...
基本は「横線を細く、縦線を太く」です。そうすると、安定した文字に見えます。そのためにはペンを図2ｰ17のように持ち、ペン先の角をうまく使って横線／縦線を描くようにしてください。字の上手下手ではなく、書き方のちょっとした気配りで、とても読みやすくなるのです。
図がないので、ここだけ読んでもいまいちぴんと来ないでしょうが、ともかく「両方とも細い部分で書かないように」「横線描くときは細く、縦線描くときに太く」なるようにペンを握ります。実際にやってみたイメージは↓な感じ（左が意識した方で、右が今までの書き方）。学生の頃から、自分で書いたノートが汚くて読めない自分が、これ意識するだけで「字が見やすい」と言われるようになっちゃいましたｗ
あとは、色の使い分けの指針とかも。感覚では何となく分かっていたものの、こうやって明記されると判断しやすいです。
- <黒> 大半の文章や図解を描く
- <赤> 重要なタイトルを枠で囲む、重要なキーワードに下線を引く、特に注意を引きたい文を描く
- <青> 少し目立たせたい文を書く、囲み図形を描く
- <緑> 補足事項を書く、囲み図形を描く
他には、箇条書きや囲み・矢印・つなぎ方など、単調になりがちなところをいくつか例示してるところが参考になりました。一度素振りしてたけど、もうちょっと定着させてぱぱっと出せるようになるために、また素振りしとこうかな。
第4章 研究編 ファシリテーターの頭の中を解剖する!?
説明しづらいけど、この章はかなり参考になる。最終的にできあがったホワイトボードや模造紙だけでなく、議論の流れと一緒に描いてる途中経過も説明しながらどういう流れでできあがったかを、幾つかのサンプル事例を見せてくれる章。
パーキングロット
色々参考にはなったのですが、やっぱりというか「パーキングロット」の技は使えるなという印象。
あまり今の議論に関係なさそうなやつを隅の方に一応書き留めておくやつですが、こうやっておくと本来議論したいところに戻ってきやすいってのは、結構経験しています。それでいて、発言者もまったく流されたわけじゃないという受け止めができるので、結構オススメ。
ゴールの明示
ゴールがどこまでか設定してなくて、結局終了時間になっても何も決まってない、ってのをよくやりがち。予めゴールは考えておいて、それを明示しておきつつ共通認識を合わせるっての大事。
逆に、ゴールをちゃんと決めておけば、時間がこなくてももうさくっと終われる。これ、精神衛生上にもいいんですよね。もちろん、時間をムダにしないっていう点でも。
ファシリテーターって誰でもできる？
で、この章見ながら感じたのですが、ファシリテーションはある程度スキルがいりそう。聴きながら、描いていく。分かりやすくするためには多少なりとも描き方にコツがいるし、シミュレーションなど事前準備も結構大事。これを、メンバーでやるのっていけるんだろうか？まあ最初はやっておいて、やり方見せていけばだんだんできるものなのかな？
まあ、0か1か、いつもファシリテーターがいる or いらないというものではないですね。ある程度込み入ったミーティングになりそうな場合は、別途慣れた人がファシリテーターとして入って（今の状況だと多分自分）、そうじゃない定例的なものは他の人でもできるようにしていくのが健全そう。
ある程度想定の上で読んだのですが、今の自分にとってはテクニック寄りな内容が多かったです。テクニック系は、状況にはまれば即効性は高いので、使い所を間違わないように活用していきたいですね。
実際に、この本の内容を実践した後、「ホワイトボードの字がきれいですね」って言われたことがありました。自分が取ったノートすら、字が汚くて後から読めないこの僕がですよ。それだけでも、効果のほどは分かるんじゃないかと。
「アジャイルコーチング」を読みました
原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。
- 作者: Rachel Davies,Liz Sedley,永瀬美穂,角征典
- 出版社/メーカー: オーム社
- 発売日: 2017/01/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
第1章 旅を始める
「エクササイズ：コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。
- 動機：自分はどのような変化をもたらしたいのか？
- 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
- スキル：自分は何を提供すべきか
- （他チーム・他社のベストプラクティスを含め）メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
- 責任：仕事の進捗をどうやってレビューすればいいか
- 以前よりチームとして成果を出せていること
- （のためには、成果って何？とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・）
- 支援：周りからどのような支援が受けられるか
- 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる
第2章 みんなと一緒に働く
「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。
ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。
権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。
第3章 学習を促す
質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。（略）たとえば「このバグをもっと早く見つけるにはどうしたらいい？」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。
あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。
とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。
ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。
第5章 デイリースタンドアップ
「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。
ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。
朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。
第6章 何を作るかを理解する
ユーザストーリーの作り方や、ストーリーテスト（受け入れ基準）の話。ストーリーテストのテンプレートとして、 Given-When-Then（前提 - もし - ならば ） という形が紹介されていました。ってこれ、BDDで見たパターンだ。
以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given（前提）とWhen（もし）の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。
いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。
第7章 前もって計画する
午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。
このやり方、よさげ。機会あれば提案してみようかしら。
あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。
書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。
(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)
@ikikko 書記のところは、コーチやスクラムマスターみたいな人がホワイトボードのペンを持ってしまう、みたいなことです。その人が場をしきる感じになってしまい、チームのための会議という感覚が薄まってしまうので、できれば避けたいところです。
— 角征典／新刊『アジャイルコーチング』 (@kdmsnr) 2017年5月8日
第8章 見える化する
この章、目下の課題。
うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。
まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。
第13章 ふりかえりで変化を推進する
ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。
スーパー雑に、ふりかえり・カイゼンとやる必要があること（タスク）や、大きな目標について、自分の今の理解を書いてた pic.twitter.com/4cPETpKns7
— ikikko (@ikikko) 2017年5月4日
第14章 あなたの成長
この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。
例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。
コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。
あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。
自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの？」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの？」
「それは・・・」
それに続く理由は山のように浮かんだわ。
（うまくやらなくてはいけないから。）
（明らかなミスをするのは恥ずかしいことだから。）
（もっとうまくやりたいから。）
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら？
途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。
ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・
