サイトトップ

Director Flash 書籍 業務内容 プロフィール

TechNotes Extra
テクニカルノート番外編

フォーラム・メーリングリスト
質問NGワード集

【質問に必要な基本的情報】
フォーラムやメーリングリストで、お答えしにくいご質問に遭遇することが少なくありません。そうした多くのご質問に共通する特徴は、ご説明が抽象的であったり、基本的な情報が不足しているということです。

1. 使用環境の情報は必須
まず、ご質問には、最低限お使いの環境を知らせましょう。オペレーティングシステムやアプリケーションのバージョン、問題がブラウザやプロジェクタで発生している場合にはその情報(ブラウザ名・バージョン、プレーヤー・プラグインの正確なバージョンなど)も必要です(ブラウザのFlash Playerのバージョンは、本サイトのFlashページ右上に表示されます)。

2. 目的・処理内容・結果を具体的かつ客観的に伝える
つぎに、どのような目的で、どういう操作処理を行い、(意図に反して)どんな結果が発生したのかを、具体的かつ客観的にご説明ください。必要に応じて、操作の手順を箇条書きしたり、具体的なスクリプトを提示しましょう。

3. サンプルデータにも説明が必要
さらに、言葉で説明しにくい場合には、サンプルデータをアップすることも有効です。しかし、ものを見せれば、説明が不要になる訳ではありません。

お医者さんの診察室でも、黙って座っていたのでは診療してもらえません。お医者さんも回答者も占い師ではなく、通常特殊な能力も持合わせませんので、どこが悪いのかは必ず説明していただく必要があります。できれば、サンプルデータは、余分な処理や構造を省いて問題部分だけを取出すことが望ましいです(この作業を行うことにより、ご自分で解決に辿り着くこともあります)。

よく「ファイルを見てもらった方が早いので」という人があります。しかし、「早い」のは説明の手を抜いたその当人だけの話です。訳のわからないデータを見せられ、その中を分析して問題を探す方にとっては、とんだ手間というほかありません。

4. 著作権などに配慮
アプリケーションのトライアル版を使用して質問されることは構いませんが、違法コピーを使われている場合にはフォーラムやリストへの参加資格そのものがありません。多くの参加メンバーが、デザインや開発など権利保護を主張すべき側の仕事をしています。そうした場に対して、他人の権利を侵した人が、協力を求めることは許されません。

書籍のサンプルスクリプトを丸写しで公開したり、サンプルムービーをそのままアップロードすることは、通常禁じられます。しかし、Webで公開されているデータについては、誰でも手に入ります。だからといって、自分のもののように公開することまでは、一般に許諾されません。サイトやURLなど出典を明記すべきです。また、出所を示したとしても、ダウンロードしたサンプルファイルをそのまま自分のサーバーに公開することは控えましょう。

利用・改造が許されているサンプルは、内容を理解したうえで自分のムービーに適用し、その自分の作成したサンプルを質問に必要な範囲で公開されるのは差支えないと考えられます。

以下には、ご質問の典型的なNGワードを掲載しました。これらの言葉を一切使うなとはいいません。しかし、これらの言葉は、客観的に提供される情報量が極めて少ないといえます。NGワードを使わないように努力することで、具体的かつ客観的なご説明が可能になるでしょう。


【一から教えてください】
「一から」というのは、どこからですか?⇒【初心者なので最初から説明してください

たとえば、「掛け算を教えてください」と質問されたとします。九九は小学校2年生で習う、ごく基本的な計算です。けれど、1年生でもわかるように、「一から教えてください」といわれたらどうでしょう。数の概念やその数え方、足し算など、小学校1年生の算数をひととおり説明しなければなりません。つまりそれには、1年生の算数の教科書に近い分量の解説が必要になるということです。

質問者は、基本から覚えたいとの気持ちで、ごく気軽にこのように尋ねたのかもしれません。しかしそれなら、自分が理解していることこそ、「一から」説明すべきです。その質問に対して回答者が、間違っている部分や足りない点を指摘する方が、よほど効率はよいはずです。それをしないのは結果として、自分の質問の説明は手を抜いて、その手間を回答者に押しつけるに等しいです。

【*一度にいくつも質問する】
いくつも質問して悪いことはありません。けれど、いくつもの質問に対するいくつもの回答を、すべて確かめてそれらすべてにきちんと対応することができますか。自信をもってできるのでしたら、その力を質問の中のもっとも簡単そうな問題ひとつに集中すれば、おそらく解決できるはずです。どれも手がつけられないのであれば、それらをまとめて質問することそのものそのものが無謀です。→【一度にすべてをやろうとする】

【*一度にすべてをやろうとする】
目的の動作を一度に達成しようとするのは、問題をあえて難しくするようなものです。課題はステップに分けて、ひとつひとつ解決していきましょう。それが、目的を達成する早道です。

テニスを習い始めたら、試合で勝ちたい、あるいはいいプレーをしたいと考えるのは当然です。ただ、だからといって、いきなり試合をこなして上達しようとするのは無茶です。サーブやレシープ、ボレーといった基本をひとつずつ練習し、場合によっては基礎体力も鍛えて、それから試合に臨むのが結果として上達の早道になります。

【いまひとつわかりません】
では、ひとつ手前のおわかりになっていることをご説明ください。

ことに、回答者のご説明に対して、このひと言で返すのは失礼です。相手の答えが「イマイチ」とも読め、喧嘩を売っているものと受取られても仕方ありません。⇒【よくわかりません

