解説！地図を捨ててコンパスを頼りに未来へ進め！ Agile Tour Osaka 2012資料公開 #agileto2012

Agile Tour Osaka 2012 in Minoh

Agile Tour Osaka 2012で発表させていただきました。箕面という精神的に遠く感じるロケーション（実質それほどでもないんです）でありながら、たくさんの方に来ていただけました。ありがとうございます。発表資料についてはSlideshareで公開しておりますのであわせてご確認ください。

発表解説

この発表の依頼を頂いた時に、オーガナイザーのてつさん、細谷さんからは「テーマはチェンジ。場所は箕面ね」というわずかな情報をいただきました（笑）。

困ったなー、大阪だとどういう話が面白いかなーと考えているうちに、ぱっとひらめいたのが「地図を捨ててコンパスを頼りに進め」でした。

実は発表資料は、最近ブイブイいわせているLean Startup Japan和波さんから、以前

スタートアップの人の中には、従来型の開発ベースでサービス開発をはじめようとする人が多い。それだとスタートアップでは勝負にならないんだということを伝えたい

ということを伺い、それを聞いて私自身も「ああ、うちもサービス開発やっているけど、従来型の考え方でやろうとする人多いよなぁ。なんでだろう？」という疑問が浮かび、考えをまとめたものがベースになっています。

その後、UMLモデリング推進協議会（UMTP）さんからもアジャイル開発セミナーでの事例発表の依頼をいただき、参加される方は大手SIerの方も多いみたいだったので、どちらかというとサービス開発よりも従来型開発をされている方向けになりました。

仕様書は正しいのか？

発表の中で出てきた「Why？」を1つずつ補足さえていただきます。その他の質問等は、右下のMessageLeafやTwitter、メールでいただければ回答させて頂きます。

今回の発表は今年頭から支援しているチームでの出来事が中心になっています。私のチームで、当初よくでてきた問題が

仕様がないと作れないからはやく決めて欲しい

というものでした。チームには『プロデューサ』という役割の人間が一人いて、ビジネスと開発をつなぐ仕事をしています。ただ、今の現場ですとプロデューサが企画やその仕様を考えており、そこがボトルネックになったようです。

サービス開発は関係者全員が当事者です。この課題に対しては、「仕様を一緒に作れば、仕様がくるまで待たなくてもいいし、作るだけの仕事より面白いんじゃない？」ということになり、エンジニアからのフィードバックや提案が少しづつ出てきました。

また、リリースしてみたものの、予想と違った反応がユーザから返ってきたケースもありました。仕様は仮説でしかなかったわけです。そして、仕様が仮説であるとすれば、間違った時のリスクを考える必要がでてきて、リスクを減らすために小さくリリースするようになってきました。

設計で問題として出てきたのが「スケール」「汎用性」といった言葉。「どこまで考えるか？」は悩ましい課題です。小さいサービスで開発をしていると「でっかいビルを作る」ような思想や手法がマッチしません。

どちらかというと小さな家（機能）を作りながら街（システム）を作っていく感覚があります。「設計」という工程に時間をかけるよりも、実際に作ってみたほうがはやくなりました。

どんな街にしようか？を考えるようにしていて、綺麗な白い家が並ぶ街に、赤い東京タワーを建てようとしないように、全体としての整合性は必ずチェックしています。

最後に、仕様は作るまでがゴールではありません。作ったものがちゃんと使われているか？想定通りの使われ方か？を計測する必要があります。なんとなく作ったものを、なんとなく出すのは賢い選択ではないため、リリースしたものを全部計測するようになってきます。

計画は守らなければならないのか？

計画は作ります。時間をかけてゴールをしっかり話しあいながら作ります。そして、現状を見極めて柔軟に変更します。お互い確認する手段として、ロードマップを活用します。

ロードマップは高速道路の標識のように、方向性とそこまでの距離をチェックするために利用しています。「東京まで、51.23565kmです」だとうれしくないので、距離に精度は求めておらず、「名古屋まで100キロ、東京まで500キロ」のようにすることで、全体像が見えて進んでいるのを実感しやすくなりました。

いくら計画を変更するとはいえ、自分たちのビジネスのためにコミットメントが求められるときももちろんあります。それが毎回だとちょっと厳しいですが、そのときはがんばるの（残業や徹夜）は仕方ないことだと思います。ただ、それがずっと続くと何かがおかしくなってきます。

サービス開発はビジネスと開発の両輪で動いています。だから、企画には理由があり意味があることをビジネス側は説明する必要があり、開発サイドはゴールに納得する必要がでてきます。これは上下関係ではなくパートナーシップのような関係です。

あとは、一つひとつの作業をしっかり完了させるだけです。作ることは最低条件でしかなく、ユーザのためビジネスのため、とさまざまな価値を考えながらDONEさせていきます。

