「無効にする」という言葉は案外むずかしいのかもしれない

「無効にする」という仕様でプログラマーとテスターが違うものを想像した話です。開発中の些細な出来事ですがツイートするには長すぎるのでこっちにメモしました。

ある日のこと 

ある画面に表示しているスライダーコントロールを触っていたら、おかしな現象に気づきました。Trackの部分をマウスの中ボタン（ホイールボタン）でコロコロしたら、値の増減が正しく行われる時と行われない時があるんですね。

説明上、スライダーコントロールの部品の名称を載せたかったので docs.microsoft.com .NET.Framework の Slider Class の図を直接リンクしました（わたしたちが開発してる製品とは無関係です）

担当のプログラマーTさんとFさんにその現象を見せて、そのあとチームでどうするか話し「中ボタンは無効にする」ことになったのですが、翌日修正したものを触ったらなんかおかしい。

• Trackの部分を中ボタンでコロコロしても値は増減しない。無効になっているのでOK
• Trackの部分を左ボタンで長押しすると連動して値が増減する。元からあった仕様でこれもOK
• 左ボタンを長押ししたまま（マウスダウンしたまま）中ボタンをコロコロすると値が戻ってしまう。あれ？

例えば、値が１０の時プラス方向に長押しすると１１、１２、１３、１４と増えていきマウスボタンを離したときに増加が止まります。これは良いのですが、長押ししながら中ボタンをコロッとすると１０（長押しする前の値）に戻ってしまう。

中ボタンは無効にすることになったので、長押ししながら中ボタンをコロッとしても何もせずに無視するが、わたし（テスター）が期待した動作でした。直しきれてないコードがあって中ボタンのイベントが発火したのかなと思いました。…にしてもどう作るとこうなるんだろう。

さっそくプログラマーTさんとFさんにその現象を見せたら「そうなるように作ってます」と衝撃の言葉が！えっえっどういうこと？と聞いてみたら「中ボタンは無効にすることになったので、中ボタンが押されたら前の状態に戻してます」とのこと。無効＝取り消し＝それまでの操作を取り消す意味で捉えたのか！なるほどー。*1 

結局、中ボタンを押しても無視する（何もしない）ことになったのだけど「無効にする」という言葉は案外むずかしいのかもしれない。今後「無効にする」が出てきたら無効とはどういうことか、どう動くのか（どう動かないのか）を具体的に話そうと思います。

*1:前の状態に戻すにはある時点での状態をどこかに記録しておく必要があるので作るの大変だったのではなかろうか…

バグが報告されたときにわたし（テスター）がやってること

バグが報告されたときにベテランプログラマーSさんがやってること（コード修正以外）

①見つかったバグに関連するチケットAを探す
②チケットAで何をTestしたのか確認
③なぜそのときにバグを見つけられなかったのかを考える
④チケットAに不足していたTest（今回のバグを検出できるテスト）を追加

— miwa (@miwa719) 2019年5月8日

こちらのツイートですが、思いがけずたくさんの方に見ていただきソフトウェア開発（特にテスト駆動開発）への思いやご意見を伺うことができました。ありがとうございます。

この記事では「バグが報告されたときにベテランプログラマーSさんではなくわたし（テスター）がやってること」をメモしておこうと思います。

自分以外の誰か（以降、同僚）がバグを見つけたときにあなたは何をしていますか。個人的に大変興味深いテーマですが、バグを見つけるための手法やプロセス、バグを見つけたあとの報告の仕方（バグ票の書き方など）と比べて取り上げられることが少ないように思います。もしかしたら当たり前すぎて話題にならないのかもしれませんが『当たり前にやってることに価値がある』と聞いたことがあります（これを書くモチベーションにしよう！）。

バグが報告されたときにやってること

以下にざっと列挙しましたが（★）は自分でバグを見つけたときにもやってることでした。消すのもなんなので載せておきます。（だいぶ書いてから気がついた）

