1. よしおかひろたか
TDDBC@大阪
楽天株式会社 DU,開発アーキテクチャ部 よしおかひろたか ｜June 2nd, 2012
1

2. よしおか
本日のメッセージ
開発者の皆さん、
テストを書こう
テストを書く＝テストコード＋入力データ＋期待する出力データ
Excelでテストケースを作ることではない。
2

3. アジェンダ
• 大規模ソフトウェア開発におけるディリー
ビルド＆リグレッションテスト
– 民族誌的なソフトウェア開発経験のお話
3

4. 自己紹介
• 楽天、開発部、開発アーキテクチャ部、技術理事
よしおかひろたか
• 2009年8月入社
• カーネル読書会の主宰者、DEBUG HACKS共著
ISBN978-4-87311-404-0
• twitter @hyoshiok http://d.hatena.ne.jp/hyoshiok
http://someday-join-us.blogspot.jp/
4

5. わたしの経験から
• 大規模ソフトウェア開発の現場の経験をお話す
る。
– ソフトウェア製品開発は受託開発とは相当異なる。
• 事例：
– Oracle8の開発現場
– DEC Rdbの日本語化、国際化
– 日本語COBOL
– Samba3.0国際化対応（オープンソースの場合）
5

6. Oracleの場合
• 開発環境
• 開発プロセス
• プログラマの日常
• リズム
• チェックアウト、チェックイン
• ディリービルド
• リグレッションテスト
• 学んだこと
6

7. Oracle 8の場合
• わたしが参加した時期、1995年～2000年
• Oracle8/8iあたりのころ
• 開発環境：Sun Workstation、SunOSからSolaris
• Clearcaseベースの開発環境。
– ファイルの仮想化。一人で複数のブランチを同時に
持てる。
• 例えば、Oracle 7.3用、Oracle 8用、Oracle 8.1用。バグ修正、
機能ごと、ちょっとした確認用などなど
• check-outしたものはcheck-inするまで他の人には見えない。
7

8. 開発プロセス（Oracleの場合）
• 要求仕様作り（開発者）
– 外部API、UIなどを決定する。
• 例：SQLのシンタックス、セマンティックスを定義する。
– リファレンスマニュアルのベースになる。
• 設計（開発者）
– APIなどを決定したら、設計＆実装になる。
• 実装（開発者）
– コードを書く、テストを書く、テストをする
• ディリービルド＆リグレッションテスト（自動）
– チェックインされた最新のコードをスクラッチからビルドして、リ
グレッションテストを実行。
• チェックインしたコードの概要と、テスト結果の概要が日々
担当者にメールで送られる
• 常に動くコードが毎日ある。
• 安定化プロセス
– フィーチャーフリーズ（機能追加を凍結する）
– コードフリーズ（重大なバグフィックス以外のチェックインを認め
ない） 8

9. ソフトウェア製品開発のプログラマ
• 設計者が実装者でテストも書く
• 一つの機能については、すべて知ってい
る。
• コーダーという人がいるわけではない。
9

10. プログラマの一日
• 朝会社に来る。
• コーヒーでも飲みながら、メールをチェックする。
– 担当のテストを確認する。
• 自分が昨日チェックインしたコードがリグレッションテストを
壊していないか。
• 他の人のチェックインが、担当テストを壊していないか。
• 壊れている場合は、調査する。あるいは調査を依頼する。
• 仕掛の作業を行う。
– コードを書いたり、テストを流したり、あれやこれや。
– 全テストを流すと時間がかかるので、サブセットを流す
– コードが安定したら当該ブランチの最新版にマージする
• 自分の環境で動作確認ができたら、
– 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさそ
うの場合、リリースマネージャーにチェックインの許可をもらう。
• 許可が出たら、チェックインする。
– 次の日はどきどきしながらリグレッションテストの結果を見る
• 休暇の前に確認しないでチェックインをするな、という不文律
– http://d.hatena.ne.jp/hyoshiok/20040516#p1 10

11. リズム
• チェックアウトして
• コードをいじって、テストを書いて、
• テストを実行して、OKになるまで繰り返し
て、
• 同僚にレビューしてもらって、
• リリースマネージャに許可をもらって、
• チェックイン
11

