「よし！」と思ったあとのもうひと手間（テスト）が大事

今朝、Amazonのほしい物リストに愛用している替え芯を追加しました。商品名のほかにも必要な個数や持っている個数などを入力することができます。

最大何個まで指定できるんだろう？とソフトウェア開発者（特にテスター）ならあるあるな思考で大きな数字を入れてみました。どうやら最大値は 99999 のようです。（そういう風に動いているだけで、欲しかったものがそうだったのかはわかりません）

100000 を入力した時の ! 正しい数字を入力してください はすこし不親切だなと思いました。

「最大値のチェック」を確認したあと「最大値が保存できる」ことを試しました。保存先の入れ物のサイズが小さいと保存に失敗することがあります。保存後、ほしい物リストに戻り 99999 が表示されることを確認しました。念のためAmazonアプリを再起動し、ほしい物リストを開き 99999 が表示されることを確認しました。

「必要」のとなりにある「持つ」は編集画面とあわせて「持っている」のほうがいいね。

次に気になるのは「持っている」の個数ですが、こちらも最大値は 99999 みたい。「必要」と「持っている」の両方に 99999 を設定して保存しました。このあとほしい物リストはどうなると思いますか？

ほしい物リストから「替え芯」が消えます。

必要な個数と持っている個数が同じになると、あなたの希望は叶えられた！となり自動的に消えるようです。なるほど。ただ、替え芯のような消耗品だと持っていても使えば減るので、このふるまいはちょっとどうなの？と気になりました。そして、自分がこのアプリの開発者なら「リストに登録された商品を削除する機会を増やしたい」と思うかもしれないな、とも。

一通り触って大丈夫かな（大丈夫かなって誰にも頼まれてないけど…）「よし！」

このあとわたしはもう一度、同じ替え芯をほしい物リストに追加します。ほしい物リストはどうなると思いますか？

最大値の 99999 を突破してしまいました。

普段の開発でも「よし！」*1と思ったあとのもうひと手間で、問題や課題が見つかることがあるのよねと思いながら、この記事を書きました。*2

そうそう「よし！」はテストするときだけでなくバグを見つけたあとにも応用できます。例えば、それほど大きな問題にはならなそうなバグ（A）だけど、それを踏んでしまうと、そのあとの操作でお客さまにインパクトのある問題（B）が発生しやすくなることがあります。こんなときうちのチームのベテランテスターはすかさず（B）まで報告してきます。きっと（A）を見つけた時点で「よし！」と安心せずに、もうひと手間かけてテストしてくるのだろうな。

「よし！」はテストに限ったことではありません。わたしがテスターなのでどうしてもテスト寄りの話になってしまいますけど。

*1:最近は「よし！」と思うとき、黄色いヘルメットをかぶった『現場猫』のイラストが浮かんでしまう病気にかかっていて、その度に「ヨシ！」じゃないほうの「よし！」と脳内でいちいち訂正してる。それはそれとして、わたしは工場勤務なので『現場猫』のネタがすごくわかるときがあって「くくく」と笑っています。この記事のアイキャッチ画像も『現場猫』にしたかったのですが、著作権がよくわからなくて断念しました。

*2:明日もう一度触ってみようと思うこともあるし、もうひと手間かけられるくらいのちょっとした余裕がないとむずかしいのかもしれない。そのちょっとした余裕は（時間というよりは）自分が支配してそう。

デブサミに行ってきた（２）

目黒の雅叙園で開催されたDevelopers Summit 2020（デブサミ）に行ってきた。今回も大盛況で満員のセッションが多く、人気のセッションでは壁沿いに立ち見も出ていた。どの会場も入場待ちの長い列ができていて大変そうだったが、わたしはお金の力（個人スポンサー）で解決したので快適だった。二日間でいくつかのセッションを聴講した。特に良かったものを数回にわけて書き記しておく。前回の記事はこちら。

『質とスピード』和田 卓人さん（タワーズ・クエスト株式会社）

