ククログ

RubyKaigi 2013にシルバースポンサーとして参加したまとめ #rubykaigi

シルバースポンサーとして応援したRubyKaigi 2013が終了しました。今後、どこかのスポンサーの参考になるかもしれないので、クリアコードがスポンサーとして参加したRubyKaigi 2013をまとめます。

スポンサーの種類

クリアコードはRubyを応援しています。その一環として日本Ruby会議2009から毎回スポンサーとしてRuby会議を応援してきました。

スポンサーには額に応じていくつか種類があるのですが、クリアコードは毎回一番低い額のスポンサー枠です。今回だとシルバースポンサーです。より額の多いスポンサー枠に比べれば微々たるものですが、身の丈にあった応援をしています。

少し話はずれて参加者としての視点になりますが、RubyKaigi 2013でのスペシャルスポンサーの各社のスポンサーシップは、直接的に助かるためスポンサーのありがたさがとてもよくわかりました。例えば、Microsoftさんのドリンク提供や、Herokuさんの弁当提供や、DeNAさんのWiFi提供などです*1。参加者としてとても助かりました。ありがとうございます。

ノベルティ配布

会場にノベルティ置き場があるということだったので、次のものを配布しました。

rroongaステッカー: 5枚
mroongaステッカー: 5枚
groongaステッカー: 20枚 + 約80枚
groongaサポートサービスのチラシ: 20枚 + 10枚
コミットへのコメントサービスのチラシ: 20枚 + 10枚
インターンシップ応募者募集のチラシ: 20枚

以前、つくばで日本Ruby会議があったときもチラシを配布したのですが、そのときは多く持っていってしまって配布しきれませんでした。その経験をふまえて、今回は分相応の量を持っていきました。しかし、後述のとおり、予想以上に持っていく方が多かったため2日目に追加しました。「+ XX枚」となっているものが2日目に追加した分です。

これらの配布が終了するペースは次のとおりです。

rroongaステッカー: 初日の午前中で配布終了。
mroongaステッカー: 初日の午前中で配布終了。
groongaステッカー: 初日の午前中で20枚は配布終了。2日目に追加した約80枚は2日目が終わる頃には配布終了。
groongaサポートサービスのチラシ: 初日の夕方には20枚の配布は終了。2日目に追加した10枚は2日目が終わる頃には配布終了。
コミットへのコメントサービスのチラシ: 初日が終わる頃には20枚の配布は終了。2日目に追加した10枚は3日目の夕方には配布終了。
インターンシップ応募者募集のチラシ: どの日も5枚ずつくらい減っていて、最終的に7枚残った。

全体として、クリアコードの想像以上に興味のある人が多いということがわかりました。自分たちの製品やサービスなどにどのくらいの人が興味を持つかを観測するために、RubyKaigiでステッカーや関連資料を配布してみるのはよいかもしれません。観測するだけであれば、来場者数の1/10の数もあれば十分でしょう。今回は574名（スピーカーやスタッフを含む）の参加ということなので50部もあれば十分でしょう。

配布状況については以上です。

RubyKaigi 2013が終了して数日しか経っていませんが、現時点での配布後の状況にも少し触れます。インターンシップへの応募がありました*2。これは驚くべき成果です。今後、RubyKaigi効果での成果が増えたら報告します。

ただ、これはチラシを配布しただけの効果か、発表もしたからなのかはわかりません。なお、発表資料は次のとおりです。

Rubyリファレンスマニュアル刷新計画2013 初夏
- SlideShare
- Rabbit Slide Show
- Ustream（後半30分）
Be a library developer!

「Be a library developer!」はRubyKaigi 2013前に紹介したときに内容を説明してあります。参考にしてください。

まとめ

シルバースポンサーとしてRubyKaigi 2013を応援した会社視点でRubyKaigi 2013での活動をまとめました。日本Ruby会議の頃はブースやスポンサーの発表枠などもありましたが、RubyKaigiではWebサイト掲載用のロゴと会社説明の送付だけになったのでスポンサーとしてやることはほとんどなくなりました。必要ならノベルティを配布する程度です。もし、Rubyを応援したくて多少金銭的な余裕があるのであれば、それほど手間がかからない*3のでRubyKaigiのスポンサーになってみるのはいかがでしょうか。

