自分のできること、好きなこと、やりたいこと。


プログラミング言語は主にJavaとRuby
最近は少しずつ関数型言語も学習中。Smalltalkには憧れるがJavaScriptにはどうも馴染めない。

個人的にWebアプリをつくるのが好き。GAE/J + GWTで個人的な家計簿アプリなどをつくって楽しんでいる。

TDDはJavaというかJUnitしかできない軟弱者。CIは他人がJenkinsを動かしてるのを眺める程度。興味がないわけではないが積極的に推進してくれる人がいるので任せてる感じ。

開発プロセスが好き。というか無駄のあるチーム作業が嫌い。個人は暇を持て余すべきだがチームが時間を持て余してはならないと考える。

効率的な開発を進める補助としてツールを使うのが好き。ツールは少しの操作で大きく広範囲に使用できることが望ましいと考える。
逆にルールとして存在するツールは多くの場合、効率化の弊害になるのではないかとも考えている。

ツールができることの意味と実際の開発にマッチさせるためにはどうすればよいのか、と考えることが好き。

より少ない手間で大きなことができるのがソフトウェアとインターネットの存在価値だと考える。

今の会社ではRedmineをすすんで導入してきた。ツールを使うことで得られること、そしてツールを使う人がそのツールにどのような期待を抱くのか、について経験を得られた。

それとともにRedmineを使ってできることの限界も感じはじめた。ツールを使わされている側の人にとっては諸々の入力作業なとが手間にしかならないこともあるし、そもそも何のために使ってるのか考えない人も多い。

その経験を踏まえた上で、ぼくはツールを作り、開発の効率化に貢献したいと思う。
自分が考える最強のALMをつくってみたいと思う。

そんなことを思う、最近です。

Issue Tracking Systemの利用パターン

redmine

ツールは手段です。ツールを使用するには目的が伴うのが普通です。
本記事では目的に応じたIssue Tracking Systemの使い方を示したいと思います。

Issue Tracking Systemを導入する目的

Issue Tracking Systemを導入する目的はなんでしょう？

  1. 要件を管理したい
  2. タスクを管理したい
  3. 報告書の元ネタにしたい
  4. 情報を共有する場にしたい
  5. 進捗を管理したい
  6. 課題を管理したい

いろいろ挙げられると思いますが、ここでは次の3点に絞ります。

  1. 要件管理
  2. 要件 + タスク管理
  3. 課題管理

順番に見ていきます。

その前に前置き

要件という用語はユーザーストーリーとして置き換えてもらっても構いません。
ざっくりと次のようなイメージをしてもらえば良いでしょう。

要件(ユーザーストーリー)
お客さん*1が望んでいること、お客さんに提供する価値
タスク
要件を実現するためにすべきこと、TODOと言い換えても可

もうちょっと前置き

向いているツールに(?)がついてるのは使用経験がないので憶測で書いています。*2
フィードバックがあれば歓迎しますのでお願いします。

「要件管理パターン」

プロジェクトの要件だけを管理するパターンです。
詳細なタスクまではチケットにしません。

文脈
  • 要件の変更が激しい
  • タスクが細かすぎる
  • 具体的な作業はアナログで管理したい
解説

タスクが細かすぎてチケットを作成するコストが高くなってしまう場合に有効です。
要件の変更、追加などに対応するため、1つ1つの要件は比較的小さくなるでしょう。
作業のトラッキングはリポジトリのコミットコメントなどを活用します。Redmineのようにチケットとコミットを関連付ける機能を持っているツールであると助かります。

メリット
  • チケットにかけるコストが低い
  • 工夫次第で様々に管理できる
  • 要件しか乗らないのでお客さんとのやり取りにも使いやすい
デメリット
  • タスクが漏れる可能性がある
    • (漏れても気づかないリスク)
  • ツールを見ただけでは要件のステータスを把握できない
向いているツール
  • Pivotal Tracker ◎
  • JIRA (?)
  • Redmine+Backlogsプラグイン(タスクボードは使わない) ○
  • Trac (?)
  • TFS (?)
  • Backlog △

「要件 + タスク管理パターン」