【いろいろ探しましたが見つかりませんでした】
「いろいろ」というのは、具体的に「何をどのように」探したのでしょうか? 本を調べたのですか、ネットを検索したのですか? 具体的にどういう題名の書籍を読んで、ネットならどのようなキーワードで検索をかけたのでしょう。本当に情報が少ないご質問なのか、単に探し方が悪いだけなのか、「いろいろ」ではアドバイスのしようがありません。

さらに、探せば済むことと、理解して考えるべきこととを、区別する必要があります。たとえば、「(1+2)÷3+4×5」という計算の答を知りたいとき、これとまったく同じ式が説明されている参考書を探しても、おそらく見つからないでしょう。答えは探すものではなく、四則演算と計算のルールを理解し、考える必要があるのです。

検索をするとすれば、問題の式そのものでなく、「四則演算」や計算の「規則」「順序」などの説明です。それが理解できれば、数字が違っても、「+」が「−」だったり、「×」が「÷」であっても、答えは自分で求められるようになります。

【いろいろ読んでもわかりませんでした】
では、いろいろご説明しても、無駄でしょう。

冷たいようですが、ひとつのことの説明の仕方に、それほどバリエーションはありません。場所を変えてご質問されても、おそらく同じような説明をされるのがオチです。それでも疑問を解決したいと望むのであれば、わからなかった原因をまず取除くしかありません。大きくふたつの理由が挙げられます。

第1に考えられるのは、その問題を理解するのに必要な知識が欠けている場合です。これには少し回り道に思えても、一旦疑問は脇に置いて、基礎となる事項を学習すべきでしょう。基礎知識が足りなければ、何をするにしても早晩行き詰まります。この機会に補っておくことは、結局後のちの上達につながります。

第2は、結論を急ぐあまり、ひとつひとつの情報をきちんと読んで、理解しようとしていない場合です。飛ばし読み、拾い読みは、結果として時間を無駄に費やします。受験を前に英単語集を買いあさって、当日までに結局AからCまでの単語しか覚えていないのと同じです。

また、理解のプロセスをないがしろにするのは、アクセル/ブレーキ/クラッチの機能を「理解」せず、「操作の順番」だけ覚えてドライブしようとするのに等しいです。危険ですし、大抵事故ります。

「いろいろ」でなく、どれかひとつでもきちんと読んで、それでもおわかりにならない点があったなら、改めて質問されればよいことです。その際は、ソースを明らかにしたうえで、どこまで理解し、どこがおわかりにならないのかを具体的にご説明ください。そうすれば、適切なアドバイスが得られるでしょう。

【うまくいきません】
ですから、ご質問をされたのでしょう。それはわかっています。わからないのは、具体的に何がどうしたのかです。110番に電話する人たちの第一声が「大変です!」だといいます。けれど、「大変」でなければ、普通110番しません。具体的に何がどう大変なのかを聞かないかぎり、警察は出動のしようがありません。

「うまくいかない」というのは、目的とそぐわない結果が発生しているという主観的な感情しか伝えません。つまり、赤ん坊がむずかって泣くのと同じ情報量といえます。このご説明から解決を導ける専門家は、占い師と精神科医だけです。

目的・意図」がどういうもので、どういう「結果・現象」が発生しているのかを、客観的にお伝えください。さらに、どのような「操作・処理」を行ったのかという具体的な情報を加えれば、質問の基本的な体裁(前述「目的・処理内容・結果を具体的かつ客観的に伝える」参照)が整います。

【うまく説明できません】
「うまく」説明できなくて、結構です。ただ、へたでも何でも、説明はしてもらわないことには、話が先に進みません。

言葉の通じない旅先で、親御さんか恋人あるいはお子さんが原因不明の急病になったとしましょう。お医者さんに説明しようにも、言葉がわかりません。そんなとき、「うまく説明できません」といったきり、放っておきますか?辞書を調べ、身振り手振りを交え、絵を描いて見せたり、自分にできるあらゆる手段を使って、状況を詳しく正確に伝えようとするのではありませんか?

それをしないとすれば、そもそもその状況・問題を解決したいという意欲・切迫感が欠けている、と判断されても仕方ないでしょう。

【*回答をきちんと読まない・回答者から聞かれたことに答えない】
たとえば、ご質問にこんな回答があったとしましょう。「確認した環境にインストールされているFlash Playerのバージョンは、いくつですか? また、パブリッシュするバージョンを変えてみるとどうですか?」この回答に対して、つぎのような返信をする人が少なくありません。「Flash Playerのバージョンは、最新です。ほかに、何か原因は考えられませんか?

回答者は、Flash Playerのバージョン絡みで、ご質問の問題について何か心当たりがあるのかもしれません。ですから、バージョンを尋ねるだけでなく、違ったバージョンでパブリッシュを試してみるようアドバイスしている可能性があります。それをあっさりスルーしてしまうのは、NGです。⇒【他に原因・方法は考えられますか

エンドユーザーからFlashムービーの不具合について報告を受けたとき、まずFlash Playerのバージョンを確認するのは基本です。それに対して、かなり多くのユーザーが「最新です」とお答えになります。しかし、経験上大半は、少なくとも最新のPlayerではありませんでした。ですから、「最新」という回答は、酔っぱらいが「酔っていない」とろれつの回らない口で答える程度の信憑性しかありません。

そういうと、自分はFlashのクリエーターで、素人ではない、といわれるかもしれません。けれど、プロならばこういう質問に対して、「最新」という表現はしません。たとえば、Windows版Flash Player 8.0r24ですと答えるでしょう。さらにいえば、そのバージョンをgetVersion()関数やSystem.capabilities.versionプロパティなどのスクリプトで確認したのか、Adobeなどのテストページで確認したのかの情報も添えるはずです。

問題を早く解決したいのでしたら、回答者から見捨てられないうちに、謙虚に訊かれたことには答え、確認した情報を正確に伝えられることをお勧めします。

