都元ダイスケ IT-PRESS このページをアンテナに追加 RSSフィード

最近は会社ブログしか書いてません。

2011-12-05

[]JIRAの課題検索とフィルターを使いこなそう

JIRA Advent Calendarってのに巻き込まれました。巻き込まれサイコーw

昨日は@oota_ken氏のJIRAのスキーマーをastahのクラス図で書いてみる ユーザー編 – テスト自動化他何かのメモでした。確かに、JIRAのデータ構造って、ぶっちゃけ理解するの大変ですよね…。なんちゃらスキーム苦手ですw

で。@yusukeyサンからの「オマエのJIRAへの愛を語れ」っていう振りは完全スルーして、普通に活用Tips書きますw

自分はJiemamyプロジェクトにOSSライセンスを頂いて以来、随分長いことJIRAユーザをしています。なので、もうちっとディープな話もできなくもないかなぁとは思ったのですが、周囲を見ていると、玄人向けの難しい機能を紹介するよりも「願わくば全てのJIRAユーザが活用して欲しい、けどもなかなかこれを活用している人はいないんですよね」的な機能の紹介をしたほうがウケがいいよね、と思ってそんなネタを書きます。

JIRA Advent Calendarに参加するような人たちは既知のお話だと思いますが、活用歴が浅めのユーザさんに向けて。

まず課題検索を理解する

f:id:daisuke-m:20111205210334p:image:right

JIRA上には様々なチケットが蓄積されていきます。まず、そのチケットを「探す」ことにフォーカスを当ててみましょう。

検索と言えば、まずは普通にキーワード検索が浮かぶと思います。また、チケットID*1でチケットを探すこともあると思います。このような検索は、通常画面の右上にある「クイック検索」を利用します。

とりあえず、Jiemamy ProjectのJIRAに行ってみて、右上のクイック検索欄に「FileNotFoundException」とか入力してみましょう。この記事の執筆時点では ISM-18 とCORE-128 という2つのチケットが引っかかるはずです。続いて、同じくクイック検索に「ECL-100」と入力してみると、該当チケットに直接ジャンプします。って、普通ですね。

ここまでは敢えて説明するまでもない、普通の検索です。しかしこの「クイック検索」ボックスは、実は恐るべき機能を備えています。例えばここに「ECL unresolved」と入力してみましょう。そうすると「スマート クエリが起動しました。」というメッセージと共に「未解決で、かつECLプロジェクトに属するチケット」が表示されます。そう、unresolvedなど、いくつかの単語は普通にキーワード検索されるのではなく、特殊な意味として解釈されるのです。

f:id:daisuke-m:20111205210335p:image

その他、「CORE bug created:-10w」(COREプロジェクトで過去10週間以内に作成されたバグチケット)など、色々な検索を手軽にできるんですが、その中でも私が一番使うのは「my unresolved (プロジェクト名)」(ex: my unresolved ECL)ですかね。このスマートクエリは、是非知っておきたい機能です。

あわせて読みたいno title

色々なフィルターを紹介

クイック検索を使って、簡単にチケットを検索できることがわかりました。しかし、前述のような何度も使う簡単な検索条件は、覚えてしまえば良いのですが、覚えるのには向かない程度に複雑であるものの、よく使う検索条件、というのも存在します。そういったものは「検索条件を保存」しておいて、必要な時に呼び出せば良いのです。このように「よく使う検索条件を保存したもの」のことを「フィルター」って呼びます。

f:id:daisuke-m:20111205210336p:image:w100:right

f:id:daisuke-m:20111205210337p:image:w150:left

少し話が飛びますが、検索には「簡易検索」と「高度な検索」というものがあります。前者はフォームに検索条件を細かく指定するタイプ(右図)の検索なのですが、私はほぼこれを使いません。まどっろっこしい! まぁ多分、エンジニアだからでしょうけどw フィルターに保存するくらいの複雑さを持つ検索条件は、「高度な検索」を使うと良いと思います。というわけで、これを高度な検索に切り替えてみましょう。

まず、クイック検索で適当に「my unresolved」等と検索してみましょう。その上で、検索結果の左側にあるエリアの上方「高度な検索に切り替える」をクリック(左図)します。そうすると、検索結果の上に「クエリ」というテキストエリアが表示され、ここに検索条件を「式として」記述できるようになります。この条件式の記述言語はSQLに似た形になっており、「JQL (JIRA Query Language)」と呼ばれています。JQLを活用すれば、簡易検索では表現できない複雑な検索条件を記述できるようになります。

f:id:daisuke-m:20111205210339p:image

