見出し画像

ソフトウェア開発と定量的品質管理は一定の条件を満たさない限り、相性がすこぶる悪い

Takashi Suda / かんた

ふと思ったんです。

というか、以前からわかってはいたんですけど、あまり世間ではその点に触れられないから後回し、後回しにしていたんですが「やっぱおかしいよなー…？」という気がしてきて、改めて脳内整理を行いました。

それが

　「ソフトウェア開発と定量的品質管理は相性が悪い」
　　※ただしある条件を満たした場合はその限りではない

です。

製造業のそれとソフトウェア開発は同じではない

まず、大前提として覚えておいて欲しいのは

　「ソフトウェア開発のプロジェクト活動と
　　製造業におけるライン製造はまったく違う」

ということです。製造業の品質管理をそのままソフトウェア開発に適用しようと思ったら失敗するのは当然です。

そもそも、昔から"違う"ということはわかっていたんです。確かに設計→製造（実装）→試験を行いますが、ＩＴはあくまでもサービス業（情報サービス産業）です。第三次産業であって、製造業のような第二次産業とは一線を画します。

ですが、そんな上っ面（…でもないけど）のことしかわかってませんでした。

製造業というものをさらに深く掘り下げると、製造業には「試作」と「量産」の２つの段階があることがわかります。

画像1

定量的品質管理はどちらかというと、ここでいうQCやQMで用いるものです。

もう少し噛み砕いて説明すると

　（試作の段階が終わり）きちんと製造する仕組みが構築できてから、
　『本当に仕組み通りに進められているか？』を外部の観点から
　検証するために行われるもの

になります。量産…要するに大量にモノをつくるから、その測定を「数値」で測定することが可能になるわけです。

翻って、試作の段階ではどうでしょう。

一つひとつの仕組みが試行錯誤の繰り返しで、２つとして同じ手順はないかもしれません。まったく同じモノはないかも知れません。それでは同じ「数」として計上することが困難です。

算数の定理と同じですね。

みかん１個とリンゴ１個を足しても、みかんは１個であって、２個になることはありません。無理やり「みかん２個です！」と言い切ってしまったら、色々とおかしくなってしまいます。

ソフトウェア開発…というかプロジェクト活動でも同じことが言えます。

プロジェクトの定義は

「独自の製品、サービス、所産を創造するために実施される有期性の業務」

画像2

とされています。そのため、プロジェクトごとになにかしらの独自性があって2つとして同じものが無いということを意味します。そう、製造業で言う『試作』と同じような環境下で、常に一発勝負の製品開発を余儀なくされているのです。

Ｂ２Ｂで行われるソフトウェア開発は、（組込みでない限り）試作と量産という考え方は当然ありません。すべてが一発勝負であり、また一発勝負分のスケジュールしか与えられないものとなっています。


ソフトウェア開発のプロセスはいまだ属人的

また、メンバー一人ひとりが作るモノも違いますし、残念なことにメンバー一人ひとりが行う作業も厳密には異なってきます。

たとえば「基本設計」という工程を見てみましょう。

わかりやすいところで「画面レイアウト設計」を行ったとします。

画像3

ちょっと画像検索しただけでも、たくさんの様式が出てきました。

とはいえおそらくプロジェクトの中では様式の統一は行われていることでしょう。そこまではいいのです。しかし、よく見てください。

画像4

たとえばこのような様式。
おそらくは画面レイアウト上の各項目についての説明が上段に、下段は利用者がアクションを実施した時の動作結果がどのような状態になるのか書かれている感じですね。

比較的よく見るものではありますが、この様式を見て、私は不安が募ります。それは

　自然言語が多用されている

ことです。自然言語…すなわち、人間が意思疎通のために日常的に用いる言語のことです。口語か文語かは置いておいて、普通に文章としてずらずらと表現すると、次のような問題が潜在的に組み込まれます。

・作り手の「表現能力」や「言葉の理解」に依存した品質となってしまう
・読み手の「読解力」や「言葉の理解」に依存した品質となってしまう

