○○したら、 受託開発が180°変わった 2014.10.18 Creators Meet Up
自己紹介 原田 敦 @harada4atsushi 日本シーエイダブリュウ株式会社 WEBアプリケーションエンジニア Androidは趣味
日本シーエイダブリュウとは 見積もらない受託開発 Ruby on Rails WEBアプリケーション AWS
アジャイルひよこクラブ ビギナー向け 「実践」を増やしたい 現場から変えて行く
うまくいかない受託開発
炎上・デスマーチ
仕様書に書いてないぞ！ 追加費用だ！ バグだ！！ 即刻タダで直せ！ 互いが身を守るための不毛な争い
何この機能？ こんなんじゃ 使えないよ えっ… それでいいって 言ってたやん…
これでいいって 言ったじゃないすか！ ムリです。 出来ません！ 言ったかも知れないけど ちゃんとやってくれないと困るよ！ どうにかして！
もう帰りたい… 疲弊するエンジニア
仮説 仕様変更が絶えないのは 最初に全部決めようとするからだ
Try 一週間単位の逐次開発にしてみる
Problem タスクを消化しては、また次から次へとタスクが生まれる「わんこそば式開発」 予定していた納期が迫ってきて突貫工事
仮説② あとから設計がひっくり返されるのは 動くソフトウェアをみていないからだ
Try 汚いソースコードでもいいから 動くソフトウェアを爆速で作る
Problem 負債の上に負債を重ねて多重債務状態になる あとから修正するつもりだった雑なDB設計が残り続ける 次第に行き当たりばったりになってくる
aaa 保守曲線、放物線
あれ？ 何も変わってないな？
すごい人に相談してみた - アジャイルひよこクラブ 第1回イベント - アジャイルひよこクラブ第一回のイベントでソニックガーデン倉貫さんに相談してみました
相談 なんでうまくいかないの？
Q.なんのために ソフトウェアを作ってるの？
A. お客様の価値を実現するために作っている
Q. 君の言う価値って何？
A. ソフトウェアを導入することでコスト削減を実現すること
Q. コスト削減ってことは 従業員をクビにするってこと？
A. いいえ。空いたリソースを別のことに費やすことだと思います。
それ君の想像でしょ？
半信半疑だけど お客さんに聞いてみた
どうやって聞いたの？
コスト削減？ どうやって聞いたかはあとで話す。 人事部が使う社員管理システム、のようなものを受託していたときの話。 人事部が今までExcelで管理していたけど、管理が煩雑になってきたのでシステム化したいという話だった。 コストを削減することが目的ではなかった。何が目的だと思いますか？ ここの人事部は社員のモチベーションを管理すべくフォローアップする業務があった。そこに時間をかけることが出来るようになりたかった。
本当に実現したい「価値」に 目を向けていなかった
ゴールデンサークル * 我々のコンピュータは素晴らしく、美しいデザインで簡単に使え、親しみやすい商品です * ひとつ買いませんか？ * 我々のすることはすべて 世界を変えるという信念で行っています。違う考え方（Think Different）に価値があると信じています * 私たちが世界を変える手段は、美しくデザインされ簡単に使え、親しみやすい製品です * こうして素晴らしいコンピュータができあがりました
ゴールデン・トライアングル Why? How? What? 不可視の溝 Why What すると、両者の間に不可視の溝が生まれてしまう。 反対側から見る感覚 How?
Whyの実現を期待して Whatだけを言葉にしている 顧客は、 Whyの実現を期待して Whatだけを言葉にしている
WhatからHowを導き、 Whatだけを実現している 作り手は、 WhatからHowを導き、 Whatだけを実現している
その結果 「こうじゃなかった」に なってしまう
ゴールデン・トライアングル Why? How? What? 不可視の溝 Why What すると、両者の間に不可視の溝が生まれてしまう。 反対側から見る感覚 How?
Whyを聞き出して WhatとHowを導き、 Whyを実現する
ゴールデン・トライアングル Why? How? What? すると、両者の間に不可視の溝が生まれてしまう。 反対側から見る感覚 How?
なぜ作るのかを 顧客自身に言葉にしてもらう プラクティス① 受注する前に なぜ作るのかを 顧客自身に言葉にしてもらう このとき以降から、やり方が変わった。 開発者はHowを先に考えてしまう。だけど先にWhyを聞こうということ。
エレベーターピッチ(記入用) [課題解決： ] したい [対象： ] 向けの、 [名前： ] というプロダクトは、 [カテゴリ： ] です。 [課題解決： ] したい [対象： ] 向けの、 [名前： ] というプロダクトは、 [カテゴリ： ] です。 これは [重要な利点： ] ができ、 [代替手段： ] とは違って、 [決定手的な特長： ] が備わっている。
ダイエットアプリ/ぜい肉で育つダイペット
エレベーターピッチ(例) [楽しくダイエットを続けられるように] したい [女性] 向けの、 [ぜい肉で育つダイペット] というプロダクトは、 [育成型ダイエット支援アプリ] です。 これは [自分がやせた分、ペットに餌を与えて育てることや、ルームの模様替えが] ができ、 [体重を一覧やグラフで見れるだけのダイエットアプリ] とは違って、 [飽きずに楽しみながらダイエットを続けられる仕組み] が備わっている。
注意点 なるべく多くの関係者に書いてもらうこと 絶対に作り手の言葉だけでまとめないこと
プラクティス② How?の前にWhy?を聞く このとき以降から、やり方が変わった。
ある一つの機能・画面に対して なぜ？ どんなときに？ 誰が？ 使うかを、理解するまで作らない というルールを設けた
例
例 なぜ？ Google検索と照合して、データに存在しなかったり、相違がある店舗を探すため どんなときに？ 毎週月曜日に店舗情報の更新作業時に 誰が？ パートのおばちゃんが
How?の前にWhy? それは本当に今必要なものなのか？ それは本当に期待している価値を実現できるものなのか？ それはもっと他の手段で簡単に実現できないか？
それが説明できなければ Whyを聞いたことにはならない
疑問 なんでうまくいかないの？
自分の答え 顧客にとっての「価値」ではなく 単なる「手段」だけを提供しているから
Why?を聞いたら、 受託開発が180°変わった
ソフトウェアを作る人と、 ソフトウェアが欲しい人と、 ソフトウェアを使う人、 全員が幸せになれる仕事をする
ありがとうございました