[plamo:20000] How to ask a question ?

[kojima]

昔にも似たような文書を書いたことがあるんだけど，最近，改めて書く機会が
あったので，コメント等を頂けることを期待して ML にドラフトを流してしま
います :-)

一応書籍の一部となることを前提にしたドラフトなので，ここ以外にはあまり
流さないでくださいませ(笑)

# もっとも，実際に出るかどうかは未定ですが，ポシャった場合は PlamoWeb 
# なネタにする予定，，(^^;

------------------------------------------------------------------

質問の仕方

本書では，ソフトウェアに付属のさまざまな一次資料の読み方を紹介すると共
に，ログファイルやシステムの情報ファイル，各種設定ファイルの調べ方など
を紹介してきました．これらの情報やインターネット上の検索エンジンに代表
されるさまざまな二次資料を活用すれば，たいていの問題には自力で対処する
ことができると思います．自分の力で必要な情報を見つけることができれば問
題を解決した時の喜びもひとしおですし，それが初心者から中級者へと進んで
いくための原動力となることでしょう．

しかしながら，初心者にとってはインターネットのような情報の大海の中から
自分に必要な情報を見つけ出すこと自体が大変なのも事実です．そのような場
合に役に立つのはメーリングリスト(ML)や各種の掲示板から得られる先達の経
験です．しかしながら，ML や掲示板等で質問する場合でも，答えを得やすい
質問とそうではない質問があります．そこで本節では，ML や掲示板等で質問
する際に，どうすれば答えを得やすい質問になるかのポイントを紹介します．

・問題の説明は的確に

隣りにいる人に問題を説明するにはディスプレイの画面を見せるだけで済みま
すが，ML や掲示板で文字情報だけを使って問題を説明するには，かなり詳細
に，時には冗長過ぎると思うくらい丁寧に問題について説明する必要がありま
す．問題を説明する際には以下のような項目に注意して，必要な情報を漏れな
く記述するようにしましょう．

- エラーメッセージ

問題が発生したことを示すエラーメッセージが出力されている場合は，実際に
画面やログファイルに出力されたメッセージを「そのまま」書くようにします．
X ウィンドウを使っている場合は，出力されたエラーメッセージを cut &
paste して直接メールに貼りつけてしまうのがいいでしょう．

初心者の場合，エラーメッセージのうちトラブルの原因とは直接関係しないと
思った部分を省略したり，適当に意訳したメッセージを示すことがありますが，
それらはむしろ問題解決の妨げになるので，表示されたエラーメッセージはで
きるだけそのまま転載してください．

- ログファイル

対話的なコマンドの場合はエラーメッセージは直接画面に出力されますが，各
種ネットワークサービスを提供するデーモンプログラムのエラーメッセージは
画面には出力されず，各種ログファイルにのみ出力される場合があります．そ
の場合 XXX 章を参考に，dmesg の出力や /var/log/messages，
/var/log/syslog などを調べ，関係する部分を転載しましょう．問題によって
は /etc/syslog.conf でログファイルに出力される警告レベルを調整しなけれ
ばならないかも知れません．

また，ネットワークサービスに関わる問題の場合，そのサービスを利用しよう
としたクライアント側のエラーメッセージとサービスを提供するサーバ側のエ
ラーメッセージを併記すれば問題の原因とその解決方法が分かりやすくなる場
合があります．

- 設定ファイル

Linux の各種コマンドは設定ファイルの指定によって動作が大きく変わります．
システムの動作に必須の設定ファイルについては XXX 章で解説しましたが，
それ以外にもアプリケーションごとに使用する設定ファイルはいろいろなもの
があります．rpm 等のバイナリパッケージからインストールする場合，あらか
じめ必要な設定が施された設定ファイルがインストールされますが，ソフトウェ
アを手動でインストールした場合は，設定ファイルも自分で適切に設定しない
とコマンドが正しく動作しないことがあります．

ソフトウェアのインストールは成功したものの，動作が正常でない場合，たい
てい設定ファイルに原因があります．その意味で，質問をする前には設定ファ
イルについて見直し，自分で追加した部分や修正した部分を確認しておきましょ
う．

質問の際に設定ファイルを添付すれば問題が簡単に解決することも多々ありま
すが，設定ファイルにはセキュリティやプライバシーに関する情報が含まれる
こともあるため，設定ファイルを添付する際には注意が必要です．

- 環境について説明

PC を使っていると，ついつい自分の環境が万人に共通するものと思い込みが
ちですが，いわゆる PC 互換機の場合，CPU の種類や速度，積んでいるメモリ
やHDDの量等のハードウェア面だけでも千差万別です．Linux の場合，それに
加えて使っているディストリビューションの種類やバージョン，さらにはイン
ストールしているパッケージなども異なるため，同一の環境など存在しないと
言ってしまっても過言ではないでしょう．

