CAT GETTING OUT OF A BAG

What the tester is thinking.

テスターのあたまの中（サマータイム開始日と終了日）

 

サマータイムが話題ですね。システムやソフトウェアに手を入れなければならないようなサマータイム導入には反対ですが、サマータイムをお題に「起きたら嫌なこと」や「気にしたいこと」を想像するのは面白い。思いついたことをメモしていこうと思います。*1

この記事は

  • きれいにまとめるつもりはないので、粒度はバラバラです
  • 重複しても気にしないことにします（無理に１つにまとめると隠れて見えなくなってしまうものがある）
  • わざと言葉を曖昧、省略してるものがあります（ここからさらに想像を膨らませたい）
  • 不定期に更新します
  • こちらのBCN＋Rさんの記事が、とても分かりやすかったので、これをお題にしました。図もモディファイさせていただきました（気にしたい時刻、時間帯を、赤い線や丸印でマークしました）

www.bcnretail.com

サマータイム開始日の午前２時、３時台はスキップされる

f:id:miwa719:20180815092931p:plain

  • バッチ処理が実行されない
  • 予約処理が実行されない
  • １日＝２４時間を意識した処理がおかしくなる
  • 経過時間を意識した処理がおかしくなる
  • この日、週、月、四半期、年などの統計値がおかしくなる
  • 歯抜けの日時はおかしくないのに異常だと判断される
  • 実行すべきでないバッチ処理が実行される
  • 実行すべきでない予約処理が実行される
  • 実行すべきでないタイムアウト処理が実行される

サマータイム終了日は午前２時、３時台が２回訪れる

f:id:miwa719:20180815165713p:plain

  • 実行すべきでないバッチ処理が実行される（２回目）
  • 実行すべきでない予約処理が実行される（２回目）
  • 実行すべきでないタイムアウト処理が実行される
  • 順番に並べることができない
  • タイムアウト処理が実行されない
  • 重複したデータが作成される
  • データが上書きされる
  • データが存在することを前提に動いている処理がエラーになる（例えば、１回目でデータ削除、２回目で削除するデータは存在しない）
  • １日＝２４時間を意識した処理がおかしくなる
  • 経過時間を意識した処理がおかしくなる
  • この日、週、月、四半期、年などの統計値がおかしくなる
  • 重複した日時はおかしくないのに異常だと判断される
  • 実行すべきでないバッチ処理が実行される（２回目）のは、実は正しかった（仕様が間違っていた）
  • 実行すべきでない予約処理が実行される（２回目）のは、実は正しかった（仕様が間違っていた）

その他

  • ファイルやデータの作成日時、更新日時、削除日時を意識した処理はないか
  • 日時を元に計算してるものはないか
  • 時間、または単一時間内を何かでカウントしているものはないか
  • 表示用の日時を誤って計算用に使ってしまう
  • 内部処理用の日時を誤って表示用に使ってしまう
  • 表示用の日時と内部処理用の日時の変数名が似ているかもしれない（ミスしても気づきにくい）
  • お客様に直接関わる機能のサマータイム対応は万全だったが、メンテナンス用のツールやサービスツールが対応できていない（サマータイムに対応したことで、これまであまり使われることがなかったツールを使う羽目になることを予想）
  • インストール時に使用期限を設定しているものはないだろうか
  • お客様の環境で、これまで一度も通ったことのない「エラー処理」が初めて実行される（例えば、日時データがおかしいことが原因で）
  • お客様が使わないデータ（例えば、アクセスログ、操作ログ、エラーログ）がサマータイムに対応してなかった（不具合の解析などで困る）
  • サマータイム用のロジックが、サマータイムではない日、月、年に実行されてしまう
  • オンラインヘルプ、取扱説明書などへの記載（サマータイム対応）を忘れる
  • 自システム（サマータイム未対応）では問題が露見しないが、接続している他システム（サマータイム対応）では日時エラーになり、結局やりたいことができない
  • サマータイム対応前に登録したデータが、正しく処理できない
  • 接続している他システムがサマータイムに対応してるとは限らない（おかしな日時データが指定されても、システムが耐えられるか）
  • 接続している他システムがサマータイムに対応してるとしても、自分たちが想定してる日時データを指定してくるとは限らない
  • サマータイムに対応するために、データフォーマット、データベース、ファイル構造が変わるものがあるかもしれない
  • データサイズが変わったことで、受け渡しに使うデータ群の１番最後の項目が正しく処理されないかもしれない（１番最後の項目が、今回追加した日時データでない場合は、注目されにくいかもしれない）
  • サマータイムは馴染みがないため、正解を想像するのが難しい（不具合かどうかがわかりづらい）
  • その仕様は本当に正しいのか、お客様のやりたいことができるようになっているだろうか 