【勝手に文法をつくらない】
スクリプトの書き方がわからないからと、いい加減な文法を勝手に編出す人がいます。スクリプトの文法というのは、大文字小文字が1字違っても動きません。[ヘルプ]などをきちんと調べもせず山勘で手当り次第に試すのは、道に迷ったとき地図も見ないでやみくもに歩き回るのと同じです。遭難します。

世の中には、ごく稀に勘の優れた人はいます。けれど、訳がわからなくなって今ご質問をされている時点で、あなたがそうした才能をもっている可能性はかぎりなく低いでしょう。調べるべきものは調べ、理解できるかぎりの事実を把握したうえで、何がおわかりにならないのかを明らかにしてご質問されるのが、解決にたどり着くもっとも確かな方法です。

【具体的なスクリプトを教えてください】
その前に、具体的な処理の流れや考え方は理解されましたか? アクセル・ブレーキ・クラッチの機能を「理解」せず、単に操作の順番だけ「丸覚え」してたまたま車が走ったとしても、それは自動車を運転できたことにはなりません。それどころか、危険でさえあります。

【こんな現象(エラー)に詳しい人はいないでしょうか】
結果として起こったことだけを示して、このように尋ねる人を見かけます。その現象(エラー)が起こる詳しい状況も、起こった経緯も、具体的なムービーのつくりやスクリプトなど何も説明されていません。どのような答えを期待されているのでしょう。

頭が痛くて病院を訪ねたときも、それだけでは風邪か偏頭痛か、はたまた脳疾患か、考えられる病名は数かぎりありません。ですから、お医者さんは他の自覚症状や変調に至った経緯を問うたうえで、原因の予測を立てて身体を調べるのです。自覚症状や経緯は本人でなければわかりません。フォーラムのご質問に本当に答えてほしければ、これらの情報は自ら進んで説明しましょう。

もしかすると、たまたま同じ現象(エラー)に遭遇して、しかも原因をつきとめ、それが偶然にも自分と同じで、さらに幸運なことに解決策まで見いだした人に出逢えることを期待しているのかもしれません。しかし、それは「白馬の王子様」を夢見る少女と同じ幻想です。自ら解決しようと努力していく先に、手助けしてくれる人は現れるものです。

【さっぱりわかりません・さっぱりです】
これだけでは、状況が「さっぱりわかりません」⇒【まったくわかりません

【参考サイト・サンプルの掲載されているサイトを教えてください】
もちろん、目的や現在の状況、問題点、理解できない部分をきちんと絞込んだうえで、このご質問をされるのは結構です。しかし、ただイメージや希望だけ述べて、このように聞かれても困ります。やりたいことがそっくりそのまま掲載されているサイトは、よほど運がよいか、よほどありふれたことを試そうとしているのでないかぎり、見つかりません。⇒【どうしたらいいですか

【至急お願いします】
「至急」というのは、回答者が今取組んでいる仕事を一旦脇に置いて対応せよということでしょうか? それとも、他の方々の質問より、自分の質問への回答を優先すべしということですか? 急ぐべきは、回答者ではありません。問題を抱えるご自身が、まず調査や確認、テストを十分に行うことです。可能なかぎりの手を尽くして、その結果を詳細に報告して質問されれば、通常は速やかな回答が得られるはずです。

ロクな情報もなしに「至急」とオーダーするのは、クライアントが発注先に、あるいは上司が部下に対する態度です。しかも、そういうクライアントや上司にかぎって、ロクな成果を挙げられないものです。

【*自分にしかわからない用語を使う】
たとえば、「りんごを買おうとしたら、出てこないので、買い物かごに入れられません。なぜでしょう?」と質問されたら、どう答えますか? 何を質問しているのか、わかりませんね。さすがに、こんな無茶な質問をする人はいないと思うでしょう。でも、つぎの質問も、基本的には同じことです。

「ウィンドウを開こうとしたら、開きません。何が悪いのですか?」確かに、「ウィンドウ」はコンピュータ用語として存在します。けれど、それが「ブラウザのウィンドウ」なのか、「Windowコンポーネント」を使っているのか、はたまた自作の「ウィンドウのパーツ(シンボル)」をつくって表示/非表示を切替えようとしているのか、まったく区別できません。

操作や動作の質問をするのなら、見た目のイメージで説明するのでなく、アプリケーションの機能や要素の用語を使って質問すべきです。自分の制作物のイメージは、本人には自分の部屋のように鮮明なのでしょうが、他人にはアマゾンの奥地に等しいのです。

略語にも、注意しましょう。JavaScriptのことを「ジャバスク」とか「JAVA」などと勝手に略す人がいます。前者は一般に通用している用語とは思えませんし、後者はJavaScriptとはまったく別物です。用語に無神経な人は、得てしてドキュメントや他人の説明もよく読みません。そうでなくても、そういう印象を与えるだけ損です。「リプト」のたった3文字を省いたために、失うものの方が大きいといえます。

【〜してしまいます。どうしたらよいでしょう】
たとえば「道に迷ってしまいました。どうしたらよいでしょう?」と尋ねられても、答えようがありません。最低限どこに行きたいのかという目的地を伝え、現状はどうなっているのか具体的な説明が必要です。単に困っているという悩みを相談したいのでしたら、占い師か精神科医を訪ねるべきです。

【〜しようと思いましたができません】
特殊な能力がないかぎり、「思った」だけでは何もできません。言葉尻の揚げ足取りと感じられるかもしれませんが、回答者に与える情報は「思った」だけの場合と異なるところがありません。多くの場合「できない」理由は、「やり方」が悪いからです。それなのに、実行した具体的な「やり方」をロクに説明もせず、どうすべきか回答せよというのは、傲慢な上司が部下に接するような態度です。