いいかえるなら、言葉の自由度を上げすぎてしまったがために、コミュニケーション不良が一ヶ所でもあったら「作成者の責任」でも「読解者の責任」でもなく、

　この様式を採用したマネージャーや承認者の責任

ということです。

話し手、聞き手がそれぞれ「自分は正しい」と認識していても、コミュニケーション不良が起きるのは世の常です。にもかかわらず、自然言語を多用させるというのは、それだけで

　「お互い勝手に間違いあうがいい！ﾜｰﾊﾊﾊﾊ!!!」

と言っているようなものです。

そして、たとえ同じ様式を採用していたとしても、一人ひとりの表現力や読解力に依存して、基礎品質のレベル感が統一できない仕組みになっている時点で、品質を一律同じ基準で評価することが非常に困難であるということができるわけです。


レビュー品質の基準が定まらない

次にレビューです。

ソフトウェア開発の現場ではおそらく品質に多少詳しい人であっても、100人中99人は「データの品質（ISO 25012）」という概念をご存じないでしょう。

この「データの品質」は本来、システムやソフトウェアの中で取り扱うデータそのものの品質について定義されたものです。プログラムは命令されたとおりにしか動作できません。そのため、あらかじめ想定しているデータしか処理できませんし、それ以外のデータを取り扱おうとするとたいていの場合、エラーとなってしまいます。

ゆえに「プログラムがどんなに正しくても、データの品質が正しく活用されていなければ、いずれシステムは問題を起こす」というものです。

ですが、それは人と人とのコミュニケーションでもまったく同じことが言えます。

　設計書や仕様書の各項目に記載される『データ』
　人と人との間で会話される際の言葉も『データ』

です。プログラムの呼び元と呼び先の代わりに、人の書き手と読み手、話し手と聞き手が存在しているにすぎません。この

　書き手→読み手／話し手→聞き手

の間においてもその間で取り扱われる『データ』の品質が常に一定になっていなければ、否応なくコミュニケーション不良が発生し、欠陥（バグ、不良、障害、etc.）は埋め込まれます。

さて、その品質を保証しなければならないのは大きく２つ。

　レビュー（設計工程のテスト）
　テスト（プログラムのテスト）

です。テストは後で説明するとして、レビューについてはどうでしょう。先ほどの『データの品質』に照らし合わせると

図23

データそのものが最初から持っている属性上の検証であれば、誰でもできるでしょう。たとえば「年齢」というデータであれば

　「数値（数字は除く）」

という属性を持っています。

画像6

こんな画面だったら、そのほかにも

　「0～150しか入力が許容されていない」
　「未入力は不可」

というのも付随してくるでしょう。これはレビューアの力量云々関係なく、機械的に決まってしまう属性依存のデータ品質になります。

そのほか、利用者のニーズによって業務やシステム固有の仕様が存在する場合はたしかに"有識者"の存在が必要になってくるかもしれません。仕様書や設計書にすべて「誰が読んでも絶対に誤読することがない」様式で記載されていれば誰がレビューを実施しても問題はないのでしょうが、なかなかそんな仕様書や設計書にはお目にかかれません。結果的に、最も品質保証としては不安定な"有識者"に頼ることになってしまいます。

ですが、ここでも非常にまずいのは

　「レビュー品質を一定にするための施策」

が万全に整ったプロジェクト…というのを、過去１度も見たことが無い点にあります。もちろん、私はすべてを知っているわけではないので、私の知らないところでレビューの品質が非常に高度なプロジェクト…というのは存在していたかもしれません。

ですが論点はそこではなく、何十件と大手SIerが携わるような巨大なプロジェクトに関わっているにもかかわらず、そんな私ですら１度もお目にかかったことが無いくらい「レア度」が高いということです。

はぐれメタルも真っ青かもしれません。

画像7

とりわけこのレビューで恐ろしいのは大別して３点。

①観点は整理されていても、具体的なチェック方法は個人に依存している
②レビューアが複数存在する時、一人ひとりレビュー品質に個人差がある
③レビューするたびに、思い付き等が発生することを許容する