おまけ：RubyHiroba 2013でリーダブルなコードを考える会をした

スポンサーとは関係ありませんが、RubyKaigi 2013関連としてRubyHiroba 2013にも少し触れます。

RubyHiroba 2013で「リーダブルなコードはどんなコードかを実際のコードを題材にして考える会」をしました。そもそも誰も参加しなくて開催すらできないのではないかと心配していましたが、5人で開催できました。

題材はRabbitというプレゼンツールのコードにしました。参加してくれたみなさんが積極的に考えを話してくれたので、いろんな視点でリーダブルなコードを考える機会になりました。この会をふりかってみると、進行役として話や注目している点をうまく整理する人がいると、「みんなで」考えることをよりうまくできそうでした。また機会があれば、そのあたりを試してみます。参加してくれたみなさん、ありがとうございました！

*1 RICHOさんの提供したサイネージはあまり使わなかったので触れていません。すみません。でも、楽しそうに絵を書いたりしている人たちを見たので、有効活用した人たちはたくさんいそうです。

*2 応募があっただけで、まだ開始したりしているわけではありません。

*3 効果を最大化したいとなると、そこそこ手間がかかるかもしれません。

この記事の続き

2013-06-04

クリアコードの1日

クリアコードがこの「ククログ」というブログを始めたのが2008年5月なので、先月でククログを始めてから5年経ちました。今月から6年目に入ります。実は、ククログでは毎週1本以上記事を公開するという目標を設定しています。何度か公開できない週もありましたが、5年間こつこつと続けてきました。

記事を書くことはそれなりに時間がかかりますが、ふだんあまり意識せずに考えたり実行したりしていることがまとまるというメリットがあります。記事を公開することは知識や便利な情報などを社内・社外と共有する機会ができるというメリットがあります。私達は開発者なので、プログラムを書かずに記事ばかり書いていることには違和感がありますが、たまに書くのであれば十分にメリットがあります。

以前は特定の人だけが記事を書くという傾向がありました。記事を書くことには情報の整理・共有というメリットがあるため、特定の人だけではなく他のメンバーも記事を書くことにしました。記事は、空いた時間をみつけて書くのではなく、あらかじめ書くための時間を確保して書いています。書いた記事は社内Wikiにストックしてあり、毎週その中から選んで公開しています。

この仕組みにより、記事を書く人が特定の人に偏らなくなったため、ククログの記事の内容に幅がでてきました。ただ、ククログでは技術トピックが多めなので、クリアコードでの働き方という観点のものはあまりありませんでした。そこで、今回はクリアコードでの働き方を紹介します。

自己紹介

こんにちは。昨年4月にクリアコードに入社し、オープンソースのカラムストア機能付き全文検索エンジンgroongaやMySQLで高速全文検索を行うためのmroongaのリリース、組込み機器向けのサイネージシステムの開発を担当している林です。

プライベートでは、Sylpheedのプラグインをあれこれ作ったりしています。

今回は自身の例をもとに、クリアコードでの働き方について「1ヶ月のふりかえり」の取り組みと、とある1日の様子について紹介します。

1ヶ月のふりかえり

筆者の場合、ひと月ごとに「1ヶ月のふりかえり」という取り組みを実施しています。この「1ヶ月のふりかえり」では主に2つのことを行います。

1つは、その月の業務内容のふりかえりです。もう1つはふりかえりを踏まえた上で、次の1ヶ月の業務内容を決めるということです。

その月の業務内容のふりかえりでは、以下の内容の報告をします。

実施したこと
実施できなかったこと
業務を通じて思ったこと
できるようになったこと

報告のあと、次の1ヶ月の業務内容を相談します。

それぞれ順番に説明します。

実施したこと

まず、前回の1ヶ月のふりかえりで合意した業務内容のうち、実施したことについて報告します。業務内容は、前回の1ヶ月のふりかえりで決めた後に急遽変更になることもあります。その場合は、変更された内容について報告します。

実施できなかったこと