12. チェックアウト、チェックイン
• 複数のブランチを同時にいじっている
• バージョンがいくつか
• それぞれについて、バグフィックス、機能
変更、機能追加、機能ごとに別々のブラ
ンチを切っておく。
• 最新のバージョンでバグフィックスしたも
のを昔のバージョンに適用することもある。
（バックポート）
12

13. ディリービルド
• 毎日大量のチェックインがある。数十～
• 最新のソースからビルドする。
– コンパイルエラーが出るチェックインは無条
件にロールバックされる。
– 複数のビルドマシンで分散ビルド
• 安定性に差こそあれ常に動くものがある。
– Oracle8の最初のビルドは前バージョン
(Oracle 7.3)と同一。ここから始まる。
13

14. リグレッションテスト
• ディリービルドされた最新の実行イメージでリグ
レッションテスト（数千）を実行する
– 10数台（？）のサーバーマシンで何時間もかかる。
– テストコード、入力データを与えて、期待する出力と
実際の出力の差分を見る
– diff（差分）が出たらそれを目視確認する。期待する
結果なのか、いなか。
– 新機能追加、バグフィックスの場合は対応するテスト
の追加、修正などを行う。
– リグレッションテストがあるので、既存の機能の予期
しない影響がすぐにわかる。リグレッションの発見。
14

15. 安定化プロセス
• あるクライテリアで、安定化プロセスに入る。
– 新機能の追加を凍結する（feature freeze)期間に入
る
– バグ修正だけを行う
– リグレッションテストのdiffの数を減少させる
– テストの追加、実行だけをやって、製品の安定化を
図る。
– あるクライテリアで、重大なバグ修正以外は一切変
更を認めない(code freeze)期間に入る。
– バグ（不具合）はリリースノート等に記載し出荷する
15

16. 学んだこと
• ディリービルドによって、常に動作が確認されているも
のがある。
– どの機能が実装されていて、どの機能が実装されていないか
が一目でわかる
– 実装すべき機能のプライオリティが変更になったとしても、すぐ
に対処可能
– スケジュールが遅延した場合、どの機能を落とすかの判断が
容易に可能。（どれが動いているかいないかを把握できている
ので）
– Oracle 8開発開始時には、オブジェクトリレーショナル機能が目
玉とされていたが、競合が競争力がなくなって行ったので、そ
の機能の多くは次バージョンへ。
• 大規模ソフトウェア開発において俊敏性を高めるベスト
プラクティスで、ソフトウェア製品開発では広く利用され
ている。（例：マイクロソフトのOS開発など）
• 闘うプログラマー http://books.rakuten.co.jp/rb/6130084/
16

17. DEC Rdbの日本語化、国際化
• ソフトウェアの日本語化プロセス
• ビルド環境って
• インターネット以前のソフトウェア開発
• 学んだこと
17

18. DEC Rdbの場合
• ソフトウェアの日本語化プロセス
– 米国本社で開発されたソフトウェアを日本で日本語
化した。（別のバイナリーになる）
• 1980年代後半のころ
• 参加人員：日本側開発者3名～。US側は100名前後
• 開発環境の入手
– ソースコードの入手
– ビルドスクリプト
– テスト環境
• 開発環境構築
– VAX/VMS、OSの違い、コンパイラの違い、その他ツールの違いな
どなどで一筋縄では行かない場合も
• 実際の開発
– ビルド＆リグレッションテスト
18

19. ビルド環境
• 開発環境を日米で完璧に一致させることは難し
い
– もちろん仮想化環境などはない。ツール、コンパイラ、
OSのバージョン
• 社内ネットワークはあったが回線が細い
– 100MBをコピーするのに足掛け3日とか
• リグレッションテストの結果を確認するのが難し
い。（開発環境が微妙に異なるので）
– 安定化させるのに2~3ヶ月かかることも。
19

20. インターネット以前のソフトウェア開発
• 大規模分散開発だったのだけど、
– 社内ネットワークの帯域は細かった
– コミュニケーションは、メール、電子掲示板（VAX Notes）
• 最終的には、本社に乗り込んで、ソースコードをマージ
した（1990年ごろ）
• DECはOS（VMS）、ハードウェア(VAX)、ミドルウェア
(Rdb)、コンパイラ、ツール、その他すべて内製品。垂直
統合型企業
• SQA (Software Quality Assurance)という部隊があった。
– OS/HW/ミドル：各レイヤーの互換性をリグレッションテストで確
認
20

