書籍「LeanUX」を頂きました。

　Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)を監訳者の坂田さんから献本して頂きました。ありがとうございます。

　私は原著を1年くらい前だったかに読んでいたのですが、日本語で読めるのはやはりありがたいですね。ページ数も厚くはなく、それほど時間を取られることなく読めてしまうのではないでしょうか。

　構成は、Lean UXの原則にはじまり、具体的なプロセス、プラクティス、最後に実践のための補完(アジャイル開発との統合、組織的な移行)となっています。スタイルガイドやMVP(プロトタイプ)のパターンについて、語っているのはこの本らしさといえます。

　LeanUXから何かテーマを取り上げるとすると「共通理解」があげられます。チームの間での「共通理解」は「LeanUXの貨幣」と表現しており、特に重要視している概念であることがうかがえます。状況や製品、顧客に対するチームの共通の知識を醸成することで、コミュニケーションのための報告書や重厚なドキュメントを不要とする。結果、チームの仕事が円滑に進むようになり、より成果が期待できるようになる。

　開発チームだけではなくデザイナーも含めたチーム運営について悩んでいたり、考える必要があったりする方は、一度手に取ってみると良いかもしれませんね。

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

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

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

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

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

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

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

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

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

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

　　

　　

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

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

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

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

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

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

因果関係図で現場課題を捉えようワークショップ from toshihiro ichitani

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

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

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

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

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

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

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

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

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

越境する開発 from toshihiro ichitani

境界なき現場を行け from toshihiro ichitani

　どちらも「リーン開発の現場」から最も届けたい言葉を元に作っています。「越境する開発」の方は、現職の2年半で積み上げてきたことをまとめた内容になっています。ふりかえる良い機会になりました。「越境」するための作戦を述べたものが「越境する開発」のお話です。

　一方、「境界なき現場を、行け」はAgileSamuraiBaseCampというカンファレンスの締めのセッションで、参加された方の明日の一歩を少しでも支えられるようにと作ったお話です。何かを現場で始めよう、試そうとするその一手が難しいことはよく分かっています。だからこそ、ああせいこうせい、信じていけばいいんだ、とカンタンに締めるわけにはいかないわけで、私には自分自身の話をする他ありませんでした。

　「越境する開発」は道具に沿って話をしています。話を書いていて、これだけでは足りないと感じました。なので、「境界なき現場」では道具の話ではなく「そもそも、境界って何なの」という意思の話をしました。道具だけでも、突破できない。意思だけでも、戦えない。道具も意思も両輪なんだと思います。さしずめ、この2つの話は地と図の関係にあります。黒と白。

　これらの話が誰かの明日の何かに少しでも繋がることができたら、こんなに嬉しいことはありません。また、どこかで楽しく真面目に、互いの現場の話をしましょう :)

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

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

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

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

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

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

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

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

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

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

自己紹介

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

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

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

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

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

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

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

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

次の現場は

上野さんです。