で、JQLの細かい書き方はドキュメントに任せることにして、ここでは私が普段使っているフィルターを、成り立ちと共に具体的に紹介したいと思います。(エンジニアの方は普通にJQLを読めると思います)

報告者にアサインして解決確認を依頼すべき担当課題

JIRAのチケットは、特にカスタマイズしていない状態では、「オープン→対応中→解決済み→クローズ」というライフサイクルを辿ります。ただ、私の経験上、デフォルトのままのJIRAを運用すると、解決済みのステータスで止まってしまってクローズに至らないチケットがあまりにも多いのです。しかしこれはある意味当然の事。実施者が満足して解決済みとしたタスクは、多くの場合特に問題はなく、完全に終わったタスクだとみなされてしまいます。従って、それ以上、そのチケットに対してアクションをする必要はない、と考えてしまうのです。そもそも「クローズ」という状態の存在さえ忘れてしまう。だって、解決したんだから良いでしょう? という気持ちです。

ただ、より一層厳密に仕事を進めるために、対応者が行った仕事の結果を報告者*2に見てもらい、チケットを作った意図通りの結果になっているかどうか最終確認をしてもらう、というプロセスを踏んだ方がトラブルが少ないでしょう。従って、まずチーム内で「対応者が満足して解決済みにしたチケットは、報告者にアサインを返し*3、クローズを依頼する」というルールを作り、コンセンサスを得ます。(このルールを厳密化するために、私が管理するJIRAでは「報告者でなければチケットをクローズできない」ように設定しています。この方法は今回の話から脱線するので、また別の機会にでも。)

しかし、人間というのは基本的にミスをする生き物です。前述のルールでは、対応者がチケットを「解決済み」にする際に、報告者にアサインバックすべきなのですが、担当者の変更を忘れてそのままにしてしまう、というミスが頻発します。こんなエントリを書いている私でさえ、よくやります。このようにアサインバックを忘れられたチケット*4は、ダッシュボードの「自分の担当課題」には表示されなくなるため、ほぼ確実に "忘れ去られた存在" になります。

そこで効果を発揮するのがこのフィルター。

status = Resolved AND assignee = currentUser() AND reporter != currentUser()

「ステータスが解決済み かつ 担当者が自分 かつ 報告者が自分ではない」チケットですね。この条件に引っかかるチケットは、前述の「アサインバック忘れ」ですので、見つけ次第、報告者にアサインを返す操作をしましょう。

解決を確認の上クローズすべき担当課題

次に、上記のシナリオでアサインバックされた側の話。このような経緯でアサインバックされたチケットは既に「解決済み」のチケットです。従って、このチケットも「自分の担当課題」には挙ってこないんですね。というわけで、確認しなければならない立場の人にとっても同様、"忘れ去られて然るべき存在" なのです。同じように、フィルターで検出してあげましょう。

status = Resolved AND assignee = currentUser() AND reporter = currentUser()

解決済みで、担当者と報告者がどちらも自分のもの、というフィルターです。この条件に引っかかるチケットは、対応内容を確認して、問題が無ければクローズ、問題があれば再オープンして対応者に差し戻す必要があります。

期限超過の担当課題

JIRAのチケットには「期限」という項目があります。が、別に期限を過ぎたからって、デフォルトのJIRAは何をしてくれる訳でもありません。でも、期限をオーバーしてしまったチケットには早めに気づきたいですよね。そこでコレ。

resolution = Unresolved AND assignee = currentUser() AND due <= now() ORDER BY due

このように、期限の値が現在より小さい(つまり過去)で、解決されていない自分担当のチケットを検出します。この条件に引っかかったら、早急に対応するか、または期限の見直しをすべきでしょう。

長期放置の担当課題

とは言え、チケットの期限設定というのは意外と難しいものです。チケットを作る人が勝手に期限を設定したとしても、実際の対応者が対応しきれなければ全く無意味です。対応者の忙しさを度外視して、チケット作成者の都合だけを押し付けた期限を設定しても印象悪いだけですしw 従って、よほど明確なデッドラインがあるチケットでなければ、基本的に期限を付けずにチケット発行することが多いようです。経験的に。

しかし、期限がないままチケットをアサインすると、そのチケットをそのまま握り続けられてしまう場合があります。期限がないので「期限超過の担当課題」にも引っかかりません。他にもっと優先度が高いチケットがある、という錦の御旗の下、黙殺されるチケットになってしまうのです。

しかし私は、そういった優先度の低いチケットであっても、定期的にレビューし、放置されている状態が適切かどうかを考える必要があると考えています。もしかしたら状況が変わっていて、もっと優先度が上がっているかもしれません。GTDでも、定期的にタスクをレビューしますよね。