21. 学んだこと
• 米国本社のエンジニアと一緒に働いた
• すごいエンジニアがいっぱいいた
• ソフトウェア国際化のあるべき姿について
とことん議論できた
• 大規模広域分散ソフトウェア開発のイ
メージが持てた
21

22. 日本語COBOLの場合
• 非力なマシンでのソフトウェア開発
• コード管理システム、モジュール管理シス
テム、テスト管理システムなどのお話
• バグ管理
• エンジニアのイロハを教えてもらった
• 学んだこと
22

23. プロジェクト概要
• 日本語COBOLの開発
– 1984年～
– 3人（自分は新卒プログラマ）
– 開発環境、VAX/VMS
– 言語：BLISS、SCAN（独自の言語）
• コード管理システム、モジュール管理シス
テム、コンパイラ、テスト管理システム、バ
グ管理システム、すべて自社製
23

24. • 夜中の0時に、ビルドのバッチが動き出し、その
後テストを実行する。
– チェックインしたファイルのdiffをメールするようにし
た。
– 見よう見まねで、makeファイルを書いた。
– テストスクリプトもテスト管理システムを利用して書
いた。テスト結果もメールした。
• チェックインの数、発見したバグの数、修正した
バグの数などをグラフにすると、週単位での進
捗が見えた。（手書きw）
24

