プロダクトオーナーは常に血液を送る心臓のような働き

Jim Coplien さんの認定スクラム研修シリーズが終わりました。つぎはまた6月に来るそうです。あとScrum Book (スクラムパターンの本) もいよいよカウントダウンで、もうすぐ出るみたいですよ！

プロダクトオーナーの研修を手伝いながら、多く受けた質問が「プロダクトオーナーって大変すぎませんか？」でした。いやぁ、間違いなく大変ですよね。

皆さんのお話を聞きながら、プロダクトオーナーの立ち位置について、ハッと気づいたことがありました。

サッカーのフォーメーションにたとえて考えてみる

サッカーというのは11人の味方プレイヤーが協力して、ボールを相手チームの奥にあるゴールに入れると得点、というゲームです。手を使うことが禁じられているので、ボールを誰かが確実に保持するということが出来ず、足元にボールをキープしたり、他の人に蹴ってパスしながら、相手チームの11人の隙をついてボールを運んでいく必要があります。相手ゴールに近いエリアを担当して、攻撃を担うフォワード、自陣に近いところで守備すなわち相手がキープするのボールを奪ったり、前に進むのを防ぐディフェンスという大まかな分担があります。絵に描くとこんな感じ。

上が相手のゴールで、そこに近い人がフォワード、下側にいるのがディフェンスです。(絵では省略してますが、相手チームも同じ人数が上下反対の構成でいます。)

作る人と売る人の分業の世界

ソフトウェア開発ビジネスは、長らくメディアを買ってもらったり、作る行為そのものをあらかじめ買い上げてもらう、事前支払いのモデルがほとんどでした。作る人が作ったものを売る人が売ってくるか、またはあらかじめ作る人の時間を売る人が売ってくることで、売上が立つことになります。サッカーのフォーメーションだとこんな感じ。

今も、こう考えている人が多いんじゃないかと思います。営業部隊を「フロント」と言ったりすることがありますね。顧客に商材を説明して、契約を取ってくるのが、フロントの大事な仕事です。

そして、売りものを作るのが作る人の仕事です。ちゃんと売れるものをちゃんと作る。売れそうなものを考え、予算を取り、人を集め、ものを作って、流通に乗せて届ける。

デリバリーの大きな変化

ソフトウェア開発は新しい分野ですが、多くの変化を経験してきました。パソコン、インターネット、クラウド、スマホ、データサイエンス、機械学習 ...。作り方も届け方もお金のもらい方も変化してきます。

パソコン(やワークステーション)の普及によって、開発現場は大きく様変わりしました。といってもその前を知らないのですが、少なくともパソコン普及以前はすべての人が汎用的なコンピュータを使うということはなかったはずです。作るのも変えるのも、一部の人しかできなかったのではないかと想像します。しかしパソコンやUnixワークステーションは、作る装置も使う装置も同じという特徴がありました。農地や工場に行かなくても、誰でも作る側に回れるのです！なので誰かにお願いして作って貰う必要が本質的にはありません。同じ部屋の中で、欲しいものを作れます。しかも外から買ってくることもできるし、買ったものと作ったものを組み合わせて使うこともできます。

そこで、分業をなくしてチームで作ろう、というのがアジャイルやスクラムの考え方です。あなたは営業、あなたはデザイナー、あなたはプログラマー、あなたはマネージャー、と決めたとしても、目の前のパソコンはケチらない限り共通です。

スクラムのプロダクトオーナーと開発チーム

以下の絵はスクラムのプロダクトオーナーと開発チームの関係について書いたものです。プロダクトオーナーはビジョンや情報に基づき、プロダクトバックログを開発チームに提示できるように頑張ります。開発チームはプロダクトバックログの優先順位に従ってデリバリーできるように頑張ります。

プロダクトオーナーは開発チームにバックログアイテムを提供し続ける

先ほどのサッカーの絵と並べたら、面白いことに気がつきました。

先ほどの図とは逆で、ゴールに近い上側、価値を届けるフォワードが開発チーム、下側でネタを提供するのがプロダクトオーナー、に見えてきました。

常に血液を送る心臓のような働き

特に現在はサブスクリプションモデルが多くなってきています。企業は使う前に契約でお金を取るより、使っただけ支払って貰う方式に変わってきました。ユーザーはいつでも契約を終了することができます。

継続的に使い続けてもらわないと、収入が発生しないのがサブスクリプションモデルです。顧客を引きつけるために、常に革新的なアップデートを提供し続ける必要があるのです。

