各工程で心がけたい思想を掘り起こしてみる
「問題解析」、これを取り上げてみますか。製造工程の要ですね。 私が実際に経験したケースで考えてみます。
システム試験で問題発生
「システム試験であるシナリオを流したら、タイムアウトした。」と一報が入ました。そのシナリオは自分が担当しているモジュール(「モジュールA」としときましょう)がメインで動くシナリオなので、解析依頼が来て作業開始です。
解析手法
現場ごとに、いろいろですね。デバッガをつないだり、解析装置で信号線の入出力確認したり、ログだけが頼りなんて場合もあります。慣れない環境ではてこずる場合もありますが、ともかく限られたデバッグ情報をもとに原因を究明しなければなりません。 まずは報告通りの現象になっているかを確認しましょう。ここが食い違ってると話になりません。
システムの問題解析
解析担当になった時点で、担当モジュールの不具合を探すのではなく、システム内の不具合を探すという心構えが必要ですね。「モジュールA」がメインだとしても必ずしもそこに問題があるとは限らないわけですから。特に自分のモジュールの品質に自信が持てないとそのモジュール内の犯人探しに時間を浪費し、問題の本質を見落とす上に貴重な時間を浪費してしまいます。デバッグ情報から客観的に何があったかを見極めましょう。
「モジュールB」登場
調べてみると、「モジュールA」がスタックしていました。スタックしている原因を探ると「モジュールB」から想定外のデータが入力されているようでした。本来なら、「モジュールB」の担当者に解析担当を振って、ひとまず様子見ですね。ところが、、
時間がない！
問題が解決しないと週末の無人連続運転ができないとか、リリース期限が迫ってるとか、問題解決を急がされるケースがありますね。幸い各モジュールの担当者は同じフロアで作業しています。すぐに「モジュールB」の担当に来てもらい一緒にデバッグ情報を見てもらいました。すると、「モジュールC」から読みだしたデータをそのまま使っているとのことでした。すぐに「モジュールC」の担当に来てもらうとデータの設定は「モジュールD」が行うとのこと、、 最終的に、「モジュールE」の担当まで来てもらい、テストシナリオに必要なイベント送信が無いことが判明しました。解析担当を振っただけなら二日くらいはかかったかもしれませんが、数時間で問題解決です。この時、実際に各担当に声をかけたのは私ではなく「モジュールB」の担当者でした。
何か掘り起こせた？
- 客観的にデバッグ情報から状況を正確に把握する
- 周囲を巻き込む力 「周囲巻き込む力」はスピード勝負では特に大事ですね。「システム内の不具合を探す」というスタンスだからこそです。
おしまい
現場によっては別のモジュール担当が遠隔地にいるなんてこともありますね。そんな時はどうするべきですかね。問題は山積みです。
