ObjectSquare [2012 年 10 月号]

[突撃インタビュー]

separator line

組み込みアジャイルコーチ James Grenning さん突撃インタビュー( 前編 )

 Jonathan さん

去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。

インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった以下の話題についての質問を順次尋ねる形で進めました。

・ 組み込みソフトウェアに対するアジャイル開発やTDDの導入
・ モデリングやアーキテクチャ設計と TDD の関係
・ 従来のテストとTDDの関係
・ アジャイル開発でのシステムテストの運用

今月より数回に渡り、Jamesさんへの突撃インタビューの結果をお伝えします。


1. James Grenningさんのこれまでの経歴

-- 今日は、インタビューの機会を下さいましてありがとうございます。最初に James さんのこれまでのご経歴 [3] ついて簡単に説明して頂けませんでしょうか?

そうですね、昔の話からしましょうか。私が高校生の頃、コンピュータを持っている友達がいました。そのコンピュータはプログラムをパンチカードに印刷して使うものでした。プログラムを動かすために、わざわざ窓の無い部屋に行かなくてはいけなくて非常にひどいもののように思えました。なので、あの当時はコンピュータを避けていましたね。

-- ( 笑 )

70年代、私は大学生でした。数値解析の講義を受講して、BASIC でニュートン法のシミュレーションをやったのですが、非常に楽しかったことを覚えています。それで、コンピュータの講義も受講し、プログラミングにのめり込んで行きました。「楽しい」それが最初の体験です。

最初の仕事はアメリカ連邦航空局 [4] から請け負った天気図表示システムの開発です。降雨量の傾向を違う色で表示するシステムのハードウェアとソフトウェアの両方を小さいチームで開発しました。これが最初の組み込みの仕事です。

2つ目の仕事では、80年代に Robert Martin [5] と一緒に Teradyne [6] という会社で働きました。彼は「 Bob おじさん」と呼ばれている人ですね。Bob は80年代後半に退職して、Object Mentor [7] という素晴らしいコンサルティング会社を起業しました。私は90年代半ばまで Teradyne にいて、その後に Bob の会社に入りました。

Bob の会社では、オブジェクト指向設計のコーチング、トレーニング、コンサルティングの業務をしました。コンサルティングという仕事の性質のため、組み込み以外も含めて、多種多様な仕事を担当しました。

90年代に特にやったのが XP の導入です。その当時、XPは 組み込みシステム開発をやる人間にとっても重要なものだという印象を受けました [8] 。組み込みシステム開発の問題の一つがハードウェアが準備されていない状況でソフトウェアを開発しなければいけないことですが、私は XP に取り組む中で製品コードからハードウェアへの依存性を取り除く可能性について考えました。そうすることで、ハードウェアを待たずしてソフトウェアの開発を進めることができるからです。

この当時、同じ取り組みをしていた Motorola と仕事したことは幸運だったと思っています。その時は、C++ で組み込みシステムを開発していて、多くのハードウェアやOSを必要としていました。私たちはインタフェースまで実装して、シミュレーションで中の動作を確認したりしました。

その後、しばらくして組み込みシステムカンファレンスでアジャイル開発について紹介するようになりました [9] 。当時は誰もアジャイル開発について発表していませんでしたからね。組み込みシステム開発に対するアジャイル開発や TDD の導入に興味を持つ人に話をしようとしましたが、参加者からの最初の反応は「(興味がなさそうに)ふーん、面白そうだね。うちでもできたらいいな。」というものでした。「だったら、なんで君はこのカンファレンスにいるんだ?君がここにいる理由はない。どっかよそに行ってくれ。」そう思いました。幸運なことにカンファレンスの後、組み込みシステム開発者にとって重要なものを理解して、がっかりするようなことはありませんでした。

その後、2008 年に Renaissance Software Consulting 社を起業して、現在は企業に対するアジャイル開発の導入を支援しています。

-- Jamesさんはアジャイルソフトウェア開発宣言を書いたメンバーの一人ですよね。その活動にどのように参加したのでしょうか?

元々は、Bob と Alistair Cockburn [10] がアジャイルソフトウェア開発宣言の取り組みを始めました。Bob からは「ユタ州にスキーに行こう」と聞かされていたのでスキーが大好きな私は参加することにしました [11]

--(笑)

その当時、私は XP について取り組み始めたばかりでした。Bob Martin や Martin Fowler [12] といった XP の指導者達からプラクティスを教えてもらえることができて非常に幸運でした。 そして、ミーティングでは非常に面白い話ができ、発見に満ちていました。

驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。

それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。

2. 組み込みソフトウェアに対するアジャイル開発やTDDの導入

 Jonathan さん

-- 組み込みソフトウェア開発にTDDを導入する事例は増えているのでしょうか?

