プロの条件と開発プロセスこうすればできる開発手順の標準化(1)

» 2006年07月28日 12時00分 公開
[瀬谷茂,豆蔵]

ソフトウェア開発に「開発プロセス」は必要なんでしょうか? これはよく私が「開発プロセス」の標準化のお手伝いやトレーニングをする際に、最初にされる質問です。もし、この質問をされたら、これを読まれている皆さんはどう答えるでしょうか? おそらく、いろいろなご意見、回答があると思います。「こうすればできる開発手順の標準化」第1回では、「もの作りのプロフェッショナル」という視点からこの問いが持つ意味について考えてみたいと思います。

(1)プロフェッショナルとは?

 筆者が20年くらい前に新人で会社に入り、ソフトウェア開発部門に配属されたとき、こう尋ねられました。

 「ソフトウェア開発で、プロフェッショナルとアマチュアの違いは何か?」

恥ずかしい話、そのときは「給料をもらっているか否か」くらいしか私の頭には浮かびませんでした。しかし、そのとき教えられたのは、「仕事の成果(物)の品質を保証できるか否か」ということで、いまでもそのことは常に頭の片隅に残っています。品質を確保・保証するために、アマチュアの3倍以上の手間暇を掛けて、成果物=ソフトウェア製品を作るのだという、もの作りのプロフェッショナルとしてのプライドのようなものを教えられました。

 そしていま、筆者が同じ質問をされたら、やはり「品質の保証」という答えを返すと思います。加えて、経験と知識が少し増えた分、「品質が保証され、かつ効率化された手順、きちんとトレーニングされた要員、適切なツール、品質の監視・改善の仕組み」が整った環境で行うのが、プロフェッショナルなソフトウェア開発であるというかもしれません。

(2)「プロフェッショナル」なもの作りの現状

  しかし実情はどうでしょう? 残念ながら上記のような「プロの条件」を満たした環境でソフトウェア開発が行えている現場は少ないように思えます。筆者自身、「プロの条件」を満たせないもの作りをした時間の方が長いかもしれません。

 理由はさまざまあることは承知していますし、そういう状況を変えるのは容易でないことも分かっているつもりです。しかし、それでも、このような状況はそもそも異常なはずです。異常がほとんど当たり前になってしまっているところに、問題の根深さがあると思います。

 一方、視点を変えてソフトウェア開発の顧客側から見てみましょう。顧客にとって、「プロの条件」が満たされていないという状況を現場の開発者が当たり前だと思っているような認識は、決して「当たり前」ではないはずです。顧客から見れば、もし先進のツールを駆使するソフトウェア開発の「プロ」が、「開発の標準的手順は持たず(あっても順守されず)、開発要員には必要な訓練が行われておらず、品質を監視・改善する仕組みがない」ような状況でもの作りをしていると知ればかなり驚くでしょう。そして、出来上がったソフトウェア製品に何か重大な欠陥がないか疑いの目で見ることになるのではないでしょうか。

 最先端の建設機械・素材を利用していながら、実際には標準的な工程もなく(守られず)、熟練工もおらず、適切に品質も管理されていないような建設会社・工務店に、家造りを依頼するでしょうか。

 外側から見ればプロフェッショナルのはずなのに、見られる方の認識・要望に作り手が応えられていない。これは近年、日本の多くのもの作りの現場で見られる共通の現象のようにも思えます。そして、このことはソフトウェア開発の現場では、特に顕著に表れているような気がします。

 そういうわけで真にプロフェッショナルなソフトウェア開発には、ほとんどの状況で「開発プロセス」は不可欠なのではないかと筆者は思っています。

開発プロセスvs.創造性?

 「開発プロセスは創造性を阻害する」という意見を聞くことがあります。これには、2つの意味があると思います。


  1つは、無から何かを作り出すような最先端の研究開発プロジェクトなどでは、品質や効率よりも「何か新しく有益なもの」をつくり出すことが優先されますので、この場合、開発プロセスの重要性はそれほど高くないかもしれません。


  もう1つは、開発プロセスは開発の手順や成果物のフォーマットまで決めてしまうので、創造的な仕事ができない、という意見です。一見、正しいように聞こえますが、実際にはそうでないように思えます。


  アーキテクトとしてプロジェクトで一番創造的な部分を担うべき担当者が、本来利用できる開発プロセスがあればほとんどやらなくても済むような仕事(すなわち手順書や成果物定義、ガイドラインの作成、そのトレーニング)に多くの時間を割かれ、本来の仕事に集中できないということがよくあります。これはアーキテクトに限った話ではありません。要件定義者、設計担当者、テスト担当者、プロジェクト管理者、すべてにいえることです。本来求められている仕事に時間を費やすには、いかにほかの決まりきった作業を軽減できるかが重要になります。そういう意味でも、あらかじめベースとなる開発プロセスを、開発メンバーを含めて利用可能にすることは、創造性や生産性の向上に少なからず影響しているといえるのではないでしょうか。



(3)開発プロセスに対する誤解

 「開発プロセス」という言葉には、ちょっと注意が必要です。開発プロセスには、開発プロジェクトの作業標準として、ほぼ強制的に利用され、その決められた手順によって決められた成果物を作成するという、ソフトウェア開発を支援する手段としての一面があります。しかし、それはあくまで手段でしかありません。開発プロセス導入の目的は、「品質を確保し、効率的にものづくりを行うこと」です。その目的さえ達成できるのなら、手順や成果物の大幅な省略、簡略化も全く問題ありませんし、逆に状況に応じて手順やルール、成果物を増やすことも検討する必要があります。

 重要なのは目的であり、目的と手段の重要度の比重が逆転してしまうと、「何でこんな無駄なことをしているのか」と不満を持つ開発者が増えてきます。一度決めてしまうとそれが不可侵の規律になってしまい、現場の状況に合わせて目的達成のために柔軟に適用していくということが難しくなってしまっていることがあり、それが「開発標準嫌い」を増やしてしまった一因とも思えます。実際いろいろな現場を回ってみて、この「トラウマ」は想像以上に大きいと感じています。

 そのせいか、「開発プロセス=開発者を縛り、面倒な作業を増やすルール」という認識を持っている開発者・管理者が多いように思えます。個人的には、非常に残念なことです。

 合理的かつ妥当で、その運用さえうまくいけば、「開発プロセス=皆を悩ます面倒なルール」ではなく、「開発プロセス=プロジェクト・組織の知恵・ノウハウ」になっている例を筆者は少なからず体験しています。そして、それこそが目指すべき姿ではないかと思っています。

 成功している日本のもの作りの現場ではいわゆる「カイゼン」を行いながら、開発・製造プロセスをもの作りの知恵・ノウハウとして極限まで最適化し、競争力を高めています。それはソフトウェア開発にも当てはまると考えることは、あながちとっぴな発想ではないと思います。事実、インドや中国などのソフトウェアベンダは、このような考えを取り入れて競争力を高めています。


 ということで、プロフェッショナルなもの作りとしてのソフトウェア開発という視点や、もの作りのノウハウ蓄積という視点からは、開発プロセスは必要なもの、と考えるのが自然なのではないでしょうか。もしソフトウェア開発の現場を、混沌(こんとん)としたものとしてとらえるなら、まずはそういうところを原点としてもの作りのやり方を見直すことが必要かもしれません。

 それでは、最後にあらためて皆さんにお尋ねしたいと思います。

 「開発プロセスは必要でしょうか?」

 次回は「開発プロセス」の現状と課題について解説をします。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