SlideShare a Scribd company logo
1 of 81
Download to read offline
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDはじめて物語
2016/2/27 TDDBC in Tokyo 2016-02
大中浩行
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テスト駆動開発(Test Driven Development)
TDDとは?
Generated by 社畜ちゃん台詞メーカー
http://blog.oukasoft.com/OS/
#ccc_r11
Copyright 2016 Hiroyuki Onaka
By National Photo Company [Public domain], via Wikimedia Commons
https://en.wikipedia.org/wiki/Bulletproof_vest
テストファーストしたら?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
?
By NASA [Public domain], via Wikimedia Commons
https://en.wikipedia.org/wiki/Self-replicating_machine
テストが自動化されたら?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDとは
「TDDとは、プログラミングとテストすること
を工程として統合した開発スタイルです。」
- @setoazusa
#ccc_r11
Copyright 2016 Hiroyuki Onaka
アジェンダ
• TDDとは
• テストファーストとは
• なぜTDDするのか
• TDDには何が必要か
• なぜTDDするのか(again)
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDとは
#ccc_r11
Copyright 2016 Hiroyuki Onaka ※絶版
TDDとは
#ccc_r11
Copyright 2016 Hiroyuki Onaka
By Improve It (Flickr: Kent Beck no Workshop Mapping XP.) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via
Wikimedia Commons
https://en.wikipedia.org/wiki/Kent_Beck
Kent Beck
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDとは
1.素早くテストを追加する。
2.すべてのテストを実行し、新しいテストの失敗を確
認する。
3.小さな修正を行う。
4.すべてのテストを実行し、すべての成功を確認する。
5.重複を取り除くためにリファクタリングを行う。
ケント・ベック(著)長瀬嘉秀(訳)「テスト駆動開発入門」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
座標平面上にある点で、x座標 (x-coordinate) 、y座標
(y-coordinate) がともに整数である点を格子点と呼び
ます。
• x座標とy座標を与えて格子点を生成してください
• 生成した格子点からx座標とy座標を取得してください
• 生成した格子点から文字列表記 (notation) を取得してく
ださい
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テストを追加する。
@RunWith(JUnit5.class)
public class GridPoinTest {
@Test
public void x座標とy座標を与えて格子点を生成できること(){
}
@Test
public void 生成した格子点からx座標とy座標を取得できること(){
}
@Test@Disabled
public void 生成した格子点から文字列表記を取得できること() {}
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テストを追加する。
@RunWith(JUnit5.class)
public class GridPoinTest {
@Test
public void x座標とy座標を与えて格子点を生成できること(){
// コンストラクターのテストは通常書かないですが、
// 課題の「格子点を生成できること」と対応を取るためにあえて
// テスト化しています
GridPoint point = new GridPoint(4, 7);
assertNotNull(point);
}
@Test
public void 生成した格子点からx座標とy座標を取得できること(){
GridPoint point = new GridPoint(4, 7);
assertEquals(4, point.getX());
}
@Test@Disabled
public void 生成した格子点から文字列表記を取得できること() {}
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
すべてのテストを実行し、新しいテストの失敗を
確認する。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
小さな修正を行う。
public class GridPoint {
private int x;
public GridPoint(int x, int y) {
this.x = x;
}
public int getX() {
return x;
}
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
すべてのテストを実行し、すべての成功を確認す
る。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
再びテストを追加する。
@Test
public void x座標とy座標を与えて格子点を生成できること() {
GridPoint point = new GridPoint(4, 7);
assertNotNull(point);
@Test
public void 生成した格子点からx座標とy座標を取得できること() {
GridPoint point = new GridPoint(4, 7);
assertAll(
() -> { assertEquals(4, point.getX()); },
() -> { assertEquals(7, point.getY()); }
);
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
再びテストを実行する。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
修正を行う。
public class GridPoint {
private int x;
private int y;
public GridPoint(int x, int y) {
this.x = x;
this.y = y;
}
public int getX() { return x; }
public int getY() { return y; }
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
すべてのテストを実行し、すべての成功を確認す
る。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
重複を取り除くためにリファクタリングを行う。
private GridPoint point;
@BeforeEach
public void before(){
point = new GridPoint(4, 7);
}
@Test
public void x座標とy座標を与えて格子点を生成できること() {
assertNotNull(point);
}
@Test
public void 生成した格子点からx座標とy座標を取得できること() {
assertAll(
() -> { assertEquals(4, point.getX()); },
() -> { assertEquals(7, point.getY()); }
);
}
#ccc_r11
Copyright 2016 Hiroyuki Onaka
フィードバックループ
「運転というのはね、車を正しい方向に走らせ
ることじゃないの。常に注意を払って、こっち
に行ったら少し戻して、あっちに行ったら少し
戻して、そうやって軌道修正していくものよ」
これがXP のパラダイムだ。注意して、適応して、
変更する。
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テストファー
スト
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDの観点から
TDDでは、なぜテストファーストするのか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「テストファーストしてないテストは怖い」
-@setoazusa
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テストを先に書くことはどんな意味があるのか
• テストに求められる機能は、成功するとGreenに
なり、そうでない時にRedになること
• テストファーストしてないテストは、「まず失
敗させる」ことができないため、テストとして
の信頼性がさがる
• 「失敗していないテストのカバレッジは50%し
かない」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
思い出してみてください。
自動化されてないテストで、テスト項目書に
「正しく表示されていること」と記載されてい
て、検証に苦労したことはありませんか?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
ユニットテストが「テスト」である以上、テス
トの答えとなるものは先に用意されているはず
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDではなぜテストファーストするのか
あくまでテストのあるべき姿を追求したことで、
結果としてテストを最初に書くことになるイ
メージ。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
よくある質問
「TDDって、テストを必ず先に書かなければい
けないんですか?」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
http://www.slideshare.net/YasutoEnjoji/20150621-asbc-pub/29
#ccc_r11
Copyright 2016 Hiroyuki Onaka
テストファーストよりも大事なこと
• 「1ヶ月かけてコーディング、1ヶ月かけてテ
スト」のようなアンチパターンから、どれだ
けプログラミングとテストを連携して開発が
できるようにするか
• テストによって開発が駆動されているか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
• 大事なのは、システムをデリバリーするために、
どうステップを踏んでいくか
• テストファーストを導入できるなら、すればよ
い。
• そうでないとしても、ユニットテストより上位
レベルのテストの項目は先に作成するなど、テ
スト同士で補完していけば良い。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
ただ、IT技術者として手札は多いほうがよいの
で、スキルとしてテストファーストできるにこ
したことはないです。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
なぜTDDする
のか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
最初に答えをいいます
「継続的インテグレーションをもたらすための
核心である素早いフィードバックは、ユニット
テストのカバレッジが十分にないと可能になら
ないのだ」
Jez Humble,David Farley(著) 和智右桂(訳)
「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「エラーが自動的に増殖するのがDevOps」
https://twitter.com/devops_borat/status/41587168870797312
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「テストがないコードはレガシーコードだ!」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
Test Early and Often
Microsoft 「Test Early and Often」
https://msdn.microsoft.com/library/ee330950.aspx
#ccc_r11
Copyright 2016 Hiroyuki Onaka
Shift left Testing
By DonFiresmith (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)],
via Wikimedia Commons
https://en.wikipedia.org/wiki/Shift_left_testing
#ccc_r11
Copyright 2016 Hiroyuki Onaka
とはいうものの…
• TDD=テスト自動化ではない
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDが目指すもの
「動作するきれいなコード」、ロン・ジェフ
リーズのこの簡潔な言葉は、TDD(テスト駆動
開発)の目標である。動作するきれいなコード
は、あらゆる理由で価値がある。
Kent Beck(著) 長瀬 嘉秀(監訳) 「テスト駆動開発入門」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「動作するきれいなコード」
「きれいなコード」とは?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
By Wikinaut (Own work (own photo)) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0
(http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
https://ja.wikipedia.org/wiki/スパゲッティプログラム
きれいでないコード(スパゲッティーコード)
#ccc_r11
Copyright 2016 Hiroyuki Onaka
では「きれいなコード」とは
…なんだ?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「動作するきれいなコード」を英語で言うと、
「Clean code that works」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
#ccc_r11
Copyright 2016 Hiroyuki Onaka
とはいっても、「クリーン」にも色々ありまして
• 複雑度
• メソッド/関数の行数
• コードスタイル
• 命名規則
• etc…
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「クリーンなコード」についてはこちらを
#ccc_r11
Copyright 2016 Hiroyuki Onaka
どうテストす
るか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「不安をテストで表現する」
http://gihyo.jp/dev/serial/01/tdd/0010
#ccc_r11
Copyright 2016 Hiroyuki Onaka
@t_wada曰く
#ccc_r11
Copyright 2016 Hiroyuki Onaka
私たちプログラマの手を止めるものは何でしょうか。私は
「不安」だと思っています。「もしかしたら」という感情で
すね。「もしかしたら,自分の書いているコードは間違って
いるかもしれない」「もしかしたら,ライブラリの使い方が
正しくないかもしれない…」。(略)
だから,これから書くコードに対して,if文があるだろうな
とか,ループがあるとか,正規表現使わなきゃいけないなと
か,そういった自分自身に対する不安,これから書くことに
対する不安に対して,テストを書いていきます。
「[動画で解説]和田卓人の“テスト駆動開発”講座 第10回 テストの最小単位は不安」
http://gihyo.jp/dev/serial/01/tdd/0010
#ccc_r11
Copyright 2016 Hiroyuki Onaka
• プログラマーとしての「不安」
• データベース技術者としての「不安」
• インフラ担当としての「不安」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
• お互いが不安に感じていることを認める。
• その人の弱さを認める。それを品質保証の出
発点にする。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「信頼で結ばれた共同体」
James O. Coplien , Neil B. Harriosn (著), 和智右桂 (翻訳) 「組織パターン」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
もう一つ、よく聞く話
「TDDでテストすれば、他のテストはいらない
んですか?」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
開発者と品質保証の関係
• 開発者テストのレベルで「開発者の思ったと
おりに動く」ことが保証されているから、品
質保証のテストは品質の検証に注力できる
• 品質保証のテストが後詰めとして控えている
から、開発者テストはプログラムの中の勘所
を押さえることに注力できる
#ccc_r11
Copyright 2016 Hiroyuki Onaka
製品品質モデル(JIS X 25010)
• 機能適合性
• 性能効率性
• 互換性
• 使用性
• 信頼性
• セキュリティ
• 保守性
• 移植性
JIS X 25010(ISO/IEC 25010)
「システム及びソフトウェア製品の品質要求及び評価(SQuaRE)- システム及びソフトウェア品質モデル」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
アジャイルテストの四象限
Lisa Crispin,Janet Gregory(著) 榊原彰(監訳)「実践アジャイルテスト」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「二重のフィードバックループ」
Steve Freeman, Nat Pryce「Growing Object-Oriented Software, Guided by Tests」
(邦訳「実践テスト駆動開発」)
#ccc_r11
Copyright 2016 Hiroyuki Onaka
BDD(Behavior-Driven Development)
John Ferguson Smart
「BDD in Action Behavior-Driven Development for the whole software lifecycle」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
なぜテストす
るか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDはプログラマーの義務?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
だがちょっと待って欲しい
「テストを書く/書かない」ということは、道
義的な責任の問題ではない
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「テスト」と責任の関係
• テストという工程は、その性格上、品質保証
や、成果物への責任と強い関係をもっている
• 「テストを書くべきだ」という論に明快に異
を唱えられる人は少ない
#ccc_r11
Copyright 2016 Hiroyuki Onaka
• 開発プロセスの望ましい姿を論じていたはず
が、道義的な責任の問題になってしまう
• テストを書く人と書かない人の間の感情的な
対立は、何も生み出さない
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「TDDやれば偉いわけじゃない」
http://b.hatena.ne.jp/entry/232721484/comment/t-wada
#ccc_r11
Copyright 2016 Hiroyuki Onaka
幻想を捨てる
• カバレッジ100%
• ユニットテストを書けばバグがなくなる
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「テストを書く」ということは、継続的インテ
グレーション(CI)や静的解析、コードレビュー
やペアプログラミングなど、チーム開発のため
のプラクティスと連携して、初めてその力を発
揮する。
#ccc_r11
Copyright 2016 Hiroyuki Onaka
TDDが銀の弾丸でないなら、なぜTDDするのか
その前に、ちょっと世の中の様子を見てみよう
#ccc_r11
Copyright 2016 Hiroyuki Onaka
https://twitter.com/yotchang4s/status/699030352686256129
#ccc_r11
Copyright 2016 Hiroyuki Onaka
https://www.google.co.jp/search?q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&tbm=n
ws
#ccc_r11
Copyright 2016 Hiroyuki Onaka
https://twitter.com/setoazusa/status/650250873017204736
#ccc_r11
Copyright 2016 Hiroyuki Onaka
#笑ってはいけないSIer
#ccc_r11
Copyright 2016 Hiroyuki Onaka
我々はなぜここにいるのか
• 生活のため?
• お金のため?
• プロだから?
• 技術者だから?
#ccc_r11
Copyright 2016 Hiroyuki Onaka
なぜTDDするのか
私の場合…
#ccc_r11
Copyright 2016 Hiroyuki Onaka
信頼できる成果物のために
「技術力は信頼関係につながる。作業を正確に
見積もり、最初から品質の高いものを届け、高
速なフィードバックループを構築すれば、あな
たは信頼されるパートナーになれる。」
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
強いチームとは
メンバーを集めた「プロジェクト」を、メン
バーのバックグラウンドを尊重できる「コミュ
ニティ」に出来るか
#ccc_r11
Copyright 2016 Hiroyuki Onaka
「君が質の高いソフトウェアを届けることは誰
にも止められない。君が現場に立って、お客さ
んに向けてプロジェクトの状況と、プロジェク
トに必要なことを誠実に伝えることも誰にも止
められないんだ。」
Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳)
「アジャイルサムライ 達人開発者への道」
#ccc_r11
Copyright 2016 Hiroyuki Onaka
ありがとうございました!
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://blog.fieldnotes.jp/

More Related Content

What's hot

VMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMVMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMyy yank
 
「GebとSpockではじめるシステムテスト自動化」
「GebとSpockではじめるシステムテスト自動化」「GebとSpockではじめるシステムテスト自動化」
「GebとSpockではじめるシステムテスト自動化」Hiroyuki Ohnaka
 
テスト駆動開発の進化
テスト駆動開発の進化テスト駆動開発の進化
テスト駆動開発の進化Yukei Wachi
 
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめTDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめKei Sawada
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門Shuji Watanabe
 
静的解析ツール Klocworkによる 機能安全規格への対応
静的解析ツール Klocworkによる 機能安全規格への対応静的解析ツール Klocworkによる 機能安全規格への対応
静的解析ツール Klocworkによる 機能安全規格への対応Masaru Horioka
 
XP祭り2017 LT 「DevOps再考」(改題)
XP祭り2017 LT 「DevOps再考」(改題)XP祭り2017 LT 「DevOps再考」(改題)
XP祭り2017 LT 「DevOps再考」(改題)Hiroyuki Ohnaka
 
Klocwork カスタムチェッカー紹介
Klocwork カスタムチェッカー紹介Klocwork カスタムチェッカー紹介
Klocwork カスタムチェッカー紹介Masaru Horioka
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローques_staff
 
Tddのすゝめ
TddのすゝめTddのすゝめ
Tddのすゝめ将 高野
 
静的解析ツールKlocwork によるCERT-C/CWE対応
静的解析ツールKlocwork によるCERT-C/CWE対応静的解析ツールKlocwork によるCERT-C/CWE対応
静的解析ツールKlocwork によるCERT-C/CWE対応Masaru Horioka
 
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCIどうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCIKoichiro Sumi
 
CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料Yasui Tsutomu
 
Klocwork 2017.1アップデート
Klocwork 2017.1アップデートKlocwork 2017.1アップデート
Klocwork 2017.1アップデートMasaru Horioka
 
静的解析Klocwork とJenkins CIの連携
静的解析Klocwork とJenkins CIの連携静的解析Klocwork とJenkins CIの連携
静的解析Klocwork とJenkins CIの連携Masaru Horioka
 
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社Game Tools & Middleware Forum
 
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カットRakuten Group, Inc.
 
テスト駆動開発へようこそ
テスト駆動開発へようこそテスト駆動開発へようこそ
テスト駆動開発へようこそShuji Watanabe
 

What's hot (20)

VMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMVMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VM
 
「GebとSpockではじめるシステムテスト自動化」
「GebとSpockではじめるシステムテスト自動化」「GebとSpockではじめるシステムテスト自動化」
「GebとSpockではじめるシステムテスト自動化」
 
テスト駆動開発の進化
テスト駆動開発の進化テスト駆動開発の進化
テスト駆動開発の進化
 
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめTDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門
 
静的解析ツール Klocworkによる 機能安全規格への対応
静的解析ツール Klocworkによる 機能安全規格への対応静的解析ツール Klocworkによる 機能安全規格への対応
静的解析ツール Klocworkによる 機能安全規格への対応
 
XP祭り2017 LT 「DevOps再考」(改題)
XP祭り2017 LT 「DevOps再考」(改題)XP祭り2017 LT 「DevOps再考」(改題)
XP祭り2017 LT 「DevOps再考」(改題)
 
Klocwork カスタムチェッカー紹介
Klocwork カスタムチェッカー紹介Klocwork カスタムチェッカー紹介
Klocwork カスタムチェッカー紹介
 
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フローKDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
 
静的解析のROI
静的解析のROI静的解析のROI
静的解析のROI
 
Tddのすゝめ
TddのすゝめTddのすゝめ
Tddのすゝめ
 
Klocworkのご紹介
Klocworkのご紹介Klocworkのご紹介
Klocworkのご紹介
 
静的解析ツールKlocwork によるCERT-C/CWE対応
静的解析ツールKlocwork によるCERT-C/CWE対応静的解析ツールKlocwork によるCERT-C/CWE対応
静的解析ツールKlocwork によるCERT-C/CWE対応
 
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCIどうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
 
CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料CodeZineAcademy TDD実践講座PR資料
CodeZineAcademy TDD実践講座PR資料
 
Klocwork 2017.1アップデート
Klocwork 2017.1アップデートKlocwork 2017.1アップデート
Klocwork 2017.1アップデート
 
静的解析Klocwork とJenkins CIの連携
静的解析Klocwork とJenkins CIの連携静的解析Klocwork とJenkins CIの連携
静的解析Klocwork とJenkins CIの連携
 
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
 
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
 
テスト駆動開発へようこそ
テスト駆動開発へようこそテスト駆動開発へようこそ
テスト駆動開発へようこそ
 

Viewers also liked

実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記Hiroyuki Ohnaka
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証Yasuharu Nishi
 
TDD のこころ
TDD のこころTDD のこころ
TDD のこころTakuto Wada
 
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014Takuto Wada
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術Takuto Wada
 
Pull Request & TDD 入門
Pull Request & TDD 入門Pull Request & TDD 入門
Pull Request & TDD 入門ESM SEC
 
Androidアプリ開発にクリーンアーキテクチャを取り入れよう
Androidアプリ開発にクリーンアーキテクチャを取り入れようAndroidアプリ開発にクリーンアーキテクチャを取り入れよう
Androidアプリ開発にクリーンアーキテクチャを取り入れよう kan-notice
 
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)Amazon Web Services Japan
 
ペアプログラミング ホントのところ
ペアプログラミング ホントのところペアプログラミング ホントのところ
ペアプログラミング ホントのところTakuto Wada
 
Blue-Green Deployment Pattern on AWS
Blue-Green Deployment Pattern on AWSBlue-Green Deployment Pattern on AWS
Blue-Green Deployment Pattern on AWS真吾 吉田
 
ソフトウェア開発の3本柱
ソフトウェア開発の3本柱ソフトウェア開発の3本柱
ソフトウェア開発の3本柱Shuji Watanabe
 
エンジョイ☆スクレイピング
エンジョイ☆スクレイピングエンジョイ☆スクレイピング
エンジョイ☆スクレイピングKazufumi Ohkawa
 
iOSビヘイビア駆動開発
iOSビヘイビア駆動開発iOSビヘイビア駆動開発
iOSビヘイビア駆動開発Brian Gesiak
 
テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践Yuusuke Takeuchi
 
Visual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsiVisual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsiTadahiro Ishisaka
 
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して Rakuten Group, Inc.
 
ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)Takatoshi Yamada
 

Viewers also liked (20)

実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
 
TDD のこころ
TDD のこころTDD のこころ
TDD のこころ
 
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
 
Bambooによる継続的デリバリー
Bambooによる継続的デリバリーBambooによる継続的デリバリー
Bambooによる継続的デリバリー
 
Pull Request & TDD 入門
Pull Request & TDD 入門Pull Request & TDD 入門
Pull Request & TDD 入門
 
Androidアプリ開発にクリーンアーキテクチャを取り入れよう
Androidアプリ開発にクリーンアーキテクチャを取り入れようAndroidアプリ開発にクリーンアーキテクチャを取り入れよう
Androidアプリ開発にクリーンアーキテクチャを取り入れよう
 
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)
AWS Blackbelt 2015シリーズ Amazon EC2 Container Service (Amazon ECS)
 
ペアプログラミング ホントのところ
ペアプログラミング ホントのところペアプログラミング ホントのところ
ペアプログラミング ホントのところ
 
Blue-Green Deployment Pattern on AWS
Blue-Green Deployment Pattern on AWSBlue-Green Deployment Pattern on AWS
Blue-Green Deployment Pattern on AWS
 
Shizudev git hub宿題
Shizudev git hub宿題Shizudev git hub宿題
Shizudev git hub宿題
 
ソフトウェア開発の3本柱
ソフトウェア開発の3本柱ソフトウェア開発の3本柱
ソフトウェア開発の3本柱
 
エンジョイ☆スクレイピング
エンジョイ☆スクレイピングエンジョイ☆スクレイピング
エンジョイ☆スクレイピング
 
iOSビヘイビア駆動開発
iOSビヘイビア駆動開発iOSビヘイビア駆動開発
iOSビヘイビア駆動開発
 
テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践テスト駆動ゲーム開発をJava scriptで実践
テスト駆動ゲーム開発をJava scriptで実践
 
Visual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsiVisual studio 2015 update1 ctpとcsi
Visual studio 2015 update1 ctpとcsi
 
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
 
TDDBC東京 1.6 LT
TDDBC東京 1.6 LTTDDBC東京 1.6 LT
TDDBC東京 1.6 LT
 
ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)ライトニングトーク Windows10体験記 201510_山p(アップロード用)
ライトニングトーク Windows10体験記 201510_山p(アップロード用)
 

Similar to 「TDDはじめて物語」 #tddbc

What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...Yoshifumi Kawai
 
Tensor flow勉強会3
Tensor flow勉強会3Tensor flow勉強会3
Tensor flow勉強会3tak9029
 
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能Yoshifumi Kawai
 
ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03Daiki Maekawa
 
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)NTT DATA Technology & Innovation
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについてMasahito Zembutsu
 
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1MasuqaT
 
