ソフトウェア開発において高品質評価をうけるには

例え話

あるシステム刷新のためのプロジェクトで、新しいプログラミング言語フレームワークを採用するにあたり、開発ガイドラインを作ろうという話になった。 日ごろからアーキテクチャに関心を持っていた担当者は意気込み、膨大なプラクティスを実際の実装・設計作業を想定の上で丁寧に体系化し、技術の時流に合ったドキュメントが完成した。

しかし、それを受け取った従来からのエンジニア達は、まったく新しい技術を手に、前システムのプラクティスを混ぜ込みつつシステム開発をし、 開発ガイドラインが意図したものとはずれた方向へ実装してしまった。現状と乖離し、しかし独自の自律性を持ったドキュメントは、「参考にするが、鵜呑みにすると痛い目を見るドキュメント」として見られることとなった。

果たして、このドキュメントは、高品質といえるだろうか?

品質と主観

ひねくれた回答かもしれないが、それは見方によって違う、というのが一番的を得てると思っている。

何かの基準を達成すれば品質がいい、そうでなければ悪いといえる。 「何か」とは、たいてい実際にモノを使ってみたとき、思い通りに使えたかどうかだ。

だから何の基準も提示せず「高品質なもの」を要求するのは、「俺たちに都合のいいもの」を要求しているに過ぎない。

IPAが公開している、「ソフトウェア品質説明の考え方」という資料でも、下記の記述がある。

https://www.ipa.go.jp/files/000040880.pdf

「品質の良し悪しは顧客の評価で決まる」

顧客から低品質評価を受けるパターン

システム開発に従事しておりある程度の規模のIT部門・責任者とのやりとりを経験されているなら、そのうち品質に関するクレームを頂くことになる。

「バグが出るのは作業品質が悪いのではないか」「設計書と実装が乖離しているのは品質の面からどうなのか」「受託している以上品質担保してくれないと困る」

だいたいは『品質』という内容のない言葉を主張することが多いが、請負側は大抵ぐうの音も出ない。なぜなら、色々な経緯の上、それなりのものを納品したはずだらからだ。 それには、いくつかパターンがある

想定しない要求が増え、現実解が低品質なものになった

当初の設計を実装していったら、想定外のことが発覚し折れに折れ、誰から見てもダメなモノに成り下がる。 PoCやフィジビリティを見切れず、ウォーターフォールなら後工程で品質担保・検証するから何かしら出来上がるだろう、という、楽観的な見積もりだが方向転換を許さない環境で生まれる。

もしこの常習犯となりそうだったら、仮設検証とソフトウェア工学において”ここまで確認・検証すればうまくいく”ラインと"変えると過去確認・検証した内容が台無しになる前提"の見切りができていないことを肝に銘じるべきで、もしそんなことを知らない権力に晒された場合は説明責任があなたにあるはずだ。

顧客が求める品質を理解していなかった

例えるのも嫌な例だが、非常に政治的なIT部門の担当者から品質のクレームがあがったとき、彼が本当に求めるものは何かわかるだろうか。

経験則上、下記のような背景がある。

  • システムから直接利害をうけるユーザーからIT部門へクレームや要望があがり、その代理として要望している。
  • IT部門の担当者はコミュニケーションによる費用対効果の最大化を図る志向であることが多く、品質向上をコストを引き合いに求めている。
  • 社内で管理する資産や別ベンダー・部署への提示資料として再利用可能な資料を求めている。

システム開発が責務、と思っているエンジニアも少なくないと思われるが、それは、都合のいい顧客像を抱いているだけかもしれない。 実際、これらに配慮すれば、開発したアプリケーションは適切に使われるだろうし、逆に顧客のいる土俵にあがりこんで逆にハックするのも、それはそれで楽しい。

現実解を提示できなかった

下請けや外部から参入したパートナーに作業を依頼した結果、低品質なものが出来上がり品質向上しきれず破綻することも、よく見る光景だ。

言い換えれば、自分が逆に顧客の立場であり、彼らは顧客に対して高品質なものを納品する術を持っていなかった。そして、自らも彼らが低品質を招くパターンに至ることを阻止できなかった。

人月商売では「いい感じでお願いします」が禁句と思っている。人類への感性極まったアーティストか本当に価値観や考え方を見知った同僚にしか通用しない。 事細かに書かれたチェックリストや隙のないルールを提示しても、数割はまともに読まず、他割もないか目の前の課題や問題に熱中したとき、おもしろくないものなど忘れてしまう。

人の心理を理解し、デザインして、この領域における現実解を提示できない限り、ずっとこの問題に悩まされることになる。

最後に

契約を単に徹頭徹尾履行するだけでは、瑕疵とはならないが高品質にはならない。 高品質になるようにデザインされた契約や計画を履行することが価値につながる。

結局、高品質評価を受けるということは主観と満足度を満たすことに落ち着く。 世にいう品質特性とは、よくある品質評価を単に分類しただけであり、顧客が気づいていない品質を予測し満たすための指標であり、”これを満たすことで品質保証したとみなす”のは正直、ありきのビジネスに他ならないと内心思っている。

高品質なものづくりは、その領域においてそれなりの技術と知識を要するが、実践の敷居は低い。間違った道が分かりやすく、定性的に検証可能で、何より実践・関与した人間の中に積み上げが効く。

世の中に、良いものが作られて行ってほしい。