• どのようなバグなのかを知る（★）
• どうやってそのバグを見つけたのかを教えてもらう
• バグを再現させてみる
• 自分ならそのバグを見つけられたかどうかを考える
• どんな風に作るとそのバグが起きそうかを考える（★）
• そのバグが起きるなら…（他のバグを探しに行く）（★）
• バグを見つけた同僚を褒める

どのようなバグなのかを知る（★）

うちのチームは面白いバグや重大なバグが見つかるとザワつくことが多く（何かが起きたらしいぞ）を感知したプログラマーやテスターが発生源に集まってきます。そこで見つけたてのバグを再現方法も含めて披露してもらうのですが、バグそのものの現象を知るには一番早くて確実な方法ですね。

朝会の中で（昨日そんなバグが見つかったのかー）とはじめて知るものもあります。現象自体はなんとなく想像できるものが多いのですが、分からなかったらその場で聞いて教えてもらいます。嫌な現象は起きてないけど今の実装だとまずい（いつかアプリケーションがクラッシュする）というものも報告されます。

これらのバグを修正していく過程でどんどん明らかになっていく「バグの原因（どこをどう間違ったのか）」「何を実装したときにこのバグが入ってしまったのか」「どこをどのように直すのか」に耳を傾け、またそれに伴うディスカッション（その修正方法だとこういうケースでダメなのではないか etc ）も合わせ聞いたうえで、徐々に「こういうバグなんだな」が分かるようになります。*1

どうやってそのバグを見つけたのかを教えてもらう

これは操作手順のことではなく、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかです。思考側（きっかけ、動機）ですね。

• 前に開発していた製品でこんなバグを見たことがあったので
• 画面の更新が一瞬遅くなったからあれ？と思った
• 処理が遅すぎて（退屈で）やることがないので押せるものを押してた
• チケットを ”クラッシュ” で全文検索して気になるものをやってみた
• いつも同じデータで試していて問題を見つけられなかったことがあったので
• 見た目はこんな画面構成だけど、内部的にはデータを二重管理しているから…

これを教えてもらうと、同僚が知っていることや経験してきたことや考えていることを（断片的ではありますが）自分のものにすることができます。例えば、これまで見てきたバグや自分自身の失敗談、いま何に注目し、何を心配しているのか、テストのやり方や得意なこと、こだわりや癖など。それを自身の開発（テスト）に活かすのです。これはオススメです。*2

毎朝、昨日見つけたバグやバグではないけど気になることを（チームを超えた）テスター同士で交換するのだけど、話を聞いたテスターがそれに関連するような（または似たような観点で）バグを見つけてくるのはおもしろい現象だなと思っています。一度や二度ではないから、偶然ではないと思っています。

— miwa (@miwa719) 2018年11月14日

ただ、実際に自分で経験したことではないので揮発性というか時間の経過と共に忘れてしまうことが多いです。そのことに気づいてからは専用のメモ帳に書いておき、ときどき読み返しては自分の脳にせっせと書き込んでいます。

バグを再現させてみる

先ほど ”朝会ではじめて知るバグも現象自体はなんとなく想像できるものが多い” と書きましたが、バグが直ったことを確認するときのために（このバグは自分の手で再現させて自分の目で見ておかなきゃ！）と思うものがあります。

• タイミングを狙うような操作が必要なもの
• 操作手順が複雑なもの
• 現象自体が分かりづらいもの

これらのバグは練習して確実に再現できるようにしておきます。例えば「この処理の一瞬の隙間を狙ってボタンを素早く二回押す」といった操作です。”現象自体が分かりづらいもの” というのは「動作がもっさりする」「画面がパシャパシャする」「ボタンが一瞬チカッとする」のようにオノマトペで表現されるものが多いです（うちのチームだけの特性かもしれませんが）。自分で再現させる前にバグを見つけた同僚に目の前で再現させてもらったり、どこがどうおかしいのか説明してもらうこともあります。パシャパシャとはこの現象を言ってるのだな、とかね。プログラマーが優秀で翌日にはバグが直ってしまうこともあるので（見ておかなきゃ！）と思ったらすぐやるようにしています。