ことによって、レビューそのものの品質が安定しない…すなわち

　レビューごとに異なる品質基準となっている
　（厳密には、２つとして同じ品質のレビューは存在しない）

という点です。まったく同じ品質のレビューだからこそ、定量的に積み上げて分析することが可能なのに、レビュー自身が一定の品質を保たない以上、

　ＡのレビューとＢのレビュー
　１回目のレビューとｎ回目のレビュー

で、チェックの内容、濃さ、観点、ポイント、etc.…それぞれが異なっていては正しい分析なんてできるわけがありません。

製造業の場合、『量産』に入ってしまえば工場のラインが完成し、常に同じ製品を同じ質で作り上げることが求められます。だから当然、チェックの内容やタイミング、ポイント、頻度なども同じとなるように定められていることでしょう。

ですが、ソフトウェア開発ではそうなりません。

エンジニアがガチガチに仕組みで固められるのを嫌がりますし、なによりソフトウェア開発手法そのものが未だに発展途中にあって、常に進歩し続けているような状況だからです。


仮に、定量的品質管理において『レビューの指摘密度』を分析したところで、その偏りは

　「複数いるうちの１人レビューアが数回思い付きで言っただけだし、
　　そのレビューアも、すべてのレビュー時に気にしていたわけではない」

なんてことだってあるでしょう。ソフトウェア開発の現場では、それくらい自由で無法地帯が罷り通っているものだったりします。「じゃあ、レビュー観点に加えればいいじゃん」という人も出てくるかもしれませんが、どんなにレビュー観点に加えたところで、レビューアは勝手に自分で思いついたことをチェックしようとするでしょう。

四角四面に、カッチリと、機械的にレビュー観点に書かれたことだけを実施してくれるわけではないし、プロジェクトマネージャーも、自身のマネジメントがずさんなことを重々承知していますから、レビューアには"有識者"を充てて、彼らの経験則や独自のチェック観点をアテにしてするしかありません。だから、ほぼ絶対にレビュー自体の品質が一定化することはないと言えるのではないでしょうか（レビューが自動化できるツールでも生まれない限り）。


テスト品質の基準が定まらない

言いたいことは色々ありますが、今回は１点に絞ってお話ししましょう。
あくまで「定量的品質管理」との相性について明確にすることが目的なので、ここでは

　障害管理

について言及したいと思います（まぁレビューでも同じ問題を抱えているのですが）。

みなさんは、障害管理をどのようなルールや手順、基準を設けて実施していますでしょうか。…と聞くと、「Redmineを使ってます」とか「Backlogを利用しています」という回答が返ってきそうですが、それはあくまで「手段」の中の「ツール選定」というだけであって、運用のルールや基準、手順とは全く関係ありません。

仮にそう言ったツール群を使うことによって

　・手順はある程度ツールの使い方に依存して定まる
　・基準はツールの中で入力／選択できる内容に依存して定まる

ことはあっても、どうしても定まらない…言い換えるなら人が人の自由な判断・決断によって行えてしまう部分が無くならない以上、絶対に「定量的な品質の分析ができない」という問題は解決しません。

たとえば「障害原因」はどうでしょう。

画像8

どこの開発現場でも、まぁだいたいこんな感じで管理されていると思います。では、RedmineやBacklogに登録、記載する際に、

　「どの機能の、どんな現象で、どんな経緯があって、どんな状態なら、
　　どの区分を選択するべきか」

という観点において絶対に間違えることが無い判断基準を作っているプロジェクト…というのは存在していますでしょうか？

たとえば、プロジェクトにメンバーが５名いたとして、一人として誤った判断、異なった判断をしないような基準って設けていますでしょうか。

区分を細かく分割するかしないかはプロジェクトごとの自由ですが、分割した以上は何かしらユニークな『条件』というものがあるはずです。それらを明確に定義していますでしょうか。

残念ながら、私はそんなプロジェクト見たことありません。

厳密には、私がマネージャーをやってた頃でさえ、ごく一部を除いてしていませんでした（今なら出来ますけど）。

