トップ > ITS

日常の ToDo 管理を org-mode から Trello に移行した話

Life ITS Service

プロジェクト管理、文書作成、そして日常におけるタスク管理を org-mode でやってました。

blog.kondoumh.com

org-mode はプロジェクト管理や、文書作成ではすごくワークするのに日常のタスクは一向に片付かないという問題を抱えていました。

プロジェクトや文書執筆はそれなりに時間がかかる難易度の高いタスクの集合であり、タスク間の依存関係も複雑なので、パソコンに向かってじっくり集中して管理する必要があります。対して日常の ToDo は単純なタスクが多く、空き時間に優先度の高い順から片付けていくやり方が向いています。なので、モバイルでサクッと更新できる方が捗るんでは？と思いました。

org-mode はとても素晴らしいのですが、モバイル対応が進んでいません。公式アプリ MobileOrg や Android 専用 Orgzly がありますが、使いこなせず挫折しました。Emacs をスマホやタブレットで使うのは厳しいです(サーバに ssh で繋ぐ必要があるし物理キーボードがないと入力無理だし)。

org-mode 以外の GTD 的ツールにはほとんど馴染みがなかったのですが、ずっと前にサインアップしていた Trello を本格的に使ってみることにしました。Google Keep とかでもよいのかもしれませんが、Trello はあの Stackoverflow の Joel Spolsky 先生のプロダクトですし。

もちろん Android / iOS のアプリがあるので、Nexus 6P / iPad Air 2 にインストールしました。

Trello では、ボード - リスト - カード という3階層構造でタスクを管理します。ボードは Redmine などの ITS におけるプロジェクトに相当すると思います。カードがチケットに相当するタスク。

org-mode のテキストから Trello のリストやカードを作成して使い始めたのですが、なんか違和感が。

  • リストが横にしか並べられない (PC のブラウザだけでなく、縦に並べた方が見易いはずのスマホやタブレットでも)
  • カードはリスト間をドラッグ&ドロップで移動できるのに全然移動することがない
  • そして完了したカードはアーカイブするしかない

ここで、ようやくリストは、カードのカテゴリではなく、カード(タスク = チケット) の状態 (ステータス) として使うべきだったと気づきました。

org-mode からの移行時に、何も考えずリストをカテゴリ(チケットの種類)として使っていたのでした。Trello がかんばん方式を具現化したツールと知っていたはずなのですが。。ツール間のメタモデル変換が脳内でうまくできてなかったということでしょうか。

このツイートは、カードとリストを間違えていました。

スマホやタブレットでいつでも更新できるのはやはり便利です。思いついた時に ToDo を追加できるし、カードの並び順を優先度として表現してもわかりやすいですし。日常の細々としたタスクが整然と管理できるのは、職業柄か安心感がありますね。

Trello は JIRA で有名な Atlassian に買収されています。

japan.blogs.atlassian.com

課金すると色々な機能が解除される模様ですが、とりあえずミニマムなフリープランのままでも、個人の日常 ToDo 管理には十分機能してくれてます。

ということで、今更感ありますが Trello 使い始めたという話でした。

Redmine (3.1.0-0) から VisualSVN のリポジトリに接続

ITS

2015年8月18日現在、Stackoverflow 日本語版では Trac に関する質問0件、Redmine に関する質問16件。Qiita では Trac に関する投稿 98 件に対し Redmine に関する投稿は 487 件。つまり国内では Redmine が圧勝のようです。

ということで、今の開発現場では ITS として Redmine を採用することにしました。さようなら Trac ...

運用環境は、Windows Server 2012 R2 です。Windows Server 2008 と比べると格段にセキュリティに厳しくなっており、セットアップが面倒くさいという印象があります。> 2012 R2

bitnami から、Windows 版インストーラーをダウンロード。使用する VCS は Subversion ですが この際 Git とかも全部入りでインストールしました。

無事インストールが完了し、プロジェクトの作成とかユーザーの追加とかは滞りなくできたのですが、プロジェクトで使用することになっている既存の SVN リポジトリに繋ごうとすると

リポジトリにエントリ/リビジョンが存在しません

