メディア

開発プロセスに対する幻想を破壊する：開発プロセス標準化への道（1）

» 2005年04月16日 12時00分公開

[今村智，健全ＩＴプロジェクトプロデューサー]

　この短期連載は、社内のソフトウェア開発プロセスの標準化に日夜取り組んでいるあなたにぜひとも知っていただきたいことをお伝えしていきます。理由は、それ（ソフトウェア開発プロセスの標準化）がうまくいっているという話を、少なくとも私はほとんど聞いたことがないからです。

標準化の目的

　そもそもなぜ、開発プロセスの標準化に取り組むのでしょうか。ソフトウェア開発組織の使命は、顧客のビジネスの成功に対する貢献であると、わたしは考えています。そして、日々その貢献度を上げていかなければ競争を生き残れないと感じています。事実、多くの開発組織では、表現に違いはあるものの、同様の内容を自らの使命として掲げています。そして、貢献度を上げるための手段として、自身の開発力を高めていこうとしているのです。

　開発力を高めるための手段としては、

特定の分野に特化する
開発期間の短縮
開発コストの削減
品質の向上

といったことが挙げられます。貢献度を上げるための手段として、このほかにはIT戦略の策定、経営戦略に対する助言など、コンサルティング業務を含めたソフトウェア開発以外の部分での活動を行う場合もあります。

　開発プロセスの標準化は、上で挙げた“開発力を高める”ための取り組みの1つにすぎません。期間を短縮するためのプロセス、開発コストを削減するためのプロセス、品質を向上させるためのプロセスを、組織の標準プロセスとして定めようということです。

標準化における間違った認識

　さて、ここで少し視点を変えてみたいと思います。開発プロセスの標準化に取り組む組織のお手伝いをしてきた中で、いつも言われることがあります。それは、開発プロセスを標準化することで、

「誰がやってもプロジェクトがうまくいく」

あるいは、

「どのプロジェクトでもうまくいく」

ようにしたい。つまり、これらを実現できるプロセスが欲しいというわけです。中には、“そこそこ”うまくいくこと、というような表現を使う組織もありますが、いわんとしていることは同じです。果たしてそのような開発プロセスを定義することができるのでしょうか？

　誰がやっても、どんなプロジェクトでもうまくいく――。そのような開発プロセスが存在するとしましょう。この場合、そのような万能な開発プロセスの存在は、それをある1社で独占状態にでもしない限り、結果的に、ソフトウェア開発業界の競争力を消滅させるでしょう。なぜなら、いまのソフトウェア開発業界では、プロジェクトの成否が開発組織の能力の差別化につながっている面があるからです。逆にそうでなければ、開発プロセスが話題にのぼることなんてありません。少し極端な話に思われるかもしれませんが、開発プロセスの標準化には、このような自己矛盾が見受けられるのです。とはいえ、そのような万能の開発プロセスなんてありませんから、現時点においては、よりよい開発プロセスを持ち、適切な姿勢でそれと付き合うことが開発力強化につながるということになるのです。

　さて、言葉遊びのようになってしまいましたが、開発プロセスの標準化に過大な要求をするのはやめましょう、ということをご理解いただくためには意外と必要な道筋だということをご理解ください。それでは、標準プロセスとはどのようなものとして扱えばよいのでしょうか？

山頂へのルートの1つ

　登山の場合、山頂へ至るルートは複数存在するといっていいと思います。どのルートをたどっても構いません。しかし、登山者の経験、技術、天候などの外部要因によって、結果的に、選択可能なルートは絞られてきます。登山者の体調や天候の急変によって、途中からルートを変えることも考えられます。途中でルートの変更があるかもしれないからといって、ルートを決めないというのは無謀でしょう。ルートはあらかじめ決めた方がいい。そのルートをたどれば、どのようなペース配分で行けばよいのか、どのような事態が想定できるのか、あらかじめそれらに備えておくことで、安心して初めの一歩を踏み出すことができるようになります。

