プロセス指向のソフトウェア開発

はじめに

　近頃流行のキーワードは「サービス指向」であり、開発の現場でもその方式が主流になりつつあります。ですが、今回はあえて「プロセス指向」を取り上げてみます。ソフトウェア開発のライフサイクルに関わったことがある人ならば、おそらくその理由もお分かりではないかと思います。プロセス指向の重要性がわからないという人でも、本稿を読めば、開発プロセスをスムーズに進める上でのヒントが得られることでしょう。

　ソフトウェアの開発は、難しい作業ではありません。開発者の学歴など関係ありません。コードを書くのはきわめて簡単であり、簡単な概念と構文を理解すれば、ソフトウェアのコードをすぐに書き始めることができます。他のエンジニアリング分野とは違って、基本的なトレーニングを受ければ、ソフトウェアの仕事は簡単に手に入り、それなりに稼ぐことができます。

　上で述べたことは基本的に真実ですが、だからと言って、初心者がすぐに優れたコードを書けるわけではありません。良いコードと悪いコードの間には、多くの違いがあります。それは、優れた設計と優れた土台で家を建てるのと、単にブロックを積み重ねて家の形を作るような違いです。残念ながら、家を建てるときと同じくらいの慎重さでソフトウェアを作成する人はあまりいません。これには、次のような理由が考えられます。

• 誰がどれほど品質の低いコードを作成しても、他の人を傷つけるわけではない（少なくとも、大半のソフトウェアプロジェクトの場合）
• 中心となる標準委員会（またはそれに相当する会社）によって適用される規則/規定/標準がない

　私個人としては、このような標準や倫理の欠落が他の分野であまり見られないことにほっとしています。良いRDMBS設計や良いコーディング標準、オブジェクト指向設計、デザインパターンに関して書いた本は多々ありますが、これらはただの本にすぎず、品質の低いコード（およびその作成者）の誕生を現実的に阻止できるわけではありません。品質の低いコードや不適切なプラクティスを防止して開発者の生産性を最大限に高めるための絶対確実なシステムがあればいいのですが、残念ながらいまだ目にしたことはありません。

　ここで、コーディングから少し離れて、ソフトウェアの外側の実際の世界に目を向けてみましょう。私は、自分が生活している世界において、常に最高の状態を期待しています。例えば、高速道路を運転するときはきれいに整備された道路を期待しますし、大型画面のテレビを買うときには画面の傷やボタンの欠損は許されません。お金を払うからには、最高の製品やサービスを求めます。

　では、ソフトウェア業界に話を戻しましょう。私は、コードのバグを無料で修正すると申し出たことなどありません。会社は私に給料を支払い、妥当な期間内に高品質のコードを作成するよう要求します。しかし、私の人生にはやるべきことがいくつもあり、ソフトウェア開発は私にとってそれほど優先順位の高い仕事ではなく、定期的な収入を得るために行っているにすぎません。私は、自分のコードがレビューに送られたり、自分のコードのバグが他人に発見されたりすると腹立たしい気持ちになります。私がこれまでに読んだ経営管理に関する本の多くは、「他人の過ちを許し、他人を非難しないこと」と述べていて、私もその意見に賛成です。レビュー担当者やバグを見つける人たちは、その人たちのスキルで改善を施せばよいわけで、何も開発者をイライラさせるようなことをしなくてもいいじゃないかと思うのです。言ってみれば「他人には最高のものを要求し、自分はできるときにできることだけをする」というダブルスタンダードですが、それが悪いとも思いません。今の雇い主のところで週30時間も働くのは働きすぎだ、と思うことすらあります。私はC++もHTMLもJavaもよく知っているので、今の景気とMonster.comがあればいつでも簡単に別の仕事を見つけられるはずです。

