Jenkins World 2017 で日本のJenkinsコミュニティの代表として Most Valuable Advocate 賞をいただきました!

初めての海外カンファレンスとしてJenkins World 2017に参加し、何とそこで日本のJenkinsコミュニティの代表としてMost Valuable Advocateなる賞をいただきました!

f:id:ikikko:20170901032423j:plain
f:id:ikikko:20170901032441p:plain

Most Valuable Advocate
This award is presented to an individual who has helped advocate for Jenkins through organization of their local Jenkins Area Meet­up.

https://www.cloudbees.com/jenkinsworld/awards

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の勉強会をやりたいなと思うのですが」というメーリングリストへのポスト、ここから始まったのでした。

f:id:ikikko:20170826211129p:plain
f:id:ikikko:20170826211146p:plain
f:id:ikikko:20170826211159p:plain

1ダースもくれば大成功なんじゃないでしょうか」という川口さんの言葉とは裏腹に、蓋をあければ200人以上の参加!この会をきっかけに、僕も含めた日本のJenkins界隈がさらに加速したのではと、今思い返してみると感慨深いものがあります。


これからも、みんなの力でJenkinsやCI界隈を盛り上げていきましょう!みなさん、ありがとうございました!!

「ファシリテーション・グラフィック」を読みました

ミーティングの内容が同じところを堂々巡りしてたり、結局何を話してたんだっけってなったりで、なんとなーく空中戦が多いなと感じてたので。空中戦を避けて、議論を見える化するための引き出しの一つとして読んでみました。


うちは拠点が分散してるのもあって、ホワイトボードを使うことは少なく、代わりにデジタルなツールを使うことが多いです。その辺は、下記のスライドでも紹介してました。距離が分散してる場所でも使えることや、ある程度定形のフォーマットがあるミーティング(例えば、ふりかえりのKPTなど)、きれいに整形して記録として残しておきたい・コピペ的な流用が多い場合は、デジタルツールはやはり便利ですね。

speakerdeck.com

ただ、やっぱデジタルだと使うのに一手間かかることも多く、柔軟性がない。具体的には、フリーハンドでグリグリ書いたり何かと関連づけたりが、どうしても1テンポ遅れて、なんか思考に直結しないというのを感じてました*1。で、結局ツールを使うのにもたもたしてる間に、口頭で話進んでいって、しばらくすると空中戦になったりーの。

その辺を打開すべく、お世話になってる関西弁のコーチがよくホワイトボード使ってるのを見て、自分もやってみようと思ったのがきっかけ。まだまだ試行錯誤してる段階ですが、最近ではビデオ会議システムでホワイトボードを映して、僕がホワイトボードに話しながら書くのを別拠点の人に配信するというやり方もちょいちょいやってます。結局参加してるみんながホワイトボードに書くわけではないことが多いので、このやり方でも結構うまくいきますね。

第1章 基礎編 議論を書けば話し合いが変わる

発言の中の言葉を活かす

よくある失敗は、体言止めを使って一般的な用語に置き換えてしまうケースです。たとえば「そもそも、この商品が持っている機能が、狙っていた顧客層になっていないのではないでしょうか?」という発言を「商品コンセプトの問題」と要約してしまうのです。

...

なるべくメンバーが使った言葉をそのまま使い、キーワードをうまくつなげて要約文をつくりましょう(例:機能がユーザーに合っていない?)

あ、これ前までよくやりがちでした。きれいにまとめようとして、いい感じの言葉に置き換えようとしてしまうんですよね。けど、この箇所を読んでから、ちゃんと発言そのまま活かして、疑問形ならば「?」をつけることで表すようになりました。

Column-3 準備してきたものを手放す勇気を持とう

ファシリテーターともなれば、前もって議論の展開を考え、使えそうなツールを思い描いて場に臨むのは当たり前の話です。だからといって、それを会議が始まるなり押し付けるのは、あまり関心しません。

...

事前の準備は大切ですが、用意してきたものを使うかどうかは、場の状況を見て決めるものです。人はどうしても準備してきたものを使いたくなりますが、それを潔く手放す勇気を持ってください。

これも、最初のほうは自信のなさからよくやってた気がします。が、今はある程度経験を積んだのをふまえて、頭の中に思い描いた道筋はあるものの、まずは相手の疑問や話したいことを話してもらうというのをやれるようになってきました。相手が特に話したいことがなかったり、自分が思い描いたものと同じ方向性ならば、準備どおりに進められるし、別の方向にいったのであればそれはそれで有意義な方向なのでそれを尊重しつつ議論を進めるように(頭の中はかなりフル回転してますが)。

