Something like blog

2019/08/07

ヒーローインタビュー

内容が思いのほか長くなってしまったので最初に結論だけ書いておきます。

  • 質問者は相手を理解するために質問しているのではなく、自分の中の「イメージ」に沿う回答が得られるように誘導尋問をしている
  • 質問者が得られる回答の質は質問者の質に依存する

の2つが書きたかった内容です。


それでは本文です。

野球のお立ち台の時のインタビュアーの質問ってワンパターンだと思いませんか?

だいたい「打席に入った時の気持ちを聞かせてください」と質問して、だいたい「絶対にここで打ってやるんだ、という強い気持ちで打席に入りました」と答え、そして球場が沸く、といった流れです。

ちょっと話が横にそれるんですが、こういった意気込みを選手に聞くのはやめてほしいと個人的に思っています。

たしかに、サヨナラホームランの後にそういったやり取りをして観衆を盛り上げたい意図は分かります。

しかし、その打席以外の他の試合、他の打席において散々「ここで打てば完全に試合を決められる」といった場面でことごとく凡退していたりします。さらに次の回にエラーをしてしまい、それが決勝点になってしまったり……

決定機でなくとも打席に入ればベンチからのバント指示などがない限りはどの打席であろうとバッターは「打つ(あるいは塁に出る)」という気持ちで打席に入っているはずです。

仮に気持ちの強さが結果につながるなら、凡退した打席は「打つ気持ちがなかった」ということになってしまいます。

なので自分としてはチャンスで凡退するたびに「お前勝つ気あんのか?」という気分になってしまいます。

勝率が高いチームだと勝つ機会の方が多いので「打席に対する意気込み」で盛り上がるのもいいですが、勝率が低く負け越しているチームだと、勝って盛り上がる機会より、チャンスで打てずフラストレーションがたまる機会のほうが多くなります。

シーズン全体で見れば、ストレスが発散されるよりむしろストレスが蓄積されます。

ですので勝利インタビューの時は、打席に入る前の意気込みを聞くのではなく、純粋に打った後の気分だけを聞いてほしいと思います。

そうすれば「最高の気分です!」となって観衆も盛り上がれますし、その1打席の結果に対しての「気分」なので、他の打席の「意気込み」にも影響しません。

ホームランを打った後の気分は、その前の打席でワンアウト満塁の場面でゲッツーを取られてしまった時の意気込みとはなんの関係もありません。

そこを「絶対に打ってやるという気持ち」と言われてしまうと「じゃあ、前の打席でゲッツーになってしまったんはやる気がなかったんか?」といった邪推が発生してしまいます。

勝利インタビューに関する愚痴はこの辺にしておきます。

ここで言いたかったことは「質問」というのは得てして自分たちの知らない「何か」を知りたいのではなく、自分たちの中で何かしらの納得感を得たいために行うということです。

自分の知らない何かを相手から引き出したいのではなく、自分の中にある、あらかじめ存在している仮説というか希望に対して辻褄を合わしてほしいのです。

「打席に入った時の気持ちを聞かせてください」と聞いて「別に」と答えられることはかけらも想定してないのです。

答える方も相手が何を求めているかは空気でなんとなく分かるので、自分のホントの気持ちはひとまず横に置いておいて相手が求めているであろう答えを回答するのです。

つい口がすべって本音を出してしまい「別に」と答えてしまった日には世間一般の皆さんからものすごいバッシングを受けてしまいます。

ですので、インタビューに対する受け答えは予定調和であり、相手から何かを引き出すのではなく、聞き手側の「空気」を読んで、その期待に答えるだけのやり取りとなるのです。

質問をしているのに、実際に欲しているのは知識や情報ではなく共感なのです。

こういった慣習が記者(質問者)の質の低さという現実を生んでいます。

最近では、記者会見の様子をYoutube等で生放送で視聴できたり、無編集の映像をまるまる見れる機会が増えました。

「編集」というフィルターを通すことなく、実際の質疑応答の一部始終がダイレクトに世間一般のみんなにさらされるようになりました。

イチローの引退会見やここ最近の某お笑い芸人周りの騒動における会見を見ていると、記者の質問内容があまりにも低レベルでびっくりしてしまいます。

支離滅裂で自分で何を言っているのか理解できていないのでは?と思わせる発言や、同じような質問、会見の趣旨と全く関係のない質問をとても高い打率で繰り出しています。

そこで、なぜ質問の質が低いのか?を考えると上記までで述べてきた「質問者に求められるのは相手から情報を引き出す能力ではなく世間一般から共感を得られる答えを引き出す能力」という環境要因がある、と考えることができます。

