『Running Lean -実践リーンスタートアップ』刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN に参加しました

今夏、社内の一部でも盛り上がった英語版のRunning Lean。
Lean Startupを読んで「さぁ何かやってみよう！」と盛り上がるものの、具体的に何から手を付けていいのか判らない。といったモヤモヤした部分に一筋の光を与えてくれたのがRunning Leanでした。
しかし英語の壁は高く、盛り上がりはやがて自然消滅。
このたび、そんなRunning Leanの著者の来日講演が聴ける！ということで東京ミッドタウンのヤフー株式会社様にお邪魔しました。

事前準備

実は以前、Running Lean入門ワークショップ#2 に参加していたため、日本語版の本は前日にGetできました。
8割くらいを読んだ状態で望む事が出来、事前準備万端です。

Running Lean

最初にアッシュ・マウリャさんからのお話。
参加者について簡単にアンケートを取っていましたが

• 開発職＝約７割
• マーケ・営業職＝少し
• 起業を考えている人＝若干名
• リーンスタートアップを知っている人＝ほとんど

自分にとっては少々意外な結果でした。
流行を掴むアンテナをエンジニアは普段からも鍛錬されているためでしょうか。
肝心の本編については、ほぼ本に書いてある内容でしたので割愛します。気になる人は本嫁！

大組織の中でのリーン

発表資料はこちら
iPhoneアプリ開発を振り返って、知らず知らずに Build→Measure→Learnが回っていたというお話。
自分の経験も振り返ってみると確かにうまくいったプロジェクトは自然に「もっと良くしよう」というような意識が働いていましたし、Build→Measure→learnとまでは言えなくても好循環のサイクルが回っていたように思います。
リーンを実践してクビになったら弊社へ。ってまさにそうですね。
スクラムマスターもクビになって一人前と誰かが仰っていたなーw

感想

色々と盛りだくさんなイベントでしたが、自分が一番衝撃を受けたのは「爆速」でした。
会社やサービスの問題を自分事として捉え、自発的に行動する事の象徴＝「爆速」。
このような精神が社員一人一人にまで行き渡っており、能動的に活躍できる大組織は滅多にあるものではないと思います。
つい数日前にクックパットさんのお話でも感じたことですが、ビジョンが共有され浸透している組織の強さを改めて学ぶ事ができました。
内発的動機付けの話をすると大概が性善説vs性悪説の話になってしまい、議論どころでは無くなってしまうのですが
何かヒントが得られたような気がします。

DevLOVE Conference 2012に参加しました

12月15日(土)、16日(日)と行われたDevLOVE Conference 2012に参加しました。
とは言え諸事情により16日は参加できず、15日だけの参加となりました。
会場は渋谷マークシティのサイバーエージェントさん。
むかーし別フロアでお仕事をしていた時もあり、非常に感慨深いものがありました。

開場後すぐの様子。当時100人強がこの広さで働いていたんだなぁ。。。

私とDevLOVE

私とDevLOVEの歴史は、浅過ぎてお話にもならないレベルなのですが
初めて参加したのはLeanStartupNightの回。
次はEnterprise User eXperience Design - ユーザー中心設計の実践 -
今回が3回目の参加でした。
しかし、私のような新参者にも広く間口が開かれていますし、参加のしやすい敷居の低さは流石だと感じました。

参加セッション

私の参加したセッションは以下です

• アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
• Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜
• エンジニアの未来
• ソフトウェアエンジニアが、UXに興味を持って進んできた一つの道
• 【徹底比較】SIerとWeb系はココが違う！　キャリアチェンジしたエンジニアが見た両者の現場から
• どこでも生きていけるエンジニアを目指した後に見えるもの
• DevLOVE2012渾身会(懇親会)

感想

自分は今エンジニアと呼べるような活動はしておらず、コードも全く書いていませんが
参加者の皆さんの並々ならぬ情熱に刺激され、自分もそろそろ重い腰を上げないとな。。。という事を痛感しました。

