1. 高速かつ高品質
トレードオフではありません
Ishigaki Naoki
石垣尚紀

2. class 石垣尚紀
include Agile::Mind
def experience
{sier: 6, web: 3} #+9years full stack
end
def skills
[:project_management, :ruby, :java, :mobile, :linux]
end
def projects
[:政府, :o2o, :自動車, :広告, :ベンチャー]
end
end

3. 品質は高く、スピードアップしたい
アイデアを形にして届ける！
アイデアを形にして届ける！
しかも、フィードバックが早いと、
次の開発でなにをするべきか参考になる！
いいね!
いいね!

4. どうしたら速くなるかな？
1. すばやくタイピングする!!
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
5. 人間がやらなくてもいいことは機械に任せる
6. 先のことはイメージはあっても深くは考えないでおく

5. 1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
5. 人間がやらなくてもいいことは機械に任せる
6. 先のことはイメージはあっても深くは考えないでおく
どうしたら速くなるかな？

6. 1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
a. →会話せずにコレ！というものをつくれる？設計せずに正しいものをつくれる？
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
5. 人間がやらなくてもいいことは機械に任せる
6. 先のことはイメージはあっても深くは考えないでおく
どうしたら速くなるかな？

7. 会話しないで人の想いを汲み取るゲーム
＜やること＞
この会場で
今日のお昼ごはんがうどん・そば・ラーメンのどれかだった人の
人数を教えてください。
＜ただし＞
時間がないので、誰とも話してはいけません。
油そばとソーキそばは、ラーメンに含めます。

8. 新しいジャンケンの開発ゲーム
＜やること＞
グー・チョキ・パーのルールを変更して、
みんなで新しいジャンケンをしましょう。
（優勝者には、プレゼントがあるかも .. ）
＜ただし＞
時間がないので、新ルールの設計はせずに、はじめましょう。

9. 1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
a. →会話せずにコレ！というものをつくれる？設計せずに正しいものをつくれる？
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
5. 人間がやらなくてもいいことは機械に任せる
6. 先のことはイメージはあっても深くは考えないでおく
どうしたら速くなるかな？

10. どうしたら速くなるかな？
1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
a. →会話せずにコレ！というものをつくれる？設計せずに正しいものをつくれる？
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
a. →疲れた頭と身体で、高度な判断力が必要な場面で、品質を保てるのかな？
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
a. 一切の味見がされていない料理を食べてみようか。
5. 人間がやらなくてもいいことは機械に任せる
6. 先のことはイメージはあっても深くは考えないでおく

11. どうしたら速くなるかな？
1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
a. →会話せずにコレ！というものをつくれる？設計せずに正しいものをつくれる？
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
a. →疲れた頭と身体で、高度な判断力が必要な場面で、品質を保てるのかな？
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
a. 一切の味見がされていない料理を食べてみようか。
5. 人間がやらなくてもいいことは機械に任せる
a. 機械は人間と違ったミスをしないから、いいかも。
6. 先のことはイメージはあっても深くは考えないでおく
a. 今日の予定が決まっている人は多いけど、１年後何してるかはふんわりさせておくよね。いいかも。

12. どうしたら速くなるかな？
1. すばやくタイピングする!!
a. →どれくらい速くなるかな？限界がありそう。
2. 会話とか設計なんてしてないで、とにかく手を動かす!!
a. →会話せずにコレ！というものをつくれる？設計せずに正しいものをつくれる？
3. 8時間ではなく、12時間を仕事すれば、1.5倍速!!
a. →疲れた頭と身体で、高度な判断力が必要な場面で、品質を保てるのかな？
4. 作ったものの品質チェックをしない。最初からバグのないものを作ればいい。
a. 一切の味見がされていない料理を食べてみようか。
5. 人間がやらなくてもいいことは機械に任せる
a. 機械は人間と違ったミスをしないから、いいかも。
6. 先のことはイメージはあっても深くは考えないでおく
a. 今日の予定が決まっている人は多いけど、１年後何してるかはふんわりさせておくよね。いいかも。
❌ 急ぐ、個人プレイ、ムリ、短縮 => 品質悪化
⭕ 品質を落とさないように、ムダを削ぎ落とす