成功とはなんだ？

今担当しているサービス開発では納品がありません。納品という意味を知らないメンバーがほとんどです。開発という基礎体力がついてきた実感が出てくると、徐々に目標を高めていくようにしました。

プロジェクト制のようにリリースまでを成功にするのはもう過去の話です。

品質とはなんだ？

ワインバーグさんの言葉は面白いですね。ここにでてくる「誰かにとっての価値」とは何か？「誰か」ってだれだろう？今の考えだと誰かにはお客さん大切だし、ビジネスも成功させたい。そして、サービス開発にかかわる人間全員の価値も尊重したいと思っています。

それぞれの価値は異なるかもしれませんが、「ユーザにサービスを提供しビジネスをする」という部分は根本的に変わらないので、意見がぶつかったときは、この前提条件を考えながら話しあってます。もちろん、個人のやりたいことも尊重します。

また、バグ率のような品質については、画面テストの自動化によって、バグ率が異常に低くなりました。自動化したテストと同じようなことを、QA等のテストで（手作業で）実施したのが原因と考えています。

最後の最後にテストする無駄や、チームがほしかったテストじゃなかったという価値のズレが課題として残りました。手触りのいいサービスを作るために、価値の高い手作業を増やすことで、これまでの『品質』を見直すきっかけが生まれました。

地図を捨ててコンパスを頼りに進め

まとめです。

今年の支援活動のキーワードは「地図を捨ててコンパスを頼りに進め」というものでした。

アジャイル開発については、プラクティスをやりはじめても浸透しないことが多かったので、なぜそれをやるか？を先に伝えてきました。結果的に意味を先に考え、必要なプラクティスを選択・実施・ふりかえり・続ける続け内の判断を、繰り返ししてきました。

一方、人財の育成を考える必要があったため、基礎体力となる基本技術（プログラミングがほとんど）をベースにチームを育てる必要がありました。その技術をさらに活かすためにマインドやゴールについて問いかけてきました。結果的にクラフトマンシップへの道のりにつながればいいなぁと。

方向性をそろえるために有効活用したのがふりかえりです。週に1〜2時間を使い、外の情報や中の情報。個人の意見やチームの意見を考える場を作りました。自分たちの活動を見える化するためにベロシティをざっくり計算し、傾向を細かくチェックするようにしています。例えば、

• TODOが減ってきたらそろそろ計画の時間が必要だ
• DONEが減ったら何がダメだったのか考える機会だ
• DOINGが増えたらDONEできていない可能性がある

というように、きっかけをみつけるぐらいのふわっとしたチーム計測を行なってます。

現場支援を始めた当初のDONE率が4割。これを少ないと感じるかどうかは人によって違いますが、チームはこれを「少ない」と考え、様々なトライを行うようになってきます。

現在は、見積もりの精度や開発効率が上がっている影響か、前倒しが増えてきています。いずれ100％ぐらいに安定すると思うのですが、現状だと100〜140％ぐらいのDONE率になってきたんじゃないかなぁという感覚です。手戻りはほとんどありません。

最後に、今のチームの中で、若手プログラマがPCに貼り付けていた付箋が印象的だったので紹介させていただきました。CIを使うようになって彼女なりに忘れないようにメモしたのでしょう。

彼女ははじめ、エラー調査で数時間悩んで「もったいない時間を過ごした」というふりかえりをしました。そこででてきたトライが「時間を決めて悩もう」というものだったので、こういう書き方になったのだと思います。

たしかに人を変えるのは難しい。でも、この付箋を見てから、「人って変わるんじゃないか？」という期待が僕の中に生まれました。

おわりに

はじめに書かせていただいたように、この発表は当初従来型開発を見直すために作ったものです。

東京では今月末にUMPTアジャイル開発セミナーで話させていただこうと思っています。また、今度のUltimate Agilist Tokyoでも倉貫さんとこういう話をしたいなぁと思っているので、興味のある方はぜひ。

勉強会には様々な方がいらっしゃるので、実際の仕事のビジネスモデルが異なる場合、なかなか議論が進まない気がしています。「コンテキストが違うから」「うちは違うから」と言われることもよくあります。

本当に違うんでしょうか？

自分からは遠い話ですか？あなたは関係ありませんか？私は決してそうは思っていません。サービス開発であろうと、SIerであろうと、ソフトウェア開発に関わっているわけなので、状況は違えど似たような壁はあります。

だから、自分はいつもチームに繰り返し問いかけています。理想の開発をしよう。理想は僕らで考えよう。誰かの話ではなく自分の話をしよう。これまでの当たり前を変化させよう。そして、

地図を捨てて、コンパスを頼りに、一緒に進んでいこう。

*