メディア

オフショアでアジャイル開発の実際：アジャイル実践者インタビュー（3）

JUDEはUMLツールとして無償版から始まり、有償版も出て広く使われてきているツールであるが、この製品開発がオフショア（中国）と日本とでアジャイルに実施されていることはそれほど知られていないと思う。今回はオフショア開発での話とJUDEプロダクト自身のアジャイルな一面を開発者自身に答えてもらう。

» 2006年03月10日 12時00分公開

[猪狩錦光, 畑田成広, 水越明哉, 塩田英二，＠IT]

　JUDEは、1999年から2000年に最初の「Jude梅」シリーズを公開し、その後一時開発を中断、2002年冬に「Jude竹」で復活し、2004年10月に無償版を「JUDE/Community」に名称変更した。その後、同11月に有償版である「JUDE/Professional」の販売を開始した。

　JUDEはオフショアで開発をしている。加えて、JUDEという製品開発を進めるうえで、初めに定まり切らない仕様とその時々に出てくるさまざまなユーザーニーズに柔軟に迅速に対応していくために、結果としてアジャイル的な開発を実践してきている。今回はその一端を開発者のインタビューを通して紹介する。

体制

　当初は中国側、日本側それぞれ3名程度の体制でスタート、その後製品版の発売などでサポート要員なども増え、今回設立した新会社ではJUDEの開発とサポートに、中国10名、日本10名の体制となった。日本側開発陣の中核的メンバーである永和システムマネジメント第2事業本部　UML事業部の山本明夫　事業部長と梅田政利さんに話を伺った。

梅田　中国とは、昔から付き合いがあったわけではありません。オフショアの可能性を確認する意味もあって、当時開発が一時ストップしていた「Jude梅」の機能強化をオフショア開発で行うこととなり、2002年10月から「Jude竹」の開発がスタートしました。

山本　オフショア開発の話がなければ、JUDEの機能強化はもっと遅れており、これほど多くのユーザーの方に使われるツールにはなっていなかったかもしれません。

梅田　JUDEの開発に本格的にアジャイルを取り入れたのも、「Jude竹」の開発からで、ほとんど初めての試みでした。中国側もアジャイルは初めてでした。いまでも中国でのアジャイル開発は特殊な方で、それほど一般的にはなっていないと思います。

コミュニケーション

梅田　始めに日本側から全員が中国に3週間行って、実際に2イテレーションのアジャイル開発を行いました。次に日本と中国に分かれての分散開発を挟んだ後に、日本で2週間再び全員が同じ場所にそろって開発しています。

　これは、ペアプログラミングや朝会、そして一緒に食事をすることなどによって、お互いの理解、ナレッジ共有などのためのコミュニケーションをしっかり取る狙いがあり、その効果は非常に大きかったと思います。一度ペアプログラミングをしておくと、その後分散開発になっても信頼関係やお互いへの理解が継続できます。

　また、いったん分散開発を挟んで、その問題点を日本での合同開発のときに確認し合ったことも、その後の分散開発を行ううえで役に立ちました。

中国でのペアプログラミング風景

開発場所

　その後はメッセンジャーを用いてリアルタイムに会話することとしていましたが、英語でのやりとりで、仕様確認とかになるとずっとチャットし続ける状態になってしまっていたので、いまはコミュニケータとして中国側から日本語の分かる要員に1人日本に来てもらいその人を介して行うようにしています。それでも直接話をするときはやはり英語です。後は文字ベースだとどうしても限界があるので、Wikiを立ち上げてそこに画像をペタペタ張ったりして仕様を共有しています。

山本　過去に、明らかに仕様が間違っているにもかかわらず、間違った仕様どおりに無理やり作られた謎なコードが送られてきたこともあります。英語はどちらにとっても第2言語なので、どうしても十分なコミュニケーションが得られず、仕様の基となっている要求を伝え切れなかったのが原因でした。

　開発メンバーには中国の人もいますが、現在は中国から1人、コミュニケータとして来てもらう形がうまく機能しています。一般的にはブリッジSEと呼ばれる役割だと思いますが、JUDEのチームではコミュニケータと呼ばれています。

　徐々に変化しながら、いまのコミュニケータという形に落ち着いてきたとのことである。もちろんUMLの設計情報のコミュニケーションに関してはJUDE自身を使って行っているという。続いて実践していることに関してきいた。

サインアップ

梅田　いまでもこれは継続しているのだけど、だんだん選択できるタスクの範囲が限定されてきていてあまり選択の余地がなくなってきています。ある意味、専門化が進んだのだと思います。専門化が進むと、生産性は上がる傾向にあるのですが、逆にハネムーンナンバー（注1）を減らすリスクにつながるため、どのように知識を分散させるべきか、今後の課題です。

