見出し画像
Photo by noouchi

問い合わせ調査好きなんだけどなんていう領域なんだろう

chobishiba

こんにちは。chobiishibaです。普段はエンジニアリングパートナーとしてお客様と一緒に開発する仕事をしています。

開発にまつわるタスクは色々ありますが、そんな中でも問い合わせ調査がタスク好きです。
先日もこんなことポストしてました。

問い合わせ調査が好き

問い合わせを受けて、実装とログとDBを行き来しながら何が起きたか、仮説と検証を繰り返して突き止める作業が結構好きです。
実装の傍ら、という状態が特に好きです。作ることも好きなので、調査100%ではなく、ちょこっとでもいいので実装もしながらが好きです（手を入れたことのあるアプリの方が圧倒的に調査が捗るのもある）。

なのでどこのプロジェクトでも「誰か調べて〜」タスクは嬉々として取りに行っちゃいます（何を期待してアサインされるかはそのプロジェクトによって変わるのでいつも関われるとは限らないのが残念なところですが）。

まだRubyをやる前、汎用機の世界（COBOL）にいる頃も保守開発をやっていたので、そこで問い合わせ調査は開発と同じくらい毎日の仕事に組み込まれてるものでした。なので私にとって調査は割と身近なものです。

とはいえ、ユーザーの方には問い合わせしなきゃならない作りにしてすみません & CSの方には問い合わせを受けて下さってありがとうございますの気持ちでいるので、許される限り可及的速やかに回答をお返しすることを信条にしてます。

あんまり同意が得られない

個人的には割と楽しんでやってる問い合わせ調査ですが、これ周囲に聞いてみるとイマイチ好きじゃないって反応が多いんですよね。

  • 原因かわからなかったらと思うと気が重い

  • （割り込み作業なので）開発の計画がずれるから嫌

  • 突き止めるより、新しく作りたい

という意見が多かったです。

原因かわからなかったらと思うと気が重い

確かに原因かなかなかわからない時や、調査が考慮されてないログしかなくて特定しきれない時は大変に感じることもありますが、「プログラムは書いた通りにしか動かない」のである程度のところまでは必ずいけるという強い心で挑んでます。
（毎度「そんなバカな」と思いながら調査すると「そうなりますよね😇」に行き着きつくんですよね）

（割り込み作業なので）開発の計画がずれるから嫌

最初に問い合わせ調査やったプロジェクトが、来るか来ないかわからない（でも多分来る）問い合わせ分の稼働を見越して機能追加の開発計画を立てるチームだったので、今もその感覚で計画を立てます。
計画も、全員が調査やるという前提で計画立ててもよし、メインの実装する人と、ブロッカーにならないタスク片手に調査がきたらそっちを優先する人に分けてもよし。
こんなフォーメーションでやってたこともありました。

原因突き止めるより、新しく作りたい

好みって人それぞれだと思うし理屈じゃない部分あると思うのですよね。なのでそんな方はぜひ！私と！組みませんか！！

調査してるといいこともあるよ

調査をやっているとそのアプリの癖もわかってくるので、機能追加するときの影響範囲や、アプリとしての振る舞いの統一感などそういうところへの気づき力も上がります。

好きですがもちろんできる人を増やしておかないと、おちおち休んでられないし、怖いもののハードルは下げておいたほうがいいしと、ペア調査や、そこまで緊急度の高くないものなら一度1人でやってもらって行き詰まったらペア調査するなど「いざとなったら私に投げればいいからま、やってみ」と言いながら日頃から触れてもらったりしてます。（そういって育ててもらったので自分にもそう言える分野ができて嬉しいところです）

問い合わせを活かす

ものによっては、問い合わせが来る前にこちらで検知できるようになった方がいいよねってものもあります。リリース前にいろんなことを想定するものの、どうしても運用して初めてわかることも出てくるので、調査後はどうすればこの問い合わせを起こさずに済んだか、アプリの内部処理、UI、マニュアルいろんな方法をいろんな職種の方と検討して改善案考えるのも好きな作業です。

どうやって学んだか

調査の仕方どうやって学んだか聞かれることがあるんですが、私は先人の調査結果からです。
いい調査ログには調査の過程トレースすることができるんですよね。
まず何が起きたか確認して、どういう仮説を立てて、ログやのDBのどこを見て、実装と照らし合わせて、どう結論づけたか
そういうのをみていると、ああそういうキーで抽出するといいのかとか
こういう小技があるのかとかも学びの宝庫なんですよね。
（昔いたプロジェクトでは調査結果資料集を「虎の巻」と呼んでました）

なので割と私も辿れるように残します。
そうしておくと自分の調査が間違ってないか、漏れがないか、自分でも確認できるし、他の人にレビューしてもらうのにも使えます。

そんなふうにしてたらある現場では直接関わったことの無い方から、実は調査ログに助けてもらってましたなんて言っていただくこともあって、私が先人にしてもらったことがちょっとは次の人に回せたのかな？なんて嬉しく思ってます。

さてこれはなんという領域なのか

今年は働きはじめて20年で、周年イヤーなこともあり今までやってきたことを棚卸したりしてるのですが、今までやったことでいくらでもやれちゃう作業はもしかしたらこの問い合わせ調査なのかもなと気がつきまして。
そういう好きなことをやれる時間をどうやったら増やしていけるか、もっと調査スキルも上げたいし、情報キャッチアップもしたい。名前知っていたらそういうのもはかどるんじゃないかなと気になっています。

開発や保守の1領域とも考えられるし、CREとして独立してるような体制のところもありそう。「調査」以外に技能としてなにか名前ついてたりするのかな〜

この記事が気に入ったらサポートをしてみませんか？