13. そもそも品質って？
コレジャナイ 私が欲しいものは、コレジャナイ
ソレジャナイ 僕が作りたかったのは、ソレジャナイ
なんか変！ 僕が想定したとおりに、動いてない
設計通りに
動かない！ 僕が設計したとおりに、動いてない
ミスった！
サーバを壊してしまった！

14. 製造 検証 お届け
設計
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ
設計通りに
動かない！
品質と工程 品質を落とさないように、各工程のムダを削っていこう。
届けたい価値の整理
なんか変！
想定したとおりに
動かない！
人間はときどき、
ミスをする！

15. 大きな問題は
小さく分割する
Main Part

16. 製造
製造
設計通りに
動かない！

17. 製造の正体は...
● 製造 = 設計どおりに作る行為
○ ex: ビルド、コンパイル
■ プログラムを解釈して機械が実行できる状態に変換する作業
● 設計 = システムがどう動くべきか？を決める行為
○ => 仕様を決めたり、プログラミング、設定..etc
Ref: What Is Software Design? By Jack W. Reeves / (c)C++ Journal - 1992

18. 製造の正体はビルド
ビルド
Ref: What Is Software Design? By Jack W. Reeves / (c)C++ Journal - 1992
● 製造 = 設計どおりに作る行為
○ ex: ビルド、コンパイル
■ プログラムを解釈して機械が実行できる状態に変換する作業
● 設計 = システムがどう動くべきか？を決める行為
○ => 仕様を決めたり、プログラミング、設定..etc

19. 現場の実際
書く！ ビルド 書く！ ビルド 書く！ ビルド
ビ
ル
ド
設計
ビ
ル
ド
設計
ビ
ル
ド
設計
● 製造 = 設計どおりに作る行為
○ ex: ビルド、コンパイル
■ プログラムを解釈して機械が実行できる状態に変換する作業
● 設計 = システムがどう動くべきか？を決める行為
○ => 仕様を決めたり、プログラミング、設定..etc

20. ビルド 検証 お届け
設計
製造コスト≒０
届けたい
価値の
整理
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ
なんか変！
想定したとおりに
動かない！
人間はときどき、
ミスをする！

21. 設計
検証
届けたい
価値の
整理
お届け
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ
なんか変！
想定したとおりに
動かない！
人間はときどき、
ミスをする！
製造コスト≒０

22. 検証
検証
かなり大事なポイントです。
要チェック！
なんか変！
想定したとおりに
動かない！

23. 検証
検証
＜やり方１＞
人間の手でひとつひとつ確認する
→手動テスト
＜やり方２＞
機械に任せる
→自動テスト
なんか変！
想定したとおりに
動かない！

24. １人じゃ足りない!! 時間がかかる!!
データの設定がうまくいかない !!
すみません、僕のパソコンだと動かないです !!
確認項目は、、よくわかんないけど、これでいいの
かな？（新人・応援できた人）
検証
方法１：手動テスト
ブラウザを開いて、１つ１つ動き
を確認していくぞー！
ときがたつと、仕様が複雑になっていき、
テストするべき項目が増える
テストで出たバグを修正した！
でも、またテスト.. するの... 😱
はじめは、さくさく
なるべく...
修正したくないな.. 😓