第2章 技術編 ファシリテーション・グラフィック上達の6つのポイント

この章はテクニック的な話。いくつかあるのですが、知っておくだけで簡単に活かせるのは、この辺かな。

見やすい字を確認は、ゴシック体を意識して書くのがコツです。四角のマスに字を埋めていくつもりで書いていくのです。大半の人は四角ばった文字を書くと安定した感じになります。

...

ペンの太いほう(太字角芯)を使って字を書くようにしてください。

...

基本は「横線を細く、縦線を太く」です。そうすると、安定した文字に見えます。そのためにはペンを図2ー17のように持ち、ペン先の角をうまく使って横線/縦線を描くようにしてください。字の上手下手ではなく、書き方のちょっとした気配りで、とても読みやすくなるのです。

図がないので、ここだけ読んでもいまいちぴんと来ないでしょうが、ともかく「両方とも細い部分で書かないように」「横線描くときは細く、縦線描くときに太く」なるようにペンを握ります。実際にやってみたイメージは↓な感じ(左が意識した方で、右が今までの書き方)。学生の頃から、自分で書いたノートが汚くて読めない自分が、これ意識するだけで「字が見やすい」と言われるようになっちゃいましたw

f:id:ikikko:20170528113718j:plain

あとは、色の使い分けの指針とかも。感覚では何となく分かっていたものの、こうやって明記されると判断しやすいです。

  • <黒> 大半の文章や図解を描く
  • <赤> 重要なタイトルを枠で囲む、重要なキーワードに下線を引く、特に注意を引きたい文を描く
  • <青> 少し目立たせたい文を書く、囲み図形を描く
  • <緑> 補足事項を書く、囲み図形を描く

他には、箇条書きや囲み・矢印・つなぎ方など、単調になりがちなところをいくつか例示してるところが参考になりました。一度素振りしてたけど、もうちょっと定着させてぱぱっと出せるようになるために、また素振りしとこうかな。

f:id:ikikko:20170528114827j:plain

第4章 研究編 ファシリテーターの頭の中を解剖する!?

説明しづらいけど、この章はかなり参考になる。最終的にできあがったホワイトボードや模造紙だけでなく、議論の流れと一緒に描いてる途中経過も説明しながらどういう流れでできあがったかを、幾つかのサンプル事例を見せてくれる章。

パーキングロット

色々参考にはなったのですが、やっぱりというか「パーキングロット」の技は使えるなという印象。

あまり今の議論に関係なさそうなやつを隅の方に一応書き留めておくやつですが、こうやっておくと本来議論したいところに戻ってきやすいってのは、結構経験しています。それでいて、発言者もまったく流されたわけじゃないという受け止めができるので、結構オススメ。

ゴールの明示

ゴールがどこまでか設定してなくて、結局終了時間になっても何も決まってない、ってのをよくやりがち。予めゴールは考えておいて、それを明示しておきつつ共通認識を合わせるっての大事。

逆に、ゴールをちゃんと決めておけば、時間がこなくてももうさくっと終われる。これ、精神衛生上にもいいんですよね。もちろん、時間をムダにしないっていう点でも。

ファシリテーターって誰でもできる?

で、この章見ながら感じたのですが、ファシリテーションはある程度スキルがいりそう。聴きながら、描いていく。分かりやすくするためには多少なりとも描き方にコツがいるし、シミュレーションなど事前準備も結構大事。これを、メンバーでやるのっていけるんだろうか?まあ最初はやっておいて、やり方見せていけばだんだんできるものなのかな?

まあ、0か1か、いつもファシリテーターがいる or いらないというものではないですね。ある程度込み入ったミーティングになりそうな場合は、別途慣れた人がファシリテーターとして入って(今の状況だと多分自分)、そうじゃない定例的なものは他の人でもできるようにしていくのが健全そう。


ある程度想定の上で読んだのですが、今の自分にとってはテクニック寄りな内容が多かったです。テクニック系は、状況にはまれば即効性は高いので、使い所を間違わないように活用していきたいですね。

実際に、この本の内容を実践した後、「ホワイトボードの字がきれいですね」って言われたことがありました。自分が取ったノートすら、字が汚くて後から読めないこの僕がですよ。それだけでも、効果のほどは分かるんじゃないかと。

*1:ちなみに、ホワイトボードではないけど、似たような役割のものに付箋があると思ってます。以前あった例では、Google spreadsheetでプロダクトバックログ的なのを書いて議論しようとしてたのですが、頭にはいってこないこない。で、全部付箋に書き出して、それを順番入れ替えたり別の付箋でグルーピングしたりしながら話出すと、かなり頭が整理されて一気に話が進んだということもありました。