もちろん、ヘルプのチュートリアルどおりの操作を間違いなく実行しても、どのようなやり方をしても、その結果の実現は不可能だという絶対の自信がある場合でしたら、細かい操作など説明する必要はありません。ただし、その絶対の自信の根拠くらいは示した方がよいでしょう。

【初心者なので〜】
日本語の初心者である場合を除き、この言葉は何の説明にも、言い訳にもなりません。

「オムレツの作り方」を質問されたとしましょう。その相手が「初心者」だといったとしても、目玉焼きくらいつくったことのある人と、卵の割り方もわからない人に対する説明とでは、当然内容が変わってきます。オムレツは、洋食の料理人を目指す学生さんの卒業試験に出ることさえあるそうです。料理学校の学生さんだって、料理人としては初心者です。「初心者」という表現だけでは、何についてどの程度知っているのか知らないのか、明確な手がかりを与えないのです。

・初心者なのですみません
知識や技術がないことについては、礼儀をわきまえ、質問する場を選びさえすれば、変に恐縮する必要はありません。しかし、説明を尽くそうとしないのは単なる「手抜き」ですし、目の前で起こっているトラブルとかフォーラムのルールをよく確かめないのは「不注意」というべきです。何でも「初心者」を言い訳に使う態度は、社会人として改めた方がよいでしょう。

・初心者なのでよく説明できません
お医者さんに行けば、誰でもご自分の病状をきちんとご説明されるはずです。医者にかかる人たちのほとんどは、医学について初心者どころかずぶの素人です。だからといって、説明できないで済まされるのは、幼児かカタコトの外国人くらいでしょう。自覚症状を正確に伝えられる人は、患者本人をおいてほかにいないのです。同じように、あなたが今どんな問題に直面し、何に悩んでいるのかは、あなた以外に説明できる人はいません。

たとえ技術用語がわからなくても構いません。お医者さんにアッペ(盲腸)とかイレウス(腸閉塞)などという専門用語で自分の所見を披露するのは、医療関係者だけでしょう。症状から病気を診断するのは専門家であるお医者さんに任せてよいのです。しかし、病状を推測できる程度の客観的な事実は、まず患者の側が正しく伝えなければなりません。

・初心者なので最初から説明してください
「最初」からというのは、PCの電源の起ち上げからでしょうか。それとも、コンセントの差し方からでしょうか。たとえば、「海外は初めてなので、NYにはどうやって行くのか教えてください」と訊かれたとき、どう答えればよいか考えてみてください。

単に、航空会社と航空便だけ伝えれば済むとはかぎりません。パスポートの取り方、チケットの手配からわからないかもしれません。あるいは、成田空港への行き方も知らないという場合さえありえます。後のケースになってくると、くどくど説明するより、旅行代理店を紹介した方が早いでしょう。

つまりひとことで「初心者」といってもいろいろな人がいて、それぞれの具体的な知識に応じて、回答も異ならざるをえません。「初心者」という言葉を使っていけないとはいいませんが、結局どこまで理解していて、どこがわからないのかを伝えなければ話が進まないのです。

【スクリプトはわからないので】
スクリプトを書こうとして、質問されているのではないのですか? でしたら、わからないでは済まされません。最低限の知識は勉強しましょう。

回答者に希望のスクリプトを作成してもらって、そのまま使いたいということでしたら、それは「質問」とはいいません。「作成依頼」もしくは「発注」です。それなら、ご予算も伝えるべきでしょう。もちろん、それを0円とされるのも自由です。ただ、ご自分が生業とされている仕事を、見ず知らずの他人にタダでやってくれといわれたとき、どう感じるかは想像してみる価値があります。

そうではなく、サンプルさえあればそれを応用して何とかなる、と考える人も多いようです。けれど、「理解」しないで「応用」することは困難といえます。アクセル/ブレーキ/クラッチの機能を「理解」せず、「操作の順番」だけ覚えてドライブしようとするのに等しいです。危険ですし、大抵事故ります。

スクリプトは、ロジックで組立てられています。そのロジカルな処理の流れを理解することが大切です。そうした考え方を理解することこそ、応用力を高めることにつながるのです。

【スクリプトを見てください】
実際のスクリプトを見せるのは結構です。しかし、問題部分の切分けさえしていないスクリプトを、何の説明もなく羅列するのはやめましょう。正しく動作しないスクリプトというのは、チューニングの合っていない楽器のようなものです。そのまま何もいわず、全曲フルに聴かせるのは、嫌がらせでしかありません。

ローマの一番よい三流のホテル」。これは、あるイタリアのホテルのホームページ上に、実際に記載されていた文です。もちろん、誤訳です。正しい日本語に直してくださいと頼まれたら、何と答えますか?「いったい何がいいたいの?」と聞返すのではないでしょうか。間違った日本語だけ見せられても、本当は何を伝えたいのかという意図がわからなければ直しようはないのです(なお、原文は"superior 3-star hotels in Rome"のようで、「三流」ではなく「三つ星」とすべきでした)。

アプリケーションのバグがないかぎり、スクリプトは記述されたとおりに動きます。ほとんどの場合、問題はスクリプト自体の動作にあるのではなく、目的や意図に合わない記述をしている点にあります。目的や意図は、期待どおり動作しないスクリプトの記述を見せられても、推測することはできません。

さらにいえば、説明をロクにしないというのは、訳のわからないスクリプトを解析したうえで回答せよとオーダーしているのに等しいです。傲慢な態度と受取られても仕方なく、回答者の意欲を損なうのに十分といえるでしょう。

