Murga

個人的に言いたいコト・主張・気持ち。

「間違っていないことの確認」を怠る人

後輩「合ってるはずのパスワードをコピペして入れてるんですが、何度やっても通らないんです」

僕「一度通らなかったら同じこと繰り返しても意味ないから、まずパスワードが正しいことを確認しようか」

後輩「いや、パスワードは合ってるはずなんです、このメールに書いてある初期パスワードをコピペしてるんで」

僕「なるほど、じゃあ、これが初期パスワードなら、違うパスワードを取り違えている可能性は、一旦ナシとみなそう。これから色々試してもダメだったら、この初期パスワードが合ってない線が濃厚だからね」

後輩「はい」

僕「それじゃあ、コピペした文字列が合ってるか確認しようか。メールからコピーした時に、行末のスペースや改行までコピーしてないか確認しよう」

後輩「いや、そんなはずないですよ」

僕「推測はいいから、実際に試して観測してみようか。そのコピーしてる文字をメモ帳に貼り付けてみて」

後輩「はい、貼り付けました」

僕「ほら、貼り付けたら何か改行が出てきたよ、やっぱ余計な文字までコピーして入力してたんじゃない?このメモ帳から改行を除いてそれを再度コピーして貼り付けてごらん」

後輩「はい……あ、通りました。えー、スペース混じってたんですか?そんなはずないんですけどねぇ…,。自分はそんなつもりなかったんで……」

僕「人間側がどういうつもりだろうとなかろうと、事実はそうだったんだよ。いくら推測で正当性を主張しても、解決には繋がらないから、自分が間違ってないことを証拠付きで確認する習慣を付けような」

後輩「はぁ……」


最近、こういう「自分が正しいと思っているから正しいはずだ」と思い込める人があーん多い気がする。「僕がやったことの中の何が間違ってるんですかねぇ…?」という目線ではなく、「僕がやったことは正しいはずなのに、なんで上手くいかないんですか?」と言ってくる。

実際調べてみると、

  • 前述のようにコピペの仕方がマズくてパスワードに余計な文字が混じっていたとか、
  • コードの修正が反映されないと言っていたけどライブリロードしてなかった (本人は「さっきターミナルから立ち上げておいたはずなのに、おかしいな…」といった顔) とか、
  • ライブリロードは立ち上げていたものの触っていたファイルが別のプロジェクトのファイルで、反映されるはずがなかったとか、
  • マウスが効かないと言い出したがよく見たら電源スイッチが OFF になっていたとか

そういう初歩的な確認を怠ったことによる、しょうもないミスばかりなのだ。「はず」も「つもり」も、トラブル解決には無意味な言葉だから、検証して観測しよう。

こういう人がやらかしている特徴はいくつか挙げられるので、自分が以下に当てはまっていないか確認しよう。

  • トラブルが起こるまでの自分の行動を正確に覚えていない
    • 「記憶」に頼っている時点で正確ではないことを理解せよ。より正確なのは「記録」である
    • 叩いたコマンド、触ったファイル、書いたコードを、1文字単位で間違いなく記録する
  • その行動をキレイさっぱり戻せるように準備していない
    • 作業を最初からやり直したら、解決の糸口が見えることがある。作業は再現性を高くしておく。つまり、キレイさっぱり元に戻せて、完全に同じ状態から同じ作業ができるようにしておくことが大事。
    • Git でのコード管理だったり、ファイル削除はゴミ箱もしくは別フォルダに退避したりすることで、やり直しできるようにしておく。
  • どこで、何に対して、何をしたか、をもう一度確認する
    • 「書いたはず」ではなく「間違いなく書いてあることをもう一度見る」。
  • その行動が本当に正しいのかもう一度調べる
    • 間違いなく書いたその設定項目が本当に正しいか、記述位置、つづりを見直す。設定したことによる効果の内容に勘違いがないかもチェック。
  • ハードウェア的な問題がないか確認する
    • 電源は入っているか、電池は残っているか。
    • USB などであれば、一旦挿し直して再認識させてみる。
    • 操作しているサーバが本当に起動しているか、フリーズしたりしていないか。サーバの生存チェック大事。
    • 故障はほとんどないと思うが、他に原因がないようであれば SSD や HDD の故障や、通信機器の破損などもチェックする。

しょうもないミスでつまづかない人は、何かトラブルがあった時にこうしたポイントを瞬時にチェックしていて、「あっ、電源入ってなかったわ」とすぐに復旧したり、「他に原因が見当たらないから、ココで追加したコードがまずいのかも?」と当たりを付けたりできるのだ。

