1. ninjinkunの声日記
  2. デバッグの要領で問題を特定し..
2024-06-06 08:56

デバッグの要領で問題を特定した話

仕事で起こった問題をプログラミングのデバッグ的なやり方で解決した話をします。


 

00:01
こんにちは、ninjinkunです。
昨日、仕事でちょっとやったなっていうことがあって、あんまり詳細は話せないんですけど、
とあるお客さんから依頼されたことがあり、
それをUSのメンバー経由で、さらにUSのコントラクター、
契約社員というか、手伝ってもらっている人に伝えてもらってやってもらったんですけど、
その依頼してきた日本側のお客さんから、
いや、言った通りになってないですよという指摘をもらって、
で、それをそのまま向こうに伝えてもよかったというか、そのままやるとそうなるんですけど、
ん?と思って、そこでちょっと引っかかるものがあったので、
US側に伝える前に、そのお客さんが共有してきたドキュメントとかをもう一回読み返すと、
いや、これはお客さん側が、お客さんも別の部署から言われたことを僕らに伝えてたんですけど、
具体的なことは話せないんで、めちゃめちゃモヤっとした言い方になっちゃいますけど、
その別の部署から言われたことを伝えてきてたんですけど、
その別の部署から共有されてきて、さらにそれが僕らに回ってきたドキュメントを見ると、
その依頼してきたお客さんの解釈が、これは間違ってるなとおそらく、まだ今確認中なんですけど、
と思ったので、US側は多分これにのっとって今こうしたなっていうのが推測できたので、
一回グッとこらえて、US側には伝えつつ、
多分あなたの対応は問題ないから、一回お客さん側に確認するねって言って戻して、
で、US側はまだ寝てたので、朝になって見たら、
そうそう、あなたの言う通りでこれに従ってこうしたよって言ってて、
あ、この対応でよかったなと思って、おそらくはお客さん側の間違いでこれは多分確定かなっていうふうに僕は思ってるんですけど、
はい、なんで、それでうまいこと先回りというかして、
変な無駄なやり取りを減らせたんじゃないかなっていうふうに自分では思ってます。
03:00
はい、これは何かこういう問題を発見したりするのは何か若干プログラミングにも似てるかなと思ってて、
何か問題が起きたときにどこかが間違ってるということが想定されて、じゃあどこが間違ってるのかっていうことを考えていきますよね。
そういうときにまず相手が言ってることが正しいというふうに仮定して問題を特定していくわけですけど、
そのときにでももしかして誰かが間違ってるっていう可能性が出てきて、
そのときは伝え方に問題があるか解釈に問題があるかのどっちかかなっていうふうになりますよね。
そうすると問題がじゃあ伝え方を検討して、その伝え方が合ってたら誰かの解釈が間違いだから、
じゃあ解釈は聞くしかないから、でもその中で全員聞いて回るよりもまずは怪しそうなところを発見したいってなると、
そのバックグラウンド知識みたいなものがより専門性が高い人やっぱ間違いづらいし、
っていうふうにして疑っていくというか発展していくんですけど、
今回いうとその依頼してきたお客さんの担当者は他の部署から聞いたことを言ってるだけだったので、
その依頼に対する専門性は高くなかったんですね。
一方で解決したそのUS側のコントラクターはその辺りは一応専門家であるという感じだったので、
これは依頼側に問題があるんじゃないかなと思って調べたらどうもそうだったという感じだと思います。
なので、それこそプログラムで言うと、自分のコードと使っているライブラインのどっちがバグがあるかって言ったら、
自分のコードの方が遥かに間違いやすいわけですよね。
あとはライブラインにバグがある場合も、やっぱりたくさんの人がメンテしているライブラリよりも、
少ない人がメンテしているライブラリの方が間違いやすいし、みたいな感じで問題を絞り込んでいくわけですけど、
同じようなことを応用してやってるなというふうに思いました。
本当は別の話しようと思ったんですけど、問題を特定できたのが嬉しかったので話しちゃいました。
これにタイトルをつけるとすると、
プログラミングの応用で問題を特定した話みたいになるんですかね。
あともう一個思ったのは、リモートワークをして特に時差があるので、
06:07
時差がある場合にこういう相手がどういうふうに考えているかをトレースするってすごく大事だなって思っていて、
やっぱりリアルタイムでやり取りができないので、相手ならこう考えるだろうとか、
これだけの前提知識を与えれば動いてくれるだろうみたいなところまで先回りして考えて、
ドキュメントなり情報を用意してお願いして、あとはもう信頼するっていうふうにするんですけど、
対面でやってるとその場でリアルタイムで情報を交換しながら、
じゃあこれわからなかったらこれこれって感じで多分できると思うんですけど、そうできないので結構先回りしていろんなことを用意するっていう習慣が、
こういう実際にリモートワーカーは多分あるんじゃないかなと思っていて、
前うちにいたUSのメンバーとかもそういうのがすごいうまくて、朝起きてくると、
ここまで用意してくれたんだみたいな、まさにこれが欲しかったみたいなことが結構あったので、
自分もそういうことができるといいなと思ってやってるかなと思います。
今回の場合でいうと、そのUS側のコントラクターの頭の中をトレースして、
おそらくこう考えただろうっていうことを考えて対応したという感じで、
結果的には合ってたっぽいので良かったなと、もちろんね間違うこともいっぱいありますけど、
いくつか話が混ざっちゃいましたけど、さっきの通りのタイトルで行こうと思います。
プログラミング的な思考で問題を特定した話。
ありがとうございました。
使おうなんですけど、結果的に問題は思った通りに解決しました。
ので良かった。目指し目指しという感じです。
あとこれを自分で聞き返して、プログラミングというかデバッグ的な思考ですね。
これはどっちかっていうと、デバッグってこうなんか、よくバイナリーサーチって言いますけど、
2つに問題を分割して、さらにそれを分割してっていう風に、
その絞り込んでいくようなことをしますけど、どうもそういうことを自分は言いたかったのかなと思ったので、
タイトルもまあ多分そんな感じのものにすると思います。
はい、ではありがとうございました。
08:56

コメント

スクロール