私たちが扱うAzureのOSS（Azure Database for PostgreSQL / MySQL flexible server）のマネージドサービスは、日々すごいスピードで機能が増えています。それと同時に、ドキュメントも常に更新され続けており、日本語版は自動翻訳をベースに整備されているページも少なくありません。その結果として、なんとなく言いたいことは分かるけれど、日本語として少し読みづらいであったり、本当にこのとおりの仕様なのか不安になるといったモヤモヤを感じる場面もあると思います。
一方で、お客様の現場では、そのサービスを使って本番システムを支え、ビジネスを動かしていただいています。
このギャップを埋めるために、私たちサポートチームが何をしているのか。
そして、お客様にどのような情報をいただけるとさらに製品をより良くしていけるのかをお伝えしたい、というのが本記事の意図です。
ドキュメントの違和感は、遠慮なく教えてほしい
まず、Azure のドキュメント（Microsoft Learn）は、グローバルの仕組みとして、すべてのページにフィードバック機能が用意されています。各ページの上部や下部にある「フィードバック > このページは役に立ちましたか？」から、内容が分かりづらかった点や誤りの可能性を直接送ることはできます。
とはいえ、実際のところ、運用中に気になった箇所についてのフィードバックは、担当者をつけるのが1番良いと考えます。
そのためにサポートリクエストを上げて、弊チームに気軽な気持ちでご相談いただけたらと私たちを考えています。
サポートリクエストを作成いただく際に、 「このドキュメントの、この段落が分かりづらかった」や「日本語のニュアンスが英語版と違うように見える」といった形で URL と該当箇所を教えていただくことも、とても重要な情報になります。
私たちサポートチームは、その情報を整理したうえで、ドキュメント担当チームやプロダクトチームにお客様の声としてお届けしています。このページではどのように具体的に開発部門と連携をしているかと言うところも後述いたします。
「できない」ときこそ、理由や背景を教えていただきたい
サポートにお問い合わせいただく内容は、大きく分けると二種類あります。
- 既存機能や仕様の範囲で、問題を解決する（トラブルシューティング）
- したいことや、できないことに対するご相談
1つ目は、いわゆる問題解決のサポートです。
一方で、2つ目はプロダクトマネジメントに直結する内容です。
クラウドの強みは、現行仕様としてはできないことも、将来のアップデートで実現できる可能性があることです。
Azure Database for PostgreSQL / MySQL flexible serverも、ここ数年でできることが継続的に増えてきています。
ここで、お客様にぜひお願いしたいのが、「なぜその機能が必要なのか」「ビジネス上どのようなインパクトがあるのか」をできるだけ具体的に教えていただくことです。
たとえば、以下のような情報があると、私たちサポートチームがプロダクトチームにエスカレーションする際に、単なる思いつきの改善要望ではなく、現場で実際に困っているお客様の具体的なニーズとして伝えることができます。
- ビジネスやシステム全体でどのような背景でその要件になっているのか
- 既存の機能や設定で代替すると、どこに無理が出るのか
- 運用チームや開発チームにとって、どのような手間やリスクが発生しているのか
完璧ではないこと、完璧を目指し続けること
ここで誤解していただきたくないのは、「一緒にサービスを育てていきたい」という言葉は、「とりあえず中で開発しているから、細かいところはお客様の力でなんとかしてほしい」という意味では決してないということです。
この世に存在するどのようなプロダクトでも、まず作る側は作る側の視点から、可能な限り良いものになるよう作るという特徴があります。想定しているユースケース、セキュリティや信頼性の要件、コストやパフォーマンスの制約 といった多くの前提を踏まえながら、今できるベストを目指して設計が進んでいきます。
ただ、どれだけ真剣に考えても、現実には視座の観点でもある程度の限界があります。すべての環境、すべての業種、すべてのパターンを最初から完全にカバーすることは、クラウドに限らず、業界を超え、すべてのプロダクトでほぼ不可能です。
むしろ、完全に分かったつもりになり、進化させることをやめてしまうことのほうが、長期的には危険だと考えます。
大事なのは、最初から完璧にできているかどうかよりも、完璧にはできないかもしれないが、可能な限り完璧に近づこうとし続けることを実行することだと私たちは考えています。
この完璧を目指し続ける姿勢は、開発もサポートも同じです。
リリースされたサービスをどう検証し、どうドキュメント化し、どうお客様に届けるか。その過程のどこかで漏れや解釈の揺れがあった場合でも、お客様の声を聞き、必要であれば設計や表現を見直し、その結果をまた次のリリースやドキュメントに反映していくというサイクルを早く回し続けることで、少しずつ現場にとっての実用的な完璧に近づけていくことができます。
その意味で、内側だけで考えられる限界を、お客様の現場の視点で押し広げていただく。そのような背景からお客様の力が必要です。
サポートは問い合わせ窓口ではなく、プロダクトとの橋渡し役
ここからは、日々プロダクトマネージャー（PM）とやり取りしている立場として、少し具体的な空気感をお伝えしたいところです。
社内の会話のトーンとして、決して「うちのロードマップはこう決まっているから、その要望は無理です」という 決め打ちで終わるものではありません。
むしろ、「確かにその声はもっともだ」「それは今の仕様だとつらいね」といった形で、お客様の声の妥当性そのものを一緒に検証するスタンスが強いです。
そのうえで、妥当だと判断されたものについては、既存のロードマップの中で優先度が見直される あるいは、ご要望の一部だけでも早めに取り込めないか検討されたりといった動きになります。
ドキュメントについても同様で、「ここは確かに分かりにくい」「このパターンは現状の説明だと漏れてしまっている」といった議論になれば、その日のうち、あるいは比較的短いサイクルで修正が入り、実際のページに反映されていくことがあります。
つまり、社内計画がこうだから、外から何を言われても変わらないという姿勢ではなく、それが妥当かどうか、どれだけ多くのお客様に影響するか、どの程度のリスクとコストで改善できるかを、毎回きちんと会話したうえで判断しています。
Azure の OSS マネージドサービスのサポートは、単にトラブル対応をするだけではなく、日々のケースを通じてプロダクトチーム（開発チームやプロダクトマネージャー）と密にやり取りしています。サポートから単に「お客様がこう言っています」と投げるだけではなく、なぜその背景でそういう要望になっているのか、既存機能や構成とのトレードオフはどこにあるのかに加えて内部情報といった文脈を添えて社内で議論できるのが、サポートの役割です。
もちろん、すべてのフィードバックがすぐに製品の仕様変更や新機能として反映されるわけではありません。優先順位や技術的制約、セキュリティ上の理由など、さまざまな観点から検討が行われます。
それでも、中長期的に見たときに、お客様の声が仕様検討の議論の土台になることは間違いありません。
サポートとしても、単なる問い合わせ窓口で終わるのではなく、お客様 ↔ プロダクト の間をつなぐ橋渡し役として、できるだけ多くの生の声を聞きたいと考えています。
一緒にサービスを育てていくために、お願いしたいこと
ここまでの話を少しだけ整理すると、一緒に製品をより良くしていくうえで、スムーズになる情報は次のようなものです。
まず、ドキュメントに関しては、どのページのどの部分が分かりにくかったのか、具体的な URLと箇所を教えていただけると、ドキュメント改訂の議論にスムーズにつなげやすくなります。英語版と日本語版で意味がずれているように見えた場合は、その比較も重要な材料になります。
次に、機能や仕様に関するご要望に加え、その背後にある業務フローやアーキテクチャ、ビジネス上の制約を共有いただけると、プロダクトチームにとっても判断しやすくなります。
お客様の現場の声やその背景の中には、クラウド側の機能として提供すべきかどうかを考えるうえで、重要な情報がある場合があります。
製品としてどうしても得意ではないことや、設計思想としてあえて対応していないことが存在するのも事実です。
そのような場面では、正直に「現時点では難しい」というお話をさせていただくこともありますが、そのときにも、「なぜその設計になっているのか」「どこまでであればワークアラウンドで寄せられそうか」「今後の方向性として、どういう観点を社内に伝えていくべきか」といった部分は、形式的なやりとりではなく、担当するお客様と会話しながら進めていきます。
おわりに：問い合わせのその先へ
サポートに問い合わせるとき、多くの場合は「いま目の前で困っていることを解決したい」というのが第一の目的だと思います。
私たちサポートも、まずは目の前の問題を解決することを最優先に考えています。
ただ、その少し先に、「このサービスがもっとこうなったら良いのに」「このドキュメントがこう書き換わったら、自分以外のユーザーも助かるのに」という長期的な観点でもサポートすることが可能です。
この世に存在するプロダクトは、実際に使い込んでくださっているお客様の視点が加わって、はじめて現実的で、現場に根ざしたものになっていきます。
そして、その進化を弊チームが扱う製品(Azure Database for PostgreSQL / MySQL flexible server)に当てはめると、提供する側と利用するユーザーという一方的な関係ではなく、1 件 1 件のケースで人と人が向き合うことから始まると考えています。
今後も、お気軽にご相談、実際の声を聞かせていただければ幸いです。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。