要件とタスクを管理するパターンです。

文脈
  • やることが詳細まで決まっている
  • 作業を抜け漏れなく管理したい
解説

要件はタスクから積み上げられるためざっくりとした題名になりがちです。そのため要件のチケットを終了させるタイミングが難しく、誰のどういう判断基準によって終了と見なすのかチーム内でしっかりと合意する必要があります。
タスクはすべてチケットになっているため外部の人が見た時も状況把握の手助けになります。あとどれだけの作業が残っているのかもメンバー間で認識しやすくなります。*3
またデジタル上でタスク管理する利点として、バーンダウンチャートなどを自動で作成してくれるツールも活用できます。
ちなみに要件とタスクは階層関係になるためチケットも親子関係で作られることが望まれます。*4

メリット
  • 作ったタスクが漏れることがなくなる
    • アナログだと消えたり忘れられたりどこかに飛んでいってしまうリスクがある
  • バーンダウンチャートなどツールによる支援も活用できる
デメリット
  • チケットを作成してメンテナンスするコストが高い
  • 要件を終了させるタイミングが難しい
  • 1つ1つの要件が大きくなりがちなため要件間の重複が発生しやすい
向いているツール

「課題管理パターン」

課題を管理するパターンです。一般的にバグトラッキングと言えばこの使い方になります。
課題と書きましたが障害やバグと言い換えても良いでしょう。

文脈
  • バグをワークフローに沿って管理したい
解説

上述の2パターンと比較すると目的はより明確です。
1つ1つのバグを記録し、解決するためのワークフローを提供します。

メリット
  • 目的が明確であるためツールを選ばない
  • バグを記録するだけなのでチケットの粒度に悩まない
デメリット
  • ツールが多すぎて迷う
向いているツール
  • JIRA (?)
  • Redmine ○
  • Trac ○
  • Mantis (?)
  • Bugzilla (?)
  • 影舞 (?)
  • Backlog (?)

「要件管理パターン」と「要件+タスク管理パターン」の関係

「要件管理パターン」はタスクの管理をアナログな方法によって解決することが期待されます。アナログな方法はチームの工夫次第で様々な取り組みをしてよいでしょう。
一方で「要件+タスク管理パターン」はデジタル上でタスクを管理することにより、確実なタスクのトラッキングを可能にします。Issue Tracking Systemと銘打つツールですからトラッキングは重要な要素です。厳密に1つのタスクも取りこぼせない詳細な管理をしたい場合は「要件+タスク管理パターン」が有効でしょう。

パターンの組み合わせ

おそらく「課題管理パターン」はどのプロジェクトでも必須だと思われます。
そのうえで、必要に応じて「要件管理パターン」もしくは「要件+タスク管理パターン」を組み合わせるようになるでしょう。

まとめ

冒頭にも書きましたがツールは手段です。目的に応じた使い方をみなさんそれぞれで考えてみてください。
Enjoy!

*1:もしくはユーザー

*2:というかRedmineしか使ってないユーザーの主観なのでアテにしないでください

*3:要件管理パターンの場合はこれをアナログなタスクボードによって解決します

*4:またはそれに類する関係

Redmine(or Trac or yet another ITS)でスケジュールを管理するのは有効か？

redmine

有効ではないと思ってます。

〜 これが正解だとは思ってませんが以下、個人的に思ってることを書きます 〜

Redmineでは標準でガントチャート機能があってチケットの開始日、終了日にあわせてチャートを作ってくれます。初めてRedmineを見る人は、「これを使えば進捗管理ができるんじゃないか？」と思うことでしょう。ぼくも思ってた時期がありました*1。
しかし、実際にチケットをWBSみたいに運用するのはそれなりの労力を求められます。
なぜでしょうか。

  • スケジュールに変更が起こった時のメンテナンスコストが高い
  • 開始日、終了日を簡単に変えられるUIではない

メンテナンスに時間を取られることももちろんですが、日付を変える作業のめんどくささが半端なくてRedmineを使うのが精神的苦痛になります*2。個人的にはMS ProjectのUIでも満足できていません。(使いこなしてないだけなのかもしれませんけど)

そもそもスケジュール管理って？

