ダラスからの帰り道、Lean from the Trenchesを日本に届けようと思った。
目の前にいる彼の口調は若干、いや、相当早かった。時おり顔全体を笑顔でゆるませて、早口に語りかけるのであった。私は、彼の語る「自分たちの現場の物語」に、引きこまれた。彼の名前は、ヘンリックといった。
2012年の夏に開催されたAgile2012のヘンリックのセッションに参加して、私はレポートを書いている。
へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート
彼の書籍「Lean from the Trenches」は、PragmaticBookShelfから出版されている。Agile2012でも書籍販売ブースに並んでいた。彼のセッションを聞いて、私は彼の物語を日本に持って帰ることを決めた。
Agile2012に行って、その帰り道に、日本に戻ったらやろうと思ったことが3つあった。最初の1つは、カンファレンスの開催だった。
もう1つは、日本の現場をフィールドワークすること。
ソフトウェア開発の現場パターン -アジャイル型開発におけるプラクティス活用事例調査-
最後の1つが、この物語を日本に居る友人たちに紹介するということだった。Lean from the Trenchesは、理論をまとめたものではなく、ヘンリックが実際に現場で工夫してきたことを生々しく描いた、実践の本である。より良い仕事をしたいと、前進し続けようとする開発現場にとって、この本は、向かうべき先を示すコンパスになりうると思った。
さて、この本の訳をどのように進めるべきか。何しろ商業本として翻訳に携わるのは初めてのことだ。一人で進めるには何かと心もとない。ふと、アジャイルサムライを手にとってみると、そこには2人の監訳者の名前があった。アジャイルプラクティスも、アジャイルな見積りと計画づくりも、2人だ。そうか、翻訳は2人だ。相方を探さなければならない。この本を訳すからには、当然この本を気に入ってくれる人を探すべきだ。ほどなく、一人の男を思い浮かべた。藤原大だ。
2012年の暮れも押し迫ったある日、彼の家にカニ鍋を食べに乗り込んだ。楽天市場で彼が購入したカニは実に美味しかった。鍋を挟んで、彼はいつものように何でもないように応えた、と思う。
「やるか。ぱんだ。」
こうして、2人の本作りの旅は始まったのでした。それは、短くも、長い旅の始まりでした。今、書籍刊行の予告を打てるまでに至ったのは、相棒の大はもちろん、多くの人の協力があってのことです。本当に感謝をしています。
Lean from the Trenches 日本語翻訳版 2013年秋頃予定
出版までは、あとラスト3マイルくらい。僕らは向かい続けることにします。
時を超えた共に開発する者への思い。
2009年ごろ、所属していた海外沿いのSIerにて、社内の組織を超えた繋がりを作る目的で、社内イベントを開催していた。この開催の後に、自分が残してたエントリを覗いてみて驚いた。
このイベントに込めた思いが、この会社が続く限り、 生きていて欲しいと願う。
これを読むと、すでに自分がこの回で社内イベントの開催を最後にするつもりだったのが伺い知れる。この社内イベントは、100名くらいが参加する、手作りのカンファレンスで、もともとデブサミに触発されて始めたものだ。社内にデブサミのような、自分たちの技術や知識や経験、そして熱さを存分に語る機会を設けようという思いから始めて、この2009年で第3回目を迎えていた。
2008年にはenterprisezineに取り上げてもらった。
身近な仲間と繋がり、刺激を与えあう「社内デブサミ」はいかにして生まれたか
実際のところ、2009年以降社内版デブサミが開かれることはなかった。私も、当時一緒に企てを推し進めていた友人たちも、一人、また一人と件のSIerを後にしたのだった。
それから時は流れ、共に社内版デブサミを企画をしていた、川島義隆さんとはコミュニティの方で繋がりを持ち、コミュニティのカンファレンスや関西イベントでの発表など、力をお借りしていた。お世話になりっぱなしなので、少しでもお借りしているものを返したいという思いから、件のSIerでコミュニティとしてイベントを開き、川島さんに話をしてもらう企画を思い立った。
川島さんの話は、「ふつうの受託開発」と呼ばれる全くふつうではないお話で、いつもはコミュニティで話をしてもらっていたが、本当に届けたい先は、社内の他のメンバーなんだと分かっていた。だから、会場を海外沿いのSIer(もう海外沿いから移転している)にして、社内の人たちが気軽に川島さんの話を聞きに来れるという建付けとした。
開催日は、あえてデブサミ2013と同じ日の夜にした。デブサミに参加する人たちの多くは、参加のための社内の調整がついていたり、何かアクションを起こそうとしている人たちだと考えられる。
しかし、デブサミに行きたくても日常の仕事からどうしても参加できない人がもっとたくさん居るのは想像できることだ。デブサミには行けないけども、自分がいる会社で、自分が居る会社の人が、自分の会社の開発の話をする、そこに参加してみようと思う人たちに向けて、開催を企てた。
HangarFlight - BlizzardSailing -
開催からしばらくして、企画を手伝ってくれた海岸沿いのSIerの友人たちと、ふりかえりを行った。ふりかえりの中で、ある若いエンジニアがこんなことを言った。
「DevLOVE(DevLOVE2012というカンファレンス)に参加して、僕はどよめきを得たんですよ。」
お前がいうどよめきとは何か?と聞いても、とにかくどよめいたとしか言わない。何なんだよ、どよめきって。彼のどよめきが実に面白くて、どちらがけしかけたか定かではないが、じゃあ、海岸沿いのSIerの中でもどよめきを得ることやれよ、という話になった。むかし、海外沿いのSIerにもどよめきを得る場があったんだよ、社内版デブサミと言ってな。お前ら明日ではダメだ、今すぐ事を起こせと、ふりかえりの帰り道に、彼らのオフィスに押し戻して、今すぐ企画メンバーを集める檄文を社内SNSに書け、と半ば強引に事を進めた。
それから、しばらく静観を続けた。もとより、海岸沿いのSIerの社内カンファレンスなのだ、私が出る幕など無い。ある日、彼らの中心に立ったリーダー(彼と出会ったときは彼も若かったが、今では立派な中堅社員になっていた)がその場に私も呼んでくれるというメッセージをもらった(実のところ何とか押しかけようとさえ考えていた)。
かくして、社内版デブサミは再開し、私は彼らと再会したのだった。どよめきの彼とも、リーダの彼とも、もちろん川島さんとも。それから、2009年の開催にあたって激しくやりあった当時の企画メンバーで、今回も企画を支えたごみさんとも。5分LTでも必ず100枚近くスライドを用意する塩じいとも。今回のリーダーを支えてくれたあまぬまや、現場仕事に追われて外に行く余裕もない若きインフラエンジニアも。満面の笑顔を見せてくれた。そして、藤原士朗とも。
面の厚いことだが、LTの時間をもらえたのでこの話をした。
この話は、最初の社内版デブサミを開いて、開きました!という事例発表をXP祭り2007というカンファレンスで話すために用意したものだった。かなり若い内容だが、あえて手を入れることをせず、あの時と全く同じ話をした。
みんな、開催にあたっては、本当に参加者が会場に現れるのか、始める瞬間まで不安だったはずだ。だからこそ、この話をはなむけにしたかった。みんなが図らずとも生み出した熱量は、きっと届いているはずだ。大丈夫だ。なぜなら、すでに私が、6年前にそれを証明しているからだ。
リーダが祭りの最後に言った。やめていった人たちが悔しがるような場を作るんだ。すばらしい。きみは既にそれを達成している。
私が2009年に残した最後のエントリ、その願いとも言うべき予言は、彼らの手によって成就したのだった。
アジャイル開発の優しい教科書
わかりやすいアジャイル開発の教科書を読みました。この本の著者の皆さんは関西の方で、いずれの方ともコミュニティにて繋がった方々でした。前川さんには、私が企画した東京の方のイベントでお話を頂いたり、細谷さんとも同じくイベントや本作りでお世話になっています。西河さんには、昔私が関西で開いたイベントに来て頂いたことがありました。お三方ともソフトウェア開発に真摯に向き合っている方々で、私が開発コミュニティに顔を出し始める前から活動をされていて、尊敬する先輩諸氏です。身近に感じる方々がアジャイル開発の、教科書と銘打った書籍を出されると知って、これはどうしても読みたいと思いました。先輩諸氏がアジャイル開発についてどんな言葉を残すのか。どんな言葉を日本の開発現場に届けるのか。楽しみでした。
本には、様々な工夫が凝らされていました。まずは、構成から。冒頭のテーマは「なぜアジャイル開発なのか」です。Start with Why。いきなり開発プラクティスの紹介ではなく、そもそも、なぜアジャイル開発であろうとするのか、そして、ソフトウェア開発が関与する「価値」とは何なのかに踏み込んでいきます。抽象度の高いテーマなので、すらっと読めてしまうところですが、書籍を一旦閉じて、Whyや価値について思いを馳せると良さそうです。なぜアジャイル開発なのかというWhyに始まり、では現場でどのように導入し定着させていくのか、具体的には何をしたらいいのかというHowへ展開する構成。教科書と銘打っているとおり、テーマに対するカバー範囲は広く、要求を捉えるところから、それを実現するためのエンジニアリングまで。TDDに関してはコードで説明しています。
本書では、具体的な始め方や学び方のために、いくつかのワークショップを紹介しています。目的や手順を詳しく説明しており、読み手のアクションを助ける内容になっています。他に類書を見ないくらい、ファシリテーションの紹介に力を入れており、この本の特徴にしています。他にも、Smiling Adventureと呼ばれる小さなワークを随所に織り込んでおり、書籍の内容理解を助ける工夫、フーバーストアやマエカワ電器という仮想プロジェクトを題材にストーリーで分かりやすく伝える工夫、実践で遭遇しそうな課題への対処をコラム(「こんなときどうする?」)で補足したりと、書き手の工夫が随所にあふれています。さらに巻末は、書籍の外側で学ぶための場、コミュニティの紹介で締めくくります。
また、表現の仕方に、この書籍のらしさがあります。要求をこうありたい、こうしたいという「思い」という言葉に、価値をその思いが手に取れるようにすること、すなわち「カタチ」と表現しています。思いからカタチを描き、エンジニアリングによってカタチを実際に作り上げる。カタチはタイムボックスで確認し続ける。思いとカタチを合わせて行くようにする。こういう表現の仕方は私は好きです。
本書をどういう言葉で表すかと考えたときに、「易しさ」以上に「優しさ」を感じました。数多くの独自の工夫から書き手の、分かりやすく伝えたい、伝わってほしいという思いを私は感じた気がします。この本が日本の開発現場で、アジャイルサムライ以来の全部入り入門書として活用されると願って、紹介を終えたいと思います。
- 作者: 前川直也,西河誠,細谷泰夫
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2013/03/28
- メディア: 単行本
- クリック: 2回
- この商品を含むブログ (5件) を見る
ソフトウェア開発の現場パターン -アジャイル型開発におけるプラクティス活用事例調査-
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コミュニティからフィヨルドの町田さんと繋がり、町田さんから、デザイナーの方々を紹介して頂くことが出来た。自社の予算との調整を経て、最終的に、前田製作所の前田さんにお願いすることになった。そして、ページは完成した。
そう、ようやくご提供できるようになりました。
ここまで、影に日向に支援して頂いた角谷さんを始め、このエントリに出てきた方々、協力して頂いた方々に、感謝をしたいと思います。ここまで来るのに、恐ろしく時間がかかりました。いつ途中で終わってもおかしくなかったけども、続けてこられたのは、皆さんのおかげです。本当にありがとうございます。とても小さいけれども、これは僕にとっては、課題山積の中掴みとった橋頭堡みたいなものです。これからが、また次の始まりで、このサービス自体を僕や安井さん、家永といった中心のメンバーが育ていく必要があるし、また別の橋頭堡を築かなければならないのだから。