自分ならそのバグを見つけられたかどうかを考える

同僚が見つけたバグを「自分なら見つけられたかどうか」を考えます。

• 自分ならその操作を試そうとしただろうか
• 自分ならその状況を思いついただろうか
• 目の前にそれ（バグ）が現れたときにおかしいと思えただろうか
• 設計や実装を想像できただろうか

遅かれ早かれ「自分でも見つけられたかな」と思うものはそれでよしとします*3。そうでないものは、そのバグを見つけられないのはなぜか、自分でも見つけられるようになるにはどうすればよいかを考えます。

• これから開発（テスト）するときに注目すべき点（観点）としてXXXを自分の中に取り入れよう
• バージョンごとにそんな複雑な仕様になってることを知らなかった → その仕様に詳しいNさんに教えてもらう
• この特殊な画像データを使うとおかしさに気がつきやすいのか！ → 使う
• 設計や実装を知らないとそこが怪しいなんて絶対想像できない → プログラマーSさんに説明してもらう*4

どんな風に作るとそのバグが起きそうかを考える（★）

これは自分でバグを見つけたときにもやってることなので省略します。

こんなバグ(現象)を見つけた！みたいなツイートを見ると、どんな風に作るとそのバグ(現象)が起きそうか考えてしまいます。

考えたことの当たり外れはどうでもよくて、あれこれ想像するのが楽しくて好き。

— miwa (@miwa719) 2018年6月21日

そのバグが起きるなら…（他のバグを探しに行く）（★）

これも自分でバグを見つけたときにもやってることなので省略します。

バグを見つけた同僚を褒める 

「これはいいバグ！」「よく見つけたなー」と思ったら褒めます。わたしも誰かに褒められたら嬉しいですもん。最近だと入社２年目のエンジニアKさんが「丁寧にテストしないと見つからないバグ」を報告していたので褒めました。Kさん「だんだん慣れてきたらこんなに（丁寧に）テストしなくなるかもしれません」と馬鹿正直に言うので「１０年後もその丁寧さを忘れないでーーーー」とお願いしました。

テスターNさんがとてもいいバグを見つけたのを朝会で聞いて嬉しくて「すごい！すごいわ〜」と言いながら思わず拍手してしまいました。拍手いいよね。気分が上がる。流行らせたい👏

彼女は半年前に隣のチームにJoinしたんだけど、最近めきめきと腕をあげてきてる。素晴らしいなあ。

— miwa (@miwa719) 2018年11月29日

同僚じゃなくても褒めてますね。

ある操作での画像の歪みを見つけるなんて @suginoy さんすごいな！

こういうのは気にしない人は気にしないと思う。画像としては分かるからね。だから気がつくのすごい。

— miwa (@miwa719) 2018年9月6日

おわりに

バグが報告されたときにわたし（テスター）がやってることをメモしました。同僚がバグを見つけたときって今の自分には無いものに気づいたり、足りないものを学習したり、他人の経験（暗黙知を含む）を自分のものとして取り入れることができる良い機会だと思っています。

テスト駆動開発

ソフトウェア・テストの技法 第2版

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト293の鉄則

新装版 達人プログラマー 職人から名匠への道

*1:分かったことが「本当に正しいかどうか」は気にしすぎないようにしてます。もちろん正しいのが理想なんですけど、自分で（こうなんだな）と思えればまずはよし。あとから分からないことが出てきたり疑問に思ったときにまた調べたり誰かに聞いたり、間違いに気がついたときにエラー訂正します。

*2:自分でバグを見つけたときも、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかを話すようにしています。

*3:見つけられたとは思うけどそのバグはもうすこし早い段階で見つけたかったな…と思うものがあります。何かの順番が間違っているのでしょうね。

*4:Sさんにもどのようなバグを見つけられるようになりたいのかを伝えます。Sさんはそれを踏まえてどう作られているのかの種明かしや秘密を暴露してくれるはずです。