デキる人は最初から一つもミスしないのではなく、「この辺はよくミスしがちなところ」と認識していて、すぐに繰り返しチェックする癖が付いている、ということなのだ。


それから、問題を素早く解決するためのアドバイスとして、以下が挙げられる。

  • 慌ててむやみな行動を取らないこと
    • パスワードが合っているはずだ、と3回間違えてみたりすると、パスワードロックがかかって復旧不可能になったりする。
    • 慌てて行動して記録をしてなかったり、根拠の無い行動を取らないこと。怪しい時は何も触れず周りに助けを求める。
  • 試すことは一つずつ試す
    • 何かのコードが動かない時、「ココかな?それともこっちか?」などと、複数の場所に変更を入れて試さないこと。無関係なコードが別の悪さをするかもしれないし、たまたま上手く行ったとしても、無駄なコードまで追記が必要なモノと勘違いしたりする。
    • 本筋とは違う不具合を踏んでしまうと、根本解決から遠のいてしまう。違うエラーが出たら、元に戻せるようにも準備しておく。
    • これらは「自分が何をしているのか理解していない」ことが原因。そのコードの役割を認識せず、雰囲気で直そうとしているから無駄なコードを入れてしまいがち。
    • 解決には向けて複数の手段が考えられるなら、一つずつ試す。それぞれの変更による結果を見比べて、その中で必要な一つ、もしくは組合せを見極める。

間違っていないことは何度確認したって良い。初歩的すぎる足元こそよく見ていないものだから、自分に「確信」があることであっても、何度でも見返しておこう。

人と企業はどこで間違えるのか?---成功と失敗の本質を探る「10の物語」

人と企業はどこで間違えるのか?---成功と失敗の本質を探る「10の物語」

質問は常に堂々としよう

人に質問する時に、

  • 「○○が動かないんですけど……」(← けど、何?)
  • 「○○を設定したら△△ってエラーが…出て……これって……○○の……バージョンが……」(← 何が質問したいの?)

っていう、尻すぼみになる質問の仕方をする人によく遭遇する。途中から消えそうな声で喋るから「文末までハッキリ堂々と喋りなさい」といつも言っている。

この質問の仕方は複数の理由から忌むべき聞き方なので、即刻止めよう。

  • 「○○が動かなくなってしまいました。どうすれば良いか皆目検討も付かないので教えていただけませんか?」
  • 「○○を設定したら△△というエラーが出ました。○○のバージョンが古いせいかと推測しているのですが、これに関する文献やノウハウはご存知ないでしょうか?」

このように、「助けて欲しいです」「このように手を差し伸べてほしいです」とハッキリ言おう。

前者が悪い質問の仕方である理由、後者のように聞くと良くなる理由を、自分なりに解説する。

日本語の構造上の問題

「尻すぼみな質問」の問題は、聞いている側がどういう質問なのか分からない点だ。

日本語の構造上、質問文というモノは文末が重要になる。「何々がどうなって、コレコレがあぁで、どれそれしたんですけど、」という手前の話はそこまで重要ではない。大事なのは文末なのだ。「でも解決しました。何の問題もありません」と文章が続くかもしれないし、「○○のファイルだけ足りないようなのでコレをください」という依頼かもしれないし、「もう結局何がなんだか分かりません!自分じゃ手に負えません!」という悲鳴かもしれない。聞いている側は質問者が何を求めているのか分からなくて、何を求めているかを探るために文末を早く聞きたいのだ。手前の補足情報は後で話せばいい。

聞かれた側が、望んでいる答えが何かを読み取って応答できるように、質問する側は文末の具体的なお願い・依頼・求めるアクションをハッキリ言わないといけないのだ。

相手に察してもらおうとしているその姿勢に問題がある

尻すぼみに話す人は、突き詰めて言うと、「途中まで言えば、相手は答えを話し始めてくれるだろう」という期待を抱いている。自分が困っていて、ちょうど良い救いの手を差し伸べてくれるよう、「察しろ」と思っているワケだ。

ふざけんな。

仕事上の分からないことは、一刻も早く解決して、その先に進んで成果を挙げないといけないのだ。どうせこの程度の質問の仕方をする連中のことだから、大したことのない問題でくだらない時間を浪費しているだけだ。そんなの先輩に聞いて5秒で解決しろ。解決して、その先の仕事をどんどん進めろ。