Android cleanarchitecture
Android cleanarchitectureAndroid cleanarchitecture
Android cleanarchitectureTomoaki Imai
 
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンドTakehara Ryo
 
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナー
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナーRICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナー
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナーcontest-theta360
 
LightSwitch 結局何ができるの
LightSwitch 結局何ができるのLightSwitch 結局何ができるの
LightSwitch 結局何ができるのYoshitaka Seo
 
わんくま名古屋 #37 (20151114) TDD道場 #25
わんくま名古屋 #37 (20151114) TDD道場 #25わんくま名古屋 #37 (20151114) TDD道場 #25
わんくま名古屋 #37 (20151114) TDD道場 #25Yasuhiko Yamamoto
 
Android Studioの魅力
Android Studioの魅力Android Studioの魅力
Android Studioの魅力Keiji Ariyama
 
Osc2010 tokyo fall@kaorun
Osc2010 tokyo fall@kaorunOsc2010 tokyo fall@kaorun
Osc2010 tokyo fall@kaorunKaoru NAKAMURA
 
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~Hiroyuki Ohnaka
 
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
Observable Everywhere  - Rxの原則とUniRxにみるデータソースの見つけ方Observable Everywhere  - Rxの原則とUniRxにみるデータソースの見つけ方
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方Yoshifumi Kawai
 