プロダクトオーナーは、そのために開発チームに常にプロダクトバックログアイテムを提供し続けないと生きていけません。そうしないと、開発チームは価値のある機能を迅速に届け続けることができないのです。脳や手足に常に血液を送り続ける心臓のように、ずっと動かないといけないのかもしれません。

プロダクトオーナーとしては、いいボール供給してガンガン得点してもらえるといいですね。

Fun! Done! Learn!とスクラムとXP

沖縄でみんなでつくった Fun! Done! Learn! が広がりをみせていて、作った人の一人としてとても嬉しいです。ちなみに私の貢献は寝坊して起きてきた朝に「いいねそれ！」って言ったことと、「Deliverは長いし、汎用性考えるとDoneのほうが使いやすそうだし、なにより英語でも日本語でも語呂がいい」って主張したくらいです。つまりだいたい私のおかげだと思っております(壮大な勘違い)。

yattom.hatenablog.com

大事なポイントは、私たち、全然教えてないのに、これだけ広まって、成果の声が届いていることです。これは、なんかすごいものを、見つけてしまったのではないかと感じています。みなさんの共通の、心のなかにあったものを、見える化できたんじゃないかと。

　　

このエントリは、私の心の中にあったものを、書き出してみたものです。Fun! Done! Learn! とは一体なんなのだろうか。私なりの捉え方です。(捉え方は人それぞれでよいと思います。)

KPTじゃだめなの？

私としてはKPTを否定したいつもりは１ミリもありません。第一人者である天野勝さんからお話聞いたときに「Keepで現状よかったことをちゃんと認識するのが大事」というのを聞いて、ほんとにそうだなぁ、と思っています。ProblemやTryの前に、ちゃんとKeepがあるのがいいんですよ。課題認識と改善のネタ出しは大事なんですけど、それだけでは、チームにないことばかり話してしまいます。

メンバーが自信を持って前に進むには、ちゃんと、できてることを認識して、増やしていかないといけません。チームにできることがあるから、次の仕事の依頼があるわけですし。チームの価値を、自分たちがわかってないと売れないし、誰かに言わないと勘違いしてた時に直せない。

これだけ! KPT

スタート・ストップ・コンティニュー

海外の書籍では、ふりかえり手法としてスタート・ストップ・コンティニューがよく参照されていて、海外ではデファクトスタンダードなのかなと思います。やめること、続けること、始めてみること、ですね。

チームや個人の態度とかではなくて、事実としてコトを認識して、合意するのがよいところなんじゃないかと思います。犯人探しより、「問題対私たち」の状況を作って、ポジティブに対応できそう。

gamestorming.com

XPとプロジェクトファシリテーションが日本のアジャイルコミュニティを牽引してきた

日本では、2000年代前半からXPコミュニティがアジャイルコミュニティを推進してきました。また、フルのXPを入れられなくても、見える化などを進めましょうということで、プロジェクトファシリテーションと銘打って、ふりかえりやタスクかんばんを中心に普及を進めてきた、という流れがあります。

objectclub.jp

まず開発チームで、ふりかえりをやってみましょう、と。ウォーターフォールのままでも、今週やったことをちゃんとふりかえって、課題があれば解決を考えていきましょう。そこからアジャイルは始まるんじゃないでしょうか、という提案でした(と思います)。

もちろんいまでも、XPを中心にしているチームがありますし、プロジェクトファシリテーションやふりかえりを中心に普及活動されている方がいます。

www.ogis-ri.co.jp

スクラムの中で使うことを考える

で、2010年代は日本でもスクラムが普及してきまして、最近はスクラムからアジャイルに入った人たちが多いかなと思います。私がスクラムを教えたりカンファレンス運営をしている都合上、多く耳に入ってくるってだけかもしれませんけれど。