確かに興味は持たれています。私はこの種類のプラクティスは、産業界に受け入れられる必要があると思っています。 TDD が受け入れられるかどうかは、法律の問題になるでしょう。それはソフトウェアの欠陥は深刻な問題を引き起こすからです。問題が起きた後では企業の社会的地位を保つ方法はありません。おそらく日本でも同じでしょう。もし、私が「 debug later programming 」と呼んでいる手法、つまり実装後にデバッグをしてバグを見つける手法を続けるなら、製品の品質を軽視していると言えるかもしれません。法律の問題になることは避けるべきだと考えるので、TDD を導入してほしいとは思います。今後もソフトウェアの欠陥は産業に対して影響を与え続けるでしょう。

-- 組み込みソフトウェア開発にTDDを導入する一番のモチベーションは何でしょうか?

皆さん、開発で痛みを感じているので、私はモチベーションから始めることが好きです。TDD の導入を検討する最初のモチベーションはバグの追跡でしょう。

私がトレーニングをやる時は事前にアンケートを取り、3つの数字を答えてもらいます。それは開発期間における (1) 実装の比率、(2) テストの比率、(3) デバッグの比率です。通常、テストとデバッグは実装より多くなります。そして、企業は労力のほとんど、具体的には 50% 以上をバグの除去に費やしています。

私は、新しく TDD に興味を持った人に対してバグの防止を最重視していることを強調します。もし、TDD のアプローチに従うなら、実装中にバグが検出されるので、多くのバグを未然に防ぐことができます。全てではありませんが、多くは防げます。企業経営者に話をする時も、TDD がバグを防止する仕組み、そして debug later programming の問題について説明しています。もし、コードの欠陥によるリスクを取り除くができれば、開発はより良いものになるでしょう。

もう1つモチベーションがあります。手動テストが持続可能ではないということです [13]。テストを手動でやるなら、ちょっとした修正をやった時や新しい機能を追加する時に全ての機能を自分でテストする必要があります。こうなるとテストの工数が制御できなくなります。私の知っている限りでは、テスト工数を低く保つにはテストを自動化するしかありません。

他の影響として、適切に書かれたテストコードは実行可能なドキュメントになります。これは開発の後に得られる2次作用のようなものです。

-- 多くの現場ではテストコードがない製品コードが多く、TDD の導入が困難な場合があります。その場合、どのように対処すれば良いでしょうか?

まずは小さく始めるべきです。テストコードがない場合でも、新しい機能を追加する時に、同じようにテストも追加します。既存のコードに変更を加える時、変更の前に変更対象のコードをテストハーネス [14] に追加し、コードの振る舞いについて確信を得るためにいくつかテストを書き、コードの修正作業をテストで駆動します。

Michael Feathers [15] がレガシーコードに対するテストについて「レガシーコード改善ガイド」という素晴らしい本を書いています。私の本の第13章「Adding Tests to Legacy Code」にも、製品コードから動作対象のハードウェアに依存した部分を分離し、段階的にテストハーネスに追加する手続きについて書いているので参考にしてください。

-- 組み込みシステム開発では、一般的にソフトウェア開発以外にもハードウェア開発とQAも非常に時間がかかり、困難な作業です。アジャイル開発をやる上で、どんな対策があるのでしょうか?

QA のプロセスにおいては反復的なアプローチを考えると良いでしょう。それは QA 担当者が各イテレーションにおいて開発者が作った成果物に対してテストを書くやり方です。開発者がイテレーションの仕事を 1〜2 週間で完了し、QA 担当者がテストし、成果物の受け入れを行います。

この時に QA 担当者がやるテストは、単体テストより高いレベルのテストです。いくつか名前があり、振る舞い駆動開発(Behavior Driven Development; BDD)[16]、ストーリーテスティング、受け入れテスト駆動開発(Acceptance Test Driven Development; ATDD)[17]、統合テストなどと呼ばれています。このような「実行可能な仕様」を書くためのツールとして、FitNesse/CSlim [18]Cucumberrobotframework などがあります。

私自身はハードウェアについてはあまり情報を提供できません。Timo PunkkaNeil Johnson [19] がハードウェアの領域にアジャイルを適用する取り組みをしています。彼らのブログが参考になるでしょう。

また、リーン開発から来たもう1つの興味深いアイデアとしてバリュー・ストリーム・マッピング [20] があります。この手法により、プロセスを見て、無駄や遅延を排除できます。バリュー・ストリーム・マッピングについて学んで、自分のプロセスに適用してみると良いかもしれません。

-- アジャイル開発においてテストの役割分担の境界をどう設定するのでしょうか?開発者がどこまでをテストし、どこから QA 担当者がテストするべきでしょうか?