LoRaWANとAzure IoT Hub接続ハンズオン
LoRaWANとAzure IoT Hub接続ハンズオンLoRaWANとAzure IoT Hub接続ハンズオン
LoRaWANとAzure IoT Hub接続ハンズオンTomokazu Kizawa
 
わんくま同盟大阪勉強会#61
わんくま同盟大阪勉強会#61わんくま同盟大阪勉強会#61
わんくま同盟大阪勉強会#61TATSUYA HAYAMIZU
 
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみるasa88
 

Similar to 「TDDはじめて物語」 #tddbc (20)

What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
 
Tensor flow勉強会3
Tensor flow勉強会3Tensor flow勉強会3
Tensor flow勉強会3
 
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
ライブラリ作成のすゝめ - 事例から見る個人OSS開発の効能
 
ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03ROS JAPAN Users Group Meetup 03
ROS JAPAN Users Group Meetup 03
 
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
 
2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて2014年を振り返る 今年の技術トレンドとDockerについて
2014年を振り返る 今年の技術トレンドとDockerについて
 
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1
C#のコード解析ってなんだ@20160825 CenterCLR.学生 #1
 
Android cleanarchitecture
Android cleanarchitectureAndroid cleanarchitecture
Android cleanarchitecture
 
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド
自動化ーニバルだよ!GDC16に見る自動化技術とテストのトレンド
 
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナー
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナーRICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナー
RICOH THETA x IoT デベロッパーズ コンテスト 第2回クラウドAPIセミナー
 