セッションで一番印象に残ったのは、SIer経験と某レシピサイトについてお話していただいた@takaiさん。
会社として１つのビジョンがあり、それが社員ひとりひとりにまで行き渡っている事の強みをひしひしと感じました。
その後の渾身会でも少しお話をさせていただき「仮説構築能力」の話に。
仮説は検証が可能でなければならないのですが、その検証方法や期待している結果がぼやけていると、結局その仮説で何を達成したかったのかがフワフワしてしまいがちです。
リーンスタートアップのような方法論を実践しようとすると、(いまのところ)だいたいネックになるのは「仮説構築能力」です。
こういった能力を引き上げるための訓練、練習、素振りを今後どうしたものか。悩みは尽きないですね。

最後になりましたが、運営の皆様、参加者の皆様、大変お疲れさまでした。 このような大きなイベントに参加することができ、たくさんの刺激をいただきました。 またどこかの回にお邪魔させていただきたいと思います！

スクラムを活用したアジャイルなプロダクト管理を読みました

スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発

とても薄いので(正味120ページくらい)一気に読むことができました。
と、いっても３時間かかりました。もっと早く読む技術が欲しい

この本はスクラムチームの中で、プロダクトオーナーとして何を考え、どう振る舞えば良いのかが書かれている貴重な１冊であると思います。
プロダクトオーナーを新たに始めるという方には教科書となるのではないでしょうか。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

今までは「アジャイルな見積もりと計画作りを読んでね。」とお勧めする事が多かったのですが
この前段階として今後布教していきたい１冊です。

しかし、プロダクトオーナーの一番大変な仕事は「何を作るか」を考え、見つける事です。
その方法は教えてくれていません。
見つけるための手法は、日々様々な形で議論されていますが(UX界隈や、LeanStartup界隈等)
それらもうまく活用できなければ、ゴミを大量生産するだけです。

本の６章にも書いてありますが、絶えず成長し続ける事こそが本当は大事な事なのではないでしょうか。
自分の弱点を理解することは辛いことですが、弱点がわからなければ補強のしようがありませんね。

この本をきっかけとして、自分の周りにも更に良い風が流れてくれる事を期待します。

ジェフ・パットン 情熱プロダクトオーナー研修に参加しました

http://jp.agilergo.com/23
10/18～19の2日間かけて行われた、ジェフ・パットン氏によるプロダクトオーナー研修に参加しました。 この研修はScrumAlliance公認のCSPO研修でもあり、これで晴れてCSM兼CSPOとなったわけですが。。。
自分の理解がまだまだという事もあり、自分への戒めとして簡単に整理してみようかと思います。
まさにチラ裏。

参加背景

現在は社内でスクラムマスターの方を支援するような、誤解を恐れずに言うと「コーチ」業をやっているのですが
自分がエンジニア出身ということもあり、プロダクトオーナーへの理解が足りていないと常々思っていました。
「プロダクトバックログ」を用意して「優先順位」を付けて下さい。以上！といった突き放しになっていた場面もあったかもしれません。
そういった知識の偏りをなんとか解消すべく、会社の方々にも理解していただき、参加できる事となりました。

研修内容

いろいろとネタバレを含むと不味そうなので割愛します。
タイトルは釣りです。

得られたもの

プロダクトオーナーとして振る舞うのは物凄く大変な事なのだ。という事を改めて気付かされました。
「誰を、どのようにハッピーにさせるのか」を考える場合には様々なスキルが必要とされますが、これらのスキルを全て身につけた人間はそうそういません。
ですので、色々なスペシャリストでProduct Ownership Teamを作る。様々なツールや会話(Conversation)を通じて成功率の高いプロダクトを「発見」する。
まさに課題であると感じていた部分でもあるので、是非こういった流れに取り組んでいきたいところです。