今回のデブサミで楽しみにしていたセッションの一つだ。昨年の『技術選定の審美眼』もよかったなぁ。久しぶりにスライドを見てみようと調べたら一昨年のデブサミだった。いろいろ思い出したぞ。講演後 Ask the Speaker で「審美眼の美はどこにあったのか？」としょうもないことを聞いたらギクリとしていた。数時間後に別の講演会場で会ったとき「あのあとすぐにスライドを見直したら何ページのどこそこのXXXXXというフレーズにかろうじて美が入ってました。よかった…」と教えてくれた。つられて「よかったねぇ」と言ってしまったが、そうじゃないだろう。和田さん（以降 @t_wada）だってはじめから知っていたはずだよ？

本当にいつもすみません。

@t_wada の講演はいつでもどこでも大人気なので個人スポンサーでものんびりしてられない。ランチセッション聴講後、急ぎ足で会場に向かう。入り口でネームパス（バーコード）をピッとしてもらい前のほうへ歩いていく。壇上の横のすこし暗いスペースにおそらく緊張して吐きそうになっている @t_wada の姿が見えた。

speakerdeck.com

@t_wada の話は「今回も良かったね」だけでは終わらないところが良いところだと同行者の @m_seki と本人がいないところで褒め合う。聴講後はこんなことを考えていた。

テストしていて急かされたことがほとんどない

テスターのわたしがそう感じるということは、うちのチームのプログラマーもあらかたそうなのではないかと予想する。だってわたしがテストする時点でテストに耐えられるレベルのモノができている、ということだからね。急いで何かをしなきゃならない状態にならないようにする力学が働いているように思う。まあ、たまにそうならないときもあって、そんなときは誰かが暴れる。

おそらくこれと関連してチームでいつも意識してるのは「がんばらない」ことだ。自分たちの穏やかな"いつもの時間"を守るために日々「がんばらない」をがんばっている。何を言っているのかわからないかもしれないが「がんばればできそう」「もうすこしやれそう」「むしろやりたい！」ときも時間がきたら我慢して帰る。定時すぎにモニターを覗き込んでいると「もう17時過ぎましたよ、帰らないんですか？（帰ってくださいの意）」と声をかけられる。わたしは（テストに関しては）時間を忘れて熱中しがちなので目をつけられているのだ。

若者が朝会でうっかり「がんばります！」などと言うと「がんばらなくていいから普通にやって」と言われる。がんばらないとできないものは何かが間違っているとのこと。@m_seki が言ってた。

ベテランだって急かしちゃダメだ

講演の中で「うまい人はうまいしヘタな人はヘタ」のようなスライドがあった。

技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。

逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。

これはTesting*1にも当てはまると思う。ベテランが10分もさわれば見つけられるバグを初心者が3日かけても見つけることはできないのと同じだ。その人の技術力以上のTestingはできない。これは良い悪いの話ではなくそういうものだという話。

ただ、ベテランでも急かしちゃダメだと思う。さっき"ベテランが10分もさわれば見つけられる"と書いたが、テストするのに10分間しか与えなかったらそのバグは見つけられない可能性が高くなる。でも1時間与えたらはじめの10分で見つけられるような気がする。これは「ヤーキーズ・ドットソンの法則」（多少のストレスがあると注意力が高まるためパフォーマンスも高まるが、ストレスが強すぎると低下してしまう）に当てはまる事例だと思っている。試したことはないんだけど。*2

うちのチームでスピードを求められるとき

普段、急かされることはないがスピードを強く求められるときがある。それは何かおかしな挙動（期待との差）を見つけたときだ。テスターならスクリーンショットやログをとったあとにこんなことがしたくなるのではないかな。少なくともわたしはそうだ。

• いまやったことをもう一度やってみて、再現手順を確かなものにする
• おかしくなるときとおかしくならないときの手順や条件の違いを見つける
• 一番シンプルな再現手順を見つける
• 類似する不具合を見つけにいこうとする
• 不具合かどうかわからないときはそれが仕様（期待しているふるまい）かどうかを調べる

うちのチームではこれはやってはならない。なによりも先にプログラマーにいま何が起きたのかを話し、新鮮な状態を見せなければならない。見せたあとならやってもよいが

• これはコードを追って原因を見つけます（だから再現させなくていいよ）
• ここの条件はこのバグとは関係ないっすね、むしろこっちがあやしいな