*1:わたしはテスターとして組み込み系製品の開発に従事しています。

サディスティックミワテスト

はじまりはこのツイート

で、こうなって

技術顧問にロゴを発注して*1

f:id:miwa719:20180812141607j:plainf:id:miwa719:20180812141558j:plain

Tシャツを作ってもらいました

suzuri製です。Tシャツをクリックしてみてね。 

suzuri.jp

うれしい。ありがとうございます！

追記（2018.08.25） 

druby.booth.pm

druby.booth.pm

 

*1:"Sadistic Miwa Test" → サディステックミワテスト → サディステック・ミカ・バンド → おお、懐かしい → 1970年代 → サイケデリックな感じで、とお願いした。

ベテランプログラマーとバグの調査をしたときのこと


これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作（入力）が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 

プログラマーに状況を説明する

おかしな状態になる前に、どんな操作（入力）をしていたのか。たまたま、関係しそうな画面を４枚ほどキャプチャーしていたので、それを１枚ずつ見せながら、Sさんに説明しました。

miwa「次にこの画面ですけど、Aの値は、デフォルトの値が XX だったんですが、YY に変更しました。で、Bの値は、Aを変えたことで自動的に ZZ になったので、それを 1.4 に変更して、、
Sさん「うわあああ、ここに 1.4（小数点の値）を入れたんですね
miwa「入れました。小数点の値、嫌なんですか？
Sさん「嫌かも、というか、小数点の値はあまり試してません…


その後も

「きゃーーー、やめてーーー
「こわい、こわい、こわい
「これは、何が起きるかわからない


Sさんのリアクションは、控え目に言って最高でした。こういうのって（テスターにとって）ものすごく有難いんですよ。

  • プログラマーが「やって欲しくないこと、嫌なこと」を知ることができる
    わたしの脳内：ここは大したことしてないと思っていたんだけど、内部の処理は、想像以上に複雑なのかも。もしかしたら、Sさんもまだ不安なところがあるのかもしれないな。もう少し時間をとって、テストしたほうが良さそう。
  • プログラマーが「まだ試してないこと、試しづらいこと」を知ることができる
    こんなことを聞いたら（テスターだったら）とりあえず、すべての入力項目に、小数点の値を入れてみようと思いますよね。それから 1.4 以外の値は大丈夫なのか、数値を丸めているのだとしたら、どのような丸め処理をしているのか、有効桁数はいくつなのか、いろいろ気になってきます。

このような情報は、当然、設計ドキュメントには載ってない。だから大変貴重です。*3

どの操作が引き金になっているのかを探る

わたしがやったことを一通り話した後に、どの操作が引き金になっているのかを探りました。*4いま思うと、もうこの時点で「この現象が起きるのなら、どの操作（入力）が関係しているのか」が、Sさんにはある程度わかっていたんだと思います。話を聞きながら、Sさんの頭の中には、プログラム（コード）が浮かんでいたのでしょうね。


今度はSさんの話を聞きながら、わたしが手を動かします。ペアテストに似ていますね。

「まず、ここは関係ないはずなので、ここの設定は全部オフにしてみましょう
（カチャカチャ、ターン）
「はい、再現しますね（想定どおり）
「では、ここも関係ないと思うので、ここもオフにしましょう
（カチャカチャ、ターン）
「はい、再現しますね（想定どおり）
「この現象が出るのは、◉◉の値がおかしくなっている、ということなんです
「◉◉の値は、AとB、あとCの値が関係してるんですよ
「ということで、AとBとCの値を変えてやってみましょう
（カチャカチャ、カチャカチャ、ターン）
「再現しなくなりましたね。ということは…


すこしずつ条件を変えながら「これだ！」という操作（入力）に迫っていきます。いくつかのパターンを試しました。引き金になる操作を特定したのは、それから１０分後くらい。やっぱり早いわー。

今回のケースは、入力値だけでなく、操作順も関係していたので、再現手順を見つけるのが大変なバグでした。同じ値を設定しているのに、再現するときと、再現しないときがあるのです。こういうのは難しいですね。Sさんのナビゲーションがなければ、１時間かけても、たどり着かないかも…。*5

