はじめまして。
製品部門に異動してから1年ほど経過した、Y.Sです。
元々はお客様向けに当社ecbeing製品をカスタマイズ・構築する部門で長く仕事をしていました。
これまでの活動を振り返ってみると、開発メンバーの問題解決のサポートであったり、
お客様環境で発生している問題の調査・調査支援を行う機会がかなり多かったと感じています。
ここで言う「問題」とは、システムエラー/データの不整合/システム間連携が上手くいかない/パフォーマンスが出ない、などの技術的な課題全般のことを指します。
当社のようなWebアプリケーション開発部門において発生する課題に対して、
素早く原因を突き止め解決に導くために心がけていることについて、今日は話してみたいと思います。
※もちろん、過去の経験が問題解決に直結するケースも少なくないですが、この記事では経験にない問題にあたった場合の対処の心がけについてを取扱います。
- 問題の出所からは、細かく情報を聞き出す
- 類似の事例がないか情報を集める
- 生成AIを活用する
- 切り分けを続け、考慮する範囲を狭くしていく
- 素早くトライ&エラーできる環境を整える
- データの動きを見る、Before&Afterを比較する
- まとめ
- お知らせ
問題の出所からは、細かく情報を聞き出す
何かの調査に当たる時、最初に起こすアクションになります。
具体的には以下のような内容をヒアリングします。
（自分が出所の場合は、以下の内容を調査します）
いつから発生していたか。
どのような条件で発生するか。また、発生しない条件は何か。
確認していた環境（サーバー、OS、ブラウザ等）
解決のために、これまで何を試したか。
これらの内容を確認後、同じ条件で再現を確認することが出来てからが調査スタートのイメージになります。
逆に再現が確認できない場合は、条件の見落としがあるか、そもそも出所の確認ミスの可能性もありますので、さらにコミュニケーションが必要となります。
類似の事例がないか情報を集める
再現確認が出来たら、まず情報収集から始めることが多いです。
ドンピシャで同じ問題にあたって既に解決しているケースを見つけることが出来れば、原因調査の手間も省け、対策をそのまま流用できるため、一番のスピード解決になります。
情報収集の手段としては、主に以下を活用します。
社内リソースを活用
社内チャットツール内で全体チャット検索（Teams、Slack）
社内チャットツールの質問チャネルから質問を投げる
社内の有識者に質問
その他
Webで自然検索（世の中一般的な問題の場合）
生成AIを活用する（後述）
当社は非常に多くのお客様に向けて機能開発をしていますので、 これらの方法で同じ問題にあたっている社内のメンバーを見つける確率は決して低くはなく、かなり優先度の高いアクションだと思っています。
一方で、他の社員がナレッジを見つけられるように、こちらで調べて解決に至った情報は社内の公開領域にアウトプットしておくことも重要です。
生成AIを活用する
社内機密情報をAIに投げる場合は、入力内容が学習に利用されないセキュアなAIサービスを利用する必要があります。
ecbeingの場合は、当社グループ会社の株式会社ソフトクリエイトが提供している「Safe AI Gateway」を社内利用しています。
このような環境がある前提ですが、特に以下のようなケースで有用だと感じています。
- 読み解くのが大変な情報をAIに投げて、分かりやすく説明させる
例えば、以下はデータの登録処理でDBのデッドロックエラーが多発した際に
AIに問い合わせした内容になります。
XML形式で出力されるデッドロックのレポート情報をかみ砕いて説明してくれ、非常に理解しやすいものとなり、原因の特定がしやすくなりました。
他にも、エラーメッセージ、スタックトレースと対象メソッドのコードを投げて原因を推測させる等の使い方も有効だと感じました。
社内用AI以外だと、私の場合は「Perplexity」を調査に活用することが多いです。
リアルタイムにインターネット検索を行い、関連する情報源を元に 回答内容を生成してくれます。
検索にかかるような内容であれば、かなり高精度な回答が返ってくると感じています。
切り分けを続け、考慮する範囲を狭くしていく
Webアプリケーションは複数の技術スタックやコンポーネントで構成されています。
バックエンド、フロントエンド、データベース、外部API、ネットワーク環境など、問題がどこにあるのかが特定できないまま調査を進めると、膨大な時間がかかります。
特に混み入った調査の場合は、原因を切り分けることで、調査範囲を狭め、解決に至るまでの時間を短縮できます。
例えば、APIを呼び出した際に、期待するデータが取得できないような場合は以下のような切り分けポイントがあります。
- リクエスト内容
- レスポンス内容/レスポンスの元データの状態
- ヘッダ情報
- API認証・アクセス制限
- ネットワークの問題の確認
- 環境依存の問題
これらの切り分けポイントを考え、一つ一つクリアしていき考慮する範囲を狭くしていくことが重要と考えています。
素早くトライ&エラーできる環境を整える
APIの例を続けますが、実際のアプリケーションの実行環境だけで調査を進めると、クライアント側の画面遷移や状態管理が調査の障害になり、問題の切り分けに時間がかかることがあります。
そこで役立つのが、Postman のようなAPIテストツールです。
以下のようなメリットがあります。
- 直接APIを呼び出せる
- 素早くパラメータを変更できる
- 履歴管理と再利用性
APIの例に限らずですが、すぐに特定が難しいような問題の場合は、実際の実行環境ではなく、デバッグ実行やテストツールを活用して、素早くトライ&エラー出来る環境を整えることが重要になります。
データの動きを見る、Before&Afterを比較する
データの比較を行うことが、問題特定のためには必要になることもあります。
状況にもよりますが、具体的には以下のような観点で比較をします。
- 問題が発生しているデータと、発生していないデータの比較
- 問題発生前と後のデータの比較
- 問題発生前と後のデータが出来るまでの過程の比較
まとめ
それぞれの優先順位は一定ではなく、取り組む問題によって臨機応変に変えていく必要がありますが、私の場合は概ねここで挙げたような考え方を組み合わせて問題解決にあたることが多いです。
参考となれば幸いです。
お知らせ
ecbeingでは新進気鋭なエンジニアを募集しております！ careers.ecbeing.tech