というわけで、長期に渡って放置されている課題をフィルターで検出します。

updated < -14d AND status != Closed AND assignee = currentUser()

ここでは「長期」を「14日間」としていますが、まぁここは各自調整してみてください。この条件に引っかかるチケットは、引き続き放置することが適切であるかをレビューしましょう。放置してはいけないと判断した場合はチケットを編集して優先度を上げましょう。編集すればupdatedの値が更新されるのでこのフィルターには引っかからなくなります。また、引き続き放置する場合は、一言コメントしましょう。コメント操作でもupdatedの値が更新されます。

フィルターを購読する

と、まぁ私が普段使っているフィルターを色々紹介してきましたが、フィルターを作るだけではあまり効果がありません。このフィルターは「フィルターの結果」ウィジェットを使ってダッシュボードに常設しておくと良いでしょう。ウィジェットの追加方法は、説明し出すとまた長くなるので、@Sean_SFさんのブログ no title を参照してください(逃)

ここではもう一つ。定期的にフィルターの条件を満たすチケットが無いかをチェックし、条件にhitするチケットが検出されたらメールを送る、という技です。

JRIAの課題メニューの一番下に「フィルターの管理」という項目がありますので、このページに飛んでください。作ったフィルターが列挙されているはずです。そのそれぞれのフィルターの右方に「配信登録」というリンクがあるはずです。これをクリックし、適当なスケジュール(例えば毎朝9時など)で配信登録してみましょう。これで、フィルターに引っかかった課題リストを毎日メールしてくれるようになります。

朝出社したら、このメールを見ながらチケットを整理することによって、クリーンな状態で仕事を始めることができますね。

番外編:今週解決した課題

resolution = Fixed AND resolutiondate >= startOfWeek() AND resolutiondate <= endOfWeek()

私が最近作ったフィルターです。週の頭には1つも引っかかりませんが、週末になるに連れて課題が増えていきます。あー、ウチのチームは今週これだけの仕事を進めたんだなぁ、って眺めながらニヤニヤする用のフィルターです。

実は私はもう一工夫して「自分が今週解決した課題」として、より一層ニヤニヤしているのですが。ただしこの場合、単に assignee = currentUser() ではダメなんですね。というのも、前述のルールでは、自分が解決したとしても報告者にアサインバックしてしまうから。そこで「 lastResolutionUser = currentuser() 」っていう条件(最後に「解決済み」にしたユーザ、つまりほとんどの場合「タスクの実施担当者・対応者」を表す)を使っています。しかしこの lastResolutionUser っていうのはJIRAの標準機能ではありません。Jira Enhancer Pluginというプラグインインストールし、設定しています。頑張れる人は各自頑張ってみてください。


さて JIRA Advent Calendar 4日目は以上です! みなさんも、便利なフィルター条件があったら教えてください。明日はエロ元上司 @j5ik2o (id:j5ik2o)…かと思いきや、どうやら@yusukeyの無茶振りに対してバックレを決め込んでいるようです。俺はそんな上司に育てた覚えはないぞっ!!w 観念してエントリーするように。

というわけで、明日は @inda_re 氏のエントリーです。お楽しみに!

*1:正確にはキーって呼ぶみたいですね

*2:チケットを作った人=仕事を振った人

*3:担当者をチケット作成者に割り当てる

*4:つまり「ステータスが解決済み かつ 担当者が自分」のチケット

2011-08-21

[]ソフトウェア開発者、完売いたしました

転職活動をはじめて2ヶ月弱。ようやく次の落ち着き先を決めました。ちなみに「転職したのに上司が変わらなかった」っていうネタも考えていたのですが、id:j5ik2o と行き先は別々になりました。まぁ、かとうさんは「永久名誉上司」として、永遠にエロ上司扱いしてやろうと思っています。あ、某D社の皆様も、早速エロ呼ばわりしてみると良いと思いますよ。喜ぶと思いますw

…さて。

正直、先日のエントリを上げる直前は、もうこの業界に自分の居場所はないかもしれない等と考え、薬屋への撤退戦略などを考えたりしていました*1。しかし、エントリを上げた途端当人らがびっくりするほどの反響を頂き、最初の1ヶ月は一つ一つお話を聞かせて頂くべく東奔西走していました。この真夏の陽気で外回りは結構体力的にも大変*2でしたが、この年になって社会科見学をしているようで、様々な勉強をさせて頂きました。本当に皆さん、色んな考えを持ってソフトウェア開発に向き合っているんだなぁ、と自分の視野の狭さが恥ずかしくなるようなこともw お話を聞かせて頂いた皆々様には、改めてお礼申し上げます。

