意思決定ができるようになるまで
業務で「なぜスムーズに意思決定できるのですか?」と問われたが、自分ではほぼ無意識にやっているようなことだったので深掘りしてみる。
仮説
前提として、エンジニアになってからのキャリアの方がエンジニアに以外のキャリアより短い。
エンジニアになる前からそうだったのか、エンジニアになってからそうなったのか、自分でもよくわからない。
ただ、前職で上長が1on1で言ってた「課題を特定して解決手段を構築する流れは、そのまま要件定義の進め方と同じである」という考え方(私の意訳)が蘇ってきたので、前職でやっていたことがもしかしたら役立っているのではないかと思った。そこで、前職の経験をまとめてみることにする。
これまでの経験
ユーザーからの20~30件/日程度のお問い合わせに毎日対峙した
問い合わせをしてくるユーザー、問い合わせを一次受けするカスタマーサービス(以下CS)担当者、私たちのチームのエンジニア、インフラチームのエンジニア、という関係者がいる中での業務だった。
情報を適切に整理して問題を切り分け、然るべき対処をとるのが私の仕事で、エンジニアとして自分が手を動かす機会よりも適切な人を巻き込んでユーザーの困り事を解決する
で、実はこれ結構いい練習になっていたのではないかなーと最近気付かされた。
実際にユーザーの書いた問い合わせ内容を直接読む機会が多々あった
私たちからすれば軽微なことでも、ユーザーは結構困っている
ユーザーのほとんどは声をあげない。問い合わせとしてアクションを起こしてくれるユーザーは貴重であるという認識
提供サービスがレンタルサーバーなので、お問合せしてくるユーザーの先にはサイトを訪問してくれる方の存在が常にある状態
→直接対峙するユーザーのその先のお客さんやビジネスについて想像をめぐらす機会が多くあった
→直接ユーザーの声を目にすることでユーザー目線でのものの見え方を知ることができた(もともとエンジニアではないので理解は容易かった)
ユーザーが申告した問題が必ずしも正しい課題とは限らない(この誤りが恣意的かどうかは置いといて)
ユーザーは、ユーザーに見えているものだけを問題と捉えている
ユーザーは、必ずしも全てを正確に申告しているとは限らない
ログは嘘をつかない
お問い合わせの中でユーザーが使う言葉、問い合わせを受けるCS担当者が使う言葉と自分達が使う言葉の定義がずれていることがある
→前提を疑う、目の前のお問合せに対して状況を整理してから課題と向き合うようになった
→目の前の問題に対して、常に正しく課題設定しようとする癖がついた
ログや実装から事実を整理し、発生している事象や結果から辻褄が合うように逆算し、必要に応じて考察を添えて解決策や起きていた問題についての説明を提示する
探偵のように推理(仮説)を元に証拠(ログなど)をかき集めて、過去のある時点で何が起こっていたかを特定する作業
→時系列を追って、論理的に仮説と事実と考察を整理して文章を作成する癖がついた
→問題の全体像を把握する癖がついたので、そこから問題の切り分けを適切に行えるようになった
調査Issueを読み込んで他の人の考察の過程をトレースする練習
プラスひとりの体制で少し時間的な猶予をもらっていたのでこのような作業に時間を多く使っていた
問題の発生パターンを頭に入れることができ、対応時間の短縮にもつながった
同様の問題に現在進行形で自分が対峙している時は、過去の参考対応で論理が飛躍していると感じる部分は自分の理解や知識で埋められない部分がある可能性があるので、直接本人に意思決定の過程について質問をしたりした
自分が真似したいと思った振る舞いについて、どうやったら再現性があるかを直接質問するなどして深掘りした
1on1ではよく自分と他者の違いについて、その溝がどうやったら埋まるかを相談していた記憶がある
→身近にいる人をモデルにして振る舞いから思考の過程をトレースして身につける訓練
- 調査結果が出揃ったところで、お問合せの落とし所を決める
- 前例があるケース
- 過去の事例を踏襲する
- 過去の事例を反故にして自分なりの考えをまとめて方針を出す
- 前例がないケース
- ここまで集めた物的証拠(直接的なログ)と状況証拠(ユーザーの申し出や他のログとの整合性など)とを合わせて論理を組み立て意思決定する
- 意思決定のタイプは、様子見、他チームエスカレ、修正対応、
- 自分が意思決定した道筋を理路整然とテキストに残し、誰でも意思決定の過程を参照できる状態にする
- 必要に応じて有識者にレビューをもらって自分の意思決定についてフィードバックをもらう
→気づけば小さな意思決定を何度も何度も繰り返す過程で、意思決定の「型」を身につけていた
参考
マインド