　開発プロジェクトにおける開発プロセスとはまさに、登山における最初のルートです。開発チームの経験、技術、関係各社（者）の状況から、最適と思われる開発プロセスを“作る”のです。この開発プロセスを作るときに、毎回ゼロから作るのではなく、基本的な作業の流れと、個々の作業の実施要綱をあらかじめ標準プロセスとして用意しておき、それを適宜修正しながら活用すると、初心者でも忘れ物をしないくらいにはできます。標準プロセスとは、その程度のものと考えるのがよいのです。

一流シェフのレシピ

　標準プロセスについて、もう1つのたとえを挙げたいと思います。登山の例と同様に、例としてよく用いられるものです。あなたは、基本的な調理器具の使い方と、食材が何かを見分けることくらいはできる方だとします。そしていま、一流の食材と、それらを使った一流シェフのレシピを手渡されました。さて、あなたは一流シェフの料理を再現することができるでしょうか？おそらく無理だと思うのですがいかがでしょうか。自分で経験したことのない人には、レシピに書いてある「きつね色に焼けてきたら裏返す」とか、「素早くかき混ぜる」ということが言葉として理解できても、自分でそれを判断したり、実践することはとても難しいのです。さらには、その日の気温、湿度によっても火加減、さじ加減が変わってきます。ただ、料理名だけをいわれて作るよりは、なんとか食べられるくらいのものは作ることができるかもしれません。標準プロセスも、このレシピ程度のものと考えるのがよいのです。実践したことのない人が、一流のレシピさえあればいきなりうまくいく。そんなことを期待していては、失望しか味わうことができないのです。

プロセスは結果を保証するものではない

　以上のことを理解していただけたなら、プロセスは結果を保証するものではないということについても理解していただけると思います。正しいプロセスに従っても、プロジェクトが成功するとは限らないのです。ただ、何もない状態でやみくもにやるよりはマシなのです。

　さて、この2つのたとえでお伝えしたかったことを整理します。登山の話では、開発プロセスは1つではないし、プロジェクトに関するいろんな要素に応じたものにする必要があるということをお伝えしました。レシピの話では、どんなに文章化された手順に従っても、経験が伴わないものについて初めからうまくはできないこと、それでもレシピがないよりはマシなことをお伝えしました。

　「そんなことはいわれなくても分かっている」。そのようにおっしゃるあなたは、私が見聞きした限りでは少数派です。多くの場合、人々は標準プロセスに対して過大な期待をしています。その結果、期待値を満たす標準プロセスができない、あるいは組織にうまく展開できないという結果となり、「やっぱり開発プロセスの標準化はうまくいかない」となるのです。

標準プロセスの受け止め方の誤り

　物事のすべてに陰と陽、表と裏があるように、標準プロセスを定義し、提供する側に何か誤った認識や過大な期待があるとすると、それを受け取る開発現場の側にも問題が生じてきます。その1つが、標準プロセスがプロジェクト失敗の言い訳として扱われるという問題です。「与えられた開発プロセスでやってみた結果、プロジェクトがうまくいかなかった」というものです。

　これは、ある面では正しいといえます。それは、どれだけ良い開発プロセスだとしても、変化を強いるものであることに違いはなく、そのような場合には、一時的な生産性の低下が生じるものだからです。新たな試みをする場合には、生産性の低下をあらかじめ了解したうえで、適切にコントロールすることが必要となります。実は、長期的な運用も視野に入れたプロジェクトにおいて、段階的に取り組んでいくことが、組織に標準プロセスを導入していく際の有効な手段なのですが、この点については回を改めてお伝えしたいと思います。

　さて、上に挙げた「プロジェクトの失敗の言い訳として扱われる」ということについて、もう少し考えてみたいと思います。本当は、そもそも標準プロセスを使ってもらうこと自体が大変で、使ってみた結果失敗したというのはまだ良い方だ、と思われている方も多いと思います。この使ってもらうこと自体が大変であるという点については、後述しますので、まずは失敗の言い訳からお付き合いください。