LightSwitch 結局何ができるの
LightSwitch 結局何ができるのLightSwitch 結局何ができるの
LightSwitch 結局何ができるの
 
わんくま名古屋 #37 (20151114) TDD道場 #25
わんくま名古屋 #37 (20151114) TDD道場 #25わんくま名古屋 #37 (20151114) TDD道場 #25
わんくま名古屋 #37 (20151114) TDD道場 #25
 
Android Studioの魅力
Android Studioの魅力Android Studioの魅力
Android Studioの魅力
 
Osc2010 tokyo fall@kaorun
Osc2010 tokyo fall@kaorunOsc2010 tokyo fall@kaorun
Osc2010 tokyo fall@kaorun
 
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~
Java8移行は怖くない~エンタープライズ案件でのJava8移行事例~
 
Spring social の基礎
Spring social の基礎Spring social の基礎
Spring social の基礎
 
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
Observable Everywhere  - Rxの原則とUniRxにみるデータソースの見つけ方Observable Everywhere  - Rxの原則とUniRxにみるデータソースの見つけ方
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
 
LoRaWANとAzure IoT Hub接続ハンズオン
LoRaWANとAzure IoT Hub接続ハンズオンLoRaWANとAzure IoT Hub接続ハンズオン
LoRaWANとAzure IoT Hub接続ハンズオン
 