「アジャイルコーチング」を読みました

原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。

アジャイルコーチング

アジャイルコーチング

第1章 旅を始める

「エクササイズ:コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。

  • 動機:自分はどのような変化をもたらしたいのか?
    • 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
  • スキル:自分は何を提供すべきか
    • (他チーム・他社のベストプラクティスを含め)メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
  • 責任:仕事の進捗をどうやってレビューすればいいか
    • 以前よりチームとして成果を出せていること
    • (のためには、成果って何?とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・)
  • 支援:周りからどのような支援が受けられるか
    • 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる

第2章 みんなと一緒に働く

「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。

slide.meguro.ryuzee.com

ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。

権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。

第3章 学習を促す

質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。(略)たとえば「このバグをもっと早く見つけるにはどうしたらいい?」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。

あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。

とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。

ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。

ikikko.hatenablog.com

第5章 デイリースタンドアップ

「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。

ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。

朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。

  • 朝からの流れでその日の状況をある程度推測しつつ、問題起こりそうなのを検知・対応できるように
    • 対応悩んで時間かかりそうなものを、デイリースタンドアップ後に相談したり
    • 立て込んでキャパオーバーになりそうな場合、適切に他チームなどにエスカレーションしたり
  • 昼に一度作業の流れを切ることによって、立ち止まって状況を整理する機会を提供
    • 合わせて、デイリースタンドアップ前に 2,3 分程で状況を俯瞰できる問い合わせボードを更新
    • 定期的に整理する場があると、日々の作業にズルズル流されることなくボードを最新に追随できる

第6章 何を作るかを理解する

ユーザストーリーの作り方や、ストーリーテスト(受け入れ基準)の話。ストーリーテストのテンプレートとして、 Given-When-Then(前提 - もし - ならば ) という形が紹介されていました。ってこれ、BDDで見たパターンだ。

以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given(前提)とWhen(もし)の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。

いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。

第7章 前もって計画する

午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。

このやり方、よさげ。機会あれば提案してみようかしら。

あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。

書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。

(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)

第8章 見える化する

この章、目下の課題。

うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。

まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。

ikikko.hatenablog.com

第13章 ふりかえりで変化を推進する

ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。


第14章 あなたの成長

この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。

例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。

コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。

あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。

自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの?」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの?」
「それは・・・」
それに続く理由は山のように浮かんだわ。
(うまくやらなくてはいけないから。)
(明らかなミスをするのは恥ずかしいことだから。)
(もっとうまくやりたいから。)
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら?


途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。

ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・

docs.google.com

*1:スクラムマスター、だとスクラムに限定されそうな感じがして、ちょっと狭い

「リーン開発の本質」を読みました

何か発想の転換になりそうなので、「リーンソフトウェア開発」はちゃんと突き詰めていきたいところ。というわけで、次はこれを読んでみました。

リーン開発の本質

リーン開発の本質

そもそもなのですが、リーンソフトウェア開発が全体の中でどういう位置づけかが曖昧だったので、そこから。「リーン」と「アジャイル」の関係とは?:書籍でたどる「リーン」の本質 (3/4) - @ITの以下の画像が、分かりやすかったです。

http://image.itmedia.co.jp/ait/articles/1311/15/hu_tt_aja01.jpg

第2章 原則

検証時の欠陥発見は、当然ではなく、例外であるべきだ。検証がいつも「テストをしては修正する」というサイクルを生むようなら、それは、開発プロセス自体に欠陥があるということである。

欠陥は早め早めに(理想的には作るそばから自動的に)発見・対処できるように、プロセスを作り込んでいくべきだってことですね。思い当たるふしがあったので、今後の参考に。

第3章 価値

トヨタでは、チーフエンジニアがその車種のビジネス上の成功責任を持つ。

(中略)

チーフエンジニアを立てるという手法には、多くの情報を、責任ある一個人の頭の中で統合できるというメリットがある。

「チーフエンジニア」について。以前は、どちらかというとこういうリーダー的なのは不要ではと考えてました。チームメンバーがチームが達成すべきことなどを適切に把握してたら、リーダーはいなくとも進むだろうと。ただ、この本で説明されてた下記の理由を読んで、やっぱりリーダー的な役割はあったほうがいいかなとも思ってきました。

  • 結果責任・説明責任を明確にできる
  • 一個人の頭の中で、多くの情報を統合できる

あと、知らずに何となく感じてたことですが。チーフエンジニアって、スクラムで言うところのプロダクトオーナーみたいな役割に似てるなーと思ってたら、やっぱり関連があったとのことです(参考:株式会社戦略スタッフサービス)。なるほどー。

第4章 ムダ

