The Dragon Scroll

Be just and fear not.

「塹壕より、アジャイルプロジェクト運営」と「因果関係図で真の問題を捉えよう!」

f:id:papanda0806:20140117231548j:plain

塹壕より、アジャイルプロジェクト運営

 Regional Scrum Gathering Tokyoで登壇してきました。1日目は、藤原さんと組んで発表しました。

 「塹壕より、アジャイルプロジェクト運営」

 テーマについての質問をまず掲げて、参加者の皆さんにペアで考えてもらい、それを全体で共有する。そして、発表者があらかじめ用意していたテーマに対する要約を話すというスタイルを取りました。初めてのやり方(しかも2人で分担)なので、上手くセッションが作れるか不安がありましたが、参加者の皆さんの前のめりな参加のおかげで形にすることができました。

 質問は3つ用意しました。

  • アジャイルなプロジェクト運営をはじめるときに最初に何をすればいいのだろう?
  • アジャイルなプロジェクト運営を維持するために何に気をつければいいのだろう?
  • 関係者がプロジェクトのゴールを追うために大事なこととはなんだろう。

 前2つを藤原さん。最後の質問を私が担当しました。私の部ではこんな話をしました。

  • ゴールには「プロダクトの大いなる目標となるゴール」と「ゴールのための中間ゴールとなるマイルストーンゴール」の2つがある。
  • ゴールを明確にするためにインセプションデッキ作りを利用しよう。
  • インセプションデッキを作ると、プロジェクトのタイプ(期待)がみえてくる。プロジェクトのタイプには「仮説検証型」と「最短距離型」の2つがある。(「仮説検証型」「最短距離型」はこちらの「越境する開発」で触れた内容)
  • ゴールに向けて、それぞれのタイプに応じたリリース計画を立てる必要がある。

  f:id:papanda0806:20140118090254p:plain

  f:id:papanda0806:20140118090300p:plain

 2つのプロジェクトタイプとそれに適したプロジェクトプラクティスとは何かについては、多くの語るべきことがあります(デブサミでも話す予定です)。

 「一方的に話を聴くだけではなく、自分たちが考えることができた」というフィードバックを頂くことができたのは、質問駆動のスタイルを取った本望といえます。ご参加頂いた皆さん、ありがとうございました。

因果関係図で真の問題を捉えよう!

 また、2日目は因果関係図を使ったワークショップをファシリテートしました。

 「因果関係図で真の問題を捉えよう!」

因果関係図は、書籍「リーン開発の現場」で20章をまるまる割いて解説している問題発見のためのツールです。ワークショップで使った資料を紹介しておきます。

 なお、本ワークショップを作るにあたっては、DevLOVE神奈川の皆さんに素振りに付き合って頂きました。その時のフィードバックはとても参考になりました。感謝いたします。

2014年のデブサミに登壇する話

http://instagram.com/p/RjbPPIvoZB/

 今年もデブサミの季節がやってきました。私は2月14日に登壇します。

 Developers Summit 2014:【14-D-3】越境する開発 ~あの日開発していたサービスの名前を僕たちはまだ知らない~

 前回の登板から4年。現職に就いてから早2年半が経ちました。その間にAgileカンファレンスに参加し、訳書「リーン開発の現場」を出版しました。これを節目として、ここまでの実経験を元にお話します。テーマは「Develop the Right things Right」。キーワードとしては「期待マネジメント」と「仮説検証型開発と最短距離型開発」をあげます。なぜそれが必要なのかというWhy、それをどうやってやるのかというHowについて、具体的な現場のStoryに載せてお話します。アジャイル開発の理想と現実の間で立ち往生感がある方に向け、何かしら得るところがあればと考えています。

 「正しいものを正しく作る」というのは果てなき理想であり、大いなる挑戦です。私はこの理想に向かって、まだ踏み出したに過ぎず、追い求め続けていかなければなりません。ただ、この節目を向かえるまでに、多くの事件があり胸が透くような経験も苦い経験も様々とあって、自分にとってのアジャイル開発、ソフトウェア開発をここで一度捉え直し、そしてそれが他の誰かにも伝わるStoryにしておきたいと思いました。私にこれまで学びをもたらしてくれたデブサミの多くの先達のように、自分自身も何かを残すとしたら今だ、と。

 デブサミで話すことは私にとって、現在地を確認し次へ進むための機会になっています。このような貴重な機会をもう1度頂けたことに感謝します。2月14日目黒雅叙園での様々な出会いを楽しみにしています。

「越境する開発」と「境界なき現場を、行け」

