経験・行動面接

例えば、増分処理のモデルの条件を変えたときに全件の作り直しを忘れ、過去分と新しい分で定義の違う数字が混ざったことがあります。アナリストの指摘で気づき、影響する期間とダッシュボードを洗い出して先に連絡し、全件で作り直して元の数字と突き合わせました。

原因は、増分のモデルを変えたときの手順が人の記憶に頼っていたことだったので、レビューのチェック項目に「過去分への影響」を加え、CI で本番との件数と主な指標の差を出すようにしました。ミスそのものより、仕組みで防ぐように変えたことを中心に話します。

例えば、営業から「受注した時点で売上に数えたい」、経理から「出荷した時点でないと売上ではない」と言われ、ダッシュボードの数字でもめたことがあります。私はどちらが正しいかを決める立場ではないので、まず両方の使い道を聞き、指標の持ち主を経営企画に決めてもらいました。

結果として「受注額」と「売上（出荷基準）」を別の指標として定義書に書き、ダッシュボードに両方を名前を分けて出しました。以後、同じ種類の問い合わせは減りました。相手の目的を理解し、決める人を立てて、定義を文章に残したことがポイントです。

例えば、cron とシェルスクリプトで動いていた 50本ほどのジョブを、オーケストレーターに移す選定をしました。比較の軸は、依存関係と再実行の扱い、チームの言語（Python）との相性、運用の手間（管理サービスがあるか）、費用の4つにしました。

候補を2つに絞り、実際のジョブ 5本で2週間試し、バックフィルのしやすさと失敗の通知の分かりやすさで決めました。決めた理由と、選ばなかった案の理由を文書に残し、半年後に振り返りました。比較の軸を先に決め、小さく試して決めたことを伝えます。

結論から言うと、多くの人の判断を支える仕組みを作れることにやりがいを感じるからです。例えば、手作業で集計していたレポートを自動化し、毎朝正しい数字が届くようにしたとき、営業の人たちが数字をもとに動き方を変えるのを見て、基盤の価値を実感しました。

今後は、より大きなデータやリアルタイムの処理に挑戦しつつ、品質とコストの両方を守れる基盤を作りたいと考えています。御社では〜のようにデータが事業の中心にあると知り、そこで力を発揮したいと思いました。

必ず用意しておきます。たとえば、データのテストや鮮度の監視がどこまで入っているか、最近のデータの障害とその後に変えたこと、データエンジニアとアナリストの分担、指標の定義を誰が決めているか、パイプラインの失敗の当番の体制、入社後半年で期待される成果、などを聞きます。

答えから相手のデータ基盤の成熟度と自分の役割が分かり、関心の高さも伝わります。聞いた答えに、自分の経験でどう役に立てるかを一言添えると、最後の印象が良くなります。