開発していれば、自然と疑問が出てくるものです。SaaSをはじめ、APIベースでサービスを提供する場合、サーバ側で何が行われているかはブラックボックスになります。エラーが出たとしても、コードを追いかけながら確認することはできません。

よりよい開発体験（DX）を提供するためには、次の観点が必要です。

• ユーザ環境に近いこと
• レスポンスが早いこと
• コミュニケーションが少ないこと

この観点から、優れたサポートが何なのか解説します。

原因と対応が明確なエラーメッセージ

数分

まずユーザ環境だけで解決するのが一番良いです。例えばSDKを使っている場合、SDKの中でエラー判定をし、処理をクラウド側に送る前にエラーメッセージを出せるようにします。必須項目漏れなどのエラーがこれに該当します。

Something wrong は最もだめなエラーメッセージです。かつてPerlをCGIで動かすと、Internal Server Errorしか返ってこない時代がありました。この時にはデバッグが本当に大変で、コードを一つ一つ確認しながら解決していました。その後、エラーが起きた行数やトレースができるようになり、開発効率は大幅に向上しています。

APIでも同様に、ただ単にエラーですと出すのではなく、何のエラーなのかを明確にしなければなりません。さらに、そのエラーを回避する方法についてもメッセージを出すべきです。開発者はエラーメッセージを読んで修正を行ったり、必要があればメッセージに記載されたURLを開いて詳細を確認できます。

開発元に問い合わせることなく、ユーザ自身ですぐに解決できるのがベストです。なお、エラーメッセージを独特なものにしておくのもコツです。例えばOracleのエラーIDは常にORA-9999といった形式なので、エラーIDで検索すると検索で見つかりやすくなります。汎用的なエラーメッセージはかえって情報が増加し、探しづらくなる可能性があります。

エラーメッセージでドキュメントを記載する

10分程度

エラー内容がよく分からない場合、開発者はそのエラーメッセージでWeb検索するでしょう。そうした時に備えて、ドキュメント（またはブログ）で解説しておきます。

この時、エラーメッセージ一覧表を用意するだけでは意味がありません。こうしたエラーメッセージ一覧表は、NOT_FOUND を リソースがない といった単に日本語化しただけの場合が多くなります。開発者が知りたいのはエラーを解決法であって、その意味ではありません。どうしたらエラーを回避できるのか、どういった修正を行えば良いのかを記事化する必要があります。

Q&Aサービスを使う

数時間〜回答なし

Web検索で思ったような答えが見つからない場合、開発者はQ&Aサービスを使うでしょう。例えばTeratail、Stack overflowまたは独自のフォーラムなどです。

Q&Aサービスは善意の回答者が現れないと答えの得られないサービスです。すぐに答えが返ってくるかもしれませんが、永遠に返ってこないかもしれません。開発者は質問を投稿しますが、答えが来るまで黙って待っていられる訳ではないでしょう。そのため自己解決の道は模索しつつ、Q&Aによる答えを待つのが普通です。

Q&Aサービスは同じような課題に対して、2番目以降の人たちにとって役立つサービスになります。先進的な人たちは常に答えのない中、さまようことになるでしょう。

オープンなQ&Aサービスの場合、ある程度汎用的に聞く必要があります。自分たちのワークフローに寄りすぎていると、回答できる人も少なくなってしまうでしょう。エラー原因がよく分かっていない場合、質問すらできないかもしれません。

公式のサポートを頼る

数時間〜数日

Q&Aと前後して、公式のサポートを利用する開発者もいるでしょう。多くの場合、公式サポートは有償ユーザー向けに提供されます。また、チケットなどもあり、いつでも何でも使える訳ではありません。そのため、ある程度厳選して利用することでしょう。

公式サポートの場合、1対1で提供されるものが多いです。また、契約によっては詳細なワークフローに関係するものであったり、実際のソースコードを見せながら回答をもらえます。

公式サポートは契約次第ですが、翌営業日中の回答などというケースがあります。また、確実な回答ではなく、調査中といったステータスの報告である場合もあるでしょう。必ず解決できるとは限らないのはQ&Aサービスと同じくらいです。

ソースコードをあたる

数時間〜不明

SDKがオープンソース・ソフトウェア（またはソースコードが開示されている）の場合、実際のコードを見ながらエラー原因を探れます。大型なSDKの場合、ファイルや役割が細かく分担されているため、一目でエラーが分かることはないでしょう。また、JavaScriptのように難読化されていると、さらにコードを追いづらくなります。

とはいえ、ブラックボックスになっているSDKよりは幾分扱いやすいはずです。もちろんSDK側のコードを調べても、結局API側のエラーで何も分からなかったという結論になることもあります。

エラーが回避できない場合

もし開発者が皆さんのサービスを使っていて、エラーをどうしても回避できなかったらどうするでしょうか。まずサービスの利用を止めるはずです。そして代替サービスの利用を検討するでしょう。

最も良くないのは「このサービスは難しい・利用しない方が良い」という印象を与えてしまうことです。一度与えてしまったネガティブな印象を払拭するのは困難です。

1. すでにエラーを解決できなかったというネガティブな経験がある
2. 回避できる手段を公開したとしても、それを届ける手段がない

一度サービスから離れてしまった開発者を取り戻すのは、ほぼ不可能です。もしもう一度類似技術の導入検討を行う必要があったとしても、検討の土俵に上げてもらえることはないでしょう。

まとめ

開発時にエラーは付きものです。エラーなく開発が終わることは100%ありません。重要なのはエラーが出た後に、どう素早く解決できるかになります。素早く自己解決できれば、開発者はあなたのサービスに対して、ポジティブな印象を持つことでしょう。

大事なのは、ユーザの利用している環境に近いこと、セルフサポートできること、短時間で解決できることです。その観点からサービスやSDKのエラーメッセージを設計すると、よりよい開発体験の実現につながることでしょう。