要件を理解する
これは、ソフトウェアの設計または開発を始める前の最初のステップです。多くの場合、プロジェクトの要件を理解するためには、当初の想定範囲を超えて多くのオプションを考え出したり検討したりすることが必要になってきます。さまざまな役割と責任を理解し、すべての人の時間に価値を置くことが重要です。
会議を最大限に活用する
無駄な時間を減らし、会議を最大限に活用するためのヒントを以下に示します。
- 明確な議題を設定する（会議で決定すべき内容をあらかじめ明確にしておく）。
- 複数の議題を長時間にわたって検討するよりも、特定の議題を取り上げる短時間の会議を何回か行う。
- すべての関係者を参加させようとしない（必要な参加者が不明な場合は、マネージャや上司に相談する）。可能な場合には、特定の議題について異なる顔ぶれで何回か会議を行う方が生産的である。
- 議題に関する質問や検討事項の一覧を用意し、チーム全員に流しておく（詳細については会議で議論することを明記し、電子メールの返信が無限に続く事態を避ける）。
- 事前に必要なプレゼンテーション/ドキュメントファイルを配る（通常は行わない）。
- すべてのメンバが事前にドキュメントを読んでいるものとは想定しない。全員が同じページを目にするように、簡単なウォークスルーを行うとよい（議題に関係ない話に時間を費やさないようにする。時間をかけて検討すべき事項がある場合は、その事項に関係するメンバだけを集めて会議を再設定する）。
- すべてのメンバが議題と状況を理解したら、問題の検討に進み、結論を出す。
- 1回の会議ですべての問題を解決しようとしない。会議とブレーンストーミングセッションの違いを意識する。
- 議事録を送付して、すべてのメンバに共通の理解を持たせる。会議中に「この件は私がやりましょうか」と発言する人がいても、本当にその人にその意志（または責任）があるということにはならない。解決済みの問題（合意の上での解決）、および未解決の問題と担当者を明確にしておくとよい。
WHAT、WHEN、HOW、WHOの違いを理解する
要件に関する情報を収集するために話をしていると、要件が何（WHAT）であるかを十分に理解せずに、話がその方法（HOW）に終始してしまう人がよくいます。
WHAT： 営業チームが、要件の内容を定義します（この時点では、WHEN、HOW、WHOの詳細は問題ではありません）。プロジェクトのWHAT部分を明確にすることは難しい作業であり、場合によってはプロジェクトマネージャや技術チームによる突っ込んだ質問が必要です。
WHEN： 営業チームが、市場リリースなどに向けて何がいつ必要となるかを決定します。技術系メンバは熱心さのあまり、WHEN、HOW、WHOの詳細事項についての前提をまとめるときに、すぐにYESまたはNOの答えを出すことができません。さまざまな方法でWHAT部分を複数のフェーズに切り分け、より現実的な観点からWHEN部分を満たす方法を検討します。
HOW： この分野は技術チームが定義します。これは技術的な分野であり、営業チームやプロジェクトマネージャは口を挟まないことが望まれます。営業系メンバには、HOW部分を伝えないのが良いでしょう。
WHO： プロジェクトマネージャが、誰が何を行うかを決定します。ただし、アーキテクト/チームリーダーは、特定の業務に対して誰が適任であるかについて、フィードバックを返すことができます。
実際問題として、WHAT、WHEN、HOW、WHOはすべてが少しずつ依存し、関連しています。持っているものを最大限活用して目的のものを得るためには、プロジェクトの初期段階でこれらをある程度分けて扱うとよいでしょう。
見積もり
プロジェクトマネージャは、技術チームの支援を受けて、最適な費用/時間の見積もりおよびリソース要件を練り上げます。
設計フェーズ
設計段階で問題を修正できれば、時間の節約になり、作業のやり直しの手間を省くことができます。
- 現状で再利用できるツール/インフラストラクチャを把握します。
- さまざまな経歴や経験を持つメンバを設計のレビューに参加させて、現在の設計では十分に考慮されていない、または対応されていない問題を確認します。
- 設計レビュー/ブレーンストーミングセッションは、設計の重大な不具合を見つけ、早期に修正するのに役立ちます。
設計レビュー
設計レビューで確認する重要なポイントを以下に示します。
- 設計がすべての要件を満たしているか。
- 設計が拡張可能で柔軟性に優れていて、変更に対応できるか。
- 設計が複雑な問題を単純な方法（または適度に単純な方法）で解決しているか。単純な問題を複雑な方法で解決していないかに注意します。
- 設計がアカウントの配備、運用環境、および構成を考慮しているか。
- 共通のインフラストラクチャに取り出せる汎用的なモジュールはないか。これは、コードレビュー時ではなく、設計フェーズで特定する必要があります。
開発フェーズ
すべての開発者は次の重要ポイントを理解し、実際に従う必要があります。
- 開発者は、ツール/テクノロジを十分に理解して、利点、欠点、およびツール/テクノロジの推奨方法をすべて把握している必要があります。
- 開発者が旧バージョンで作業していた場合は、新バージョンとの違い、および新バージョンの新機能を理解することが重要です。新バージョンが特定のタスクに対して、より適切な実装をサポートしている場合は、旧バージョンで使用していた手段や方法をそのまま使用してもコーディングの役に立ちません。
- プロジェクトの生産性向上に貢献するツール/テクノロジの新バージョンの有無を確認します。
- 新しいツール/テクノロジを使用できない場合は、その理由を必ずチームに尋ねます。もちろん、まず新しいツール/テクノロジを使用する理由を理解することが重要です。個人的な興味から新しいテクノロジを使用するのではなく、プロジェクトにとってどのようなメリットがあるかを確認することが重要です。
コードレビュー
多くの人は、コードレビューをプレッシャーあるいは開発者間の仕事上の関係を危うくするものと考えています。実際のところ、彼らは多くのバグ、安定性の問題、機能の不備といった危険をプロジェクトにもたらしています。開発者は、締め切りに間に合うように慌しく大量のソフトウェアを作成しています。スキルレベルは開発者によってさまざまで、ソフトウェア開発の経験が短い人もいれば、初めての人もいます。私は、コードの整合性と安定性を実現する最良の方法は、コードレビューにあると考えます。コードレビューによって、スキル不足の開発者や、場合によってはスキルが豊富な開発者であっても、新しい手法を学習することができます。
コードレビューでは、次のことを確認します。
- コード全般が合意された開発標準/ガイドラインに順守しているか。
- コードに潜在的な問題がないか。
- ツール/インフラストラクチャが単純な方法をサポートしているのに不必要に複雑な方法を使っていないか。
- オブジェクト指向で、再利用可能かつコンパクトなコードになっているか（多数の関数を含む長いファイルは危険信号）。
- 明文化されていない前提に基づくハードコーディングや固定コーディングが行われていないか。
品質保証（QA）
多くの場合、技術チームとQAチームは切り離されていますが、興味深いことに、開発者はQA環境を管理したがります。私は、これを切り離すべきだと考えます。開発とQA環境は分離して、QAチームだけがQA環境にアクセスできることが必要です。そのためには、開発者は、エンドカスタマーにコードを配布/配備するのと同じ方法で、コードをパッケージ化し、配布する必要があります。この方法によって、すべての配備/配布オプションを前もって検討し、実際のリリースに先立ち、それらをテストすることもできます。開発チームはすべての主要な会議にQAチームも参加させて、重要な決定や方針を早期に理解させる必要があります。
QAチームにとって必要な詳細情報は、次のとおりです。
- エンドユーザーのシステム使用方法についての前提
- 一般的なエンドユーザーのワークフロー（大部分は、営業チームが提供するユースケースに基づく）
- 開発者が提供する機能および期待されるその動作（技術チームが提供）
- 提供されるインターフェイスおよび推定されるその使用方法（営業チームと技術チームがUIプロトタイプを提供）
- ソフトウェアのインストールおよびテストで必要な環境
- テストを自動化できるツール
- バグを追跡できるツール
- 特定のモジュールの担当者（特定の問題について詳細な情報が必要な場合）
QAチームは上記のすべての詳細情報に基づき、ソフトウェアがテスト可能な状態になるまでに、前もって計画を立てテストケースを用意します。
ソフトウェアの配備
設計の段階から、配備に取り組むことが重要です。多くの会社では、運用環境にインストールできる人物や、その人物が手動で実行できる操作は制限されています。そのため、一部の会社などでは単にzipファイルとスクリプトを提供してデータベースをインストールする方法がうまくいく場合もありますが、顧客に出荷される製品では、この方法は機能しません。このことを前もって考慮することで、配備用のパッケージを作成し、それをテストする時間を確実に確保できます。また、プロジェクトマネージャも、特定のリソースを見つけ、時間と予算を割り当てて配備固有の作業を実行することができます。
プロセスインフラストラクチャ用のツールとテクノロジ
概念の説明ばかりしていても意味がないので、今度はこれらの問題を解決するのに便利なツールを示します。ここでは、オープンソースの分野のツール/テクノロジと、Microsoftから提供されているツール/テクノロジを示します。特にMicrosoft Visual Studio 2005には、開発者がベストプラクティスを順守するために役立つ便利な機能が数多く用意されています。
プロセスインフラストラクチャの主要な要素は、次のとおりです。
- 中央ドキュメントリポジトリ ― チーム全体のプロジェクトドキュメントを保存、共有します。
- ソースバージョン管理システム ― プロジェクトのソースコードを保存、共有します。
- 問題/バグ追跡システム ― 未解決の問題/要求/バグを追跡します。
- 開発用のIDE（統合開発環境）ツール
- 自動テストツール ― QAチームが開発したテストケースを自動化します。
- 自動ビルドツール ― ビルドプロセスを自動化します。
- 開発者用の単体テストツール ― 単体テストを作成します。
- パフォーマンスチューニング/デバッグツール
オープンソースソリューション
上記の要件を満たすオープンソース分野のツールを、以下に示します。
| カテゴリ | ツール/テクノロジ |
| 中央ドキュメントリポジトリ | オープンソースのドキュメントリポジトリがいくつかあるのは知っていますが、私は自分で使用したことがないので、読者が自分でGoogle検索して、ニーズに適したものを見つけることをお勧めします。 |
| ソースバージョン管理システム | http://www.wincvs.org/ （使用しているIDEツールに適切に統合されるソースセーフ管理ステムを推奨） |
| 問題/バグ追跡システム | http://www.bugzilla.org/ http://www.gotocode.com/apps.asp?app_id=1 （私はかつてオープンソースのバグ追跡システムを使用していましたが、上記のシステムではありませんでした。自分自身で評価してください） |
| 自動ビルド/テストツール | http://cruisecontrol.sourceforge.net/ http://sourceforge.net/projects/nant/ |
| 単体テスト | http://www.nunit.org/ |
Microsoft固有のツール/テクノロジ
| カテゴリ | ツール/テクノロジ |
| 中央ドキュメントリポジトリ | Microsoft SharePoint http://www.microsoft.com/sharepoint/default.mspx |
| ソースバージョン管理システム | Visual Studio Team Suite Visual Source Safe |
| 問題/バグ追跡システム | Visual Studio Team Suite |
| 自動ビルド/テストツール | Visual Studio Team Suite/ MS Build |
| 単体テスト | Visual Studio Team Suite |
| パフォーマンス/プロファイリングツール | Visual Studio Team Suite |
以下はVisual Studio 2005のアドオンで、開発者がベストプラクティスに従うことを支援します。
- VS 2005のコードリファクタリング機能
- Guidance Automation Toolkit
- Smart Client Factory
- CABおよびEnterprise Library Application Blocks（2.0）
まとめ
本稿は、プロジェクト管理やソフトウェア開発ライフサイクルについて説明するものではありません。初心者の開発者およびプロジェクトマネージャに、プロセス指向開発の利点を説明することが主な目的です。本稿で説明したソフトウェア開発ライフサイクルのさまざまなフェーズについてのガイドラインが、それぞれの会社のニーズに合ったプロセスを定義する上で参考になれば幸いです。
本稿を執筆する上で私をサポートしてくれた妻のSheela Tallamrajuに感謝の意を表します。
