Redmine から Backlog へ移行する際にやったこと、注意点と仕様の違いについて

Pocket

こんにちは、山本です。
弊社ではプロジェクト管理の標準ツールとして長らく Redmine を利用していましたが、Backlog への移行を行いました。
(2015/09 ~ 12)
利用者が慣れ親しんだツールを変更するには色々と難しい点 1 がありますが、今回は移行の際に考慮したことや注意点、Redmine と Backlog の違い(利用者側、運用管理側)についてまとめようと思います。
評価中の方や、今後切り替えを予定している方の参考になれば幸いです。

移行経緯

移行前の状況

弊社の運用では、事業部にて案件がスタートすると 1 案件 = 1 Redmine = 1 VM 2 として社内 VM(プライベートクラウド)上に準備していました。
(弊社情シスが全社標準化活動の 1 つとして担当していました)
運用開始時は別部門の管理でしたが、情シスに管理が移った 3 頃には VM 数が 50 ほどになっていました。

下記で発表した AWS 移行の最初の事例です。

運用上の問題点

運用管理上の問題として下記がありました。

  • OS、Redmine バージョンに一貫性がなく、バージョンアップやセキュリティ対策の対応をする上でかなり非効率
  • 個別要望に対応していたため Redmine に適用されているプラグインもそれぞれ異なっている
  • プラグインのバージョンも管理対象となっている
  • Redmine バージョンアップにより動作しなくなるなど・・・
  • 1 案件 = 1 Redmine = 1 VM のため、VM ホストサーバのリソースが不足
  • サービス異常時の対応がチーム体制面で困難
  • 監視の仕組みがない

このままいくとかなりまずい・・・と考え、オンプレ運用からサービスへ切り替える判断を行いました。
(プロジェクト管理を効率化したいのが目的で、Redmine を使うことやサーバ運用をしたいわけではない!)

移行サービス調査

Redmine からサービス切り替えを行う上で、Redmine でできることを一通り実現でき、個人的にも使いたかった Backlog を候補としましたが、実際に利用する社員の声も反映する必要があるため、各事業部から有志を募りワーキンググループにて進めることとしました。
移行に至る経緯を説明した上で、候補となるサービスについてディスカッションを実施。
いくつか候補はあがりましたが、コスト面や利用上のハードルが高いなどもあり、最終的に Backlog の検証を開始しました。

Redmine と Backlog の比較

評価版で実際に Backlog を使いながら、機能面と運用管理面での比較を行いました。
太字 は要望が多く特に重要視していた項目です)

※2015/09 頃の検証結果です。

機能面で比較

評価項目 Redmine Backlog 備考
サブプロジェクト作成 Backlog はマイルストーンを利用すると運用で回避可能
グループ単位での担当者割当 お知らせ(ウォッチャー)機能はあるため、複数人への共有は可能
トラッカー追加・編集 Backlog はトラッカー数に制限あり
ガントチャート
バーンダウンチャート Redmine はプラグインがある
ロール設定 ○(7種類)
チケット一括登録 Redmine はバージョン or プラグインにより CSV インポート可能。Backlog は API 利用か無償プラグインがある。
チケット一括操作 Redmine は選択して右クリックで操作できるのが優位性
チケット階層構造 Backlog は子課題まで。孫課題が作れない。
Wiki Redmine はバージョンにより textile と Markdown、Backlog は Backlog 記法と Markdown 記法
スマートデバイスからの閲覧(アプリ利用) △(サーバ側の設定が必要) Backlog は iOS/Android アプリがある
デザイン・UI △(テーマなどで代替可)
SVN・Git連携 Backlog は SVN/Git リポジトリを作成できる
通知・リマインダー Redmine はプラグイン、cron を駆使すれば実現できる。

運用管理面で比較

項目 Redmine 運用 Backlog 運用
ユーザアカウントの編集 個人、または管理者にて編集可能 自身の編集は可能、他のユーザの編集が必要な場合は情シスへ依頼
ユーザアカウントの編集・削除 個人、または管理者にて削除可能 情シスへ申請
メールの受信設定 個人、または管理者にて設定可能 個人設定で、プロジェクト単位で変更可能
SVN の新規利用 情シスへ申請 Backlog にプロジェクトがある場合は、管理者にて利用設定可能
SVN のメンバ変更 情シスへ申請 プロジェクト管理者にてメンテナンス可能
SVN のコミットメールの必要有無の設定 情シスへ申請 ユーザ個人で設定可能
Git の利用 情シス対応外のため各自で準備 Backlogにプロジェクトがある場合は、管理者にて利用設定可能

考慮点

Backlog のメリット

運用・管理側と利用者側双方でメリットと感じたのは下記の点です。

SVN、Git リポジトリがプロジェクト単位で作成可能

バージョン管理として昔から SVN を利用しており(順次 Git への移行中ですが)SVN のリポジトリも情シスが準備しています。(ここも全社標準化活動の一環ですね)
Backlog ではプロジェクト単位で SVN もしくは Git リポジトリを利用者が選択し作成まで行えるため、情シスが準備する必要がなく、また利用者も情シスへ依頼する必要がなくなるためここは大きなポイントでした。

ガントチャート上で担当者、開始日、期限日を一括更新可能

ガントチャートは Redmine、Backlog ともに必須の機能ですが、Backlog ではガントチャート画面で担当者、開始日、期限日を一括更新できるのがメリットでした。
(Redmine ではチケット詳細画面にて更新する必要があります)

Backlog へのログインで参加プロジェクトすべての管理ができる

Redmine では 1 Redmine ごとに FQDN を分けていたためログイン先が異なり、複数案件に属するとそれぞれの Redmine へログインする必要がありました。
Backlog では、ログインすると自身の参加プロジェクトが一度に確認できるため、管理が楽になります。