とちぎRuby会議08 食に関するメモ #toruby

6月29日に開催した『とちぎRuby会議08』でわたしが担当した『食』に関するメモです。

ランチセッションのお弁当

今回のお弁当は『石窯イタリアン アンジェロ』さんに作ってもらった。

５月にアンジェロさんと打ち合わせをした。お弁当のボリューム感について悩んでいそうだったので「参加者の８割くらいは男性で２、３０代くらいの方もわりと多いかな……」と言ったところ「唐揚げのようなガッツリしたものがいいでしょうか？」と聞かれたので、前回（一昨年）のとちぎRuby会議07の『からあげ弁当』の話をした。（ランチセッションで用意した『からあげ弁当』の影響でパーティーのお料理が大量に余ってしまう事案発生。詳しくはこちら）

…かと言って少なすぎるのも困るんですけど……いい感じにお願いします…！とおまかせ（丸投げ）した結果が、こちらのお弁当。

１品１品、丁寧に作ってあるのわかる。彩りも豊か。夕方からはじまるパーティーのお料理とかぶらないように作ってくれた。気にしていた量も（全体的に見て）少なすぎず多すぎずだったと思う。というのは、パーティーのお料理が不足することもなかったし、大量に余ることもなかったから。

コーヒーマシン

• アンジェロさんにお借りした。とても良かった！
• ダークチェリーという豆だった。飲みやすかった。
• 何人かの方からレンタル料金を聞かれた。お料理なども全部こみでお願いしたので単品の金額はわからない。
• 開場前に設置＆使い方を教えてもらった。前回と同じ機種だったのに使い方をすっかり忘れていた。
• 適宜、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。簡単だけど１年後はまた忘れてると思う。
• 挽きたてのコーヒーは香りもいいし美味しい。売れ行きもよかった。
• 講演の最中にガーーッと豆を挽く音が響くの非同期処理ぽくて、好き。

用意した飲み物

• ペットボトル（２リットル）２８本
• 前回（８月開催、参加者数は今回とだいたい同じ）「１８本用意してほとんど残らなくて、あと５、６本あってもよかった」→ 今回増やしてみたけど１０本くらい残った。足りないよりは良い！
• お持ち帰りしてくれたみなさん、ありがとうございます。
• ウィスキンソン ジンジャーエール（辛口） ２４本
• パーティー用に冷やしたものを持ってきてもらった。
• 未開封の３本は @arton さんに持っていってもらった。ありがとうございます。
• そうそう、アンジェロさんがクーラーボックスで大量の氷を持ってきてくれた。冷たいほうがいいでしょうからって。
• 氷を用意するのは思いつかなかった。アンジェロさんさすがアンジェロさん。

軽食つきのパーティー

• ケータリングも『石窯イタリアン アンジェロ』さんにお願いした。
• お料理の搬入などはスムーズで特に問題なし。３０分くらいでセッティング完了。
• 今回のお料理もとても美味しかった。見た目も美しいし、食べやすいように工夫してある。
• いつも写真を撮り忘れるんだけど今回は忘れなかった。

• 毎回お料理の名前が分からなくて（あの美味しかったあれ）みたいな感じになっていたので、今回はお願いしてメニューをつけてもらった。
• 名前が分かるとこんなツイートができるのだ。名前重要。

とちおとめのパンナコッタ、美味しかったなー（2回目）#toruby pic.twitter.com/d1XLcCKd7Y

— miwa (@miwa719) 2019年6月30日