複雑さを自動化するな

複雑なプロセスや、乱雑なプロセスをただ単に自動化したところで、顧客の役には立たない。ソフトウェアのもつ複雑さというがちがちのよろいで、ムダだらけのプロセスをつつむようなものである。

う、頭が・・・>< CIやビルド周りに興味があるくらいなので、自動化は好きなのですが、これはそうだよねー。

続いては、ムダの話。これは有名な話ですよね、多分。リーン生産とリーンソフトウェア開発の対応表はこちら。

製造 ソフトウェア開発
在庫のムダ 未完成の作業のムダ
作りすぎのムダ 余分な機能のムダ
加工そのもののムダ 再学習のムダ
運搬のムダ 引き継ぎのムダ
動作のムダ タスク切り替えのムダ
手待ちのムダ 遅れのムダ
不良を作るムダ 欠陥の無駄

いくつか、対応付けがいまいち分かってないところもあります。「加工そのもののムダ」に相当するものが「再学習のムダ」だったり。ただ、「作りすぎのムダ」=「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがあるというのと、(対応付けは分かってなくとも)ソフトウェア開発のムダに紹介されてるもの自体はその通りなので、ひとまずはそれらのムダを意識して見つけることができるようにというところからかな。あとは、カンバンにも表れてるけど、「在庫のムダ」=「未完成の作業のムダ」らへん。

あと、バリューストリームマップ。これは、カイゼンの基本 | Ryuzee.com (on Azure)で紹介されてたこの本を読んで、別途やってみようと思ってます。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

第5章 スピード

要望やタスクを管理する「待ち行列」について。

  1. 待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サイクルタイムを管理できる。
  2. マネジャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、いったんチームがある項目に着手したら、マネジャーが日々の開発作業に干渉してはならない。
  3. チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えていられるのだ。
  4. 待ち行列ありさえすればチームに対応する時間がなくても、そのうち要求に対応してもらえる、という誤解を与えてはならない。

特に、1, 2が気になりました。1 は、無限待ち行列になってるのをよく見かけますよね。。。意識して制限しないとそうなりがちなのですが、無制限だと全体が見えづらく改善ポイントが分かりづらいとか、待ち行列を見るだけでいやになるとか、あとはリズムが出ないとかも結構大きいことかも。2 は、仕掛り始めたものをやっぱりやめたってなると、これまたリズム出ないしなかなか終わらない=価値の提供が遅れますしね。

とここまで書いてきて、これ見たことある、カンバンの原則だー!って気づきました。カンバンはリーンの考えから影響受けてるっていってましたしね。自分の読書感想ブログも含めて、本も改めて見直しておこう。

ikikko.hatenablog.com

第7章 知識

この章では、「顧客要求にもっと応えたい」というチームにおける例をふまえて、科学的方法の進め方が説明されています。科学的方法とは、こんな感じ。

  1. 問題を定義する
  2. 状況を分析する
  3. 仮説を立てる
  4. 実験を行う
  5. 結果を検証する
  6. フォローアップする / 標準化する

この中で、3 の「仮説を立てる」が「科学的方法の要でありながら、問題解決を急ぐチームが見落としてしまいがち」とされています。これ、すごい分かる。ちゃんと意識しておかないとだめですね。

ここの例、すごく参考になるので、多分今後何度も見直すんだろうなあ。

第9章 パートナー

オープンソースでのセキュリティフィックスをグローバルにまたがった複数のチームで対応した話と、トヨタ傘下のサプライヤの工場が火事になったときに別のサプライヤが協力して大本の発注を無事に納品した話。その中で、何がキーポイントだったのかというのが、↓な感じで説明されています。

よく、どうすれば世界規模のチームでのコミュニケーションを改善できるか、という質問を受ける。しかし、たいていの場合、根本的な問題はコミュニケーションではなく、約束を取り交わしたチームの不在なのだ。

なるほどね。約束を取り交わすことが第一で、その約束を果たすために必要ならばコミュニケーションの話になる、とのこと。多分その約束も、お互いがちゃんとやるべきことを把握できるレベルでの約束が大事な気がする。何となくとか、いい感じでお願いね♪みたいな曖昧なものだと、多分正しく機能しないんだろうな。

あと、コラムにあった「グローバルな作業グループから、グローバルなチームへ」っていうTIPSも、すごく参考になる。目次と簡単に一言で説明。

  1. 頻繁な統合:コードベースでの統合とか
  2. 人の交換:一方のチームメンバーを、もう一方のチームに送って一緒の時間を過ごす
  3. テストを交換する:要求を引き渡す際、実行可能なテストでやり取りする
  4. 窓口(Proxy):窓口となって、毎日コミュニケーション
  5. 動き回るチームリーダー:各地のチームを、チームリーダーが動き回る
  6. 差別の撤廃:言語や立場などの違いは、真のチームワークに欠かせない尊敬や信頼や約束を簡単に破壊する