わんくま同盟大阪勉強会#61
わんくま同盟大阪勉強会#61わんくま同盟大阪勉強会#61
わんくま同盟大阪勉強会#61
 
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる
触ってみよう! Robotics Studio -レゴマインドストームRCXを動かしてみる
 

More from Hiroyuki Ohnaka

remote Docker over SSHが熱い
remote Docker over SSHが熱いremote Docker over SSHが熱い
remote Docker over SSHが熱いHiroyuki Ohnaka
 
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験Hiroyuki Ohnaka
 
Remote Development with Visual Studio Code & A clean dev env, working every ...
Remote Development with Visual Studio Code &  A clean dev env, working every ...Remote Development with Visual Studio Code &  A clean dev env, working every ...
Remote Development with Visual Studio Code & A clean dev env, working every ...Hiroyuki Ohnaka
 
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話ChefとItamaeをニコイチしてAnsibleにマイグレーションした話
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話Hiroyuki Ohnaka
 
「WindowsデスクトップでWeb開発 改訂版」サンプル
「WindowsデスクトップでWeb開発 改訂版」サンプル「WindowsデスクトップでWeb開発 改訂版」サンプル
「WindowsデスクトップでWeb開発 改訂版」サンプルHiroyuki Ohnaka
 
Microsoft DocsにContributeした話
Microsoft DocsにContributeした話Microsoft DocsにContributeした話
Microsoft DocsにContributeした話Hiroyuki Ohnaka
 
Azure functions+typescript
Azure functions+typescriptAzure functions+typescript
Azure functions+typescriptHiroyuki Ohnaka
 
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版Hiroyuki Ohnaka
 
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版Hiroyuki Ohnaka
 
仮想通貨始めました~GethではじめるEthereum~
仮想通貨始めました~GethではじめるEthereum~仮想通貨始めました~GethではじめるEthereum~
仮想通貨始めました~GethではじめるEthereum~Hiroyuki Ohnaka
 
錬金術MeetUpへのお誘い
錬金術MeetUpへのお誘い錬金術MeetUpへのお誘い
錬金術MeetUpへのお誘いHiroyuki Ohnaka
 
Mackerelではじめる お手軽サーバー監視
Mackerelではじめる お手軽サーバー監視Mackerelではじめる お手軽サーバー監視
Mackerelではじめる お手軽サーバー監視Hiroyuki Ohnaka
 
JDK9の真の目玉機能はこれだ!
JDK9の真の目玉機能はこれだ!JDK9の真の目玉機能はこれだ!
JDK9の真の目玉機能はこれだ!Hiroyuki Ohnaka
 
「すいーとみゅーじっく」のできるまで
「すいーとみゅーじっく」のできるまで「すいーとみゅーじっく」のできるまで
「すいーとみゅーじっく」のできるまでHiroyuki Ohnaka
 
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」Hiroyuki Ohnaka
 
Reading java-property-file-from-ruby
Reading java-property-file-from-rubyReading java-property-file-from-ruby
Reading java-property-file-from-rubyHiroyuki Ohnaka
 
SQLアンチパターン「ディプロマティック・イミュニティ」
SQLアンチパターン「ディプロマティック・イミュニティ」SQLアンチパターン「ディプロマティック・イミュニティ」
SQLアンチパターン「ディプロマティック・イミュニティ」Hiroyuki Ohnaka
 
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化Hiroyuki Ohnaka
 

More from Hiroyuki Ohnaka (19)

remote Docker over SSHが熱い
remote Docker over SSHが熱いremote Docker over SSHが熱い
remote Docker over SSHが熱い
 
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験
VSCode Remote Container & GitHub Codespacesで拓く次世代のJava開発体験
 
Remote Development with Visual Studio Code & A clean dev env, working every ...
Remote Development with Visual Studio Code &  A clean dev env, working every ...Remote Development with Visual Studio Code &  A clean dev env, working every ...
Remote Development with Visual Studio Code & A clean dev env, working every ...
 
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話ChefとItamaeをニコイチしてAnsibleにマイグレーションした話
ChefとItamaeをニコイチしてAnsibleにマイグレーションした話
 