しっかし、今回ばかりは自分の体が一つしかないことを恨みましたねw 各社様、本当に素晴らしい会社ばかりでした。しかし最終的に、自分の出来ること、やりたい事、求められている事など…そして直感によって、最もチャレンジングな決断をしました。

来月からクラウドスタディという会社にお世話になります。一言で言えば、従来孤独な戦いであった「勉強」を技術の力でサポートするサービスを展開する会社です。現在はスタディログというサービスを運営しています。スタートアップ企業のため、本当に取り組むことは多く、そして面白いことが出来る場所だと思っています。

というわけで、9月からは新しい世界です。クラウドスタディ関係者の皆様、改めましてどうぞよろしくお願いします。そして、友人各位、また、このブログを読んでくれている読者の皆様、今後とも今までと変わらぬご指導・ご鞭撻を宜しくお願いいたします。

あわせて読みたい 転職先が決まりました - じゅんいち☆かとうの技術日誌

*1:この話をすると「そんなバカなww」って言われるんですが、当人は本気だったんですよぉ。。。

*2:実は、4kgくらい痩せましたw リバウンドしないといいなぁ。。

2009-12-29

[]前提条件を破った場合、どのような挙動をするのか?

「Nullチェックされている前提の処理」とJavadocに書いたとき、「throws NullPo…」は書くんだろうか。んー、コード上は発生しうるけど、実際発生しないから不要なのかな

no title

まぁ、このブログで書いている話は、あくまでも「俺式」ということをご理解いただいた上で。(ここに書いた事が全て、って訳じゃありません。他にも色々ポリシーはあると思うが、自分はこれが一番良いと考えている。)

自分の考えは、契約プログラミングに基づいてます。DbC(Design by Contract)って奴ですね。

あるメソッドが「Nullチェックされている前提の処理」というのは、引数にnullは入ってこない前提、ということですよね。そしてJavadocを書くということは恐らくこのメソッドは公開API(publicかprotected)だ。可視性については、可視性と公開APIと非公開(内部)APIと - 都元ダイスケ IT-PRESS参照。非公開APIにJavadocを書いてはいけない訳ではないのだが、その場合はExceptionではなく、Errorを飛ばし*1、「メソッドやクラスの仕様」ではなく「ライブラリの仕様」として「このライブラリのバグ*2に遭遇した場合はErrorが飛ぶ」というドキュメントをつけるようなことをする。書く場所は、このライブラリのトップレベルパッケージ(org.jiemamyとか)のpackage-info.javaあたりかな。

さて、公開APIを使うのは自分(のプロジェクト)だけではないと自分は考えている。誰がどのように呼ぶかわからない。つまり「今自分が見えている範囲」では確か呼ぶ側で事前にnullチェックがされているかもしれないが、「自分がそのプロジェクトから離れた後」にnullチェックしないままこのメソッドを呼ぶような処理を書くかもしれない。また、この成果物がライブラリ化され、「自分の与り知らない所」からnullチェックしないまま呼ぶかもしれない。ということを考慮する。

公開APIで「実際発生しない」というのは「自分が見えてる範囲でたまたま」発生しないだけだ。publicという単語には「共同で使うための、公共の」という意味がある。法律上の問題*3は別次元として、publicな型やメンバはもう「みんなのもの」なのだ。

現代は4つのアクセスレベルでの可視性制御の限界が囁かれていて、打破するためにいろいろ模索しているところ

はてなブックマーク - Nagiseのブックマーク / 2009年12月24日

余談だが、確かに影響が閉じる範囲が「クラス内(private)」「パッケージ内(default)」「全世界(protected,public)」というのはちと乱暴なのかも。defaultとprotectedの間に、もう少し広い「非公開API」があっても良いと思う。例えば「同じjar内」とか。こういうことを実現しようとしているのが、JAM(JSR 277)の話だったりOSGiの話だったりするのだろう。

閑話休題。引数がnullではない、というのはこのメソッドが動作する前提条件*4だ。この前提条件をどのように仕様化するか、いくつかの状況を考えてみた。

状況1: 暗黙の前提条件

今まで、現場で「暗黙の前提条件」というのを頻繁に見て気ました。まさにこのnullの例が多く、作った人に聞いても「いや、このメソッドはnullが渡されない前提だから」って…。なら書けw まぁJavadocがそもそも無い(=仕様がない)のだからムリだよなぁ。まぁこういった「暗黙の前提」が一番タチが悪い。