• ワインのコルクがこんな風に使えるなんて！（きれいなコルクは捨てないで取っておくか）
• ワインは赤と白１本ずつ持ってきてもらった。
• 白ワインは氷で冷やしておけばよかった。クーラーボックスに残っていたんだよね。氷。いま気がついた。
• 前回のメモによると「赤ワインはわりと早いうちになくなった。白ワインがグラス１杯分残った」→ 今回はほとんど残ってた。@ardbeg1958 さんがいなかったからかな。面白いな。
• ワインは @emorima さん @youchan さんに持っていってもらった。ありがとうございます。
• アルコール類の準備はよく分からないので（飲まない人もいるし）今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思う。
• @you_ssk さんが日本酒２本を差し入れしてくれた。ありがとうございます。
• アンジェロさんから『電気式石窯ピザ』使用のご提案があった（素晴らしい）
• 電源事情がクリアできれば挑戦したい…！焼きたてのピザはどう考えても美味しいに決まってる。

• 軽い気持ちで『電気式石窯ピザ』を調べてみたら１００万円くらいする。びっくりした。
  
  
  
• Lightning Talks は途中で短めの休憩時間を入れると良かったかもしれないね。お料理を取りに行ったり、コーヒーを淹れたりできるから。

その他

• テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます！
• お菓子の包装紙を使っていい感じに飾る方法を覚えた。@suginoy さんありがとうございます。セロハンテープの端っこを折り曲げておくとはがすとき楽になる小技も教えてもらった。

• @takkanm さんのお子ちゃまがかわいくて癒された。会場のうしろに並べた椅子でお昼寝してた。@m_seki のブランケットが大活躍！

• 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。 

追記（2019-08-18）

当日の本会の様子が『るびま』に掲載されました。思い出し用に貼っておきます。

magazine.rubyist.net

うちのチームのプログラマーはなぜテストがうまいのか

うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。

— miwa (@miwa719) 2019年6月24日

医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。

うちのチームのプログラマーはなぜテストがうまいのか。いくつかの要因が思い浮かびましたが、その中でも「毎日１時間、システムレベルのテストをしている」のが大きいのではないかと考えました。この記事では、タイトルから期待される結論（なぜうまいのか）を書くつもりはないのですが（ごめんなさい）システムレベルのテストをすることで得られそうなことをメモしておこうと思います。プログラマーがこんなにテストしてるチームはこれまで見たことがありません。これを１５年以上もやってるってすごくないですか？*1

プログラマーが毎日システムレベルのテストをしている 

うちのチームのプログラマーは全員、毎日１時間「テストの時間」が割り当てられています。テストの時間は朝会終了後の10:00〜17:00まで。好きな時間に勝手にやるスタイルではなく予め決まっていて、時間割表（テストPC * 6時間）はびっしり埋まっています。プログラマーAさんは10:00〜11:00（テストPC-001）、プログラマーBさんは14:00〜15:00（テストPC-002）のように。プログラマーCさんがテストPC-003の前に座ったら、わざわざ時計を見なくても（ああ、もう16時か）と分かるくらいに常態化しています。

この記事での「システムレベルのテスト」は「テストPC（ほぼほぼ実機環境）の前に座り、お客さまが使うのと同じようにソフトウェアを触るテスト」のことです。JSTQB*2で定義されている「システムテスト」とはすこし違うかもしれません。

テストは『本日のおすすめテスト』*3に従って実施します。テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。時間がきたら（テストが途中でも）おしまいです。そんなにビックリするようなことはしていないと思います。

システムレベルのテストをすることで得られそうなこと

• 自分が開発していない製品、機能そのものを知ることができる
  わたしたちの製品はそこそこ大きいこともありソフトウェアに関する部分だけでも複数のチームで開発しています。ひとつのチームが複数の製品を同時に開発しているので、プログラマーがシステムレベルのテストをするということは、自分以外のプログラマーが作った製品、機能も当然触ることになります。

• お客さまがどのように使うのか（ワークフローなど）を知ることができる 
• 実機での処理速度感
• システムレベルで見たときのバックグラウンド処理（特に他のチームが開発しているもの）を知ることができる
• 実際の現場に近いユーザーデータ環境がどういうものかを知ることができる
  開発PCだと少なめのデータやお決まりのテストデータで試すことが多いのではないでしょうか。