▼注1：チームのメンバーが何人新婚旅行に行っても大丈夫かという指標

イテレーションサイクル

梅田　当初からの1週間を原則維持しています。継続的インテグレーションという点では共通のCVSサーバを利用しています。ただ、ピュアなXPで推奨されているように、毎日の終わりは必ずエラーなく動くものがありますよ、という状態では残念ながらありません。

ペアプログラミング（ペアプロ）

梅田　ペアプロはあまり実施していません。定着させたいなと思うこともあるのですけど、コスト感があるので、効果が見えるまで続ける余裕がありませんでした。

　やっぱり2人で別々にやった方が早いじゃんみたいなところがあって、リリース前にこれとこれはやらないといけないから、別の人にやらせたいとか、そういうのがどうしても出てきて、それが増えてなし崩し的にやらなくなっています。

　ただし、重要な個所に対する場合や教育目的を持つ場合に、ペアプロをすることはありますね。検証はできていませんが、コードの品質はやはりペアプロで向上すると思います。とはいえ、自分はどっちかというと1人でやりたい派ですかね。

ツール

梅田　分散アジャイル開発では、ツールが特に重要になります。直接会って話をする、壁に張る、が一番なのですが、それにできるだけ近づけるツールを厳選して使っています。


種類	ツール	効果
開発	Eclipse	プログラミングが楽。ソースを追うのが楽。テストが楽。リファクタリングが楽
構成管理	CVS、Sub version	ソースコード共有が楽
会話	インスタントメッセンジャー（MSN Messengerほか）	情報・考えを伝えるのがメールに比べ格段に楽
情報共有	Swiki、TWiki、PukiWiki、影舞、Tracほか	非常に手軽に情報共有できた
XP管理	XPlanner、XpTrackerPlugin（TWiki plugin）	WebベースのXPプロジェクトサポートシステム（JUDEプロジェクトでは未使用）
ユニットテスト	JUnit	テストが楽
ビルドツール	Ant	頻繁なリリースが楽
遠隔ペアプロ	Sangam（Eclipse plugin）	離れた人とのペアプロの可能性

ツールとアジャイル開発（分散開発はツールにも支えられる）

テスト

梅田　自動テストはなるべく作っていきたいという流れに、なってきています。最初に頑張れば、良いテストが書けたのかもしれないのですが、そこのコストを思い切って掛けられない状態だったので、テストがそろっていないからテストを作るのが難しいという悪循環になっているところがあります。

　テストがそろっていると、その後開発したものにテストを足していくという強制力にもなりますよね。そういうところも弱くて、気が付いたらテストを書く文化が、一部に限ったものになってしまいました。例えば、モデルの周りを編集するところはテストがあるけど、GUI周りの部分はテストが少ないといった感じです。特にGUI周りは、テストする指針というか、具体的なやり方が見えなかったため、力を掛けることができませんでした。自動テストが厳密にそろっていないので、リリース前にはたくさんのテストを手作業で行っています。ここは大きな課題になっています。やはり頻繁なリリースには、自動テストの充実は欠かせないでしょう。

　ちなみに、JUDEのテストのレベルは、モデルテスト、コマンドテスト、ストーリテストの3レベルになっていて、最初の2つはJUnitを使っています。また、受け入れレベルはほとんど手動のテストです。

　それから、僕たちのプロセスは1リリースが3カ月、1イテレーションが1週間です。そして、ちょっと変わったところとしては、イテレーションの最初の方は、モデルに集中し、その後でモデルの上に機能を載せていきます。テストとしては、最初はモデルテストが中心です。途中からコマンドテストができるようになります。そして、製品リリースの最後のイテレーションは、ほぼそっくりそのままテストのみに割り当てられています。


モデルテスト（JUnit）	内部で持っているモデル（UMLメタモデルなど）が正しいかを確認する
コマンドテスト（JUnit）	アプリケーションを起動した状態でコマンドを送り、コマンドが正しく実行できるかを確認する
ストーリテスト（手動）	ユーザーストーリを正しく実行できるかを目視で確認する

テストの種類

オンサイトカスタマー

山本　JUDEの場合はユーザーからの要望が数多く寄せられており、非常に参考になっています。

梅田　当然ユーザーからの要望も重要ですが、一番決定権を持っている顧客の役目を果たすのが、優先度1で平鍋さん（永和システムマネジメント取締役副社長）、次にうちのプロジェクトリーダー、後はメンバー内で適当に、という感じです。

山本　平鍋さんからの要望も、いろいろなセミナーで話をした内容に対する質問や要望が集約されていることが多いですね。そして、平鍋さん経由でリクエストされた要望は、実際に機能として採用される確率が非常に高くなります。