http://instagram.com/p/bffqjQPobK/

 

 

 2つのお話をしました。「越境する開発」「境界なき現場を、行け」の2話です。

 どちらも「リーン開発の現場」から最も届けたい言葉を元に作っています。「越境する開発」の方は、現職の2年半で積み上げてきたことをまとめた内容になっています。ふりかえる良い機会になりました。「越境」するための作戦を述べたものが「越境する開発」のお話です。
 一方、「境界なき現場を、行け」はAgileSamuraiBaseCampというカンファレンスの締めのセッションで、参加された方の明日の一歩を少しでも支えられるようにと作ったお話です。何かを現場で始めよう、試そうとするその一手が難しいことはよく分かっています。だからこそ、ああせいこうせい、信じていけばいいんだ、とカンタンに締めるわけにはいかないわけで、私には自分自身の話をする他ありませんでした。
 「越境する開発」は道具に沿って話をしています。話を書いていて、これだけでは足りないと感じました。なので、「境界なき現場」では道具の話ではなく「そもそも、境界って何なの」という意思の話をしました。道具だけでも、突破できない。意思だけでも、戦えない。道具も意思も両輪なんだと思います。さしずめ、この2つの話は地と図の関係にあります。黒と白。
 これらの話が誰かの明日の何かに少しでも繋がることができたら、こんなに嬉しいことはありません。また、どこかで楽しく真面目に、互いの現場の話をしましょう :)

モメごとになる前に、モメごと本を読んでおこう。

 

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

 

  献本頂きました。なぜシステム開発は必ずモメるのか(以下、モメごと本と記す)。実は馴染みがある本です。というのも、「リーン開発の現場」を探して書店を回っていたとき、結構な頻度で隣に配置してもらっていたためです。

f:id:papanda0806:20131209155349j:plain

  さて、こちらの書籍、書き手はIT訴訟の調停委員をされていた方ということで、法的観点からソフトウェア開発のさまざまな問題やリスクを評価、対策を解説する内容になっています。当然ながら法的な解釈については説得力があり、だいたいにおいて「まぁ、そういう判断になるんやろうなぁ」という妥当感があります。

 モメごと本の中で主人公がたびたび口にするように、法的判断といっても杓子定規なものではなく、意外と要件定義書とか設計書とか開発のためのドキュメントが判断材料になったり、「ふつう考えたらそらそうでしょ」な観点も盛り込まれることに気づきます。後者は例えば、ITベンダーは開発のプロなのだから、プロとして発注側に開発上のアドバイスを怠ったりすると、その責任を問われることがある、など。善管注意義務というやつですね。 

 構成は、7章からなり、要件定義、外部設計、内部設計、プログラミング・単体テスト、統合テスト、システムテスト、受入テストと章がふられています。下敷きにしている開発のコンテキストは、この章立ての字面の印象から受け取れるとおりです。また、システム開発の受発注を想定しています。なので、サービス開発を内製でしてきております、という方にはちょっと想像し難い設定かもしれません。

 では、ウォーターフォールや受発注型の開発でしか得るところが無いのかというと、そうでもありません。システム作りを頼む側と頼まれる側という文脈に立って、この本を読むと、様々な発見があるはずです。頼む側も頼まれる側も、双方がどのような期待を持っていて、何を考え、どんな姿勢で開発に臨む可能性があるのか推し量ることができます。それは、開発のリスク察知の上で参考になります。各章末にチェックリストがついていて、自分の経験が不足している局面についての良い補完になると思います。また、メインターゲットとなる受発注型の開発をされている方(で、まだプロジェクトの経験が浅い方)はとにかく一度目を通してみると良いかと思います。「え、この解釈ちょっと厳しくない?」と思えるものがあったら襟を正すには良い機会かもしれません(私もいくつかありました)。

 なお、文体というか書き方が人物の会話形式になっていて、こういう形式の開発関連本って最近見なくなったなーと同時に、たくさん字を追うのが苦手な方には読みやすいかもしれないと思いました。内容はみかけの文体ほど軽くはないので、自分だったらどうするという解釈を入れながら読み進められると良いのではないかと思います。

現場はどこだ? 現場は、今、ここだ。

http://instagram.com/p/cQibfVPofj/

このエントリーはDevLOVE Advent Calendar 2013 「現場」の9日目の記事になります。

自己紹介

改めまして市谷といいます。ソフトウェアの受託開発の仕事をしています。

現場はどこだ? 現場は、今、ここだ。