次に、前回の1ヶ月のふりかえりで合意した業務内容のうち、その月に実施できなかったことについて報告します。自分で実施すると合意したのにできていない項目です。これは当初の工数見積もりの精度が低く、途中で軌道修正をした場合などが該当します。

業務を通じて思ったこと

実施したことと実施できなかったことを報告するとこの1ヶ月での業務内容が明らかになります。業務内容を踏まえて、業務を通じて思ったことを報告します。場合によっては、業務と直接関係のない会社のことや自分のことで感じた点を伝えたりもします。

できるようになったこと

最後の報告は業務を通じてできるようになったことです。これは技術的なことだったり、仕事の進め方だったりします。

これらの報告のあと、「1ヶ月のふりかえり」に参加した人からコメントをもらいます。

その上で、次の1ヶ月の業務内容を相談します。

次の業務内容の相談

1ヶ月のふりかえりの最後に、次の業務内容の相談をします。

このときは、事前に判断材料となる項目の洗い出しと見積もりをした上で相談します。項目についてはおおまかに以下の3つの分類からリストを用意します。

定期的に作業が必要な項目*1
積み残しのままとなっている作業項目
取り組んでみたい項目

リストアップした個々の項目に対して、見積った工数などをもとに次の1ヶ月の業務内容を相談して決めます。

これをだいたい1時間程度で実施します。

この取り組みをしばらく続けたことにより、（始めたばかりのころと比べて）自分からこれがやりたいという項目がだせるようになってきたり、（相談材料をあれこれだせるようになったことで）1ヶ月のふりかえり自体も短時間で終わるようになるという変化がありました。

とある1日の業務内容

1ヶ月のふりかえりで合意した業務内容をもとに、日々の業務を行っています。

業務の中には、定期的に実施している作業があります。それは毎月肉の日（29日）にオープンソースのカラムストア機能付き全文検索エンジンgroongaやMySQLで高速全文検索を行うためのmroongaのリリースを行うというものです*2。

リリースに向けた作業自体はおおよそ1週間前から開始していますが、ここではリリース前日を例として紹介します。

10:00頃までに出社朝会*3の準備
10:30頃朝会で昨日の業務と今日の予定を報告
10:45頃リリース用のソースアーカイブの準備
11:00頃 groongaリリース用パッケージのビルド開始*4
11:00 - リリース時のブログエントリの下書きをビルドの合間に行う
12:00 - 13:00 お昼*5
13:00 - ビルド済みパッケージの確認を随時実施
15:00頃 mroonga リリース用パッケージのビルド開始
16:00頃リリースアナウンスやドキュメントの見直しをビルドの合間に行う
17:30頃ビルド済みパッケージのアップロード、リポジトリの更新
18:00頃 Freecodeへのアナウンスの準備*6
19:00頃コミットへのコメントサービス向けにdairy-report提出
19:00過ぎあとはリリースアナウンスを翌日に行うだけなので帰宅

ぎりぎりまでリリースアナウンスやドキュメントの手直しをしていたりすることもあります。そのため細かな相違はありますが、毎月の肉の日リリースの前日はおおむねこうした進行となっています。

まとめ

昨年4月に入社した筆者の例をもとに、クリアコードでの働き方について紹介しました。より具体的にイメージしてもらえるように、1ヶ月の業務内容の決め方と、とある1日の業務の流れについて触れました。

実のところ1ヶ月のふりかえりという仕組みを実施しているのは筆者だけです。その人に合ったやりかたを模索するなかで、筆者の場合は1ヶ月のふりかえりという仕組みに（今のところ）落ち着きました。

クリアコードでは一緒に働く開発者を募集しています。昨年6月からパッチ採用という新しい取り組みを始めました。また、今年2月からインターンの募集も再開しました。インターンシップのテーマとしては以下を用意しています。

働く環境としてのクリアコード（福利厚生編）という記事もありますので、興味が出てきた人は参考にしてみてください。

今回は、どんな風に働いているかということに焦点を絞って記事にしてみました。「これでどうやってお金をもうけてるんだろう？」という疑問を持たれたかもしれません。クリアコードが会社としてどうやってお金を稼いでいるかについては、機会があれば別記事で紹介します。