各種のトラブルには，そのような環境に起因しているものも少なくないため，
質問の際には使っている環境に関する情報も忘れずに書いておきましょう．最
低限，使っているディストリビューションの種類とバージョン，問題となって
いるプログラムのバージョンは必要です．また，カーネルやlibc(glibc2)，C 
コンパイラ(gcc)など，OS にとって主要なパーツを自分で更新している場合は，
それらについての情報も書いておく必要があります．x86 系以外の CPU を使っ
ている場合，議論するための ML 等も別途用意されていることがあるので，問
い合わせ先を確認する必要もあるでしょう．

- 問題の切り分け

Linux の属する UNIX 系 OS の場合，「何でもできる一つの大きなプログラム」
ではなく「単一機能の小さなプログラム」を組み合わせてさまざまな機能を実
現しています．そのため，ある機能が使えないというトラブルが起きた場合も，
原因となっているのは組み合わさっているコマンドのどの部分なのかを切り分
ける必要があります．

問題の切り分けが必要になる典型的な例には，telnet を用いたリモート接続
や NFS マウントなどのネットワーク機能に関する問題があります．

ネットワーク機能の場合，ネットワークカードやケーブル等のハードウェア的
なレベル(ハードウェアレベル)，IP アドレス，ホスト名，ルーティング等の
ネットワーク設定のレベル(プロトコルレベル)，その上で動作する特定プログ
ラムのレベル(アプリケーションレベル)の 3 つのレベルが考えられ，それぞ
れが正しく設定されていないと正常な動作が望めません．

逆に言うと，アプリケーションレベルで問題があった場合，プロトコルレベル
で正常に動作するかを確認し(動作する場合はアプリケーションレベルの問題)，
プロトコルレベルで問題があった場合はネットワークに関する設定やハードウェ
アレベルでの動作に遡って確認する必要があるわけです．

以下に，2 つのホストに対して telnet コマンドを適用した場合の問題の切り
分け例を紹介します．

% telnet 172.16.2.97
Trying 172.16.2.97...
telnet: Unable to connect to remote host: No route to host

この例では 172.16.2.97 のホストと通信ができていません．すなわち，アプ
リケーションレベル以前にプロトコルレベル，ハードウェアレベルでの動作を
確認する必要があります．ネットワーク上に複数のマシンが接続されている場
合，それぞれのマシン間で ping コマンドを実行して問題となっているマシン
を特定することができます．また，問題のマシンが異なるネットワーク上に存
在する場合， traceroute コマンドを使ってどこまでパケットが到達するかを
調べる作業も必要になるでしょう．

% telnet 172.16.2.98
Trying 172.16.2.98...
telnet: Unable to connect to remote host: Connection refused

この例では，対象マシンまでネットワーク的には接続できていますが，
172.16.2.98 のマシンが telnet の接続を拒否した(refused)ことを示してい
ます．この場合，172.16.2.98 のマシンで telnet 接続を受け付ける設定が行
われているかを確認する必要があります．

telnet 接続を受け付ける設定をどう行うかはディストリビューションによっ
て異なりますが，RH8.0 の場合はネットワークの設定ツールでファイアウォー
ルに関する設定を緩めるとともに，xinetd で telnet デーモンを起動する必
要があります．

Plamo-3.1 の場合は /etc/hosts.allow に telnet を受け付けるような設定を
行うと共に，/etc/inetd.conf を修正して in.telnetd が inetd から起動さ
れるように設定する必要があります．

問題の切り分けがきちんとできれば，たいていの場合，自力で問題を解決する
ことができるでしょう．また， ML 等に尋ねる場合でも，問題を切り分けた過
程を記述しておけば，より適切な回答が得られることでしょう．

・質問者の心構え

前節では ML 等で質問する際に盛り込むべき情報の技術的な内容について説明
しました．質問の際，回答に必要な情報を盛り込むことはもちろんですが，質
問に答えることを仕事にしているサポート窓口とは異なり，MLや掲示板のよう
なコミュニティベースのサポートの場合，質問に答えてくれる人はボランティ
アとして自分の時間と知識を使って答えてくれるのですから，質問をする際に
は彼らに対する感謝の気持ちを忘れないようにしましょう．