だいたいの場面において、相手の意向や感性、考えを引き出すのではなく、自分の中であらかじめ決まっている「こういった反応がほしい」をいかに相手から引き出すか、という行動原理が求められているのです。

イチローに偉大な記録を達成した時の気持ちや、それを達成するまでにいかほどの努力を要してきたのかを質問するときは、それ相応の嬉しい気持ちや努力の軌跡を語ってほしいのです。

そこで「特別な気持ちとかはないですね」と言われると困るのです。

偉大な記録にはそれに見合うだけの納得のいく理由やストーリーが欲しいのです。

そして期待した回答と違った回答をされた記者は脳内で例外処理が発生してフリーズしてしまい、それを見たイチローが「僕なにかおかしなこと言いました?」「ちゃんと聞いてます?」となるのです。

そして記者側はめげずに違う言い回しで同じ質問をして、自分たちの期待する偉大な選手に見合う回答を引き出そうとがんばります。

そして「その質問さっき答えましたよね?」と言われて撃沈するのです。

相手から何か新しい知見や感性を引き出そう、という前提でやり取りを聞くと「頭の悪い質問だな」という感想になりますが、相手から共感できる何かを引き出そうとしている、という前提で捉えれば記者側の質問内容に対して多少は納得感を持てるのではないかと思います。

質問に対して回答者が回答する内容は質問者にかなり依存していると言えます。

イチローみたいな一部の天才は質問者の願望を考慮せずに誠実に正直に答えますが、ほとんどの人は「別に」とストレートには答えずに、ちゃんと空気を読んで「皆さんが支えてくれたおかげです」と質問者とその背後にいる多数の人間が望んでいる回答をします。

イチローのようなみんなが知る天才であれば奇抜な受け答えも、それはその人の味としてプラスに受け取られますが、有象無象の一般人である我々が相手の願望を無視した回答を行うと質問者から「こいつなんやねん、空気読めや」と思われて終わるだけです。

そういった意味で質問する人の器の大きさが回答者の回答できる幅を決めると言っても過言ではありません。

ある質問に対して質問者の意に反する回答がきた場合に、ダメと思って一蹴するか「こいつ鋭い目線持ってるな」と興味を抱くのでは評価が180度変わってきます。

自分の都合に対する空気を読んでもらうのではなく相手側のバックボーンに対して知識を持ち敬意を持って質問すれば、相手側も「この人にならこの話をしても理解(or 共感)してくれるかもしれない」となり、新たな知見や感性を引き出せる可能性が増えるのです。

相手から何か斬新な回答を得たければ、質問者自身が「私はあなたの回答を受け止めることができる」器の持ち主であることを回答者にあらかじめ知らしめなければいけないのです。

そういう意味で、面接官は自分の能力を超えた面接者を見抜けないのです。

相手に膨大な知見があったとしても、受け取り手である質問者に相手の知見を引き出すための素養がなければ回答者は自分の知見を披露することはないでしょう。

質問者が得られる回答の質は質問者の質に依存するのです。

2019/07/01

ドキュメント風林火山

今回は上記を読んで、なんとなくパクっ……もといインスパイアした内容となります。


今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるようなマネジメントができるエンジニアとか最先端の技術に精通しているエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもありませんでした。

ではどういうエンジニアが、ということの答えの一つとして、技術力云々ではなく、ドキュメンテーション能力が大事だと考えています。

そこで、開発におけるドキュメントの要素についてまとめたものが次の表です。

分類 能力
風のドキュメント化 迅速な文章化によってチームを加速させる。
風のドキュメント化が発生しない開発チームでは、議事録やメモが残りづらく、そもそも「ドキュメントを書く」という文化が発生しない。
林のドキュメント化 突発的なトラブルが発生しても冷静に対処し、原因と対処の文書化、及びそれをもとに作業を標準化することができる。
その結果、チームに乱れぬペースを提供する。
林のドキュメント化が発生しない開発チームは同じようなトラブルを永遠と繰り返し、人の入れ替わりにも弱い。
トラブル時や引き継ぎ時に何をすべきかの正確な判断を行えず、混乱に陥りやすい。
火のドキュメント化 焚書。
運用を進めていく中で不要になった情報を削除したり、仕様変更に合わせてドキュメントを更新していくことによりチームやその成果物の競争力を高める。
火のドキュメント化が発生しない開発チームは古くなった情報や不要な情報に惑わされてチームの進捗スピードが鈍くなる。
山のドキュメント化 厳密なチェックと堅牢なドキュメント管理によって成果物の安定性を高める。
必要なときに必要な情報にすぐアクセスできる環境を整備する。
山のドキュメント化が発生しない開発チームは曖昧な仕様による認識のズレが常に発生し、チームメンバーのナレッジも弱くなる。