「WindowsデスクトップでWeb開発 改訂版」サンプル
「WindowsデスクトップでWeb開発 改訂版」サンプル「WindowsデスクトップでWeb開発 改訂版」サンプル
「WindowsデスクトップでWeb開発 改訂版」サンプル
 
Mackerelの薄い本
Mackerelの薄い本Mackerelの薄い本
Mackerelの薄い本
 
Microsoft DocsにContributeした話
Microsoft DocsにContributeした話Microsoft DocsにContributeした話
Microsoft DocsにContributeした話
 
Azure functions+typescript
Azure functions+typescriptAzure functions+typescript
Azure functions+typescript
 
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
 
仮想通貨始めました~GethではじめるEthereum~
仮想通貨始めました~GethではじめるEthereum~仮想通貨始めました~GethではじめるEthereum~
仮想通貨始めました~GethではじめるEthereum~
 
錬金術MeetUpへのお誘い
錬金術MeetUpへのお誘い錬金術MeetUpへのお誘い
錬金術MeetUpへのお誘い
 
Mackerelではじめる お手軽サーバー監視
Mackerelではじめる お手軽サーバー監視Mackerelではじめる お手軽サーバー監視
Mackerelではじめる お手軽サーバー監視
 
JDK9の真の目玉機能はこれだ!
JDK9の真の目玉機能はこれだ!JDK9の真の目玉機能はこれだ!
JDK9の真の目玉機能はこれだ!
 
「すいーとみゅーじっく」のできるまで
「すいーとみゅーじっく」のできるまで「すいーとみゅーじっく」のできるまで
「すいーとみゅーじっく」のできるまで
 
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」
JavaOne 2015 報告会 @ 東京 「About MVC 1.0 & JSON-P」
 
Reading java-property-file-from-ruby
Reading java-property-file-from-rubyReading java-property-file-from-ruby
Reading java-property-file-from-ruby
 
SQLアンチパターン「ディプロマティック・イミュニティ」
SQLアンチパターン「ディプロマティック・イミュニティ」SQLアンチパターン「ディプロマティック・イミュニティ」
SQLアンチパターン「ディプロマティック・イミュニティ」
 
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
 

