値を追っているのに、どこで変わったか分からない人へ ｜ データの流れから原因を切り分ける考え方

はじめに

・ブレークポイントを置いている

・値も確認している

・でも原因が分からない

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

例えば、

「画面に表示される値がおかしい」

という問題が起きたとします。

すると、

値を見る

値を見る

また値を見る

気付けば何十分もデバッグしている。

でも原因は見つからない。

実はこれ、

新人だけでなく経験者でもよくあります。

なぜなら、

多くの人が

👉 コードの流れ

は追っているのに、

👉 データの流れ

を追えていないからです。

本当に確認したいこと

ここで考えるべきなのは、

👉 今の値

ではありません。

確認したいのは、

👉 どこで値が変わったのか

です。

そのために、まず整理することがあります。

最初に整理すること

調査を始める前に、

次の3つを考えます。

① 正しい値は何か

まず基準を決めます。

本来どうなるべきなのか。

これが曖昧だと調査できません。

② 値はどこで作られるか

その値は、

・画面入力

・DB

・API

・ファイル

・計算結果

どこから来ているのか。

まず入口を確認します。

③ 値はどこで変わる可能性があるか

ここが重要です。

値が変わる可能性がある場所を洗い出します。

例えば、

・計算処理

・変換処理

・条件分岐

・マッピング処理

・受け渡し処理

などです。

ここまで整理できると、

調査する場所が見えてきます。

よくある勘違い

例えば、

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

すると、

UI担当の人は画面周りを調べ始めます。

でも実際のシステムは、

入力

↓

Request

↓

Core

↓

DB

↓

Core

↓

Response

↓

画面

のように複数の層を通っています。

この場合、

画面の値がおかしいからといって、

原因がUIとは限りません。

例えば、

パターンA

Requestで渡している顧客IDが間違っていた

パターンB

Core側で別のデータを返していた

パターンC

受け渡し時の変換処理で値が変わっていた

パターンD

UIで別の項目を表示していた

どれも実際によくあるケースです。

つまり、

👉 画面がおかしい

ではなく、

👉 値がどこで変わったのか

を見る必要があります。

データの流れで考える

例えば、

顧客名が「田中」になるべきなのに、

画面には「山田」と表示されている。

その場合、

DB

↓

Core

↓

Response

↓

UI

の各地点で値を確認します。

DB 田中
Core 田中
Response 田中
UI 山田

だったら、

原因はUI付近です。

逆に、

DB 田中
Core 山田
Response 山田
UI 山田

だったら、

Core側の処理を調べるべきです。

つまり、

値を追うとは、

変数を見ることではありません。

👉 正しい値が最後に存在していた場所

を探すことです。

なぜ迷子になるのか

多くの場合、

問題が起きると

すぐにデバッグを始めます。

でも、

本来は

問題発生

↓

原因候補を考える

↓

検証する

です。

ところが、

原因候補を考えずに

いきなり検証を始める。

だから、

ブレークポイントが増える。

だから、

値を見続ける。

だから、

迷子になる。

分からなければ相談する

もちろん、

すべて一人で解決できる必要はありません。

ただし、

相談するときは

「分かりません」

ではなく、

例えば、

・DBでは田中だった

・Coreでも田中だった

・Responseでも田中だった

・UIで山田になった

・原因はまだ不明

という形で伝える。

すると、

相談される側も状況を理解しやすくなります。

逆に、

「画面がおかしいです」

だけでは、

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

まとめ

値を追っているのに原因が分からない人は、

値そのものを見ています。

でも本当に確認したいのは、

👉 値がどこで変わったのか

です。

そして、

今見ている場所が原因とは限りません。

画面がおかしいからUIが悪い。

API結果がおかしいからCoreが悪い。

そう決めつけるのではなく、

値がどこで作られ、

どこで変わり、

どこで使われているのか

を追うことが大切です。

値を追うとは、

変数を追うことではありません。

👉 システムの中を流れるデータを追うこと

です。

おわりに

今回の話は、

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

品質問題でも、

障害調査でも、

現場改善でも同じです。

現象を見る。

↓

原因候補を考える。

↓

検証する。

この流れは変わりません。

コードを読む力も大切ですが、

原因を追跡する力は、

言語や担当工程が変わっても使える力だと思います。

もし、

「こういうパターンでもハマった」

という経験があれば、ぜひ教えてください。

今後の記事で取り上げていきます。

関連記事

この値どこから来た？が分からない人へ

→ この値どこから来た？が分からない人へ ｜ 値の発生源を見つける手順

処理の流れが分からない人へ

「値がどこで変わったか」を追う前に、
まず処理がどの順番で動いているかを理解したい人はこちら。

→ ソースは読めるのに処理が追えないのはなぜ？｜フローを追っていたはずなのに迷子になる原因

値が null になる原因を追いたい人へ

今回の記事では値が変わる場所を探しました。

値そのものが消えている場合はこちら。

→ null の原因が分からない人へ

デバッグで迷子になる人へ

原因候補を考えずにブレークポイントを増やしてしまう人はこちら。

→ ブレークポイント置いたのに原因が見つからない人へ ｜ デバッグで迷子になる3つのパターン