T

品質管理についてみんな本当は知りたいこと

GoogleはPythonの開発者に、コードレビュー支援ツール「Mondrian」を作らせている。他にも、Google Testing Blogを読むと毎年テスト自動化カンファレンスを開くなど、品質管理への取り組みに積極的だ。

パッケージ商品や受託のソフトウェア開発で、コストに見合わない過度のテストは無理と主張する人はいても、品質管理が大事ではないと断言する人はいないだろう。Webアプリ開発のいわゆるチープ革命や「50%の完成度でリリース!」などのお題目に勘違いしてしまうと、この世界では命取りにしかならない。

しかし、いざソフトウェアの品質管理に取り組むと、これが一筋縄ではいかない問題だというのはおよそ全ての開発者も肯定するところだろう。素晴らしい出来映えのソースコードは一人の天才プログラマが生み出すことが出来るものだが、経験則に照らし合わせると、究極的な品質管理のプロセスもまたそうだというわけではない。

なぜ、品質管理は難しいのか。まず、品質の管理というプロセスそのものが、常にその品質を管理されていなければならないので、品質管理自体が常にメタレベルの問題を孕んでいるという事実が問題を難しくする要因の一つだ。というとなんだか現代思想のレトリックのようだが、品質管理というのは常に移ろい変化するものだと考えれば、当然のことだともいえる。例えば、セキュリティの観点から常にソースコードをチェックしているチームは、全く新しい攻撃手法が公開されれば、これまで実行していたチェックのプロセスを改善する必要があるのだ。

品質管理という作業のスコープがあいまいなのは、品質管理に手をつけようとすると、あらゆるところに問題を見いだすことが出来るせいでもある。スケジュール作成プロセスの見直しでも品質は改善される。SEがもっと粒度の高い作業指示をすれば品質は改善される。販売戦略だって劇的に製品の品質を変えることがある。職場の環境だって改善すれば品質は向上する。ボトムアップでもトップダウンでも隣同士の話し合いでも何らかの効果があるだろう。でも、だったら誰がこの作業を担当すればいいのだろう。全員だろうか。では、品質管理はみんなの副業なのか。でも、全社規模の働きかけって、ちゃんと機能したことなんかあった試しがないと思わないか?大きすぎる目標は得てして来るべき理想社会のように幻に終わってしまいがちである。

それから、品質管理がいったいどれだけ儲けに繋がるのかがわからないというのも問題だ。極端な話、製品は作れば売ることが出来るが、偉大な品質管理チームは製品の完成には寄与出来ても作り出すことは出来ない。どこまでの費用対効果を見込んでいいものか、経営者なら必ずや迷うところだろう。

たとえ品質管理の問題をとりあえず開発現場の仕事と限定したとしても、品質管理を担当するチームの人員配置は悩ましい問題だ。ソフトウェア開発会社が、コーディングを担当するメンバーより優秀なプログラマを品質管理チームに配属させることが、果たしてどれだけあるだろうか。では、多少の差がある程度の粒の揃った技術力の高いメンバーを揃えている開発会社はどれくらいあるだろう。先日こんな記事を読んだ。ソフトウェア工学の博士号を持ったようなプログラマ志望者たちに簡単なテストを実施すると、驚いたことにほとんどの人間が全くそのテストの問題を解けなかった。どれくらい簡単なテストかというと、1から100までの数字を画面に出力するが、3で割り切れる場合は数字ではなくある文字列を、5で割り切れる場合は別の文字列を、3と5で割り切れる場合はこれもまた別の文字列を出力するという内容だ。これは、何もアルゴリズムの問題ではない。ある数字が3で割り切れるか、5で割り切れるか、それともその最小公倍数の15で割り切れるか判定するだけのロジックを実装できないのである。

自身が優秀な開発者には驚きをもって迎えられたこの記事だったが、実際に現場で採用活動をしたことのある人なら知っている通り、この売り手市場のプログラミングの世界では、こんなことはとうに珍しくもない現象になっている(知らない?それはそれはおめでとうございます)。筆者の勤め先でも、面接時にこれよりもっと簡単な試験を実施している。例えば、5つの数字が改行で並ぶ(改行コードはLF)テキストファイルからこれらの数字を読み込み、その最大値、最小値、合計値、平均値を画面に表示させる。実装する言語はPHPが望ましいが、別に問わない。あまりに簡単な問題なので実装方法は幾通りもあるだろう。自分でクイックソートを実装するもよし、組み込みの関数を使うもよし。紙の上に書いてもらうのだから、まあ多少のエラーは大目に見よう。問題を作った当初はそんなことを考えていた。だが、現実には、今までにこの問題に正解を出したプログラマ志望者はほとんどいない。パースエラーがあるとか、そんな生易しい間違いではない。そもそも最後まで与えられた仕様通りに実装出来るケースの方が稀なのだ。それに、もしちゃんと書けたとしても、その人は優秀なのでいくらでも働き口が見つかるから、条件のいいところに取られてしまう。そして、結局あれやこれやと胸に抱いていた希望を捨てて、ポテンシャル採用と称して誰もいないよりはマシだろうと妥協することになる。