「このWBSを更新してあすの進捗会議に届けなければならない。」

 上司からのメールを読んで、氷を飲み込んだような冷たさを体に感じた。WBSの項目は気が遠くなるほどある。それを1つ1つ更新していく。大丈夫だ。状況は壁に貼ったタスクボードを見れば分かる。しかし、いかんせん数が多い。隣を見ればチームメンバーが2人3人まだ残ってタスクに挑んでいる。別のチームの島も覗いてみる。同僚のチームリーダーがじっとディスプレイを食い入るように見つめている。彼も同じ状況だ。時間は22時を回った。夜の高層ビルの窓際はたいそう冷える。ビルの玄関口が閉まってしまう前に、ホットコーヒーを買いにいこう。このEXCELとの格闘は間違いなく夜を徹することになるのだから。

 かつて自分が居たその現場のことを時々思い出す。もう5年も前になるが、割と鮮明に記憶に残っている。誰がそこに居て、何に憤り、どんな朝会で、何を皆で笑っていたか。決まって進捗会議の前の日は徹夜になった。結構無茶をしたし、怒りに身を任せて上司にかけあったことも何度かあった。プロジェクトとして順風満帆とは全く言えなかった。むしろ、あまりよくない方の記憶として記録されるべきプロジェクトだろう。

 だが、そのプロジェクトはここまでの10数年のキャリアの中で最も面白く、最も自分が学んだ時間だったとはっきりといえる。毎日が実験だった。試す、試す、試す。状況を好転するべく、知恵を絞る。自分一人だけではない。頼もしいチームメンバーと一緒に考える。顧客とも考える。顧客と開発チームという立ち位置を越えて、ミッションを共通に感じていた。当時はインセプションデッキなんてまだ無かったけども、われわれはなぜここにいるのか?きっと言えたと思う。

 私にとっての現場とは、誰かにとって必要なモノやコトを一緒に創る場だ。「誰かが分からない、役に立つかも分からないモノ」は作らない。システム作りなのだからと「開発側だけで作る」こともしない。自分たちには無いドメインの知識や経験を持っている相手と共に創る。目的が近くなるよう知恵を出し合いながら創る。相手はある問題を解決したいと考えている。こちらも相手に問題を解いてもらいたいと思っている。そのために必要な知識とスキルと経験を持ち寄って、創る。思えば現場とは、互いのWhyを実現するために、互いの持ち味を持ち寄る場なのだ。どちらかというとこれはまだ、理想だ。私はそうあるために、現場で仕事に向き合い続けている。

 最後に、ある私信も兼ねて。もし、仕事でミスしたり、クヨクヨすることがあったら、自分は誰の何のために仕事をしているのか思い出して欲しいんだ。それは、いつものクライアントの課題を解決して喜びを分かち合いためかもしれない。それは、憧れの上司を支えて組織を前進させるためかもしれない。あるいは、自分自身の学びや独り立ちのためかもしれない。その理由は実は何でも良い。その理由を他人の誰かがとやかくなんて言えやしないからだ。本当にそれが誰かのためになっているのなら、他人の言うことなんて聞かなくていい(立ち止まって考える機会は大事だよ)。自分が仕事をしているWhyを持ち、向かいたい先を見据えていれば、日常の悩みが些細なことに思えてくるはずだ。いや、むしろ囚われすぎてはいけないんだ。私はこう考えるようにしている。夜の間、世界は暗い。けれども。視線を上げれば、月が見える。私がこれからの生涯を含めて月に辿りつくことはないだろう。だが、それでいい。月が見えていればいい。そうすれば、向かいたい先を見失うことは決してないのだから。

次の現場は

上野さんです。

リーン開発の現場に、いたる道。

f:id:papanda0806:20131102145926p:plain

 「各自頑張ってください。」

 やや照れくさそうに、トークの最後はその言葉で締められた。10月28日にサイバーエージェントさんをお借りして開催した「リーン開発の現場」の出版イベントでのことだ。最後の言葉がしばらく耳に残った。その言葉を頼りに自分の記憶を辿ってみると、ある出来事が思い出された。

 それは2008年10月31日のことだった。出版イベントの実に5年前だ。当時私は友人の同僚と2人で「アジャイルプラクティス」の読書会を社内で開催していた。その締めくくりとして監訳者の2人を会社にお招きしたのだった。最後の読書会も終えて、その懇親会で私は恐る恐る監訳者の1人に話しかけた。その時、監訳者の方とは"持ち場"の話をした。自分たち一人一人が"持ち場"を持っている。それぞれが大切にするものは違うかもしれない。それを大切にすることは、決して楽ではないはずだ。様々な問題が待ち構えている。しかし、自分の抱える問題の解答は他人の中にはなく、自分が向きあっていくしかない。だから、自分が大切にするもののために、頑張る。監訳者の方は、私との会話をこう締めくくったのだ。