なぜ境界が必要だと考えるのでしょうか?

システムを開発する上では、多くのテストすべきポイントがあります。どこに入力を挿入するか、そしてどこの反応を見るか、多くの選択肢があります。システムが動いているか、そして動き続けるかを確認する上で必要なテストを追加するためには、我々は境界を越えてテストする必要があります。

QA 担当者は要求が満たされているか確認するテストを作成しますが、 QA 担当者が必ずしもプログラミングのスキルがあるわけではないでしょう。そのため、自動テストが導入し始めの頃は開発者が QA 担当者と一緒に QA のテストを書くことになるかもしれません。時には、どうテストを書くか具体的に教えることになるでしょう。

役割の境界についてそれほど気にしないでください。それよりも必要なテストを書くためにチームとして働きましょう。



以上が前半の内容です。次回もご期待下さい。


<補足>

[1] 書籍の内容については2012年9月号公開の書籍紹介記事を参照。

[2] 詳しくは「プランニングポーカー・オブジェクトゲームでアジャイルゲーム! Agile 2011 Conference」を参照。

[3] 詳細な経歴は James さんのサイトを参照。

[4] アメリカの運輸省の下部機関で、航空輸送の安全維持を担当する部局。

[5] アジャイル開発宣言の著者の一人。著書には『アジャイルソフトウェア開発の奥義 - オブジェクト指向開発の神髄と匠の技』、『Clean Code - アジャイルソフトウェア達人の技』、『Clean Coder - プロフェッショナルプログラマへの道』などがある。

[6] エレクトロニクス産業向けの自動試験装置で世界最大のメーカー。

[7] 1991年、Robert Martin によって設立された企業。オブジェクト指向開発やXP/Agileの導入支援を行なっている。

[8] 著書の前書きにおいて XP を考案した Kent Beck と直にペアで TDD をやった経験から、TDD の実用性を意識するようになったと言及している。

[9] Object Mentor 社のサイトに 2002年の James 氏の論文(PDF)「Extreme Programming andEmbedded Software Development」が掲載されており、2000年代初頭から組み込みシステム開発の分野にXPを啓蒙していたことがうかがえる。

[10] アジャイル開発宣言の著者の一人。著書には『アジャイルソフトウェア開発』や『ユースケース実践ガイド - 効果的なユースケースの書き方』などがある。

[11] ミーティングはアメリカ・ユタ州のスキーリゾート地で行われた。経緯についてはThe Programatic BookShelfの「Agile @ 10 - Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary」(共著)のJames氏の記事にも書かれている。

[12] アジャイル開発宣言の著者の一人。著書には「ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目」、「リファクタリング - プログラムの体質改善テクニック」、「エンタープライズ アプリケーションアーキテクチャパターン」などがある。

[13] Jamesさんのブログエントリ「Manual Test is Unsustainable」で詳しく紹介されている。

[14] ソフトウェアテストで用いられるテスト実行用のソフトウェアのこと。

[15] Object Mentor社のシニアトレーナ、メンター、コンサルタント。長年、アジャイルやXPのプラクティス、オブジェクト指向設計のメンタリングやトレーニングを行なっている。

[16] TDD から派生した開発手法であり、開発をテストで駆動する点は共通している。TDD ではプログラムの動作が正しいかどうかを確認するためのテストを書くのに対し、BDDではプログラムの「振る舞い」を自然言語に近い形で要求仕様として記述するという違いがある。 BDD の概要、具体的なテストコード、テスティングフレームワークの使い方については 「IBM developerWorks - コード品質を追求する: ビヘイビア駆動開発を舞台にした冒険」や「RubyistMagazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)」を参照。

[17] TDD から派生した開発手法であり、開発をテストで駆動する点は共通している。TDD では開発者が単体テストのレベルでソフトウェアの品質を開発者の観点で検証するのに対し、ATDD は顧客が受け入れテストのレベルでソフトウエアの品質をユーザーの観点から検証するという違いがある。詳しくは「ITPro - 「攻めるテスター」がアジャイル開発の品質を保証する」を参照。

[18] Agile2011に「How CSlim and Fitnesse Can Help You Test Your Embedded System: Doug Bradbury」というセッションがあり、FitnessとCSlimの組み合わせで組み込み分野に適用事例があることが分かる。

[19] Neil Johnson氏は「AgileSoC」という回路設計へのアジャイル開発適用を提唱しており、System Verilog用のテスティングフレームワークとしてSVUnitを開発している。

[20] リーン生産技法のひとつであり、製品やサービスを消費者に届けるのに必要な材料と情報の流れを分析するために使用される。

separator line
©2012 OGIS-RI Co., Ltd.
Index Next
Index Next