ユーザー、プロジェクト数が無制限でコストが低い(16,000円/月程度)

ユーザー、プロジェクト数の制限は Redmine でもありませんが、SaaS 型のサービスは利用数による従量課金パターンが多いためここは安心のポイントですね。
そしてなにより利用コストが圧倒的に低いのがポイントです。
(残念ながら移行後に値上げがあったのですが・・)

バーンダウンチャートが標準で備わっており、プロジェクト状況を把握しやすい

Redmine でもプラグインを導入すると利用可能になりますが、Backlog では標準で備わっています。

基本的なチケット管理、ガントチャートは Redmine と同じ事が行える

やはり最低限の仕様は満たす必要があるため、Redmine で行っていることを Backlog で比較してみましたが、致命的なところはありませんでした。

Backlog での懸念点

  • SVN リポジトリの認証方法が Backlog へのログイン ID/PASS
    ⇒ OneLogin 連携する際にパスワードを一括適用予定だった(回避方法あり)
  • チケット担当者にグループ指定ができない
  • プロジェクト毎にグループ作成できないため、利用する場合は情シスへ申請が必要となる
  • プロジェクト作成は情シスが実施するが、プロジェクト管理者でユーザー管理ができない
  • Redmine からの移行ツールが存在していたが、まだベータ版だった

移行によるコスト

本件に限ったことではないですが、ツール(サービス)切り替えの移行コストは下記が発生すると思われます。

利用者側

  • UI が大きく変わることによる、利用者が慣れるまでのコスト
  • お客様と共有している案件の場合、説明コスト

情シス(管理)側

  • 運用設計コスト
  • マニュアル作成コスト
  • 問合せ対応コスト

情シスと利用者の権限設計

ユーザ権限(全体管理、プロジェクト管理)が Redmine と Backlog ではかなり異なるため、下記のような設計に落ち着きました。

権限名 登録ユーザ(デフォルト) 内容
管理者 情シス 一般ユーザの権限に加え、プロジェクトの追加・編集、ユーザの追加・編集を行う。
プロジェクト管理者 情シスへ申請する際に指定する「Backlog 管理者」 プロジェクト毎に設定可能な権限。一般ユーザの権限に加え、権限を与えられたプロジェクトの編集が可能。一般ユーザ権限以下のユーザを新規追加可能。
一般ユーザ 社員 レポーターの権限に加え、課題の登録、閲覧、コメントの投稿、課題の編集、状態変更、カテゴリーの追加・編集、発生バージョン/マイルストーンの追加編集が可能。
レポーター 無し(必要に応じて、プロジェクト管理者にて設定) 課題の登録、閲覧、コメントの投稿が可能。課題の状態を変更不可。報告のみ行うメンバーに付与。
ビューアー 無し(必要に応じて、プロジェクト管理者にて設定) 課題の閲覧のみ可能なユーザ。課題の追加や変更不可。
ゲストレポーター 無し(必要に応じて、プロジェクト管理者にて設定) 個人設定の変更不可なレポーター権限。
ゲストビューアー 無し(必要に応じて、プロジェクト管理者にて設定) 個人設定の変更不可なビューアー権限。

※Backlog のユーザ権限の詳細は下記を参照ください。

移行方法

AWS への移行

Redmine を Backlog へ置き換える前に、まずオンプレ運用からクラウドへシフト(弊社は AWS を選定しました)することとしたため、VM 移行は並行で実施しました。
(この話も記事にする予定です)

ツールによる移行

ちょうど移行について調べている際に、ヌーラボさんが用意している移行ツール をヌーラボさんより情報提供いただいたため、ベータ版ですがツールブラッシュアップに貢献出来ればと思い検証を始めました。

移行可能なもの(バージョン適合している、お客様がユーザーに入っていない Redmine)から順次ツールにて移行を進めましたが、完全な移行はできず、都度ヌーラボさんへフィードバックを送ることで順次対応いただいている状況です。

移行後の効果

  • プロジェクト作成コストが圧倒的に低いため準備が高速に!
    ⇒ Redmine の場合は VM 作成していたため、準備に 1 時間程度かかっていたものが 5 分以内で完了できるように!

  • SaaS 版のため、サーバメンテナンス管理が不要になったことによる管理コスト削減!
    (Redmine は継続しているものもあるため新規分から)

おわりに

長くなりましたのでひとまず以上です。
まだまだ設計時の細かい検証があったのですが、また別の機会にまとめようと思います。
Redmine の優位性はもちろんありますが、運用方法を変えることで回避できるものも多く、結果的に Backlog に切り替えた効果は高かったと思っています。

Redmine からの移行を検討されている方の参考になれば幸いです。


  1. このあたりは会社の風土にもかなり左右されると思いますが・・。 
  2. 1 案件 = 1 Redmine = 1 VM としているのは、セキュリティ上の都合と、サーバ分離することによる影響範囲局所化、Redmine インストール済みの VM コピーによる Deploy の簡略化等の理由によるものです。 
  3. 政治的理由ですが長くなるので割愛しますw(ネガティブな理由ではないですが) 
Pocket

The following two tabs change content below.
山本大作
情報システムチーム リーダー株式会社神戸デジタル・ラボ
2007年に神戸デジタル・ラボへ新卒入社したインフラエンジニア。 大規模ECサイトのインフラ運用、保守、監視を経験し、兼任で情報システムの運用、管理も行い専任化。 インフラ(サーバ、ネットワーク、セキュリティ)の得意分野をベースに、クラウドサービスを組み合わせることによる効率化、自動化の究極形態を研究、模索中。自動化とAWSが好き。