「各自頑張れ、やで。」

それは5年かけて再び耳に帰ってきた言葉だった。

ラスト3マイルからの戦い

 前回のエントリから出版に辿りつくまで「3マイル」と見立てたが想像以上に険しい道のりになった。書き終え、一旦はレビューも終わった日本語の文章を徹底的に磨いていく。残っていた誤訳をしらみ潰しにする。読んでみて感じるひっかかりを削ぎ落としていく。監訳者角谷さんとのそのやりとりはすべてgithubのissueでおこなった。角谷さんがissueをあげる。こちらでissueを倒す。角谷さんがissueをあげる。こちらでissueを倒す。50のissueを倒したら、50のissueが増えている。まさに全文に手を入れ、書きなおしていく。原文の読み直しを1周したら、2周目。2周したら、3周目。issueでのやりとりを締め切り直前まで繰り返す。

 アジャイルサムライの時も直前まで手を入れていたという。「下手くそは、努力するしかない。」上手にやれる人はもちろん居る。だが、そうでないなら。やるしかないのだ。

日本語版のまえがきと解説

 今回、日本語版まえがきは角谷さん、解説は平鍋さんにお願いをした。このお二人に文章を頼んだのには思いがある。私はお二人が出した本や話したこと、その背中を見てきた。アジャイル開発に向き合ってきた、少し年齢を重ねている人ならきっと分かってくれると思う。日本のアジャイル、その最初の10年はこの二人が誰よりも先を突き進んでいた。いつも前にその背中があった感覚だ。

 平鍋さん、角谷さんと初めて会ったのは2006年のことだったと思う。角谷さんとその後まともに話をしたのは先に書いた2008年の読書会の懇親会になる。そして、2010年に初めてデブサミ発表のオファーをもらい、発表内容の相談に乗ってもらった。2011年には、私は上野の会社に移る。

 やがて、2006年から7年の時が経ち、1冊の本が出来た。その監訳者まえがきで、藤原と私をこう紹介して頂いた。

「学びとは、ただ知ることではない。知識は頭の中のものだが、学びとは手の中にあって、熱意によって行動に移されるんだ」というフレーズを体現するアジャイル開発実践者です。

(監訳者まえがき より)

角谷さんに"アジャイル開発実践者"と呼ばれることは自分にとって格別だ。自分にも歩みがあって、ふりかえれるくらいの道のりがあることに気付く。たくさんの人や書籍との出会い、出来事や仕事があって今の自分に辿りついている。すべて自分にとって必要なことだったのだと、受け入れられる。生きていれば愕然とすることや憤ることもたくさんある。出来れば避けたいと思う。しかし、ひとたび自分の時間として経験したならば、それは必ず自分の一部になる。

相棒

 人との出会いを思い起こしてみると似たような経路を辿ることに気づいた。ある人と出会えたのは、別の人が居て紹介してくれたから。その別の人と出会えたのは、コミュニティをやっていたから。そして、コミュニティをはじめたのは今やあるメガネ屋さんでRubyプログラマーとして腕を振るう仲間が、その昔同僚に居てくれたからだった。

 さて、藤原大と出会えたのはよしおかさんが居て紹介してくれたからだった。ただし同じ会社に居ながら、その後ほぼ関わりは無かった。やがて私が会社を辞めるときを迎える。藤原とは終わりを迎えてからが始まりだった。2012年にダラスのアジャイルカンファレンスに行った。その後、イベントを開催した。そして、本を作った。

 本作りは10ヶ月を要した。その間、だいたい彼が夜0時まで作業を行い、私が0時から作業を開始するという体制になっていた。「一夜明けたら、issueが半分くらいになっていて、彼がどんな驚き方をするか」を期待するのが密やかな楽しみだった。オンラインでのやりとりがだいたいで、リアルに会うことは数えるくらいしかなかった。生息する時間帯も、所属する会社も、考え方も性格も異なっていて、それでも背中を任せるのにこんな安心する相手は居なかった。おそらくは「現場が好き」という共通するたった一つのことがあったからだと思う。

f:id:papanda0806:20131102145425j:plain

  かくして、「リーン開発の現場」は出来上がりました。ただただ、読んで頂けるだけでこんな嬉しいことはありません。そして、読み終えたら。各自頑張っていこうではありませんか。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営