• 意地悪テストの残骸を見ることができる
  テストPCはテスターも使っています。テストPCを触るということはテストの残骸（データや操作履歴など）を目にすることになるので、どのようないじめ方をしているのかを知ることができます。
• 開発履歴を知ることができる
  テストケースからその機能の開発履歴（開発日記）が簡単に辿れるようになっています。どのような経緯で開発（設計、実装）してきたのか、関わったプログラマーは誰で、いつどんな変更が入ったのか、過去にどのようなバグが検出されたのか、どのように修正したのか…などがわかります。実際、開発日記を読みながらテストしているプログラマーの姿をよく見かけます。 

テストケースに書いてないことも試している

先ほど「テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。」と書きました。でも「テストの時間」にプログラマーが検出したバグを見るとテストケースに書いてないことも試しています。テストケースを誤読して偶然見つけたものもありますが「これ、絶対バグを見つけにいってるでしょ」と思うものも多いです。どういう心境でテストしているのでしょうね。「テストの時間」はプログラマーの帽子を脱ぎ、テスターの帽子をかぶっているのでしょうか。

おわりに 

うちのチームのプログラマーはテストがうまい自慢と「システムレベルのテストをすることで得られそうなこと」をメモしました。毎日テストをしているからテストがうまくなる（訓練みたいなもの）とも思いましたが、それだけではないのも実は分かっていて、いつか言語化できたらいいなと思っています。

*1:中の人たちはこれがすごいことだと分かってないのもすごい。自分たちの開発にはこれが必要だと認識してやってる感じ。

*2:Japan Software Testing Qualifications Board

*3:膨大なテストケースの中から現在の開発の状況に応じていい感じにテストケースを選んでくれるレコメンドシステムがあります。@m_seki が作りました。

ピクシー絵本の思い出

手のひらサイズ(10cm*10cm)の小さな絵本です

当時読んでいたものは引越しの際に捨ててしまい（あとになってそれを悔やんでいた）2000年にフェリシモ出版から復刻されたときに買い直しました pic.twitter.com/Eb6cwrA7QP

— miwa (@miwa719) 2019年5月3日

この中でも特にお気に入りだったのが、こちらの５冊。

当時、お出かけする時にはポシェットの中にピクシー絵本を２、３冊しのばせていくのが習慣になっていて（京浜東北線の電車の中でよく読んでいた）この５冊が選ばれることが多かったように思います。

この５冊のどこが気に入っていたのだろう？と思いながら読んでみたのですが、面白いことに気がつきました。『ひもぐつ』以外の４冊は「何かを作るお話」なんですよ。

ピクシー絵本の内容は「動物のお話」「家族のお話」「仕事のお話」「数のお話」「冒険のお話」「友達のお話」など多種多様です。その中で「何かを作るお話」が何冊も上位を占めるのですから「何かを作る」ことに対して、特に興味を持つ子供だったのかもしれないですね。

そんな子供も大人になり、医用機器を作る仕事に就き、毎日毎日「作っては壊し、また作る」ことを３０年近くやってますが、一向に飽きることがありません。

ちなみに『ひもぐつ』は、こんなお話です。

あたらしい赤いひもぐつを買ってもらった主人公（トーマス）が、お母さんにひもを結んでもらって出かけたら、かけよってきた子犬にひもぐつのひもをほどかれてしまいます。家にもどってお母さんにひもを結んでもらおうとしましたが、お母さんはパンを作っていて手が離せません。そのあともいろんな人に頼むのですがみんな忙しくて結んでもらえない。「だれも手伝ってくれないなんてひどいよ」とがっかりしていると、女の子が通りかかります。「わたしが教えてあげるわ。結び方をおぼえて自分で結べばいいじゃない」

トーマスは練習し自分で結べるようになりました。８９回目で！

これを読んで（わたしもひもぐつのひもを結べるようになりたいなー）と思いました。最後のページには「くつひもの結び方」が載っていて、まだ履いたことのない『ひもぐつ』に憧れ、眺めていた記憶があります。*1