/**
 * 入力文字列を装飾して返す。
 *
 * <p>ただし、入力文字列の長さが3未満の場合は元の文字列をそのまま返す。</p>
 * <p>修飾とは、入力文字列の前後に以下の文字列を付加することである。</p>
 * <ul>
 *   <li>前に付加する文字列 "*・゜゚・ *:.。..。.:*・゜"</li>
 *   <li>後ろに付加する文字列 "゚・ ・*:.。. .。.:*・゜゚・*"</li>
 * </ul>
 *
 * @param src 装飾対象の文字列
 * @return 装飾済みの文字列
 */
public String decorate(String src) {
  if (src.length() < 3) {
    return src;
  }
  return "*・゜゚・ *:.。..。.:*・゜" + src + "゚・ ・*:.。. .。.:*・゜゚・*";
}

余談だが、上は「Javadocから実装が書ける」ことを意識したJavaodcになっていると思う。自分が昔よくやってしまっていたのは、「一番最初の1行しか書いてない」という状況w

状況2: 前提条件は示されている

そして、まぁマシなのはJavadocに上記のような「前提」が書いてある場合。まぁ渡しちゃったからNullPointerException(以下NPE)が飛んだんだな…、と推測できる。ただ、あくまでも推測だ。仕様はガッチリ固定されているべきで、使う側に推測させると意識のズレが発生する。明確に示すべきだと思う。

/**
 * 入力文字列を装飾して返す。
 *
 * (略)
 * <p>Nullチェックされている前提の処理なので、引数にnullを与えてはならない。</p>
 *
 * @param src 装飾対象の文字列
 * @return 装飾済みの文字列
 */
public String decorate(String src) {
  if (src.length() < 3) {
    return src;
  }
  return "*・゜゚・ *:.。..。.:*・゜" + src + "゚・ ・*:.。. .。.:*・゜゚・*";
}

状況3: 前提条件が崩れている時の挙動が示されている

「引数はNullチェック済み前提」ではなく「引数にnullを与えたらNPE」つまり「@throws NPE 引数にnullを与えた場合」とだけ書くと良いと思う。これで前提条件を示すこともできるし、崩れた場合の挙動も示すことができる。

/**
 * 入力文字列を装飾して返す。
 *
 * (略)
 *
 * @param src 装飾対象の文字列
 * @return 装飾済みの文字列
 * @throws NullPointerException 引数に{@code null}を与えた場合
 */
public String decorate(String src) {
  if (src.length() < 3) {
    return src;
  }
  return "*・゜゚・ *:.。..。.:*・゜" + src + "゚・ ・*:.。. .。.:*・゜゚・*";
}

状況4: で、俺式では

/**
 * 入力文字列を装飾して返す。
 *
 * (略)
 *
 * @param src 装飾対象の文字列
 * @return 装飾済みの文字列
 * @throws IllegalArgumentException 引数に{@code null}を与えた場合
 */
public String decorate(String src) {
  if (src == null) {
    throw new IllegarArgumentException();
  }
  if (src.length() < 3) {
    return src;
  }
  return "*・゜゚・ *:.。..。.:*・゜" + src + "゚・ ・*:.。. .。.:*・゜゚・*";
}

NPEをIAEに切り替えた。なぜか?

まずは抽象度の問題。「これを装飾しろ」に対して「nullを参照する変数にアクセスしてしまった!」という結果は、なんか会話が成り立っていないと感じる。自分は「これを装飾しろ」に対して「引数がおかしいよ!」と答えることで、会話が成立すると思う。

「飯くおーぜ」→「破産しちまった!」って会話が微妙にズレてませんか? 「飯くおーぜ」→「金ねーんだ、スマン」が妥当じゃなかろうか (例がイマイチだが…)

もう一つは、NPEってのはプログラマの不注意で結構頻繁に発生する例外だからだ。無意識にNPEが飛ぶことはあるが、無意識にIAEが飛ぶことはない。

別に注意力をもっと持てという訳じゃない。人間なんだから、絶対にやっちまう事がある。だから、俺式では「NPEは、飛んだらその時点でバグ」と位置づけてしまっている。乱暴に感じるかもしれないが、こうするとバグが早期に発見できる。つまり、@throws NullPointerException は書かない。書くと仕様になってしまい、バグではなくなるから。

まとめ

  • 「前提条件は何か」ではなく「前提条件を破った時の挙動」を書く。
  • 公開APIは「世の中全てのコードから、可能性のある全ての状況で呼ばれている」と考える。
  • コード間に自然な会話を成立させるような設計を目指す。
  • NPEが飛んだらバグ

繰り返しますが、俺式ルールです。

あわせて読みたいno title

*1:assert文を使います。

*2:クラス内やパッケージ内に閉じているのだから、ライブラリのバグのハズ。

*3:著作権や特許等の知的財産権的な話。