第10章 旅立ち

どこからリーンソフトウェア開発を始めるかについて。「訓練」「思考」「計測」とありますが、計測が特に気になりました。

「開発作業が終了してからしばらくたたないと、効果的な計測は難しい -> たくさんの部分最適から着手してしまう」という流れが紹介されてましたが、これだと全体最適を阻害する可能性もあるのでだめだとのこと。代わりに、計測対象を減らして、(サブシステムではなく)システムレベルでの計測点を見つけるのがいいよと。具体的には、この辺。

サイクルタイムは、コンセプトがキャッシュになるまで。これを見るだけで、あらゆるムダが露呈するので、リーン手法の一番基本的な計測対象となる。

財務上の成果は、まあそのまま。開発(やもろもろの作業)がどう財務・ビジネスに紐づくか、当然意識して計測できるようにしておくべきだとは思ってるのですが、現実なかなか難しいなあと。ビジネスレベルまでいくと、開発者の作業以外の要素も絡んできそうなので。もちろん、最終的にはここに行き着くべきだけど、一歩目はもうちょいやりやすいところからかなーと。

顧客満足度は、こういう簡単な指標で出せるみたい。

「あなたの製品を、どれだけ薦められますか?」そして、顧客に0(薦めない)から10(絶対に薦める)までの点数をつけてもらう。その回答を、9~10点は「推奨者」、0~6点は「批判者」7~8点は「中立者」としてグループ分けする。

...

推奨者の正味比率を算出するには、推奨者の割合(パーセント)から批判者の割合を引く。すると、マイナス100パーセントから、プラス100パーセントまでの数字が出る。平均的な企業なら、点数は10パーセント」前後である。本当に優秀な企業であれば、50パーセントからそれ以上の点数が出る。マイナスになったら、深刻な問題につながると思った方がよい。

簡単なのはいいけど、実際にこのデータが手元にあった場合、どう活かせばいいのかはちょっとイメージできていない。傾向を継続的に見ていって、傾向が変わったタイミングで何かを検知するとか。もしくは、何かアクション起こす前に傾向がどう変わりそうかを仮説立てておいて、アクション後にその仮説を検証するとかかなあ。


一度通して読んだ後、この読書感想ブログを書くために再度読み直したのですが、この辺がいいなと感じたのかなと改めて。忘れがちなので、適宜また戻ってこようと思います。

  • スクラムなどの開発チーム・プロジェクトにフォーカスするだけでなく、(バリューストリーム(マップ)をはじめとして)より上位の全体システムを見据えた最適化をはかれそう
  • うっかりするとバッチサイズを大きくして一度に効率よく作業しようとなるところを、逆にバッチサイズを小さくしてサイクルタイムをよくすることを心がける

それにしても、いつにもまして長い・・・

「アジャイルサムライ」を読みました

これも定番中の定番ですが、特にプロジェクトキックオフ時の取り組みに関してインセプションデッキを追求したくて、読もうと思いました。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

第3章 みんなをバスに乗せる

はい、インセプションデッキの章です。

今までも、プロジェクトの概要や目的を明文化するような取り組みとして、"インターナルプレスリリース"という取り組みを社内でやってきていました。これは、Amazon流の開発術では、まずプレスリリースを作る | fladdictに習って、先にプレスリリースを書いてみるというものです。ただ、インセプションデッキを試した後に気づいたことは、「インターナルプレスリリース作成前に、プロジェクトメンバーみんなで認識を合わせる場があったら、もっとよりよくできたのかもしれない」ということです。

インターナルプレスリリース

インターナルプレスリリースは、以下の流れで作成していました。

  1. ある一人が、プロジェクトの概要をプレスリリースとして明文化する作業を行う
  2. 明文化したものを、プロジェクト内外に共有する
  3. フィードバックを受けて、ブラッシュアップする

インターナルプレスリリースの目的の一つに、「プロジェクト外の人に、プロジェクトの概要を周知するため」がありました。これは、会社が大きくなっていくにつれて、他のプロジェクトが何をやっているのかが分かりづらくなってきたという課題を解決するものです。インターナルプレスリリースによって、実際にプロジェクト外の人が該当のプロジェクトの概要を分かるようになりました。

ただ、インターナルプレスリリースを続けていくに従って、以下の点が問題点・改善できそうな点としてあがってきました。

  • プロジェクトの概要を明文化するのは思いのほか難しく、一人で考えていると煮詰まってしまう
  • プロジェクトメンバーでさえも、プレスリリースを眺めても深く入ってこない