と設計や実装のポンチ絵を描いてもらったり、再現手順を探るときのヒントを教えてもらうことがある。そのままプログラマーと一緒にテストして、ものすごい速さで再現手順にたどりつくのは何度も経験している。テスト環境が原因だったこともある。

プログラマーに新鮮な状態を見せるとその場ですぐに問題の原因が明らかになったり、問題の原因を特定するための最短方法がわかるのはメリットの一つだ。

「おかしさに気づいてからプログラマーに伝わるまでの時間」という品質指標があるのかないのかわからないけど、とにかくうちのチームではこのスピードが求められている。

あとは何かわからないことがあるときに「わからない」を表明するまでの時間かな。チームの誰かに聞けば大抵のことはわかるし、わからなくてもどうにかなる。だから悩んで時間を使ってしまうのは嫌がられる。時間は自分ひとりのものではなくチームの時間だ。聞けばわかるかどうかは聞いてみないとわからない。だから聞くしかないのだ。

これらは練習しないとできるようにならない。

こんなふうにに普段やっている"普通のこと"をあらためて認識できたのは @t_wada のおかげ。ありがとうございます。

これは聴講しながら書いた自分用のメモ（記念に貼っておく）

珈琲専門 猫廼舎

この日は夕食をすませたあと新宿区荒木町にある 珈琲専門 猫廼舎 に行く。ドアのガラス窓から見える店内はほぼほぼ満席で店に入るのを一瞬躊躇ってしまった。すごいな。

店主の荻野さん @ogijun に簡単な挨拶をしながらカウンター席に座る。夜にお邪魔するのは初めてなので大人になったような気分だがカウント的にはじゅうぶん大人だ。メニューを見せてもらう。バランスの取れたブレンド「イエネコ」にしよう。豆とお湯の量を5種類の中から選ぶシステムになっている。わたしは普通のコーヒーが好きなので3番の「はじめての方へのおすすめ」にした。

それからしばらくネルドリップの一瞬一瞬をとらえるような繊細な所作を眺めていた。贅沢な時間だ。

コーヒーカップはすべて有田焼。数十種類の中から荻野さんが選んでくれる。

猫廼舎には通販部がある。わたしはおまかせコーヒー豆の定期便を購入して職場で飲んでいる。淹れ方もだんだん上手くなって「今日のは最高にうまくはいったな」とか思っていたんだけど、あれはすべて勘違いだった。プロが丁寧に淹れたコーヒーは素晴らしく美味しかった。ごちそうさまでした。

『とちぎRuby会議 09』の開催日（9月12日）を伝え、店をでる。

*1:Testing：未知の問題を見つけるテスト

*2:参考書籍 インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針 「089 ストレスを感じているときには間違いを犯しやすい」

デブサミに行ってきた（１）

目黒の雅叙園で開催されたDevelopers Summit 2020（デブサミ）に行ってきた。今回も大盛況で満員のセッションが多く、人気のセッションでは壁沿いに立ち見も出ていた。どの会場も入場待ちの長い列ができていて大変そうだったが、わたしはお金の力（個人スポンサー）で解決したので快適だった。二日間でいくつかのセッションを聴講した。特に良かったものを数回にわけて書き記しておく。

『起業家的？！エンジニアのススメ』玉川 憲さん（株式会社ソラコム）

玉川さんの講演を聴くのは二回目で、調べたら前回は2016年のデブサミ（SORACOM立ち上げ格闘記）だった。あれから4年たつのか。プロダクトが素晴らしいのは言うまでもないが、多岐の分野において実にさまざまなユースケースが生まれ、モノと繋がり新しいIoTシステムとして人々の役に立っているのが本当に素晴らしい。昨年11月に福岡空港の『ふくや』でご家庭の明太子が無くなる前に自動的にお届けする『ふくやIoT』の動画広告をみて「福岡すごいなwww」と思っていたのだが、これもSORACOMの仕業だったのを知る。

