はじめに

・画面に値が表示されている

・値も取得できている

・でも、この値がどこで設定されたのか分からない

そんな経験ありませんか？

新人や新しい現場に入った人から、

よくこんな相談を受けます。

「この値、どこから来てるんですか？」

そして多くの場合、

コードをひたすら追いかけて迷子になります。

でも実は、

値の発生源を探す時には手順があります。

今回は、

実際に私が現場でやっている調査の進め方を紹介します。

前回の記事との違い

前回は、

「どこで値が変わったのか」

を調査する考え方を紹介しました。

今回はその前段階です。

まずは、

👉 この値はどこから来たのか

を見つけます。

発生源が分からなければ、

どこで変わったかも追えません。

よくある状態

例えば、

画面に顧客名が表示されているとします。

CustomerName = customer.Name;

ここまでは見つけられる。

でも、

customer がどこから来たのか分からない。

さらに追う。

var customer = service.GetCustomer();

さらに追う。

repository.GetCustomer(id);

さらに追う。

気付けば、

たくさんのクラスやメソッドを開いている。

そして迷子になる。

なぜ迷子になるのか

理由は単純です。

多くの人は

👉 コードを追っている

からです。

でも本当に知りたいのは、

👉 値の発生源

です。

つまり、

コード全部を見る必要はありません。

値に関係する場所だけ見ればいいのです。

実際の探し方

私が探す時は、

次の順番で見ます。

① 値を使っている場所を見つける

まずは今見えている場所です。

CustomerName = customer.Name;

ここで確認したいのは

customer

です。

② 代入元を探す

次に、

customer がどこで設定されたかを見る。

var customer = service.GetCustomer();

ここで

GetCustomer

が次の調査対象になります。

③ 戻り値を探す

GetCustomer の中へ入ります。

return repository.GetCustomer(id);

今度は

repository が調査対象になります。

④ 発生源にたどり着く

例えば、

SELECT * FROM Customer

が見つかった。

すると、

この値は

👉 DBから取得している

と分かります。

ここで初めて、

値の発生源が見つかります。

見つかったら終わりではない

ここが重要です。

発生源が分かった。

終わり。

ではありません。

次は、

その値が正しいかを確認します。

パターンA

DBを見ると、

田中

になっていた。

本来表示したい値も

田中

です。

つまり、

発生源は正しい。

すると、

DB
↓
Core
↓
Response
↓
UI

のどこかで値が変わっています。

この場合は、

前回の記事で紹介した

「どこで変わったか」

を調査します。

パターンB

DBを見ると、

山田

になっていた。

画面も

山田

です。

すると、

原因はDBより前です。

例えば、

・登録処理

・更新処理

・バッチ処理

などを調査します。

パターンC

DBも正しい。

Coreも正しい。

Responseも正しい。

でも画面だけ違う。

この場合は、

UI側の表示処理やバインド先を確認します。

原因箇所が担当外だった場合

実際の現場では、

原因箇所が自分の担当範囲とは限りません。

例えば、

UI
正常

↓

Request
正常

↓

Core
異常

だったとします。

この場合、

さらにUIを調査しても解決しません。

やるべきことは、

調査結果を整理して担当チームへ依頼することです。

例えば、

現象

顧客名が「田中」になるべきところ、
「山田」と表示される

確認結果

UI受信時点で「山田」

Responseでも「山田」

Core処理結果でも「山田」

DBでは「田中」

添付

ログ
取得データ
画面キャプチャ

ここまで整理できれば、

担当チームも調査しやすくなります。

逆に、

画面がおかしいです

だけでは、

相手も最初から調査をやり直すことになります。

まとめ

値の発生源を探す時は、

コードを全部追う必要はありません。

まず、

① 値を使っている場所

↓

② 代入元

↓

③ 戻り値

↓

④ 発生源

を辿ります。

そして発生源が分かったら、

その値が正しいかを確認する。

結果によって、

次の調査範囲を絞ります。

関連記事

・ソースは読めるのに処理が追えないのはなぜ？

・値を追っているのに、どこで変わったか分からない人へ

・ブレークポイント置いたのに原因が見つからない人へ

おわりに

今回の話は、

デバッグだけではありません。

障害調査でも、

品質問題でも、

現場改善でも同じです。

問題が起きたら、

まず発生源を探す。

次に正しいか確認する。

そして結果から調査範囲を絞る。

これは仕事を進める時の基本的な考え方でもあります。

コードを追うのではなく、

データを追う。

その意識だけでも、

調査のスピードは大きく変わると思います。