プロジェクトと、そうでないもの

プロジェクトとは何でしょうか。
普段プロジェクトに関わっている人にとっては、十分過ぎる程の実在感を伴っているこの言葉ですが、悲惨なプロジェクトを経験したり、理不尽な顧客の要望を聞いていると、改めて「プロジェクトとは？」と考えさせられることは少なくありません。

ざっとWebや辞書で調べたところ、プロジェクトとは「一定の期間で何かを作り出すこと」と定義できるようです。これをベースとして、例えば「複数人で遂行するものである」とか「コストが決まっている」とか「新しい物を作る」とか付随的な定義もあります。

しかしまあ、はっきり言ってこのような定義に意味はないですね。なぜなら、かなり高いレベルまで抽象化されてしまっているからです。ここまで抽象化してしまうとシステム開発だろうがビルの建設だろうが、商品の開発だろうが、何にでも適用されます。無難ではありますが、空虚な定義です。

ここではもう少し具体的に踏み込んで考えて見ましょう。具体的に、とはどういうことでしょうか。それはもうこの上なく具体的に「いや、こんなのプロジェクトじゃねーよ」と心から叫びたくなるような、そんな無体なプロジェクトについて考えてみたいと思います。

さて、ここから本題に入りましょう。

いきなり本質に飛びますが、何のかんの言ってプロジェクトそれ自体が存在するわけではありません。存在するのはあくまで人です。人が集まっては喧々諤々と、あるいはしんねりむっつりと、何事かやっているわけです。要するに、プロジェクトはそれ自体が実体として存在するのではなく、人がやるものです。つまり、プロジェクトは人次第、ということになります。

プロジェクトの中でもシステム開発のそれには特徴があります。それは「成果物がなかなか見えない」ということです。とにかく文書は大量に出来上がる。コードのサイズも増えて行く。でも、最終的な成果物＝システムがちゃんと動くかどうかはなかなか見えてきません。確かにテストをすれば分かります。でも、そのテストがちゃんとシステムの必要十分条件を満たしているかどうかは、非常に分かりづらい。

分かりづらいから人は何とかしようとします。何とかしようとするわけですが、そのやり方がまずいと「こんなのプロジェクトじゃないよー」という状況になります。

話が拡散してきました。要するにマズいプロジェクトは結局の所人の問題だ、というのが結論なのですが、一旦要件定義作業にフォーカスを当てましょう。

上手く行かないプロジェクトの特徴の一つに「要件がなかなか決まらない」というものがあります。あれもしたい。これもしたい。それも必要だ。いろいろ要件がでてきます。積極的な（＝ポジティブな）要件を決めることは比較的簡単です。あれができます。これができます。出来ることを言っているだけなら誰にも文句はありません。
難しいのは消極的（＝ネガティブ）な要件の決定です。このシステムではこれができません。このシステムを使うと、このデータは切り捨てる必要があります。この意思決定の方がよほど難しく、重要なのです。
何かを決定すれば、必ずどこかにリスクなり制約が発生します。意思決定とはそういうものです。ある選択をするということは、別の選択肢を捨てることなのです。それによってリスクや制約が発生する。しかし、そのリスクを取りたがらないお客さんがいる。そうなるとなかなか話が進まないことになります。あるいは進んだとしてもあれもこれも機能を盛り込むことによって納期、コスト、品質に悪影響が出てくる。悲惨なプロジェクトの始まりです。

このようなプロジェクトが始まると（そしてマネージャーがきちんと顧客の要求をマネージできないと）ひたすらTODOが定義されて、納期だけが決められ、品質が悪くなるかあるいはTODOがいつになってもこなせない、皆が不幸になるプロジェクトとなってしまいます。

こういう顧客をマネージすることでまず大事なのは、顧客と対立するのではなく、顧客をこちらの立場に引きこむ、ということです。リソースと時間が有限であるという課題を共有し、限られた中で一緒に何とかしてゆく、というスキームに持ち込むことです。コラボレーションして行く中で「できないものはできない」という当たり前のことを理解してもらうのです。
それから「未定義の領域がある」ことを理解してもらうことも大事でしょう。例えば「システムはこう動く」と定義して、お互いに同意して、その通り作ったとします。当然定義されていない個所については、顧客の思った通りにはならないこともあります。それはベンダーだけではなく顧客の責任でもあるのです。それを理解して貰えないと、いつまでたっても改善要望が尽きることはありません。顧客も「聞いてなかった」「知らなかった」では済まされないという意識を持ってもらう必要があります。
出来上がった後で気に入らない点が出たとしても、それはお互いの責任だ、ということです。システム開発プロジェクトでは、お客様は神様ではないのです。限られたリソースの中で一緒にモノを作って行くチームの中で、とりわけ責任が重いメンバー（リーダー）の一人なのです。

システム化するとは、あるプロセスを単なるデータの流れへと抽象化する、という側面があります。つまり、システム化によって何かが切り捨てられるのです。切り捨てられることによって、効率的になるのです。
ですからシステム化することによって何か出来ないことが出てくるのを恐れる必要はありません。それもまた、システム化の目的の一つなのですから。