*4:こういうのも事前条件と言えるんだろうか。自身のクラスが満たしているべきステートの条件のみを事前条件と呼ぶのだろうか。この辺り俺曖昧。

2009-12-22

[]MavenでLinuxのOS破壊

Mavenを使っていてLinuxのOSを破壊したので書いておく。

<plugin>
  <artifactId>maven-clean-plugin</artifactId>
  <configuration>
    <filesets>
      <fileset>
        <directory>/lib</directory>
      </fileset>
    </filesets>
    <failOnError>false</failOnError>
  </configuration>
</plugin>

mvn clean した時、通常は target ディレクトリ(配下のファイルも含めて)を削除する。これと共に、別のファイルも削除したいかったので、上記のような指定をした。この例では、プロジェクト直下のlibディレクトリを削除したかった。

さて、これをwindowsで回した時は意図通りだった。しかし、かつてJiemamyのリリースをしようとした時、Linuxサーバ上でmvnを回したのだ。

しかもroot権限で。

大方予想がついた方もいると思うが、プロジェクト直下ではなく、ルートディレクトリ直下のlibディレクトリが全部消えやがったwww そん時って、lsもできなくなるんだぜ?w

教訓「sudo su - はするんじゃねえ。」

あーとーはー。pomの設定はこんな感じにしておきましょう。

<fileset>
  <directory>${basedir}/lib</directory>
</fileset>

注:Mavenは全く悪くありません。悪いのはrootで実行した俺です…。

あわせて読みたい Mavenで個人情報漏洩 (Kanasansoft Web Lab.)

2009-07-07

[]エンジニアとしての歩き方

これから書くことは決して「これをしなければいけない」とか「他に手段はない」なんてコトを主張したいのではない。色んな道があるはずだぁ。その中の一つの事例として、自分がやってきたことをフレームワーク化し、色々挙げてみようと思う。

当然、俺の主観が入りまくっているので、突っ込みどころは満載だろうなw そもそも「エンジニア」って何?w その辺り、はてブ界隈のミナサマにおかれましてはお手柔らかに願いたいww

さて、いきなりどこかの技術系カンファレンスで1時間喋っちゃえ、とか突然は無理なのは分かる。何を話せばいいのやら、どこに喋るチャンスがあるのやらだ。しかし、そういう所で喋るような自分を将来のビジョンとして持っている人は、以下に挙げることを小さなことからコツコツと実践してみるといいかもしれない。という意図で書いていく。

何事にも興味を持とう

興味は勉強の原動力。興味のない勉強は苦痛でしかない。ここが実は一番ハードル高い。

興味って持とうと思って持てるモンじゃないもんね。だけどね、勉強やめたらエンジニア終了だと思ってる。俺は、勉強するのやめる時は、一緒にエンジニアも辞める。

そもそも、興味を持てないならば「しっかりエンジニアとして歩んでいこう」と強く思ったりしないかなw というわけで、このフェーズだけは解決策をご提案できない。残念ながら。各自全力を尽くすべしw

ブログを読もう

本文まできっちり読む必要ないんです。RSSリーダー使って、タイトルを1エントリにつき0.5〜2秒程度眺めるだけでもいい。その時間内に脳に引っ掛からないエントリはサクサク飛ばす。気になった記事だけブラウザの別タブに開いておいて、RSSを流し終わってから読む。まぁ、そんな使い方が、いまどきのRSSリーダーではできるはずだ。ちなみに自分はlivedoor Readerを使っている。

そして巡回はなるべく毎日行う。溜まると逆に読まなくなる。万一溜め過ぎてしまったら、一回破産してみる。全部読んだことにする。溜めすぎて読まないよりも、一回破産して今以降の記事を読んだほうがいい。

まだ「どのブログを読めばいいのかか分からない」というのもあるか。何かを知りたくてググった時、自分に情報を与えてくれた記事を書いていた人のブログとか。気になる人、有名人、興味があれば誰でもいい。とりあえず購読してみて、つまらないとおもったら外せば良い。興味がある人が見つからない人は前の節に戻る。

とりあえず今日から「都元ダイスケ IT-PRESS」を購読する、とかどうさw まぁ、俺だけだとたまにしか新着来ないから毎日巡回癖がつかないけどw

ひとまずネタは技術に限らない。興味あれば何でもいい。例えばこんなの。


ちなみに、これらのフィードは下に行けば行くほど購読負荷が高い気がするw 読むのに時間を食うようになり、未読を溜めがちになる。

本を読もう

興味のある本を探して読もう。時間は基本的にない。けど寝る前の30分を続けるだけでいい。

