先日、「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」というタイトルの講演（講師 日本アイ・ビー・エム株式会社ソフトウェア事業 Rational テクニカルセールス＆サービス 藤井 智弘氏）を聴いた。簡単に言うと、IBMによって開発された統合開発環境のEclipseを開発したチームが使用したチームコラボレーション支援ツールを一般向けに使えるように整備するというプロジェクトの話しだ。
オブジェクト指向におけるデザインパターンの有名な本の著者 GoF (Gang of Four) の一人、Erich Gamma もこのプロジェクトにスイスから参加している。
ものすごく表面的でやじうま的な見方をすると、Microsoft が提唱した Software Factories の開発手法とまったく正反対のアプローチを IBM Rational が打ち出した・・・ように感じた。
【Microsoft の Software Factories】
Software Factories の考え方は、開発から運用までのソフトウェア・ライフサイクルの効率化を開発者の側に立って推進する「Dynamic Systems Initiative(DSI)」がベースにあって、Microsoft の戦略に乗っかるのならば、Visual Studio Team System を使っていくことになる。
どちらかと言えばトップダウンのアプローチであり、ソフトウェアプロダクトライン、ドメインエンジニアリングの考え方も踏襲されていて、非常にシステマティックだと感じるし、これまでのソフトウェアエンジニアリングの延長線上にあるように見える。
ただひとつだけ引っかかるのは、優れたアーキテクトがプロジェクト内にいない状態でSoftware Factories のアプローチを進めていくには無理があって、どうしてもやりたい場合はVisual Studio Team System を使うことで Microsoft が用意したアーキテクチャやソフトウェア資産を使うように誘導されてしまうような気がする点である。
また、Visual Studio Team System を使いこなすだけでもソフトウェアエンジニアに相当量の学習が必要がある。ある程度システムの全体構成を構築できてしまえば、その後の開発が飛躍的に効率化できるようになるものの、そこに達するまでのハードルが高いという印象がある。
【IBM Rational の Team Concert】
一方、IBM Rational Team Concert を利用した Jazz プロジェクトは、「分散」「アジャイル」「コラボレーション」といったキーワードからわかるように、どちらかと言えばボトムアップのアプローチで巨大ソフトウェアシステムの開発を成功に導こうとしている。
これまで Agaile は大規模システムへの適用は困難と見られていたが、IBM Rational Team Concert はAgaile のアプローチの人力で提唱されていた部分をすべてシステムに取り込んで、数百人の規模の開発でも、Agail の効果を最大限に引き出すことを目的にしているようだ。
実際、Eclipse の開発で成功した実績があるのだから説得力がある。
Rational Team Concert では、日々の作業はワークアイテムを中心に回っていく。ワークアイテムは「反復する計画と関連するワークアイテムの管理」「ソース管理」「ビルド」「レポート」を含む。
ある拠点に置かれた大量なトランザクションを処理できる強力なサーバー（おそらくはIBMのサーバー）を中心にして、世界中のプログラマーが WEB上のポータルサイトを共有するような感じで、プロジェクトの状況をリアルタイムに見ることができる。各人の写真も掲載され、チャットもできるし、プロジェクトリーダーやコンポーネントの責任者からの指示も共有できる。
共通環境で管理されるのはユーザー間の情報のやりとりとソースファイルであって、分散された環境でそれぞれが持っている個々の開発環境はあまり制限せずに、それらの環境への URL によるリンクのみがツール上で飛び回ることになる。
一方で、プロジェクトの状況は自動的にグラフ化され、それらのグラフを眺めることで開発の進捗を確認したり、品質を推し量ったりできる。
ソース管理に関する機能は重要視されていて、リーダーは各チームが勝手にソースをチェックイン、チェックアウトできなくすることも可能。（チームのコンテキストにより運営ルールをダイナミックに変更できるというところが Rational Team Concert が単なるコミュニケーションツールではなく、コラボレーションツールであるという理由）
【組込みで使えそうか？】
「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」の講演を聴いていておもしろかったのは、ソフトウェアシステム開発におけるアーキテクチャの話しはほどんど出てこない点だ。アーキテクチャはコンポーネントアーキテクチャだとのこと。要するにソフトウェアのモジュールをコンポーネントに分けるところまでが重要なポイントで、後は繰り返しリリースを重ねる過程で最適化していくというような考え方に聞こえた。
大人数での Agile 開発での注意点は「コミッターボード」「ガバナンス」「チェックインの制限」ということで、ソフトウェア技術者に勝手気ままにやらせない上手なコントロールをツール上で提供することだということだった。
Rational Team Concert は表面的には出てこないが、プロジェクト内に必ず優秀なアーキテクト兼プロジェクトリーダー（複数人かもしれない）が必要になる。彼または彼らが上手にプログラマー達をコントロールしてソフトウェアシステム開発を成功に導く。表面的は完璧なボトムアップアプローチだ。（表には出てこないが、プロジェクトリーダーのリアルタイムの舵取りがプロジェクトの成功の鍵を握っているため、その意味ではトップダウンとも言えるかもしれない）
Iteration（反復）を数多く繰り返すことに重きが置かれているため、もともとポテンシャルの高い技術者が参加しているのなら、プログラマとしての成長も早いだろう。
ソフトウェアエンジニアリングの歴史から考えると正反対のアプローチのように見えるが、人間工学・組織行動学的には理にかなっているように見える。
IBM Rational Team Concert 的なアプローチがいいのか、Microsoft Software Factories 的なアプローチがいいのか・・・
組込みソフトの世界なら次のようなシナリオで適用したらうまくいくような気がするのだけれどどうだろうか？
（そのドメインの制約条件を含む知識を十分に持ち合わせた優秀なアーキテクトがプロジェクト内にいると仮定して）まず、IBM Rational Team Concert で徹底的に Iteration（反復）を繰り返し、完成度の高いプロトタイプモデルを作る。次に、できあがったプロトタイプモデルのアーキテクチャとドメインの要求がどのようにすり合わされたのかを分析し、今後同様の製品群を作成するためのプロセスモデル、ドメインモデル、アーキテクチャを Visual Studio Team System を使って設計し、可視化されたモデルをレビューし洗練させる。システムの品質が担保できるようにテスト計画を立て、すでに実施されているテスト結果を利用しながらシステム全体の Verification（検証）と Validation（妥当性確認）を確立する。
個人的な感想を言うと、IBM Rational Team Concert では、開発チームのパフォーマンスは最大になるように思うが、開発チームはシステムの品質をも担保できているようには見えない。（システム品質の説明責任を果たすことが難しい） 開発のパフォーマンスを最大限に上げることでシステム品質までも凌駕してしまおうというアプローチであり、根拠ははっきりしないが実効性はあるようにも感じる。（優秀なアーキテクト兼プロジェクトリーダーの存在が必須）
一方、 Visual Studio Team System では、プロセスモデル、ドメインモデル、アーキテクチャを構築するハードルが高く、それを実現できるプロジェクトは非常に少ない。道筋がつけられるまでを外部の優秀なアーキテクトにコンサルテーションしてもらうことは可能だが、効果が現れるまで時間がかかるし、効果が現れるまでに必要な時間や費用を組織内で確保するのが難しい。
でも、どちらのアプローチにも必要なのはドメインの知識に精通したアーキテクトの存在だ。ドメインの知識に精通したアーキテクトを育てるためには、Iteration（反復）をできるだけ回した方がいいから、IBM Rational Team Concert の方を先に取り入れた方がよいかもしれない。
【参考資料】
Rational Team Concert に関して Jazzプロジェクト
Eclips （Wikipedia)
Erich Gamma（Wikipedia)
Visual Sstudio Team System に関して(Microsoft)
Software Factories に関して(@it)
0 件のコメント:
コメントを投稿