*1:『ひもぐつ』は「できないことができるようになったお話」であり、そこにも惹かれる要素はあったと思いますが、当時は「ひもぐつへの憧れ」が強すぎて、著者が伝えたかったことは受け取れてなかったなぁ。

誰も使ってない機能にバグが見つかった時にどうするか

ある機能にバグが見つかりましたが、その機能を使っている人はいません。
1. バグを直す
2. 放置する
3. 機能を削除する
品質が上がるのはどれ？製品価値が上がるのはどれ？

— HARADA Kiro (@haradakiro) March 8, 2019

 

Twitterのタイムラインにこんなツイートが流れてきました。面白い問いですね。数年後にこれを見てどう思うのか（今の自分と比べてどう変わったのか、または変わらないのか）に興味があるので考えたことをメモしました。（自分宛てなので好き勝手に書いてます）

なお、考えている最中「いつか誰かがその機能をうっかり使うかもしれない」呪縛に取り憑かれて何度も脱線したので「その機能は未来永劫、絶対に使われることはない」を前提とします。あと「誰も使わない機能をなぜ作った？」「他の機能は大丈夫なのか？」についても考えないことにします（書いておかないと妄想が思考を邪魔するので書いた）。

「3. 機能を削除する」について

この中だと「機能を削除する」が好きです。めっちゃ好き。こんな風に書くと「好きとか嫌いで仕事してはいけません」と叱られてしまいそうだけど「機能を削除する」が好き。今の自分ならこれを選びます。

誰も使ってない機能だとしても製品の一部として提供している間は何かと手間がかかります。新しい機能を追加したり、既存の機能を変更するたびに誰も使ってない機能との関連や影響を考えるだろうし、リリースのたびに誰も使ってない機能が正しく動くことをテストしなればならないし。ちょっとした手間であっても塵も積もれば山となるわけで大変なんだよぅ。誰も使ってない機能にコストをかけるのはバカらしいのでやりたくない気持ちもある。そこに労力をかけるくらいなら、違うこと（やるべきこと）に使いたい。仕事とは言え（誰も使ってない機能なのに…）と思いながら作業するのは精神的に苦痛です。

「機能を削除する」ためのコストはかかるけど、以降「誰も使ってない機能」に関してコストはかかりません。良い。

お客さまにとっての価値

元々使ってないので機能を削除しても何も変わらないのかな。個人的にはシンプルになって良いと思うけど。その機能分プライスダウンするなら価値は上がりますか？何に価値があると思うのかは人それぞれでむずかしいと感じるけど、価格は分かりやすいと思う（この文脈では「安かろう悪かろう」は無いものとします）。それ以外だと何だろう。今後は「誰も使ってない機能」のために消費していた（消費するであろう）リソースを他の何かに割り当てられると思えば「新しい価値」を提供することは（計算上）可能のはずなのだけど…

「1. バグを直す」について

製品として提供してしまった機能はそう簡単には削除できません（少なくともうちの製品はそうです）。となると「バグを直す」か「放置する」のどちらかを選ぶことになります。ここで「バグを直す」を選びたくなるのは…自己満足なのだろうな。バグがあるのが分かっているのに直さないでいるのは気持ちが悪い。直せばスッキリする。ただそれだけなのだな。バグを直すには多少なりともコストがかかるので「未来永劫、使われない機能」なら放置した方が安い。

お客さまにとっての価値

元々使ってないのでバグを直しても何も変わらない。うっかりリリースノートに「バグを修正しましたっ」と書いたら（そんな機能は使ってないし、むしろ要らなくね？）（それよりもこっちの機能をどうにかしてほしい）とか思われたりしてね。価値が下がってしまう可能性がある。

「2. 放置する」について

お客さまにそのような問題があるということをお知らせした上で「放置する」なら受け入れられそう（自分が）。何もしないでそのまま放置するのと、バグを直すことにしたのに（優先順位が最下位のため）いつまでも直さないでいるのは似ている。これについてはまだ自分の中にうまく取り込めていない感じ。全てのバグを直すことはできないのは分かっているんだけどな。完璧主義者でもないのに変なの。