*1 毎月肉の日のリリース作業が該当します。

*2 リリース作業は見習いから始めて、3回目のリリースあたりでようやく全部自分で一通りできるようになりました。

*3 クリアコードでは全員が出席する朝会を実施しています。

*4 wheezy, testing, unstable, lucid, precise, quantal, raringなどDebian系だけでもこれだけビルドします。これに加えてCentOSやFedora、Windowsのバイナリもビルドしています。

*5 クリアコードの近所にある「向日葵」でお弁当を購入します。

*6 参考：groonga 3.0.4のアナウンス

この記事の続き

2013-06-10

TAMA協会様主催キャリア体験フェア2013（インターンシップマッチング会）に参加します

クリアコードは、社団法人首都圏産業活性化協会様主催のキャリア体験フェア2013に参加します。

このイベントでは、クリアコードの他およそ10の企業がインターンシップへの参加を検討している学生さん向けに、説明会を実施します。

開催概要

日時

平成25年6月18日（火） 15:00 - 18:30

スケジュール

受付 15:00、開会 15:30
第一部 15:30～16:10
- セミナー「インターンシップ活用のススメ(仮)」
- 参加企業紹介
第二部 16:20～18:15
- インターンシップマッチング会 25分×4回程度を予定（学生が企業のブースへ向かい面談）
閉会：（予定）18:30

場所

国分寺労政会館（国分寺駅南口徒歩5分）

参加費

無料

主催および参加企業

主催：(社)首都圏産業活性化協会(TAMA協会)
インターンシップ説明会参加企業：クリアコード他9社

※他の参加企業については、TAMA協会様Webサイトにてご確認ください。

参加申込

メールでのお申し込みとなります。詳しくは社団法人首都圏産業活性化協会様のサイトをご確認ください。

最後に

6月18日に開催されるTAMA協会様主催のキャリア体験フェアを紹介しました。

マッチング会では、クリアコードの業務内容とインターンシップについて説明します。クリアコードのインターンシップについて詳しく知りたいという方は、是非お申し込みください。もちろんキャリア体験フェアに参加されない方からのインターンシップへの質問や応募も受け付けています。こちらのお問い合わせ先はインターンシップページをご確認ください。

2013-06-11

クリアコードがインターンシップを実施する理由

こんにちは。初代社長の南です。クリアコードでは開発以外のあらゆる業務を担当しています。

はじめに

2013年6月18日にTAMA協会主催のキャリア体験フェア2013が開催されました。このイベントではTAMA地域の学生さんと企業がインターンシップのマッチングを行いました。クリアコードはインターンを受け入れる側の企業として初めて参加しました。クリアコードの他には、IT関連や金融、製造業など幅広い業種の12社が参加していました。学生さんは100名近く参加していたようです。

マッチングでは、クリアコードのインターンシップに興味をもってくれた学生さんに対して、業務内容とインターンシップの概要を説明しました。面談は1回あたり15分で合計5回行ったのですが、参加している学生さんのほとんどが経済学部や文学部といった文系の方*1で、IT業界には興味はあるけれどプログラミングの経験がほとんどない方ばかりでしたので、クリアコードのインターンシップの応募条件を満たす方には出会えませんでした。

そのような状況でしたので、最初2回は業務内容とインターンシップの説明をしましたが、3回目と4回目はなぜクリアコードはインターンシップを行うのかという話、5回目は就職活動の事例紹介として、筆者の就職活動の話やクリアコードで働くまでの経緯を紹介しました。合計5回の面談を通じて、学生さんの反応が良かった*2のはなぜインターンシップを行うのかという話と筆者の就職活動の話でした。

そこで今回は、学生さんがインターンシップ先を検討するときのアドバイスも兼ねて、なぜクリアコードがインターンシップを行うのかを紹介します。

なぜインターンシップを行うのか

インターンシップを実施する企業は、なんらかの目的を達成するためにインターンシップという手段を選んでいることでしょう。クリアコードは、4つの目的を達成するためにインターンシップを実施します。

インターンシップを実施する4つの目的