　この問題の背景には、標準プロセスの位置付けと、それを適用する開発現場へのメッセージの誤りがあります。多くの標準プロセスを持つ開発組織では、必ず標準プロセスに沿って開発を行うことが求められています。そうすることで、高品質なソフトウェア開発が可能になるとか、正しく管理されたプロジェクト運営が可能になるという理由付けもされています。つまり、「このとおりやればうまくいくから、このとおりやりなさい」というメッセージとともに標準プロセスが提供されているのです。

　このようなメッセージを受け取った方は、「そこまでいうならそのとおりにやってやろうじゃないか」となるか、「とにかくそのとおりやれば文句はいわれないだろう」となるか、大きくはどちらかの反応を示します。これらは、どちらもネガティブな反応です。いったんネガティブな反応を起こすと、標準プロセスではうまく乗り切れない問題が生じたときにも、前向きな対応策を考えるよりも、自己防衛心が前面に出てしまい、標準プロセスを悪者にしてしまうという状態にはまってしまいます。ですから、標準プロセスに添えるメッセージとしては、

　「この標準プロセスは、開発の進め方の一例にすぎません。現実のプロジェクトにおいては、その状況に応じて適切に変更、修正を行いながら適用する必要があります」

というもので、期待値を適切に設定しながら使う側にも自主性、主体性が求められることを伝えるようなものが適切なのです。ただし、メッセージがこれだけしかないと、「それならいままでどおりのやり方の方がいいよ」となってしまいます。そこで、使いたくなるように導いていくことが必要になります。

　その基本的な手順を簡単に紹介したいと思います。

（1）どんなプロジェクト、開発組織に使ってほしいのかを明確にする

　先に述べたように、誰でも、どんなプロジェクトでも使えるというものはないのです。だから、まずはターゲットを明確にすることが必要となります。例えば、

いつもプロジェクトの終盤に品質の問題が噴出す開発組織
開発期間の短縮が必須だが対処方法に自信がない開発組織

などです。もちろん、提供する開発プロセスが、ターゲットが抱える問題を解決するものであるか、少なくとも、解決してくれそうだと思われるものであることが前提条件となります。

（2）対象とする開発組織が現状を放置しておくことの危険性を伝え、行動することのメリットも伝える

　多かれ少なかれどのような開発組織でも問題を抱えているものですが、積極的に新しい試みをするところは少ないものです。それは、現状では本当には困っていないからです。

　ほとんどの場合、プロジェクトが赤字でも、毎月の給料は支払われます。しかし、現状のままでは開発の仕事そのものがなくなってしまうとか、会社の利益を圧迫し続ければ、いままで当たり前にもらっていたものももらえなくなるかもしれません。いたずらに脅すことは必要ありませんが、会社組織としての常識の範囲での影響を再認識してもらうだけでも大切なことです。その裏返しとして、行動することでどのような効果、メリットが期待できるかということも伝えることになります。

（3）挑戦への保証

　どれだけ良いと思われる開発プロセスであっても、それが初めての試みである以上、一時的な生産性の低下を招きます。それをバックアップする体制、方策の提供を保証することが必要です。また、実行結果のフィードバックを短期間で開発プロセスに反映するための実行計画と体制の保証も必要となります。

　これら（1）（2）（3）の手順に従ってメッセージを伝え、自ら手を挙げたプロジェクト、開発組織だけを対象として標準プロセスの有効性の検証を行うのです。これらのメッセージを受けて名乗りを上げたチームは、高い確率で良い結果を出すことができます。その良い結果を次回は新しいメッセージとして（2）と（3）の間に追加することで、次回はさらに手を挙げるチームを増やすことが見込めます。このようにして、常に自発的に、主体性をもって取り組んでもらえるチームを増やしていくためのアプローチが大切なのです。

　今回は、標準プロセスに対する認識の問題と、それに対する改善策をお伝えしました。次回は、継続的、段階的な改善についてお伝えしたいと思います。

プロフィール

今村智（いまむらさとし）

ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。 Webサイト( http://www.human-process.com/ )からの情報発信も行っている。

「開発プロセス標準化への道」バックナンバー