すると、全く同じ原因の不良であっても

　Ａさんは「コーディングミス」
　Ｂさんは「ケアレスミス」
　Ｃさんは「設計解釈誤り」

と分類してしまうかもしれません。そんな自由度の高い「障害原因」を分析して不良傾向を割り出したところで、なにか精度の高い分析結果は出てくるのでしょうか？

たとえば、「コーディングミス」という不良を選択してもいい条件ってなんでしょう？

以前にも書きましたが、「設計書とプログラムの間で記述に乖離があって」かつ

　・設計書に誤りがない
　・プログラムに誤りがある

という条件を満たした時に限って選ぶものではないかと思うのです。その動機的原因（なぜ？の部分）を深掘りすれば「設計解釈誤りでした」ということはあっても、本来"不良"を分類したいだけであれば、『コーディングミス』だけで十分ということがわかりますね。むしろ、

　「設計書のどことプログラムのどこが乖離していたか？」

という情報の方がよほど重要です。なぜなら、設計書の様式がそういう誤解を生みやすい書式になっているかもしれないからです。もしそうなら、他にも同じ理由で誤る可能性が高いことを意味します。

設計書の様式はこだわればこだわるほどいくらでも改善点が出てきます。「仕組み」を改善して成功の再現性たいのであれば、「人」に責任を押し付けないで、とことん現在の運用ルールや手順、基準、様式などを改善していくことです。

そうしていくことで、より定量的な評価精度も向上するのですから。


最後に

これらは「定量的品質管理」を批判したいものではありません。

ただ、多くの開発現場の実態を知れば知るほど、それらは非常に難しいと言わざるを得ないことがわかる…と言いたいだけです。だから、現状を改めない限りにおいては「ソフトウェア開発とはとても相性が悪い」と考えてしまうのです。少なくとも、私は現状のソフトウェア開発現場において、定量的品質管理を用いて

　「品質向上を図れ」

と言われれば効果のほどはさておき、おそらく実施できると思いますが、

　「品質を保証、証明してみせろ」

と言われれば即『無理です』というと思います。そして、少なくともＢ２Ｂのソフトウェア開発においては、見積り時点で「品質は100点満点からの減点方式」で進まざるを得ない以上、ただの品質向上で満足するような取り組みでは不十分であると考えています。

逆に、とことん障害管理（問題解決管理）を突き詰めれば、定量的品質評価なんて一切行わなくても、品質を保証することは可能である…となんとなーく考えています（この点についても、いずれもっと深く掘り下げて書くことができればと思います）。

もし仮に、定量的品質管理を「品質の保証が可能なレベルにまで押し上げる」というのであれば、

　・人の自由度の低減
　・基準の明確化

は今よりもはるかに厳格にする必要があるのではないかと思っています。

その意味では、

　・開発体系や開発標準が存在している
　・よほど厳格な運用をしている

企業やプロジェクトがあれば…ひょっとすると、今でも私の知らないところで定量的品質管理が、品質を保証できるレベルにまでうまく機能している…かもしれません。

機能しているかどうかは、次の点を確認すればわかります

　「発見すべき工程 ＜ 発見した工程」の不良が発生していない

…要は「抜け漏れがない」状態となっていることです。どんなに指摘数やバグ数が増えても、発見すべき工程ですべて発見できている場合は、定量的な品質管理が機能していることでしょう。

もちろん、しっかり仕組み化すれば抜け漏れは無くなっているはずですが、その上で定量的品質管理を行い、傾向／偏りを分析して、品質向上施策を打っているのであれば、次工程以降で「本来発見すべき工程で発見できず、次工程以降で大量に発見してしまった…」なんてことは起こらないはずです。もしも起きているようであれば、定量的品質管理はまったく機能していないと言ってもいいのではないでしょうか。

理想論を押し付けたところで、現場は何も変わりません。

私は、今の定量的品質管理のあり方は、まだまだその理想論…三現主義から離れた机上の空論に近いのではないかな？と考えてしまうのです。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。