月に1〜2度、技術書が豊富な本屋で、平積みになっている本をチェックする。最新動向はRSSで単語くらいは拾っているはずだから、目に付く技術がいくつかあるはず。本当に興味があったら即買ってしまおう。(積読にならない程度にw)

技術書の類は基本的に高価だが、そこは自分への投資として割り切る。読み終わって手元にいらない本であれば、Amazonで売ってしまえばよい。読み物系であれば図書館を利用するのも一つの手だ。近場に技術書の豊富は本屋がなければ、仕方ないのでAmazonの巡回で代用。

いきなり技術書は敷居高い、という場合は雑誌。この辺りお勧め。俺はWEB+DBは毎号購読している。

日経ソフトウエア 2009年 07月号 [雑誌]

日経ソフトウエア 2009年 07月号 [雑誌]

興味ある本がない? このエントリのスタートに戻るべし。

ブログを書こう

情報入力のキッカケは、以上で掴める。今度はアウトプットについて。

ブログというのはアウトプットのメディアであると考える人が多い。しかし自分はインプットのメディアだと考えている。技術系ブログを書く人の多くは、同じ感覚を持っているんじゃないかな。

発信するのにインプットとは、不思議なことを言う、という感覚もあると思う。しかし、不思議なことに書けば書くほどインプットが増える。面白いものだ。具体的には人との繋がりが出来ることで、その人からのインプットが入る等。トラックバックなどは代表例。

あとは、自分が得た知識について書くことにより、自分の頭がより一層整理される。自分に対する備忘録にもなる。何かを人に伝えるときに、自分の過去エントリを紹介することもある。例えばこのエントリなんかも、将来「どうしたら使えないエンジニアにならずに済みますか」という後進育成に使うかもしれないw

ただ、RSSも本も読まずにブログを書き始めると、書くことがない。日々、業務だけで一日が終わる状態だと、業務に関することは大抵ブログなんかにゃ書けない訳で。

前段でひっかかったネタを自分なりに色々書いてみる。以下のように、何だって良い。低レベル過ぎる!と思うかもしれないが、そのレベルだって分からない人がいっぱいいるんだ。誰かの糧にはなる。

あわせて読みたい僕がBlogを続けるたった1つの理由 - GoTheDistance

  • 開発環境構築方法
  • JavaでHello worldやってみた
  • オープンソースってなんだ? 定義を調べてみた
  • など

ニュースサイトや雑誌記事と違って、ブログは自分が主役の空間だ。著作権・プライバシー・名誉毀損・業務機密あたりの常識的なマナーにさえ気をつけていれば、別に説明が下手でも(最悪、嘘を書いてしまっても)怒られない。自分のブログに下手な文章載せて何が悪い。なにか指摘されたら間違ってましたテヘでいい。

で、ブログを書く場所としてはこの「はてな」が一番お勧め。何よりも技術者が多い。偏っていると言えばそれまでだが、メリットでもある。

あと、積極的に自分のブログを宣伝する必要はない。みんな検索で引っ掛けてくるし、特定のキーワードで網を張ってる人にも引っ掛かる。ただ書くだけで、いつの間にか読者がついていたりする。

ブクマをしよう

日々、検索やRSS等であちこちのサイトを読むと思う。タイトルに惹かれて記事を読んだら、評価にかかわらず、とりあえずブクマする。読んだものはブクマ。(自分自身もあまりできていないのだが)

人が一日に「まじめに最後まで読む」記事なんて高が知れている。全部ブクマじゃ。これは例えば、後から人と話していた時なんかに「あー、2週間くらい前にそれ絡みの記事読んだな…」という掘り起こしに便利。

あー、この人はこの分野に興味持って読んでるんだ〜、とか、自分を知ってもらえる。また、ブクマするだけなく、他人のブクマを購読しておくと、誰かが興味を持った記事を一通り追いかけることもできる。逆に言えば、誰かに自分のブクマを追いかけてもらうこともできる。

タグ分類はするに越したことは無いが、読んだ結果ツマンネとなったものはタグなし、とかにしておいても良いと思う。

で、何使うかって、はてブ使っておけばいいんじゃないかね。

勉強会に出て話を聴こう

興味のある技術に関するカンファレンス(法人主催の大規模な奴)とか、テーマは意外とバラバラだけど気軽に参加できる雰囲気のある勉強会(java-jaとか197Xとか)なんか、とりあえず行ってしまえばいいとおもう。

