過剰品質に関する西先生と秋山さんのツイートをまとめ

山田大介 @dsuke_yamada

@YasuharuNishi 続きですけど。担当者で｢過剰品質｣という逃げ言葉を使うのであれば、その前にきちんとエンジニアリングしてほしい。テストだってちぇんとできるし、設計だってちゃんとできる、まずそれが大切かと。作業者になっているから、作業が増えるんだよ。と叫びたい。

Yasuharu NISHI @YasuharuNishi

そういう技術者は、何をテストしていて何を保証しようとしているのかを分かっていませんから。 RT @dsuke_yamada: 私の見聞きした｢過剰品質」は、担当者の愚痴…「テストケースこんなに要らないよな、過剰品質だ」とか…いう「やらされ族」の愚痴に感じます。（現場の声）

Yasuharu NISHI @YasuharuNishi

その一方で、テストケースの「数」でしか判断できない品質保証部もいます。こちらも同様に問題です。 RT そういう技術者は、何をテストしていて何を保証しようとしているのかを分かっていませんから。 RT @dsuke_yamada …「テストケースこんなに要らないよな、過剰品質だ」…

山田大介 @dsuke_yamada

@YasuharuNishi ｢あなたは『なぜ』テストをしているのですか？」という問いかけに答えられない設計作業者やテスト作業者は多いように感じます。余談ですけど、昔職場で『なぜ』この作業をしているの？』を連発していたら、いじめと勘違いされた。

Yasuharu NISHI @YasuharuNishi

別に難しい話をしているわけじゃなくて、ジョブスが言うアイスホッケーのパックの話（元はグレツキー）をしているだけなんですけどね。適切な方向に滑れと言うべきで、滑るのを止めろ言っちゃいかんでしょ。 http://t.co/TZ740lOi

Yasuharu NISHI @YasuharuNishi

「なぜ」は詰問ワードですから。「責めてるんじゃなくて、理由が聞きたいんですよ。もっと改善したいから」と丁寧に言わないと、いじめだと思われますね。 (^^; RT @dsuke_yamada: …昔職場で『なぜ』この作業をしているの？』を連発していたら、いじめと勘違いされた。

Yasuharu NISHI @YasuharuNishi

その質問に答える技術がHAYST法やゆもつよメソッド、NGT/VSTePなどテスト開発方法論です。大事な技術ですね。 RT @dsuke_yamada: ｢あなたは『なぜ』テストをしているのですか？」という問いかけに答えられない設計作業者やテスト作業者は多いように感じます…

Yasuharu NISHI @YasuharuNishi

ちなみに、自分の組織の問題点を的確に把握しているソフトウェア技術者も、問題指摘・解決の技術を持っている人も、驚くほど少ないです。 RT @dsuke_yamada: ｢あなたは『なぜ』テストをしているのですか？」という問いかけに答えられない設計作業者やテスト作業者は多い…

Yasuharu NISHI @YasuharuNishi

品質管理って、問題解決なんですよ。本質的に。ルールを守るという技術じゃない。解決したはずの問題がリバウンドして再発しないためにルールやプロセスを定めるだけです。それを分かっている品質保証組織は、ソフトウェア企業には驚くほど少ないです。

Shukuguchi @Shukuguchi

@YasuharuNishi @dsuke_yamada なぜ？そうなるんでしょうね？ どこで意識（？）のかい離が生じるのか・・・ RT 自分の組織の問題点を的確に把握しているソフトウェア技術者も、問題指摘・解決の技術を持っている人も、驚くほど少ないです。

山田大介 @dsuke_yamada

ひとりでも多く本物のエンジニアを育てたい。その機会と場を提供していきたい。50代の使命として（でも体はやわやわ）。@YasuharuNishi ちなみに、自分の組織の問題点を的確に把握しているソフトウェア技術者も、問題指摘・解決の技術を持っている人も、驚くほど少ないです。

Yasuharu NISHI @YasuharuNishi

派生開発とカッコイイ用語を使ってますが、ルーチンの仕事をこなしているだけの技術者が多いからです。自分の技術の向上も、お客様の満足度の向上も、全然考えちゃいないんですよ。 RT @Shukuguchi: なぜ？そうなるんでしょうね？ どこで意識（？）のかい離が生じるのか・・・

Yasuharu NISHI @YasuharuNishi

でもそれは、考える余裕がないヒドい仕事を取ってくる営業の責任でも、そういうアサインをするマネジャーの責任でも、そういう経営をする経営者の責任でも、ソフトウェアの価値や技術力ではなく労働時間でしかオカネを払わないお客様の責任でもあるんです。現場だけを責めるのは間違い。

Shukuguchi @Shukuguchi

@YasuharuNishi おっと、趣旨を断っておかないと、変な反論が来ますよ。・・・それはさておき、「ルーチンワーク」をこなしている という話に同意です。（思考）フレームワークがいくつかありますが、フレームに沿うことが目的化する例を散見します。

Yasuharu NISHI @YasuharuNishi

暴走品質って、ダメな機能安全に似ていますね。ダメな機能安全とは、安全機能を増やしすぎて設計が複雑になり危険になる、という意味です（六本木ヒルズの回転ドアなど）。

Shukuguchi @Shukuguchi

@YasuharuNishi 本来は事故を防ぐための仕組みが、当初の目的と違う方向に進化しているとでもいえる状況は、（言葉選ばずに言うと）なぜそうなるのかとう点で興味深いです。（回転ドアの件は、仕組みがある理由が理解されずに設置・運営されていたという技術的でない話も聞きます）