25. 検証
方法２：自動テスト
テストもプログラムで書こう！
このプロダクトコードには、
こういう機能があるから、
こんなテストを書けばいいよね。
プロダクト
コード テスト
テスト実行！
(Enterを ッターン！）
ときが
経つ
プロダクト
コード テストプロダクト
コードプロダクト
コードプロダクト
コードプロダクト
コード
テスト
テスト
テスト
テスト
テスト実行！
(Enterを ッターン！）

26. 検証
方法２：自動テスト
テストもプログラムで書こう！
このプロダクトコードには、
こういう機能があるから、
こんなテストを書けばいいよね。
プロダクト
コード テスト
テスト実行！
(Enterを ッターン！）
ときが
経つ
プロダクト
コード テストプロダクト
コードプロダクト
コードプロダクト
コードプロダクト
コード
テスト
テスト
テスト
テスト
テスト実行！
(Enterを ッターン！）
書くのに時間がかかる
たしかにテストそのものは、
機械がサッと終わらせてくれるけれど、
書くのに時間がかかっちゃうよ !! 😤
テストを書いてから
機能漏れに
気づく..

27. 検証
方法２：自動テスト
テストもプログラムで書こう！
このプロダクトコードには、
こういう機能があるから、
こんなテストを書けばいいよね。
プロダクト
コード テスト
テスト実行！
(Enterを ッターン！）
ときが
経つ
プロダクト
コード テストプロダクト
コードプロダクト
コードプロダクト
コードプロダクト
コード
テスト
テスト
テスト
テスト
テスト実行！
(Enterを ッターン！）
書くのに時間がかかる
たしかにテストそのものは、
機械がサッと終わらせてくれるけれど、
書くのに時間がかかっちゃうよ !! 😤
テストを書いてから
機能漏れに
気づく..
「テストを書く」
ということを、
よーく見直してみよう。

28. テストもプログラムで書こう！
このプロダクトコードには、
こういう機能があるから、
こんなテストを書けばいいよね。
検証
方法２：自動テスト
プロダクト
コード テスト
テスト実行！
(Enterを ッターン！）
ときが
経つ
プロダクト
コード テストプロダクト
コードプロダクト
コードプロダクト
コードプロダクト
コード
テスト
テスト
テスト
テスト
テスト実行！
(Enterを ッターン！）
仕様を書いていくだけ
だから、書きやすい
あとから漏れに気づく
ということは、
原理上なくなる。
プロダクト
コードも
何故か
書きやすくなる
↑を防ぎたいのだから、
どう動くべきか？のイメージを
テストコードで定義しよう。
テストというのは、プロダクトコードありきではな
く、想定ありき！想定が先。コードは後。
なんか変！ 僕が想定したとおりに、動いてない

29. 現場の実際
プロ
ダク
ト
コー
ド
テ
スト
どう動くべきか？のイメージを
テストコードで定義しよう。
テストというのは、プロダクトコードありきではなく、想定あり
き！想定が先。コードは後。
仕様を
明確に
する
テストが
通るよう
にプロダ
クトコード
を書く テスト
検
証設計 設計
プロ
ダク
ト
コー
ド
間違いを
修正する
テスト
検
証 設計
プロ
ダク
ト
コー
ド
間違いを
修正する
テスト ok!
検
証
テスト設計は手動でも時間がかかる。検証時間が大幅に短縮されて、その効果がずっと続く。

30. 設計
検
証
届けたい
価値の
整理
お届け
検証→高品質＆高速化！
検
証
検
証
検
証
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ
人間はときどき、
ミスをする！

31. お届け
お届け
人間はときどき、
ミスをする！

32. お届け
お届け
＜やり方１＞
人間の手で
ファイルをひとつひとつ確認し、
サーバを止めて、
間違いがないように気をつけて、
ダブルチェックと、
指差し確認で、
確認しながらファイルを差し替える
→手動デプロイ
＜やり方２＞
機械に任せる
→自動デプロイ
人間はときどき、
ミスをする！

33. お届け
方法１：手動デプロイ
みんなの修正をまとめよう！
ファイル送りますね！
A` B```B`
B``
A` B````
みんなのコードを
まとめてテスト実行！
ダブルチェックしつつ、
作業手順書をみて
デプロイ！
手順書
作業手順書をつくりますね。

34. お届け
方法２：自動デプロイ
みんなの修正をまとめよう！
もう、まとめました！テストも通ってま
す！
マージを検知！
設定に基づいてデプロイ！
マージ！
マージしたよ！
設定

35. 現場の実際
プロ
ダク
ト
コー
ド
テ
スト
仕様を
明確に
する
テストが
通るよう
にプロダ
クトコード
を書く
検
証設計
テスト ok!
● いつでもお届け可能な状態にしている（リリースに備えよう）
マ
ー
ジ
コードレビュ
OK!
レビュ
マージok!
デ
プ
ロ
イ
デプロイへ
マージ!
いまから
リリースしよう！
いいね!

36. 設計
検
証
届けたい
価値の
整理
マ
ー
ジ
お届けも高品質・高速化できる！
検
証
検
証
検
証
デ
プ
ロ
イ
レ
ビ
ュ
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ

37. 価値の整理
思い込みで作って
→コレジャナイ
できたモノを見て
ソレジャナイ
届けたい
価値の
整理

38. いったり、きたり
価値の整理
届けたい
価値の
整理
どういう価値を
どんな順番で
届けたいか？
それって
現実的に
実現可能なのか？

39. いったり、きたり
価値の整理
届けたい
価値の
整理
どういう価値を
どんな順番で
届けたいか？
それって
現実的に
実現可能なのか？
どうやって
作ろうかな？

40. いったり、きたり
価値の整理
届けたい
価値の
整理
どういう価値を
どんな順番で
届けたいか？
それって
現実的に
実現可能なのか？
どうやって
作ろうかな？
設計
設計とオーバラップしてる !!
→作りたい人と作る人の 協調作業

41. 価値の整理
届けたい
価値の
整理
どういう価値を
どんな順番で
届けたいか？
それって
現実的に
実現可能なのか？
どうやって
作ろうかな？
設計
設計とオーバラップしてる !!
→作りたい人と作る人の協調作業
いったり、きたり設計を抜きには
語れない

42. 設計
ソフトウェア設計
どうやって
作ろうかな？
こんなん
作れたら
面白いよね！
テ
ス
ト
コ
ー
ド
書
く
レ
ビ
ュ
マ
ー
ジ仕様設計

43. 設計
違いは、複雑さを管理する技術力の差
テスト
レ
ビ
ュ
マ
ー
ジ
設計によっては、こんなことも ...
テ
ス
ト
コ
ー
ド
書
く
レ
ビ
ュ
マ
ー
ジ仕様設計
仕様設計

44. オブジェクト指向プログラミング
＜超ザックリ＞
関心事を分離して、自分が知っておけばいいことは自分の中に留めるし、
人に聞けば済むことを自分が知っておかないプログラミング手法
1ヶ月前の今日、ラーメン食べた
人、手を挙げてください！
1. みなさん、列になって私の前
に並んでください。
2. 順番に財布を出してください。
その際に必ず「２つ折り」「長
財布」などタイプを教えてくだ
さい。
3. 以下を繰り返す
a. 財布を開きます。開け
ない場合はエラーとしま
す。
b. 財布のポケットの数を
調べて順番にレシート
を抜き出し日付順に並
び替えて1ヶ月前の日
の分を取り出します。
c. レシートに「ラーメン」と
あれば..
4. 順番にクラウド家計簿のアカ
手帳の記録に、、、
あった！
クラウド家計簿に問い合わせ、
記録あった！
長財布のここ、レシートに、、あっ
た！
なにやってるか
よくわからない。。
テストも書きにくい..手続き型プログラミング

45. https://robots.thoughtbot.com/sandi-metz-rules-for-developers
クラスは100行まで
メソッドは5行まで
パラメータは４つまで
コントローラでインスタンス化し
てよいオブジェクトは１つまで

46. https://refactoring.guru/smells/

47. 手続き型プログラミングの弊害
仕様設計
テスト
レ
ビ
ュ
マ
ー
ジ
計画づくり
ソレじゃない！
今さら言われても ..
フィーチャーの整理
どう動くべきか？
先にしっかり
考えておかないと。。
どの機能が必要か？
先にしっかり
考えておかないと。。
どこをどう変更すれば
いいのだろう？
また変更することになったら
大変だなぁ。

48. 現場の実際
ソフトウェア設計
どうやって
作ろうかな？
こんなん
作れたら
面白いよね！
テ
ス
ト
コ
ー
ド
書
く
レ
ビ
ュ
マ
ー
ジ仕様設計価値の整理
エンジニアの技術力次第。
まだまだ、手続きを書いてしまう人もいる。
ちゃんと書けるエンジニアの存在 が必要不可欠！
コレがやりたい。
最小でやるな
ら、AとBをやろう
かな。

49. 設計
検
証
価値の
整理
マ
ー
ジ
価値の整理・設計を高速・高品質にできた？
検
証
検
証
検
証
デ
プ
ロ
イ
レ
ビ
ュ
思い込みで作って
→コレジャナイ

50. 当初の思い込み
比べてみよう
私が欲しいのは
コレじゃないなー。
本当にほしかったのは
コレ！周りのみんな
使ってるよ！
そうそう！
こんな感じ！
使ってる友達も増えてきたよ！

51. 当初の思い込み
比べてみよう
私が欲しいのは
コレじゃないなー。
そうそう！
こんな感じ！
使ってる友達も増えてきたよ！
俊敏な開発 本当にほしかったのは
コレ！周りのみんな
使ってるよ！

52. アジャイルな開発
Last Part

53. 役立つ実践いろいろ

54. こだわらない
厳密なアジャイルなんてない
アジャイル警察もいない

55. アジャイル宣言の背後にある12の原則
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更にはたとえ開発の後期であっても歓迎します。変化を味方につけることに
よって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースしま
す。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりませ
ん。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事
終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること
です。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持
できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自
分たちのやり方を最適に調整します。

56. http://agilemanifesto.org/iso/ja/manifesto.html

57. Don’t do Agile,
Be Agile

58. もっと詳しく知りたい

59. もっと詳しく知りたい

60. もっと詳しく知りたい
http://bliki-ja.github.io/

61. もっと詳しく知りたい
http://objectclub.jp/technicaldoc/xp/agile_misunderstanding

62. まとめ
Summarize

63. 品質は高く、高速に届ける。(継続的に)
当初の思い込み
私が欲しいのは
コレじゃないなー。
本当にほしかったのは
コレ！周りのみんな
使ってるよ！
そうそう！
こんな感じ！
使ってる友達も増えてきたよ！

64. ストップウォッチの開発
スタートの合図のあと、時間を数えてください。
このくらいかな？と思ったところで手を挙げてください。
ただし、時計を使ってはいけません。
ワーク：みんなでやってみよう

65. スタートの合図のあと、時間を数えてください。
このくらいかな？と思ったところで手を挙げてください。
ただし、時計を使ってはいけません。
顧客が本当に欲しかったもの：カップ麺に添える野菜
POが作りたかったもの：カップ麺タイマー
（しかもカップ麺を１分と誤解している）
テスト：人間が時間計測
ストップウォッチの開発

66. アジャイルな開発
を支える基礎
Fundament
時間があれば！

67. 実現するうえで、大事なことってなんだろう？
当初の思い込み
私が欲しいのは
コレじゃないなー。
本当にほしかったのは
コレ！周りのみんな
使ってるよ！
そうそう！
こんな感じ！
使ってる友達も増えてきたよ！
ワーク：みんなではなしあってみよう

68. 〜前略〜
〜後略〜

69. http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead
設計重要！ その場しのぎ→変更困難化、品質悪化！

70. http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead
開
発
開発 開発
開発 開発 開発 開発 開発 開発 開発

71. http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead

72. テスト、連続的インテグレーション、リファクタリングな
どを実現し、その効果を利用する
本当にほしかったのは
コレ！周りのみんな
使ってるよ！
中心にあるのは、
人と人のコラボレーション！