「風」からドキュメント化という文化が発生し、「林」で育て、「火」で質を上げていき、「山」で定着させる、といった流れになるでしょうか。

これらすべての要素が揃わないと質の高いドキュメントは生まれません。

プログラマー風林火山と違ってドキュメント風林火山のほうはあまり属人的な要素はないので、「各個人がどの要素が得意か?」というよりかは「ドキュメント化にはこういった要素があります」という内容になってしまいました。

あと、書いてて思いましたが「ドキュメンター」のような文章化を行う人を呼称する言葉ってないんですね。

最初に書いたとおり、ドキュメントはある意味技術力より重要だと思うので、それ相応の呼び名があっても良いと思います。

もう一つ、ドキュメントと同じくとても重要なのにあまり日の目を見ない能力として「バグ取り」があります。

バグの事前発見とその修正はシステムの安定化にとってとても大切なことだと考えています。

バグを潰すのが得意な人にもそれ相応の呼び名があって良いと思います。

ちなみに私はバグを見つけて修正する人を「バグシューター」という呼称で呼ぶことを提案しています。

2019/06/07

仕事は楽しいよりつまらないほうが合理的

「仕事は本来楽しいものだ」とか、「ワークアズライフ」などの思想は人類の1%くらいの人が思っている分にはいいけど、みんながそう思うのはよくない。

便所掃除を生業にしている人からすれば「知らないおっさんのこびりついたウンコを引っ剥がすことが我が人生か……」という結論になってしまい、仕事を辞めてしまって最終的にウンコが流れなくなる。

それは困る。

世の中に存在するすべての仕事は楽しいわけではないし、楽しくできるものでもない。

「仕事は楽しいもの」という概念を当たり前にしてしまうと「現実に必要ではあるが楽しくない仕事」は誰もやらなくなり、世界は回らなくなる。

そして、結局は楽しく働いている人の誰かが「現実に必要ではあるが楽しくない仕事」というハズレくじを引かざるをえなくなる。

そうなってくると「仕事は楽しいもの」という概念自体が世界を停滞させることになる。

それは困る。

「仕事は楽しくあるべき」という発想は一見ポジティブで良さげな考えに思えるが、実際には誰もしたがらない仕事がどんどん増えていくだけの結果を生むことになる。

最終的にはダンサーはいるが舞台を作る人もいなければ運営をやる人も誰もいないディストピアが生まれるだけだ。

みんなが熊川哲也なみに踊りが上手くなったとしても、その踊りを興行にできなければなんの価値もない。

ある一つの仕事だけが素晴らしいのではなく、それを支えるための数多の仕事が存在しているからこそ、素晴らしい仕事が素晴らしくあれるのだ。

本当はアーティストやクリエイターは社会インフラを支えている人には頭が上がらないはずなのだ。

それを自分が楽しく仕事をできているからといって、世の中のみんなの仕事も楽しくあるべき、などというのは無責任すぎる。

逆に「仕事マジクソだわー」みたいにグチを言う人は、文句は言うが仕事自体はしっかりやってくれる。

仕事をちゃんとしているからグチが出る。

表現はネガティブだが成果はポジティブだ。

宿題もやるから面倒くさいのであって、そもそもやらなければめんどいもクソもない。

仕事が楽しいという人だけが集まると実務がまわらなくなる。

仕事が楽しいと言っている人は無意識に楽しくない仕事を他人に丸投げしているので、楽しんで仕事している人の周りの人達は楽しくない仕事をしている。

楽しそうにしているから寄ってみたものの、いざ一緒に働くと楽しくない仕事をさせられるのですぐに人が去ってしまい、人の入れ替えが激しい状態になる。

「楽しい仕事」の裏にはこういった闇も絶対に芽生える。

光が射せばどうあがいても影はできる。

だから本当は「仕事は楽しいもの」ではなく「つまらない仕事にこそ価値がある」と思わせたほうが世界に対しては優しいのだ。

その点においては昔の宗教の教えのほうが格段に素晴らしかった。

仕事はカルマの解消であってダルマを積むためのもの、と言っておけば、つまらない仕事や苦しい仕事であってもやる意義を見いだせるのでどんな仕事であろうとみんながしっかり打ち込めた。

ところが「仕事は本来楽しいものだ」と言い出したら楽しくない仕事の存在意義がなくなってしまい、今まで辛い仕事や苦しい仕事をこなしていた人たちから仕事をする動機を奪ってしまうことになる。