【*第三者から見てわからない】
119番に「隣の家が火事です!!」と叫んでも、当然のことながら消防車は出動できません。「隣の家」はあなたにとって明らかなのでしょうが、あなたがどこにお住まいなのかわからないからです。

「読込んだ画像がちゃんとした大きさで表示されません」などというご質問も同じです。まず、「画像」には、JPEGファイルやSWFがあります。場合によっては、ビデオかもしれません。また、外部ファイルを「読込む」処理には、loadMovie()loadMovieNum()アクション、MovieClip.loadMovie()メソッドなどがあり、それぞれに応じてロードするターゲットの指定が問題になります。

それに、「ちゃんとした」大きさというのはどういう状態で、どうなると「ちゃんと」していないのでしょう。もとのファイルの大きさが、変わってしまうといいたいのかもしれません。しかし、何かサイズ変更の処理をしたのであれば、もとのままの大きさであれば逆に問題です。つまりどうしたいのかという意図がわからなければ、表示されている画像を見ても、「ちゃんと」しているのかいないのか判断できないのです。

ご質問は、複数の第三者が文面を見て、そのポイントにおいてほぼ同じイメージを想い浮かべることができるように客観的にご説明ください。そして、問題や希望とする動作のご説明は、第三者がその内容を手元で再現できる程度に、具体的にお書きいただく必要があります。

【だめでした・できませんでした】
せっかく得られた回答に対して、このひと言で返す人がいます。こういう返答には、おそらく「やり方が悪いから」もしくは「回答を理解していないから」と答えるしかないでしょう。

このような無機質な回答を望んでいるのでなければ、何をどう試してどういう結果になったのか、具体的に説明する必要があります。→【うまくいきません

【どうしたらいいですか】
「どうしたらいいですか?」と聞くこと自体は、まったく差し支えありません。問題は、尋ねるだけで、ご自分では何も調べたり、試したりしない場合です。「まったくわからない」から、手のつけようがないといわれるかもしれません。しかし、泳ぎ方がわからないからと、浜辺に座込んだまま水に入ろうとしない人に対して、水泳を教えることはできません。

「調べたけどわからなかった」という人は、ご自分のやりたいことをそのままキーワードに入力して検索していることが通例です。たとえば、「タイプライターのようなテキスト表示」で検索しても、おそらくほとんどヒットするサイトはないでしょう。

「タイプライターのよう」というのは、あくまで表現の仕方で、基本はアニメーションであり、その表示のタイミング調整です。テキストを使ったアニメーションは、Flashでは広く試行されています。そのなかから利用できそうなテクニックを採入れるという姿勢で探せば、参考になるサイトはたくさんあります。たとえば、FLASH KITのムービーには、さまざまなText Effectsのサンプルが掲載されています。

ご自分のやりたいことそっくりそのままの参考サイトやサンプルは、よほど運がよいか、よほどありふれたことを試そうとしているのでないかぎり、見つかりません。したがって、そのやりたいことを実現するには、どのようなテクニックや知識が必要なのかを分析してみる作業がなくてはならないのです。これは、ご自分で実際にあれこれ考え、試し、調べてみないとわからないことです。

【どうしてもできません】
「どうしても」というのは、「どんな手段を用いても、絶対に」という意味です(三省堂『大辞林 第2版』)。ですから、本当に「どうしても」できないというのでしたら、諦めるしかない理屈になります。そうでなく、ご自分の「試した範囲では」できなかったといわれるのであれば、具体的に「何を試してどういう結果だったのか」をお伝えください。

【どこを直したらよいでしょう】
ステートメント1-2行まで問題を絞込んだうえで、正しいシンタックスや式の記述方法を尋ねる場合にこのように質問されるのなら、まったく問題はありません。

しかし、動かないまま何の修正も試行錯誤も加えていないムービーや、流用しようとする別の目的のムービー、なかんずく他のサイトや書籍から丸写ししたサンプルスクリプトを示してこう聞くのは、「質問」といいません(なお、著作権について「4. 著作権などに配慮」参照)。それは、「修正依頼」か「発注」です。もしそうでしたら、併せてご予算もお知らせになるべきでしょう。そうすれば、やりたいことだけをお好きなように伝えられて構いません。

けれど、疑問点や問題点について他の方々の助力を受けながらも、ご自分の力で作成しようというおつもりであるのなら、そのムービーの内容をどう理解し、どこをどう直す必要があると認識しているのかも同時にご説明されなければなりません。できれば実際に試行錯誤をされて、その結果も示されるとよいでしょう。

たとえその理解が誤っていても、構わないのです。違っていれば、回答者はその点から説明すべきことがわかります。認識がおおむね正しければ、より具体的な回答が得られるでしょうし、別のもっとスマートなアイデアが提供されるかもしれません。回答者は、質問者が具体的にどの程度の知識・技術をもっているか、そのご説明によって把握することができるのです。

【どんな原因が考えられますか】
問題の起こりうるあらゆる可能性を考えようというのですか。それより、ご自分の行ったことをすべて書出して回答者にチェックしてもらう方が、ほとんどの場合はるかに労力は少ないです。説明をする手間を省こうとする無精は、回答者の手間を増やすだけでなく、解決までの道のりをいたずらに遠くするだけです。それに、そういう予感を漂わせれば、回答者は自然と引いてしまうでしょう。

【バグですか?】
その問題の発生する条件を正しく絞込み、具体的な現象を詳しく説明したうえでこのように問われたのでしたら、ほどなく他の環境でのテスト結果や適切な回答が得られることでしょう。

