KEIS BLOGは株式会社ケイズ・ソフトウェアが運営しています。

KEIS BLOG

しごできエンジニアは問題解決のときにソースコードは見ない


こんにちは、サヤマです。
今年は飲み会番長を名乗るのも恥ずかしくなってきているサヤマです。

最近、愕然としたことがあったので紹介します。

入社当時にとある先輩に教わって、大事に懐にしまっていた調査の基本があります。

大前提:推測を絶対にしないこと
① 何が起きているのかを正確にまず把握する
② 原因として考えられるいくつかの仮説を立てる
③ ソースやデータを見にいき、どんな処理が行われるのか、どんな状態なのかを理解する
④ 少しずつ条件を変えて、動作確認を行う
⑤ 想定と同じ結果か、違うのならば、なぜ違ったのかを特定する
⑥ ひたすら②-⑤をループ

これ自体はとても良いと思っていて、わりとこの通りに調査を進めていることが多いなと思います。
ですが最近、えっっっぐいミスリードがあることに気づきました。
タイトルからお察し、かもしれませんが…

ここ!
しごできエンジニアは問題解決のときにソースコードは見ないんですよね…

調査の基本は「データ」を見ることです。
わたしが今回ぶちあたっていた調査は、
お金の計算をするシステムで、とある表ととある表の数字が合わないよー
というものです。
わたしはソースコードを真っ先に見に行き、
ここが怪しいのはわかったけど…これ以上はちょっと難しいかも…
と、先輩に相談をしました。

その日中に、先輩が出してきたのは、
なんと、Excel!!!!
画面に出ている表の数字をExcelに張り、とある表ととある表の数字を比較し、
合っていない原因の箇所はココ、というレポートをくださったのです。

正直、愕然としました。

ソースコードが書けるとか読めるとか、
そういうのは調査のときにはあんまり関係ないんですね。
言われてみれば、経験上でもソースコードを見るより、
画面に出ている情報やログ、操作手順などの運用方法を確認したほうが
あっさり解決することが多いように思います。

我々はエンジニア。ソースコードを書くのも読むのも大好き。
ついついソースコードにばかり目がいってしまいますが、
こと調査においては、まずソースコードは遠ざけよう、と
肝に銘じたサヤマなのでした。