1. Redmine
Issue Importerの改造
∼ Lotus Notesからの移行 ∼
∼ あるいはRedmineマスターへの道 ∼
町井 昌徳（まちいまさのり）@tech_machii
豊福 親信（とよふくちかのぶ）@nobu_toyofuku
2012年5月19日

2. なぜこんなことを？
社内でRedmineを使っていれば，いずれこの種
の話は出てくる．
どんな会社でも「ベンダーロックイン」シス
テムがあるだろうが，昨今のITコスト削減圧
力がOSSへの転換を促している．
（私はデフレと言いたい！）

3. Redmineへ移行の是非
多くの会社でそうだろうが，塩漬けになってる
Lotus Nosteの代替としてRedmineを使えるかもし
れないと思い，2011年度から調査を始めた．
Redmineは「中途半端に」万能？といえる面を
持っているので，すぐには結論が出なかった．

4. Lotus NotesからRedmineって
簡単なの？
はっきりいって，無謀である．
「業務の本質」を正しく実装していない場合が多
い．設計書が無い場合も多く，リバースエンジニ
アリングが困難．
要するに，業務が「 チケット駆動型」タスクマネ
ジメントであるか否か？が ．

5. ...でもやてみた...
Redmineの発展に寄与するだろう！
（社内でRedmineマスターに認定されるかも？）
iPadでも使えて便利！
（使えるのは当たり前だけど，まだまだ社内システムはこんなもん）
でも，山あり谷ありだった．

6. どんな山谷があったの？
∼ 人編 ∼
「なんとなく業務システム」が多く，移行後の仕
様をなかなか決められない．
（社内システムには手抜きが多くて...）
（Notesの原価を気にしない）利用者には「チケッ
ト駆動型」をはじめて目にする人もいて，すごく
抵抗する．
(これがあとあと，Redmineの改造につながっていく...）

7. どんな山谷があったの？
∼ 技術編 ∼
Notesで運用中のシステムの設計書類がない．
（社内システムには手抜きが多くて...）
（設計書を起こさなくてもそこそこ使えるものができる，というのはある意
味，ロックインしたいベンダー側にとっては都合がいい）
【例】Notesデータをエクスポートしてはみたものの，画面で見えている以
上の項目が出力される．画面部品とデータ属性を対応付ける情報がなく，つ
まり「ロゼッタストーン」に相当するものがなく，「暗号解読」が困難，つ
まり多大な「試行錯誤」を要した．

8. データ移行の概略図
②属性項目の対応付け
（人手）
Redmine
Notesデータベース
生な 必要最小限な
中間ファイル 中間ファイル ISMS関連
ISMS文書 XML CSV
＋複合文書
契約関連
賃貸契約 変換 画像ファイル
画像ファイル
PNG
WMF
添付ファイル
Excel,
Word,
etc.
①ツールによる抽出 ③ツールによるインポート
SharePont
Converter （自製ツール）

9. 技術編の山谷を解決する
エクスポートしたデータをCSVにし，それをイン
ポートする方式にすれば，何度でも「現場合わ
せ」ができる．
CSVの状態で文字列処理するのが，安い［現場合わ
せ」である．しかし...
...予測がつかない文字列への対応などで，Issue
Importerの改造が必要になってくる．

10. 添付ファイルのインポート
Notes文書IDとMS SharePoint Converter出力ディ
レクトリ名が（チケット本文中で）結びついてい
るので，比較的簡単．
文字コードの違いに起因するリンク切れは
grep attachmennt:
で検索する．
イメージ画像WMF(Windows Meta File)はGcon.exe
でPNGへ変換．（これが一番良い，階層化フォルダを指定できる）

11. Redmine本体の改造
MySQL の64Kバイト制限を解除するために，
migrateファイルを変更．
- t.column "description", :text
+ t.column "description", :text, :limit => 1.megabytes
- t.column "notes", :text
+ t.column "notes", :text, :limit => 1.megabytes
カスタムフィールドでも追加ボタン付きリスト型
を実現．
「&[]()@」を含む添付ファイル名称へ対処．

12. Issue Importerの改造
ようやく本題m(_ _;)m
エラー発生時に，その原因／箇所も表示させる．
（ただし最初のエラーだけ）
日付型カスタムフィールドは "YYYY-MM-DD"形式
のみ許していたので，Date.parse が解釈できる形
式 ならば許すようにした．
【例】 "YYYY/MM/DD" や "YYYY/M/D" など

13. Issue Importerの改造
（２／５）
チケットの作成日をインポートした日ではな
く，CSV内に記述した日とする．
履歴の作成者と作成日がインポート可能．
（オリジナルは履歴の内容だけ）

14. Issue Importerの改造
（３／５）
Redmineへ登録済みのアカウントに対応する氏名を
データとしてインポート可能．
（「東京 太郎」とか「太郎 東京」，姓と名の間はasciiスペース）
登録済みアカウントに無い氏名はエラー表示．
（オリジナルでは，インポート実行者のアカウントが作成者になる）

15. Issue Importerの改造
（４／５）
インポート時に自動的に追加する．
（オリジナルではエラーとなる）
インポート前のチェック機能
として，空カラム名を追加．
（オリジナルはほとんど機能を有せず，
サーバーエラーとなる）

16. Issue Importerの改造
（５／Ｅ）
インポート側「カテゴリ」が当該プロジェクトの
「カテゴリ」に対応しないバグを修正．
（オリジナルでは，複数プロジェクトを有するRedmine内で，最初に見つかっ
た「カテゴリ」を対応付けていた）
履歴が一つしか登録できないバグを修正．

17. 感想
「矢でも鉄砲でも持って来い！」ってぐらい，
Redmineの改造に自信がつきました（*^_^*）
タスクマネジメントの観点から，あらゆる業務を「観
察する目」が養えました．（協働者の次は社内教育へ）
この「観察眼」で新バージョン1.4の特徴を見ると，
Ruby on Railsの先進的なOSS例として，今後の
Redmineの発展が期待できるような気がしてきまし
た．