そして、懇親会には出来る限り参加しよう。酒が飲めないとか関係ない。普通の友達と飲みに行くのと違って、飲まない奴とは盛り上がれないなんていう雰囲気は皆無。飲まない人を何人も見たことがある。id:Yoshioriなんかは毎度コーラだし。日本には「何かと理由をつけて飲みたがる」という慣習があるが、エンジニアが集まると「飲み会という理由をつけて技術談義をしたがる」のだ。あーだこーだ喋れる空間が欲しいだけなのだw 最悪酒がなくても場があれば満足するだろうw

本編で興味深いことを喋っていた人を捕まえて、話しかけるんだ。喋った人ならば、大抵会場にいる。「今日のお話、よかったです!」って言うだけでおk。そんな風に話しかけられて気を悪くする人はいない。

また、なんとなく近くに居る人に話しかけてもいいのだ。「はじめましてー」って。人見知りの人も居るだろうけど、懇親会が始まったらなるべく早く誰かを捕まえてしまおう。終盤になればなるほど「はじめましてー」で捕まえづらい雰囲気が(自分の中に)出来てしまう。安心しろ、懇親会に出てくる人は、誰か(初めての人でも)と話したいハズだ。

この辺りで人に会うと、その人のブログを読むようになる。情報の入り口にだんだん広がりが出てくる。

そして、勉強会に出たあとにはブログにまとめを書く*1。会った人と喋ったことを、はてなidつきで紹介とかしちゃう。書かれた方も嬉しいモンです。

技術者同士の繋がりを広げよう

ここまでやってくると、意外と人脈が出来上がってると思う。顔見知り数人のブログを読んだり、一方的に知ってるだけだが興味がある人がいたり。

しかし、せっかく勉強会で顔見知りになったのに、勉強会で偶然出会った時にしかコミュニケーション取れないというのは勿体無い。というわけで。

そんな人と、常日頃から絡む。今流行りのtwitterで相手の言ってることに突っ込むのもよし、skypeを利用してチャットするもよし。

twitterなんかは、この手のコミュニケーションに最適だ。twitterにおいて、誰かと「お友達」の関係を作ることを「フォロー」という*2。ところで例えば、mixiの文化は「知らない人のマイミクは無理」的な空気があると思う。しかし、twitterの文化は「フォローは自由」である。誰かのブログRSSを購読するが如く、みんなが自由にフォローする。現に、俺のtwitterアカウントは、多くの「知らない人」にフォローされている。

というわけで、誰でもフォローしちゃえばいいんじゃね。誰をフォローすれば良いかわからない? ならばコレだ。全部いっとけw

http://java-ja.yoshiori.org/index.php?%E8%B3%9B%E5%90%8C%E8%80%85

このように、色々な人と日ごろから絡んでいると、実は1年ぶりくらいなのに久々な感じがせず、コミュニケーションも円滑に進むこと請け合い。

勉強会に出て話をしよう

さて、ちょっと敷居が高くなってきた。だが構えないで欲しい。なにも30〜60分のワンセッションを丸々担当しろと言う訳じゃない。それはもっと後の話でよい。

技術系の勉強会には、大抵最後に「ライトニング・トーク(LT)」と呼ばれるコーナーがある。1人5分程度の時間でサクサクと進んでいくセッションだ。時間は厳密に区切られていて、時間になるとドラが鳴り、途中だろうと何だろうと終了、というテンポの良い楽しいコーナーだ。

そしてテーマは何でも良い。技術の話を聴きまくった後、疲れた頭をリフレッシュさせるコーナーと考えても良いと思う。みんな思い思いの話をしている。自分の趣味の話、雑学、自己紹介。技術なんか一欠けらも出す必要ない。技術の話を面白おかしく話すのもアリ。

敷居が高くなりすぎる可能性があるので必須ではないが、お勧めなのは笑いをとること。可能ならば笑いを取りにかかる。内容は関係なく、とにかく笑いが取れればOK。仕事のプレゼンじゃないんだから、ふざけたってOKなのだ。*3

あわせて読みたい2009-07-05 - 人工無脳が作りたかった

もう人脈も出来ているので「どっかでLT枠ない?」なんて相談をすれば、話す場所はすぐ見つかるはずだ。

当然、喋ったら自分のブログにまとめておくとよい。slideshare等を使って、発表に使ったスライドも大公開しておく。

チャンスを掴もう

このような活動を続けていると、ひとづてで、たまにチャンスが舞い込んでくる。「××のコミッタにならんかね?」「○○で1セッション語ってくれんかね?」「△△について記事を書いてもらえんかね?」…。こんな話が舞い込んできたら、迷わず掴む。

いつのまにか、当初思い描いていた自分のビジョンに近いところに、もう居るのだ。

*1:あ、俺最近サボってるw

*2:自分から相手に向かった、一方的な「お友達」だがw

*3:そう、仕事プレゼンの練習にもなるよね。