商用のサポート窓口に質問する場合は少々ぞんざいな言葉使いでも問題ないか
も知れませんが，MLや掲示板の場合，質問する際の言葉使いによって答えを得
られるかどうかが決まることもあります．もちろん，必要以上に卑下した表現
や丁寧すぎる言葉使いをする必要はありませんが，質問のメッセージを読んだ
人が答えたくなるような文章を書くことができれば，それだけ回答を得やすく
なることでしょう．そのような観点から，本節では質問をする際に質問者が心
がけるべきポイントを簡単に紹介します．

- 分りやすく書く

前節とも重複しますが，書かれた文章でしか情報を伝えられない ML や掲示板
では分りやすく書くことがきわめて重要です．そのためには，あまり一般的で
ない略語を使ったり，2ちゃんねる等でしか通じないような表現は用いるべき
ではないでしょう．

また，OutLook 等 Windows上のメーラーを使っている場合は英数字に全角文字
を使ってもプロポーショナルフォントが利用されるためあまり気になりません
が，そのメールを Mew 等の Linux 上のメーラーから見る場合，全角の英数字
は間延びして見難くなりますので，英文の表記には半角英数字を使うようにし
ましょう．

- 長すぎず，短かすぎず

前節ではエラーメッセージやログファイルはできるだけ詳細に書くべきと述べ
ましたが，あまりにメール本文が長くなりすぎると，それだけで読み飛ばされ
てしまう恐れがありますし，ML によっては投稿可能なメールのサイズに制限
を設けていることもあります．そのため，詳細さと簡潔さのバランスを考える
ようにしましょう．エラーメッセージやログファイルが長くなる場合は添付ファ
イルにしたり，メールの最初の部分に尋ねたい質問の要約を書き，詳細なメッ
セージ等はその後に付けるという方法もあります．いずれの場合も，答えてく
れる人が読みやすいように質問文を書く際に配慮することが重要です．

- 過去ログの検索

ML や掲示板等で質問に答えてくれる人は教え好きの人が多いですが，あまり
に同じ質問が繰り返し尋ねられると答えるのがイヤになることもあります．ML 
によっては過去のログを検索できるようにしているところもありますので，質
問を投稿する前には，最近，似たような話題が出ていなかったか確認しておく
べきでしょう．また，質問する際に Google や ML の過去ログ等をどのような
範囲まで，どのようなキーワードで調べたかを書いておけば，質問に答えよう
とする人が同じような検索をする手間を省くことができ，自分では気づかなかっ
た情報を得られる可能性が高くなるでしょう．

- 回答者に対する感謝と敬意

最初にも書きましたが，ML や掲示板の質問に答えてくれる人は，無償で自分
の時間と知識，回線料を使って答えてくれているので，回答してくれた人に対
する感謝と敬意の気持ちは忘れないようにしましょう．その回答によって問題
が解決したことを報告することも感謝の気持ちの示し方です．また，自分の抱
えていた問題と得た回答を整理して，まとめとして ML や掲示板に投稿してお
けば，後から同じような問題を抱えた人への助けにもなります．

自分で十分努力した上で，分りやすさを心がけた質問をしても，ML や掲示板
によっては質問に対して中傷的な文章が投稿されることもありますが，それら
はインターネットというメディアの特徴と思って，あまり気にすることはない
でしょう．そのような投稿に対して感情的に反応するのは逆効果で，むしろそ
れら批判的な文章の中に多少なりとも心あたりのある部分があれば，それらを
踏まえて，より丁寧に，より分りやすい質問をし直すような心の余裕を持ちま
しょう．

以上，本章では，ML や掲示板で質問する場合に注意すべき技術的な側面と心
理的な側面を紹介しました．初心者の人がこれら全てを心がけて質問文を作成
することはなかなか困難でしょうが，そのような場合でも，全てを人に頼るの
ではなく，自分で努力した上で分からないことだけを人に尋ねることを心がけ
るべきでしょう．そうすれば回答も得られやすくなりますし，自分で調べたこ
と，調べられずに教えてもらったことが経験として身に付き，初心者から歩を
進めるための力になることでしょう．

Linux のようなオープンソースソフトウェア(OSS)の場合，質問者と回答者の
間に明確な境界はなく，ある問題については質問者であっても，別の問題につ
いては回答者になることがよくあります．同様に，開発者と利用者の境界も明
確ではなく，利用者だった人がいつの間にか開発側になっている例が多々あり
ます．OSS の最大の魅力は，ソースコードが公開されているために開発者と利
用者が同じ土俵で議論し，助け合い，競い合えることです．事実，Linux はそ
うやってわずか10数年で商用の UNIX と同等以上の性能を誇れるようになりま
した．本書を手掛りに，読者が質問する側から答える側へ，さらには開発する
側へと歩を進めてくれることが筆者の願いです．