というエラーがでてしまいます。ログを見ると 404 で リポジトリ情報が取得できていません。どうやら SVN サーバーでは VisualSVN というのを使っているようです。VisualSVN 寡聞にして知りませんでした。リポジトリは SSL/TLS で自己証明書により公開されており Redmine を導入した Windows Server 側で証明書の信用ではじかれているようです。

ぐぐると subversion_adapter.rb の修正が必要という FAQ にヒットしました。

¥¥apps¥redmine¥htdocs¥lib¥redmine¥scm¥adapters¥subversion_adapter.rb

を開き、以下のように修正。

修正前
   str << " --no-auth-cache --non-interactive"
修正後
   str << " --trust-server-cert --no-auth-cache --non-interactive"

しかしこれだけでは、繋がりませんでした。VisualSVN サーバーのレジストリ変えたり、HTTPS 諦めて、HTTP で繋ぐように VisualSVN 側の設定変更するという記事が多かったのですが、今回は SVN サーバーに変更を加えるわけにはいきません。そこで単純に VisualSVN の自己証明書を Redmine の Windows Server 2012 R2 にインストールしてみたところあっさりとリポジトリの内容を取得できました。

証明書のインポートウィザードで簡単にインストールできました。

今回、Git もインストールしておいたので、MinGW 環境が使えて、 tail -f でログ見たり、Vim で Ruby スクリプトファイルを書き換えたりが簡単にできて助かりました。SVN オンリーの時でもインストールしておいて損はないです。

Trac 不定期通信5 シンプルさを維持する

ITS

Trac や Redmine のような ITS も一般的な業務アプリケーションと捉えると、開発という業務にマッチした入力画面を定義し、ユーザーである開発者にデータをエントリーしてもらうものです。例えば販売システムの受注データに相当するのが チケットと考えればいいでしょう。

チケットのクエリーで作られる各種レポートは、開発業務の状況を把握し意思決定に用いるための帳票です。正確なレポートを得るためには、入力項目を開発者が使いやすいように設定して精度の高い情報を登録してもらうことが重要です。

どのような入力項目が相応しいかは、開発チームの志向性やプロジェクトの状況によってかなり異なるというのが実際のところです。同じ業種の業務アプリケーションでも企業によって入力画面の仕様が異なるのと同じです。また、チケットの状態遷移は、開発の業務フローを反映しています。これもまたチームやプロジェクト事情で決まります。

さて、Trac はもともと(紙やスプレッドシートで Issue 管理するような)古びたやり方で開発をしているチームに最低限の支援をするという目的の元に開発されました。素の状態でも開発にまつわる問題の追跡には十分役立つだろうという入力項目とチケットフローが備わっています。逆に言うと、Trac で標準的に提供されているレベルの管理を実施していないプロジェクトは危険な道を突き進んでいると言えるでしょう。

ITS を導入する前に、その設計思想や想定している開発フローなどと現状を比較して見るのがよいでしょう。業務パッケージを導入する際、自社の業務との Fit/Gap を分析して評価するのと同じですね。自チームのやり方(自社業務のやり方) をパッケージに合わせるのか、パッケージをカスタマイズするのか。 導入までにユーザー検証を経て、既存のやり方を調整して・・・と真面目に考えるとかなり手間暇です(まあ、ITS は所詮ツールなのでそこまで大変じゃないですが)。

だからチケットにあれもこれも入れようとしてカスタムフィールドを追加しまくったり、Issue 解決までに多段階の承認ステータスを作ったりして頑張ろうとすると残念な感じになることが多いです。エントリーする開発者の負担ばかりかかってタイムリーに情報が登録されなくなり、プロジェクトの状況把握を行えなくなって行きます。
人間は自覚しているより遙かに怠惰な生き物です。シンプルこそが継続性の源泉です。そして継続性はプロジェクト成功の必要条件です。

Trac 標準の項目だって思い切って捨ててしまってもよい場合があります。優先度の調整とかイテレーション開始時の計画でやってしまえば、チケットの優先度がわりとどうでもよくなったりします。不要なフィールドであればデータを消してしまいましょう。Trac では優先度でもコンポーネントでも、データの入っていない項目は表示されなくなります。用途不明のフィールドなどノイズでしかありません。分かりやすさを第一義にしましょう。

