2015-07-31

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

概要

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

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

発端や背景

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

統計的品質管理の功罪 from 工久納

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

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

kyon_mmの所感

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2015-04-05

週刊ソフトウェアテスト 2015-14 #swtest_jp

SWTestWeekly Testing

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

2015-03-29

週刊ソフトウェアテスト 2015-13 #swtest_jp

Testing SWTestWeekly

前書き

kyon_mmの意見

テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo － Publickeyを読んでいて、概ねいいと思ったのですが、この例示というか現場は~~クソだなー~~辛そうだなって思ったのが次の文章の後半です。

私は実はQuality Assuarance（品質保証）という名前を
（私たちの仕事の名前として）使うことは反対です。
質の高い製品を作る、確約するというのはプロジェクトの誰もが持つ共通の目的です。

テスターはコードを変更する権利はなありません。
スケジュールを変更することも、予算をコントロールすることもできない。
スコープも変えられないし、プログラマの採用もできずクビにもできません。
リリースするかどうかを決定する権限もありません。

チームにおいてテスター、プログラマー、マネージャーは得意分野の宣言でしかないのに、なにを言っているんだって感じ。人の採用については難しいかもしれませんが、最低でもコードを変更する権利がないっていうのはどうかと思いますし、コードを変更するスキルがあまりにもないテスターってよっぽど特定分野でハイスキルじゃないと辛そうっていう感じが。

2015-03-22

週刊ソフトウェアテスト 2015-12 #swtest_jp

SWTestWeekly Testing

前書き

2015-03-15

週刊ソフトウェアテスト 2015-11 #swtest_jp

SWTestWeekly Testing

前書き

kyon_mmの意見

What if testing was a part of the design processにおけるデザインの領域が基本的にUIに関する部分だったのですが、もっと他の面でもテスティングは関わっているのでそういった話がそういえばないなーと思いました。（該当のブログはUI系を専門としているようなので書いていないのは当然な気がしています。）

例えば、「どのテストスイートをやり直しやすくするかによって、プロダクトのどの部分のモッカビリティを高めるか」は、テスティングがプロダクト設計に強く影響をあたえるところです。

2015-03-08

週刊ソフトウェアテスト 2015-9,2015-10 #swtest_jp

SWTestWeekly Testing

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

2015-03-06

OOじゃないDDDについて

概要

モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。

端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。

DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ

Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。

エンティティ、バリューオブジェクト、アグリゲート、リポジトリなどのようにEricが紹介したDDDにおける実装方法は少なくともクラスベースOOを前提とした何かだと考えられます。