そう考えると、なにも考えずに念仏さえ唱えてさえいれば救われる、とした親鸞は最高に合理的であるといえる。

仕事が楽しいとかつまらないとかそんな次元のことはどうでもいいから、とりあえずみんなには救われる可能性がある、としたのはすごい。

無条件にあまねく者を救いの対象にしたのは強い。

ポジティブはネガティブを救済しない時点でまだまだ旧来の宗教と比べ劣っている思想なのだ。

ちなみにマインドフルネスは「ポジティブだろうがネガティブだろうがとりあえずみんなには救われる可能性がある」を現代風に言い直した言葉なのだと思う。

苦しいことやつまらないことにも価値は必要なのだ。

2019/05/08

やさしさは人を疲弊させる

空想上の物語では人にやさしくすると、やさしさが巡り巡って最後は自分に返ってきてハッピーエンドになります。

しかし現実は人にやさしくすると、その相手が他の人にも同じやさしさを無条件に求めるようになって、別の見知らぬ誰かが疲弊するようになります。

自分が相手にやさしくした場面だけをみると、善行にみえますが、その相手が別の誰かに同じやさしさを要求した場合、そのやさしさを要求された側は理不尽な労力を求められます。

やさしさを無条件で求められた側からすれば「余計なことしやがって!」となります。

ある牛丼屋が気を利かせて冬に熱いお茶をサービスとして提供していたら、他のチェーン店もそれに習ってお茶を提供するようになり、バイト側からすればお茶出しという余計な仕事が増えただけでつらくなる、みたいなやつです。

「やさしさ」だけを評価すると無条件に良い行いに捉えられますが、マクロでみた場合、それがほんとに善行かどうかは疑わしくなります。

よくある例えとして、発展途上国に物資だけを援助するのは本質的には無意味、という言説があります。

現品だけを与えても、その施しがなくなれば、元の木阿弥にしかならないからです。

支援物資に対する依存だけを植え付けて、結局はそれを頼らないと生きていけない状態にするのは、どちらかといえば「援助」というよりかは「支配」です。 (じつは国際援助の本質は援助でなく間接的な支配です。国は世界を良くするために他国を支援しているのではなく、自国に利益が見込めるからこそ支援しています)

個人単位でみた場合、施し側はやさしさでやっているかもしれませんが、結果は救済どころか他者依存を深めてより窮地に陥れているだけです。

根本的に貧困から脱するには、やさしさによる施しを与えるのではなく、自立した経済圏を構築できる社会性を各々に植え付ける必要があります。 (もちろんこのレベルに達する国際援助も存在します)

相手に対して過剰に施しを与えてしまうと、相手がそれがデフォルトの対応だと認識して、別の人にも同じクオリティを求めるようになってしまいます。

先ほどの例だと支援物資だけに頼るようになり、自ら何かを生み出そうとする動機を奪ってしまい、さらなる支援が必要になり、さらなる労力が必要になってしまいます。

目に見える感情に頼った施しによるやさしさだけで十全になることはほとんどありません。

そのやさしさが、そもそも不要になること自体がほんとのやさしさです。

やさしさだけでは相手を救えないし、第三者の負荷も上げてしまいます。

また、やさしさは、どちらかといえば相手を隷属させるための道具としての側面が強いのです。

意識的にしろ、無意識にしろ、やさしさは怠惰と隷属を生み出す源泉になるのです。

故に、やさしさはダンピングやスポイルの温床になりやすいのです。

無条件に褒め称えてよい概念ではないのです。

できるからといって、なんでもかんでもやさしさを発揮してしまうと、その分、他の人が面倒を見る際のコストがどんどんかさんでいくので、ほどよいところで見切りをつけることも時には必要です。

やさしさは潤滑油のようなもので、噛みあわせの悪いところに適度に差す分にはいいですが、使いすぎると歯車が汚れやすくなり逆にトラブルの元になります。

そして、潤滑油は歯車そのものとしての機能はないのです。

2019/04/02

不正確さは他人の仕事を増やす

前回のエントリでは、人に何かを頼むときは、事前に互いの認識を揃えましょう、という話をしました。

今回はそれを疎かにした場合に起こる認識のズレがどれほどのコストを生むのか、というお話です。

ところでみなさんはよく、作業が早いだけでその人を優秀な人と判断していないでしょうか?

エンジニアの仕事に例えると、タスクを振ったらすぐにプルリクエストをあげてくるような人です。

それを受け取った依頼者は「もう終わったの。さすがだねぇ」みたいに言うわけです。

この時点ですべての仕事が完了になるなら「さすが」です。