わたしたちが開発してる製品もかなりとても素晴らしいのだが、そういえばSORACOMに感じる「壮大なロマン」のような感情をもってないことに気づく。少なくともいまのわたしの中には無い。いいなあ、羨ましいなと思う。今回の講演のキーワードのひとつは『パッション』だった。玉川さんのそれは「テクノロジーの民主化」とのこと。わたしはなんだろうな。開発しているモノ（医療機器）を通して「ひとりでも多くの人たちが健やかで幸せな人生を送れるよう手助けすること」だろうか。普段の開発では具体的な問題を解いていることが多く「世界中の人々の健康と幸せのためにテストしてバグを見つけるのだ！」と燃えあがるような感じでもないんだけど、根底にあるのはそれだと思った。

スピーカーラウンジ（控室）にて

最初の講演からとても良くて頭が疲れてしまったので休むことにした。個人スポンサーはスピーカーラウンジ（控室）が利用できるのだ。美味しいコーヒーとお菓子と電源とWiFiが付いてる。最高である。ジャガード織りのカバーのついた椅子に腰かけてぼーっとしていたら、斜め前のほうに玉川さんが座っているのを見つける。同行者の @m_seki に小声で「玉川さんがいるよ」と伝え、二人で話しに行く。聴講しながらiPadでメモしたものを見せたら喜んでくれた。「どこかに公開するんですか？もし公開したら教えてください。きれいに書いてあるから見たい！」と名刺を差し出す玉川さん。とても嬉しかったのに、自分の描いた絵を見せびらかしている子供のようだ（しかも初対面の人に）と思ったら急に恥ずかしくなった。「たいしたこと書いてないので…」ともじもじしてしまったが、そこに書いてあるのは玉川さんがさっき話した内容である。そういう意味ではないのだが、たいへん誤解をまねく表現だ。これからは気をつけよう。

玉川さんにはこんなことを聞いてみた。「普段仕事しているといろんなことがあって、例えば、嫌なことがあったときはどんな風に気持ちを切り替えるんですか？」

パッションだけでは乗り越えられないときってないのだろうか（きっとあるに違いない）と思ったのだが「ない」みたいだった。もうね、なんて言うかパッションがすごいのだよ、パッションが。それくらいでないと世界を変えることなんてできないのだと納得した。そしてちゃんとわたしのレベルに合わせて「睡眠の時間を十分にとったり、食事もちゃんとして、ストレスを受けにくいようにはしてますよ」とも話してくれた。なんて良い人なんだ…と感激した。

そしてこれが「たいしたこと書いてないので…」のやつである。

デブサミ「起業家的?!エンジニアのススメ」の講演資料です！
パッションをもち、自ら人生を切り開いていくような起業家精神を纏ったエンジニアが、日本で一人でも増えますように！協力いただいたソラコムのエンジニアの皆さん、多謝！！#devsumi #soracom https://t.co/5W615fdiHw

— Ken Tamagawa 玉川憲 (@KenTamagawa) 2020年2月13日

ソフトウェア技術者のためのバグ検出ドリル（問題6：ミケランジェロの呪いー入退室セキュリティ・システムの不可解なバグ）

この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1

ソフトウェア技術者のためのバグ検出ドリル

要求仕様フェーズの問題が解きおわり今日から設計フェーズです。問題6の制限時間はなんと4時間。手強い問題なのかな？とやる気満々で問題文を読みはじめたのですが、、、

そのものずばりの解答が１行目に書いてあって、うっかり視界に入ってしまった…。ううう。これから解く人は注意してくださいね。わたしは再発を防ぐために解答を隠す用の便箋を挟みました。*2

答えは分かってしまったのですが、このバグから普段の開発でどのようなことに注意すると良さそうかを考えたいと思います。気が向いたら追記しますが、まずは注意喚起でした。

*1:勘の鋭いエンジニアなら問題を逆引きできそう

*2:電子書籍リーダーで見たくない部分をさっと隠す機能ってあるのかな。幸い？本ドリルの電子書籍版は今のところないようです。

ソフトウェア技術者のためのバグ検出ドリル（問題5：迷路探索プログラム）

この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1

ソフトウェア技術者のためのバグ検出ドリル

この問題で著者の山浦さんが用意した解答（バグ）は3つ。この問題はうまく解けた感があります。うれしい。*2

本書では1つ1つのバグについて以下が記載されています。