クリアコードが掲げている目的は次の4つです。クリアコードは、クリアなコードやフリーソフトウェアを大切にしていて、それらにつながった目的になっています。

採用につなげる
- インターンシップを通じてクリアコードのことを知ってもらい、クリアコードを就職先として考えてもらいたい。クリアコードの開発者は業務としてフリーソフトウェアを開発するので、クリアコードの開発者が増えるとフリーソフトウェアへの貢献につながります。
フリーソフトウェア開発者を増やす
- インターンがインターンシップ終了後もフリーソフトウェア開発を続けるようになってほしい。インターンがフリーソフトウェア開発者になれば、フリーソフトウェアへの貢献につながります。
よいコードを書く人を増やす
- 自分達が出会うコードがきれいであってほしい。インターンがよいコードを書くスキルを身につけ、それを実践するようになれば、クリアなコードが増えます。こうしてクリアなコードをさらに広めていきたいです。
伝える技術を磨く
- クリアコードが持っているノウハウや技術を効率よく伝える方法を確立したい。インターンから伝え方に対するフィードバックを積極的にもらえれば、よりうまく伝える方法を見つけられそうです。

この4つの目的のうち、1つでも多くの目的を達成できそうな方をインターンに採用したい考えです。

インターンシップに応募する学生さんの目的

クリアコードは前述の通りの目的を達成したいと考えています。一方、クリアコードのインターンに応募する学生さんもインターンシップで達成したい目的があるはずです。インターンシップを通して学生さんが目的を達成できれば、学生さんにとってこのインターンシップはやってよかったといえるでしょう。学生さんにとって有意義なインターンシップになるどうかは、クリアコードのインターンシップの内容が学生さんの目的達成につながるかにかかっています。クリアコードのインターンシップでは、学生さんは次の目的を達成できるでしょう。

プログラマーの仕事を体験したい
- クリアコードのメンバーと一緒にフリーソフトウェアを開発します。クリアコードの場合、フリーソフトウェア開発も業務ですので、プログラマーの仕事を体験することになります。
フリーソフトウェア開発に関わりたい
- インターンシップではフリーソフトウェアを開発します。フリーソフトウェアですので、インターンシップ終了後も開発に関わり続けることができます。
よいコードを書けるようになりたい
- クリアコードの開発スタイルを伝えたり、コミットへのコメントを通じて、クリアコードがよいコードを書くために行なっている取り組みを体験し、身につけることができます。

これらのほかにも、学生さんの目的を教えてもらえればそれをインターンシップを通じて達成できないか検討します。

インターンの選考でお互いの目的を達成できるかどうか面談で確認

このように、インターンシップを実施する企業、インターンシップに応募する学生それぞれに、インターンシップによって達成したい目標があります。そのため、インターンの選考では、インターンシップを通じてお互いの目的を達成できそうであることを確認する必要があります。そこで、クリアコードのインターンシップの面談では、クリアコードの目的と応募者の目的をお互いに説明し、インターンシップを通じて目的を達成できるか確認することにしています。先日の面談でもこのプロセスを通じて、お互いの目的が達成できることを確認しました。

インターンシップ先を検討する際のアドバイス

このようなプロセスがインターンシップを実施する他の企業でも行われているのではないかと想像しています。もちろん、クリアコードのように明示的に行うところもあれば、書類選考や面接を通じて企業側の視点から企業の目的を達成できるかどうかを判断しているところもあるでしょう。これからインターンシップ先を検討される方は、インターンシップを実施する企業の目的を理解し、また自分がインターンシップで達成したい目的を明確にした上で、お互いに目的を達成することができるかどうか確認してみてはいかがでしょうか。自分に適したインターンシップ先かどうかの判断基準になるはずです。

まとめ

クリアコードがインターンシップを実施する目的と、目的が達成できるか確認するために面談をすることを紹介しました。インターンシップ先を検討する際に参考にしていただけるとうれしいです。もちろん、クリアコードのインターンシップを検討するときは、是非お互いの目的を達成できそうか考えてみてください。

また、7月11日につくばインターンシップ・コンソーシアム主催の2013夏休みインターンシップマッチングフェアに参加します。クリアコードのインターンシップに興味のある方は是非お越しください。

