« 2010年9月 | トップページ | 2010年11月 »

2010年10月

評論家と定量データオタクなんて、いらない

■日々の疑問

最近のソフトウェア開発を見ていると、

・プロセス通りにやっていない
・品質データがよくない
・そもそも品質データをとってない

というようなことを、アセスメントや品質保証を業とするソフトウェアの品質向上に関わる人々が、盛んに強調しているのを見かけることが多い。

そしてその後、彼らが、状況を改善するための具体的な何かをするのだろうかと見ていると、何もせずに言いっぱなしになっていることも多い。

自分たちが「問題がある」と評価して、それを改善するように指摘したのなら、言いっぱなしは無責任ではないだろうか?

そして、実際にソフトウェアを作っている人々が、指摘されていることはわかるが、実際に何をしたら良いのかをもっと具体的に教えてほしいと訴えても、アセッサたち(アセスメントをする人々)は抽象的な指摘をするのが仕事で、その指摘を具体化するのは、あなたたちの仕事だといって突き放す。

なるほど。アセッサの言い分もよくわかる。

彼らが言うように、仕事の分担は明確にするべきだし、具体的な指摘をするのはアセスメントの範囲ではないし、そこまでの報酬ももらっていないのだから仕方がない。

しかし、実際のところ、具体的な改善方法がわからないと言っている相手に、そんな正論を唱えても、なんら効果はないし、わざわざ費用をかけて、彼らにアセスメントをしてもらった組織は、まったくの無駄金を使ってしまったことになる。なにしろ、効果がないのだから。

しかし、そもそも、アセッサや彼らにアセスメントを依頼する組織のマネージャ達は、上のような、ソフトウェア開発に本当に必要かどうかわからないことばかりに注目し、とにかくやれ!と開発部隊に強要することに、疑いを持っていないのだろうか?

プロセスがそれほど重要なのだろうか?
品質データをとって、数字の上で議論することが重要なのだろうか?

そんな疑問は浮かばないのだろうか?

評論ばかりで実際に改善効果に結びつかないアセスメントが、本当に費用に見合うものだと信じているのだろうか?

そんな話をソフトウェア開発を業とする友達に話してみたところ、彼は、アセッサも品質保証担当者も、組織のマネージャも、現実のソフトウェア開発に直接には携わっていない人々なので、そういう疑問は浮かばないのだろうと言っていた。

なるほど。

■ソフトウェア開発技術の進歩に管理手法も追いつくべき

確かに、昔のソフトウェア開発には、そういった管理の仕方が適切だった時代があったのだろうし、いまでも特定のドメインではそれが適切かもしれないが、現代的で先進的なソフトウェア開発ではプロセスが最重要ではないし、設計書のレビューに何時間かけたかとか、文書の欠陥をどれだけ見つけたかとか、そんなことは重要ではなくて、どれだけ早く、動くソフトウェアを作るかがクオリティーではないだろうか?

正直なところ、CMMIやSPICEのモデルは時代遅れに感じる。
そして、そのモデルを使って、訳知り顔で評論するアセッサには嫌悪感を感じる。

そして、SQA(ソフトウェア品質保証)を名乗って品質データを集めることを目的化している連中はソフトウェア開発の阻害要因にも感じる。

もちろん、中には、ソフトウェア開発に有益なアセスメントやSQAもあるのだろうが、実際に目にすることが多いのは、最新のソフトウェア開発や技術の進歩に無頓着で、時代遅れな、評論家や定量データオタクだ。

ソフトウェアは常に進歩しているのに、彼らはずっと過去に止まったままだ。

なぜもっとソフトウェア開発技術自体の進歩に気づこうとしないのか?

先の友達いわく。

「だから。彼らは直接、ソフトウェア開発に携わっていないのだから、その進歩に気づかなくて当然なんだよ。」

なるほど。

| | コメント (0) | トラックバック (0)

アセスメントサービスの弊害

ソフトウェア業界では、しばらく前から、開発組織の成熟度を診断するというふれこみで、CMMIやSPICEという名前の付いたアセスメントサービスを業とする人々が出てきている。

そういうアセスメントサービスでは、それぞれの流派で診断につかうモデルがあり、ソフトウェアを開発するために必要な事柄が定義されている。

そのモデル自体は良い。経験に基づいてよく整理されているので、実際にソフトウェアを作っている人々が自分たちの問題点を見つけだして、開発にともなう苦労を少なくするのに有効に使える。

しかし、アセスメントサービスには問題も多い。

まず、ソフトウエア開発自体の役には立たない。
つまり、アセスメントを受けたからといって、その組織のソフトウェア開発能力が高まるわけではない。これは当たり前だ。

また、アセッサ(アセスメントを行う人)の説明が抽象的すぎて、組織の問題点に直接言及していないことが多く、アサッセが言っていることは一般論としてはわかるが、さて実際に自分たちのことに置き換えようとすると、何をして良いのかわからないということが非常に多い。

この2点だけでも、ソフトウェア開発組織の目的には、直接には役に立たないサービスだと言える。

さらに別の問題がある。
それは、アセスメントで「成熟度が高い」と評価されると、その組織の作るソフトウェアの品質が高い、という誤解を、他の組織に与えてしまうことだ。
これは、日本の会社が、中国やインドの会社にソフトウエアを外注する場合などに問題になる。日本の会社にしてみれば、アセスメントサービス会社が与えた「成熟度が高い」というレッテルを信じて発注するのだが、実際はそのレッテルは「高品質のソフトウェア」を意味していないので、納入されたソフトウェアはバグだらけ、ということが起こっても不思議ではないということだ。

これに至っては、受注したい会社が、アセスメントサービス会社を利用して作為的に誤解を生じさせるといったことも可能であるため、さきの問題よりも大きな弊害かもしれない。

最後に、アセスメントサービスは非常に高額だ。
一回の診断(1~数週間)で500万円という値をつけてくる会社もある。
余程、資金に余裕のある会社以外は、おいそれと出せる金額ではないだろう。
さらに悪いことに、ヨーロッパの自動車業界ではAutomotiveSPICE(SPICEの一種)の一定の成熟度であることを、部品の調達先企業の選定条件にしているし、日本でもSPICEを選定条件にしようとしている組織も出てきている。
そうすると、力はあるが資金力に乏しいソフトウェアハウスが、飛躍のチャンスを逃すことにつながり兼ねない。
これも、アセスメントサービスがもたらす弊害と言える。

以上から、日本のソフトウェア業界は、最近広がりつつあるアセスメントサービスについては、何も考えず受け入れるのではなく、弊害をとくに重視して、関わり方を決めていく必要があると思う。

| | コメント (0) | トラックバック (0)

« 2010年9月 | トップページ | 2010年11月 »