ジョナサン・ラスマセンのインセプションデッキ研修 : プロダクトオーナーにおすすめ

アジャイルサムライの著者、ジョナサン・ラスマセンさんのインセプションデッキ研修をお手伝いします。私は5年前に来日したときに受けました。

 

インセプションデッキ・トレーニング 同時通訳(1日間)

http://www.jp.agilergo.com/inceptiondeck-rasmusson-20161018

講師 ジョナサン・ラスマセン
日程  2016年10/18(火)

 

アジャイル開発でどうやってプロダクトバックログを作っていくか、ステークホルダー(利害関係者)からどうやって要件を引き出すか、彼は10個の手法を選んで、デッキにしました。

ジョナサンはモノを作る側の技術プラクティスには精通しており、正しく作ることはうまくいくのですけど、それでもプロジェクトが失敗してしまうことがある。なぜかというと、要件が不明確、もしくは、間違っていたわけです。

そこで作ったのがこのインセプションデッキです。確認すべき要件のリストです。それぞれがテンプレートになっていることが重要です。

このテンプレートを埋められるようにステークホルダに質問してみて、答えてくれればそれでよいし、なければ自分で埋めてみて「こう理解しているのですけど、どうですか?」と聞いてみれば「いやいや、こうですよ」というふうに情報を引き出せる可能性が上がります。

ジョナサンのインセプションデッキは10枚のテンプレートで構成されます。もしこれと違うものが必要になったら、自分のデッキを作ればいい(作るべき)と言っていました。まずはジョナサンのインセプションデッキを参考にし、足りない所があれば作ってみたり、不要なところを省いたりしながら、自分のものを作り上げていくといいでしょう。守破離です。

もし、ご自身のインセプションデッキの工夫があれば、ぜひ研修に持ってきて、こんなのあるよ!と聞いてみましょう!

 

  1. 私たちはなぜここにいるか?

  2. エレベーターピッチ

  3. ビジネスのビジョン

  4. 目的とスコープ

  5. 組織のコンテキスト

  6. 論理的スコープ

  7. 技術的ビジョン

  8. リスクマネジメント

  9. プロジェクト見積もり

  10. トレードオフスライダー

 

テンプレートを角谷さん(@kakutani) が日本語化して公開してくれています。

support/blank-inception-deck at master · agile-samurai-ja/support · GitHub

 

f:id:wayaguchi:20161005112933p:plain

f:id:wayaguchi:20161005113028p:plain

f:id:wayaguchi:20161005113041p:plain

 

f:id:wayaguchi:20161005113101p:plain

f:id:wayaguchi:20161005113114p:plain

f:id:wayaguchi:20161005113126p:plain

ブログを移設中

Movable Typeで置いてもらっていた古い日記(ブログ)をWordpressに移行するということで、こちらはデータを引き取ってはてなブログに移行中です。ついでに、はてなダイアリーで書いていた新しい方の日記(ブログ)もこちらこちらに移行しました。

手書き風のデザインにしてみたのですがちょっと読みづらいのでどうするか悩むところ。 ( => 更新: 本文のフォントは通常のゴシックに変更しました。タイトルは手書き風フォントのまま。)

f:id:wayaguchi:20160626192431p:plain

2004年のエントリーとかなかなか赤面モノなのですが、まあそれはそれでよい。

デブサミ2016 で発表しました : 実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう

デブサミ2016でお話しました。

前年の話を下敷きにしつつユーザーストーリーマッピングと、カイゼンの先に新規ビジネス開発をしてこそ....というお話をしました。

Day1の朝イチにもかかわらず、おかげさまで満席のお客様に入っていただきまして、ありがたい限りです。壇上に上がってから、2008年のデブサミに初めて参加して、奇しくも同じくDay1の最初のセッションで関さんの「8年目のアジャイル」のセッションに参加して、アジャイルのはじめかたとして「信頼貯金」のアイデアとか、テストの話を聞きまして、ああ、できないと思っていたけど、とっくに始めている人はいて、自分の環境でも始めようと思えば始められるのかもな、と思ったのを記憶しています。ちょうどその1年後には、スクラムを始めるべく準備のスプリントをしてました。そんな話を冒頭で語ってしまったので後半のスライドは全く未消化かつ、大事なとちきテストの会議の宣伝もできませんでしたが、資料には入っておりますので、ご参照いただければ幸いです。

以下に、資料と動画をおいておきます。

自撮り動画はこちら

https://youtu.be/W9vf18aY72k

スキルマッピング Skill Mapping

日経SYSTEMSさんで 2015年11月号から若手エンジニア向けのスキルについての連載をしております。主にスキルマッピングについて書いておりますのでぜひご参照ください。
http://itpro.nikkeibp.co.jp/SYS/

スキルマップについては2015年9月にXP祭りのライトニングトークでお話しました。
https://speakerdeck.com/kawaguti/skillmapping

その前に仙台のレッツゴーデベロッパーの懇親会で話してまして、その後 nemorine さんがブログで自作のものを公開してくださっています。
http://nemorine.hateblo.jp/entry/2016/01/27/140653

Rakuten Technology Conference 2015

今年も楽天テクノロジーカンファレンス2015 を行います!
11/21(土) 二子玉川楽天グループ新本社ビルです!
http://tech.rakuten.co.jp/

間違って品川シーサイドに行ってしまったら、りんかい線大井町まで出て、東急大井町線に乗り換えて二子玉川までだいたい40分くらいでリカバリーできますので、頑張ってたどり着いてください!

セッションスケジュールはSchedで公開中です。継続的にアップデートされてます。
https://rakutentechnologyconference2015.sched.org/

ライトニングトーク募集中です
https://docs.google.com/forms/d/18x0zE8GSkLo1DnnVWcD-QDqiGhIV83pAL80fHqXTQQk/viewform?c=0&w=1

マイクロサービスとスモールチームの話は切り離さないほうがいいと思う。

マイクロサービスとスモールチームの話は切り離さないほうがいいと思う。マーティン・ファウラーも書いてる。(きちんと読めているか自信がないので英語得意な方のご指摘をお待ちしております)

(原文) Martin Fowler のとこの Microservices
http://martinfowler.com/articles/microservices.html

How big is a microservice?

Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.

This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.

マイクロサービスってどれくらいの大きさなの?

マイクロサービスはアーキテクチャのスタイルとして有名になったが、この名前のせいで、サービスの規模やどうであればマイクロなのかといった、不幸な方向に焦点があたるようになった。マイクロサービスをやっている人たちと話した結果、サービスの規模がどのくらいになるのかを知ることができた。報告された中で一番大きな規模はアマゾンがいうところのTwo Pizza Team ( チーム全体がピザ二枚で間に合う人数 )で、つまり1ダース12人以内だ。一番小さいケースは5人で5つのサービスをみているという状況だ。

1サービスにつき12人と1人では大きな違いがあるので、マイクロサービスというラベルにまとめてよいのか、という疑問は浮かぶ。現時点ではまとめる方がよいと思われるが、今後さらにこのスタイルについて検討していくにつれ、考えが変わる可能性はある。

ユーザーストーリーマッピング増刷が決まったそうです

ユーザーストーリーマッピングの増刷が早くも決まったそうです。ありがとうございます。今後とも宜しくお願い致します。

http://www.oreilly.co.jp/books/9784873117324/

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

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