一方で「実際に現場で実践していこう！」という所まで理解が至っていないというのが現状です。
ユーザーストーリーマッピング、プラグマティックペルソナ、UIプロトタイプなど、それぞれの手法はもちろん、背景にある考え方などは理解できましたが
実際の現状のプロジェクト、プロダクトでは、どう活かしていくべきなのか。。。
全部大事な事だとはわかっていつつも、色々な事情を考えて、実践できない理由を探してしまっている自分がいます。

悩んでいてもしょうがないので、まず「やってみる」戦法が大事なのかもしれませんね。シャドーボクシング重要。

また、プロダクトオーナー研修と銘打ちながら、各所にリーンスタートアップの考え方が散りばめられている事も印象に残りました。
一歩引いて考えれば、現代に生きるプロダクトオーナーとしては当然必要とされる考え方だとは思いますが、ここまで散りばめられているのか。と正直ビックリした部分もあります。本、読んでおいて良かったなー。。。

まとめ

非常に有意義な2日間でした。
今後の自分の人生にとっても、間違いなくプラスに働く知識を得ることができました。
そして、もっともっと探求しなければいけない分野が山ほどあるということにも気付かされました。
今後も一歩ずつ精進して参りたいと思います。

第34回すくすくスクラム ～スクラム・ロールプレイング～に参加しました #suc3rum

参加レポートというほどのものではないです。

開催概要

http://kokucheese.com/event/index/56300/

最大14名という狭き門に滑りこむことができました。すくすくスクラム初参加です。

今回は海外からSergeyさんがゲスト参加ということもあり、無料にも関わらず 10:00～20:00までという

濃いい内容でした。

注意事項

はじめにebackyさんから今回勉強会を通じたお約束事 Working Agreement が登場します

• 失敗は最高の宝
• くだらない質問はない
• 学習は自己責任
• 楽しむ(Have a fun)
• あるものは使う 利用する
• ノートPC,携帯電話はNG。

土曜日の開催、プライベート時間なので「学習は自己責任」という言葉は特に強く印象に残りました。

また、今回のワークショップにもたくさんのワナをしかけて失敗させるつもりですとのお言葉も。失敗なくして学習することはできない。

進行方向

スクラムの勉強会は、当然進行もスクラムっぽく進んでいきます。

アジェンダが用意され

完了したタスクがDoneにシフトしていきます

当然のようにバーンダウンチャートも完備

今後の予定は何なのか、現在の進行状況は順調なのか等は通常ファシリテーターや運営側にしか見えないものですが 参加者にもオープンになっていることで参加者側にも安心感が生まれます。 この進行方向は、是非どこかで自分も活用したいなと思いました。

ワーク内容について

詳細はネタバレをたくさん含むことになるので割愛しますが、テーマは街作り。

１つのグループの中でプロダクトオーナー、スクラムマスター、チームの役割を演じながら

どんな街を作るのかを考え、その後に短い間隔で「スプリント計画」、「スプリント」、「レビュー」、「振り返り」を行いながら

レゴで街作りをしていきます。

結果、我々チームの最終結果は下のようになりました。

学んだこと

今回は街づくりというテーマで、実際に街を作っていくという作業を行いましたが

• 協働することの大切さ、難しさ
• ビジョンを明確にするためのポイント

といったことも当然ながら、なんといっても「ユーザの声を聞く」という当たり前の行動が、実はなかなか出来ないということを痛感しました。

作業に追われると、自分たちの作りたい物ばかりを考えてしまい、実際に利用してくれるユーザの声は時に邪魔に思えてしまう時もあります。

たとえ1スプリントの結果に見える成果が無かったとしても、ユーザの声に耳を傾ける時間を作るほうが重要な時もあります。ユーザの望んでいない物を急いで作ったところで、それはゴミである確率が高いためです。

そしてユーザの声はダイレクトに自分の耳で聞くということが重要です。誰かが集めてきた意見は、集めた人のフィルターを通した偽物になってしまうこともあるからです。