しかし、状況をロクに説明せず、ご自分の困っている結果だけを挙げ連ねて、いきなりこのように尋ねる人がいます。おそらく「バグです」という回答を得て、安心されたいのだろうと想像します。でしたら、多分「バグです」。ただし、アプリケーションまたはあなたの書いたスクリプト、もしくはその両方を原因とした。

問題を建設的に解決し、ご自分のスキルを向上させたいと願うなら、「バグ」かどうかではなく、「原因」は何なのかこそ問われるべきことです。原因を確かめるには問題を切分けて、具体的に何が意図せざる結果の発端になっているのかを明らかにする必要があります。→【問題の切分けをしない

そのうえで、その具体的な現象の発生する条件を絞込んでいくことになります(→【問題の絞込みをしない】)。できれば、新規のムービーで現象を再現できるほど、問題を簡素化することが理想です(→【問題を再現しようとしない】)。

「バグです」という回答が得られさえすればすべての責任から解き放たれるのでしたら、そこに力を注ぐ意味もないではありません(スキルの向上は望めませんが)。しかし、そのような幸せな状況にある人はごくまれで、ほとんどの人は「バグであれ何であれ」その対応を求められるのが常です。だとすれば、初めから建設的に問題に取組まれた方が、その状況から抜出す時期はずっと早まります。

精神的な癒しを求めたいだけでしたら、質問などで他人を巻込まず、酒でも飲んで早寝して鋭気を養う方がまだ前向きでしょう。

【*フィードバックをしない】
質問をして回答が得られたら、ひとことお礼をいうのは日常生活と同じ礼儀です。しかし、フォーラムやメーリングリストの場合それだけでなく、その回答がどう役に立ったのか、立たなかったのかというフィードバックを情報として書添えることが大切です。

フォーラムやメーリングリストは、ただ自分が質問して一方的に助けてもらうだけのサポートセンターではありません。その質問・回答の情報を、メンバーの共有財産として互いに利用し合おうという助け合いの場です。そのやり取りを見ている他のメンバーや、後から検索して情報を利用する人たちのためにも、顛末を報告する責任が質問者にはあるのです。

山小屋を利用したら、必ず掃除をして「来たときよりも美しく」というのが登山者のマナーです。その思いやりは、次回利用する自分にも巡ってきます。フィードバックのし忘れに気づいたり、指摘されたときは、「次回から気をつければよい」というのではなく、時間が経っても可能なかぎり補足しましょう。それを怠れば、自分勝手な人と思われて、次回には必要な助けが得られないかもしれません。

【他に原因・方法は考えられますか】
その前に、アドバイスされた対処・方法は、試されたのでしょうか?

「あなたはガンの可能性があるので、すぐに入院すべきです」と医者にいわれたら、取りあえずいわれたとおりすぐに入院しませんか? 入院して詳しい検査もしないのに、「ガンでない可能性」についてあれこれ尋ねるのは時間のムダです。精密検査を受けたうえで、詳しい病状やその後の治療について説明を受けるのが、早期治療に向けた行動です。検査で幸いにしてガンの可能性が否定されたら、その結果を踏まえてつぎにどういう原因があるかを相談することになります。

同様に、アドバイスされた対処・方法をまず試してみるというのが、問題を解決するために最優先で採るべき行動です。それで解決ができなかったら、改めて具体的に試した内容とその結果を報告しましょう。「その情報をもとに」、さらにつぎの具体的なアドバイスが得られるはずです。

最初のアドバイスから一応目的の結果が得られてなお、何か「新たな問題や要望」がある場合には、その内容を追加の情報としてご質問すべきです。

もちろん純粋な興味から、他の対処方法があるのなら勉強のために知りたいということも構いません。最初のアドバイスが「理解されたことを前提」として、もう少し高度なテクニックや汎用性のある方法が紹介されるでしょう。

しかし、いずれにせよアドバイスを試しもせず、何の追加情報も示されずに、他の原因や方法を尋ねるのはいたずらに回答者を困惑させるだけです。

【本・マニュアルを読んでもさっぱりわかりません】
それは、文字によるコミュニケーションが難しいということでしょうか? でしたら、フォーラムやメーリングリストも、基本的に文字とせいぜい若干の図を使って、しかもかぎられたスペースで情報をやり取りします。したがって、仮に回答が得られたとしても、それで状況が改善する見込みはきわめて薄いといわざるをえません。

書籍は一応はプロが書きますので、フォーラムやメーリングリストで交わされる文章と比べて、一般的には順を追って丁寧に説明されています。マニュアルは日本語としておかしかったり、わかりにくい部分はあるものの、根気よく読めば理解できる内容です。何よりどちらも情報量だけは、スペースのかぎられた回答と比べて格段に多いはずです。それらをきちんと読んだにもかかわらずまったく理解できなかったということでしたら、残念ながらそれ以上詳しく丁寧に説明してくれる人はいないでしょう。

そうでなく、解説の中に理解できない箇所があるとか、基礎知識が不足あるいはあいまいなために説明の意味を咀嚼できないということでしたら、その部分を具体的に明らかにしてご質問されるべきでしょう。⇒【まったくわかりません

【まったくわかりません】
「日本語全然ワカリマセン」という外国人から道を尋ねられたら、どうお応えになりますか? 多くの人は、そもそも関わり合いになるのを避けるでしょう。「全然」とか「まったく」というのは、単に言葉が通じないというだけでなく、意思を伝えたり理解する努力をしようという姿勢が感じられません。回答者に引かれたくなかったら、たとえわずかであっても、何がわかるのかという情報を添えましょう。

【マニュアル(参考書)のとおりにやりました】
本当ですか? もしそのとおりなら、ご質問の必要はありません。マニュアル(参考書)の記述ミスか、アプリケーションのバグです。ソフトのメーカー(あるいは出版社)に、報告なり苦情なりをお伝えください。

