うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

RE:統計的品質管理の功罪

概要

SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね?よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。

もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。

発端や背景

SNSで下記のスライドに対する言及が多数ありました。

"辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか?"と批判するかの2つが多かったように見えます。

私もこのような行数あたりのバグ数に関してつらい思いをしたことはありますが、やはりこれはあまりにコンテキストが広すぎるという感じです。

kyon_mmの所感

「ソフトウェアの品質を評価するのにコードを一切見ていない」というのは、たしかによくないかもしれないですが、 では、この現場では例えば「こういった意味で品質の良いコードです」ということは伝える努力はしたのでしょうか? それがコードを見なくてもわかるようにです。

僕は、プログラマーじゃない人にでも品質を評価してもらうというのは重要だと考えています。 最終的にはスポンサーがコードの品質にもお金を払っているわけで、 スポンサーにも同じように説得する場面が存在するであろうからです。

説得しなくても十分な場合もあるでしょう。 そのときには、この品質管理担当さんがいなくてもいいか、 もしくはもっと違う方法を取ってもらうことでサポートしてもらう必要がありそうです。

仮に「コードは、実物を見ないと評価できない」とあきらめるのであれば、 僕はそういった態度についてエンジニアとしてある種の諦めを感じますし、 あまりソフトウェア開発の未来に前向きではないなという印象を持ちました。

GitHubのIssueやコメントを求めているってどんだけ狭い話なの?

35ページに「僕たちが望んでいるもの」として、おそらくGitHubのIssueやコメントのような画面表示がありました。 そして次のページには「現実」として行数とエラーの原因や発生フェーズが書かれていました。

どちらも必要な情報だと僕は思っています。また、どちらかだけをほしいってどんだけ狭い領域で仕事しているんだよって感じです。 むしろ、この2つで足りるとでも思っているの?大丈夫?って感じが。

例えば後者の情報が長年蓄積され、共有されたことで「何をつくるかをハッキリさせることが重要だ」(要件定義のミスはやばい) という共通認識を多くの人が持っています。それらにどう対応するかはプロセス次第です。 まぁ、この情報の取り方が正しいかを考えていない人もいるでしょうが。(個々のプロジェクトでほしい情報は異なるよねー。的な)

Web上で気軽にコードのちょっとした設計について議論できるのもとても大切です。 ただ、IssueというかコメントもWeb画面上でひたすらやりとりされて、必要な情報が一切ないというのはいろんな場面で遭遇します。 あとは、楽しいと思っているだけで実際の効率について考えたことがどれくらいあるのかというのも気になります。 個人的にはチャットツールにも同じことを感じています。 (自分はSlackを使っていますが、チームメンバーで使い方ルールをつくりました。)

アジャイルの人はこれだからとか言っている人達もおかしいよね

このスライドに対してSNSの反応でアジャイルの人だからーというのが見受けられましたが、 どこにアジャイル要素があったのかわかりませんでした。

永和だから?Rubyって書いてあったから?GitHubっぽいページがあったから?コードの話をしたから? これらであれば、アジャイルかどうかなんて全く関係ないです。

仮にこの発表のコンテキストがアジャイルだったとして、 少なくとも資料上からはアジャイルに顧客への価値提供、チームビルディング、改善を考えているようには見えませんでした。 つまり、アジャイルな発表ではカケラもない。

なにがしかのイメージでアジャイルだからーとか言うのはよくないかと思います。

SQCの例としてはあまりに貧弱ではないだろうか

イベントの都合かもしれないのでなんとも言えないのですが、 この内容でSQCというのはあまりにも貧弱な内容で、お前が言いたいのはなんなんだって感じです。

SQCについてなにか思うところがあるなら、本来のSQCの使い方とどうずれてしまっているのかなど言うべきだし、 SQCがクソだと思うなら、こんな指標値よりもっと使えるものあるんだけど!とか言えばいいだけです。 とりあえずエンピリカルなソフトウェア工学の書籍や論文を片っ端から読んだらどうなんですかね。ええ。

こんな貧弱な批判でやつらを倒せるとでも思ってんのか!てきな。

コードを書籍で例えて考えてみる

最後になりますが、僕の考え方としてコードを書籍でたとえます。 初めてのアウトプットになるのでほころびがあるかもしれませんが、僕はよく頭の中でこう考えているという具合に思ってください。

まず、コード行数というのは、書籍でも行数にあたります。 それで、行数あたりの間違いが少ない方がいいっていうのは、例えばですが、書籍でも行数あたりの誤字脱字がどれくらい少ないかという話にも通じます。 書いてあることに整合性がないとか、間違った情報が書かれているとかも、行数ごとに見ることもできます。

例えば、素晴らしい発見を伝える書籍でも誤字脱字があまりにも多かったり、表現が統一されていなさすぎると読みにくいですよね。 なので、その書籍に「ユニークですごい」「文章力が低い」みたいな評判がたつかもしれません。

では、書籍同士の比較をするときに、文章力の低い人と、文章力の高い人で同じテーマの書籍について同様に「行数あたりの間違い」で見れるでしょうか? 例えば、文章をうまく書ける人であればそもそもだらだらと書く必要がありません。 そう、ここがソフトウェアのコード行数と同じようになるのです。シンプルに伝えることが1つの美徳とされます。 (もちろんそうではない分野もあるでしょうが、1例としてです)

ですが、行数あたりの誤字脱字やどれくらい整合性のとれない主張を書いてしまうかを数値で見えるようにすること自体はとても意味があります。 例えば、その著者のなかでは成長のメトリクスに使えるかもしれません。 実際には編集さんがものすごい頑張っていてそのようなメトリクスは世の中にないかもしれませんが、 編集さんがどのように思っているかを話すと、ある程度いえる数値があったり、どうやってレベルなどを感覚的に分類しているかはありそうですよね。

このように「じっくりと読んでわかる品質」もあれば「伝聞ベースの統計的に見てもわかる品質」などもあります。 なので、個人的には行数で計測すること自体にはあまり問題ないと思っています。 当たり前ですが、どうやってその行数を使うかが重要であり、くだらない方法をかざす人を見ただけで方法論を非難するのはちょっと芸がないです。