*1 筆者も経済学部出身で、普通に文系就職し、新人のころ3年ほど新卒採用に関わっていましたので、文系の学生さんとお話するのはとても懐かくて楽しかったです。

*2 筆者と学生さんが楽しく会話できて、かつ学生さんからよい感想をもらえたという基準です。

この記事の続き

2013-06-20

問題の原因調査のためのログ収集のセオリー

はじめに

クリアコードでは、FirefoxやThunderbirdのサポート業務において、ログファイルを使って原因を調査することがあります。

この記事では、その中でも特に「手元の環境では再現できない問題について、実際に問題が起こっている環境でログを取得してもらい、それを分析して原因を推測する」という調査の進め方について、どのように進めるのか、また、その時はどのような点に気をつける必要があるのか、ということに焦点を当てて紹介します。

ここでは具体例として、「ThunderbirdでIMAPのメールアカウントを使用しているときに、Thunderbirdがフリーズしてしまう」という問題の原因を調査する場合を想定します。全体としてThunderbirdの事情に特化した説明になっていますが、ログの出力が関係するあらゆる場面で適用できる一般的なセオリーとしても参照できるはずなので、そのような視点でも読んでみてください。

Firefox、Thunderbirdでのログの取り方

ログとは、ソフトウェアが実行した処理の内容や、処理の中で起こったエラーなどを出力したものです。通常は画面上には表れない情報や、処理の流れそのものを見ることができるため、障害の原因調査などにおいて大きな助けとなり得ます。FirefoxやThunderbirdの場合、NSPR_LOG_MODULESという環境変数を使って、内部のモジュール単位でログをファイルに出力できます。

参考：HTTP Logging | MDN

例えばWindowsでは、コマンドプロンプトから以下のように操作することでユーザのホーム以下にログファイルを出力できます。

> set NSPR_LOG_MODULES=timestamp,all:5
> set NSPR_LOG_FILE=%Homepath%\nspr.log
> cd "C:\Program Files(86)\Mozilla Thunderbird"
> thunderbird.exe

Linuxでは、GNOME端末などを使って同じことができます。

$ export NSPR_LOG_MODULES=timestamp,all:5
$ export NSPR_LOG_FILE=~/nspr.log
$ thunderbird

OS X（Mac）では、「アプリケーション」→「ユーティリティ」→「ターミナル」を使います。ターミナル上では、FirefoxやThunderbirdのアプリケーションファイルはフォルダ（ディレクトリ）として見えるため、その中にあるバイナリを直接実行することになります。

$ export NSPR_LOG_MODULES=timestamp,all:5
$ export NSPR_LOG_FILE=~/nspr.log
$ cd /Applications/Thunderbird.app/Contents/MacOS
$ ./thunderbird

環境変数「NSPR_LOG_MODULES」には、ログを取得したいモジュール名とログレベルを「:」で繋げたものを、「,」区切りのリストとして指定します。

モジュール名は、例えば「nsHttp（HTTPでの通信処理）」、「nsHostResolver（DNSによるホスト名の名前解決の処理）」「IMAP（IMAPでの通信の処理：Thunderbirdのみ）」などがあります。どのようなモジュールのログを取得できるのかは、Firefoxのソースコード中でログモジュールを定義している箇所（Thunderbirdの場合）を探すとわかります。各モジュールの開発者がバラバラにログモジュールを定義しているため、日本語で参照できる索引のような使い勝手のいいリストは残念ながらありません。全モジュールをまたいでログを出力したい場合は「all」をモジュール名として指定することもできます。

ログレベルは、「1」から「5」までの間の数字で指定します。数字が小さいほど情報量が少ないログ（致命的なエラーに関する重要な情報だけを出力する）に、大きいほど情報量が多いログ（デバッグ用に参考情報のような重要でない情報も含めて何でも出力する）になります。

ログを取る時の注意点

前段の説明を見ると、「モジュールall、ログレベル5」という最も細かいログをまずは取得したくなるかもしれません。でも、ちょっと待ってください。