けれど、ご自分の読違えや見落としがないか、操作や処理に誤りがないか不安があるといわれるのなら、マニュアル(参考書)のどこのどういう記述にしたがって、どのような操作・処理を試したのか、具体的にご説明いただかなければなりません。

【*マルチポストする】
「マルチポスト」とは、「同一の内容の文章を複数のニューズグループ、掲示板に別の記事として投稿すること」(Wikipedia)です。回答者の時間や手間を顧みない行為として、マナー違反とされます。

マルチポストの質問は大抵が、SPAMと同じコピー&ペーストですので、楽に済むでしょう。しかし、回答は生身の人間が、時間と手間をかけて、ほとんどの場合無償で行っています。ところが、マルチポストする人たちはほとんど、他のサイトにも同じ質問をしていることは書きません。結果、複数のサイトで別々の回答者が、同じような説明のために、同じような労力を費やすことになります。

「ちゃんとお礼はいう」と開き直る人もいるそうです(もっとも、お礼も伝えない人は少なくありません)。そういう人に問います。逆の立場だったら、型通りの礼さえ告げられれば、見ず知らずの人のために、かけなくても済む自分の貴重な時間と手間を(しかも無償で)かけますか。質問さえコピー&ペーストで済まそうと横着している人が、そのような労を厭わないとは信じられません。

「急いでいるから」はご自分の勝手な事情です。仕事で急ぎの動員をかければ、普通追加費用が求められます。自らは痛みを感じることなく、他人の労力をただで浪費する理由になるはずがありません。

「ひとつのサイトに質問をしたけど回答がなかったから」というのは、まだ酌量の余地があります。けれど、回答が得られないのは大抵、質問の情報や説明が足りなくて答えにくいからです。質問をそのまま他のサイトにコピー&ペーストするのは賢明とはいえないでしょう。また、そうしている間にも、誰かが調べたり、サンプルをつくったりして、回答しようとしているかもしれません。ひとこと、どこそこのサイトにも同じ質問をすると知らせるべきです。

Wikipediaに「マルチポストを容認してもいい」という「別の視点」が示されていると勝ち誇る人もいます。しかし、よく読めばわかるとおり、これは情報を閲覧・検索する側からの視点です。回答者の善意の労力を無駄にしてよい理由にはなりません。結局、マルチポストは自分の質問に対する善意(かつ多くの場合無償)の回答者への感謝と思いやりに欠けることが最大の問題です。

では、マルチポスト先を明記すればよいでしょうか。それは最低限の条件ではあります。マルチポストを快く思わない回答者はスルーできるからです。でも、そうして回答が減ったらマルチポストした意味がなくなるでしょう。もし本当に多くの回答がほしいのでしたら、各ポスト先の進行状況を他のサイトにも適宜伝えるべきです。ご自分がどこまで理解し、目的をどこまで遂げられているか知らせてもらえれば、二度手間は避けつつ回答することができます。

そこまでするのは面倒だと思うなら、マルチポストはしないことです。回答者はもっと面倒なのですから。

参考: ハマる生活「[Tips]マルチポストが嫌われる理由〜なぜマルチポストは問題か?」、ニコニコ大百科「マルチポスト

【*問題を切分けない】
診察で「今日はどうしました?」と訊かれて、「実はうちの嫁が...」と愚痴をこぼし始めるお年寄りの笑い話があります。お嫁さんの話は、診察には関係がありません。では、「足を挫いてしまって」だったら? そこが内科の診察室でしたら、やはり場違いということになります。

ムービーを実際に作成するには、さまざまな作業があります。しかし、質問されるときには、その問題に関連する部分を切分けて説明しましょう。

よくある例が、「外部テキストを読込んで〜したところ」から延々と説明を始められる、診察室のお年寄りに近いパターンです。「外部テキストから読込まずに、直接テキストを設定すると問題は発生しませんか?」と訊かれて、もし答えが「発生する」でしたら、外部テキストの読み込みは問題と直接「関係」のない話です。

あるいは、胃の検査をする際には、空腹にしてくるよう指示されるはずです。胃に余分なものが入っていたら、胃の状態を正しく知ることができないからです。

胃が満腹のままどこが悪いのか調べるのは、名医でも困難で、無謀といえます。また食事も抜かず、胃に余分なものが入った状態で、どこが悪いのか教えてくれとオーダーするのは、傲慢な態度と思われても仕方ないでしょう。

【*問題を再現しようとしない】
コンテンツに問題が発生したとユーザーから報告を受けた場合、すぐさま「このような問題の原因はなんでしょう?」と質問される人が少なくありません。しかし、警察が「こんな事件が起こりました」という発見者からの通報を受けて、現場検証も目撃者の事情聴取もせずいきなり「こんな事件が起こったらしいんですけど、何か心当たりはありまんか?」などと聴込みに回ったのでは、犯人は到底つかまりそうにありません。

犯人は男なのか女なのか、年齢はどれくらいか、背格好はどうなのか、何か特徴はないのか、犯行時にどんな服装をしていたのかなど、聴込みの前に確認しておかなければならないことがあるはずです。コンテンツの場合であれば、問題が発生した環境のオペレーティングシステム(OS)、ブラウザで再生している場合にはそのアプリケーションとバージョンおよびPlayerのバージョン、さらに関係がありそうなら併せてハードウェァの情報などです。

事件であれば、犯人の顔を目撃した人がいれば一番です。モンタージュや似顔絵をつくって、手配できます。トラブルシューティングの場合は、手元で同じ問題を再現することがもっとも望ましいです。そのためには、モンタージュを作成するのと同じように、問題の報告をされた方に使用環境や具体的な現象を事細かに質問する必要があるはずです。つまり、真っ先に質問をすべき相手は、フォーラムやメーリングリストでなく、問題の報告者なのです。

