ソフトウェア開発の現場パターン -アジャイル型開発におけるプラクティス活用事例調査-
Agile2012に行って帰ってきて、結果として3つのことをやろうと思った。最初から考えていたわけではなく、今から考えると、3つあったんだということ。1つは、Agile2012のように活動家たちが集まれる場を作ること。これは、UltimateAgilistTokyoというカタチになった(「日本にも10年かけて育ってきた、"Agile"がある。)。Agile2012で海外のAgileの片鱗を垣間見ることが出来た。次は、日本の現場を訪ねてみたいと思った。日本の現場で育まれているであろう、様々なAgileのカタチを見てみたかった。海外と日本、それぞれから感じるものとその違いを確かめたくなった。これが、もう1つのやりたいことだった(残りのもう1つについてはまたの機会に)。
とてもタイミング良く、IPAで国内のアジャイル開発におけるプラクティス活用事例をまとめたいという事案が上がり、先のような個人的な思い入れもあって、この渡り船に乗らせてもらうことにした。
事例をまとめるために、日本各地の現場に伺わせて頂きました。時間を割いて、アンケートとヒアリングにご協力頂いた皆さんにとても感謝しています。皆さんの現場の生々しく、そして、いきいきとした創意工夫を伺えたことは、私にとってたいへんな財産です。先の活動家たちが集まれる場で掲げた「日本にも10年かけて育ってきた、"Agile"がある」のを、正に感じ取ることができました。
まとめたレポートには、様々な現場の工夫が織り込まれており、何らかの課題にあたる際に参考にして頂けるよう、パターン・ランゲージの記述形式を取っている。プラクティスの実践にあたっては、現場現場のコンテキストに影響される部分が大きいはずで、やはり工夫が必要になると思う。それでも、このパターン集が、様々な現場でその工夫の足がかりとなって、現場の開発の先を照らすようなランタンの役割を担えるとしたら、とても嬉しいし、そうなることを願っている。
｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
今回の調査、ガイド作成は、懸田さん、本橋さん、木下さん、そして、私の4人で取り掛かった。お三方と仕事が出来たこともまた良い経験でした。半ば挫けそうな時もありましたが、先輩諸氏のおかげで私も最後まで見届けることが出来ました。感謝します。
さて、このガイドはある時点でのスナップショットであり、もちろん現場では日々新たな工夫が生まれているわけで、本来このまとめ作業には終わりがありません(！)。この文書に関するフィードバックや、新たなプラクティスを何らかの形で残していけるように何か考えたいとも書き手では話しています。これを出発点にして、日本の現場の財産になっていけたら、良いなぁ。
<関連記事>
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年さまざまな局面でインセプションデッキを作ってきた。デッキ作りを重ねることで、いくらかの知見も得られた。
インセプションデッキを始める際の助言として、「本番前に失敗しておくこと」があげられる。本番は本番なのだ。数少ないチャンスを活かすために、本番では結果を出すことが求められる。だから、現場で実践する前に、社内やコミュニティで練習をしておくことを推奨するのだ。事前に手間をかけた分は本番できっと活きてくる。
インセプションデッキでひとことふたこと話せることも出てきたかなというところで、件の西村さんから、スクラム道の登壇を依頼された。西村さんはおそらく日本で一番インセプションデッキを作ってきた人なので、それをさしおいて話すことは何もないのではないかと思った。ただ、冒頭のとおりの経緯があって、私はここまでやってこれた事を思うと、ひとつのささやかなお礼になれば良いなと感じた。そうして、スクラム道に出させて頂くことを決めた。