各メジャーバージョンに超強力なメンテナを要するソフトウェア開発の現場(アンドリュー・モートンやアラン・コックスが面倒みてくれる!)ならいざ知らず、一般的なソフトウェア開発会社の実情なんてこんなものじゃなかろうか。そうでないところは、きっと何かしらの手を打ってきたところに違いない。品質管理の重要性が最近より声高に唱えられるようになってきたのは、こんな開発現場の凄まじい事情もある。優秀なプログラマがいないなら、優秀でないプログラマの書くコードをなんとか製品レベルにするために手を打たないと、開発会社として立ち行かなくなる。ましてや、Googleさえも相当なコストをかけて品質管理に取り組んでいるのだから、このままでは普通のソフトウェアベンダならまったく太刀打ち出来なくなってしまう。

ちょっとしたソフトウェア歴史観というやつを思いついた。これは、かつて大学の研究機関やNASA、IBMのようなエリート集団や巨大企業(同じか)が中心となっていたソフトウェア開発が、一般企業の業務として開かれて拡散していったことへの揺り戻しなのだろうか。今度はGoogleを含む超優秀なプログラマ集団(まあ、Googleだって大きくなればそれなりに問題は発生してきて、結局は普通の開発会社に成り下がることだってあり得なくはないわけだが。例えば、来週キャンパスの屋根が落っこちるとか)によって集約されて、そのニッチからまた新たに開発会社の拡散が始まる、という歴史解釈もあり得るのではなかろうか。まあ、思いつきの領域を出ない話だが。

もちろん、だから今のうちにソフトウェア開発からとっと手を引いて、もっと儲かる仕事を見つけて鞍替えするという選択肢もあるだろう。開発部門とサービス部門を分社化して、ホールディングカンパニーを組織して、会食の場で情報交換して儲かりそうな投資先を交換し合うのも立派なビジネスだ。よく知らないが。

しかし、こんな状況にあっても、個別にみれば実際にうまくいっているか、少なくともそう見える会社もあるのだから、自分たちがやり方を変えれば道は開けるのかもしれない。そう思っているうちは、出来るだけのことはやってみた方がいい。

もちろん、ソフトウェアの性質上、こんな問題が起きないケースもある。基本的に、品質管理が問題になってくるのはパッケージ商品として開発される、あるいは受託開発されるソフトウェアであって、自社開発の社内システムなら多少の苦情でもなんとかなるだろう。それに、例えばLinuxカーネルの開発にさっき書いたような程度の試験問題が解けない人は参加しないだろう。フリーソフトウェアというのは、ある意味究極の答えだともいえる。ソースコードの中身を公開して、問題があったら見つけた人が直せばいいというのは、品質問題の解決という面でも究極のアプローチだ。フリーソフトウェアというのは、品質管理という視点でもかなり特異な存在といえるだろうが、いくら特異点の話をしても飯は食えないわけで、ここでは脇に置く。

やはり、今もっとも需要があって、それなのにウェブ上ではあまり情報が見つからなくて、開発現場の管理職たちがまるで異性の体はどうなっているのか知りたくて悶々とする思春期の子供たちのようになっているのは、品質管理のベストプラクティスなのではないだろうか。そういう意味で、SIer的なノウハウが表に出ないウェブの情報は問題があるといえる。

そこで、ふと思ったのだが、スケジュール管理、ソースコードの問題検知、コーディングの支援、バージョン管理、進捗管理、バグ管理、改善プロセスに必要なデータ出力といったところを揃えた、ある意味で究極のソリューションは、ひょっとしたら自社開発せざるを得ないものなのかもしれない。ビジネスのコアになるものを外部に委託するというのは、うまくいかない企業の典型だ。そして、開発会社のコアは、やっぱり開発だ。もちろん、外部の会社を買って自社のコアビジネスに組み込むのは外部委託とは違う。マイクロソフトがDOSを買い、PowerPointを買ったのは、すごいことだと思う。もしそれらの製品を開発している企業と下手なアプライアンスを組んでビジネスを進めていたら、決して数十年間ソフトウェア開発の世界でトップを進むことは出来なかったはずだ。

話がズレたので元に戻すと、現在商用、フリーを問わず出回っている品質管理のためのツールを見ていると、個々のソリューションはなかなかいいのだが、いざそれらを自社のワークフローに組み込もうという段になるとどうしても不満が出てきてしまう。ソースコードの検品に絞ってみても、例えばEclipseのソースコードチェックツールを見ると、それはそれでそれなりに優秀だとは思うが、どうしても真面目に運用すれば管理コストがかさみすぎて実用的ではない。商用製品を一通りチェックしてみても、インターフェースがいまいちだったり、ソースコードの問題検知ツールから実際にどのようなワークフローで業務を運用すれば最適なのかがわかりにくかったりして、まだまだ難しい。

そんなわけで、社内で使うツールについては自作してみようと思う。気づいたことがあれば、こちらにも載せながらあれこれ考えていく。

Posted by on 5月 17, 2007 in Software

コメントを残す