上記の課題に、インセプションデッキ作成はぴったりはまりました*1。プレスリリースとして明文化する作業の前にインセプションデッキ作成を行っておくと、「プロジェクトメンバーが、プロジェクトの概要や目的をより深く認識・共有する」ことができるようになります。その前提だと、デッキを作成するときに話した内容を元にインターナルプレスリリースを作成することができます。これによって、プレスリリース作成者が煮詰まることが少なく、多少煮詰まっても他メンバーと相談していくことができます*2

テンプレート化 on Cacoo

インセプションデッキを実際に作ってみると想像以上によかったのですが、ちょっとだけ手間がかかるところがありました。当初、本書のサポートサイトで配布されているテンプレートを使ってたのですが、更新が入るたびに毎度更新して、ファイルサーバ上に置きつつチャットにキャプチャ貼って・・・みたいなことをやってたんですよね。

で、こういう手間を無くすために、うちらはCacooというサービスを作っていたのでした。というわけで、インセプションデッキもCacoo化して、合わせて社内の他のプロジェクトでも手軽に利用できるようにテンプレート化。

多分このままだと、見ることはできても社外の人はコピーして流用するのはできなさげですが、欲しい人がいたらコメントか何かもらえると。コピーできるように、もうちょい設定します*3


第4章 全体像を捉える / 第5章 具現化させる

インセプションデッキの中でも、うちらの中では以下の2つが重要だなと実感しています。

  • 我々はなぜここにいるのか?
  • エレベーターピッチ

「なぜ」これを作るのかという問いだと思いますが、エンジニア目線だとどうしてもこの辺が疎かになってしまうことがあります。結果として、何の役に立つのか・誰に向けた機能なのかがゆるふわになったり、当初のスコープより想定以上に膨らんだりしちゃいます。「なぜ」をプロジェクト初期にちゃんと考え抜いて、何かあったときにまたこの場所に戻って来れるようにしておくことは、当たり前といえば当たり前ですが大事なことですよね。

あとは、「パッケージデザイン」が上記のインターナルプレスリリースのたたき台に使えるんじゃないかとか、「やらないことリスト」「トレードオフスライダー」でプロジェクトで重要視するものを考えるきっかけになるよねとか、感じています。

そうそう、「期間を見極める」のところで出てきた、「プロジェクトの期間は6ヶ月以内が望ましい」ってのはまさにその通り。長いと、どうしても曖昧になってしまって、あれもこれもと夢を詰め込みがちになりますしね。

第6章 ユーザーストーリーを集める

ユーザーストーリーの洗い出しについていつも悩むんだけど、よさげなやり方が紹介されてました。フローチャートを書いてそこからストーリーを抽出していく方法と、画面モックからストーリーを抽出する方法。両方よさげ。

f:id:ikikko:20170206223450j:plain

あと、あまり詳細に立ち入りすぎないようにってアドバイスもよかった。これもそのまま引用。

ストーリー収集ワークショップでは、1日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書き出せれば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書き出したストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ(孵化さじゃない)。深みにはまって身動きが取れなくなっちゃいけない。

第8章 アジャイルな計画づくり:現実と向きあう

バーンダウンチャートではなくバーンアップチャートにして、かつスコープの広がりを表すもの。「アジャイルな見積もりと計画づくり」を読みました - @ikikko のはてなブログにも、バーンダウン棒グラフだったっけな?スコープも表現するようなものはあったけど、こっちのほうがシンプルでよさそう。今のプロジェクトに提案してみようかな。

f:id:ikikko:20170206223506j:plain


最初の一歩の人に進めるときにいい一冊。アジャイル全般ならこの本で、もうちょいスクラムに絞った本ならばSCRUM BOOT CAMP THE BOOK、カンバンならばカンバン仕事術かな。本のWIPは1冊&読書感想ブログを書くのを自分ルールに決めてるのであまり色々な本を読めておらず、もっと適切な本もあるかもですが。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

*1:正直に言うと、デッキ作成しようと思い立ったときは、ここまで深くは考えていませんでしたが。

*2:正確には、インセプションデッキ作成後にプレスリリースの作成はまだやっていないのですが、おそらくこうなるだろうと感じています

*3:コピーできるようにしたら、大本のテンプレートのように CC ライセンスの記載も必要かもしれない。その辺も含めて、何かありましたらコメントもらえると助かります。

「リーンスタートアップ」を読みました