• バグ名
• 分類番号（Boris Beizer 氏のバグ分類による）
• 不良分類名
• 作り込みフェーズ
• 検出フェーズ
• 重要度

検出フェーズというのは「最悪ここまできたら検出できるよね」というフェーズのことなのかな。今回の問題の3つのバグの検出フェーズはそれぞれ「テスト」「コーディング」「コーディング」と書かれています。

プログラマーの経験がないとコーディングフェーズのバグは見つけられないか？というとそうでもないと思っています*3。今回の問題のコーディングフェーズのバグは、どちらも仕様書（ドキュメント）をよく読めばわかります。座標 (x, y) の記載が途中で (y, x) になっていたらプログラマーの経験がなくてもおかしいことに気づけるのではないでしょうか。そしてこんなことを考えるかもしれません。迷路探索がどのようなものであるかは大抵の人が想像できるだろう。部分的に座標がちぐはぐだけど他の記述を読めばこのプログラムで期待している動きは明らかだなって。些細な記載ミスで誰もそこについて何も言ってこないけど、みんなわかっているよね。そしてこの後にもディスカッションすべき議題が控えている。

そこであえて「おかしいよね」と本物の開発の現場で言えるかどうかが、わりと鍵なんじゃないかなと思っています。

Boris Beizer 氏のバグ分類で思い出して自宅の本棚にある『ソフトウェアテスト技法』を久しぶりに手にしたけど、翻訳者が山浦さんでした。知らなかった。

ソフトウェアテスト技法

うちにあるのと表紙がちがう。

*1:勘の鋭いエンジニアなら問題を逆引きできそう

*2:うまく解けた感があるときは、うまく解けてないかもしれない…。

*3:もちろんプログラミングできることで見つけられるものもたくさんあります。ここで言いたいのは（自分はプログラミングできないから…）とあきらめなくていいことまであきらめてしまうのはもったいないなぁと感じているということ。

2019年、娘ちゃんは社会人になった。

2020年がはじまってだいたい24分の1が過ぎた。これといってなにもせずになんとなく過ぎてしまった。こんな感じで1月もあっという間に終わるのだろうと思ったけど、なにもしてないわけはなくて毎日ちゃんとなにかはしてる。

2019年は娘ちゃんが社会人になった年でもあった。あのちいさかった娘ちゃんがわたしとおなじ社会人になった。とても不思議な感覚だ。10か月経ったけどまだ慣れない。

20年前のちょうどいまくらいの季節だった。右手をぎゅっと握りしめ、幼稚園バスから降りてきた光景をはっきり覚えている。差し出された手のひらには赤いボタン6個と糸くずがあった。ミキハウスの赤いPコートに視線をうつすとボタンが1つもついてなかった。娘ちゃんがじぶんで取ったところまではわかった。

いまのわたしならいつもどおりの口調で「どうしたの？」と聞くことができる。当時はそれができなかった。思い出すたびにこころが締めつけられる。いろいろいっぱいいっぱいだった。仕方なかった。

わたしの脳内の記憶領域の索引のひとつは娘ちゃんだと思う。胎児、新生児、乳児、幼児、小学生、中学生、高校生、大学生、大学院生。それぞれの学年や季節ごとの行事や日常の些細な出来事や小さな事件などにリンクして、いろんなことを思い出せるのだ。

2019年、娘ちゃんは社会人になった。

娘ちゃんは職場近くのアパートに引っ越した。何かあったときに車で駆けつけられるようにと普段なら絶対にしない長距離運転を2回した。入社式や新人研修や新人歓迎会の話を聞いて、自分が新入社員だった頃を思い出した。仕事やチームの話を聞くにつけ、職場の雰囲気や上司や先輩はこんな人たちなのかなと想像している。休日はたまに同期の仲間と遊んでいるらしい。娘ちゃんの名前が印字してある名刺をもらった。感動した。わたしの名刺と交換した。はじめてもらったお給料でなにか買ってくれると言うので、ずっと使えそうなバッグを選んだ。うれしかった。数日後あらためてバッグをみて泣いた。そして2020年のお正月は、はじめてお年玉をあげなかった。

