AWS「技術的なお問い合わせに関するガイドライン」は職業問わず全員に読んで欲しいに深く同意するし共有したい

真剣な顔のテレフォン・オペレーターのイラスト(女性)
Twitterまとめ「togetter」で話題になっていたこちらに同意しすぎるので共有します。誰かに何かを問い合わせようとしている人に届け






どんなことが書いてあるかというと



togetterに元ツイートがあるので読んでいただきたいところですが、僕の方でも抜粋してみるとこんな感じ。


技術的なお問い合わせに関するガイドライン | AWS サポート



最終的に実現したいことと現在の状況を詳しくご共有ください


解決したい課題を明確にご記載ください


文脈依存性のない記述にご協力ください


すでに試した対応策があればご教示ください


課題が解決した際のお願い




ホントマジでこれ

対応に困るパターンで一番多くあるのは、質問者が自分で状況や原因を断定し説明してくれないこと。経験上、状況や原因を適切に判断出来る人はその理由を人に説明できますし説明します。説明しない人には断定するだけの能力が不足していることが多く、断定そのものが間違っているか根拠がありません。「最終的に実現したいことと現在の状況を詳しくご共有ください」や「解決したい課題を明確にご記載ください」で書かれているように、自分で「この情報は必要ないな」と判断するのではなくきちんと全部伝えて欲しい。仕事に限らず コミュニケーション不全の第一歩は「予断」から です。


ローカルでだけ通用する用語もかなりの敵です。正社員だった頃から社内用語を振り回す人には要注意フラグを立てていたのですけど、フリーランスになってからはより一層その影響を受けるようになりました。社内用語、業界用語がわからないんですよね。昔に比べて僕も大人になったので曖昧な用語を使われたときはバカの振りして1から全部聞くようにしてるんですけど、自分が使っている言葉が相手に伝わらないということ自体がわかっていない人がほとんどです。言葉は相手に合わせて選ぶものだと思うんですけど、会社に所属して毎日同じ人と仕事してればそういう感覚も希薄になるんでしょうね。わかります。わかるけどさ。


最後に重要なのは解決したあとのこと。理想は「直りました!」だけでなくて「何をしてどういう状況からどういう状況になってOKを出した」というのがわかると良いんですけど、そこまでではなくても直ったぐらいの報告は欲しい。それがあれば、把握した症状と対応策とを付け合わせた上で「こういう場合はこうすれば良い」という知識を蓄積出来ます。ないと出来ない。そしてそれをしない人に限って同じ質問/同じような質問をしてきたりするんだよなあ。



要求定義と要件定義

先日仕事で「要求定義と要件定義を意識してほしい」というリクエストを軽く投げたんですよ。


要件定義とは、技術者が、システムを動かすための仕様を定義したものです。 「◯◯であるべき」「◯◯が必要」という表現になります。
要求定義とは、非技術者が、システムに求める仕様を定義したものです。 「◯◯したい」「◯◯になること」という表現になります。

要件定義と要求定義の違い、ご存知ですか? | 新規事業・イノベーション共創メディア | Battery(バッテリー)


というのも、非エンジニアからのリクエストが「要件定義」に落とし込まれた状態で回ってくることが多いんですけど、もっと良い改善案が予想出来るんです。でも「要求定義」が知らされていないから「もっと良い改善案」がホントにもっと良いかどうかを判断出来ない。リクエストが冗長になっても良いから、まず要求定義を記載した上で改善案としての我々の考えた「要件定義」をあげてもらえれば、それが必要十分ならそのまま設計と開発に移行しますし、不十分ならより良い改善案を提案できます。


それをせずに「要件定義」だけを見て作業をした場合、上手く行くこともあるけど結構な確率で「思ってたんと違う」って言われるんですよ。こっちからすると「説明の通りにやるとこうなるんです」なんですけど、納得してもらえるわけもなく(想定と違うんだし)、1回「思ってたんと違う」が始まってから「要求定義」の説明が始まり、「要件定義」をエンジニア込みで揉む作業が行われるので二度手間になる。ストレスっていうか時間の無駄なんですよね。。僕はそんなに仕事抱えてないけど、みなさん忙しいなか時間取ってミーティングして決めてると思うんでね。。



で、このことがつまり簡単に言うと「最終的に実現したいことと現在の状況を詳しくご共有ください」に書かれていることです。画像、再掲します。







「最終的に実現したいこと」というのが「要求定義」で、その共有が一番大事なんですよ。「これはいらんやろ」と自分で判断してしまう(=予断)のではなくて、出来る限りのことを説明して一緒に解決していく姿勢を作って欲しい。そうすると早くすんなり解決に向かいます。いやあ、マジでこれなんよ。なかなか伝わらないんですけどね。その人が優秀かどうかは関係なく知らなければ出来ない、知ってれば誰でも意識できることなので、マジで全員に読んで欲しい。


自分からフリーランスで入ってる会社のSlackに流すのは気が引けるので、誰か見つけて流してくれないかなあ。



リンクまとめ


togetterのまとめ

「義務教育で教えて欲しい」AWSの『技術的なお問い合わせに関するガイドライン』は職業を問わず全人類が読むべき – Togetter

AWS「技術的なお問い合わせに関するガイドライン」

技術的なお問い合わせに関するガイドライン | AWS サポート