LeanCanvasとエリアの関連性から企画書を見る。
既にサービスの企画書があって、ソフトウェアとして何を作るべきかを考える状況でも、LeanCanvasが使える(LeanCanvasの詳細についてはこちらをどうぞ)。企画書の内容をLeanCanvasの各エリアに書き出していって、空欄のままになっているエリアや、内容が不足しているエリアを特定する。これから作ろうとしているサービスに、該当エリアの検討は必要ではないか、企画者と会話すべきポイントになる。
Canvasがある程度埋まった状態で、その内容を揺さぶる際には、どの課題がどの提供価値に対応し、どの提供価値がどの手段で実現できると想定しているのか、関係を確認したくなる。Canvasのままで関連を確認するのはやや煩雑になるので、関連表を別途用意してチェックしてみると、理解がすっきりした。
まず、軸は課題に置く。CanvasのProblemから課題を移してきて、今挙がっている課題の他にそもそも抜け漏れがないかチェックする。以降、関連を見るにあたっては、この課題を出発点にして、何に繋がるのか見ていくようにする。
次に、その課題を持っている対象顧客を見る、その前に、課題の背景を探る。これはCanvas上には無いので、企画者との会話が必要になるかもしれない。「なぜ、それが課題と言えるのか」の問いを元に、課題の背景にあるものを明らかにする。ここが問いに対して、あいまいだとすると課題設定が間違っているかもしれない。課題->背景、ここまでがなぜこのサービスが必要とされるのかという理由にあたる。
背景の次は、その課題を持っているであろう対象顧客を書き出す。ここは、CanvasのCustomer segmentから持ってこれるはずだ。「その課題を、この顧客は本当に持っているのか」という問いで、対象顧客として妥当かを確認する。
次は、提供する価値。もちろん、CanvasのUVPから持ってきて、課題との関連を確認する。最後は、価値を実現する手段。同様に、価値と手段の関連をチェックする。
以上のように関連を書き出していくと、課題->背景, 対象顧客->価値->手段が繋がることになる。解決されないままの課題や、あいまいな提供価値といったものが企画書上に存在した場合、ここで浮き彫りになるはずだ。確認の際、上記の表形式を利用したが、各項目間がN対Nになることがあるので、表にして埋めるよりは、図にして項目間を線で繋ぎながらチェックした方が良さそうだ。
橋頭堡の中から、ユーザーストーリーマッピング。
私が今の会社に入ってすぐに始めた活動に、ソフトウェア開発の入口を揃えるというものがあった。開発の入口を揃えるとは、どういうことかというとお客様と開発会社がソフトウェア開発を始めるときの認識や状況を整えましょうということ。たいてい、必要なソフトウェアについての何らかの企画・コンセプトがあって、さらにブレイクダウンされた要求が記述されたドキュメントがあったり、もっというと画面仕様書までお客様が用意している場合がある。ただし、それらを開発側が受け取りすぐに開発に取り掛かれる状態になっているかというと、なかなか難しい。「画面設計まで終わっていて後は作るだけです」というフレーズをこの世界に居る人達なら、たいてい聴いたことがあるのではないだろうか。現実には、要件定義とは何だったのか、から考え直すことを迫られるわけだが。とかく、この認識と状況と期待がお客様と開発で一致していないことには、引き受ける開発も場合によってはずいぶんと苦労することになる。もちろん、お互いにだ。
では、何が揃っていれば、開発が始められるのか。このあたりは、アジャイルサムライ−達人開発者への道−などの書籍にあたってみるのが早いと思うので、そちらを読んで欲しいのだけど、1年半前の2011年10月頃に、私が考えたのはいかにしてお客様の視点でかつ開発側が受け取れる形で要求を抽出し、整理するかということだった。道具立て自体はいくらでもある。大事なのは、その後に来る僕らの開発に繋がるためのやり方を模索するという点だった。開発のやり方は現場によって異なるから、一概にこうするべきとは勿論いえない。ただ、要求を整理するのに、重たいプロセスと時間をかけるスタイルは、僕らの開発に合ってないのは言わずもがなだった。このあたり、場合場合によって現場で上手く進めてきていたものの、やり方についての何らかの整理は必要だと、開発を始める前のお客様との会話の中で特に感じた。あるべき入口について伝えるためには、その形が提示できなければならない。
最初のアイデアが出たのは、天野勝さんからだった。ユーザーストーリーを用いた整理の仕方、ユーザーストーリーマッピングのことだった。関係者が集まってワークショップ形式で行う。天野さんから厚い参考資料を預かり、読み解いてみると良い雰囲気はあるが、実感はない。素振り(実践前の練習)が必要だった。課題感に乗ってくれた、安井力さん、家永英治さんの2人とで、繰り返し素振りを始めることにした。本当に繰り返しで、数をこなした。素振りをするには相手が必要だ。最初は事故を起こしても無事なように社内で。次にコミュニティでの繋がりから。かなり最初の頃に、友人のあまのりょーさんに素振りをお願いして、オフィスに伺わせてもらったこともあった。いつもコミュニティの会場提供でお世話になっている、甲木さんにも弊社に来て頂いたこともあった。数をこなす中で、進め方の勘所が掴めたら、より実践に近く、懇意にさせて頂いているお客様にお願いをして開催させてもらった。
この頃になると、このワークショップをどう提供していくかという話をしていた。ユーザーストーリーマッピングは開発プロジェクトの最初に1回行なって終わる類いのものではないが、入口を揃えるという点では、開発を始める前にも行うのは間違いない。すなわち開発契約とは別に提供することになる。企画書を作るために、ワークショップ形式で短い時間でざっくりと全容を押さえるのは、有効なやり方だ。やってみた結果、企画の練り込みがもっと必要なことが分かり、開発を始めないこともあるかもしれない。このワークショップは、お客様からの依頼を受けたタイミングで都度開催する、ひとつのサービスとして提供していくことを決めた。
その後、フィジビリティスタディとして、単発でセミナーを開いた。セミナーを開くためにはまた素振りを行う。同僚の浦嶌くんたちに協力してもらって、安井さんの自宅で休みの日に行ったこともあった。セミナーを開いてみると、いくつかの課題が分かってくる。例えば、そもそも僕らが始めるサービスをお客様に伝える手段が必要だ。このワークショップを特に届けたい相手は、開発を依頼する前の段階、企画を練っている方に向けたいわけだが、折もよく相手に伝える手段を持ち合わせるのは難しいことだ。そこで、ユーザーストーリーを用いたワークショップや、僕らがそれに取り組んでいることを広く知ってもらうために、ある企画を立てた。それが、Jeff Patton☓平鍋対談だった。2012年の秋ごろに、ユーザーストーリーマッピングを提唱したJeff Pattonが来日するタイミングがあった。彼の日本でのマネジメントを担当していたアギレルゴの川口さんと相談して、アギレルゴさんとのセミナーを共催した。この企画には多くの方に参加してもらうことができた。
ところで、このワークショップをサービスとして提供するための活動は、通常の仕事にアドオンされるため、常に他の仕事との調整が発生する。プロジェクトが忙しくなると、こちらに避く時間は限りなくなくなる。何かを始めるときには必ずつきまとう話だ。案の定、進行は遅れた。
さて、サービスとして提供するからには、ランディングページが必要だ。デザイナーの方に、いい感じのページをお願いしたい。ところが、デザイン方面の方々との繋がりはあまり太くない。しかも、僕らの取り組みを理解して、デザインをしてもらうとなると、なおさらだ。幸いにして、Rubyコミュニティからフィヨルドの町田さんと繋がり、町田さんから、デザイナーの方々を紹介して頂くことが出来た。自社の予算との調整を経て、最終的に、前田製作所の前田さんにお願いすることになった。そして、ページは完成した。
そう、ようやくご提供できるようになりました。
ここまで、影に日向に支援して頂いた角谷さんを始め、このエントリに出てきた方々、協力して頂いた方々に、感謝をしたいと思います。ここまで来るのに、恐ろしく時間がかかりました。いつ途中で終わってもおかしくなかったけども、続けてこられたのは、皆さんのおかげです。本当にありがとうございます。とても小さいけれども、これは僕にとっては、課題山積の中掴みとった橋頭堡みたいなものです。これからが、また次の始まりで、このサービス自体を僕や安井さん、家永といった中心のメンバーが育ていく必要があるし、また別の橋頭堡を築かなければならないのだから。
憧憬と共感のはなし
人が自分ではない他者からの影響を受けて具体的な行動を起こすには、2つの感情が湧いているような気がする。それは、憧憬と共感。つまり、「ああ、なりたい」という憧れ。ただ、この憧れだけでは、「あれはあの人だから出来ること」で終わる。勉強会やカンファレンスに行って、遠く前で話をしているエライ人を眩しく見つめて終わる。一方、憧憬とともに、「あの人もそうあるために、トライしているんだ」といった、彼の人の姿勢に対する共感が生まれると、自分の行動に繋がるような気がするのだ。何よりこういった感情と行動の関係は身を以って経験をしてきた。
8月、ダラスに渡る前に、グラグリッドさんを訪問した。グラグリッドさんは、UXデザインやグラフィックファシリテーション、ビジネスモデルのプロトタイピングをサービスとして提供されている。こちらの代表の尾形さんとは、とある機会でほんの少しばかり話をすることがあった程度で、単身訪ねていくほど強い繋がりがあったわけではない。
なぜ、尾形さんに会おうと思い立ったか。仕事もコミュニティの活動も忙しい中で、それでも尾形さんに会いに行きたいと思ったのには、尾形さんに対する憧憬があったように思う。いや、その時はそこまでの感情はなかった。そうではなく、期待があったのだ。自分には無い、グラグリッドに行けば何かが見つかるような気だけがしていた。会社もコミュニティも充実した時間を過ごしている。それでも何かを見落としている気がしてならなかった。それは、今思えば、自分の外にあるものへの過度な依存、この依存に対する恐れだったのかもしれない
尾形さんは、三澤さんとお二人でグラグリッドの運営をしている。起業するまではユーザビリティにまつわる仕事を手がける会社に在籍されていたとのこと。2011年にグラグリッドを設立されている。起業という、自分で全て背負って生きていく道を選んだ、尾形さんの強さに、私は憧憬を感じた。しかも、尾形さんと私の年齢はあまり変わらない。同年代の方の起こした行動の強さが、純粋に逞しいと感じられた。
グラグリッドさんが手がけるビジネスモデル・プロトタイピング・センター「カミヒコウキ」は実にユニークだ。フューチャーセッションという対話を中心として、コミュニケーションでビジネスモデルを探っていく。フューチャーセッションは、私のマスターの一人、野村恭彦さんがこの数年普及を進めている、問題解決のための対話の場のことだ。尾形さんは、そのフューチャーセッションを応用して、「カミヒコウキ」を提供している。フューチャーセッションは、私も推し進めたいと考えている概念であり、それを中心に据えたアプローチに、強く共感をした。
人は、日常においては無意識のうちに自分の手の届く範囲内で生活を収めようとしているかもしれない。日常では出会わない人の方を向いて、話をすることはパワーが要る。だが、それを乗り越えたとき、やはり、得難い何かがあると思う。私は、尾形さんと話をしたのち、意図的に人と会うようにした。LeanStartupJapanの和波さんであったり、学習パターンの井庭先生、エクスペリエンスビジョンの山崎先生。いずれの方も、強いメッセージをくださった方々。様々なご協力を頂いていて、感謝しております。そして、私の小さな世界を開く切欠をくださった尾形さんに。
さて、私が感じていた恐れについては、ダラスに渡り、帰国してからすっかり変わってしまった。その話については、また別のところで。
Ultimate Agilist Tokyo で The Art of Agile Project Managerの話をします。
11月17日のUltimateAgilistTokyoでは、The Art of Agile Project Managerというタイトルでお話をさせて頂きます。タイトルは、アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) から。The Art of Agile Project Managerという書籍があるわけではないので、あしからず。お話の元ネタは、9月7日に発表した、PMシンポジウムのものをベースにする予定です。PMシンポジウムでは、2時間30分(!)喋り倒すべく、200枚を越えるスライドを用意しました(スライド未公開)。ちなみに、PMシンポジウムでも同タイトルで、Agile開発のPMに求められること、についてお話を致しました。あちらのカンファレンスでは、Agileとは?から始めたので、多くの言葉を必要としましたが、今回のUltimateAgilsitTokyoでは、そのあたりの導入はばっさり省き、核となる部分について、より突っ込んで話をしたいと思っています。
プロジェクトを始めるには、入り方があります。例えば、はじめてのステークホルダーとプロジェクトを始める場合、お互いがどういう期待を持っているか分からないものです。開発チームには、開発チームのやり方があり、そのやり方が今回のプロジェクトでも取れるか、適していのるかどうか最初は分かりません。それは逆もまたしかりで、そのプロジェクトにソフトウェア開発に詳しくない、ビジネス企画やプロダクトオーナーが居るとしたら、彼らもまた、今回のソフトウェア開発に何をどこまで期待できるのか分からないものです。互いの期待が分からないままに、プロジェクトを始めることで、後になって「話が違う」となるのはよくあることです。難しい問題ですね。
テラフォーミングという言葉があります。"人為的に惑星の環境を変化させ、人類の住める星に改造すること(Wikipediaより)"という考え方。同じことがソフトウェア開発のプロジェクトでも言えるように思います。私たちがプロジェクトを始められるようにプロジェクトを地ならしする時間が必要です。互いの期待をメンテナンスする、期待マネジメントは、プロジェクトのフォーミングに必要な主要タスクと言えるでしょう(ひとことふたことの言葉にするほど決して簡単ではないのですが)。詳しくはUltimateAgilistTokyoにてお話します。
ご参加はこちらから。
Your Mind is the Scene of Development.
お客様先で、インセプションデッキを作ろうとして、西村直人さんに「そのままやったら事故るで。」と言われたのは、ちょうど1年前のことだったと思う。西村さんのインセプションデッキ作りを目の当たりにして、そのファシリテーションの難しさと得られる効用を同時に理解したのだった。あれから、1年さまざまな局面でインセプションデッキを作ってきた。デッキ作りを重ねることで、いくらかの知見も得られた。
インセプションデッキを始める際の助言として、「本番前に失敗しておくこと」があげられる。本番は本番なのだ。数少ないチャンスを活かすために、本番では結果を出すことが求められる。だから、現場で実践する前に、社内やコミュニティで練習をしておくことを推奨するのだ。事前に手間をかけた分は本番できっと活きてくる。
インセプションデッキでひとことふたこと話せることも出てきたかなというところで、件の西村さんから、スクラム道の登壇を依頼された。西村さんはおそらく日本で一番インセプションデッキを作ってきた人なので、それをさしおいて話すことは何もないのではないかと思った。ただ、冒頭のとおりの経緯があって、私はここまでやってこれた事を思うと、ひとつのささやかなお礼になれば良いなと感じた。そうして、スクラム道に出させて頂くことを決めた。
日本にも10年かけて育ってきた、"Agile"がある。
2012年8月、Agile2012に参加してきました。Agile Conferenceはその名のとおりAgileをテーマとしたカンファレンスで、世界中から参加者が集まるグローバルなカンファレンスです。書籍の中でしか会えないと思っていた著名な方々も多数集まる。スコット・アンブラー、ジム・ハイスミス、メアリー・ポッペンディーク、ヘンリック、エトセトラエトセトラ。いずれも、最高のヒーローたちだ。そう、Agile Conferenceは、Agileのアベンジャーズが集まる場なのだ。そういう人たちが、たいていセッションを持っていて、成果や新しい発見について披露する。参加者は、5日間さまざまなAgileストーリーに浸かることになる。極上の時間だ。
会期中のセッションやカンファレンスの様子についてはManasLinkのレポートページで確認することができる。今回、私は、藤原大、伊藤さん、及部くんとレポートチームを組んで、カンファレンスに参加した。私のレポートも数本だが上がっている。
参加セッション: Scaling Agile with Multiple Teams: Using Lean to Drive Business Value
スピーカー: Alan Shalloway
参加セッション: Lean from the Trenches: Managing Large Scale Projects with Kanban & Scrum & XP
スピーカー: Henrik Kniberg
参加セッション: Scaling Lean|Agile Development to the Large Enterprise with the Scaled Agile Framework
スピーカー: Dean Leffingwell
さて、Agile2012の開催地ダラスから帰ってくると、自宅にある小冊子が届いていた。差出人は、大阪の細谷さんだった。冊子は、私も寄稿しているUltimateAgileStroyという自費出版物だった。細谷さんが編集長を務め、複数人の記事を集めた、Agileをテーマとしたアンソロジーだ。今年は2巻目になる。
一読、感想として抱いたのは懐かしさだった。この冊子に出てくる執筆者には、私が5〜6年前にコミュニティで出会い、今はほとんど会うことがなくなってしまった方々が多く含まれていた。会わなくなった理由は、単純にお互いに忙しいということと(本当に忙しくなったと思う!!)、出会うきっかけ、場が無いからだ。Agileに関するコミュニティや場は、昔に比べて大いに増えた。ところが、彼らと顔を合わせるような場は、いつの間にか無くなっていることに、私は本を読み終えて気づいたのだった。
文章で、彼らの考えていることを垣間見て思った。互いの考えや活動について、せめて1年に1回くらい、伝え合うことがあっても良いのではないかと。おそらく、自然に遭遇することを待っていても、その確率は低い。場がないならば、作るまで。すぐに、細谷さんに一筆、提案のメールを送ったのだった。8月20日のことだったから、本当に帰国してすぐに思い立ったのだ。日本の活動家たちが集まる場を作ることを。
活動家たちが、1年に1回集まり、各々の成果や新しい発見について語り、互いに交換する。そこで語られる言葉は、現場で磨かれた本物の言葉だ。大いなる刺激と誉れが得られることだろう。そして、また、現場、自分のフィールドへと戻り、自分の言葉に対するフィードバックを活かす。そう、これが私の目に写ったAgile Conferenceの姿だった。Agile Conferenceのような場を日本でも開きたかった。
UltimateAgileStoryの執筆者の中から、この場への登壇をオファーした。場のコンセプトをお伝えすると、日程的にご都合のつかない方を除き、オファーした全ての方から快諾を頂いた。後から考えると、これは凄いことだと気づいた。この場は、全く新たに作る場になる。まだ、一度もカタチになったことがないのだ。そういう未だ概念のものに、乗ってやろうではないかと、言ってもらえた。本当にありがたいことだった。
ひととおり、セッションテーブルを組み、予算を検討し、企画書をまとめたところで、藤原にそれを見せた。藤原に企画書を見せた理由は2つあった。1つは、Agile2012でかなりの時間を共有した藤原がこの場を見てどういう反応を示すか確認したかった。もう1つは、彼が私をAgile2012に連れて行った経緯にある。AgileConferenceは毎年行くかどうかの逡巡を繰り返している。彼の強力な後押しがなければ、おそらく私は今回もスルーしていたことだろう。その彼に、AgileConferenceに行って帰ってきた私の行動として、この企みを知ってもらいたいと思ったのだ。この企画書を読んだ藤原は、この企みの実行に手を貸すと言い出した。こうして、UltimateAgilistが集まる場が、実現に向けて加速し始めることとなった。
そして、我々は、この場に、UltimateAgilistTokyoと名付けた。
http://ultimateagilist.doorkeeper.jp/events/1823
ぜひ、この場を訪れてみて頂きたい。そこには、日本が10年育ててきた、Agileがある。
