『Weekdayランサーズ勉強会第1回 - 開発体制/プロセスについて』にて発表した資料。

1. もっと早くに取り組ん
でおけばよかった開発
プロセス
4 5
4 6 3 4
21
.

4. 参考 http://ecnomikata.com/

5. テモナ株式会社
テクニカル リーダー
高橋 和樹
社会人4年目 25歳
ITの世界で働きたくてインターン(PHP)
自分でサービスを作りたい
現職テモナ株式会社ではrailsに没頭
踊れるエンジニア
Facebook :
https://www.facebook.com/kazukiiin

6. もっと早くに取り組んでよかった開
発プロセスというテーマについて
1. 2013年7月当時のCTOが起業
2. その時点で開発経験3年未満のメンバーonlyのチーム
3. 開発メンバー3 ∼5人くらい
4. 同じミスは繰り返す
5. 改善は気持ちの問題
その場限りの対応で
いっぱいいっぱい！！
な状態の連続でした。

7. きっかけは救世主の登場
当社のイケてるCTO
中野 賀通(通称 ガッツさん)
FaceBookID:
nakano.noriyuki.1
CTOは
C(ちょー)T(たのしー)O(お仕事)
の略だよー

8. 既存のプロセスの問題点は沢山
あった。(今思えば・・・。)
1. 承認という名の自由？ 承認フローはあるが機能していない
2. アップグレードの精度は、テスト担当のレベルに依存（ヒューマン
エラーの発生）
3. 半年に一回のセキュリティテストの実施(それで大丈夫か?という問
題)
4. ソースコードの管理の手間
5. 死活監視ONLYの監視

9. 承認という名の自由？(1/5)
• 承認はあるけれど機能していない 結果とし
て事故が起きていた。
• 企画書・仕様書の徹底
• 単体結合テストの結果、セキュリティテストの結果
の添付
• データベース構成図、自動化テストの結果の添付

11. アップグレードの精度は、テス
ト担当のレベルに依存(2/5)
• 人が作ったものを人が検証する。
• その状態では必ずヒューマンエラーが発生してしまう。
• E2E(エンドツーエンド) テストの導入
• TestUnit ×SeleniumWebDriver(Ruby)で構築
• 受注から出荷までの流れを画面とDBから検証

12. [kazuki@takahashi-no-MacBook-Pro] ~/project/repeat/autotest
% tree -L 1 (git)-[autotest2]
.
├── README.md
├── data # test用のデータを格納
├── document # documentを自動生成
├── evidence # テスト結果を格納
├── helpers # テストヘルパーを実装
├── logs # テストの実行logを書き出し
├── pages # pegeごとの画面定義を記述
├── rakefile # 実行用のrakeファイル
├── scinarios # テストシナリオ
└── tools # クローラーによってpageオブジェクトを生成
PageObject
デザインパターン

13. class OrderSpは
スマートフォンにおける
注文フローの
操作をまとめるオブジェクト
画面の要素を
定数で定義するので
変更に強い！！

14. 半年に一回のセキュリティテス
トの実施(3/5)
• セキュリティテストを常に実施する環境を作
りたい
• アプリ面 ： OWASP ZAPを使ったリリース毎のテストの実
施
• サーバー面 ： 脆弱性スキャナOpenVASによる定期的なセ
キュリティチェック 有償のセキュリティチェックと合わせ
て利用することによって安心が大きい！

15. http://www.owasp.org/

16. http://www.openvas.org/

17. SeleniumDriverを用いたブラウザテストに
OwaspZAPをプロキシモードで起動しておき、
FireFoxで起動して、自動化テストを実行しつつ、
セキュリティテストも自動で行う。
①プロキシモード
で起動
②Portを指定して接続
③自動テストを実行

18. ソースコードの管理の手間(4/5)
• リリース時のマージ作業が大変
• gitの導入

19. master
preli
dev
リリー
ス
masterからブランチを作成して開発
localでテストが完了したらpreliにマージ
リリース内容のすべてがテスト完了後
masterにマージ

20. 死活監視ONLYの監視(5/5)
• 死活監視のみ 緊急事態しか検知出来ない
• Zabbixでの監視の導入
• 監視用のControllerの実装で様々なシステムの
状態を検知する(WatchDogController)

21. http://www.zabbix.com/jp/

22. WatchDog(番犬)
異常が起きたよ！！
監視
検知！！
通知！！
・受注の状況
・注文生成処理の監視
・メルマガ配信の確認 etc…

23. 今後の改善
• GitHubに乗り換え(現状一部のソース)
• chef-zeroですべての環境を管理
• Capistranoでデプロイ
• Jenkins × ヘッドレスブラウザ × E2E
で自動テストの自動実行の仕組みの構築

25. 1.承認という名の自由？ 仕様書、テストパターンなどの
document整備の徹底
2.アップグレードの精度は、テスト担当のレベルに依存（ヒューマ
ンエラーの発生） 必須で検証が必要な部分はシステムで検証を
行う
3.半年に一回のセキュリティテストの実施(それで大丈夫か?という
問題) リリース毎にセキュリティの検証を出来る環境を整える
4.ソースコードの管理の手間 今の開発にGitは必須
5.死活監視ONLYの監視 番犬を置く、Zabbixで監視
まとめ

26. テモナで働いてみたい方はこちらへ
http://www.temona.co.jp/recruit/