そもそもスケジュール管理って何をするためのものなのでしょうか？「計画した通りの進捗であることを制御する」ことが目的であるのなら管理するポイントをマイルストーンとして置けばいい話です。
イテレーション開発をしているならイテレーションごとの期日だけを見ていれば十分なのでチケット(タスク)ごとの期日などどうでもよいはずです。ウォーターフォール開発についても同様で、外向けのスケジュールと打ち向けのタスクは乖離するのが日常なのでチケットの期日にこだわってたらいつまでたってもタスクを終了にできません。
そもそもスケジュールを管理するのは誰の責任なのか？チャートの日付と進捗を見るのをスケジュール管理として扱うことが本当に適切なのか？今一度考えてみるべきではないでしょうか。

Redmineを有効な使い方

  • 要件管理
  • タスク管理
  • 課題管理
  • 情報共有
  • 作業時間管理

要件管理だけをするならPivotal Trackerが最適かもしれません。タスク管理だけをするならアナログのホワイトボードや付箋が良いかもしれません。
その他、情報共有したり作業時間の分析をしたりとトータルな管理をするのにRedmineは向いてると思います*3。

まとめ

ソフトウェア = 少ないコスト → 最大限の効果

が成り立つのが人がソフトウェアを使う大前提であるべきなので、コストが必要以上にかかってしまうスケジュール管理はRedmineには向いていない、というのが(現時点での)ぼくの意見です。

*1:2,3ヶ月くらい

*2:ならない人には向いてるかもしれませんね

*3:別にRedmineじゃなくてもTracでもなんでもいいですが

アジャイルサムライ #agilesamurai

agile

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

レビュアーとして

僭越ながらレビュアーの一人として参加させて頂きました。錚々たる面々の中で自分ができることをしたつもりです。
レビュアーを選ぶときに、それぞれの切り口を期待してレビュアーを選考されていたみたいですが、自分がどういう役割で選ばれたのかは謎のままでした。

内容について

監訳者・レビュアーの方々含めて多数の記事が上がっているのでそちらを参考にされた方が適切かもですが。内容としてはアジャイルなソフトウェア開発の概要から実践的な例までコンパクトに解説しています。
「アジャイルってなに？」という方は迷わず本書をお取りいただいければ、と思います。

本書で大事だと思うところ

  • なにより顧客へ継続的に価値を届けることがアジャイルだと説いていること
  • ユーザーストーリーの完了とは即ちリリース可能な(=お客さんに価値を届けられる)状態を意味するということ
  • アジャイルであることが大切なのではなく、プロダクトを素早く継続的にお客さんに届けることが大切であるということ*1

レビュー概要

  • @ryuzeeさんのスタートダッシュ
  • WACHIさんのレビューはチート(翻訳者の一人に名前を入れてもいいんじゃないかと思うくらい)
  • @kakutaniさんはカンフー・パンダが好き
  • 後半に@miholovesqさん(松井世代)が覚醒
  • 最後の最後の方で素敵なコラムが追加
  • 監訳者あとがきにみんな感涙*2

オーム社さんの執筆システム

詳細はこちらをどうぞ http://www.geekpage.jp/blog/?id=2008/1/16
レビュアーとしてはビルドされたpdfをダウンロードして読み込んでフィードバックするだけなのですが、それでも生原稿がどんどん改版されてリビジョンがあがっていくのを見てると、すごくワクワクさせてもらうことができました。貴重な体験でした。

ということで良い本です

買って損はしない本です。ホントは自分がフィードバックした箇所を逐一あげて自慢したいのですが、そんなことをしてこの本の価値が下がったら困るのでしません。
見かけたら手にとって読んでみてください。アジャイルについてわかった気になれると思います。わからなかったとしてもあなたのソフトウェア開発にかける情熱を失わないでいて欲しいと思っています。

from a heartful Redmine user.

*1:メタプログラミングなんてない！すべてはプログラミングだ！に通じるものを感じますね

*2:推測

Redmine Mail Intergration plugin

redmine

前置き

「Redmineがメール受信」という表現はRedmineが稼働しているサーバ上で"rake redmine:email:receive_pop3"を実行したときだと解釈してください。