スクラムを前提として考えた時に、ふりかえり(レトロスペクティブの役割はちょっと変わるのかもしれないな、と気づきました。(いやそれは違うぞというご意見もお待ちしてます)

スクラムおさらい

スクラムではPDCAサイクルに似ていて、スプリントと呼ばれる1-4週間のサイクルを、プランニング→ワーク→レビュー→レトロスペクティブ(ふりかえり)で一周します。

• プランニング : チームとして取り組める範囲を予想し、実施計画を立てる
• ワーク : 仕事を進め、各プロダクトバックログ項目を完成させ、出荷判断できる状態にする (毎日デイリースクラムをして動的に再計画を行う)
• レビュー : 成果物を関係者に見せてフィードバックをもらう、状況をアップデートしてプランを見直す
• レトロスペクティブ : 計画、実施、フィードバックを踏まえ、チーム自身で進め方について見直す

それぞれのミーティングや役割はいろいろ決まっている(ベストプラクティスがある)のですが、目指すところは、

• ワークの時間をなるべく中断なく、多くとって、
• チームが自律的に作業を進められるようにし、
• 進め方の改善もチーム自身で行うことで、
• 顧客や組織の課題に対応できるチームを作る

ということです。作る人々(チーム)を中心にして、アウトプットを出しながら、ちゃんと育っていくようにする。 

Ping Pong Game ピンポンゲームでスクラム体験ワークショップ - Speaker Deck

 スクラムは経験主義に基づく

スクラムでは、レトロスペクティブをやる前に、まずはプランニングをしているわけです。プランニングの完了時点までに、チームがワークに着手できる状態にします。チームはこのスプリントで自分たちが何をやろうとしていたのかを知っている前提です。

また、デイリースクラムでもやり方を話し合っていたり、レトロスペクティブ以外に、やり方を話し合うチャンスがいくつもあります。チームのコミュニケーションを密に保つのが特徴です。

そして、スクラムは「経験主義(empirical)」に基づきます。チームの実力は、前回までの スプリントの成果をもとに予想します。「チームはどうあるべき」という理想論ではなく、過去の実績値に基づいて天気予報のように先をみていこう、というのが根底にあります。速度=ベロシティの予測で、昨日の天気*1というのを聞いたことがある方も多いと思います。まずちゃんと現実を見ようよ、ということです。誰かが決めた目標値ではなく、自分たちの体温を見て、今日の体調を確認しようということです。

スクラムのレトロスペクティブで陥りがちな罠

一方で、これはスクラムのコミュニティでよく聞くのですが、「レトロスペクティブでKPTをつかっているのだけど、Problemばかりが出る。また、Tryがまったく着手されなくて残る」ということがあるようです。

この問題はチームのマンネリ化を呼んでしまうので、対策として「Tryはアクションアイテムとして必ず次にやるようにする」という話もよく聞きます。よいことと思います。自分たちでそう決めるなら、特に。

でも、なんかルールが増えていっても、あんまり楽しくない感じがします*2。なにか大事なことが言語化できてない気がする、と感じていました。

レトロスペクティブの第一法則

以前、レトロスペクティブの祖であるノーム・カースさんの第一法則を紹介しました。

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。 

kawaguti.hateblo.jp

これを調べた時、「これだ！」って思いました。

まずは、これを言語化したらいいと思うんです。自分たちは、ベスト尽くして、なにをやってきたのか。現状のベストの確認です。

そのあと、沖縄で生み出されたばかりの Fun! Done! Learn! に出会うわけですが、そこでも「これだ！」って思うわけです。みんな同じようなこと考えてたんですね。

自分たちがやったことにフォーカスする

改善案を考える前に、まず、現状をちゃんと見回すべきだと思います。このスプリントでなにをやってきたのか。なにが楽しかったのか (または大変だったのか)。そこからなにが学べたのか。...  シンプルにこれを見直すためのフレームワークがFun! Done! Learn! です。

そこには、感覚的なものも含め、事実しかありません。感情もまた、その時誰かが感じた事実です。実際やってみた人たちから「すごくたくさん事実が集まる！」という反響もいただきます。

そんな事実も、時間がたってしまうと記憶が風化して、あいまいな思い出に変わってしまいます。ですので、スプリントの最後にやって、まだ新鮮な記憶のうちに、共有するとよいのではないかとおもいます。

https://speakerdeck.com/kawaguti/fun-done-learn?slide=34

ProblemもTryも仮説にすぎない 

その事実の上に、課題を見つけ、解決策を考えていくとよいはずです。私の感覚だと、事実を話し合うと、自然と課題や解決策の話も出てきます。やったことがあることには、もっとうまくやる方法のアイデアが出てくるものだと思います。

人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。

(第一章 P.13-14)

教育心理学概論 (放送大学教材)

だってみんな、今後もずっと付き合っていくような、自分たちの仕事なら、もっとよくしたいと考えますよね。もっと効率的で、価値が高い仕事をして、お客さんやユーザーさんに喜んでいただいて、ちゃんとお金をいただきたい、と考える。

そこを信じましょう、というのがスクラムの根底であり、アジャイルでも語られていることです。アジャイルマニフェストの12の法則に、こうあります(下段は私が作った反例です)。 

Flipped Agile Manifest - Speaker Deck

まずは、自分たちの目で、自分たちがやってきたことをちゃんと見る。そのうえで、もっといいやり方を考えていく。この順番が大事だと思います。

ベターベターの積み重ね 

話は飛びますが、トヨタ自動車の豊田章男社長が、年頭のメッセージで、トヨタの文化は「ベターベターの積み重ね」だとおっしゃっていました。これを見たとき、まさにそれだ！と思いました。ちゃんと現場をみて、自分で動いて、よりよい方法を一つ一つ試していく。スクラムでもその意識が大事なんじゃないかなと思います。このビデオとても素晴らしいので是非どうぞ。

INSIDE TOYOTA #1 豊田章男からのメッセージ　～”自分”のためにプロになれ！～

結論: Fun! Done! Learn! は現状のチームを把握するのにとってもいいよね！

ということで、とっちらかってますが、Fun! Done! Learn! は現状のチームを把握するのにとってもいいよね！っていう思いを書きました。今日よりも明日。今週よりも来週。仕事は続くよどこまでも。いいチームを目指していきましょう。

みなさんが、いい成果を出せることを願ってます！

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

ユーザーストーリーマッピング

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

*1:このメタファーはXPコミュニティから来ていると聞きました

*2:そもそもスクラムなので、次にやると決めたなら、プロダクトバックログに載せるべきだとおもうのですが...。

「さよならメインストリーム」に参加した。

昨日は角さんがFacebookで共有してくれたイベントに参加してました。明治大学渡邊恵太研究室が単独で開催しているイベントで、司会も先生本人という。ほんとすごいなと思います。企業のTechConfを手作りでやってきたので共感ビシバシでお手伝いしたくてムズムズしてしまいました。中野に明治大学のキャンパスがあるってことを初めて知りましたし、素晴らしい取り組みだなと思いました。

keita-lab.jp

急に入れた予定のため、というか私が午前中仕事しなかったせいで、最初のトークセッションだけで中座してしまったのですがとても楽しめました。

深津さん「面白いもの作れる人は、鉛筆と紙があれば作れるので、鉛筆と紙を無限に供給すれば良くて、大理石とノミを提供しても...」

深津さん「共同体の箱の中で普遍的に機能するものを考えてる」

深津さん「炎上するものとかスキャンダルが評価されるシステムにすると、そういうものが評価されるんだと学んでそういうものが増える」「運営としては(よいものを)見せることが大事で、チュートリアルは副次的なもの」

深津さん「日本のメーカー言うほど技術好きじゃないよね問題。技術者は技術好きなんだけど、会社総体として技術好きじゃなかったり、技術者を大事にしてなかったり」

深津さん「酒好きかつビジネス感覚のある人がやる酒屋が必要」

メモが深津さんに寄り過ぎていて、お前どんだけ深津さん好きなんだよと...。

最後に、新聞社とかのアプリと、Noteでの取り組みはどんなところが違うのかをしつもんしたのですが「もちろん全然違います」というご回答でした。もうちょっとちゃんと質問できたら面白くできたかなと思い反省しております。

Joy, inc. のリチャード・シェリダンさんの基調講演書き起こしが公開されました。

Regional Scrum Gathering Tokyo 2018で基調講演をしていただいたRechard Sheridanさんの講演の書き起こしが、ログミーTechさんで公開されました。３回にわけて毎日更新だそうです。

logmi.jp

ネガティブイベント、官僚化、そしてシャドーIT

ネガティブイベント、つまり悪い物事が起こると、組織が反応を起こしますよね。ソフトウェア業界であれば、それは分厚い本のようなものです。文書による承認、委員会の招集、ミーティング、誰かが承認しないといけない申請書で埋め尽くされた分厚い本です。ソフトウェア開発のライフサイクルといった書類です。私たちは、カオスから脱却しないといけません。そしてその分厚い本を司るプロジェクトマネジメントオフィス（PMO）を設立します。

そして官僚主義に至ります。全く仕事が終わらない状態(カオス)から脱却しようとしたのに、今度は仕事を始めることすらできなくなるのです(官僚主義)。待つ必要があるからです。サイン（ハンコ）、書類の承認、委員会の会議、誰かが何かを決めることを待たねばなりません。そしてもちろん、そんな状態でも、仕事しないといけないし、終わらせないといけません。

そしてシャドーITが根を張ります。皆、物事を終わらせるために、システムの外側で作業を始めるのです。その結果、私たちはカオスと官僚主義の両方に同時に放り込まれます。

これがまさに私の人生でした。ここでまさに、私は自分の専門分野に対して心が折れてしまったのです。

 

エクストリーム・プログラミング(XP)とデザイン思考(IDEO)との出会い

悲しみについてお話ししましょう。この業界におきるもっとも悲しい物語は、例えば非常に長時間、一生懸命働いていたのに、ある日上司が来て「この案件はキャンセルになった。もうやめだ。この仕事が世に出ることは決してないだろう。新しいプロジェクトがあるからとりかかってくれたまえ」と言われたときなどです。プロジェクトが葬られると同時に、自分の一部も消えてしまいます。

私はそういった経験をしていました。そして探求の旅を始め、この本にたどり着きました。ケント・ベック著『エクストリームプログラミング』です。

エクストリームプログラミング

そして私は、カリフォルニアにある商業デザイン企業IDEOの動画も視聴しました。まず書面で読んでから、動画を見たのです。するとその瞬間、私の頭の中で何かがカチッとはまりました。すべてのことが突如はっきりと明快になり、私は自分のやりたいことがわかりました。 

ABC Nightline - IDEO Shopping Cart

オープンスペースではなく、オープンカルチャー

私たちのやり方を見学するために、世界各地から年間3千から4千人が訪れます。見学者が大きな入り口のドアをくぐると、見えるのはこの光景です。広々としたオープンな環境です。多くの見学者はオープンスペースをあまり好まず、いやがります。オープンスペースは、ソフトウェア開発の環境としては良くないのではないか、と考える人が大勢います。「リッチ、オープンスペースはうまくいかないと説く本を何冊も読んだが、なぜメンローではうまくいったのだろうか」と聞かれます。

私はこう答えます。「私たちが作ったのは、オープンスペースではありません。オープンなカルチャーです。このスペースは、私たちが根底に持つ、風通しの良さ（オープンネス）、透明性、コラボレーションといったカルチャーの価値観を反映しています。私たちの職場は騒音であふれていますが、これは働く時に立てる物音であり、週末に応援するスポーツチームの得点についておしゃべりする声ではありません。働く音なのです。

人間とは何かという概念を拡張する

35年前、ネイスビッツはすでに現代にタイムリーなこの言葉を書いているのです。「21世紀最大の発明は、技術そのものではなく、人間とは何かという概念を拡張するものになるだろう」

この言葉は、技術を軽んじているわけではなく、人間の方がより大切であると訴えています。私たちは時にそれを忘れてしまっているように感じます。

そこで、社内の対話を変革するためには、デジタルに頼らないことにしました。Slackでもメールでもなく、メッセージアプリでもありません。私たちの言うところの「ハイスピード・ボイス・テクノロジー」です。

 デイリースタンドアップ

毎朝10時、アラーム時計が「ボーン、ボーン」と鳴ると、全員が立ち上がり、円陣になります。デイリースタンドアップミーティングには、60人から70人が出席します。（写真を指して）全員が出席します。犬も出席します。

バイキングの兜を持ってペアで発表する

私たちはペアで仕事をしていて、ペアで発表をするために起立します。バイキングの兜が回ってくれば、ペアのパートナーとあなたが、自分たちが今やっていることを話す番なのです。話し終われば次のペアに兜を渡します。話し終われば、さらに次のペアに兜が渡されます。兜は70人の手を渡り、全員が話し終わると、テーブルの上に戻されます。こうしてミーティングは終了します。通常30分くらいの長さです。

logmi.jp

ショウ＆テルで顧客に報告 (実際は顧客が報告)

メンローでは役割が逆転します。私たちが、顧客に前の週の進捗を報告するのではありません。顧客側にコンピュータとマウスを配置し、進捗中のソフトウェアをスクリーンに投影して、「顧客が」私たちの前週の作業を「メンロー社員たち」に見せ、メンローの担当者がそれを見学するのです。

計画ゲームで顧客と協調的に計画を行う

作業は全て、インデックスカードに手書きで書き込まれます。見積は1時間単位で立てられ、カードは見積の大きさに合わせて折りたたまれます。こちらが16時間のカード、8時間カードはこれ、4時間カードはこれくらいの大きさです。大きさで判別できるようになっています。

 実行するのは開発チーム。すべてをペアで進める

ひとたびプランが完成すれば、全員の目につく場所に貼り出されます。全ての紙片について、縦はそれぞれペアが費やした5日間の作業内容を示し、横に貼り出したひもは5日間のサイクルで現在どのあたりかを示しています。ひもは、工程が進むにつれ、時計のように毎日進みます。

 QAチーム(実際はQAを担当するペア)が完了を評価する

メンローでは、プログラマーたちには「完了したと思う」と表現してもらいます。QAチームがチェックをしその了承を得られれば、緑の評価を得られます。緑の評価をもらえることは、プログラマーたちにとって非常に喜ばしいことです。メンローにおける「緑ドット」は、プログラマーにとって幸せと喜びの象徴です。

 ハイテク人類学者はUXリサーチから要件定義を担う

メンローのハイテク人類学者たちは、世界にでかけて行き、相手が暮らしている環境の中で相手を観察します。トヨタの人たちの言うところの「現場へ行く」ですね。働いている現場に行く理由は、相手のワークフローや習慣、生き方の目標、働き方を表現する言語を把握するためです。

 実験してよう！やってみて学ぼう！

だからこそ、私はみなさんに、このシンプルな言葉を覚えて帰っていただきたいのです。もし誰かがみなさんに「うちの会社ではうまく行かないだろう」と言ったら、みなさんは相手の顔を見て、「そうかもしれない。でも、実験してみよう」と言うのです。「ノーと言う前に試してみよう。何が起こるかを見てみようじゃないか」

logmi.jp

顧客やステークホルダーを巻き込むには

なぜなら、我が社ではプロジェクトを壊すものは2つあると信じています。1つ目は、「恐れ」です。恐れても、悪いニュースは無くなりません。恐れは、悪いニュースを隠してしまいます。私たちは、恐れを克服するには、問題を進行させず、迅速に対処します。

プランが遅れ気味で、顧客がカード（注：プラン作成用の手書きカード）を吟味している時には、顧客はテーブルにカードを並べながら、直に個人的に参加しているのです。カードは壁に貼り出され、5日以内にディスカッションを始めます。すると顧客は、私たちが仕事をするためには、自分たちの仕事がどれだけ大切か理解し始めます。なぜなら、顧客が仕事を終わらせないと、私たちの仕事にも影響が出るからです。

要するに、シンプルに全体を見える化するのです。顧客との新たな関係を築くことができます。言うのは簡単ですが、実際にやるとなると、非常に難しいですよね。ありがとうございました。

自分たちでやり方を変えていく

すると彼らは言いました。「赤ドットには、『停滞』や、『完了したと思う・QA待ち』など、いろいろな意味がありすぎて、赤だけでは成り立たなくなってきたのです。しかもQAで問題が見つかれば、前のカードの指示まで戻ってやり直さなくてはなりません。そこで、チームが『オレンジのドットを使う』という実験をしたのです」今では、オレンジドットが「完了したと思う、QA待ち」という意味を持つようになりました。

委員会も、大きなミーティングもありませんでした。誰かが小さなオレンジドットのシールを持って来て「オレンジドットを使ってみよう」と言ったのです。10年ほど前のことです。以来、私たちはずっとオレンジのドットシールを使い続けています。

講演資料はこちらです。 

speakerdeck.com

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

お試し版もあります。 

ジョイ・インク 役職も部署もない全員主役のマネジメント【無料お試し版】【固定レイアウト版】

logmiを見直して

一年たった今見直しても、すばらしいお話だったと思います。2000-2001年ごろにちゃんと走り出している人たちがいて、ずっと工夫しながら続けてきて、当時「うちには難しいな」と思って諦めた多くの人たちにとって、背筋を伸ばさせられるトークになったのではないかと思います。でも、全然今からでもできるんじゃないかと思います。具体例もあるし、十数年分の経験を積み重ねてきたのですから。しかも飛行機に乗ってミシガンに行けば(デトロイトから30分です)、簡単に見せてくれるんです。残念ながら偉い人の北米視察コースには入ってないと思いますが。

RSGT2018では、Microsoftのエンジニア、河野通宗さんの基調講演も行われました。こちらもクラウド時代のエンジニア像として、生々しく話してくれています。LogmiTechでどうぞ！

logmi.jp

Starbucksでのデジタルトランスフォーメーション at Microsoft Build 2018

Microsoftの石坂さんが紹介してたこのビデオ。Starbucksでのデジタルトランスフォーメーションのパネルがよかったです。

Digital Transformation at Starbucks : Build 2018

司会はStarbucksクラウドサービスチームのリーダー Scott Bockheim氏。頭出しはこんな感じで始まります。

今日はStarbucksのデジタルトランスフォーメーションを考えて、クラウド化を推進してきたかについて、ちょっと話します。...

技術の話をする前に、Starbucks のミッションの話をします。一杯、一人、一人の隣人に特別な体験を、というもの。...

テクノロジーチームからみると、デジタルトランスフォーメーションはその体験をもっと深めること。特別なデジタル体験を届けて、顧客にStarbucksをもっと伝える。キラキラした新しいものでも、単なる技術が出たから使う、でもない。店舗に寄ってもらったり、モバイルアプリを届けることを通じて、顧客とパートナーを第一に考え、テクノロジーを届ける。

そのあと、各担当を交えた説明が続きます。AIの時代にどう対応するかとか、DevOpsやSREを進めてきたという話。On Boarding (新しい人が参加するときの教育)プログラムをちゃんとしたとか。

最後に聴衆を鼓舞するようなことをいいたい、ということでこう結びました。

私がこの2年で学んだことは、
「あなたのチームを見くびるな」
(Don’t underestimate your team) だ。

開発者、技術者、アナリスト... 話しに行って、どうしたいのかを伝えるんだ。あなたのチームを見くびるな。社員はやりたいんだ。支援や教育の機会があれば、社員は喜ぶ。信じられないほど、みんな走り出す。さっき「どうやったら普及をうまく進められる？」って質問があったけど、うまくいったことについて話せばいい。雪だるまみたいなものだ。あるチームを誘って、うまくいけば隣のチームもやりやすくなる。そしてサイクルを回す。機会と支援を与えて、成功や学びを得たら共有する。 … ベロシティも普及も興奮もびっくりするほど得られるよ。

 Microsoftのチームは直接顧客のところに行って、技術やプロセスの支援をしたっぽいですね。このあたりの組み方も、最近のMicrosoftという感じです。かっこいいプレゼン打ってライセンスを売る、というのではない、実際に使い続けてもらって売り上げにつなげるサブスクリプション時代の普及活動を感じられてよかったです。

ここまでちゃんといろいろやって、発表できる企業が日本でもたくさん出てきたらいいな、と思います。もちろん経営にも説明しているし、経営も理解しているということでした。

スクラムフェス大阪に実行委員として参加してきました

スクラムフェス大阪に実行委員として参加してきました。RSGTの雰囲気を気に入ってくれたスクラム道関西の人たち中心に、立ち上がりから実施までコンパクトに行われたカンファレンスでした。スタッフはたった13人。実行委員会は4-7人くらいで作業を進めてる。燃え上がらず、燃え尽きず、よい場所をちゃんとデリバリーする。そういうのがちょっとできた気がしました。

個人的な思いですみませんが、ちゃんとダンプしておこうかな、というのがこのエントリです。

www.scrumosaka.org

東京から実行委員会に参加しながら、なんとなく考えていたこと

第一回のスクラムギャザリング東京でCEDECにご協力いただいた縁がきっかけで田口さんのスクラム事例に感動したり、オージス藤井さんにはいろんなカンファレンスでご支援いただいたり、2011年にCopeのCSPO研修をやったり、2012年以降は楽天の大阪支社に講師として何度も呼んでもらったり、関西からRSGTに多くの人が来てくれたり、仕事面で大阪に育ててもらった部分がたくさんあります。今回は大阪で久しぶりにCopeの研修をするというタイミングもあり、楽天を辞めたばかりでいくばくかの自由な時間もあり、できることはなんでもしよう、と思ったのが今回実行委員をしたきっかけです。

そこにいる人でできない作業はない

カンファレンスの準備や運営の作業って、基本的にはそこにいる人でできないような高度の専門性を求められるものってほとんどないと思っています。カンファレンスのテーマをやりたい実行委員が普通に持っているスキルでなんとかなる。知らなくても調べればよい。時間が足りないと難しいけど、知ってさえいれば最低限は実行可能なものが多くて。かといって、それをやりたい人もいないのですが。だから、お金を支払って業者さんに手助けいただく道もあるし、やることを絞って自分たちで手作りできる範囲に抑えることもできる。大事なことは、ちゃんと選択することかなって思います。

まずは「できる範囲でやる」っていう判断がちゃんとできることが大事かなと。

大阪の人たちが考え、RSGTの知見で補完する

RSGTはイベント業者さんに手伝っていただいたこともあるし、自分たちでやったこともあります。基本は大阪の人たちが考えるベストな方法で進めるとして、RSGTの開催を通じて知っているノウハウがあれば、お渡ししようと思いました。わざわざ大阪に行く必要も、実行委員になる必要もないと思うかもしれません。しかし、仕事でもそうですけど「わからないことは質問もできない」という人間の認知の問題がありますので、「なんでもメールで聞いて！」モデルも「次のミーティングでまとめて聞いて！」モデルもなかなかうまくいきません。初めての時こそ、同席(Sit Together)が有効で、必要と感じたらすぐ手伝える体制で横にいるのが大事かなと思います。

2019.scrumgatheringtokyo.org

自分がいなくても10年使える仕組みをちゃんと考えながら

今回、イベント業者さんは使わなかったのですが、グッズの製作や会場など、多くの関係業者さんと話をしないといけないですし、スポンサーさんや登壇者の方々にも連絡や相談が必要なことがあります。どこかにブラックボックスを作ってしまえば、来年他の誰かがやるときに問題になるかもしれない。どういうタイミングで、何を誰におねがいしないといけないのか、ちゃんと残しながら、かといって重要なコンセプト以外の議論に時間をかけずにすすめていくことを、考えながら参加しました。たぶん、大阪でずっと同じようなカンファレンスが行われることが、みんなにとってよいと思うからこそ、このカンファレンスをやってみるわけで、そこそこ成功するなら、それはたぶん、続けてほしいということになる。そうなったときに続けられないような情熱や仕組みでやってしまうと、寄付金だけ集めて逃げる詐欺業者、とまでは言わないですけど、ちょっと残念な感じがします。実行委員の人たちがやめたくなったらやめればいいんですけど、できるだけ自由な判断ができる状態を作っておきたいと思いました。

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

「謎の人」

恩返しの意味はあるにせよ、個人的には特にはっきりとしたメリットがあるわけではないのですが、そうなると、なんで来るの？って感じになりますよね。旅行や出張がそんな好きなわけでもないし、今回はアギレルゴで旅費を出してもらってますけど、アギレルゴがそんなに儲かるわけでもない。

メリットが明確になってから努力を傾けることは誰にでもできるので、そうではないとこに努力を傾けてこそ、世の中にとって価値があることにつながるのではないか？とちょっと思いながら、タガを外す。ただ、思い余って無理をしないこと。誰も見てないとしても、淡々と貢献する。他の人がやりそうなことでもないので、やっておけば学びも多いです。まとめると、さして深く考えてませんでした。

www.jp.agilergo.com

資金がないとしんどい

初回のカンファレンスで一番辛いのは、資金繰りだったりします。今回は東京からの支援とか、Scrum Alliance からのスポンサーとかも確定しないし、参加者も何人来てくれるのかわからないわけで、それで運営に失敗すれば、お金だけがマイナスになる。これはやったことがある人はわかると思いますが、思った以上にしんどいです。

今回はありがたいことに、かなり初期からいくつものスポンサーについていただくことができ、会場も関西大学さんにお借りすることができ、資金の面では安定した運営を行うことができました。黒字分は、法人税等を支払った上で来年の催行に回すことができます。

そのあたり、スクラムギャザリング東京を始めた2011年とはだいぶ状況が変わっているのを実感しました。心強かったです。いつもの関係先に、ちゃんとご支援をお願いするというのもできました。慣れてないと意外と難しいと思います。普段のみなさんの活動がすごくプラスに働いて、無理のないところからご支援をいただくことができたのではないかと思います。 

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

はじめて何かをするときに起きがちなこと

 これはScrum Fest 大阪で起きたことではないのですが、初めてアジャイルをやるとか、カンファレンスをやるところに立ち会ってきて、起きがちなことがあると思います。

• 100対0の雑な議論が起きがち
• 実現性のないアイデアも話が盛り上がりがち
• やったことがある人がマウントしがち
• 途中でも原則論でひっくり返したくなりがち
• その結果、議論や作業の時間がなくなりがち
• 持ち帰り作業が増えると一部の人が疲弊しがち
• 一部の人が疲弊すると、次にやってくれなくなりがち

　作業時間内で、まず実現可能な選択肢を作り、その中からちゃんと選ぶ、というのを心がけました。リーン製品開発でいうセットベース開発に似てるかもしれません。

リーン開発の本質

たくさんの笑顔をみることができたので、きっとちゃんと続く

今回は多くの笑顔をみることができました。チケットの販売も好調で席が足りないくらいでしたし、セッションもよかったし、スタッフも大変だけど次にやりたくないほどではない感じがしてます。ほっとしました。すべての関係者のみなさま、本当にありがとうございました。続きそうでよかったです。

　

　

　

　

　

全員の意見が一致してよかった！

割と Fun! Done! Learn! はジェフ・パットンさんに教えてもらったこれに基づいています。

長々と説明するより、まず一旦書き出すことで、理解の差異がわかって、議論ができる。一方的な説明では時間がかかりすぎるので、同時並行・即時・インタラクティブ・フラットに質問して確かめて、必要ならアップデートしていく。欲しいのは共有文書ではなく共通理解。

協調ワークショップというやり方です。

ユーザーストーリーマッピング