　以前の私は、すべての開発者が自分と同じように考えていると思っていました。しかしあるとき、自分とは異なる種類の開発者――自分の仕事に熱心に取り組み、期待されている以上のものを常に提供している人々――に出会いました。彼らは「与える者」であり、世の中に変化をもたらす人々です。彼らは、単に好きだからという理由で仕事をしているのであり、お金はそれに付随するものにすぎないのです。彼らのおかげで、私は自分の好きなことをすべきであるということ、そして自分が他人に求めるのと同じサービスを提供すべきであるということを悟りました。このことは、私のソフトウェア開発の方法と考え方に重大な影響を与えました。本稿では、彼らが私のような開発者に与えてくれたヒントを皆さんにも紹介したいと思います。これが多少なりともソフトウェア開発の世界を良い方向に変えていくための一助になれば幸いです。

プロセス指向の実践

　日常生活では、一定の方法で行うことが数多くあります。車を運転する場合は、赤信号や一時停止標識で停止します。親切な人ならば、歩行者が渡るのを待ったり、別の車線の車に道を譲ることもあるでしょう。日常生活の中で行う多くのことは、他人の行為に基づいており、それに気を配ります。規則が守られていない場合は、当局が登場して強制します。このようなプロセスが作られているのは、我々が混乱なく一緒に働き、生活するためと言えます。

　「プロセス」はきわめて一般的な言葉ですが、本稿で「プロセス」または「プロセス指向」という言葉が出てきたときは、ソフトウェア開発における意味合いで使っているとお考えください。

プロセス指向開発とは

　「プロセス指向開発」とは、すべてのチームメンバが定性的、定量的、かつ一貫した成果物を生み出せるようにするための一連のプロセス、ガイドライン、およびサポートインフラストラクチャのことです。

プロセス指向の利点

　プロセス指向を実践すると、仕事にかかわるチームのすべてのメンバから、同程度の一貫性、品質、および生産性を引き出すことができます。適切に定義されたプロセスを実施することで、チームの新メンバやスキル不足のチームメンバに作業を引き継ぐ必要がある場合でも、移行に要する時間が短くて済みます。

プロセス指向に当てはまらないもの

• チームの創造性の柔軟性を奪ったり、制限するものではありません。
• UMLを使用したり、ガイドラインを作成するものではありません（場合によっては、その一部がプロセスに含まれることもあります）。
• すべてのケースに対応することはできません。会社/プロジェクトの要件や状況はそれぞれ異なるため、誰もが従うことができる1つのプロセスガイドラインを作成することは賢明ではなく、現実的でもありません。
• 多くのドキュメントや、実際には誰も守ることができない大量の規則を作り出すものではありません。

プロセス指向のイニシアチブ

　プロジェクトマネージャ、アーキテクト、および技術チームリーダー/マネージャは、イニシアチブをとり、次のものを用意する必要があります。

• ソフトウェア開発のすべてのアクティビティが従う必要があるプロセス。
• 定義されたプロセスの高速化と実装ならびに停止時間の短縮化に役立つツールやインフラストラクチャの識別。
• 従うべきプロセスと基本原則をチーム全員に理解させるためのトレーニング。
• プロセスの実装/実行における、各チームメンバの責任の所在の明確な定義。
• プロセスガイドラインを定義する上での重要な要因は、何をすることが会社/チーム/プロジェクトのためになるかを十分に理解することです（すべての要件とタイムラインを考慮します）。

プロセス指向に関するヒント

　本稿で紹介する方法は現実的でない、と多くの人は主張するでしょう。しかしこの手の反論をする人は、大抵の場合、仕事のやり方がめちゃくちゃだとか、無駄な作業が多いとか、標準が決まっていないとか一貫性がないという不平を述べているのと同じ人です。私はいつも、このような不平を言う人には、こうした問題を解決し、他のチームメンバを教育するための計画を立てるようお勧めしています。同じような問題が時々発生する場合には、事前に定義しておいた方法に従うようにチームをトレーニングし、ドキュメントを整備しておくことが有効です。これは、プロセスを定義し、すべてのチームメンバにプロセスを理解させることにほかなりません。