シンプルさを保つには用途に応じて Trac プロジェクトを変えるようにするのがよいでしょう。多目的な用途には Trac はシンプルすぎます。Trac プロジェクトを跨るチケットは InterTrac リンク機能で関連付けることが可能です。機能追加・仕様変更管理用やバグ管理用などプロジェクト局面に応じて適宜追加して行くと良いでしょう。

Trac 不定期通信4 TicketQuery 記法を活用する

ITS

久々の Trac 本ネタです。

Trac のレポート機能というと、カスタムレポートやカスタムクエリで作るものと思っている人が多いと思います。確かに色々な用途でレポートを作り公開することは有効ですが、作りっぱなしで活用されないことも多いです。開発真っ最中のチームメンバーがわざわざレポートを見に来てくれることを期待するのも望み薄だったりします。


レポートではなく、よく閲覧されるWiki ページに、ページ内容にマッチしたチケットリストを埋め込んでおくのです。そうすれば閲覧の頻度が上がりチケットへの関心が高まります。 Wiki にチケット一覧を表示したい時は TicketQuery という記法が使えます。カスタムクエリで実現できるレポートはそのまま Wiki に埋め込むことができます。Wiki ページにレポートへのリンクを埋め込むという方法もありますが、やはりワンクリックが必要となり、ダイレクトなアクセスという点では劣ります。

TicketQuery を使うとリリースノートも簡単に作成出来ます。

Wiki ページにすんなりと表示されていい感じですよね。

リリースノート用の TicketQuery サンプルです。そのまんまですね。

[[TicketQuery(milestone=2.0リリース,type=機能追加|仕様変更,status=closed,resolution=対応
済,col=summary,format=table)]]

Issue をチケットで管理することで、One Fact In One Place (1つの事実は1か所) の管理ができます。さまざまな観点でのビューを用意することで開発の状況を可視化しやすくなります。システム屋だったらアタリマエのことですよね。Excel シートなんかで管理してると進捗報告用にマクロ組んだりしないといけない。バカバカしすぎ。Excel に執着するそこのあなた。Excel は表計算ソフトです。問題管理ツールではありません(もちろんワードプロセッサーでもありませんよ)。

Trac 不定期通信3 TracNav を使い倒す

ITS

TracNav は古くからあるプラグインです。

プロジェクトの Wiki ページには、作業手順などチームメンバーで共有すべき内容が書かれ、どんどんページが増えていきます。有用なページでもメンバーによってはその存在を知らなかったりしますし、情報の鮮度や有効性が失われ、いつの間にか忘れ去られて埋もれてしまうものあるでしょう。でも、常にメンテナンスすべきトップレベルのページがいくつかあるはずです。Trac の Wiki トップページはプロジェクトのポータルであり、ここに出来る限りの情報を集中させることが情報共有の第一歩です。TracNav は階層付きリストで Wiki ページヘのリンクを作りページの右側に配置できます。

ページヘのリンクの他にも以下のようなリンクがあるといいでしょう。

  • チケットのレポート(障害/タスク/課題)
  • Chekstyle, FindBugs などソースコードの静的分析レポート
  • 必読なドキュメント
  • ソースコードの JavaDoc
  • Maven Inhouse Repository などデプロイされた成果物
  • リリースノート

TracNav はトップページにかならず設置しておき、主要ページにも設置しておくとよいでしょう。スクロールしなくても見渡せる範囲に情報を集中させることが大切です。どんな人でも最初に入ってくる情報に一番注目するものです。だから知っておいて欲しい情報から並べていくのがいいです。TracNav は任意ページの箇条書き情報を指定できます。箇条書きのネストを利用して情報をカテゴライズするようにしましょう。

Trac 標準のマクロである PageOutline も ページ内の見出しで目次を生成し、TracNav のようなセクションを表示してくれますが、TracNav の表示位置と競合してしまいます。ですので、PageOutlline マクロに inlie を指定して、本文ページに埋め込むようにするとよいでしょう。

さて、Wiki に情報を集中させてもそれだけでは十分ではありません。朝会でアナウンスしたり、メールでもアナウンスしたりすることはもちろん必須です。開発者はメール読まないし朝会に遅刻してくるやつもいます。とにかく全員に染み渡らせる手間を惜しまないようにしましょう。