娘ちゃん社会人1年生が新たな索引となってわたしの記憶に色濃く残りそうだけど、社会人2年生、3年生……は、果たしてどうなるのだろう。

実はすこし前から気づいていることがある。これまで娘ちゃんにわたしが好きで自分勝手に捧げていた（もしかしたら鬱陶しく思われていたかもしれない）パワーが消費しきれずに余っているのだ。ちょっとくらい無駄になってもいいので楽しいことに使いたい。*1わたしはもともとあまり体力がないので、それでも人並み以下なのだろうけど、これまで意識的に（無意識かもしれないが）選択してこなかったことをすこしずつやってみようと思う。

変わらないのは娘ちゃんが生まれる前も、50歳になったいまもソフトウェア技術者で、この職業を選んでよかったということだ。製品開発は本当に面白い。

*1:娘ちゃんにお金がかからなくなり、わたしの預金額も急速に増えていってる。こっちは無駄に消費せず老後のために貯蓄しなくてはならない。

ソフトウェア技術者のためのバグ検出ドリル（問題4：文字変換表のバグ）

この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1

ソフトウェア技術者のためのバグ検出ドリル

要求仕様フェーズのバグ（問題4『文字変換表のバグ』）

先日、この問題を技術顧問 @m_seki に出題したところ一瞬（だいたい2秒くらい）でバグを見つけられてしまいました。わたしはというと問題文を丁寧に読みはじめたところでしたので唖然としました。そして（このドリルは独りでやろう…）と思いました。このような練習問題をみんなで解く面白さも勉強会などで体験してますが、自分でバグを見つけたい気持ちの強い人はまずは独りでやることをおすすめします。今回は仕方ないので気を取り直して本書に載っているプログラムを実際に動かしてみました。

ソースコード（C言語）を写経する

本書には問題に応じてソースコード（C言語）や実行結果が載っています。著者の山浦恒央さんは以下の手順で解いてほしいと言っています。

1. まず、机上デバッグで、バグを見つける。
2. 見つからない場合、実際にプログラムを動作させ、マシン・デバッグで見つける。
3. 見つけたバグを修正する。

問題4もソースコードと実行結果が載っています。バグのある要求仕様に基づいて実装したのでソースコードも間違っていますし、実行結果も期待したものではありません。
それではうまく動かないっぷりを実際にプログラムを動かして自分の目で見てみましょう。たまたま Visual Studio Code を開いていたのでそれを使ってソースコード（PrintAsciiCode.c）を写経しました。

プログラムを実行する（間違っていることを確認する）

$ clang PrintAsciiCode.c
$ ./a.out

おおぅ、Terminal に printf() の "¥n" がそのまま文字で出力されてしまった…。Mac だと改行コードはどう入れるのだ？と調べたら「option + "¥"」で "\" を入力すればよいのですね。ソースコードを直してもう一度実行し、期待どおり実行結果が間違っていることを確認しました。

この間違っている状態を自分の目で見ておくことは普段の開発でも大切にしています。特に自分以外のテスターやプログラマーが見つけたバグで操作手順や条件や状態が複雑なもの、朝会で聞いたけどどのようなバグかよくわからなかったものは、その日のうちに聞いたり目の前で操作してもらい、そのバグを自分でも出せるように練習しておきます。そうしておかないとバグが直ってきたときに「よし、直ってる」ということに強い確信を持てないからです。実際に手を動かしてバグを実感しておくと記憶に残りやすく未来のテスト（Testing）に活かせるという利点もあります。

プログラムを修正して再実行する

要求仕様に書かれているとおりに出力できることをプログラムを動かして目で見て確認しました。

おわりに

炎上覚悟で言いますが*2 この問題4のタイトル自体がバグだと思います。だってタイトルどおり「文字変換表のバグ」なんだもん。これではバグを見つける面白さが半減してしまいます。*3

はっ！もしかしてこれで安心させる作戦なのかな？実は他にもバグがあるのかも、、、

*1:勘の鋭いエンジニアなら問題を逆引きできそう

*2:最近、Twitterでこのフレーズをよく見るので一度使ってみたかった

*3:ちなみに @m_seki にはタイトルを見せないで出題したので本当にすごいと思いました。恐れ入った。