「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。

1. ○○したら、
受託開発が180°変わった
2014.9.6 XP祭りLT

2. 自己紹介
 原田敦@harada4atsushi
 日本シーエイダブリュウ株式会社
 WEBアプリケーションエンジニア

3. 日本シーエイダブリュウとは
 主に受託開発
 Ruby on Rails
 WEBアプリケーション

4. アジャイルひよこクラブ
 ビギナー向け
 「実践」を増やしたい
 現場から変えて行く

5. うまくいかない受託開発

7. バグだ！！
即刻タダで直せ！
仕様書に書いてないぞ！
追加費用だ！

8. もう帰りたい…

9. イテレーションを導入してみたけど…
 タスクを消化しては、また次から次へと
タスクが作られる「わんこそば式開発」
 予定していた納期が迫ってきて突貫工事
 あっちを直したらこっちでバグが出る

10. あれ？
何も変わってないじゃん…

11. 相談してみました
- アジャイルひよこクラブ第1回イベント-

12. 君の言う価値って何？
 そのシステムを作る目的は何？
 人をクビにしてコストを削減すること？
 空いたリソースで別事業を進めること？

13. それ君の想像でしょ？

14. インセプションデッキやってみた
(エレベーターピッチ)

15. エレベーターピッチ(記入用)
• [課題解決： ] したい
• [対象： ] 向けの、
• [名前： ] というプロダクトは、
• [カテゴリ： ] です。
• これは
• [重要な利点： ] ができ、
• [代替手段： ] とは違って、
• [決定手的な特長： ] が備わっ
ている。

16. コスト削減

17. トップダウンとボトムアップ
 顧客は機能について、実現したい事柄か
らトップダウンで見る。
 開発者は機能について、手段の集合から
ボトムアップで見る。

18. トップダウンとボトムアップ
不可視の溝

19. How?の前に
Why?

20. How?の前にWhy?
 必須なのかそうでないのかがわかる
 全部作らなくても良くなる
 よりコストの低い代替案を提案出来る

21. 向いている方向が一致した

22. Why?を聞いたら、
受託開発が180°変わった

23. システムを作る人と、
システムが欲しい人と、
システムを使う人、
全員が幸せになれる仕事をする

24. ありがとうございました