「実は、AとBに値を入れた後に、ある計算をしていて、ほら画面にも計算結果を表示してますけど、これ以外にもいろいろ計算してるんですよ。表には見えないんですけどね。裏でものすごい計算が走ってる。特にBね。だから、Bに値を入れた直後に、おかしなことになっているのかもしれないな。


わたしの脳内に「Bはヤバい、Bに注意」が刻まれました。こういう情報も、テスターにとっては貴重です。

Sさんの予想どおり、Bにある値を入れた直後に処理を実行すると、再現しました。Bにある値を入れた後に、違う項目（例えば C）に値を入れてから処理を実行すると、再現しませんでした。

こんなのを目の前で見せられると、プログラマーすごいなあ、これは真似できない、と思いますね。鮮やかでした。素晴らしかった！

ベテランプログラマーに共通する、ある行動

確信はないのだけど、前々から（もしかしてそうなのかな？）と思っていることがあります。それは「ベテランプログラマーほど、不安なところを包み隠さず、丁寧に教えてくれる」（傾向がある）ということなんですけど、今回のことで、うちのチームだけではなく、隣のチームでも観測することができたので（やはり、そうなのかもしれない）と思っている、今日この頃です。*6

おまけ

今回の「再現手順を見つけるのが大変なバグ」を説明するのに、簡単な画面を作りました。でも、文章で伝わりそうだから、いらなかったですね。せっかく作ったので、貼っておきます。（ラベルの枠のコーナーを丸くするやり方を覚えました！）

f:id:miwa719:20180805204133j:plain

プログラマーとお仕事をするということ

プログラマーとお仕事をするということ

 

*1:Region of Interest：操作の対象として選ぶ領域（関心領域）のことで、画像処理などで使われる用語です。

*2:ここのところ、隣のチームで絶賛開発中の「ある機能」をテストしている。

*3:この情報は、同僚のテスターや、隣のチームのテスターにも伝えます。

*4:Sさんがいちいち悲鳴をあげるので、観客が２名もついた。

*5:まあ、その前にうちのチームの誰かが、わたしの異変に気がついて、１時間もやらせてもらえないと思うけど。

*6:観測範囲がものすごく狭いので、気のせいかもしれません。書籍『プログラマーとお仕事をするということ』にも、そんなことは書いてなかった。

テスターと内部設計情報

大層なタイトルをつけてしまいましたが、先日 Twitter に連投したことをブログに残しておきたいだけのエントリーです。（すこしだけ、補足しました）  

 

 

 

 

 

 

 

 

今回ツイートしたのは「画面に表示する項目と内部変数の関係」ですが、このように「内部設計情報」を知ることで、心配事が変わる（テストが変わる）のは、わりとよくあります。（だからと言って、なんでもかんでも知りたい、という感じでもないのですが…）

どんなところの「内部設計情報」を知りたいと思うのか。すこし考えてみたのですけど、一つ言えるのは、テストが大変そうなところ（似たような項目が多いとか、何かの種類が多いとか、状態がたくさんあるとか）は、特に知りたいです。*1また、知りたいと思ったときは、すでにその時点で、２種類くらいのやり方を予測*2していることが多いように思います。

ただこれは、プログラマーがどのように設計したのか、を当てることを目的とした予測ではありません。ですので「内部設計情報」を知ることができないときでも、システムやソフトウェアを動かして得られる結果から、それを予測し、テストに活用します。*3

これは、テスターによく見られる習性なのでしょうか？
いつも使っているお気に入りのアプリでも、こんなことをしていますね。（以下のツイートを参照）

 

Amazon社のエンジニアに「内部設計情報」を聞くことはできませんので、動かして得られた結果から「内部設計」を予測しています。（これ、Safariでもうまく動かなかったのですが、そのうまく動かないっぷりがiPhoneアプリと同じだったので、ほっとしました。）

 

そうそう、秋山さんからこんなコメントをいただいたので、いつかお返事したい。

 

*1:例えば、接続デバイスが返してくるエラーの種類が５０種類あったとして、その５０種類のエラーコードをプログラムでどのように処理しているのか、とか。

*2:プログラマーがするようなガチなソフトウェア設計ではないが、それとセットで、こんな風に作っていたら、こんな確認をしておかないと、とやりたいテストのイメージも浮かんでいる。

*3:わたしたちは、非常に多くの組織、チームで製品開発をしているため、他の組織、チームが開発している部分の詳細については、知らないことも多いのです。

テストする順番を気にする