一口にログといっても、そこからいつでも好きなようにあらゆる情報を引き出せる訳ではありません。詳細すぎるログは情報の濁流のようなもので、手がかりなしに欲しい情報を見つけることは至難の業です。何の説明もなくぽんとファイルを1つ渡されただけでは途方に暮れてしまうこともしばしばです。

また、ログを取得する側においても、闇雲に詳細なログを取ろうとすると、数百メガバイトから下手をしたらギガバイト単位の巨大なログになってしまう可能性があります。そんなに巨大なファイルとなると、送るのも一苦労です。

どんなログであれば調査の手助けになるのか。ログを取る時にはどんな点に気をつける必要があるのか。基本原則として、ここでは以下の4点を述べます。

原則1：タイムスタンプ付きのログを取得して、実際の操作のメモも残す

タイムスタンプとは、ログの各行が出力された時刻を秒以下の単位で表したものです。FirefoxやThunderbirdのログは、何も指定しないとタイムスタンプが付かない仕様になっています。しかし、タイムスタンプがないと、個々の処理がいつ行われたのか、それぞれの処理にどのくらいの時間がかかったのかがわかりません。特に後者は、「特定の操作でフリーズしてしまう」「処理に異常に長い時間がかかってしまう」といった種類の問題の調査では致命的です。

FirefoxやThunderbirdでタイムスタンプ付きのログを取得するには、「NSPR_LOG_MODULES」で指定するモジュールのリストに「timestamp」を加えます（ログレベルの指定は不要です）。これにより、ログファイルの各行の先頭にタイムスタンプが付くようになります。タイムスタンプはUTC（協定世界時）で出力されるので、日本標準時に直して見るときは表記の時刻に9時間を加える必要があります。

また、タイムスタンプと共に重要な情報として、各操作の実行時や問題発生時の時刻のメモも残しておきましょう。例えば以下の要領です。

X時Y分Z秒頃、Thunderbirdを起動
X時Y分Z秒頃、Thunderbirdの起動が完了（操作できる状態になった）
X時Y分Z秒頃、フォルダを選択
X時Y分Z秒頃、Thunderbirdがフリーズする
X時Y分Z秒頃、Thunderbirdがフリーズから復帰した
X時Y分Z秒頃、Thunderbirdを終了

タイムスタンプと操作時刻のメモを付き合わせることで、ログのどのあたりを重点的に調査すればよいかが分かりやすくなり、調査のための手間を大幅に軽減できます。逆に、このような操作メモが残されていない状態のログ（特に、自分ではない他の誰かが取得したログ）では、最悪の場合は先頭から順に読んで「ここでこんな操作をしたのかな？」と解読していくことになるため、大変な労力が必要となります。

また、そのように付き合わせる都合上、この時の時刻は腕時計や柱時計などではなく、ログを収集している環境の時計（Windowsの時計など）を参照する必要があります。システムの時計と腕時計などとの間で時刻がずれていると、見当違いのログを調べる羽目になってしまいますので、注意してください。

以上の通り、ログのタイムスタンプは非常に重要な情報源となります。ログには必ずタイムスタンプを出力しましょう。

原則2：問題発生時と正常時の両方のログを取得する

問題が再現したりしなかったりして、「問題に再現性はあるが、再現条件が完全には明らかでない」というときは、問題が発生している場合と発生していない場合の両方について、可能な限り同じ手順でログを取得しておきます。問題発生時と正常時の差をログから調べることで、問題の原因究明に繋がる可能性があります。

問題発生時のログだけからでも問題の原因を見つけられるのでは？と思うかもしれませんが、ログに記録されている異常の中には、調査したい対象の問題とは無関係なものが含まれていることがあります。ログに表れている異常を片っ端から「これも怪しい」「ここも怪しい」と精査していると、調査の労力が爆発的に増大してしまいます。特に、手元の環境とは異なる未知の環境で取得されたログの場合、それが問題に関係がある異常かどうかの判断は非常に難しいです。

問題が発生していない時のログが比較対象として存在していれば、問題発生時と正常時の両方のログに表れている異常は、問題とは無関係のものであるとして無視できます。ログは可能な限り、問題発生時と正常時の両方のログを取得しておきましょう。