それなのに、「質問したいことは察してもらえますよね?」「私が教えて欲しいことは分かってますよね?」と言わんばかりの尻すぼみの質問の仕方。答える側も、あらかた察しが付いていたとしても、答える気が失せる。お前は自分のケツも拭けないのに、拭いてほしいタイミングで上手く拭けよ、と先輩上司に言っているワケだ。家族が介護してるワケじゃねえんだ、自分のことは自分で解決して自分で仕事を進めていくつもりで、主体性を持って質問に来い。

「僕はコレが分かりません。これが解決できれば、この先のタスクが完了できるんです。ココだけ教えてください」そういう態度で聞きに来て、必要なことを吸収して、「教えてもらったやり方で上手く行きました、構造の作業に進みます!」と主体的に仕事して欲しい。それが一番、周りの足を引っ張らない質問の仕方だ。

質問すること自体は悪くないから堂々と言おう

質問自体は悪いことではない。先程も書いたが、問題はサッサと解決して、早くその先の価値ある仕事に進むのが望ましい。そのためには、サッサと人に聞いてしまうというのは充分良い手段だ。

その現場にしかない情報は、どんどん周りから聞こう。直接回答をもらわなくてもいい。「どこどこのマニュアルに書いてあるよ」とか「この共有ファイルを見ておいて」とか、情報の在り処を教えてもらうだけでも良い。

辞書を引けば分かるような一般常識、ググればすぐに出てくることばかり質問するのは避けたいものの、その「一般常識」を、「その現場」に適用して良いのかどうかは判断が付かなかったりする。その場合はもはや「一般常識」ではなく「その現場特有の情報」になるのだから、その場にいる有識者に聞いて良いことだ。

もし、一般常識かもしれないが、調べ方が分からない、というのであれば、悩んでいる時間が無駄だから早く聞こう。「そんなことも知らねえのか、常識だぞ」と言われたとしても、「すみません知りませんでした、この現場で仕事をこなすために必要なことはすぐに吸収していきますから教えてください」と言えばいいのだ。

どうも、「質問する」という行為自体を、「他人に迷惑がかかるから極力避けるべき行為」とか、「負けを認める恥ずかしい行為」みたいに捉えている人がいるが、まことに自己中だなと思う。

質問すればすぐに解決できることを、もしくは質問しないと分からなかったようなことを、「聞いたら上司の時間を奪って迷惑かもしれないから」と聞かずに自力で調べていると、スケジュールが遅延して、マネージャが迷惑する。スケジュールの遅れを自分でなんとかしようとして質問せず、誤った成果物を提出すればレビュアーが困るし、もしそれが製品に混じってしまってバグを引き起こしたりしたら、利用者も、チームメンバも、皆が困る。

問題というのは先延ばしにすればするほど、顕在化した時の悪影響が大きくなるもので、そうなると多くの人員の多くの時間を奪うトラブルになる。そうなる未来を選ぶよりは、今5分間上司の時間を奪って、問題が小さな段階で早く解決した方が、周りの迷惑にならないで済む。

「聞いたら負け」「知らないと言うのが恥ずかしい」といった自分のくだらないプライドは、サッサと捨てよう。あなたは知らないし、自力で解決できない、低レベルな人間なのだ。そんな低レベルな人間が、自分のプライドを守るためだけに、周りに質問しないで知ったかぶりしてバグやトラブルを握りつぶして誤魔化していても、問題は必ずいつか顕在化する。そうなると皆が迷惑し、「あいつのせいで酷い目にあった」「あいつ嘘つきじゃねえか最低だな」と取り返しのつかない低評価を付けられる。いくら自分が否定しようとしても、給料や役職という具体的な形で、あなたの自己中心的かつ無能な様が露呈する。

だったらそうなる前に、「お恥ずかしいのですがコレが全然分からなくて、教えてください」と質問してしまい、吸収して自分のスキルにして、以後はバリバリ仕事をこなしていけば、「あいつ最初のうちはどうなるかと思ったけど、勉強熱心で頑張っているじゃないか」と評価してもらえる。

質問は、しなかった時のリスクや被害が大きくなることが多い。早い内に質問した方が、得られる効果や削減できる時間は大きい。

その問題すら解決できない人間が変に推測するな

「質問したら相手に迷惑かもしれない」「もうちょっと調べたら自分で解決できるかもしれない」といった推測は、全て誤っている。

管理職としては、問題があるなら早く知って軌道修正する時間に当てたいし、新人からの質問の量もその人の仕事の姿勢を評価する基準の一つになっているのだが、本人はそのことに気付いていない。