確か『「ユーザーストーリーマッピング」を読みました - @ikikko のはてなブログ』でMVP(Minimum Viable Product)という言葉が出てきて、その言葉をもうちょっと確認したくて、この本を手に取ってみました。

リーン・スタートアップ

リーン・スタートアップ

はじめに

  1. アントレプレナーはあらゆるところにいる
  2. 企業とはマネジメントである
  3. 検証による学び
  4. 構築・計測・学習
  5. 革新会計

上記のリーンスタートアップの5原則のうち、太字にした 3, 4 が今の自分にささってます。要するに、作りっぱなではなく、ちゃんと検証したり計測・学習しようねということだと理解してます。

第4章 実験

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「Just Do It(やってみよう)」型企業と呼ぶ。この方針に従うと様子を見ることには必ず成功するが、検証による学びが得られるとはかぎらない。失敗がなければ学びもないーそれが科学的手法の教えるところなのだ。

あー、やりがちだし分かる。「様子を見よう」ってのは、思考停止の兆候なのかもしれない。

「様子を見る」ってのは、つまり「何を検証したいか」・ひいては「どうあって欲しいか」というゴールをちゃんと考えきれていないということなのかな?ゴールがゆるふわな状態でのアクションは、結局そのアクションがゴールに結びついてるかどうか分からないという状態になりかねないと思ってます。なので、「様子を見る」というアクションは極力取らないようにしよう。

第6章 構築・検証

MVPに対して、「作り込みすぎたり約束しすぎたりという衝動をいかに抑える」ための実例が参考になった。エンジニア目線だとどうしても自動化・ソフトウェア化が一番のMinimumだと思い込みがちだけど、それよりもっと手前に、コンセプトに価値があるかを検証できる手段はあるよということ。

  • 動画型MVP:Dropboxの実例
    • 優れた体験をプロトタイプででも提供するのは困難と判断して、動画でコンセプトを説明
  • コンシェルジュ型MVP:Food on the Tableという、自分や家族の好みに応じて1週間の献立と食材のリストを作ってくれるサービスの実例
    • レシピ作成を最初からソフトウェアで自動化するのではなく、文字通り中の人として顧客の自宅まで出向いて欲しい献立を対面で確認して、それをもとにレシピを手動で作成

あとは、品質についてのこの原理も、なるほどと思いました。

誰が顧客なのかがわからなければ、何が品質なのかもわからない。

第7章 計測

コホート分析なるものが気になりました。こっち方面ド素人なんですが、これ結構いい指標なんじゃないだろうか。総数などに紛らわされずに、同じ指標でアクションの結果を計測していけそう。Mixpanel上で、これっぽいやつが実現できるかは不明(Retentionが近そうだけど)なので、だれか教えろください。もしくは、社内のその筋の人に聞いてみよう。

コホート分析の場合、総売上や総顧客数のような総計あるいは累積値を見るのではなく、製品と新しく接する顧客グループの成績を個別に見る。

...

さて、このグラフをよく見るといくつかのトレンドが読み取れる。製品の改良はわずかだが効いている。我々の製品を5回以上使う人は5%以下から20%近くまで増えた。しかし、この部分が4倍になってもIMVUを買ってくれる顧客の割合は1%前後で変わらない。

...

これはコホート分析なので、古い製品の第一印象に顧客がとらわれているんじゃないかとか、外部環境がよくないとか、そういう言い訳はできない。

f:id:ikikko:20161224140420j:plain

あとは、スプリットテスト(A/Bテスト)とカンバンについてが面白かったです。「Xという機能をリリースしたとき、それは顧客の行動に影響を与えたか」を、スプリットテストなしでは測るのが難しい・コストがかかるけど、スプリットテストを実行するとこの辺が分かりやすくなる、とのこと。カンバンは、WIPの制限などはまあいわゆるカンバンの定義そのままなのですが、ステータスの一種に「構築完了」後に「検証中」を用意して、機能のユーザ価値まで検証を強制してるのがいいなと思いました。詳しくは、図を見てもらうと。

f:id:ikikko:20161224143718j:plain

第10章 成長

3種の成長エンジンというのが気になりました。3種全部備えた事業もあるけど、原則としてはどれか1種に集中してそのエンジンをチューニングすることにかけた方がいいよとのこと。

  • 粘着型成長エンジン
    • 一度顧客が使い始めるとずっと使ってくれることを念頭においた事業・ビジネスモデル。なので、解約率を指標とする。
  • ウイルス型成長エンジン
    • 顧客が使うにつれて自然と広まっていくような事業・ビジネスモデル。ウイルス係数(顧客一人あたり何人の友達を連れてくるか)が大事になり、1.0(=1人当たり1人を連れてくる)を境に指数関数的に成長し始める。
  • 支出型成長エンジン
    • 顧客を獲得するのに必要な支出と売上が相関してるような事業・ビジネスモデル。成長にあたって、顧客当たりの支出を抑える or 売上を増やすのどちらか。

