わかること、わからないこと

私はとあるシステムのプログラマー兼SEをやっていたりする。携わるシステムは規模が結構大きめ。でも既に運用して数年が経過してるから、チーム人数はそんなに多くない。時々機能改善の要望やバグがあったら対応するくらい。
私のチームリーダーはプログラマー経験がないから製造はからっきしだけど、別の大規模システムのSEとして、気難しい顧客と調整したりというマネジメント経験があって、自分にはないスキルを持っていて格好良いな思ってる。
先日、バグらしき挙動が発見されたので私に原因特定のお仕事が回ってきた。ただ、その機能は滅多に手が入らず、自分も数年前に当時の先輩のお手伝いをしただけ。しかし、他に適任もいない。
役者不足じゃないかなと思いつつ話を聞くと、特定の順番で機能を動かすと情報が落ちるらしい。似たようなパターンいくつかとの比較が既に試されていて、ある１パターンだけエラーになるらしい。
パターンの特殊性や機能内部のフローを思い描いた時に、こりゃプログラム覗くよりは仕様と動作からアプローチしたほうが早いわと思い、手元で再現しようと思っても上手くいかない。
再現性があることまでは確認してるから、自分の操作が悪いんだろうかと思いつつ悪戦苦闘していたら、リーダーが様子を聞きにきた。

リ「どう？」
私「あ、今再現に手間取ってます。」
リ「ん？ソース見れば分かるんじゃないの？」

多分自分の器が小さいからだけど、「ソース見れば分かる」という一言に、反射的に反論したくなってぐっと堪えた。
リーダーは、折衝と調整は経験していても、製造チームとしての経験は浅い(12月に配属された)し、私達も製造について知ることはリーダーに求めていない。でも、ちっちゃな事だと頭で解っていても、さらりと言われたことにぐさりときてしまった。
ソースを見れば分かるというのは、ある意味で正しいし、でも、膨大なソースを読むだけではわからないことも意外と多い…というのは作ってみないと分からないのかもしれない。
その立場的なわかる、わからないを「わかるべき」に変えたとき、技術者と管理者が摩擦するような気がする。プログラマーからすると知っていてほしいことなんだけどね。
リーダー好きだけどな。愚痴っぽくなってスミマセンデシタ。