「TDDはじめて物語」 #tddbc

  • 1. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDはじめて物語 2016/2/27 TDDBC in Tokyo 2016-02 大中浩行
  • 2. #ccc_r11 Copyright 2016 Hiroyuki Onaka テスト駆動開発(Test Driven Development) TDDとは? Generated by 社畜ちゃん台詞メーカー http://blog.oukasoft.com/OS/
  • 3. #ccc_r11 Copyright 2016 Hiroyuki Onaka By National Photo Company [Public domain], via Wikimedia Commons https://en.wikipedia.org/wiki/Bulletproof_vest テストファーストしたら?
  • 4. #ccc_r11 Copyright 2016 Hiroyuki Onaka ? By NASA [Public domain], via Wikimedia Commons https://en.wikipedia.org/wiki/Self-replicating_machine テストが自動化されたら?
  • 5. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDとは 「TDDとは、プログラミングとテストすること を工程として統合した開発スタイルです。」 - @setoazusa
  • 6. #ccc_r11 Copyright 2016 Hiroyuki Onaka アジェンダ • TDDとは • テストファーストとは • なぜTDDするのか • TDDには何が必要か • なぜTDDするのか(again)
  • 8. #ccc_r11 Copyright 2016 Hiroyuki Onaka ※絶版 TDDとは
  • 9. #ccc_r11 Copyright 2016 Hiroyuki Onaka By Improve It (Flickr: Kent Beck no Workshop Mapping XP.) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons https://en.wikipedia.org/wiki/Kent_Beck Kent Beck
  • 10. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDとは 1.素早くテストを追加する。 2.すべてのテストを実行し、新しいテストの失敗を確 認する。 3.小さな修正を行う。 4.すべてのテストを実行し、すべての成功を確認する。 5.重複を取り除くためにリファクタリングを行う。 ケント・ベック(著)長瀬嘉秀(訳)「テスト駆動開発入門」
  • 11. #ccc_r11 Copyright 2016 Hiroyuki Onaka 座標平面上にある点で、x座標 (x-coordinate) 、y座標 (y-coordinate) がともに整数である点を格子点と呼び ます。 • x座標とy座標を与えて格子点を生成してください • 生成した格子点からx座標とy座標を取得してください • 生成した格子点から文字列表記 (notation) を取得してく ださい
  • 12. #ccc_r11 Copyright 2016 Hiroyuki Onaka テストを追加する。 @RunWith(JUnit5.class) public class GridPoinTest { @Test public void x座標とy座標を与えて格子点を生成できること(){ } @Test public void 生成した格子点からx座標とy座標を取得できること(){ } @Test@Disabled public void 生成した格子点から文字列表記を取得できること() {} }
  • 13. #ccc_r11 Copyright 2016 Hiroyuki Onaka テストを追加する。 @RunWith(JUnit5.class) public class GridPoinTest { @Test public void x座標とy座標を与えて格子点を生成できること(){ // コンストラクターのテストは通常書かないですが、 // 課題の「格子点を生成できること」と対応を取るためにあえて // テスト化しています GridPoint point = new GridPoint(4, 7); assertNotNull(point); } @Test public void 生成した格子点からx座標とy座標を取得できること(){ GridPoint point = new GridPoint(4, 7); assertEquals(4, point.getX()); } @Test@Disabled public void 生成した格子点から文字列表記を取得できること() {} }
  • 14. #ccc_r11 Copyright 2016 Hiroyuki Onaka すべてのテストを実行し、新しいテストの失敗を 確認する。
  • 15. #ccc_r11 Copyright 2016 Hiroyuki Onaka 小さな修正を行う。 public class GridPoint { private int x; public GridPoint(int x, int y) { this.x = x; } public int getX() { return x; } }
  • 16. #ccc_r11 Copyright 2016 Hiroyuki Onaka すべてのテストを実行し、すべての成功を確認す る。
  • 17. #ccc_r11 Copyright 2016 Hiroyuki Onaka 再びテストを追加する。 @Test public void x座標とy座標を与えて格子点を生成できること() { GridPoint point = new GridPoint(4, 7); assertNotNull(point); @Test public void 生成した格子点からx座標とy座標を取得できること() { GridPoint point = new GridPoint(4, 7); assertAll( () -> { assertEquals(4, point.getX()); }, () -> { assertEquals(7, point.getY()); } ); }
  • 18. #ccc_r11 Copyright 2016 Hiroyuki Onaka 再びテストを実行する。
  • 19. #ccc_r11 Copyright 2016 Hiroyuki Onaka 修正を行う。 public class GridPoint { private int x; private int y; public GridPoint(int x, int y) { this.x = x; this.y = y; } public int getX() { return x; } public int getY() { return y; } }
  • 20. #ccc_r11 Copyright 2016 Hiroyuki Onaka すべてのテストを実行し、すべての成功を確認す る。
  • 21. #ccc_r11 Copyright 2016 Hiroyuki Onaka 重複を取り除くためにリファクタリングを行う。 private GridPoint point; @BeforeEach public void before(){ point = new GridPoint(4, 7); } @Test public void x座標とy座標を与えて格子点を生成できること() { assertNotNull(point); } @Test public void 生成した格子点からx座標とy座標を取得できること() { assertAll( () -> { assertEquals(4, point.getX()); }, () -> { assertEquals(7, point.getY()); } ); }
  • 22. #ccc_r11 Copyright 2016 Hiroyuki Onaka フィードバックループ 「運転というのはね、車を正しい方向に走らせ ることじゃないの。常に注意を払って、こっち に行ったら少し戻して、あっちに行ったら少し 戻して、そうやって軌道修正していくものよ」 これがXP のパラダイムだ。注意して、適応して、 変更する。 Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
  • 23. #ccc_r11 Copyright 2016 Hiroyuki Onaka テストファー スト
  • 24. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDの観点から TDDでは、なぜテストファーストするのか
  • 25. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「テストファーストしてないテストは怖い」 -@setoazusa
  • 26. #ccc_r11 Copyright 2016 Hiroyuki Onaka テストを先に書くことはどんな意味があるのか • テストに求められる機能は、成功するとGreenに なり、そうでない時にRedになること • テストファーストしてないテストは、「まず失 敗させる」ことができないため、テストとして の信頼性がさがる • 「失敗していないテストのカバレッジは50%し かない」
  • 27. #ccc_r11 Copyright 2016 Hiroyuki Onaka 思い出してみてください。 自動化されてないテストで、テスト項目書に 「正しく表示されていること」と記載されてい て、検証に苦労したことはありませんか?
  • 28. #ccc_r11 Copyright 2016 Hiroyuki Onaka ユニットテストが「テスト」である以上、テス トの答えとなるものは先に用意されているはず
  • 29. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDではなぜテストファーストするのか あくまでテストのあるべき姿を追求したことで、 結果としてテストを最初に書くことになるイ メージ。
  • 30. #ccc_r11 Copyright 2016 Hiroyuki Onaka よくある質問 「TDDって、テストを必ず先に書かなければい けないんですか?」
  • 31. #ccc_r11 Copyright 2016 Hiroyuki Onaka http://www.slideshare.net/YasutoEnjoji/20150621-asbc-pub/29
  • 32. #ccc_r11 Copyright 2016 Hiroyuki Onaka テストファーストよりも大事なこと • 「1ヶ月かけてコーディング、1ヶ月かけてテ スト」のようなアンチパターンから、どれだ けプログラミングとテストを連携して開発が できるようにするか • テストによって開発が駆動されているか
  • 33. #ccc_r11 Copyright 2016 Hiroyuki Onaka • 大事なのは、システムをデリバリーするために、 どうステップを踏んでいくか • テストファーストを導入できるなら、すればよ い。 • そうでないとしても、ユニットテストより上位 レベルのテストの項目は先に作成するなど、テ スト同士で補完していけば良い。
  • 34. #ccc_r11 Copyright 2016 Hiroyuki Onaka ただ、IT技術者として手札は多いほうがよいの で、スキルとしてテストファーストできるにこ したことはないです。
  • 35. #ccc_r11 Copyright 2016 Hiroyuki Onaka なぜTDDする のか
  • 36. #ccc_r11 Copyright 2016 Hiroyuki Onaka 最初に答えをいいます 「継続的インテグレーションをもたらすための 核心である素早いフィードバックは、ユニット テストのカバレッジが十分にないと可能になら ないのだ」 Jez Humble,David Farley(著) 和智右桂(訳) 「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」
  • 37. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「エラーが自動的に増殖するのがDevOps」 https://twitter.com/devops_borat/status/41587168870797312
  • 38. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「テストがないコードはレガシーコードだ!」
  • 39. #ccc_r11 Copyright 2016 Hiroyuki Onaka Test Early and Often Microsoft 「Test Early and Often」 https://msdn.microsoft.com/library/ee330950.aspx
  • 40. #ccc_r11 Copyright 2016 Hiroyuki Onaka Shift left Testing By DonFiresmith (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons https://en.wikipedia.org/wiki/Shift_left_testing
  • 41. #ccc_r11 Copyright 2016 Hiroyuki Onaka とはいうものの… • TDD=テスト自動化ではない
  • 42. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDが目指すもの 「動作するきれいなコード」、ロン・ジェフ リーズのこの簡潔な言葉は、TDD(テスト駆動 開発)の目標である。動作するきれいなコード は、あらゆる理由で価値がある。 Kent Beck(著) 長瀬 嘉秀(監訳) 「テスト駆動開発入門」
  • 43. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「動作するきれいなコード」 「きれいなコード」とは?
  • 44. #ccc_r11 Copyright 2016 Hiroyuki Onaka By Wikinaut (Own work (own photo)) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons https://ja.wikipedia.org/wiki/スパゲッティプログラム きれいでないコード(スパゲッティーコード)
  • 45. #ccc_r11 Copyright 2016 Hiroyuki Onaka では「きれいなコード」とは …なんだ?
  • 46. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「動作するきれいなコード」を英語で言うと、 「Clean code that works」
  • 48. #ccc_r11 Copyright 2016 Hiroyuki Onaka とはいっても、「クリーン」にも色々ありまして • 複雑度 • メソッド/関数の行数 • コードスタイル • 命名規則 • etc…
  • 49. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「クリーンなコード」についてはこちらを
  • 50. #ccc_r11 Copyright 2016 Hiroyuki Onaka どうテストす るか
  • 51. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「不安をテストで表現する」 http://gihyo.jp/dev/serial/01/tdd/0010
  • 52. #ccc_r11 Copyright 2016 Hiroyuki Onaka @t_wada曰く
  • 53. #ccc_r11 Copyright 2016 Hiroyuki Onaka 私たちプログラマの手を止めるものは何でしょうか。私は 「不安」だと思っています。「もしかしたら」という感情で すね。「もしかしたら,自分の書いているコードは間違って いるかもしれない」「もしかしたら,ライブラリの使い方が 正しくないかもしれない…」。(略) だから,これから書くコードに対して,if文があるだろうな とか,ループがあるとか,正規表現使わなきゃいけないなと か,そういった自分自身に対する不安,これから書くことに 対する不安に対して,テストを書いていきます。 「[動画で解説]和田卓人の“テスト駆動開発”講座 第10回 テストの最小単位は不安」 http://gihyo.jp/dev/serial/01/tdd/0010
  • 54. #ccc_r11 Copyright 2016 Hiroyuki Onaka • プログラマーとしての「不安」 • データベース技術者としての「不安」 • インフラ担当としての「不安」
  • 55. #ccc_r11 Copyright 2016 Hiroyuki Onaka • お互いが不安に感じていることを認める。 • その人の弱さを認める。それを品質保証の出 発点にする。
  • 56. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「信頼で結ばれた共同体」 James O. Coplien , Neil B. Harriosn (著), 和智右桂 (翻訳) 「組織パターン」
  • 57. #ccc_r11 Copyright 2016 Hiroyuki Onaka もう一つ、よく聞く話 「TDDでテストすれば、他のテストはいらない んですか?」
  • 58. #ccc_r11 Copyright 2016 Hiroyuki Onaka 開発者と品質保証の関係 • 開発者テストのレベルで「開発者の思ったと おりに動く」ことが保証されているから、品 質保証のテストは品質の検証に注力できる • 品質保証のテストが後詰めとして控えている から、開発者テストはプログラムの中の勘所 を押さえることに注力できる
  • 59. #ccc_r11 Copyright 2016 Hiroyuki Onaka 製品品質モデル(JIS X 25010) • 機能適合性 • 性能効率性 • 互換性 • 使用性 • 信頼性 • セキュリティ • 保守性 • 移植性 JIS X 25010(ISO/IEC 25010) 「システム及びソフトウェア製品の品質要求及び評価(SQuaRE)- システム及びソフトウェア品質モデル」
  • 60. #ccc_r11 Copyright 2016 Hiroyuki Onaka アジャイルテストの四象限 Lisa Crispin,Janet Gregory(著) 榊原彰(監訳)「実践アジャイルテスト」
  • 61. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「二重のフィードバックループ」 Steve Freeman, Nat Pryce「Growing Object-Oriented Software, Guided by Tests」 (邦訳「実践テスト駆動開発」)
  • 62. #ccc_r11 Copyright 2016 Hiroyuki Onaka BDD(Behavior-Driven Development) John Ferguson Smart 「BDD in Action Behavior-Driven Development for the whole software lifecycle」
  • 63. #ccc_r11 Copyright 2016 Hiroyuki Onaka なぜテストす るか
  • 64. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDはプログラマーの義務?
  • 65. #ccc_r11 Copyright 2016 Hiroyuki Onaka だがちょっと待って欲しい 「テストを書く/書かない」ということは、道 義的な責任の問題ではない
  • 66. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「テスト」と責任の関係 • テストという工程は、その性格上、品質保証 や、成果物への責任と強い関係をもっている • 「テストを書くべきだ」という論に明快に異 を唱えられる人は少ない
  • 67. #ccc_r11 Copyright 2016 Hiroyuki Onaka • 開発プロセスの望ましい姿を論じていたはず が、道義的な責任の問題になってしまう • テストを書く人と書かない人の間の感情的な 対立は、何も生み出さない
  • 68. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「TDDやれば偉いわけじゃない」 http://b.hatena.ne.jp/entry/232721484/comment/t-wada
  • 69. #ccc_r11 Copyright 2016 Hiroyuki Onaka 幻想を捨てる • カバレッジ100% • ユニットテストを書けばバグがなくなる
  • 70. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「テストを書く」ということは、継続的インテ グレーション(CI)や静的解析、コードレビュー やペアプログラミングなど、チーム開発のため のプラクティスと連携して、初めてその力を発 揮する。
  • 71. #ccc_r11 Copyright 2016 Hiroyuki Onaka TDDが銀の弾丸でないなら、なぜTDDするのか その前に、ちょっと世の中の様子を見てみよう
  • 72. #ccc_r11 Copyright 2016 Hiroyuki Onaka https://twitter.com/yotchang4s/status/699030352686256129
  • 73. #ccc_r11 Copyright 2016 Hiroyuki Onaka https://www.google.co.jp/search?q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&tbm=n ws
  • 74. #ccc_r11 Copyright 2016 Hiroyuki Onaka https://twitter.com/setoazusa/status/650250873017204736
  • 75. #ccc_r11 Copyright 2016 Hiroyuki Onaka #笑ってはいけないSIer
  • 76. #ccc_r11 Copyright 2016 Hiroyuki Onaka 我々はなぜここにいるのか • 生活のため? • お金のため? • プロだから? • 技術者だから?
  • 77. #ccc_r11 Copyright 2016 Hiroyuki Onaka なぜTDDするのか 私の場合…
  • 78. #ccc_r11 Copyright 2016 Hiroyuki Onaka 信頼できる成果物のために 「技術力は信頼関係につながる。作業を正確に 見積もり、最初から品質の高いものを届け、高 速なフィードバックループを構築すれば、あな たは信頼されるパートナーになれる。」 Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
  • 79. #ccc_r11 Copyright 2016 Hiroyuki Onaka 強いチームとは メンバーを集めた「プロジェクト」を、メン バーのバックグラウンドを尊重できる「コミュ ニティ」に出来るか
  • 80. #ccc_r11 Copyright 2016 Hiroyuki Onaka 「君が質の高いソフトウェアを届けることは誰 にも止められない。君が現場に立って、お客さ んに向けてプロジェクトの状況と、プロジェク トに必要なことを誠実に伝えることも誰にも止 められないんだ。」 Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳) 「アジャイルサムライ 達人開発者への道」
  • 81. #ccc_r11 Copyright 2016 Hiroyuki Onaka ありがとうございました! • 大中浩行(Onaka,Hiroyuki) • @setoazusa • グロースエクスパートナーズ株式会社 アーキテクチャソリューション部 テクニカルリード • http://blog.fieldnotes.jp/