Trac 不定期通信2 Jenkins ビルドジョブ推移グラフで Wiki を CI ダッシュボード化

ITS CI

CI を健全な状態に保つことは、コードの品質維持や問題発生時の迅速な対応には欠かせません。

CI の状態をチームに通知するには、ビルドがコケた時にメールが飛ぶとか Trac のタイムラインにビルド結果を流すとかいろいろありますが、イベントドリブンになってしまうので見ない人は見ないです(スパム的に無視する)。[改訂] Trac 入門では、プロジェクトのポータル(Wiki)に Jenkins ビルドジョブの ビルドの推移 グラフを貼るという Tips を紹介してます。CI のトレンドを全員で常に監視してるような状態になって平時でも CI を意識してもらえます(それでも見ない人は見ないですが)。

今私がいるチームでは複数のモジュールを開発・保守しています。ブランチとか結合テストなどを含めるとビルドジョブの数は20個近くになるのですが、trunk で開発が進行している5,6個のビルドジョブに関しては、ビルドの推移を Wiki のトップページで一覧できるように、小さめにリサイズして並べて表示するようにしています。
チームで開発しているモジュールの CI トレンドが、ブラウザーを起動するだけで分かるため、チームメンバーの気づきが早くなり対応着手までのリードタイムが短縮されます。

モジュールのテストの数も開発が進んでいくと1000 のオーダーになるので、10個ぐらいテストがエラーになってもトレンドグラフで目立った変化が出なくなってしまいます。エラーだけを表示にしておくと、エラーが1，2個でもめちゃ派手なグラフになって、メンバーが CI のエラーに敏感になってくれる効果があります。

[[Image(http://jenkinshost/job/hogemodule/test/trend?failureOnly=true, 300px,link=http://jenkinshost/jenkins/view/hogeteam/job/hogemodule/)]]

上記の例では、hogeteam の hogemodule のビルドの推移グラフをエラーのみ表示で横幅300ピクセルで表示し、グラフのリンク先に Jenkins のビルドジョブのページを指定しています。

推移グラフではテスト前のコンパイルが失敗した場合は何も表示されないので注意が必要です。

Trac 不定期通信1 イテレーションはマイルストーン？

ITS

改訂 Trac 入門も無事発売になったことですし、不定期に Trac ネタを書いていきたいと思います。

今回は、イテレーティブ(繰り返し型)開発におけるイテレーションの扱いについて。

業務アプリ開発でも 1-2 週間という短めのサイクルでタイムボックスを区切るイテレーション(Scrum だと スプリント) を導入している現場はけっこうあるのではないでしょうか。イテレーション終わりに最終顧客に対する出荷を行わないまでも、チームの生産性や品質を短いスパンで見直し改善策を講じたりできるというメリットがあります。

ところで Trac でイテレーションを扱う時ってマイルストーンで管理するでしょうか？

1チームですべての開発が完結している場合は、マイルストーンでもよいと思います。ですが、ある程度の規模のプロジェクトで複数チーム連携して開発を進める場合、チームのイテレーションとプロジェクトのマイルストーンは分けて考えた方がよいでしょう。

例えば、フレームワークや共通部品を提供するチームが先行して組織されてアプリ構築の基盤を構築し、その後アプリチームがイテレーションを開始して個別の業務アプリを構築するような場合、各チームの成果物を結合してテストやユーザー受け入れ試験に向けて出荷していくことになります。

各チームは作っているものこそ違えど、プロジェクトで設定されたイベントに向けてコードを書きテストを重ねて行きます。チームのイテレーションはタイムボックスであり、プロジェクトのマイルストーンと違ってチームの裁量が効くものです。開発対象の機能は他のチームの計画にも影響しますのでプロジェクトで決定された期日には間に合わせる必要がありますが、どのイテレーションで作業するかということは各チームの事情で決められるケースが多いはずです。

ですのでプロジェクトのマイルストーンをマイルストーンで扱い、イテレーションは専用のカスタムフィールドで扱うとプロジェクト全体の観点とチーム都合の観点に分離してスコープの管理ができるのです。