継続的デリバリー
継続的デリバリー
信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
2012年3月15日 /544P Jenkins実践入門 ～ビルド・テスト・デプロイを自動化する技術
現代では継続的にソフトウェアをリリースすることが必須になっています。
本書は、継続的なソフトウェアのデリバリーを実現するための
ビルド、デプロイ、テスト、リリースの自動化についての本格的な解説書です。
賛辞 - 川口耕介
本書は「俺たちはこういうふうにソフトウェアを開発・リリースしたいんだ」
という心の叫びが感じられます。
・・・対してJenkinsは、じゃあ実際にどうやってやるのよ、ということをメインに考えています。
第1部 基礎
第01章 ソフトウェアデリバリーの問題 39
1.1 導入
1.2 リリースによくあるアンチパターン 40
1.3 もっとうまくできないだろうか？ 47
1.4 どうすれば目標を達成できるだろうか？ 48
1.5 どんな恩恵を受けられるのか？ 54
1.6 リリース候補 60
1.7 ソフトウェアデリバリーの原則 62
1.8 まとめ
第02章 構成管理 69
2.1 導入
2.2 バージョン管理を使う 70
2.3 依存関係の管理 76
2.4 ソフトウェア設定を管理する 78
2.5 環境を管理する 88
2.6 まとめ
第03章 継続的インテグレーション 95
3.1 導入
3.2 継続的インテグレーションを実現する 96
3.3 継続的インテグレーションの前提条件 99
3.4 継続的インテグレーションソフトウェアを使用する 104
3.5 基本的なプラクティス 107
3.6 やったほうがいいプラクティス 113
3.7 分散したチーム 117
3.8 分散バージョン管理システム 121
3.9 まとめ
第04章 テスト戦略を実装する 127
4.1 導入
4.2 テストの種類 129
4.3 実際に起こり得る状況と戦略 137
4.4 プロセス 144
4.5 まとめ
第2部 デプロイメント パイプライン
第05章 デプロイメント パイプラインの解剖学 151
5.1 導入
5.2 デプロイメントパイプラインとは何か？ 153
5.3デプロイメントパイプラインのプラクティス 159
5.4 コミットステージ 166
5.5 自動受け入れテストという関門 169
5.6 後に続くテストステージ 173
5.7 リリースに備える 176
5.8デプロイメントパイプラインを実装する 180
5.9 メトリクス 186
5.10 まとめ
第06章 ビルド・デプロイメントスクリプト 191
6.1 導入
6.2 ビルドツールの概要 192
6.3 ビルドスクリプトとデプロイメントパイプラインの原則とプラクティス 200
6.4 JVMを対象としたアプリケーションのためのプロジェクト構造 206
6.5 デプロイメントスクリプト 210
6.6 コツと裏技 214
6.7 まとめ
第07章 コミットステージ 221
7.1 導入
7.2 コミットステの原則とプラクティス 222
7.3 コミットステージの結果 227
7.4 コミットテストスイートの原則とプラクティス 230
7.5 まとめ
第08章 自動受け入れテスト 241
8.1 導入
8.2 なぜ自動受け入れテストが欠かせないのか？ 242
8.3 受け入れテストを作成する 247
8.4 アプリケーションドライバレイヤ 253
8.5 受け入れテストを実装する 259
8.6 受け入れテストステージ 269
8.7 受け入れテストのパフォーマンス 275
8.8 まとめ
第09章 非機能要件をテストする 281
9.1 導入
9.2 非機能用件を管理する 282
9.3 キャパシティを確保するためのプログラミング 284
9.4 キャパシティを計測する 287
9.5キャパシティテスト環境 291
9.6キャパシティテストを自動化する 294
9.7キャパシティテストをデプロイメントパイプラインに追加する 302
9.8キャパシティテストシステムのもうひとつの利点 304
9.9 まとめ
第10章 アプリケーションをデプロイ・リリースする 307
10.1 導入
10.2 リリース戦略を作成する 308
10.3 アプリケーションをデプロイする 310
10.4 デプロイメントのロールバック、そしてゼロダウンタイム・リリース 317
10.5 緊急修正 324
10.6 継続的デプロイメント 325
10.7 ヒントと裏技 329
10.8 まとめ
第3部 デリバリー エコシステム
第11章 基盤と環境を管理する 337
11.1 導入
11.2 運用チームのニーズを理解する 339
11.3 基盤をモデリングし、管理する 343
11.4 サーバーのプロビジョニングおよび設定を管理する 348
11.5 ミドルウェアの構成を管理する 356
11.6 基盤サービスを管理する 361
11.7 仮想化 364
11.8 クラウドコンピューティング 373
11.9 基盤やアプリケーションを監視する 378
11.10 まとめ
第12章 データと管理する 387
12.1 導入
12.2 データベースのスクリプト処理 388
12.3インクリメンタルな変更 390
12.4データベースのロールバックとゼロダウンタイムリリース 394
12.5 テストデータを管理する 397
12.6 データの管理とデプロイメントパイプライン 401
12.7 まとめ
第13章 コンポーネントや依存関係を管理する 409
13.1 導入
13.2 アプリケーションをリリース可能な状態に保つ 411
13.3 依存関係 416
13.4 コンポーネント 420
13.5 依存グラフを管理する 429
13.6 バイナリを管理する 439
13.7 Mavenを使って依存関係を管理する 441
13.8 まとめ
第14章 高度なバージョン管理 447
14.1 導入
14.2 リビジョン管理システムの簡単な歴史 448
14.3 ブランチとマージ 454
14.4 分散型バージョン管理システム 460
14.5 ストリームベースのバージョン管理システム 466
14.6 メインライン上での開発 472
14.7 リリース用のブランチ 475
14.8 フィーチャによるブランチ 477
14.9 チームによるブランチ 480
14.10 まとめ
第15章 継続的デリバリーを管理する 485
15.1 導入
15.2 構成管理およびリリース管理の成熟度モデル 487
15.3 プロジェクトのライフサイクル 489
15.4 リスク管理プロセス 497
15.5 デリバリーによくある問題 - その症状と原因 501
15.6 コンプライアンスと監査 505
15.7 まとめ
第1部 基礎
第01章 ソフトウェアデリバリーの問題 39
1.1 導入
1.2 リリースによくあるアンチパターン 40
1.2.1 アンチパターン:ソフトウェアを手作業でデプロイする
1.2.2 アンチパターン:開発が終わってから擬似本番環境にデプロイする
1.2.3 アンチパターン:本番環境について手作業で構成管理を行う
1.3 もっとうまくできないだろうか？ 47
1.4 どうすれば目標を達成できるだろうか？ 48
1.4.1 あらゆる変更はフィードバックプロセスを引き起こさなければならない
1.4.2 フィードバックはできる限り早く受け取らなければならない
1.4.3 デリバリーチームはフィードバックを受けとり、それに対応しなければならない
1.4.4 このプロセスはスケールするのか？
1.5 どんな恩恵を受けられるのか？ 54
1.5.1 チームに権限を与える
1.5.2 エラーを削減する
1.5.3 ストレスを低減する
1.5.4 デプロイメントの柔軟性
1.5.5 「できるようになりたければ、練習しろ」
1.6 リリース候補 60
1.6.1 あらゆるチェックインは潜在的にリリースにつながる
1.7 ソフトウェアデリバリーの原則 62
1.7.1 ソフトウェアをリリースするための、反復可能で信頼できるプロセスを作り上げよ
1.7.2 ほとんどすべてを自動化せよ
1.7.3 すべてバージョン管理せよ
1.7.4 痛みを伴うものはこまめに実施し、痛い思いは早めにしておけ
1.7.5 品質を作り込め
1.7.6 完了したとはリリースしたということだ
1.7.7 誰もがデリバリープロセスに対して責任を負う
1.7.8 継続的改善
1.8 まとめ
第02章 構成管理 69
2.1 導入
2.2 バージョン管理を使う 70
2.2.1 ひとつ残らずすべてバージョン管理に保存せよ
2.2.2 定期的にtrunkにチェックインせよ
2.2.3 意味のあるコミットメッセージを使え
2.3 依存関係の管理 76
2.3.1 外部ライブラリを管理する
2.3.2 コンポーネントを管理する
2.4 ソフトウェア設定を管理する 78
2.4.1 設定と柔軟性
2.4.2 設定の種類
2.4.3 アプリケーションの設定を管理する
2.4.4 アプリケーションをまたいで設定を管理する
2.4.5 アプリケーション構成管理の原則
2.5 環境を管理する 88
2.5.1 環境管理のためのツール
2.5.2 変更プロセスを管理する
2.6 まとめ
第03章 継続的インテグレーション 95
3.1 導入
3.2 継続的インテグレーションを実現する 96
3.2.1 始める前に必要なもの
3.2.2 基本的な継続的インテグレーションシステム
3.3 継続的インテグレーションの前提条件 99
3.3.1 定期的にチェックインせよ
3.3.2 包括的な自動テストスイートを作成せよ
3.3.3 ビルドプロセスとテストプロセスを短く保て
3.3.4 開発ワークスペースを管理する
3.4 継続的インテグレーションソフトウェアを使用する 104
3.4.1 基本的な操作
3.4.2 オプション機能
3.5 基本的なプラクティス 107
3.5.1 ビルドが壊れているときにはチェックインするな
3.5.2 コミットする前に、常にローカルでコミットテストを実行せよあるいは代わりにCIサーバーにやってもらえ
3.5.3 次の作業を始める前に、コミットテストが通るまで待て
3.5.4 ビルドが壊れているのに、家に帰ってはならない
3.5.5 常に以前のリビジョンに戻す準備をしておくこと
3.5.6 リバーとする前にタイムボックスを切って修正する
3.5.7 失敗したテストをコメントアウトするな
3.5.8 自分が変更してビルドが壊れたら、すべてに対して責任をとれ
3.5.9 テスト駆動開発
3.6 やったほうがいいプラクティス 113
3.6.1 エクストリームプログラミング(XP)の開発プロセス
3.6.2 アーキテクチャ上の違反事項があった場合にビルドを失敗させる
3.6.3 テストが遅い場合にビルドを失敗させる
3.6.4 警告やコードスタイルの違反があったときにビルドを失敗させる
3.7 分散したチーム 117
3.7.1 プロセスに与えるインパクト
3.7.2 中央集権的継続的インテグレーション
3.7.3 技術的な問題
3.7.4 代替案
3.8 分散バージョン管理システム 121
3.9 まとめ
第04章 テスト戦略を実装する 127
4.1 導入
4.2 テストの種類 129
4.2.1 開発プロセスをサポートするビジネス視点のテスト
4.2.2 受け入れテストを自動化する
4.2.3 開発プロセスをサポートする技術視点のテスト
4.2.4 プロジェクトの評価をするビジネス視点のテスト
4.2.5 プロジェクトを評価する技術視点のテスト
4.2.6 テストダブル
4.3 実際に起こり得る状況と戦略 137
4.3.1 新規プロジェクト
4.3.2 プロジェクトの途中
4.3.3 レガシーシステム
4.3.4 インテグレーションテスト
4.4 プロセス 144
4.4.1 血管バックログを管理する
4.5 まとめ
第2部 デプロイメント パイプライン
第05章 デプロイメント パイプラインの解剖学 151
5.1 導入
5.2 デプロイメントパイプラインとは何か？ 153
5.2.1 基本的なデプロイメントパイプライン
5.3デプロイメントパイプラインのプラクティス 159
5.3.1 バイナリをビルドするのは1回限りとせよ
5.3.2 あらゆる環境に対して同じやり方でデプロイせよ
5.3.3 デプロイメントをスモークテストせよ
5.3.4 本番のコピーにデプロイせよ
5.3.5 各変更は直ちにパイプライン全体を通り抜けなければならない
5.3.6 パイプラインのどの部分であっても、失敗したらラインを止めよ
5.4 コミットステージ 166
5.4.1 コミットステージのベストプラクティス
5.5 自動受け入れテストという関門 169
5.5.1 自動受け入れテストのベストプラクティス
5.6 後に続くテストステージ 173
5.6.1 手動テスト
5.6.2 非機能のテスト
5.7 リリースに備える 176
5.7.1 デプロイメントとリリースを自動化する
5.7.2 変更をバックアウトする
5.7.3 成功を積み重ねる
5.8デプロイメントパイプラインを実装する 180
5.8.1 バリューストリームをモデリングし、働くスケルトンを作成する
5.8.2 ビルドとデプロイメントプロセスを自動化する
5.8.3 ユニットテストとコード解析を自動化する
5.8.4 受け入れテストを自動化する
5.8.5 パイプラインを進化させる
5.9 メトリクス 186
5.10 まとめ
第06章 ビルド・デプロイメントスクリプト 191
6.1 導入
6.2 ビルドツールの概要 192
6.2.1 Make
6.2.2 Ant
6.2.4 Maven
6.2.5 Rake
6.2.6 Builder
6.2.7 Psake
6.3 ビルドスクリプトとデプロイメントパイプラインの原則とプラクティス 200
6.3.1 デプロイメントパイプラインのステージそれぞれに対してスクリプトを書け
6.3.2 アプリケーションをデプロイするのに適切なテクノロジーを使え
6.3.3 すべての環境にデプロイするのに、同じスクリプトを使え
6.3.4 OSのパッケージングツールを使え
6.3.5 デプロイメントプロセスが冪等(べきとう)であることを保証せよ
6.3.6 デプロイメントシステムをインクリメンタルに進化させよ
6.4 JVMを対象としたアプリケーションのためのプロジェクト構造 206
6.4.1 プロジェクトのレイアウト
6.4.2 ソースコードを管理する
6.4.3 テストを管理する
6.4.4ビルドの成果物を管理する
6.4.5 ライブラリを管理する
6.5 デプロイメントスクリプト 210
6.5.1 デプロイレイヤとテストレイヤ
6.5.2 環境設定をテストする
6.6 コツと裏技 214
6.6.1 常に相対パスを使え
6.6.2 手作業を根絶せよ
6.6.3 バイナリからバージョン管理へのトレーサビリティを組み込め
6.6.4 ビルド時にバイナリをバージョン管理にチェックインするな
6.6.5 テストが失敗してもビルドは続けよ
6.6.6 統合スモークテストでアプリケーションに制約をかけよ
6.6.7 .NETのコツと裏技
6.7 まとめ
第07章 コミットステージ 221
7.1 導入
7.2 コミットステの原則とプラクティス 222
7.2.1 役に立つフィードバックを素早く提供せよ
7.2.2 どういうときにコミットステージを止めるべきか？
7.2.3 コミットステージを丁寧に整備せよ
7.2.4 開発者に所有権を与えよ
7.2.5 きわめて大規模なチームにはビルドマスターを置け
7.3 コミットステージの結果 227
7.3.1 成果物リポジトリ
7.4 コミットテストスイートの原則とプラクティス 230
7.4.1 ユーザーインターフェイスを避けよ
7.4.2 DIを使用せよ
7.4.3 データベースを避けよ
7.4.4 ユニットテストでの非同期処理を避けよ
7.4.5 テストダブルを利用する
7.4.6 テスト内の状態を最低限に抑える
7.4.7 時間の概念を偽装する
7.4.8 しらみつぶり
7.5 まとめ
第08章 自動受け入れテスト 241
8.1 導入
8.2 なぜ自動受け入れテストが欠かせないのか？ 242
8.2.1 保守しやすい受け入れテストスイートの作り方
8.2.2 GUIを叩いてテストする
8.3 受け入れテストを作成する 247
8.3.1 アナリストとテスターの役割
8.3.2 イテレーティブなプロジェクトにおける分析
8.3.3 実行可能な仕様としての受け入れ基準
8.4 アプリケーションドライバレイヤ 253
8.4.1 受け入れ基準の表現方法
8.5 受け入れテストを実装する 259
8.5.1 受け入れテストにおける状態
8.5.2 プロセス境界・カプセル化・テスト
8.5.3 非同期とタイムアウトを管理する
8.5.4 テストダブルを利用する
8.6 受け入れテストステージ 269
8.6.1 受け入れテストをグリーンに保つ
8.6.2 デプロイメントテスト
8.7 受け入れテストのパフォーマンス 275
8.7.1 共通のタスクはリファクタリングせよ
8.7.2 高価なリソースは共有せよ
8.7.3 並列テスト
8.7.4 コンピュートグリッドを用いる
8.8 まとめ
第09章 非機能要件をテストする 281
9.1 導入
9.2 非機能用件を管理する 282
9.2.1 非機能要件を分析する
9.3 キャパシティを確保するためのプログラミング 284
9.4 キャパシティを計測する 287
9.4.1 キャパシティテストの成功・失敗の判断基準は？
9.5キャパシティテスト環境 291
9.6キャパシティテストを自動化する 294
9.6.1 ユーザーインターフェイス経由のキャパシティテスト
9.6.2 サービスや公開APIに対するインタラクションを記録する
9.6.3 記録したインタラクションテンプレートを使う
9.6.4 キャパシティテスト用スタブを使ったテスト作り
9.7キャパシティテストをデプロイメントパイプラインに追加する 302
9.8キャパシティテストシステムのもうひとつの利点 304
9.9 まとめ
第10章 アプリケーションをデプロイ・リリースする 307
10.1 導入
10.2 リリース戦略を作成する 308
10.2.1 リリース計画
10.2.2 製品をリリースする
10.3 アプリケーションをデプロイする 310
10.3.1 最初のデプロイメント
10.3.2 リリースプロセスをモデル化し、ビルドを反映する
10.3.3 設定を反映させる
10.3.4 オーケストレーション
10.3.5 ステージング環境へのデプロイメント
10.4 デプロイメントのロールバック、そしてゼロダウンタイム・リリース 317
10.4.1 直近の正常動作するバージョンの再デプロイメントによるロールバック
10.4.2 ゼロダウンタイム・リリース
10.4.3 ブルーグリーン・デプロイメント
10.4.4 カナリアリリース
10.5 緊急修正 324
10.6 継続的デプロイメント 325
10.6.1 ユーザーがインストールするソフトウェアを継続的にリリースする
10.7 ヒントと裏技 329
10.7.1 実際にデプロイメントを行なう人たちを、デプロイメントプロセスの策定に参加させよ
10.7.2 デプロイメント作業を記録せよ
10.7.3 古いファイルは削除せず、移動せよ
10.7.4 デプロイメントはチーム全体で責任を持つ
10.7.5 サーバーアプリケーションにGUIを持たせない
10.7.6 最初のデプロイメントにはウォームアップ期間を持たせよ
10.7.7 失敗は早めに
10.7.8 本番環境を直接修正するな
10.8 まとめ
第3部 デリバリー エコシステム
第11章 基盤と環境を管理する 337
11.1 導入
11.2 運用チームのニーズを理解する 339
11.2.1 文書化と監査
11.2.2 異常発生時の警告
11.2.3 ITサービスの継続計画
11.2.4 運用チームが慣れている技術を使え
11.3 基盤をモデリングし、管理する 343
11.3.1 基盤へのアクセスを制御する
11.3.2 基盤へ変更を加える
11.4 サーバーのプロビジョニングおよび設定を管理する 348
11.4.1 サーバーのプロビジョニング
11.4.2 進行中のサーバー管理
11.5 ミドルウェアの構成を管理する 356
11.5.1 設定を管理する
11.5.2 製品を調査せよ
11.5.3 ミドルウェアが状態をどのように扱うのかを調査せよ
11.5.4 設定APIを探せ
11.5.5 よりよいテクノロジーを採用せよ
11.6 基盤サービスを管理する 361
11.6.1 マルチホームシステム
11.7 仮想化 364
11.7.1 仮想環境を管理する
11.7.2 仮想環境とデプロイメントパイプライン
11.7.3 仮想環境を使った、高度に並列化したテスト
11.8 クラウドコンピューティング 373
11.8.1 基盤のクラウド化
11.8.2 プラットフォームのクラウド化
11.8.3 ひとつで何もかもを解決する必要はない
11.8.4 クラウドコンピューティングに対する批判
11.9 基盤やアプリケーションを監視する 378
11.9.1 データを収集する
11.9.2 ログ出力
11.9.3 ダッシュボードを作成する
11.9.4 ふるまい駆動監視
11.10 まとめ
第12章 データと管理する 387
12.1 導入
12.2 データベースのスクリプト処理 388
12.2.1 データベースを初期化する
12.3インクリメンタルな変更 390
12.3.1 データベースのバージョンを管理する
12.3.2 オーケストレイトされた変更を管理する
12.4データベースのロールバックとゼロダウンタイムリリース 394
12.4.1 データを失なわずにロールバックする
12.4.2 アプリケーションのデプロイをデータベースのマイグレーションから分離する
12.5 テストデータを管理する 397
12.5.1 仮のデータベースでのユニットテスト
12.5.2 テストとデータのつながりを管理する
12.5.3 テストの分離
12.5.4 準備と後始末
12.5.5 一貫したテストシナリオ
12.6 データの管理とデプロイメントパイプライン 401
12.6.1 コミットステージでのテストにおけるデータ
12.6.2 受け入れテストにおけるデータ
12.6.3 キャパシティテストにおけるデータ
12.6.4 その他のテストステージにおけるデータ
12.7 まとめ
第13章 コンポーネントや依存関係を管理する 409
13.1 導入
13.2 アプリケーションをリリース可能な状態に保つ 411
13.2.1 新機能は完成するまで隠せ
13.2.2 すべての変更はインクリメンタルに
13.2.3 抽象化によるブランチ
13.3 依存関係 416
13.3.1 依存地獄
13.3.2 ライブラリを管理する
13.4 コンポーネント 420
13.4.1 コードベースをコンポーネントに分割する方法
13.4.2 コンポーネントをパイプライン化する
13.4.3 インテグレーションパイプライン
13.5 依存グラフを管理する 429
13.5.1 依存グラフを作成する
13.5.2 依存グラフをパイプライン化する
13.5.3 いつビルドすべきか？
13.5.4 慎重な楽天主義
13.5.5 循環依存
13.6 バイナリを管理する 439
13.6.1 成果物リポジトリの活用法
13.6.2 デプロイメントパイプラインと成果物リポジトリとのやりとり
13.7 Mavenを使って依存関係を管理する 441
13.8 まとめ
第14章 高度なバージョン管理 447
14.1 導入
14.2 リビジョン管理システムの簡単な歴史 448
14.2.1 CVS
14.2.2 Subversion
14.2.3 商用のバージョン管理システム
14.2.4 悲観的ロックをやめろ
14.3 ブランチとマージ 454
14.3.1 マージ
14.3.2 ブランチ、ストリーム、そして継続的インテグレーション
14.4 分散型バージョン管理システム 460
14.4.1 分散型バージョン管理システム
14.4.2 分散型バージョン管理システムの簡単な歴史
14.4.3 企業環境における分散型バージョン管理システム
14.4.4 分散型バージョン管理システムを使う
14.5 ストリームベースのバージョン管理システム 466
14.5.1 ストリームベースのバージョン管理システムとは？
14.5.2 ストリームを使った開発モデル
14.5.3 静的ビューおよび動的ビュー
14.5.4 ストリームベースのバージョン管理システムによる継続的インテグレーション
14.6 メインライン上での開発 472
14.6.1 複雑な変更をブランチなしで行なう
14.7 リリース用のブランチ 475
14.8 フィーチャによるブランチ 477
14.9 チームによるブランチ 480
14.10 まとめ
第15章 継続的デリバリーを管理する 485
15.1 導入
15.2 構成管理およびリリース管理の成熟度モデル 487
15.2.1 成熟度モデルの使い方
15.3 プロジェクトのライフサイクル 489
15.3.1 発見期
15.3.2 開始期
15.3.3 構築期
15.3.4 開発・リリース期
15.3.5 運用期
15.4 リスク管理プロセス 497
15.4.1 リスク管理入門
15.4.2 リスク管理のタイムライン
15.4.3 リスク管理の実践法
15.5 デリバリーによくある問題 - その症状と原因 501
15.5.1 頻度の低いデプロイメント・バグのあるデプロイメント
15.5.2 貧弱な品質のアプリケーション
15.5.3 管理が貧弱な継続的インテグレーションプロセス
15.5.4 貧弱な構成管理
15.6 コンプライアンスと監査 505
15.6.1 文書化よりも自動化を
15.6.2 トレーサビリティを確保する
15.6.3 サイロで作業する
15.6.4 変更管理
15.7 まとめ
ハンブル，ジェズ（Humble,Jez）
さまざまなプラットフォームや技術を扱い、非営利団体やテレコム、
さまざまなプラットフォームや技術を扱い、非営利団体やテレコム、
金融サービス、オンラインレンタル企業などのコンサルを行っている。
２００４年以来、ＴｈｏｕｇｈｔＷｏｒｋｓと、北京、バンガロール、
ロンドン、サンフランシスコのＴｈｏｕｇｈｔＷｏｒｋｓ Ｓｔｕｄｉｏで働いている。
オクスフォード大学の物理学および哲学の学士と、
ロンドン大学東洋アフリカ学部民族音楽学の修士を有している。
イテレーティブな開発や継続的インテグレーション、かなりの量の自動テストなどを採用してきた。
「デリバリー」をキーワードに、要件定義、方式設計から開発、
テストまでロールにとらわれずに仕事をしている。
1972年大阪府生まれ。さまざまなプロジェクトでドキュメントの翻訳に携わるようになる
