はじめに
プログラミングをやっている人であれば、スタック・オーバーフロー（Stack Overflow）を知らない人はいないと思います。
エラーメッセージをコピペしてググるとトップによく出てくる、このページのことです↓
Stack Overflow - Where Developers Learn, Share, & Build Careers
また、ご存知の方も多いかもしれませんが、去年の12月からは日本語版サイトも登場していて、現在は日本語で質問と回答が投稿できるようになっています。
とはいえ、ネットで見つけて回答を読むことはあっても、自分から質問したり回答したりする人はまだまだ少数派のような気がしています。
そこで、今回のエントリでは日本語版サイトをメインターゲットにして、スタック・オーバーフローの使い方をまとめてみようと思います。
注：このエントリでは関数呼び出しの無限ループ等で発生するスタックオーバーフローの説明は出てきません。
もくじ
ちょっと長いので、先に目次を載せておきます。
それでは以下が本編です。
スタック・オーバーフローの概要
スタック・オーバーフローは簡単にいうと技術者向けのQ＆Aサイトです。
プログラミングをしていて、困ったことがあれば質問を投稿することができます。
もちろん、Q＆Aサイトなので質問の回答を知っていれば、回答を投稿することもできます。
疑問が解決したら、質問者は一番役に立った回答を承認することができます。
（Yahoo!知恵袋の「ベストアンサー」のようなものです）
承認された回答は以下のように緑のチェックマークが付きます。
スタック・オーバーフローのユニークなところ
これで終わると本当にただのQ＆Aサイトなんですが、スタック・オーバーフローには他にもユニークな仕掛けがいろいろあります。
質問や回答に投票ができる
スタック・オーバーフローの質問や回答をよく見ると「▲▼」のアイコンと数字が表示されています。
これは質問や回答に対する投票数です。
▲がクリックされると票が増え（賛成票）、▼がクリックされると票が減ります（反対票）。
みんなから「これはよい！」「役に立った！」と思われると票数が多くなり、逆に「これはひどい」と思われると票数がマイナスになります。
ちなみに誰がどういう投票をしたのかは、投票した本人以外にはわかりません。
他人の質問や回答を編集できる
スタック・オーバーフローはWikiページのような側面も持っており、他人の質問や回答を自由に編集することができます。
コンテンツの質を高めるための編集であればサイトとして大歓迎、という方針です。
以下は僕が実際に他の人の質問を編集している様子です。
ただし、編集内容は即座に反映されません。
編集内容が反映されるためには、信用度（後述）の高いユーザーによってレビューされる必要があります。
ユーザーごとに信用度が付与され、ランキングが表示される
スタック・オーバーフローにはユーザーごとに「信用度」というポイントが付与されます。
たとえば、自分の回答が承認されると信用度が15ポイント増えます。
また、回答が賛成投票されると10ポイント増えます。
一方、回答や質問が反対投票されると2ポイント減ります。
つまり、信用度が高ければ高いほど、スタック・オーバーフローに貢献しているユーザーということになります。
さらに、スタック・オーバーフローのユーザー一覧はデフォルトで信用度順にソートされています。
つまりこれはスタック・オーバーフローのユーザーランキングです。
ちなみに僕は2015年10月4日の時点で総合ランキング6位です（！）
なお、信用度がどういうときに増え、どういうときに減るのかは下記のページにまとめられています。
信用度が増えるにつれ、権限が解放される
スタック・オーバーフローにおいて、信用度はユーザーランキングのためだけにあるのではありません。
信用度はスタック・オーバーフロー内での権限とも密接に関連しています。
アカウントを作成した時点では、信用度が1です。
質問や回答の投稿は信用度が1でも実行可能ですが、賛成票を投票するには信用度が15ポイント必要です。
なので、アカウント作成直後だと賛成票を投票することはできません。
また、反対票の投票には125ポイントの信用度が必要です。
これ以外にも様々な権限があり、信用度が増えるにつれ、権限が解放される仕組みになっています。
つまり、信用度が高いユーザーほど自由度を高めることで、サイトが荒れたり、コンテンツの質が低下したりすることを防止しています。
信用度と付与される権限の具体的な対応関係は下記のページにまとめられています。
以上がスタック・オーバーフローの基本説明です。
ここからはもっと具体的なノウハウを説明していきます。
上手に質問するコツ
スタック・オーバーフローで質問するときは、「わかりません！」「できません！」「おしえてください！」だけでは回答者に嫌がられます。
公式ヘルプセンターに「良い質問をするには？」というページがあるので、初めて質問する人は質問する前に一度目を通しておいた方が良いでしょう。
公式サイトの内容と重複する部分もありますが、僕が回答者として「こんな質問は困る」「こうしてくれたら嬉しい」と感じるポイントをいくつか挙げていきます。
文章だけではダメ！コードやログ、スタックトレース、スクリーンショットを載せましょう
質問を見ていると、文章だけで「うまく動きません」「エラーが出ます」「どうしたらいいでしょうか」と助けを求めてくる方がよくいます。
たとえばこんな感じです。
RailsでFacebookログインページを作っています。
ローカルではちゃんと動作したのですが、Herokuにデプロイするとエラーになります。
ネットを見ても解決できませんでした。
設定を見ても特におかしなところはありません。
どこが悪いのでしょうか？教えてください。
よろしくお願いします。
こういう質問は何かしら困っていることは理解できても、何がどう悪いのかは残念ながらサッパリわかりません。
回答する側の立場からすると、次のような疑問がわいてきます。
- 「エラーになります」とはどういう状況なのか？
- システムエラーが発生するのか？
- それとも「ログインできませんでした」のようなアラートが表示されるのか？
- 「ネットを見ても解決できませんでした」とあるが、どんなことを試したのか？
- 参考にしたページは何か？
- 実際に試した内容とその結果はどうだったのか？
- 「設定を見ても特におかしなところはありません」とあるが、なぜおかしくないと言い切れるのか？
- あなたは「正しい」と思っていても、実は間違っている可能性は十分あるはず
人間の言葉はあいまいですし、意図せずに「ウソ」をついてる可能性もあります。
なので、言葉ではなく正確な情報を提供してくれる、
- コード
- 設定ファイルの内容
- ログ
- エラーのスタックトレース
- スクリーンショット
をそのまま載せましょう。
（ただし、勤務先に迷惑が掛からない範囲で）
先ほどの「悪い例」であれば、まず「エラーになります」の具体的な内容を知りたいので、
- エラーが発生したときのスクリーンショットを貼る
- ログインボタンを押してからエラー画面が表示されるまでのログをコピーして貼り付ける
というふうにしてもらうのが望ましいです。
HogeではなくUserと書きましょう（コードの目的や質問の背景を明確にしましょう）
コードは書いてくれるのですが、目的が不明で何のためにそうしたいのかわからない質問もよく見かけます。
たとえばこんな感じです。
HogeというクラスがPiyoにhas_manyで関連しています。
class Hoge < ActiveRecord::Base
has_many :piyos
end
class Piyo < ActiveRecord::Base
belongs_to :hoge
end
Hogeを更新したらPiyoに新しいレコードを追加してHogeのデータをすべてPiyoにコピーしたいのですが、どうすればいいのでしょうか。
データをコピーしたいというのであれば、その方法を紹介できなくもないです。
しかし、そもそもHogeとPiyoがどういうクラスで、何のためにデータをコピーしたいのかがわかりません。
なので、答える方も「こういう回答でいいのかな？」と不安になってしまいます。
質問に書くコードは極力実際のコードをそのまま載せてください。
もちろん「仕事で書いてるコードだからそのままは無理」というケースもあると思いますが、その場合でもHogeやPiyoではなく、そのコードが使われるシチュエーションが伝わるようなコード例に書き換えてください。
また、データをコピーしたい、という件も「なぜデータをコピーしたいのか」という理由や目的もあわせて書いてもらうのがベターです。
目的が明確になると、「データをコピーしようとしていますが、そういう用途であればこのgemを使うと便利ですよ」というふうに「求められている回答よりも適切な解決策」を提示できる可能性があります。
先ほどの質問例であれば、こんなふうに書いてもらった方がより具体的で良い質問だと思います。
Userがhas_manyでUserHistoryに関連しています。
class User < ActiveRecord::Base
has_many :user_histories
end
class UserHitory < ActiveRecord::Base
belongs_to :user
end
現在作成中のアプリケーションでは、監査のためにユーザープロフィールの更新履歴をすべてデータベースに残しておく、という要件があります。
なので、更新前のUserのデータをすべてUserHistoryにコピーしたいのですが、どうすればいいでしょうか？
こういう質問であれば、目的が明確なので回答する側も回答しやすくなります。
ちなみに、僕が本当にこの質問に答えるのであれば、「いやいや、データを自分でコピーするよりもpaper_trailのようなgemを使った方が便利ですよ」と答えます。
質問に載せるコードは「多すぎる」ぐらいでかまいません
質問にはとりあえずコードを載せてくれているのですが、ほんの一部しか載せてくれない質問もよくあります。
たとえばこんな感じです。
Blogクラスにenumで以下のようなステータスを定義しました。
enum :status, %i(draft published hidden)
このステータスを画面でセレクトボックスに表示したいのですが、Viewで呼び出すと NoMethodError が発生します。
なぜエラーが出るのかまったくわかりません。
どうしたらstatusをViewで呼び出せるのでしょうか？
こういうのも非常に「もやっ」とするタイプの質問です。。。
プログラムはひとつのファイルで完結するのではなく、複数のファイル（クラス）が協調して動作します。
たとえばRailsであれば通常、ModelとViewとControllerが協調します。
また、ファイル内ですらその場でローカル変数が宣言されて、メソッドに引き渡されたりします。
つまり、協調関係の最初から最後までをきれいに追えないと、どこに問題があるのかハッキリわかりません。
先ほどの例であれば、Viewでsatusどのように呼びだしているのかも質問に載せてもらう必要があります。
（あともちろん、エラーのスタックトレースも！）
質問の内容によっては、Model、View、Controllerの3つを載せてもらった方がよい場合もあるでしょう。
また、コードを載せるときも「1行だけ抜粋」ではなく、前後関係がわかるように「大きなかたまり」として載せてもらう方がベターです。
というわけで、質問する人は遠慮せずにたくさんコードを載せてください！
ちなみに、「たくさんコードを載せてください」と書くと、公式ヘルプのガイドライン（下記）に相反するところがあります。
すべての質問が、コードを含めることで利益を得るわけではありません。
問題が、作成したコードに関係する場合、一部を含めてください。
ただし、プログラム全体をただコピーすることは避けてください!
そうすると、勤め先のコードを投稿している場合には問題になる可能性が高いだけでなく、読者が問題を再現しようとするときに無視しなければならない無関係な詳細がたくさん含まれることになりがちです。
以下にガイドラインを挙げます。
- 他の人が問題を再現するのに十分なだけのコードを含める。最小の完全で検証可能な例の作成方法が役立ちます。
- 問題の生の例を作成できてそこにリンク できる場合は (たとえば http://sqlfiddle.com/ または http://jsbin.com/ など)、 そうしてください。ただし、質問自体にもコードを含めてください。外部のサイトには誰もがアクセスできるわけではありません。また、リンクも時間の経過とともに切れることがあります。
良い質問をするには？ - ヘルプ センター - スタック・オーバーフロー
コードが多すぎるとノイズになるのは確かにそうですし、必要最小限のコードだけを載せるのが理想的なのもわかります。
ただ、質問を見てると「コードが少なすぎる」と感じる機会の方が多いので、僕は「多すぎるぐらいで構わない（たぶんそれぐらいで結果的にちょうどいい）」と述べることにしました。
問題が解決したら、回答を承認しましょう
誰かの回答であなたの疑問が解決したら、その回答を「承認」してあげましょう。
承認をすると、次のようなメリットがあります。
- ググってあなたの質問にたどりついた技術者が「なるほど、この回答で解決したんだな」ということが一目でわかります。
- あなた（質問者）の信用度が2ポイントアップします。
- 回答者の信用度が15ポイントアップします。
- 信用度が上がるだけでなく、回答者の気持ちがスッキリします。（何も反応がないと回答者はモヤモヤします）
よくコメント欄に「これで解決しました。ありがとうございました！」とだけ書き込んでどこかへ行ってしまうケースがあるのですが、「ありがとう」を書き込む前にまず「承認」をしてあげてください！
また、承認されないまま放置されると、その質問はゾンビのように時間を空けてトップページに出現します。
スタック・オーバーフローのトップページで更新者名が「Community ◆」になっている質問は、システムが自動的に未承認の質問をピックアップしてトップページに表示したものです。
本当に質問が解決していない場合は新しい回答が付いて解決する可能性がありますが、解決しているのであればトップページに表示する意味はほとんどありません。
「ゾンビ質問」にならないように、質問者の方は「解決したら承認！」ルールを守るようにしてください。
自分で回答＆承認するのもOKです！
「回答は付かなかったけど自分で解決できた」もしくは「他人の回答よりも自分の見つけた解決策が一番しっくりきた」という場合は、自分で回答して自分で承認することができます。
自分の質問に自分で回答することも、スタック・オーバーフローが公式に推奨している使い方です。
詳しくはこちらのヘルプページをご覧ください。
質問に誰も回答してくれない場合
質問に誰も回答してくれない、もしくはほとんど読まれてなさそうだ、という場合は次のようなアクションをとってみてください。
- 適切なタグが付いているか確認する
- 回答者の人は後述する「お気に入りのタグ」を使って、回答できそうな質問を絞り込んでいることがあります。
適切なタグが付いていれば、その分野に明るい技術者があなたの質問を見つけて回答してくれるかもしれません。 - タイトルを見直す
- 公式ヘルプページに良いタイトル、悪いタイトルのサンプルが載っています。
これを参考にして、自分の質問のタイトルを修正してください。
良い質問をするには？ - ヘルプ センター - スタック・オーバーフロー - 質問内容を改善する
- 質問内容に情報が不足しているのかもしれません。
より詳しく状況を説明してみてください。
また質問を更新することで、質問一覧のトップにあなたの質問が表示されます。
詳しくは公式ヘルプページの説明を参照してください。
質問に誰も回答してくれない場合は？ - ヘルプ センター - スタック・オーバーフロー - 質問に「お礼」を付ける
- スタック・オーバーフローには「お礼」という仕組みがあります。
これは自分の信用度を回答者に分け与える制度です。
「お礼」を付けると他の質問よりも目立つので、回答をもらいやすくなるかもしれません。
詳しくは下記の公式ヘルプページを参照してください。
お礼とは？どうしたら開始できますか？ - ヘルプ センター - スタック・オーバーフロー - 英語版サイトで質問してみる
- 日本語版サイトでは回答が付かなくても、英語版サイトにいけば誰か回答してくれるかもしれません。
英語版サイトは日本語版サイトよりもかなり活発に回答が投稿されているからです。
英語が苦手な人でも、どうしても解決したい問題なのであればチャレンジしてみる価値はあると思います。
「良い回答者」になるコツ
では続けて、「回答する側」のポイントを説明していきます。
不明な点があればコメント欄で質問する
「なんとなく答えられそうな質問だけど、ちょっとよくわからない点がある」という場合はコメント欄で質問することができます。
不明な点があればとりあえず質問（または追記の依頼を）してみましょう！
以下は実際に僕が質問にコメントしたときのスクリーンショットです。
コメント欄で回答しない
コメント欄は不明な点に関する質問や、追記の依頼に徹した方が良いです。
よく「～の設定が抜けていませんか？」とか「～ではありませんか？」という、疑問形の回答を載せてしまう人がいます。
以下はコメント欄で解決してしまうやりとりの例です。
質問：
ローカルではテストが毎回パスするんですが、Wercker CIではときどき失敗するテストがあります。
（コード例）
どうしたらよいでしょうか？
============
コメント：
CIの環境変数 TZ にローカル環境と同じタイムゾーンを設定したら直りませんか？
============
コメント：
設定したら直りました！本当にありがとうございます！！
これで解決してしまうと、コメント欄だけでQ＆Aが完結してしまい、回答の承認がされないまま終わることが多いので好ましくありません。
こうなってしまわないよう、「疑問形の回答」はコメントではなく、回答として載せるようにしてください。
承認済みの質問に回答してもOK
承認済みの質問であっても、新たな回答が禁止されることはありません。
「承認済みの回答よりももっと適切な答えを知っている」という場合は、新たな回答を投稿しましょう。
承認済みの回答は変更することができるので、もしかするとあなたの回答が「承認済み」に変更される可能性もあります！
トップページの表示を見て、質問の状態を把握する
スタック・オーバーフローのトップページに表示される質問一覧には、以下のようなルールがあります。
「回答数」が緑の四角で囲まれていると、「1件以上の回答が付いている」ことを表します。
さらに、その回答数の文字が黄色になっていると、「承認済み（解決済み）」になっていることを表します。
回答が全く付いていない質問は「緑の四角」が表示されません。
このルールを理解しておくと、質問がどういう状態なのかをぱっと把握することができます。
お気に入りのタグと無視するタグを活用して、回答できそうな質問を絞り込む
スタック・オーバーフローにはお気に入りタグと無視するタグを設定できます。
これを使うとトップページの表示が次のように変わります。
- お気に入りのタグに該当する質問は黄色く表示される
- 無視するタグに該当する質問は薄い色で表示される
たとえばこんな感じです。
こうしておくと、自分が回答できそうな質問が一目でわかるようになります。
自分が得意な分野と不得意な分野が見えてきたら、お気に入りのタグと無視するタグを設定するのがオススメです。
オーディエンス（Q＆Aを見る人）の心構え
スタック・オーバーフローは質問する人と回答する人だけのサイトではありません。
おそらく質問する人と回答する人以上に、Q＆Aを読みに来る人の方が多いのではないでしょうか。
日本語版はともかく、英語版Stack Overflowであれば、圧倒的に「読む」機会の方が多いはずです。
そこで「読み手」のポイントもいくつか紹介しておきます。
承認済みの回答よりも、投票数に注目する
これは重要なポイントです。
Yahoo!知恵袋であれば「ベストアンサー」を読んでおしまい、かもしれませんが、スタック・オーバーフローではそのルールは当てはまりません。
スタック・オーバーフローで一番重要な指標は投票数になります。
日本語版サイトは投票数があまり多くないのでわかりづらいですが、英語版サイトだとさかんに投票が行われています。
たとえばこんな質問があります。
ruby on rails - value_to_boolean deprecated; what's a good replacement? - Stack Overflow
この質問に対する「承認済みの回答」はこちらです。
しかし、投票数はこちらの回答の方がずっと多いです。
これはつまり、後者の回答の方が「お役立ち度が高い」ということを意味しています。
実際、僕もこちらの回答を参考にして自分のコードに適用しました。
というわけで、スタック・オーバーフローでは「承認済み」以上に、投票数に着目するようにしてください。
もちろん、回答がたくさん付いている場合は「承認済み」でもなく、「投票数トップ」でもない、「その他」の回答が自分にとって役立つ場合があります。
「読んで終わり」ではなく、「コンテンツの品質向上」に貢献しよう
最初の方にも書きましたが、スタック・オーバーフローは投票ができたり、他人の質問や回答を自由に編集できるのがユニークな点です。
せっかくなので、そういった機能を活用してコンテンツの品質向上に貢献するのがオーディエンスのあるべき姿かなと思います。
- 「役に立った」と思った質問や回答に賛成投票する。
- 「適切ではない」と感じた質問や回答には反対投票する。（できればその理由もコメントに書く）
- 記述内容に不備があれば質問や回答を編集する。
こういったアクションを随時とるようにしましょう。
特に、日本語版では投票機能が英語版に比べて活用されていない感があるので、「読むだけ」の人も積極的に投票してもらいたいなーと思っています。
（ただし、投票にはいくらかの信用度が必要になるのは前に述べたとおりです）
その他、知っておくと役立つ知識
最後に、もしかしたら役立つかもしれないその他の豆知識を紹介します。
コードブロックはスペース4つぶんインデントさせる
スタック・オーバーフローではMarkdown形式で質問や回答を記述します。
MarkdownはQiitaをはじめ、いろいろなサービスやツールで使われているので、技術者であればお馴染みの記法だと思います。
ただ、サンプルコードの書き方にはちょっと注意が必要です。
Qiitaとかだと、以下のようにコードの最初と最後にバッククオート（ ` ）を3つ並べてその間にコードを載せる、という形式になっています。
以下はRubyで掛け算をする場合のコード例です。 ``` a = 1 puts a * 10 ```
しかし、スタック・オーバーフローではコードブロックとして認識させるために、スペース4つぶんインデントさせます。
以下はRubyで掛け算をする場合のコード例です。
a = 1
puts a * 10
Markdownの方言が異なるので、ここには十分注意してください。
ちなみに、手作業でスペース4つぶんを追加するのは大変だと思うので、コードブロックを選択して「{ }」アイコンを選択するのが簡単だと思います。
コードブロックの使用言語を明示的に指定する
スタック・オーバーフローのコードブロックは自動的に使用している言語が類推されます。
類推がうまくいけば、何もしなくても適切なシンタックスハイライトが適用されます。
しかし、類推がうまくいかない場合もあります。
その場合は "<!-- language: lang-js -->" や "<!-- language: lang-ruby -->" のようなHTMLコメントをコードブロックの前に挿入します。
以下はRubyで掛け算をする場合のコード例です。
<!-- language: lang-ruby -->
a = 1
puts a * 10詳しくは以下のヘルプページを参照してください。
スタック・オーバーフロー自体に関する質問は「スタック・オーバーフローMeta」を使う
もしスタック・オーバーフローの使い方がわからなくなり、ヘルプページを見ても解決しなかった場合は「スタック・オーバーフローMeta」というサイトで質問を投稿してください。
使い方の質問以外にも、運営ルールに関する質問、意見、誤訳の改善といった内容はMetaに投稿するのが適切です。
下図のように、Metaの見た目や使い方はスタック・オーバーフローと同じです。
英語版と日本語版はアカウントは同じでも信用度は別々
英語版Stack Overflowと日本語版スタック・オーバーフローはどちらも同じアカウントでログインできます。
ただし、信用度はそれぞれ別々に集計されます。
たとえば僕のアカウントだとこんなふうになっています。（上が英語版、下が日本語版）
まとめ
以上がスタック・オーバーフローの主な機能です。
スタック・オーバーフローをただのQ＆Aサイトだと思ってた人にとっては、今まで知らなかったサイトの工夫や仕組みがたくさんあったのではないでしょうか。
他にもいろいろな機能がありますが、とりあえずこれぐらいを理解していれば快適にスタック・オーバーフローを使えるようになると思います。
一人でプログラミングをやっていて、「どうしても解決できない。でも周りに質問できる人がいない」という場面に遭遇したら、スタック・オーバーフローが強い味方になってくれるはずです。
また、特定の技術にある程度精通している人は積極的に回答して信用度を溜めていきましょう。
スタック・オーバーフローは世界的に有名なQ＆Aサイトです。
スタック・オーバーフローで信用度を溜めておけば、将来外資系のIT企業に転職したいと思った場合に良いアピールポイントになるかもしれません。
GitHubのスター数みたいなもんですね。
英語版Stack Overflowだとどうしても「読む専門」になってしまう人が多いと思いますが、日本語版スタック・オーバーフローは「日本語でOK」です。
どんどん質問と回答を投稿して、英語版に負けないぐらい豊富で良質なコンテンツを増やしていきましょう！
あわせて読みたい
その昔に書いた英語版Stack Overflowの説明記事です。
基本的な機能は当時と変わっていませんが、この頃はまだ英語版しかありませんでした。
英語版サイトに投稿してみたい、でも英文を書くのはちょっと苦手・・・という方はこのエントリが参考になるかもしれません。
創業者のジョエル・スポルスキ氏は書籍「Joel on Software」の著者としても有名です。
「Joel on Software」はとてもユニークかつ、ためになる話がたくさん載っているので、一度読んでみてください。
- 作者:Joel Spolsky
- 発売日: 2005/12/01
- メディア: 単行本
- 作者:Joel Spolsky
- 発売日: 2009/04/09
- メディア: 単行本（ソフトカバー）
スタック・オーバーフローのイベントが開催されるそうです
2015年10月9日（金）に東京浜松町のアジュール竹芝で「Dev Days」というスタック・オーバーフローのイベントが開催されるようです。
ジョエル・スポルスキ氏も来日し、講演します。
スタック・オーバーフローに興味のある方はぜひ参加してみてください。
（僕も行きたいけど、東京開催なのでちょっと厳しい >< ）
