Q&A
HTMLというタグは全く関係ないので外してくださいね
例えば、ウェブデザインのあるところが分からないのでコードを貼ってこうしたけど分かりませんと伝える能力を上げるのにコツはいりますか？
ここで質問・回答をしているうちに上達すると思いますが、自分の質問文の書き方が悪くよくマイナス評価がつきます。
ビジネスでは、話すことを短く要点をまとめて書くと言われていますが、プログラミングの仕事では伝え方が違うと思います。
teratailの質問をする際の注意事項を読んでもうまく整理できません。
仕事になれば丸々コードを貼って分かりませんというのはできないので、今からそういう癖をつけたいです。
タイトルには「プログラミング」とありますが、本文ではウェブデザインに触れておられる様子。WebデザインはHTML/CSS/画像の分野なので、プログラミング言語の問題ではないですね。この場合、タグとして適切なのは [デザイン], [HTML], [CSS] となるでしょうか。最も、質問の履歴を拝見しますと、JavaScriptの質問もあったようなので、「プログラミング言語のコミュニケーションにフォーカスする」のなら、[プログラミング言語] のタグをつける方向性もあると思います。このように「タイトルと本文で質問している内容が異なる」という事実は、質問に低評価を投じられる原因になり得ます。「マークアップ言語」「スタイルシート言語」「プログラミング言語」がそれぞれ別の言語である事を理解していれば、こうした間違いは発生しないのですが、「正しい用語」を知らないが故に曖昧な質問になってしまっているわけですね…。
回答5件
0
コードで伝える
基本的にプログラミングはコードを伝えてコミュニケーションをとるものだと思います。
コードがない状態で日本語による説明をすると、行き違いが発生する事が多々あります。
話し手の誤解から間違った用語で説明してしまったり、前提となる知識が間違っている事によって起きる場合がほとんどですね。
コードの変質による誤解
コードには語彙力の差から間違いが起きる可能性がほぼないので、日本語による説明よりは安全です。
「ほぼない」というのは「実際に動かしているコードをそのままコピー＆ペーストせずに、掲示板に投稿できるようにコードを改変していく中で、当初の問題とはかけ離れたコードを開示してしまうことがある」からです。
「問題が再現可能な最小限のコード」を出すことが大切なので、最小限のコードを作る際に逐一問題の再現性をテストする必要があります。
最も、大抵はその過程で自己解決しますので、正しい切り分け方を知っている人はあまり質問をしません。
以下、stackoverflowより引用します。
最小限であること
確認しなければいけないコードの量が多くなればなるほど、問題の原因を見つけにくくなります。サンプルコードを減量するには 2 通りのやり方があります：
- 一から作り直す プログラムを新規作成し、問題を再現するのに必要な部分のみを追加していきます。コードが大規模で、関連箇所を特定できそうであれば、最初から作り直した方が早いケースがあります。実際のコードを（契約上、倫理上の理由から）公開できない場合にも有効な方法です。
- 各個撃破する コードの量が少ないが問題の箇所を特定できない場合、問題が再現できなくなるまでコードを少しずつ削ります。そして最後に削った部分が問題の箇所ということになります。
日本語による説明
コードではなく、日本語で説明するには扱っているプログラミング言語における「正しい用語」をよく理解している必要があります。
初心者特有の思い込みが一切なく、しっかりと基礎勉強を固めて、間違いないと確信をもっていえる用語だけを使う事が重要です。
とにかく「作り上げる」事を優先すると、基礎知識が疎かになりがちなので、分厚い本を読むなり、仕様書を読むなりして勉強する事も必要になります。
Re: skpro さん
投稿2018/01/26 15:48
総合スコア18162
日本語でRuby本体に投げられたIssueに対して、外国人が「Sorry I don't know Japanese, but was able to understand the Ruby at least」と、コードを読んでバグを解決していった、という話もありました。
https://bugs.ruby-lang.org/issues/11804
To: maisumakun さん
興味深いですね。プログラミング言語が他国語の壁を乗り越える良い例だと思いました。
0
質問を書く際に参考になると思われる記事を紹介しておきます。一度目を通していただければ幸いです
技術系メーリングリストで質問するときのパターン・ランゲージ
http://www.hyuki.com/writing/techask.html
質問するときのヒント
https://teratail.com/help/question-tips
後者の記事にある "人に質問をするには、自分が何を尋ねたいかを知っている必要があります。これは、「自分が今『何がわからないのか』がわかっていて、言語化できている」ということです" というところが重要だと思います。
言語化といっても「掲示板に書いてあること以外は知り得ない第三者が読んで分かるように」という条件があるはずです。その力をつけるには知識も身に着ける必要があって時間がかかると思いますが、それでも以下の情報は提供できるのではないですか？
(1) 何を作っているか
(2) 開発環境
(3) 全体のシナリオを含めて何がしたいのか
上記 (1), (2) は、プログラミングに関する質問をする以上、常識的に書くべきことだと思うのですが、書いてない人が多すぎます。
例えば、TextBox がどうこうという話から始まる質問をよく目にしますが、何の TextBox か分からない。それでは話が始められません。OS や .NET のバージョンによって話が大きく違ってくるのにそれが書いてない。（聞いても、無視して書かない人もいます。何を思っているのでしょうか・・・スミマセン愚痴でした）
上記 (3) については、そうすると質問が冗長になるということもあるかもしれませんが、特に初学者の人は、簡単でいいので書いた方がよさそうです。
全体的なやりたいことやストーリーのごく一部を切り出して質問すると、もしその質問が全体的なやりたいことを実現するのには見当違いだった場合、回答も当然やりたいことを実現するには的外れになってしまいます。そうすると、見当違いと的外れのやり取りが繰り返されるだけになって、なかなか解決にたどり着けません。時間の無駄でもありますし。
局所的な質問の部分は実現が無理 or 他にもっと良い方法があるような場合、「それはできない or そのやり方は適切ではないけど、やりたいことはこうすれば実現できる」というような代案も出てくるかもしれませんし。
投稿2018/01/27 02:16
退会済みユーザー
総合スコア0
0
ベストアンサー
伝える能力を上げるコツ。次の二点を挙げておきましょう。
- テンプレを活用する
- 他山の石を活用する
teratailは親切設計で、質問をしようとするとテキスト入力欄にテンプレートが表示された状態になっています。まさにこういう質問こそがteratailにあるべき姿なのだと開発運営側が教えてくれているわけです。まずは自分の状況を個別要素に分解して、このテンプレートにできるだけ素直に当てはめてみることです。ドンピシャでないように最初は思えても、すこし視点を変えれば自分が抱えているのはまさにこの項目だ、と気づけることもあります。テンプレは偉大です。最初はおとなしく従ってみましょう。こういうところで変にオリジナリティを発揮する必要はありません。
テンプレには先達が苦労して作り上げた汎用的なものがいくつも知られています。PREPとかSDSとかDESCとかです。詳しくはググっていただきたいですが、例えばDESCならこうです。
- Describe(描写): 問題を客観的に描写する
- Express(表現): 主観的な意見や問題点を述べる
- Suggest(提案): 上記の問題点に対する解決法を提案する
- Consequence(結果)またはChoose(選択): 提案を実行した場合に期待できる結果を提示する
これはどちらかというと「報告」用ですから、質問に使うとなるとアレンジは必要です。しかし使えないわけではありません。「自分はこれこれを目指している者で最終目的はこうです」がDで、「こういうコードを考えてみた」はEで、「こういう問題が発生して解決できない」は提案ではないがS、「最終的にこういう結果がほしい」がCと考えられるでしょう。多少無理やりでも型にあてはめてみれば楽に文章が構築できます。
teratailをしばらく観ていると、ときどき回答と質問がかみ合っていない事例があることに気づきます。そういうのを観察しましょう。なぜ理解してもらえないのか？ なぜ回答者があからさまにイライラ感をかもしだしているのか？ 多くのケースで「この説明じゃわからないよねー」と感じるものがあるはずです。自分を振り返るのは難しいですが、人の不備を見つけるのは比較的簡単です。そして、その「不備」はしばしば自分に当てはまっているのです。
投稿2018/01/26 17:04
総合スコア13671
SDSとは「安全データシート(Safety Data Sheet)」のことでしょうか。
ぐぐってみたのですが、安全データシートのサンプルを読んでみると質問文に応用できるようには読めず、実際には別の単語を指しているのかもしれないとも感じています。
http://www.ecoangel.jp/uploads/GHS-SDS-JP.pdf
> SDSとは「安全データシート(Safety Data Sheet)」のことでしょうか。
違います。
SDS=Summary, Details, Summary
PREP=Point, Reason, Example, Point
http://shippitsu.xyz/sub/tsuzuri/tsuzuri/cat1/cat13/post-32.html
https://happylifestyle.com/9312
なるほど、理解しました。
補足ありがとうございました。
0
think49 さんが少し触れていますが、質問やコミュニケーションにすれ違いが発生する原因の一つに「正しい用語を使用していない」場合があります。
共通認識にズレがあると、発した言葉が正しく伝わらないので、「正式名称」を略なしで使用することをオススメします。
質問をする場合は、回答者に負担をかけないように注意する必要があります。製品名や技術名等の略しがちなものも、できるだけ正式名称で記述するのが、誤解を減らす必要な手順です。
また、正式名称が分からない（あいまい）な場合、まずその名称を定義するところから始めると良いです。
~といった処理を行う機構（以下、XXXと呼びます）のように記述することで、誤解を与える可能性はかなり低減できます。
あまり、長々とした正式名称を文章の中で使い続けるのは冗長なので、正式名称を略称として使用する場合も、上記のように定義すると良いです。本や契約、顧客に納めるドキュメントの中でもしばしば使われる手法です。
投稿2018/01/27 00:14
退会済みユーザー
総合スコア0
0
以下のリンク先の記事はバグ報告についての内容ですが、質問する時にも役立つ内容なので引用します。
やさしいバグトラッキング (Joel on Software)
良いバグレポートのルールを覚えるのは簡単だ。すべての良いバグレポートに必要なものは正確に3つだ。
- 再現する手順、
- 期待されること、そして
- その代わりに観察されたこと。
投稿2018/01/26 17:42
編集2018/01/26 20:01
総合スコア5846
あなたの回答
tips
プレビュー