背景

Redmineにはチケットが更新されたときなどにメールで通知してくれる機能があります。さらにその通知メールに返信することで注記を書けたりします。
さらには、Redmineのメールアドレスを宛先に含めておくだけでRedmineがメールを受信してチケットにできる機能もあります。
いろいろ便利な機能がそろっているのですが、うちの会社の使い方ではちょっと痒いところに手が届きません。

なにに困ってるの

マネージャ「お客さんからこんなこと頼まれたんだけど、Aさんこの作業お願い！」
とお客さんからの依頼をAさんのメールアドレス宛にRedmineのメールアドレスをCCに入れて転送しました。*1
Redmineはメールを受信してチケットに起こして通知メールを投げます(投げったっけ？)。

Aさんが受け取ったメール

この時点でAさんはマネージャからのメールとRedmineからの通知メールを受け取っています。
AさんがRedmineからの通知メールに返信すればRedmineは注記として処理できます。しかし元々のマネージャからのメールに返信すると、Redmineは返信元のチケットを特定できないので、新たにチケットを作成してしまうのです。注記にできないどころか無駄なチケットが作られてしまいます。困りました。

そこで作ったプラグイン

Redmineがメール受信したときにメールのMessageIDと処理したチケットNoを覚えておくプラグインを作りました。
この場合でいうと、最初にマネージャが投げたメールを処理したときにMessageIDとチケットNoをDBに保存します。
そしてAさんからの返信を受信したときに、メールのin-reply-toからMessageIDを検索して処理元のチケットを特定します。

まとめ

これでRedmineを意識できない人でもとりあえず宛先にRedmineのメールアドレスを含めておいてもらえば、チケットに履歴が残っていってハッピーになれるかもしれません。

試してみたいかたはこちらから

https://github.com/YusukeKokubo/redmine_mail_intergration
注意点としてはまだ稼動実績がないのでちゃんと動くかあやしいところ…かな。

*1:本来ならこの時点でRedmineにチケットとして作れよ、という話ですが

Redmine Backlogsプラグイン カスタマイズ

redmine backlogs

うちの会社用にカスタマイズしてるのを公開してます。興味あったら試してみてください。
https://github.com/YusukeKokubo/redmine_backlogs

ざっくりとしたカスタマイズのポイントとしては

Task Board

  • タスクの移動時に注記を入力できるようにした
    • 本当はwindow.promptじゃなくてちゃんとしたポップアップを作りたい
  • 終了してるストーリーとステータスを背景色でわかるようにした
  • アバターを表示
  • タスクの入力項目から優先度を削除して代わりに予定時間を追加
  • 終了したタスクは溜まると縦に長くなるのでギュッと表示するようにした
  • 担当タスクのフィルタリングをできるようにした

Master Backlog

  • Backlogs管理外のトラッカーのチケットもMaster Backlogから参照できるようにした
  • ストーリーのステータス選択の選択項目はプロジェクトに設定しているトラッカーに紐づくステータスのみにした
  • 活動画面をiframeで表示するようにした
  • Wikiをiframeで表示するようにした

時間入力

  • remaining_hoursを作業時間の入力によって減算するようにした
    • デフォルトだと終了にしたときに自動で0になる
  • ストーリに作業時間を入力できないようにした
    • タスクのみ入力可
  • 作業時間の入力が注記として残るようにした
  • ステータス移動時の予定時間の入力を必須にした
  • 「新規」のステータスでは時間入力できないようにした

その他

  • redmine_yojitsuをマージ
    • Master Backlogのメニューにもこっそりリンクを追加

箇条書きしてる分、薄い印象になってしまいましたが、一個一個が面白い試みなのでよろしければどうぞ。

(漱石の夢に出てくる)運慶から学ぶオブジェクト指向プログラミング

tech OO

前振り