　以降では、ソフトウェア開発についてあまり知らない方を念頭に置いて、いくつかのヒントを示します。この説明は、すべての責任と注目を引き受けているように見える（事態が悪い方向に進んでいるときはなおさら）哀れな開発者を対象とするものではありません。とはいえ、これから紹介するヒントは、ソフトウェア開発のライフサイクルにかかわるすべての人にとって役立ちます。プロジェクト管理の担当者にとって役立つ情報もあれば、技術チームにとって有益な情報もあります。

要件を理解する

　これは、ソフトウェアの設計または開発を始める前の最初のステップです。多くの場合、プロジェクトの要件を理解するためには、当初の想定範囲を超えて多くのオプションを考え出したり検討したりすることが必要になってきます。さまざまな役割と責任を理解し、すべての人の時間に価値を置くことが重要です。

会議を最大限に活用する

　無駄な時間を減らし、会議を最大限に活用するためのヒントを以下に示します。

• 明確な議題を設定する（会議で決定すべき内容をあらかじめ明確にしておく）。
• 複数の議題を長時間にわたって検討するよりも、特定の議題を取り上げる短時間の会議を何回か行う。
• すべての関係者を参加させようとしない（必要な参加者が不明な場合は、マネージャや上司に相談する）。可能な場合には、特定の議題について異なる顔ぶれで何回か会議を行う方が生産的である。
• 議題に関する質問や検討事項の一覧を用意し、チーム全員に流しておく（詳細については会議で議論することを明記し、電子メールの返信が無限に続く事態を避ける）。
• 事前に必要なプレゼンテーション/ドキュメントファイルを配る（通常は行わない）。
• すべてのメンバが事前にドキュメントを読んでいるものとは想定しない。全員が同じページを目にするように、簡単なウォークスルーを行うとよい（議題に関係ない話に時間を費やさないようにする。時間をかけて検討すべき事項がある場合は、その事項に関係するメンバだけを集めて会議を再設定する）。
• すべてのメンバが議題と状況を理解したら、問題の検討に進み、結論を出す。
• 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には、開発者がベストプラクティスを順守するために役立つ便利な機能が数多く用意されています。

　プロセスインフラストラクチャの主要な要素は、次のとおりです。

1. 中央ドキュメントリポジトリ ― チーム全体のプロジェクトドキュメントを保存、共有します。
2. ソースバージョン管理システム ― プロジェクトのソースコードを保存、共有します。
3. 問題/バグ追跡システム ― 未解決の問題/要求/バグを追跡します。
4. 開発用のIDE（統合開発環境）ツール
5. 自動テストツール ― QAチームが開発したテストケースを自動化します。
6. 自動ビルドツール ― ビルドプロセスを自動化します。
7. 開発者用の単体テストツール ― 単体テストを作成します。
8. パフォーマンスチューニング/デバッグツール

オープンソースソリューション

　上記の要件を満たすオープンソース分野のツールを、以下に示します。

Microsoft固有のツール/テクノロジ

　以下はVisual Studio 2005のアドオンで、開発者がベストプラクティスに従うことを支援します。

• VS 2005のコードリファクタリング機能
• Guidance Automation Toolkit
• Smart Client Factory
• CABおよびEnterprise Library Application Blocks（2.0）

まとめ

　本稿は、プロジェクト管理やソフトウェア開発ライフサイクルについて説明するものではありません。初心者の開発者およびプロジェクトマネージャに、プロセス指向開発の利点を説明することが主な目的です。本稿で説明したソフトウェア開発ライフサイクルのさまざまなフェーズについてのガイドラインが、それぞれの会社のニーズに合ったプロセスを定義する上で参考になれば幸いです。

　本稿を執筆する上で私をサポートしてくれた妻のSheela Tallamrajuに感謝の意を表します。