今のうちのサービスだと、どれに該当するのだろう?粘着型:ウイルス型が 7:3 ぐらいかな。ITSやチャットなどのコミュニケーションツールは、ナレッジがたまると乗り換えコストが高く、ずっと使い続けた方がいい粘着型。かつ、組織の外部の人と使う際は一緒に使って自然と広まっていく、ウイルス型の側面もあるので。


どんぴしゃ自分が向かう分野ではないかもだけど、この辺の人たちと同じ文脈・同じ言葉で話せるようにという意味では、まあ読んで損はなかった本かなという気がしてます。あと、正直最後の方は息切れしたので、また別の機会に読み直してみたいです。

「Fearless Change」を読みました

いいものは色々取り入れようと日々奮闘しているのですが、そうは言っても取り入れ方にもいいやり方とちょっと受け入れづらいやり方ありますよね。というわけで、お次はこの本です。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

第1部 概要

第3章 さて、どこから始めよう

最初の足がかりとして、「エバンジェリスト」パターンが紹介されています。自分が「これはいい!」と情熱を持って導入・推進しないと、何事も進まないというのは、その通りだと思います。

エバンジェリストを前提として、以下が最初に導入する際の1セットとして紹介されています。とくに、後ろ三つの(ふりかえりの時間・小さな成功・ステップバイステップ)は、いわゆるスクラムでのふりかえりでもかなり重要視しています。色々根付かせるのは、ここからですよね。

  • 予備調査
  • ふりかえりの時間
  • 小さな成功
  • ステップバイステップ

第3部 48のパターン

どうでもいい話ですが、48という数字を見ると別のものを連想しちゃいます。。。

7 ブラウンバッグ・ミーティング / 9 何か食べながら

両方とも、食べることに関するパターンです。

「ブラウンバッグ・ミーティング」は、要するにランチミーティング。ランチミーティングは結構好きなんです。時間を有効活用してる感じがするとか、お弁当持ってきてるからとか仕事上人と合わせづらくてランチ一緒に行けてないけど行きたいとかの理由で。ただ、何回かランチミーティングやったら、あまり芳しくなかったのでちょっとサミシイ><

「何か食べながら」は、そのまんまですね。食べながら話すと、リラックスできてより前向きに話し合えるとのこと。うちでも、リリース後のふりかえりとか、特別なイベントの際には経費でケーキなどを準備してもらうように進めています。あとは、ちょっと長くなりそうなミーティングの場合、1時間ぐらいでいったん休憩を挟んで、甘いものやコーヒーなどをとってもらうように仕向けるとか。

15 空間を演出する

物理的に掲載して、否応なしに目に入るようにするパターン。カンバンなどでもあるように、物理で見せるとやっぱり分かりやすい。ただ、うちはオフィスが分散してるので、ちょっと難しいんですよね。物理の力は偉大だと思ってるので、何かうまくやる方法を見つけたいとは思ってるところ。

お隣さんの製品ですが、「JIRA とアナログのボードの併用」ってのはいいアイデアだなーと思いました。一度試しにやってみたい。オフィスに遊びに行って見せてもらうかーw

www.evangelism.jp

22 種をまく

プレゼンやミーティングを行うときに、参考書籍やURLを出せるようにしておく、というパターン。割りとこれはやってる。特に、リモートの人と会話するときは、参考URLをぱっと出すと、相手もイメージしやすいので。

24 定期的な連絡

「コーチングマネジメント」を読みました - @ikikko のはてなブログにもあったけど、定期的にリマインドするの大事。何もしないと、人は忘れるものなので。

36 場所重要

少し特別なイベントを行うときは、普段の作業場所ではなく、ちょっと場所を入れ替えるというパターン。普段の場所だと、良くも悪くもすぐに普段の仕事に戻れるので、半強制的に切り替える。「9 何か食べながら」とかと組み合わせるとよさげですね。

46 恐れは無用

抵抗勢力がまったくいない状況を想像すると、ぞっとする。あなた一人で常に 100% の正しさを保証しなければならない。これはおそろしいことではないだろうか。

なるほど。こういう視点はなかった。こういうのを意識しておくと、何か抵抗や批判を受けたときも、リスクを潰してくれた・協力してくれたと前向きに考えることができるようになりますね。



基本的にこの本はパターン集なので、ざっくり頭に入れておいて、よさそうな機会に本引っ張り出して確認・適用みたいな流れになりそうかな。