オブジェクト指向が何なのかという議論はいたるところで語られますが、元祖となるアラン・ケイのオブジェクト指向であったり、派生したすっぽすっぽ先生の抽象データ型のオブジェクト指向であったりと定義からしてゴチャゴチャしてなかなか収束しないことが多いです。
そもそも「オブジェクト指向」という言葉なのになぜか「クラス」が主役かのように語られることが多いのが疑問です。大切なのはクラスではなく実体化されたインスタンスでありオブジェクトであるはずです。クラスはあくまでもオブジェクトの1つでしかありません。
(メタプログラミングは置いといて)クラスはどれだけ頑張っても静的な情報しか持てないので、そこから個々のオブジェクトがどう連携してメッセージをやり取りしているかをイメージできるか、プログラミングできるか*1が1番重要であるはずです。

オブジェクトとは何か？

オブジェクトとはなんでしょうか？プログラマが作りだすものでしょうか？あれやこれやと設計書をもとに作られるものなのでしょうか？
昔はぼくもクラスやオブジェクトはプログラマやモデラーが頑張ってクラス図とかUMLを頑張って書いて作りだすものだと思っていました。
しかし最近はちょっと違った考え方を持っています。
オブジェクトはただ、そこに存在しているだけなんです。

オブジェクトはどこにいるの？いるなら手を振って欲しい

オブジェクトが存在しているといってもどこにいるのでしょうか？それはプログラマの目の前です。今目の前に写っている画面にこそオブジェクトは存在します。
あなたが今「プログラミングしよう！」と思ったその瞬間からオブジェクトはそこに存在するのです。オブジェクトは作るものではなく掘り起こすものなのです。

そこで運慶登場

漱石の短編小説「夢十夜」に明治時代に蘇った運慶の話がでてきます。
( なんと青空文庫で公開されてました。http://www.aozora.gr.jp/cards/000148/files/799_14972.html )

　しかし運慶の方では不思議とも奇体ともとんと感じ得ない様子で一生懸命に彫っている。仰向（あおむ）いてこの態度を眺めていた一人の若い男が、自分の方を振り向いて、
「さすがは運慶だな。眼中に我々なしだ。天下の英雄はただ仁王と我（わ）れとあるのみと云う態度だ。天晴（あっぱ）れだ」と云って賞（ほ）め出した。
　自分はこの言葉を面白いと思った。それでちょっと若い男の方を見ると、若い男は、すかさず、
「あの鑿と槌の使い方を見たまえ。大自在（だいじざい）の妙境に達している」と云った。
　運慶は今太い眉（まゆ）を一寸（いっすん）の高さに横へ彫り抜いて、鑿の歯を竪（たて）に返すや否や斜（は）すに、上から槌を打（う）ち下（おろ）した。堅い木を一（ひ）と刻（きざ）みに削（けず）って、厚い木屑（きくず）が槌の声に応じて飛んだと思ったら、小鼻のおっ開（ぴら）いた怒り鼻の側面がたちまち浮き上がって来た。その刀（とう）の入れ方がいかにも無遠慮であった。そうして少しも疑念を挾（さしはさ）んでおらんように見えた。
「よくああ無造作（むぞうさ）に鑿を使って、思うような眉（まみえ）や鼻ができるものだな」と自分はあんまり感心したから独言（ひとりごと）のように言った。するとさっきの若い男が、
「なに、あれは眉や鼻を鑿で作るんじゃない。あの通りの眉や鼻が木の中に埋（うま）っているのを、鑿（のみ）と槌（つち）の力で掘り出すまでだ。まるで土の中から石を掘り出すようなものだからけっして間違うはずはない」と云った。

わかりましたでしょうか。オブジェクトは創りだすものではなくて彫り出すものなのです。
余計なことをゴチャゴチャ考えずにあるべき姿をイメージできるかがオブジェクト指向プログラミングの肝なのです。

えっそんな芸術的なことを言われてもわかりません！

ですよね。ぼくもわかりません。
でも「芸術だ！」って言われるとあまりにも途方過ぎて、返ってそんなに難しく考える必要もないかなって気が楽になりませんか？
少なくとも、プログラミングを助けるためのツールであるはずの概念に囚われて試行錯誤するよりもよっぽどかマシなんじゃないかとぼくは思ってます。

*1:そしてそれはプラガバルであるか？ http://d.hatena.ne.jp/coolstyle/20101223/1293120737