25. バグ管理
• テストプログラムは、自分以外が実装した
分について書いた。(他人のコードをテス
トする）
• 発見したすべてのバグはバグデータベー
ス（自作）に登録した。
– 110件くらいバグを発見したと思う。
– バグの分析などもした。3割くらいが未実装。
25

26. 新人のしつけ（自分のこと）
• コードを書くとは？
– 「プログラム書きましたよ」
– 「あれー、どこにある？チェックインした？」
– 「チェックインしました」
– 「あれコンパイルできないぞ」
– 「コンパイルエラーとりました」
– 「ところでテストした？」
– 「していません（てへ）。」
– 「…（怒）」
26

27. エンジニアのイロハを教えてもらった
• マニュアルを読むこと
• テストを書くこと
• デバッグの仕方
• 質問の仕方
27

28. 学んだこと
• 社内にはすごい人がいっぱいいる
• 自分もそうなりたい
• ソフトウェア開発プロセスのイロハ
• 大規模分散開発のイメージ（未来像）
• ソフトウェア国際化のイメージ（未来像）
28

29. Samba3.0国際化対応の場合
• オープンソースとコミュニティの対応
• 新参者がコミュニティに入るには
• プロジェクトの流れ
• オープンソースの都市伝説
• プログラマの日常
• リズム
• 学んだこと
29

30. Samba3.0国際化
• プロジェクト概要
– Samba2.xは日本人コミュニティが開発した日本語
パッチがあったが、Samba3.0になって、内部コードが
Unicodeになったため当該パッチが利用できなくなり
ShiftJIS関連の問題が発生した。
– Unicode対応、テストの追加など
– 2003年ごろ
– http://www.miraclelinux.com/technet/samba30/
index.html
– http://d.hatena.ne.jp/hyoshiok/20041022
30

31. オープンソースとコミュニティ
• 高い技術力とdisciplineを持ったハッカーによっ
て構成されている
– 企業の開発者は企業の利益拡大
– 企業の開発者とコミュニティのハッカーの利害が一
致するとは限らない。しばしば相反する。
• パッチを送ったからといって受け入れられると
は限らない。
– 技術的な問題というより、しばしばコミュニケーション
の問題だったりする
31

32. 新参者がコミュニティに受け入れられるには
• 何の実績もない人が受け入れられるには
– 技術の問題ではなくコミュニケーションの問題と認識した
• Samba-jp（日本のコミュニティ）とSambaのコミュニティ
の関係。両方に受け入れられる必要がある。
– テストをどんどん作って、発見した問題をバグデータ
ベースにどんどん登録した。チームのメンバーは個人名
で登録。
– ついでにパッチなども投稿した。個人名で投稿。
– 直接会って話したり、メール、チャット、電話会議などで、
プロジェクトの紹介などを行った。
– コミュニティにデビューするには、自分たちの技術力を
理解してもらう必要がある。バグフィックスは最初の一歩。
– 大きなパッチをいきなり送るのではなく、小さいバグ
フィックスの積み重ねで、徐々に信頼を得ていく。
32

33. プロジェクトの流れ
• ディリービルド、リグレッションテストの開発環境
を準備した。
• Sambaのテストフレームワークを利用し
– テストケースの作成
– テストコードの作成
– テストの実施
– 不具合をbugzillaに登録
– 修正パッチを投稿
• 機能追加、修正などのパッチを適宜投稿。本家
にマージしてもらう。
• 英語のホームページ、ドキュメントなども用意し
た
• フェースツーフェースの会議、メール、チャット、 33
電話など様々な方法をとった

34. オープンソースの都市伝説
• ハッカーは無法者？
– 極めて高い技術力とdiscipline（規律）を持つ
– コミュニティの価値を大切にする
– プロフェッショナルである
34

35. プログラマの日常
• やることリストの確認
• Bugzillaのチェック
• テストの追加
• パッチの作成
– リグレッションが起こっていないことを確認
– 新機能が実装されていることを確認
• コミュニティへ投稿
– メーリングリスト、電話、チャット、などなど
35

36. リズム
• 作成したテスト数が見える
• バグの数が既知
– 最初にテストがあるので、そのテストで発見
した数が初期値になる
– Samba3.0は今ここにあるが国際化の機能が
ない。（バグの数＝実装すべき機能）
• バグの数を減らしていくのがリズム
36

37. 学んだこと
• OSSもテストファーストできた
• 何をやりたいかをテストで表現した
WHAT
• テストを作ることによってオリジナル製品
の挙動を深く理解した
• プロジェクトマネージャーとして、プロジェ
クトの進捗が、テストの進捗、残バグ数に
よって見える化されているので、安心。
37

38. ちょっとした思い
• プロフェッショナルって
• 変化を許容すること
• プログラマに必要な３つのチカラ
38

39. プロフェッショナルについて
• ソフトウェアは人が作る
– 自分がプロフェッショナルになるしかない…
– アスリートが毎日トレーニングしているように
われわれはトレーニングをしているだろうか
39

40. 変化を許容することについて
• 環境は変化する
• 自分は変化しているだろうか
• 成長しているだろうか
40

41. プログラマに必要な３つのチカラ
• ソースコードリーディング
• テスト
• デバッグ
• ワークショップや勉強会を開催していきた
い～～～
41

42. 経験則
• テストを書かない
プロフェッショナルはいない
（プログラマ的な意味で）
• テストのないコードは
レガシーコードだ。
• 読書会しましょう～
レガシーコード改善ガイド
保守開発のためのリファクタリング、翔泳社
http://books.rakuten.co.jp/rb/6121689/
42

43. • 公理１：すべてのプログラムは
テストをしなければいけない。
• では、どうテストをするか
– A：人がやる
– B:テストコードを書いて、それを実行する
– 正解：B
– 証明：自明。
43

44. テストを作ると
• システムの振る舞い(WHAT)を
記したことになる
– テストを作ることによって、システムの深い理
解を得られる
– 安心感を得られる（心の平静を保てる）
44

45. テストがあると
• 変更の影響が即座にわかる
– 影響範囲がわからなくて、
塩漬けではなく、
どんどん積極的に変更できる
＞変更容易性、アジリティ向上
– 安心である。（心の平静が保てる）
45

46. テストがあると
• 機能を確実に実装したことを
確認できる。
– 手作業による確認は、もれやミスが発生する。
コストが高いし、なにより楽しくない。
– 機械が実行してくれるので、楽である。
– 安心である。 （心の平静が保てる）
46

47. テストがあると
• 変更容易性があがり、
運用コストが下がる
– OSやHWなどシステムを変更したときも、そ
の影響がすぐにわかる
– 安心である。 （心の平静が保てる）
47

48. 開発者の皆さん、
テストを書こう
テストを書いてプロフェッショナルになろう
世界へ行こう
ご参加
おまちしてます
48

49. 49