お客さまにとっての価値

元々使ってないので放置しても何も変わらない。問題を公表したことが良いイメージ（誠実性や透明性など）につながるのなら、なんらかの価値を与えられるかもしれない。うーん。ちょっと無理があるね。何も変わらないですね。

ここまでのまとめ

本題とは外れますが「自己満足のために仕事してる部分がある」が観測できたのはよかったです。これからは暴れる前に何かを主張する前に（これは自己満足かな？）と問いかけるようにしたい。あと熱中してる時とか…（身に覚えがある）。スッキリした時もかなり怪しい。スッとしたとかツイートしてる場合じゃないわよ（笑）。すこし消化不良するくらいが私にはちょうどいいのかもしれないな。いずれにせよ、仕事に自己満足はいらない。

「多数決で決める？」

開発現場で課題や問題を解決していく最中におこる「小さな会話」が「よいチーム」をかたち作る（のではないか）という仮説から、うちのチームでよく使われる「フレーズ」をいくつかのイベントで紹介したのですが、とうとうボット化する者が現れました。これは感慨深い…。ありがとうございます！

yoshitake-1201.hatenablog.com

ちなみに私達は、資料で詳しく紹介されてないフレーズが通知されたときは「こういう風に使ってるんじゃないかな？」と想像しながら意見交換しています。
（なお、我々の中では「多数決で決める？」というフレーズは、「このままだと多数決になっちゃうよ、それでもいいの？」という感じで使っているんだろうという結論になりました。今度ご本人たちにお会いしたときにどういう感じで使っているのか聞いてみようと思っています）

詳しく紹介していないフレーズもこんな風に話題にしてもらえるのは想定外でした。これもまた嬉しかったです。福岡と栃木ではいつお会いできるか分からないので（笑）「多数決で決める？」というフレーズについて解説しておきたいと思います。

こんな良いことが起きる

• 決めようとする、決まる
• ハッとする（関さんに決められてしまう、やばい！）*1
• それまで黙っていた（実は意見のある）人が口を開く（そうならざるを得ない）
• もう少し（ちゃんと）考えたくなる、考える
• 難しいかもしれないけど、より良いものを選べる

状況

• どうでもいいことを話しているわけではないのに、みんながノッてこない
• 論点がずれてきた
• こうしたほうが良いと薄々気がついているのに言わない（やれるのにやりたくない雰囲気を出してる）
• 間違ってはいないけど（最適解ではない）安易な方に流れてしまいそう

解説

「多数決で決める？」は「多数決で決めちゃダメなもの」に使います。普段の開発の中で何かを決めたり選んだりするシーンってよくあると思うのですが、多数決で決めていいものなんて無い（そういう開発を私たちはしていない）んですね。みんなそれは分かっています。

状況にも書きましたが、話し合っているうちに論点がボヤけてしまうことってあるんですよ。だんだん理詰めではなくなってきて「納期がー」とか（もう今日は結論までたどり着けなくてもいいかぁ）と時間切れを狙って（るように見えるだけかもしれないけど）ダラけてしまう、みたいなの。ないですか？

そんな時に誰かが「じゃあ、多数決で決める？」と言うと（いやいやいや、そうじゃないだろwww）と思いますし、その一言で場の雰囲気も変わります。みんなでクスッとするのがいいんですよ。

おまけ

「多数決で決める？」と似たフレーズで「うなずきんで決める？」があります。意思決定支援ツール『うなずきん』に話しかけると「うんうん」と頷いてくれるので、自分の都合のいいように話しかけて使うんだけど、たまに頷かない（首を左右にふる）時がある。うちのチームに３個くらいあります。

うなずきん NatureVer. Green

おまけのおまけ

うなずきん以前の意思決定支援システム（懐かしい）

*1:間違ってはいないけどヘンテコで難しいやつにされる可能性がある