はじめに
近頃流行のキーワードは「サービス指向」であり、開発の現場でもその方式が主流になりつつあります。ですが、今回はあえて「プロセス指向」を取り上げてみます。ソフトウェア開発のライフサイクルに関わったことがある人ならば、おそらくその理由もお分かりではないかと思います。プロセス指向の重要性がわからないという人でも、本稿を読めば、開発プロセスをスムーズに進める上でのヒントが得られることでしょう。
ソフトウェアの開発は、難しい作業ではありません。開発者の学歴など関係ありません。コードを書くのはきわめて簡単であり、簡単な概念と構文を理解すれば、ソフトウェアのコードをすぐに書き始めることができます。他のエンジニアリング分野とは違って、基本的なトレーニングを受ければ、ソフトウェアの仕事は簡単に手に入り、それなりに稼ぐことができます。
上で述べたことは基本的に真実ですが、だからと言って、初心者がすぐに優れたコードを書けるわけではありません。良いコードと悪いコードの間には、多くの違いがあります。それは、優れた設計と優れた土台で家を建てるのと、単にブロックを積み重ねて家の形を作るような違いです。残念ながら、家を建てるときと同じくらいの慎重さでソフトウェアを作成する人はあまりいません。これには、次のような理由が考えられます。
- 誰がどれほど品質の低いコードを作成しても、他の人を傷つけるわけではない（少なくとも、大半のソフトウェアプロジェクトの場合）
- 中心となる標準委員会（またはそれに相当する会社）によって適用される規則/規定/標準がない
私個人としては、このような標準や倫理の欠落が他の分野であまり見られないことにほっとしています。良いRDMBS設計や良いコーディング標準、オブジェクト指向設計、デザインパターンに関して書いた本は多々ありますが、これらはただの本にすぎず、品質の低いコード（およびその作成者）の誕生を現実的に阻止できるわけではありません。品質の低いコードや不適切なプラクティスを防止して開発者の生産性を最大限に高めるための絶対確実なシステムがあればいいのですが、残念ながらいまだ目にしたことはありません。
ここで、コーディングから少し離れて、ソフトウェアの外側の実際の世界に目を向けてみましょう。私は、自分が生活している世界において、常に最高の状態を期待しています。例えば、高速道路を運転するときはきれいに整備された道路を期待しますし、大型画面のテレビを買うときには画面の傷やボタンの欠損は許されません。お金を払うからには、最高の製品やサービスを求めます。
では、ソフトウェア業界に話を戻しましょう。私は、コードのバグを無料で修正すると申し出たことなどありません。会社は私に給料を支払い、妥当な期間内に高品質のコードを作成するよう要求します。しかし、私の人生にはやるべきことがいくつもあり、ソフトウェア開発は私にとってそれほど優先順位の高い仕事ではなく、定期的な収入を得るために行っているにすぎません。私は、自分のコードがレビューに送られたり、自分のコードのバグが他人に発見されたりすると腹立たしい気持ちになります。私がこれまでに読んだ経営管理に関する本の多くは、「他人の過ちを許し、他人を非難しないこと」と述べていて、私もその意見に賛成です。レビュー担当者やバグを見つける人たちは、その人たちのスキルで改善を施せばよいわけで、何も開発者をイライラさせるようなことをしなくてもいいじゃないかと思うのです。言ってみれば「他人には最高のものを要求し、自分はできるときにできることだけをする」というダブルスタンダードですが、それが悪いとも思いません。今の雇い主のところで週30時間も働くのは働きすぎだ、と思うことすらあります。私はC++もHTMLもJavaもよく知っているので、今の景気とMonster.comがあればいつでも簡単に別の仕事を見つけられるはずです。
以前の私は、すべての開発者が自分と同じように考えていると思っていました。しかしあるとき、自分とは異なる種類の開発者――自分の仕事に熱心に取り組み、期待されている以上のものを常に提供している人々――に出会いました。彼らは「与える者」であり、世の中に変化をもたらす人々です。彼らは、単に好きだからという理由で仕事をしているのであり、お金はそれに付随するものにすぎないのです。彼らのおかげで、私は自分の好きなことをすべきであるということ、そして自分が他人に求めるのと同じサービスを提供すべきであるということを悟りました。このことは、私のソフトウェア開発の方法と考え方に重大な影響を与えました。本稿では、彼らが私のような開発者に与えてくれたヒントを皆さんにも紹介したいと思います。これが多少なりともソフトウェア開発の世界を良い方向に変えていくための一助になれば幸いです。
プロセス指向の実践
日常生活では、一定の方法で行うことが数多くあります。車を運転する場合は、赤信号や一時停止標識で停止します。親切な人ならば、歩行者が渡るのを待ったり、別の車線の車に道を譲ることもあるでしょう。日常生活の中で行う多くのことは、他人の行為に基づいており、それに気を配ります。規則が守られていない場合は、当局が登場して強制します。このようなプロセスが作られているのは、我々が混乱なく一緒に働き、生活するためと言えます。
「プロセス」はきわめて一般的な言葉ですが、本稿で「プロセス」または「プロセス指向」という言葉が出てきたときは、ソフトウェア開発における意味合いで使っているとお考えください。
プロセス指向開発とは
「プロセス指向開発」とは、すべてのチームメンバが定性的、定量的、かつ一貫した成果物を生み出せるようにするための一連のプロセス、ガイドライン、およびサポートインフラストラクチャのことです。
プロセス指向の利点
プロセス指向を実践すると、仕事にかかわるチームのすべてのメンバから、同程度の一貫性、品質、および生産性を引き出すことができます。適切に定義されたプロセスを実施することで、チームの新メンバやスキル不足のチームメンバに作業を引き継ぐ必要がある場合でも、移行に要する時間が短くて済みます。
プロセス指向に当てはまらないもの
- チームの創造性の柔軟性を奪ったり、制限するものではありません。
- UMLを使用したり、ガイドラインを作成するものではありません（場合によっては、その一部がプロセスに含まれることもあります）。
- すべてのケースに対応することはできません。会社/プロジェクトの要件や状況はそれぞれ異なるため、誰もが従うことができる1つのプロセスガイドラインを作成することは賢明ではなく、現実的でもありません。
- 多くのドキュメントや、実際には誰も守ることができない大量の規則を作り出すものではありません。
プロセス指向のイニシアチブ
プロジェクトマネージャ、アーキテクト、および技術チームリーダー/マネージャは、イニシアチブをとり、次のものを用意する必要があります。
- ソフトウェア開発のすべてのアクティビティが従う必要があるプロセス。
- 定義されたプロセスの高速化と実装ならびに停止時間の短縮化に役立つツールやインフラストラクチャの識別。
- 従うべきプロセスと基本原則をチーム全員に理解させるためのトレーニング。
- プロセスの実装/実行における、各チームメンバの責任の所在の明確な定義。
- プロセスガイドラインを定義する上での重要な要因は、何をすることが会社/チーム/プロジェクトのためになるかを十分に理解することです（すべての要件とタイムラインを考慮します）。
プロセス指向に関するヒント
本稿で紹介する方法は現実的でない、と多くの人は主張するでしょう。しかしこの手の反論をする人は、大抵の場合、仕事のやり方がめちゃくちゃだとか、無駄な作業が多いとか、標準が決まっていないとか一貫性がないという不平を述べているのと同じ人です。私はいつも、このような不平を言う人には、こうした問題を解決し、他のチームメンバを教育するための計画を立てるようお勧めしています。同じような問題が時々発生する場合には、事前に定義しておいた方法に従うようにチームをトレーニングし、ドキュメントを整備しておくことが有効です。これは、プロセスを定義し、すべてのチームメンバにプロセスを理解させることにほかなりません。
以降では、ソフトウェア開発についてあまり知らない方を念頭に置いて、いくつかのヒントを示します。この説明は、すべての責任と注目を引き受けているように見える（事態が悪い方向に進んでいるときはなおさら）哀れな開発者を対象とするものではありません。とはいえ、これから紹介するヒントは、ソフトウェア開発のライフサイクルにかかわるすべての人にとって役立ちます。プロジェクト管理の担当者にとって役立つ情報もあれば、技術チームにとって有益な情報もあります。
