もぐら叩きしてるエンジニアのソフトウェア品質とは

プロジェクト計画レビューをしていて、どーもシックリとしないんですね。そうです、品質管理で。まぁ、機能改善や機能追加がメインの維持管理のようなプロジェクトなので、現行システムを引き摺ったままでの品質管理になるのですが。
巷のシステムエンジニアのみなさんは、品質管理に対してどのようにスキル習得をしているのかなぁ、と、とても興味を持っています。ワタシの組織でも品質管理については研修があったような気がしますがワタシ自身は巨大プロジェクトの実務で習得したことがベースになっていて、そこに後付で理論武装(と言っても鍋の蓋や木の枝くらいですが)の装備で尤もらしいことを尤もらしい顔で決めているわけです。


もぐら叩きが品質管理だとは
彼のプロジェクト計画レビューでは、計画書自体が網羅的に目次が用意されていて、書いて欲しいことがサンプルで記載されているので初めてでもなんとか形にすることはできます。でも、人は怠惰なので先人や隣人が作っていたらそれをアセットと称して使い回すものですし、それが正しいやり方です。
#興味を持ったことを一からすべて自分で学び習得するには人生は短すぎますから。
所詮、人の行いなんて誰かがすでにやっていることの焼き直しなんでしかないですし。

誰かのを手本に、若しくは、寄り抜きしてでも過去事例やサンプルとして使うのはいいとして、引っ張ってきた内容理解しているの?って思っちゃうようなプロジェクト計画に出会ったとき、「ふへーっ、コイツ品質管理の品質を管理するということわかってねー」って思ってしまうんですね。
で、お尋ねするわけです。

「“この”プロジェクトでの“品質”は何?」
「顧客のやりたいことをやってあげること。」


顧客要求を合意した姿として捉えて、実現すること自体が“品質”であることは、わかっているんだけど。で、さらに、質問するよ。


「その品質とやらは、どうやって実現するの?」
「この手順でシステム作って、バグでたら直すよ。」
(だめだ、これじゃ。)


このプロジェクトは現行システムがあって、機能改善や機能追加がメインの維持管理のようなプロジェクトです。ご多分にもれず、都度のリリースでときどきポカをするんですね。で、原因分析をさせると「手順がー」とか、「考慮がー」とかおっしゃる。で、再発防止というか、「同じ失敗するのはバカだよね、どうする?」と尋ねるわけです。

そうすると、やっぱり出てくるのは人間系での「チェックを強化します!」という紋切り型の回答が。
#こりゃ絶対再発するな。


雑談をしていてわかった
あるトラブルが起きたとき、人を介する作業が原因なら、それを何重に人を介しても決してゼロになることはないです。だって、介する人の興味がいつも同じレベルで維持されるわけ無いもの。

人を介して起きるトラブルは、その人が介在する手続き自体を変えなければ作業不良はなくなりません。作業の結果の品質を確保したければ、その作業の手続き=プロセスを変えることです。人が作り出すアウトプットの出来具合をコントロールしたければ、そのアウトプットを作り上げる振る舞いを「コントロールされた振る舞いで作らせなさい」と言うことです。

なんでこれがわからないんだろうなーって思いつつ雑談していたとき、そのわからないことがわかった。そのプロジェクト計画書を作ったシステムエンジニアは、

“スクラッチでアプリケーションの開発をして品質で苦労したことがないんだ”


ということです。

確かに、大雑把に言えば、インフラなら要件をパラメータに落として設定するので不具合のような品質トラブルは稼動確認でわかるから、間違っていたら直します、となるんですね。要件を実現する機能の品質は機器が製品として担保しているのです。だから、設定間違っていたら直すよ、でおしまい。

パッケージをつかったソリューションでもシステムのコアはパッケージなので、ほぼパッケージが品質を担保しているわけです。パッケージ以外で品質トラブルがあるのはアドオン開発部分ですがパッケージソリューションのエンジニアは、どちらかと言えば、インフラに近い思考をするのではないな、と。パッケージのカスタマイズ(=パラメータ設定)なんて、インフラでのパラメータ設定と作業としての本質はそう変わらないもの。パッケージソリューションのシステム開発としては、fit&gapでgapが大きくならないようにするわけだし、大きいままならパッケージを導入する意味ないし。そうすると、やっぱり作業はパラメータ設定に寄るので設定間違いが無いように、間違ったら直します、と。


ところがスクラッチのアプリケーション開発は、そうは行かない。作るシステムの品質は全部作る側にかかっている。インフラなら機器が、パッケージならパッケージが担保していた仕様や機能をこれから作るソフトウェアに品質を依存してしまい、担保はその作業と言う行為そのものに掛かっているのだから、と。
そういうことだったのだぁ。そりゃ、仕事の手続きとして品質を確保するなんてことに辿り着くわけ無いや。