1. エクストリーム・エンジニアへの道
（Ruby編）第１回 概要
テクノロジックアート
⻑⾧長瀬 嘉秀

2. ■エンジニアに要求される能力
■設計技術
■プログラミング技術
■ツール
■デリバリー
■テスト技術
内容

3. ■アジャイル開発は必須
■要件を短時間でつかむ
■要件をブレークダウン
■テスト駆動開発
■短い開発サイクル
■ユーザーとのコミュニケーション
■チーム開発
■瞬時に設計（基本設計、詳細設計はない）
エンジニアに要求される能⼒力力

4. 業務要件
■ビジネスプロセス（業務フロー）
■機能（ユースケース）

5. 業務⽤用件

6. ビジネスプロセス

7. 機能要件（ユースケース）

8. ■ストーリー（ユーザーストーリー）
■ユースケース、フィーチャーなど
■瞬時に整理する
■数時間で、多くのストーリーを作成する
■要件定義に、何ヶ月もかけてはいけない
■開発しながらブレークダウン
■チームメンバ全員が理解する
アジャイル開発での扱い

9. アジャイル開発

10. ストーリー

11. ■ストーリーを管理
■進捗を管理
■プライオリティ付（特急、普通など）
■バッファによるプロセスの最適化
■要員の最適化
カンバン

12. カンバンボード

13. カンバン

14. 実際のカンバン

15. シナリオ名：交通費を入力する（正常系１）
シナリオ概要：社員（田中太郎）は京都出張の清算のため、出発駅（練馬）
と到着駅（五条）と乗換駅（品川）を入力し、料金を確認する
事前条件：社員（田中太郎）がログインしている
ステップ：
１．出発駅として、練馬を入力する
２．到着駅として、五条を入力する
３．乗換駅として、品川を入力する
４．経路の候補が表示されるtので、該当する経路を選ぶ（練馬→池袋→品
川→京都→五条）
５．出張の日付（2014年6月16日）を入力す
6．出張の交通費を表示して、確認ボタンを押す
シナリオ

16. #
レスポンスはh+p://shoueisha.co.jpに向けられる
def
test_response_should_go_to_shoeisha
assert_equal
respond.to
‘h+p://shoueisha.co.jp’
end
#
respondの結果は320を返すこと
def
test_respond_result_equal_320
assert_equal
respond.result
‘320
end
#
認証(auth)はOKであること。
def
test_respond_auth_returns_ok
assert_equal
respond.auth
‘OK’
end
Rubyにおける要件
RSpecによる要件、テスト

17. 設計とコードの関係
モデルによる設計（例えばUMLなど）
コードベースの開発
モデルベースの開発
モデル、アーキテクチャ、フレームワーク
アーキテクチャ別、ドメイン別など分割技術
設計技術

18. コードと設計
クラス設計
オブジェクト指向設計

19. クラス

20. コード

21. • モデルとコードの関係
• マッピング
• DSL
マッピング技術

22. • POJO
(Plain
Old
Java
Object)
• UI、DB
フレームワーク

23. アーキテクチャー適⽤用

25. ■アーキテクチャによるドメイン分割
■業務、機能によるドメイン分割
ドメイン分割

26. • クラス、関数、モジュール
Rubyにおける設計

27. ■きれいなコード
■クラス分割
■リファクタリング
■デザインパターン
■名前付け
■テストコード
■モック
■関数型プログラミング
プログラミング技術

28. ■テストを書く
■テスティングフレームワーク
■ターゲットロジック
■リファクタリング
テスト駆動開発

29. テストコード

30. ■パターンにより、よりよいコードへ
■リファクタリングで利用
デザインパターン

31. コンポジットパターン

32. コンポジットパターン適⽤用

33. コード

34. • RSpecによるTDD
RubyにおけるTDD

35. ■関数、モジュールとの切り分け
■JavaやC++とは、異なるところもある
Rubyにおけるデザインパターン

36. • Mocks
Aren't
Stubs
(MarXn
Fowler)
• h+p://marXnfowler.com/arXcles/
mocksArentStubs.html
モック技術

37. – 高階関数
– クロージャー
– 再帰的
関数型プログラミング

38. – ConXnuous
Delivery
– Chef、Puppet
– テストの組み込み
– クラウド実行環境
– Docker、MicroServices
デリバリー

39. – 要件整理
– カンバンボード
– TDDができるIDE（Eclipseなど）
– ソースコード管理（Gitなど）
– ビルド管理（Jenkins）
– クラウド環境（Herokuなど）
– クラウド実行環境
– リリースツール（Chefなど）
– テストツール
ツール

40. – ユニットテスト
– 非機能テスト
– バリデーションなどのテスト
– テストパターン
– UIテスト
– テストコードの設計
テスト技術

41. – ペアプログラミング
– スタンドアップミーティング
– ストーリー
– レトロスペクティブ
– ビジネスアナリスト、エンジニア、テストエンジニ
ア（QA）、ユーザー（顧客）
チームビルディング

42. – 分業化は終了
– 各自がすべての技術を持っている必要がある
– 多能工
– 開発技術が多岐にわたるため、かなりの勉強
が必要
– 従来の基本設計のように、コードを書けない人
が設計するなどはなくなる
– 使えない技術者にならないために
まとめ

43. エクストリーム・エンジニアへの道
（Ruby編）第１回 概要
テクノロジックアート
⻑⾧長瀬 嘉秀