実際に質問したら、上司に「今は忙しい、後にしてくれるか?」と言われるかもしれない。でもそれは「以後質問しないようにした方が良い」ことにはならない。上司は「よく調べろよ」「前も言っただろ」などとは言うかもしれないが、「もう二度と質問しに来ないでくれるか」とは絶対に言わないはずだ。それは、上司としては問題を隠される方が困るから、忙しくても質問して欲しいからだ。「お忙しい中本当に申し訳ありませんが、教えてもらわないと先に進められない問題なのです。いつでも良いのでお時間をとってください」と、それでもお願いすれば良いことなのだ。

その問題自体を解決するためのアプローチとしても言える、よく言われている言葉としては、「推測するな、観測しろ」ということだ。「こうかもしれない」「こうしない方が良いかも知れない」ではなく、実際に実行して、その結果を確認するのだ。

  • 「こうしたら直せるか試してみよう、どれどれ、あぁダメだったか。でもエラーメッセージがちょっと変わったなぁ」
    • これも大事な観測。触ってみた場所が、問題の箇所に対して影響があることが分かった。
  • 「ココはコレに関係していないはずだから、こうしても解決しないはずだよな、試してみよう、どれどれ、おや?なぜか問題が解決した、どういうことだ??」
    • 無関係な場所が本当に無関係なのか検証することも大事。
    • 実際に試してみたら無関係ではなかった、ということもある。

質問する時の姿勢としても同じ。「今質問したら悪いかもしれない」「こんなこと聞いたら非常識だと思われるかもしれない」と推測して声をかけないのではなく、「今質問しても宜しいですか?困っておりまして。」と相手に聞いて確かめるのだ。「私は忙しいから、悪いけど○○さんに聞いてみて」などと言ってもらえるかもしれない。

変に推測せず、まずやってみる。ダメだったら「出直します」で良いのだ。素人の推測は大概間違っているから、推測せず観測しよう。

質問の仕方を定型化しておく

僕は後輩を新たに迎え入れる時、必ず以下のルールを伝えている。

  • 分からないことに出会ったら、5分調べてみる。
    • Google 検索や自分なりの試行錯誤。知識がない状態で「悩ん」でも答えは絶対に出ないから、ググって知識を仕入れて、それらを総合して「考える」こと。
  • 5分調べて分からなかったら、すぐ聞く。
    • 分からないことを放置するメリットはない。すぐに周りに助けを求めて解決を図る。
    • 「自分が困っている」ということを周りに共有するのもチームとしては大事なことだから、どんどん困っていることをアピールしろ。
  • 質問したい時に相手がどういう状況でも、必ず呼び止める。
    • 質問しない方が良いかは質問する側が考えることではない。迷惑がられてもいいから呼び止める。
    • 「今質問よろしいですか」「5分ほどお時間いただけますか」とか聞いて、ダメだったら別のタイミングに調整してもらえ。
  • 先に聞きたいことをハッキリ言え。詳細は後から言え。
    • 「Java の設定ファイルに加えた変更が反映されなくて困っている。どうしたら反映されるようになるか知りたい」コレを最初に言え。
    • 「○○ファイルをこう書き換えていて…」とか「このやり方は試したのですが…」とかはその後言え。

最初のうちは伝えていてもなかなか従ってもらえず、尻すぼみな質問をされるのだが、「分かんなくても堂々とハッキリ言い切れ」と繰り返し指摘していくと少し良くなってくる。

この辺のルールを、質問する側も、質問される側も、文書化して共有しておくと良いかなと思う。結局のところ、上司は上司で「部下にはこういう風に行動して欲しいんだけどなぁ〜 (← でもそれを直接は言わない)」と思ってるだけだったり、部下は部下で「よく分かんないけど質問するのは悪い気がするし〜 (← 本当に悪いかどうか確認していない)」と思い込んでいるだけだったりする。

文書化してお互いの姿勢を共有しておけば、「○○が分からなくて困っています」「5分調べたか?」「はい、文献に従ってコレとコレを試しましたがダメでした」「じゃあこのトラブルパターンかもしれないな、ちょっと見てみよう」と会話がスムーズに進められる。


質問はどんな場合・状況でも常に、ハッキリと、堂々と言い切るべきだ。それが相手のためになる質問の仕方だし、チーム全体が一番負担にならない、推奨される行動だ。

「良い質問」をする技術

「良い質問」をする技術