梅田　平鍋さん自身の意見もユーザー視点が多いと思いますね。プレゼンしていたら、ここが気に入らなかったとか、こういう機能がほしいなとか。本当に顧客みたいなものです。平鍋さん自身がJUDEのヘビーユーザーなので。

アジャイルとUML

――UMLツールをアジャイルに作っているわけですが、アジャイルとUMLの関係はどう考えていますか？

梅田　私はアジャイルとUMLはあまり関係ないと思っていて、単にコミュニケーションをするためのツールがUMLなだけで、こちらの意図が正確に伝われば、何でもいいと思います。JUDE作っていていうのもなんですけど、本当に何でもいいかなと。

　JUDEチームに関しては、UMLは本当にコミュニケーション目的でしか使っていないといってしまっていいと思います。そういう意味ではアジャイルにすごくマッチした使い方だと思っています。

山本　アジャイルとUML自体はそれほど密接な関係はないと思います。JUDE自身がどちらかというと、必要な部分の設計をラフスケッチ的に書いて、それでコミュニケーションするためのツールという趣旨で開発が始まっています。実際にJUDEの開発でもそのような使い方をしていますね。

JUDEの特色：スケッチングツール

梅田　アジャイル系の方の中にはスケッチというものを肯定している方が多い印象があり、JUDEは使いやすいスケッチに向いたツールとして、そういう方たちに受け入れられていると感じます。半面、UMLに新しく入るという意味での入門者は、どうしてもカタログスペックに目を奪われている気がして、そこを何か、うまく変えていきたいと感じます。UML 2.0のように厳密なものを必要とする人はごくまれですよね。

　実際MDA方向が必要っていうか、いますぐ適用すべき範囲というのはごく一部じゃないのかなと思っています（JUDEは現在UML 2.0対応を進めている。2006年6月ごろには最初のリリースを行う予定）。

マインドマップ

山本　JUDEの大きな特色として、使いやすいという以外に、マインドマップのサポートがあります。マインドマップは、ユーザーからの要望ではなく、UMLとマインドマップを組み合わせたら面白いじゃないかという内部アイデアによるものです。普通はこんな要望は出さないですよね。JUDEにマインドマップを乗せるかどうかについては内部的な議論は賛否両論いろいろありましたけどね、ユーザーの方には非常に評価していただいており、いまではほかのUMLモデリング製品と比較した場合の最大の特徴といえるでしょうね。

梅田　マインドマップでどこまで表現できるようにするかっていうのはあるのですけど、JUDEの既存の機能をベースに、マインドマップの機能を必要最低限のレベルで押さえると、結構単純じゃないですか。そういう意味で、実装するための敷居は低かったかなと。ものすごい開発ボリュームだったら、JUDEに乗らなかったと思いますけど。

パッケージ開発とアジャイル

梅田　パッケージ開発というのはアジャイル開発に向いていると私は思います。最初にガーンと出して、そこからあまり成長が要らないパッケージなら別だと思いますが、全体が大き過ぎて、いきなりバーンと出せないものとか、少しずつ成長させていきたいツールだとやはりアジャイルが向いているんじゃないかと思います。

山本　マインドマップも最初のリリースでは必要最低限の機能でしたが、ユーザーからの反応が非常に良かったので、その後のバージョンアップで機能追加と改善を繰り返して、マインドマップツールとして必要な機能をそろえてきました。

　最初からすべての機能をそろえようとしていたら、まだ出せていなかったかもしれません。何より、それだけの工数と時間を掛けてユーザーに受け入れられなかったら意味がありません。

　特にUMLは、今後も新しい規格がどんどん出てくると思いますし、ツールに対するユーザーの要望がまだまだ活発な状況ですので、数年かけて開発した新バージョンをリリースするという開発サイクルではあまりにも長過ぎて、変化の激しい市場ニーズに対応できません。そういう点ではアジャイル的な開発による年3、4回の製品リリースサイクルは、いまのJUDEに非常に合っていると思います。

　今後UMLの規格も固まって、ユーザーからの要望や、取り込みたい機能がなくなってしまえばリリースサイクルも変わるかもしれませんが、JUDEでやりたいことのストックはいっぱいあるので、まだまだ先の話です。

中国での共同開発風景

　以上、JUDEの製品開発を通して、オフショアという遠隔地との開発におけるアジャイル開発の特色の一端が垣間見られたのではないかと思う。1カ所に集まってやらなければできないなどという制約にとらわれず、果敢に実践してこられている様が少しでも伝われば幸いである。

「アジャイル実践者インタビュー」バックナンバー