原則3：最初は問題に関係が深そうな特定のモジュールのログから取得して、後から解像度を上げる

前述した通り、FirefoxやThunderbirdではログの取得対象モジュールとして「all」を指定すると、モジュールを横断してすべてのログを取得することができます。しかし、怪しい箇所の見当も付けられていない状態でいきなりすべてのログを取得しても、どこから見ればよいのかがわからないためお手上げになってしまいかねません。実際、ログモジュールが「all」の状態では、画面描画に関するログやフォントの処理に関するログまで記録されてしまうため、例えばネットワークに関係する機能で起こっている問題に対する調査では、関係ない情報が多すぎて問題の箇所が埋もれて見つけられなくなってしまいます。

問題の内容からある程度の見当が付けられるのであれば、まずは問題に深く関係していそうなモジュールだけに絞ってログを取得しましょう。例えば冒頭で述べた「ThunderbirdでIMAPのメールアカウントを使っていて、Thunderbirdがフリーズする」という問題であれば、少なくとも、HTTPでの通信やPOP3関係の処理は無関係と考えてよいでしょう。逆に、メールフォルダ一般の処理や、IMAP関連で特有の処理は問題と関連していそうだと予想できます。Thunderbirdのソースコードに含まれているログモジュールの定義の中から関係が深そうなモジュールの名前を探して、そのモジュールに限定してログの取得を試みます。

タイムスタンプと操作時刻を付き合わせたり、通常時と問題発生時のログを比較したりして、「ログのこのあたりに異常が現れている」という見当が付いたら、そこで初めて他のモジュールのログも併せて取得するようにしましょう。他のモジュールのログも併せて取得した中から、先程見当を付けたログに対応するものを探し、その周囲を眺めると、モジュール単位のログには表れていなかった、一見すると無関係な別のモジュールの異常が見えてくるかもしれません。

例えば、IMAP関連の処理のログの中でタイムスタンプにギャップが生じている（1行1行の間に数秒以上時間がかかっている）箇所があった場合、他のモジュールのログも含めて出力したものから、異常が現れていたIMAPのログの箇所を見つけ出すこおで、そのギャップの間に何が起こっていたのかが明らかになる可能性があります。

同様のことがログレベルにも言えますが、問題が起こっているときの原因調査という場面では、ログレベルは最初から「5」（デバッグ用、最も詳細）を指定して問題ないでしょう。「1」などの解像度が低いログレベル（エラーのみの出力など）は、運用上のポリシーとして普段から常時ログを取り続けるといった場合に使います。

原則4：ログの取得中は、余計な操作をしない

原則3とも関係していますが、ログの収集中は可能な限り、関係のない操作をしないようにしましょう。

例えば、前述した通り、ログモジュールが「all」の状態では、画面描画やフォントの処理に関するログまで出力されるため、極端な場合、マウスを動かしてツールバーボタンの表示が変わるだけでもそれに対応するログが記録されます。このような無関係なログの出力を控えるため、モジュール「all」でログを取得するときは、マウスやキーボードに必要以上に触れないことが望ましいです。

また、自動アップデートのためにバックグラウンドで行われる通信なども、問題の再現条件に含まれないのであれば、可能な限り無効化しておくことが望ましいです。FirefoxやThunderbirdの詳細設定で機能を無効化できますので、忘れずに確認しておいてください。

Thunderbridではなく、サーバ上で動作するソフトウェアのログを収集する場合は、関係のない処理はなるべく停止しておくということになります。例えば、システムのアップデートやrsyncでのファイル同期、cronjobなどが考えられます。できるならば、サーバをサービスから切り離せる（そのサーバ1台をネットワークから隔離しても、表向きはサービス運用に支障がない）状況を整えておいて、調査時には必要のない処理はすべて停止しておきたいものです。

問題の種類によってはログの取得に時間がかかることがあり、その間、暇つぶしや日常業務として別のことをしたくなるかもしれません。しかし、問題と無関係な情報がログに大量に含まれていると、本当に問題の原因となっている箇所を特定することが難しくなります。ログの収集中は、ログ収集という作業の「本番」と考えて、可能な限りそのことだけに集中することが望ましいです。