しかし内容を確認してみると、コメントが全く無かったり、コメントがあっても雑でよく理解できなかったりで、相手にいろいろ「ここのこれってどういうことなの?」みたいに更に確認が必要になったりします。

さらに、バグがあったり、仕様とは違った実装だと発覚すると最終的にリジェクト(却下もしくはやり直し)になったりもします。

こうなってくると、プルリクエストの時点でほぼほぼ完了だと思っていたのが、進捗率0%の振り出しに戻ってしまいます。

確認に手間取ったり、再提出となると作業者のコストも依頼者の確認コストもどんどん積み重なっていきます。

ここで、それぞれのパターンにおけるコストを図示化してみていきましょう。

図1

まずは、普通のスピードで作業を行い、提出物が一発で通った場合です。

この時の作業者のコストを100、確認者のコストを10ぐらいと見積もると、トータル110のコストでタスクが完了します。(図1A)

次に、仕事の早い人がいて、半分の50で作業を終わらせたとしましょう。

しかし、成果物の内容のすり合わせなどが必要になり、互いに更にコストが発生した場合が図1のBです。

トータルではコストが低くなっていますが、作業者が倍の成果を出しているかと言われると、そんなことはなく、トータルで1.3倍ぐらいの成果です。

しかも、確認者のコストを余分に使っているので、第三者の労力をスポイルにした成果ともみれるわけです。

そして、やり直しとなると普通の速さで作業したときよりもコストが増えます。(図1C)

しかも、その分のコストは自分ではなく他人になるのです。

ここからさらに確認作業が長引いたり、やり直しとのダブルコンボになったり、それらが複数回発生してくると、無限にコストが増殖していきます。(図1D)

作業者が正確に仕事を行い、確認者に対して分かりやすい状態まで準備をしてからバトンを渡してあげれば、少なくとも確認者のコストを最小限に抑えられます。

自分ひとりの仕事がいくら早くても、それが雑なアウトプットであれば、チェックする側だったり管理する側だったり、利用する側の人が無駄なオーバーヘッドを強いられるのです。

そして最終的にチーム全体としてのコストは膨らんでしまい、全員の仕事時間をすべて足すと想像以上にコストが膨らんでいた、ということは往々にして発生します。

タスクにまつわる人と時間が増えるほど、他者に可能な限り無駄な時間をかけさせないことに価値が生まれるのです。

長期的には自分の仕事を速く終わらせるより、他人の仕事を早く終わらせるようにするほうが価値が高いのです。

自分ひとりだけだと一人分の時間の節約にしかなりませんが、他の人の時間も節約できるなら、最大でチーム内にいる人数分の時間を節約できます。

ですので、作業の速さよりも正確性を求めたほうがチームとしては早く作業が終わるようになるのです。

2016年のリオ五輪で日本が400メートルリレーで銀メダルをとれたのは、まさにこの理屈による成果です。

個別の実力では他国の個別選手のほうが圧倒的に上でしたが、連携時の無駄なコストを可能な限り削減し、チーム全体としてのタイムを一番短縮できたのです。

バトンをうまく渡すことによって、次に走る人のアウトプットを最大限引き出せた上での結果なのです。

ウサイン・ボルトが第一走者だったら日本が金メダルを取れていた可能性すらあるほど、個人の実力以上に他人のオーバーヘッドをなくすほうがチーム戦においては価値があるのです。

そこで次に、作業の質が後の作業にどのような影響を与えるかを分かりやすく図にしてみました。

図2

作業には時間がかかったが、その後の影響度が少ない場合が図2のEとなります。

最初に作ったシステムから機能の追加や改善タスクが増えていっても、改修コストを低く抑えられます。

限られたコストの中で沢山の改善タスクを回せます。

次に作業が速くても、その後の影響が大きい場合を表現したのが図2のFです。

雑な作業の結果が後に関わる仕事すべてに影響を及ぼし、限られたコスト内でみると、先ほどよりも改修できる作業の数が減ってしまいます。

そして現実では関わる人が増えるほど、改修が繰り返されるごとに、エントロピーの法則により作業に対するコストは上昇していきます。(図2G)

これが一般的に言う技術的負債です。

エントロピーの法則に可能な限り抗うためには、雑に早く作業するよりも、少し時間がかかっても丁寧に作業を行うほうが良いのです。

以上のとおり、一人の仕事が早かったとしても、その仕事の結果が後に与える影響まで考慮した場合、生産性が低くなるケースはまれによくあると分かりました。

目に見えないコストは他にもたくさんあるので、人が協力してうまく仕事をこなしていくのは大変ですね。

More entries ...