以前、ある方から「普段、当たり前にやっていることって何ですか？」と質問があり、その場では即答できなかったのですが、最近になって（これ、当たり前にやってることかも）と思うことがあったので、紹介します。

わたしは、テスターとして組み込み系製品の開発に従事しています。ですので、この記事は、その「テスト」に関して「当たり前にやっていること」のひとつになります。

f:id:miwa719:20180715141033j:plain

テストする順番を気にする

わたしは、１日の大半をテストに費やしているのですが「テストする順番」を、かなり（無意識に）気にしてるようです。ただ、急ぎでやらなければならないもの（緊急性の高いもの）は、先にやるので、ここでは除きますね。

どのように順番を決めているのか。その順番にしている理由、順番を決めるときの材料やシグナルなども織り込みながら、１日を３つに分けて紹介します。

  • 午前中
  • 午後１時〜２時
  • 午後２時〜６時 

午前中

問題が出たら嫌なところ、複雑なところをテストします。もうすこし具体的に書くと、こんな感じです。

  • 問題を見逃すと生命、自然環境に関わるようなところ
  • 問題を見逃すとお客様の業務に支障が生じるところ
  • 製品化の中でも特に重要な機能
  • 複数の機能が絡み合ってそうなところ
  • 過去に不具合が多く出ているところ
  • 他のチームにも影響がありそうなところ
  • 開発中に設計や実装が二転三転したところ
  • 担当プログラマーの顔が不安そうなところ
  • 担当プログラマーの顔は普通なのに、他のみんなが不安そうにしてるところ

朝会で脳内をウォーミングアップ

わたしたちのチームは、朝会（９時１５分〜１０時）で、チケットの読み合わせをしています。これをやることで、テスターのわたしも、今、開発してるものが、どんな状況にあるのか（どこが、なぜ、うまくいってないのか、昨日困っていたあれはどうなったのか、内部の設計や実装など）を知ることができます。同時に、今日からテストできるもの（昨日コミットされたチケット）もわかります。プログラマーひとりひとりの表情を見ながら、その言葉に耳を傾け、場合によっては質問し、テスト可能なチケットを整理しながら「テストする順番」を決めます。ソフトウェアは毎日変化しているので、それに合わせてテストも毎日調整します。

午前中に「問題が出たら嫌なところ、複雑なところをテスト」をするのは、いち早く重大な問題を見つけて、チームのみんなにお知らせしたい、のも理由の一つなのですが、それよりも（これは多くの方がそうだと思いますが）朝会の後のこの時間が、１日の中で最も脳内がスッキリしていて、冴えているからです。おかしさを見つけられる感度が、就業時間の中で最高のはず。おそらく身体能力も相当高い。*1

気分が乗らなくて後回しにしたテスト

その他にも午前中にテストするものがあります。それは、前日までに一度はトライしようとしたけど、挫折してやめてしまったテストです。

  • 思っていた以上に時間がかかり、途中で集中力が切れてしまった
  • テストするための準備が何となく面倒
  • テストする場所が極寒で風邪引きそう／徒歩で５分もかかる（しかも雨降ってる）

などなど。理由はいろいろありますが、要は、気分が乗らなくて後回しにしたテストです。人間だからそんな日もあるよね。

これは、もう自分で分かっていますからね、午前中にやらないとダメですね。今日も午後に回したら、また挫折します。これはもう仕事だから仕方ない、今日こそはやるぞ！と思ってやります。*2

午後１時〜２時

それほど頭を使わなくてもできるテストに充てます。例えば、画面に表示する文字（ラベル）の位置、色、メッセージなどの変更、アイコン（絵）の貼り替えとか。まあ、そんなところでも、あとから問題が見つかって（そんな作りになっていたとは！）となることもあるんですけどね。この時間帯は、どうしても集中力が低下してしまうので、自分自身のテストのミス（見逃し）も多くなります。人間だから仕方ない。だから、頭を使うような難しいテストや、混み入ったことは、極力やらないようにしています。

午後２時〜６時

上記に書いたもの以外をテストします。午前中の続きをやることも多いです。また頭が冴えてきますからね。乗ってきて過集中になるのも、大抵この時間帯ですね。そうそう、集中して物事に取り組むのは良いことですが、集中してること以外（外側）は「散漫」になっているんですって。それを聞いたときに（確かに、そうだわ）と思って、ちょっとゾッとしました。だから、集中しすぎないために１時間ごとに休憩するよう、心がけています。*3
また、午後５時以降に取りかかったチケットは（大丈夫だろう）と思っても close しないことにしています。これも「疲れ」から誘発されるかもしれないミスを防ぐためです。翌日にもう一度、軽く確認してから close します。（週末の夜にコミットしないのと、似てるかもしれませんね。）

