|
 |
|
|
|
 
 | レベル: |  |
 |
|
| |
|
|
Christian Buckley (buckley@redhillpartners.com)
Red Hill Partners 社長
Darren Pulsipher (darrenp@cadence.com)
Cadence Design Systems 構成管理アーキテクト

ClearCaseの導入を成功させる秘訣は、正しい質問によって得た回答を元に、計画を進めることです。本記事は、長年の経験に基づく助言とガイダンスを提供します。
あなたは頻繁に占い師を訪ねますか? 重大なソフトウェアの決断を、地元の手相占い師に託す人はあまりいないでしょう。しかし、私たちが犯す多くの「軽はずみな決定」は、近所の占い師に頼るのとさほど違いがなくありませんか?
大規模なClearCaseソリューションを実装するにあたり、時間を節約するという大義名分のために、ともすれば手を抜いていませんか?
手を抜くことは、占い師に頼るのと、どれほどの差があるでしょう? 理由付けを伺いましょう。あなたが管理しているチームのメンバーは、賢くて優秀な人員ばかりで、当然、自分たちが何を行っているかを理解しているはずですね?
ソフトウェアには、フル・バージョンのマニュアルが同梱されており、デフォルトのインストール・プロセスもごく簡単ですね?
新規ソフトウェアは、チームの既存インフラストラクチャと開発プロセスに、即座にプラグインできるはずですね?
何が起こるかは運任せという状況なので、占い師の目からあなたの選択肢を見てみましょう。一方の道は、苦難や不運、ともすれば失敗が待ち受けています。これは、貧弱なな要件定義、不適当なハンドオフや手順の定義、そして、拡張できないアーキテクチャに相当するかもしれません。もう一方の道は、厳しい仕事が待ち受けていますが、知的財産や資産を賢く管理でき、やがては成功にたどり着くでしょう。
ソフトウェア構成管理ソリューションの設計と構築を、きちんと計画せずにやり遂げようとすることは、成功を運に任せるという意味で、手相占いやタロット・カード占いに頼るようなものです。古い格言にもあるように、「計画に失敗するということは、失敗を計画するに等しい」のです。
両親や教師が説教や叱責で同じ格言を使ったときは、「ああ、またか」とうんざりしたものです。しかし私たちは、わずかな手間を省きたいばかりに、不十分に立てられた計画によって、数多くのチームとプロジェクトが被害を受けるのを目の当たりにしてきたのです。
また、こんな例えもあてはまるでしょう。長期の海外旅行をするとき、バックパックに手当たり次第にものを放り込んで、空港へ向かいますか?もちろん、そんな人はあまりいないでしょう。滞在先で何が必要か考えてみるでしょうし、持参するものをリスト・アップしてみるかもしれません。滞在期間、訪問予定の相手や環境、天候、なんらかの余暇活動などを想定して、計画を立てるはずです。その上で、靴を余分に持って行くかもしれないし、何日分かのソックスや下着も用意するでしょう。もし、最初に計画を立てなかったらどんな問題が起こるでしょうか?
旅行も4日目、行きの飛行機で着ていたのと同じ服を着て、ソックスや下着さえも換えていない状態で、シンガポールのクライアントと面談したくはないでしょう(もちろん、比喩的な意味においてですが)。
ごく簡単なことです。しっかり計画すればよい。まず初めに、すべての登場人物と、互いの関係を把握します。そして、ユース・ケースを構築し、ビジネス・ルールに適用して検証した上で、計画を立てるのです。すべては、的を絞った質問から始まります。しかし、どのような質問をすればよいか、お分かりでしょうか?
ここでの質問は、組織における長期的な計画の必要性に応えるシステムとツール・セットを構築するための第一歩となります。誰にでも「壁に突き当たる」ことはあります。したがって、このリストは、脳の歯車を回転させるための潤滑油のようなものと考えてください。まず、次の質問から始めましょう。
- プロジェクトの規模は?
これは面白い質問で、しばしば回答に窮するものでもあります。プロジェクトの規模は、どうやって判断するのでしょうか?
コードの行数、クラス数、またはファンクションポイントで決定しますか? 多くの場合は、LOC(コードの行数)を基に、プロジェクトの規模を判断します。プロジェクトのLOCは、様々な方法で見積もることができます。"A Discipline for Software Engineering"
には、Watts Humphrey氏によるいくつかの方法が掲載されています。
- 製品開発に携わるメンバー数は?
プロジェクトの規模は、作成されるコードの行数だけではなく、開発チームのメンバー数によっても左右されます。多くの場合、チームに必要なメンバー数は「推測で見積もる」ことができます。このとき、ソフトウェア開発のサポート要員(QA、プロジェクト管理者、テクニカル・ライター、マネージャーら)を忘れないようにしてください。彼らもまた、コードにアクセスする必要があり、彼らがClearCaseを使用することによって受ける恩恵は、ソフトウェア・エンジニアに勝るとも劣らないのです。
「新しいClearCase アーキテクチャなら大容量のVOBがサポートされるから、VOBのサイズを心配する必要はない」と言われる方がいらっしゃるかもしれません。しかし、巨大なVOBが可能だからといって、必ずしも巨大サイズにしなければならないわけではありません。セグメント化と複数VOBを使用した場合の利点を忘れないようにしましょう。
- 製品開発、テスト、導入を実行するサイト数は?
ここで、「1つの場所しかない」と回答した方、またはチームから中央センターにtelnetして作業を進められると考えておられる場合は、プロジェクトの規模が本当に小さいか、あるいは、抱いている構想が小さすぎると思われます。ブロードバンドが世界中に普及している今日では、多くの企業が、より安価な方法でチームの協働を図ろうとしています。各従業員グループの地理的サイトにVOBサーバを簡単に設定できる状況で、チーム全体をシリコン・バレーに移動させるのは高くつきます。製品のテストや開発を海外で手掛けている場合もあります。開発サイト数と各サイトでの作業内容は、VOBアーキテクチャ、トリガー、サード・パーティー製ツールとの統合において重要な役割を果たします。
- 社内向け製品か、社外向け製品か?
社外向け製品の場合、どのような方法でリリースする予定ですか? CDですか?
インターネットでのダウンロードですか? あるいはサービスを提供するのでしょうか?VOBを用いてリリース管理を行えますか?
どれくらいの頻度で顧客に製品をリリースする必要がありますか? 製品は顧客先で極めて重要な役割を果たすものですか?
社内製品の場合は、通常の社外顧客相手の問題に加えて、社内での統合という問題に対処しなければなりません。別のチームが、あなたのプロジェクトを使用して製品を開発する予定がありますか?そのチームではClearCaseを使用していますか?(理想的には、全員がClearCaseを使用していることが望ましい)そのチームは、あなたのチームからのリリースを、どれぐらいの頻度で入手できますか?どのような種類の調整を提供する必要がありますか?
- 使用予定のサード・パーティー・ツールは?
サード・パーティー製のツールをいくつ使用する予定ですか?開発チーム(上記で触れたサポート要員を含むチーム)で使用予定のすべてのサード・パーティー・ツールのリストを作成します。プロジェクト管理、テスト、テクニカル・ライターによる作業を忘れないでください。これらのツールにあわせたVOB戦略を立てておくとよいでしょう。これには、OSパッチや、コンパイラ、Quantify、Purify、FrameMaker、MSWordなどが含まれます。5年以上も前の重要製品のパッチに何週間も費やせねばならない上に、構築やテスト、ドキュメンテーションのためのあらゆるツールにアクセスできないことほど厄介なことはありません。
- 製品の開発サイクルは?
従来のウォーターフォール型で製品を開発する予定ですか?サイクル・タイムはインターネット向け(3ヶ月)またはテレコム向け(7年)のどちらですか?これは、VOBのレイアウト方法で重要な要因となります。VOBやClearCaseのせいで開発が滞るのではなく、実際の作業を迅速に進められるようにしたいものです。しっかりした計画があれば、トリガーを用いてポリシーを実施し、通常は手動で行う操作を自動化することができます。
開発サイクルに関する上の質問に答えられない場合は、Rational Unified Processを参考にしてください。なんらかの方向性が得られるはずです。
- 現在の開発方法論は、ツール計画にふさわしいか?
手持ちのツール・セットに合わせてプロセス自体を変更しているグループが数多くあります。しかし、このやり方は、管理手続き上、支障をきたす恐れがあります。誰が開始したのかわからないプロセスがあったり、何のためのプロセスかわからないという事態が起こりかねません。誰が作成または開始したのかわからないプロセスを回避するために作成されたプロセスさえあります。多くの場合、このような事態は、チームが使用しているツールが不十分であるために起こることです。方法論に適った正しいツールを見つけることが重要です。今日のツールのほとんどは、柔軟でカスタマイズ可能であり、あらゆるプロセスを処理できるようになっています。
- 重要な役割をチームに入れ忘れていないか?
開発チームに必要なすべてのメンバーが含まれていることを確認する必要があります。いくつかのシナリオについて熟考してください。製品開発に携わる主要メンバーのリストには載っていない人物から、プロジェクトについて最近尋ねられませんでしたか?
彼らの役割は何でしたか? この人物をチームに加えるべきでしょうか? 複数のサイトで作業している場合、全サイト間のミーティングを調整している人物は誰ですか?
マルチ・サイト管理者は誰ですか? 顧客がClearCase リリース VOBにアクセスする必要はありますか?
すべてのメンバーを書き出してみてください。
- 必要なハードウェアが揃っているか?
ハードウェアぬきで、開発環境とClearCaseを導入することは非常に困難です。不可能ではありませんが、自分のVOBサーバが他のユーザーのデスクトップ・マシン上にあるというのでは困ります。省エネのため、清掃員によって夜中にコンピュータの電源が落とされたり、経費節約のため、週末は会社のエアコンが切られるということも起こりかねません。こうなったら、一大事です。必要なハードウェアが揃っていることを事前に確認してください。開始時点で正しく実行する方が、後で修正するよりずっと簡単なのです。
- 計画をサポートするインフラストラクチャが整っているか?
忘れられがちな項目として、開発計画をサポートするインフラストラクチャがあります。適切な開発環境には、エアコンや電源、フロア・スペース、ネットワークが確実に整っていることを確認する必要があります。サーキット・ブレーカーを落とさないように、一定の順序でマシンをブートする必要があるような環境なら、明らかにもっと電源が必要です。コンピュータの過熱を防ぐため、Kmartで購入した12ドル99セントの「ブルーライト」扇風機が必要なら、エアコンを増やす必要があります。さらに、複数サイトで開発を進めている場合は、すべてのサイトへのアクセスを確保する必要があります(この一見ささいな、アクセス可能性というようなことが、後に問題となることが多いのです)。そして、最も困難なタスクが、インフラ整備のための投資を促すことです。事前にしっかりと用意し、プロジェクトを正しく計画しておけば、必要経費も重役陣に容易に認めさせることができるはずです。
要はいたって簡単なことです。ClearCaseを正しく導入するには、そのための準備が重要なのです。正しい質問をすること、正しい要件を収集すること、必要なすべてのツールとプロセスへのアクセスを確保すること。これで完了です。
VOBとClearCase環境の設定方法を知ることは、製品の将来を予測する必要があるという意味で、将来を見通そうとしているようなものかもしれません。しかし、あなたの人生についてまったく根拠のない助言をする電話占い師とは異なり、ここで、あなた自身が質問をし、回答に基づいて重要な決断を下さなければなりません。
製品開発に携わるメンバー数は?
開始当初は、占い師に頼っているかのような心もとない努力が数多くあるものですが、これらの質問に回答することにより、プロジェクトは自己達成的な予言となります。正しく計画することにより、「予想」に頼ることも少なくなり、リスクを大幅に軽減できるようになります。
ClearCaseの公開で開発を推し進めようとしている方には、次回以降の記事が参考になるはずです。ClearCaseの導入で重要となる以下のようなトピックを取り上げる予定です。
- 入出力 - ClearCaseの導入に関するユース・ケース分析
- VOBアーキテクチャ
- トリガー戦略(セキュリティーと整合性)
- 統合点(ClearQuest、間接部門システム、プロジェクト管理ツール)
- 立ち上げ/トレーニング戦略
賢い導入とは、すなわち、確実なリスク管理のことです。正しく計画すればリスクが軽減します。強力なソース・コード管理システムの正しい計画は、他方面のプラクティスにもつながります。開発マシンを駆動する強力なツール・セットとプロセスがあれば、開発チームも、より精密で論理的な開発計画を立てることができます。そして結果として、より良い製品を作ることができるのです。
こんな風に考えてみてください。学生時代、宿題をするとき、散らかった部屋でやった場合と、上から下まできれいに片付いている部屋でやった場合、何か違いませんでしたか?
臨床研究により、きれいに片付いている環境で学ぶ学生は、散らかった環境の学生よりも優秀な成績を修める傾向にあることが分かっています。あなたの作業環境の場合も同じです。
あなたのオフィスはきれいに片付いていますか?

著者について
|
|
|
|
|