私にとって最後のデブサミ。
デブサミ2014で「越境する開発」という話をしました。発表時に使用した背景画像はslideshareに置いてあります。こうして読み返すと、デブサミで伝えたかったことは、このスライド自体には無いように感じます。伝えたかったことは、あの日の雅叙園のあの場所に置いてこれたのだと思います。
続きを読む書籍「LeanUX」を頂きました。
Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)を監訳者の坂田さんから献本して頂きました。ありがとうございます。
私は原著を1年くらい前だったかに読んでいたのですが、日本語で読めるのはやはりありがたいですね。ページ数も厚くはなく、それほど時間を取られることなく読めてしまうのではないでしょうか。
構成は、Lean UXの原則にはじまり、具体的なプロセス、プラクティス、最後に実践のための補完(アジャイル開発との統合、組織的な移行)となっています。スタイルガイドやMVP(プロトタイプ)のパターンについて、語っているのはこの本らしさといえます。
LeanUXから何かテーマを取り上げるとすると「共通理解」があげられます。チームの間での「共通理解」は「LeanUXの貨幣」と表現しており、特に重要視している概念であることがうかがえます。状況や製品、顧客に対するチームの共通の知識を醸成することで、コミュニケーションのための報告書や重厚なドキュメントを不要とする。結果、チームの仕事が円滑に進むようになり、より成果が期待できるようになる。
開発チームだけではなくデザイナーも含めたチーム運営について悩んでいたり、考える必要があったりする方は、一度手に取ってみると良いかもしれませんね。
Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)
- 作者: ジェフ・ゴーセルフ,ジョシュ・セイデン,エリック・リース,坂田一倫(監訳),児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/01/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
「塹壕より、アジャイルプロジェクト運営」と「因果関係図で真の問題を捉えよう!」
塹壕より、アジャイルプロジェクト運営
Regional Scrum Gathering Tokyoで登壇してきました。1日目は、藤原さんと組んで発表しました。
テーマについての質問をまず掲げて、参加者の皆さんにペアで考えてもらい、それを全体で共有する。そして、発表者があらかじめ用意していたテーマに対する要約を話すというスタイルを取りました。初めてのやり方(しかも2人で分担)なので、上手くセッションが作れるか不安がありましたが、参加者の皆さんの前のめりな参加のおかげで形にすることができました。
質問は3つ用意しました。
- アジャイルなプロジェクト運営をはじめるときに最初に何をすればいいのだろう?
- アジャイルなプロジェクト運営を維持するために何に気をつければいいのだろう?
- 関係者がプロジェクトのゴールを追うために大事なこととはなんだろう。
前2つを藤原さん。最後の質問を私が担当しました。私の部ではこんな話をしました。
- ゴールには「プロダクトの大いなる目標となるゴール」と「ゴールのための中間ゴールとなるマイルストーンゴール」の2つがある。
- ゴールを明確にするためにインセプションデッキ作りを利用しよう。
- インセプションデッキを作ると、プロジェクトのタイプ(期待)がみえてくる。プロジェクトのタイプには「仮説検証型」と「最短距離型」の2つがある。(「仮説検証型」「最短距離型」はこちらの「越境する開発」で触れた内容)
- ゴールに向けて、それぞれのタイプに応じたリリース計画を立てる必要がある。
2つのプロジェクトタイプとそれに適したプロジェクトプラクティスとは何かについては、多くの語るべきことがあります(デブサミでも話す予定です)。
「一方的に話を聴くだけではなく、自分たちが考えることができた」というフィードバックを頂くことができたのは、質問駆動のスタイルを取った本望といえます。ご参加頂いた皆さん、ありがとうございました。
因果関係図で真の問題を捉えよう!
また、2日目は因果関係図を使ったワークショップをファシリテートしました。
因果関係図は、書籍「リーン開発の現場」で20章をまるまる割いて解説している問題発見のためのツールです。ワークショップで使った資料を紹介しておきます。
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話です。
モメごとになる前に、モメごと本を読んでおこう。
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2013/09/27
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
献本頂きました。なぜシステム開発は必ずモメるのか(以下、モメごと本と記す)。実は馴染みがある本です。というのも、「リーン開発の現場」を探して書店を回っていたとき、結構な頻度で隣に配置してもらっていたためです。
さて、こちらの書籍、書き手はIT訴訟の調停委員をされていた方ということで、法的観点からソフトウェア開発のさまざまな問題やリスクを評価、対策を解説する内容になっています。当然ながら法的な解釈については説得力があり、だいたいにおいて「まぁ、そういう判断になるんやろうなぁ」という妥当感があります。
モメごと本の中で主人公がたびたび口にするように、法的判断といっても杓子定規なものではなく、意外と要件定義書とか設計書とか開発のためのドキュメントが判断材料になったり、「ふつう考えたらそらそうでしょ」な観点も盛り込まれることに気づきます。後者は例えば、ITベンダーは開発のプロなのだから、プロとして発注側に開発上のアドバイスを怠ったりすると、その責任を問われることがある、など。善管注意義務というやつですね。
構成は、7章からなり、要件定義、外部設計、内部設計、プログラミング・単体テスト、統合テスト、システムテスト、受入テストと章がふられています。下敷きにしている開発のコンテキストは、この章立ての字面の印象から受け取れるとおりです。また、システム開発の受発注を想定しています。なので、サービス開発を内製でしてきております、という方にはちょっと想像し難い設定かもしれません。
では、ウォーターフォールや受発注型の開発でしか得るところが無いのかというと、そうでもありません。システム作りを頼む側と頼まれる側という文脈に立って、この本を読むと、様々な発見があるはずです。頼む側も頼まれる側も、双方がどのような期待を持っていて、何を考え、どんな姿勢で開発に臨む可能性があるのか推し量ることができます。それは、開発のリスク察知の上で参考になります。各章末にチェックリストがついていて、自分の経験が不足している局面についての良い補完になると思います。また、メインターゲットとなる受発注型の開発をされている方(で、まだプロジェクトの経験が浅い方)はとにかく一度目を通してみると良いかと思います。「え、この解釈ちょっと厳しくない?」と思えるものがあったら襟を正すには良い機会かもしれません(私もいくつかありました)。
なお、文体というか書き方が人物の会話形式になっていて、こういう形式の開発関連本って最近見なくなったなーと同時に、たくさん字を追うのが苦手な方には読みやすいかもしれないと思いました。内容はみかけの文体ほど軽くはないので、自分だったらどうするという解釈を入れながら読み進められると良いのではないかと思います。