いざユーザの声を聞いてみよう。と思ったとしても「誰に聞いていいのかわからない」といった状況が訪れる場合があります。そもそも誰向けに提供しようとしているのかが定まっていないということであり、とても危険な兆候であることに気付かされました。

こうして並べてみても当たり前すぎる話なのですが、この当たり前を実行することがとても重要であると再認識できました。

まとめ

すくすくスクラムは初めての参加でしたが、初参加者でも気軽に参加できる雰囲気があり、楽しく学ぶことが出来ました。

過去の資料を見ても楽しそうな回が多いので、またどこかで参加させていただきたいと思います。

運営の皆様、参加者の皆様お疲れ様でした。ありがとうございました。

スクラムにおける納期

いわゆるプロマネをやっていた人にプロダクトオーナーとして振る舞ってもらう場合によく受ける質問。

以前は機能Aのリリース日はn月m日。としてプロジェクトを進めることができていた。

スクラムではそれをどうやって実現すればいいのか？

というもの。

そもそも、何故今までは n月m日 にリリースできていたかというと

・たくさん残業して間に合わせた

・実はもっと前に終わっていたけど、n月m日まで待っていた

・たまたま

といった理由であることが多い事をまずは知る必要がある。

A機能が本当に重要であるならば、n月m日よりも前にリリースしたいはずだ。

であれば、エンジニアリソースはA機能に集中させるべきだし、A機能として充分に役割を果たすことが出来、且つ、余計なものが一切無いという機能要件を狙えれば、納期を早める事も可能性として充分にあるはずである。

スクラムではこういった思考の変化や切り替えがあってこそ

「いいものを早く出す」という事を繰り返し可能とする。

それでもプロジェクトの陣頭指揮をとっていた人などにとっては「こんなあやふやなスケジューリングでうまくいくはずがない」と思われがちだ。

そのためにも、スプリントレビューでは動くもので進捗を伝えなければならないし

そのためにはプロダクトバックログを綺麗に保つ必要があって

そのためには定期的なリファインメント、グルーミングの必要があって、、、

と、話しが逸れてしまったが

リリース日に間に合わせることができるんですか？と聞かれた時の答えとしては

「リリースできそうだと思った時に、すればいいと思います」

ということでFA。

リリースとスプリントレビューに対する誤解

 優先順位の高い「A」というプロダクトバックログをスプリント前半で消化できた場合、この「A」はスプリントレビューを待たずにリリースしても良いのか

社内でも良く質問を受けるし、スクラムに関する誤解の一部でもあると思うので

自分の考えを書く。

「リリースできる状態になったけど、あと1週間待って下さい。スプリント中なので」

などという事は普通に考えてナシである。常識の範囲内でナシである。

1日、もしくは数時間の遅れが命取りになるかもしれないこのご時世で

そんな悠長な事は言っていられないはず。

なので自分の答えとしては「好きな時にリリースして下さい」なのだけど

そうすると次にくる質問は大概、

「じゃあ、スプリントレビューはやらなくてもいいんですか？」

という、スプリントレビューに関する質問。

よく書籍などには「スプリントレビューはプロダクトオーナーがリリースジャッジを行う」というような事も書かれているが

多分これは数年前の話であって、今もそこを信じ込む必要は無い。

では何なのか。

スプリントレビューは、フィードバックをもらうための場だ。

ウォーターフォールでは「仕様変更」として扱われがちだった改修提案を、フィードバックという前向きな提案として扱う。

このフィードバックにも優先順位を付けて管理することで、よりよい製品に仕上がりやすい作用を生んでいる。

優先順位の高いものから組み立てていくため、そこに対するフィードバックも自ずと優先順位が高いことがほとんどだからだ。

というわけで、リリースはいつでも出来るべきだし、リリースした／していないに関わらず、フィードバックによって変更される（できる）可能性があるのであれば、スプリントレビューは行うべきである。