【*問題を絞込まない】
道に迷ったとき、やみくもに歩き回るのは危険です。まずすべきことは、立ち止まり地図を開いて、今自分がどこにいるのか見当をつけることです。事件が発生したら、犯行時刻を推定します。そして、その時刻をもとに、容疑者を絞込みます。同じように、問題が起こったとき、それがどこからどこまでの処理の間で発生しているのかを絞込む作業が大切です。その絞込みをせずむやみに検索したり試したりするのは、犯行時刻を特定せずにキャッチセールスのような聴込みをするのに等しいです。

どうしても見当がつかない場合には、ムービー中の要素(Flashなら、フレーム・シンボル・インスタンス。あるいは、スクリプトのステートメントや式の項)を片っ端から削除していきます。その都度動作を確認して、問題の現象が消滅したら、その直前に削除した要素の中に容疑者がいます。そうして、これ以上ひとつの要素も削除できないという状態になったら、改めてその内容を詳しく確認しましょう。おそらく、この時点でおおよその目星はついてくるはずです。

【*問題を単純化(シンプルに)しない】
お手玉を初めて覚えようとするとき、まずふたつか3つで始めるでしょう。いきなり10個でやれといわれたら、ほとんどの人は無理だと答えるはずです。ところが、複雑な処理が意図どおりの結果にならないとき、処理を複雑にしたまま頭を抱える人が少なくありません。

10個のお手玉を目標にするにしても、いきなり10個を投げたのでは、到底できるはずがありません。まずふたつか3つで練習して、それができたら徐々に数を増やしていくというのが賢明です。処理内容も、いくつかのステップに分けたり、あるいは本質を変えない範囲で単純化したり、1回に取組む規模をできるかぎり小さくする工夫が必要です。⇒【問題を絞込まない

【やり方(スクリプトの書き方)を教えてください】
やりたいことは、明確に説明できたとしましょう。するとそれに続けて、いきなりこのように質問される方があります。目的地がはっきりすれば、そこへの行き方(道順)は簡単に説明できると思いますか?

電話かメールで、あなたの仕事場あるいは住まいまでの行き方を尋ねられたら、どうお答えになりますか? 目的地は、はっきりしています。すると、最寄り駅から説明しますか? 相手がどこから来るのか、わからないのですよ。その最寄り駅自体、知らない可能性があります。では、たとえば東京なら、東京駅のようなターミナル駅から話せばよいでしょうか? 飛行機で、羽田空港に降り立つかもしれませんよ。そもそも相手が日本在住でなければ、成田空港から先がまったくわからないこともありえます。

目的地が明確であっても、そこへの道順は、自分がどこから行くのか、あるいはどこまで行けるのかを伝えなければ、適切な回答を得ることはできないのです。つまり、いきなりやり方を尋ねる前に、自分ではどこまでできるのか、何はおわかりで、何を調べたのか、現在の理解の到達点を説明することが不可欠です。

やりたいことが伝われば、実際のムービーをつくってみせることはできるはずと思う人もいるかもしれません。しかし、それは「質問」とはいいません。適正な料金を払って、「発注」するときのスタンスです。

【やりたいことはこうです】
やりたいことを明らかにするのは大切です。けれど、その要望だけを延々と羅列する人がいます。果たして、そのすべてが一度にできるのでしょうか。→【一度にすべてをやろうとする

もちろん、最終的にやりたい目標を伝えることは悪くありません。でもそれなら、ご自身が今どこまでできて、何を理解し、最終目標に達するまでに何が足りないのかを明らかにすべきです。そこまで具体的にわからないというのでしたら欲張らず、そのために初めに必要となることから、ひとつひとつ確かめながら学ぶのが結果として早道です。

一度にできもしないことを尋ねるのは、そもそもご自身でやるつもりがないと思われても仕方ありません。他人にやってもらおうというのは、「質問」ではなく「発注」です。→【どこを直したらよいでしょう

【よくわかりません】
これは、お医者さんの診察室で「どうしました?」と尋ねられて、「具合が悪いのです」と答えるようなものです。確かに、そのとおりでしょう。でも、お医者さんには、基本的に具合の悪い人しかきません。「具合が悪い」というのは、何も情報を伝えたことにならないのです。

必要なのは、どこまでならわかったのか、そしてどこからわからないのかという、具体的なご説明です。「よくわかりません」という答えが適切と考えられる例は、警察で取調中の容疑者と、国会で証人喚問を受けている政治家くらいでしょう。つまり、何も答えたくない場合に、使うことばです。

したがって、ご自分の抱える解決したい問題について、相談に乗ってほしいときには不適切な表現といえます。きちんと説明しないというのは、本気で解決したいという姿勢を疑われても仕方がありません。ましてや、回答者からのご質問やご説明に対してこのひと言で返すのは、不適切をとおり越して失礼です。

【わかりやすく説明してください】
普通、わざとわかりにくく説明する人はいません。回答者の国語能力に問題がある場合を除けば、わかりにくい説明の原因は、あなたが何をわからないのか把握できないことです。つまりあなた自身が、ご自分の抱えている問題を、回答者にわかりやすく説明していないことを意味します。どこまで理解し、どこでつまずいているのかを正確かつ具体的に質問されていれば、「わかりやすく」などと頼まなくても、自然と適切でわかりやすい回答が返ってくるはずです。⇒【初心者なので〜】・初心者なので最初から説明してください

_____

作成者: 野中文雄
作成日: 2003年11月21日


Copyright © 2001-2012 Fumio Nonaka.  All rights reserved.