全体的に気にすること

わたしたちは、複数の製品（バージョン）を同時に並行開発しているので、スケジュール（締め切り）を気にします。締め切りが早いものは、できるだけ先にテストできるように調整します。締め切りが遅いものは、重要な機能であっても後回しです。（例外はありますが）

それから、担当プログラマーが今日いるかどうかも気にします。例えば、テストできる状態にはなっているけど、今日は休暇でいないような場合は（内容にもよりますが）優先順は下がります。これは、もしテストしてクラッシュするようなバグが見つかっても、その場ですぐに見てもらえないからです。明日来るんだから、わざわざ今日テストしなくてもいいか、みたいな感じですね。

さいごに

普段、わたしが「当たり前にやっていること」のひとつ「テストする順番を気にする」を紹介しました。

いつも無意識にやっていることを、改めて見つめ直し、言語化したら、これまで見えてなかった「何か」が浮かび上がってくるのかな…と、淡い期待もあったのですが、そうでもなかったですね。本当に当たり前のことだったわ。*4

 

*1:視力とか、腕力とか、聴力とか。

*2:それでも、どうしてもダメなときは、同僚のテスターに「何時から一緒にやろう！」とお願いしている。もう逃げることはできないので、午後でも大丈夫。

*3:Apple Watchが教えてくれるので、少しは改善している。

*4:公開するのも躊躇うレベルですが、せっかく書いたので放流します。

テスターから見た「テストの合間にプログラミングする」

druby.hatenablog.com

この記事を読んだときに、この「テストの合間にプログラミングする」という感覚が、はたして読み手に伝わるのかしら、、と思いまして、テスターの立ち位置で、いくつかツイートしました。
今回はそれを引用して、さらに補足します。

2009年にも言ってたみたい。というかずっと言ってたけど記録が残ってるのは珍しい。


元の記事にも書いてあるように、咳マニアとか、咳フリークと言われる（または自覚がある）人たちにとっては、わりとおなじみのフレーズなのかもしれませんね。「テストの合間にプログラミングする」って、どのような風景を思い浮かべているのでしょうか。とても興味があります。 

バグを見つけたら、スッと立ち上がり、そのストーリーの担当プログラマーを探します。（うちのチームは『全員同席』なので、大抵すぐに見つかる）

miwa719.hatenablog.com

そのときのプログラマーのシチュエーションは、こんな感じです。

  • コードを書いてる（ひとりで）
  • ペアプロしてる（２、３名で）
  • 数人のプログラマーが集まって、小さなホワイトボードに何かを書きながら話してる
  • テストしてる（プログラマーも１日１時間、テストの時間があります）
  • すでに誰かに割り込まれてる

バグを見つけたら、と書いたけれど、ちょっと違和感があるようなとき（例えば、この操作をしたときだけ、反応が少し遅い）や、質問や相談ごと（こういうテストをしてみたいのだけど、どうやったらその状態が作れますか？）も、プログラマーに話しに行きます。

miwa719.hatenablog.com


「テストの合間にプログラミングする」の「テストの時間」は、誰かのテストで見つかった問題、疑問、相談について、割り込まれて作業するのも「テストの時間」であり、１日１時間のテストの時間だけが、プログラマーにとっての「テストの時間」ではありません。

そのような「テストの時間」が、１日にどれくらいあるのかは、人それぞれですが、うちのチームのエースプログラマーを見ていると、１日のほとんどが「テストの時間」なんじゃないかな。でも、プログラミングもしてる（ストーリーが仕上がってくるからね）。この辺は、元の記事にも書いてありますね。

（速い人ほど）多くの時間テストに関わっていることになる。


わたしは、これまでいくつかの組織、チームに所属してきましたが、こんなにテストに時間を使っているプログラマーがいるチームは、見たことがありません。

 

さて、今回この記事を書くにあたって、久しぶりに過去の記事を読み返しているのですが、こんなのも見つけました。プログラマーを褒めるためにも、割り込んでる！

miwa719.hatenablog.com

テスターなので、普段からかなり意地悪なことをするんですけど、それでも壊れない、不安定さを感じない、これは頑丈に作られているなと、テストしていて（これは、素晴らしい・・・）と、思う瞬間があるんですね。プログラマーが、様々なユースケースを想定した上で、丁寧に設計、実装してきたのが、分かるんですよ。そんなシステム、ソフトウェアの動きを目の当たりすると、これはもう、一言言わずにはいられない。ストーリーを担当したプログラマーのところに行って「こんな（ひどい）ことしたんだけど、ちゃんと動いてた！すごい！感動しました！」て、割り込むんですね。

「割り込む」という言葉は「無理に押し割って入ること」「横入り」のように、どちらかというと、悪いイメージや印象を持つことが、多いかもしれないですね。でも、うちのチームは「これ」が推奨されています。（とは言っても、他人の作業に割り込むのは、練習しないと出来ません。わたしも出来るようになるまで、数ヶ月かかりました。）

割り込まれたプログラマーは、コードを書く手を止めます。ペアプロも、設計レビューも中断します。うちのチームで「割り込み」は、優先度が高いものとして扱われているので、コンピュータの世界での、割り込み（インターラプト）「実行中の処理を中断して、優先度の高い別の処理をする仕組み」に、似ていますね。


そうそう、プログラマーだけでなく、テスター同士でも、お互いのテスト中に割り込んで、いろんなことを話します。

  • 昨日コミットされた◯◯だけど、さっきこんなバグを見つけたよ（目の前で見せる）
  • おおお
  • それが出るなら、これはどうかな（おもむろにペアテストがはじまる）
  • うーん（深く）触るのは、このバグを修正してからの方がいいかもね

  • ◉◉のテスト、シミュレータ環境では動いたけど、これ、実機環境でも確認したい
  • うんうん、ハードウェアの制御も絡んでくるし、タイミングが微妙に変わってくるかもしれないよね
  • じゃあ、午後、テストベイで一緒にテストしようか
  • OK


もちろん、テスターも（テスト中に）プログラマーに割り込まれます。

  • 昨日のバグが再現しないので、一緒にテストして欲しいです
  • ◯◯について、テストの作戦を立てたいんだけど、今からちょっといいですか？
  • ＊＊の件、直してみたんですけど、こんな感じでどうですか？（コミットする前に、プログラマーの開発環境で見せてもらい、動作確認することもある）

そう考えると、プログラマーにとっては「テストの合間にプログラミングする」だけど、テスターにとっては「テストの合間にテストする」ですね。（わかりづらい！）

 

「テストの合間にプログラミングする」を、テスターの目線で補足しました。うちのチームの開発風景と「テストの合間にプログラミングする」この感覚が、すこしでも伝わりましたら、うれしいです。

 

間違えたことを大切にする


これはバグだと思ったけど、調べたらそういう仕様だったとき、あなたはどうしてる？


f:id:miwa719:20171223135220p:plain

つい二、三日前にそんなことがあって、仕様だと分かったのは、Bugチケットを発行した後だったのだけど『そっ閉じ』しないで、チームのみんなに見てもらったよ。

"そういう仕様で作ったから、そうふるまうのは正しいよね"

と、認識を合わせた上で

"バグだと思ってしまったのは何故なのか？"

に、論点（興味）が移るのが、うちのチームの素晴らしいところ。（今回の記事はチームの自慢が目的ではないので、ああ、そうなんだね、くらいに読んでね。）

  • たしかに、この操作でこれが出来ないのは、分かりづらいかもね
  • なんでこうしたんだっけ？
  • ここは、◯◯のふるまいも気にして決めたんだよね
  • ちょっと無理があるのかな
  • そもそも、●●の制約を入れた時点で負けじゃない？
  • もう一度（全体的な仕様を）考えてみようか
  • じゃあ、続きは二次会で


f:id:miwa719:20171223135220p:plain


何かを「間違える」のは、どちらかと言うとネガティブなイメージが強いから、間違えたことを恥ずかしく思ったり、隠したい気持ちになるんだけど、単に自身の勉強不足や注意散漫、だけでは済まされないコトが「間違える」には含まれている。


だから、あなたが何かを間違えたら『そっ閉じ』しないで、まずは、あなたの周りの人に話してみるといいと思います。

これは、開発現場だけの話ではなく、日常生活の中で起きる「間違い」全般に言えることなんだけど、わたしは（組み込みシステムの）テスターなので、冒頭のような例を出して説明しました。

「間違える」は、とても分かりやすくて、じぶんで気がつくことができる便利なシグナルだから、ぜひ、今日から練習してみてね。


じぶんの間違いを大切にできるようになると、周りの人の間違いも大切にできるようになるよ。

f:id:miwa719:20171223100219j:plain