Redmine テーマ minimalflat2 v1.3.0 リリース

2017年7月16日 0 開発 , ,

Redmine 3.4 がリリースされたので minimalflat2 も対応した。

以下、開発メモ。

Stylus 定義を標準 application.css にあわせる

minimalflat2 の CSS は Stylus で記述して application.cssresponsive.css へコンパイルしている。Stylus の代表的な機能には透過的な変数参照、Mix-In、クラスのネストがあってこれまで便利に利用してきたのだけど、本バージョンからネストは控え目にした。

ネストによってクラス定義の冗長さは軽減される。例えば

#top-menu {background: #3E5B76; color: #fff; height:1.8em; font-size: 0.8em; padding: 2px 2px 0px 6px;}
#top-menu ul {margin: 0;  padding: 0;}
#top-menu li {
  float:left;
  list-style-type:none;
  margin: 0px 0px 0px 0px;
  padding: 0px 0px 0px 0px;
  white-space:nowrap;
}

のように同一 id やクラスを親としているものは

#top-menu {
  background: #3E5B76; color: #fff; height:1.8em; font-size: 0.8em; padding: 2px 2px 0px 6px;

  ul {
    margin: 0;  padding: 0;
  }

  li {
    float:left;
    list-style-type:none;
    margin: 0px 0px 0px 0px;
    padding: 0px 0px 0px 0px;
    white-space:nowrap;
  }
}

のようにネスト可能。ただしこれを徹底すると標準 application.css と定義位置が乖離してゆき、差分比較して追従するのが難しくなる。また、ときには位置の依存関係が崩れることで意図せぬ問題を引き起こす。

以上の理由からアイコン フォント用の疑似要素などを除き、標準 application.css の定義順へならうことにした。Redmine のバージョン更新があれば、最後に対応したものと最新版の application.css を差分比較して部分対応すればよい。従来もそうしていたのだが、今回の変更によりこれが更に容易となった。

Redmine v3.4 の Vagrant Box

テーマ開発における Redmine 上の動作確認は onozaty さん が提供している Vagrant Box を利用している。今回も Redmine v3.4 版が公開されたので、それを Vagrantfile へ指定するようにした。

Twitter 上で Vagrant Box リリースされないのかな?とつぶやいていたら迅速に対応していただけた。非常にありがたい。

Redmine v3.4.0 から間隔が空いたのは、これのすぐ後に致命的なバグを修正した v3.4.1 がリリースされたので、これを待っていたのかもしれない。

Redmine v3.4 プロジェクト一覧の謎

minimalflat2 では theme.js によりプロジェクト一覧をツリー上に開閉する機能がある。しかし Redmine v3.4 へ更新したら、これがうまく動作しない。そもそもプロジェクト名と説明文が横並びになったりする。

もしかして HTML の DOM 構造が大幅に変更された?標準テーマではどうだろう?と試したら、標準のほうでもそうなる。これは application.css にある

#projects-index {
  column-count: auto;
  column-width: 400px;
  -webkit-column-count: auto;
  -webkit-column-width: 400px;
  -webkit-column-gap : 0.5rem;
  -moz-column-count: auto;
  -moz-column-width: 400px;
  -moz-column-gap : 0.5rem;
}

という定義が原因だった。

複数カラムでグリッド状に表示するための定義らしいけど、responsive.css のほうは従来どおり縦一列である。表示幅が広ければグリッドで、ということなのだろう。しかしプロジェクト名に対して説明文が回り込んでしまうなど、好ましくない表示のされかたをする。また minimalflat2 としてはツリー表示によりプロジェクト一覧を整理する方針なのでグリッドにしなくても冗長さはおさえられる。

以上の理由から、この新しい定義は無効化することにした。プロジェクト一覧は表示幅にかかわらず、従来どおり常に縦一列になる。

モバイル用メニューのアイコン フォント対応強化

Redmine v3.4 ではアイコン画像を表示する DOM 要素に icon- を接頭辞とするクラスが統一的に指定されるようになった。指定されるだけで CSS に画像指定のないものも多数あるのだが、minimalflat2 としてはなるべくこれらにアイコン フォントを割り当てるようにした。

もっとも目立つのはモバイル用メニューのアイコンだろう。サイド メニューから移動されてきた項目以外はのきなみ icon- 接頭辞をもつため、かなり華やかになった。

モバイル用メニュー

簡易テスト用 HTML 更新

Vagrant なのか Redmine の設計なのか分からないが、VM のテーマ ディレクトリーと同期している場所で CSS が更新されても Redmine に反映されない。Web ブラウザーのリロード、スーパー リロードをしてもダメで、しかたなく vagrant reload している。

しかしこれは非常に時間がかかる。そのため Redmine の代表的な画面を静的 HTML として保存し、そこにコンパイルされた application.css などを読ませるようにして簡易テストできるようにしている。

今回も Redmine v3.4 用に HTML を保存し直して更新した。また従来のリポジトリー構成では

src/
├── debug_images/
├── favicon/
├── fonts/
├── images/
├── javascripts/
├── stylesheets/
├── stylus/
└── *.html

のように src/ 直下に全ファイルが並んでいて stylus のように開発で頻繁に書き換えるものと、静的でほとんど更新のないものが区別しにくかった。そこで

src/
├── assets/
│   ├── debug_images/
│   ├── favicon/
│   ├── fonts/
│   ├── images/
│   ├── stylesheets/
│   └── *.html
└── stylus/

のように静的リソースは assets/ へ置くようにした。最近の Web フロントエンドや Electron アプリ開発でもこのようにしている。Stylus がコンパイルした CSS と Source Maps は assets/stylesheets/ へ出力される。

assets/ がテーマとして動作するための構成をもったディレクトリーとなる。リリース用イメージ生成も、ここにあるものから必要なファイルをコピーすればよい。動的なファイルは Stylus のコンパイル結果ぐらいなので、cpx 用のフィルターも書きやすくなった。

Redmine theme minimalflat2 v1.2.2 release

2016年10月24日 0 開発 , ,

長らく放置していた minimalflat2 を v1.2.2 としてリリースした。

今回の変更点は以下。

大きな変更、というか方針転換として Redmine プラグイン対応がある。

テーマ側で特定のプラグインに対応すると、それらの更新に影響を受けるため避けてきた。しかし何件か PR で対応されたことから考えを改めた。

現在の方針としては

  • 最新の Redmine に対応していること
  • Vagrant の最新 Redmine box で動作確認できること
  • テーマとして対応が容易であること
  • GitHub issues にて要望されること

を満たしたものについては対応することにした。なお、この条件は意外に厳しい。

かの有名な Redmine CMS の対応を要望されたのだが、依存 gem の関係か bundle に失敗、そのまま Redmine を再起動したら 500 error になってしまった。ログを見るに Active Record の参照問題っぽいが、それはテーマ側で修正するものではなく、どうにもならない。

前に Redmine 運用の記事でも書いたが、Redmine プラグインは gem 依存が自身で完結しておらず、うまく解決されないと Redmine 本体がクラッシュする。

要望があっても私の環境で動作確認しないことには対応できないわけで、今のところ gem 未使用なプラグインとか Redmine 最新版に追従できてるものだけサポートという状態である。

放置していたものをリリースすることになったのはこの issueで修正したはずの問題が再報告されたため。

開発者としては commit/push 時点で終わったつもりになっていたけど、それを反映したものをリリースしなければ意味がない。半端に修正したまま放置というのはいかにも無責任である。

ということに気づいたのでリリースとあいなった。

あと、対応するバージョンを決めかねる issue は v.NEXT という Milestone を設定することにした。Redmine でも同じような運用をしているのだが、将来に見送るものはそうであることを明示しておくと issue の状態がわかりやすくなる。

Redmine 運用について 3/3 – 普及の施策と課題

2016年7月29日 0 開発

Redmine 運用について書いてみるシリーズ 3/3。

最終回は Redmine に馴染みないユーザー、例えば工程管理やバグ表を Excel で運用していたとか、そういう管理職や社員に対して Redmine を普及させるための施策や課題などを書く。

これまでの内容と重複する部分もあるが、本記事ではルールよりも事例や留意したことに重きを置く。

シリーズまとめ
Redmine 運用について

現状分析

前職はソフトハウスであり、一部に Trac による TDD を経験していたプロジェクトもあったので Redmine 導入はスムーズに行われた。TDD に親しみのない社員も BTS として利用しはじめて、Excel ベースのバグ表を置き換えながら慣れていった。

一方、現職は私が移籍する前に Redmine を導入していたものの、数名が実験的に利用しているような状況で、業務は主に上長の手による Excel シートで管理されていた。

シートには部署に属する社員と担当業務がずらっと並んでいる。2 週間ごとにおこなわれる定例で聞いた話を紙にメモ、その後に自席に戻ってそれを Excel に反映させるのだという。

これを Redmine 管理へ置き換えることを提案することにした。まずは現状分析するために二ヶ月ほど定例に参加してみた。定例の規模は 7 人で 1 時間、参加した回数は 5 回ぐらい。その中で気になった点をまとめる

  • 同じ課題が何度も繰り返されている
    • あの問題どうなりました、確認中です、ではまた次回に、という感じ
    • 手元のメモで数をカウントしたら 3 回のものもある
  • 進捗報告は基本的に作業の開始と終了のみ
    • 〜に着手しました、終了しました
    • 中間報告は率ではなく問題の有無となる
    • 期限までに終了すれば経緯を問わない
    • 担当者が問題と感じたものだけが問題として扱われる
    • 良くいえば裁量主義、悪くいえば放置放任
  • 議事録がない
    • 定例の記録は各人のメモに委ねられている
    • 業務管理 Excel シートは一種の議事録ともいえる
  • 2 〜 3 人で細かな業務の議論が突発的にはじまる
    • それで大丈夫ですか?あれはどうなっています?という感じで開始
    • 細かくメモを取るタイプだと報告から問題に気づき、それを指摘することが多い
    • 議論の記録が保証されないためか、この場で結論せねば、という雰囲気
    • これが数回あると、定例が 2 時間に及ぶこともある
    • 議論に関係ない社員は終了を待ち続けるか、雑談をはじめる
    • 私は眠気が抑えきれず、船を漕いでいる

業務管理はもとより定例にも多くの問題がある。これをもとに Redmine で対策する方法を考える。

部署単位の業務管理

定例で私の番が回ってきたとき、現状分析で気になった点を発表した。そのうえで、これらの問題が既に導入されている Redmine で解決可能なことを説明。口頭のみでスライドなどは用意しなかったが、当時を思い出しながら問題と対策をまとめる。

  • 同じ課題が何度も繰り返されている
    • 課題を Redmine のチケットとして管理する
    • チケットには課題の内容、担当、期日、対応状況を設定できる
    • 個人のメモや記憶に頼らず、常に確認可能
    • チケットならば任意のタイミングで着手できる
    • 定例を待たずとも議論可能
  • 進捗報告は基本的に作業の開始と終了のみ
    • 途中経過も重要
    • 作業の見積もりと実際にかかった時間は計測されているべき
    • そうしないと効率化できない
    • 定例の合間となる 2 週間、質問するまで手が空いていることもわからない
    • チケットで期日、作業時間、進捗率を設定することでリアルタイムに現状報告される
    • 定例を待たずとも把握可能
    • 作業が発生したら定例の場でチケット化する
    • 理想はチケット一覧を眺めながら数値で現状確認すること
  • 議事録がない
    • 議事録ドリブンを提案
    • テキストで残して全員が読めることの重要性を説明
    • 定例の前に Redmine Wiki に議題を書き、読んできてもらう
    • 定例では Wiki の内容をテキスト エディタでプレビュー表示
    • 当時は Sublime Text + timonwong/OmniMarkupPreviewer
    • 現在は Atom + textile-preview を利用
    • 議題に対する発言や決定事項をエディタで編集
    • メモしてほしいことがあれば発言する、というルールを提示
    • 定例が終了したときには議事録が完成、Wiki に反映して共有できている
  • 2 〜 3 人で細かな業務の議論が突発的にはじまる
    • 議事録ドリブンにより大きな問題は議題として登録済み
    • 小〜中規模の問題はなるべく当事者間で議論、できればチケットで
    • テキストでやりとりしないと、理解の齟齬が起きやすいことを説明
    • 口頭では相手の発言を精査引用するのが難しい、博覧強記を求められる
    • すべてを把握するより必要な情報がある場所を管理するほうが簡単

こんな感じの話をした。私は既に自身の業務に関係する社員と Redmine でやりとりしていたので、そのチケットを見せたりもした。

結果、まずは部署内の業務管理で Redmine を活用してみようということになった。上長の Excel シート管理はその後もしばらくは続いていたようだが、ここ 1 年ぐらい見ていないので移行できたのだろう。

対策のうち議事録ドリブンは採用、業務のチケット化については少しずつ浸透している。オフィスを歩いているときに見える PC の画面で、チケット編集している様子をみることが増えた。

全社的な展開

現職の企業は社員数 20 名ほどの小さな会社である。そのため、全社的な展開といっても大企業の 1 部署程度なのだが、横展開の手法という意味では規模に関係なく汎用性がある話といえるかもしれない。

個人、部署レベルでは Redmine による業務単位を取り入れたので、これを全社へ展開することにした。管理職には前述の提案を繰り返すことで賛同を得られたのだが、具体的な運用がピンと来ないとのことで、勉強会を希望された。

勉強会を開催するにあたり、実運用しているプロジェクトをサンプルとした。私はソフトウェア開発を担当しているのだが、この業務は目的のはっきりしたチケットが多いため、サンプルにふさわしい。

ある機能の開発着手、進捗更新、解決報告して検証、終了という流れを見せた。またそれをソフトウェア開発とな異なる業務、たしか書類作成だったかに当てはめて、同じように進捗管理する手順を説明。

概ね納得していただけたようで、全社的に積極利用する運びとなった。社員に対する説明は Wiki
に掲載した運用ルールやチャット、必要ならば個別に対応する。既に Redmine が導入済みということもあり、基本操作については特に解説しない。

かわりに

を購入して会社の本棚へ公開した。

私はこれの第 2 版を持っているが、基本機能だけでなく呉服屋の管理事例など運用面の話も面白く、かなりオススメの書籍である。Redmine の更新ペースには追従できていないが、激変というほどでもないので入門には十分だと思う。

管理職の説明会には質問も多く挙げられた。それらの内、特筆すべきものをまとめる。

プロジェクトはどういう単位で作成すればよい?

この話は前回を参照のこと。

現在の〜という業務をチケット化するとしたら?

  • 実際にチケットを作成しながら説明
  • バージョンや親チケットなどは慣れないと分かりにくいので割愛
  • トラッカーで業務の大まなか分類を指定
    • ソフトウェア開発でなくても「実務 = 機能」、「問題への取り組み = バグ」、「顧客対応 = サポート」のように分類可能
  • 題名に業務内容を指定
    • 〜業務とするより、その業務で達成したいことや成果物で考えるとチケット化しやすい
    • 〜する、〜を作成する、など
  • 説明に業務の背景や補足情報を記述
  • ステータス新規進行中終了だけで管理する
    • 慣れたら解決フィードバックも利用して終了を判断するタイミングを設ける
  • 優先度は慣れるまで設定しなくてよい
  • 担当者は業務を依頼する社員を指定
    • チケット上で対話する場合は、その内容をコメントしたうえで担当者を相手に変更
    • 相手が返答したら相手が自分に担当を戻す
    • これで対話が成立
  • 開始日はチケットに着手した日を指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • デフォルトはチケット作成日
    • すぐに着手しないなら空欄にするとよい
  • 期日は業務の締め切りとなる日を指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • デフォルトは空欄
    • これを設定するなら開始日も厳密に指定すること
    • 開始日と期日を指定することで正確なガントチャートを表示できる
  • 予定工数は時間単位で指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • 1 日 = 8、半日 = 4、1 時間 = 1、30 分 = 0.5 ぐらいの単位で入力
    • ざっくりでよい
    • あわせて時間管理を有効にし、実作業の時間も記録すると効率化や見積もり精度の向上に役立つ
  • 進捗率
    • 業務の現状把握に関わる、管理職として非常に重要な設定
    • 0 からはじめて 10% 単位で更新
    • ステータスを解決終了にするときは 100% にする

業務の資料はなるべく Wiki に書くべきか?

  • なるべく Wiki がよい
  • Wiki は基本的な装飾とページ階層化、リンク機能があるので大抵の資料は書けるはず
  • チケットや Wiki のリンク略記も便利
  • 情報を Redmine に集約することで、検索の価値が高まる
  • 編集履歴も自動保存されるため、簡易なテキスト専用リポジトリとしても有用
  • 他社とのやりとりや印刷を考慮するなら Microsoft Office も可

Redmine に関するお知らせ

Redmine に関する情報を社員に告知したい時がある。例えば

  • Redmine 本体のメンテナンス
  • Tips
  • FAQ

など。これらを通知するため、以下の方法を採用している。

チャット

現職ではチャットワークを利用しており、Redmine という専用のグループを設置。メンバーは社員全員。例えば

  • Redmine の更新
  • サーバー更新に由来する再起動
  • 影響の大きな設定変更
  • 運用ルールの改訂

について通知している。突然利用できないとか動きが急に変わったといった問題に遭遇すると不安を感じるさせることになる。これを避けるため、事前通知は重要である。

また常時、質疑応答を受け付けている。その内容を FAQ にすれば社としての Redmine 知見を貯められる。ただ、あまり質問されることはなくて私が流した Tips に対する反応とか、そんな感じのやりとりが多い。

Wiki

Redmine の運用ルールや Tips、FAQ を貯める場所として利用。

チャットと同様に Redmine 専用プロジェクトを設置しており、Redmine に関することはその Wiki に記述。ここを読んでもらえれば Redmine はバッチリ!という状態を目指している。

Redmine の推進にあたり心がけていること

Redmine の推進にあたり心がけていることをまとめる。

古い管理手法を尊重する

業務やバグ管理に Excel シートを利用することについて、Redmine や GitHub issue を経験していると旧態依然に見えることだろう。

複数人の同時編集が難しい、履歴が取りにくい、セル管理の破綻しやすさなど、Web ベースの TDD/BTS に比べるとメリットなど皆無に感じられる。

それでも、紙でないだけマシである。また、紙であったとしても管理されているだけで価値がある。業務や開発において、最もよくないのは管理されていないことだ。

非効率、または無駄なルールが多くても、管理されているのであれば状況は可視化されている。つまりは改善の対象となりえる。管理されていない場合、業務で起きていることの分析・分類から始めなくてはいけない。

以上を踏まえ、Redmine や GitHub issue による管理を提案する場合は古い手法の管理者を尊重しよう。よくぞ管理してくれていました、と。

この記事でも挙げた Excel シートによる業務管理では社員単位の作業分担が記録されていた。ということはつまりチケットの題名と説明、担当者に流用できる。あなたの管理してきた情報は価値あるもので、それをより便利なツールに移行するだけという点を強調する。あまり過剰にすると褒め殺しっぽくなるので注意。

Redmine に限らず新しいツールや手法を提案するときは、いつもこのようにしている。対立を避けながら賛同を得るための方法としてなかなかよいと考えているのだけど、どうだろう?

とはいえ私は凡人なので、旧態をけなす誘惑に苛まれることがある。

Redmine 以外だと例えば Subversion から Git、jQuery から React へ移行したときには古巣がみすぼらしく感じられたものだ。それをけなすことで簡単に自身の成長を実感できる。いままで悩まされていたことを愚痴るのは、抗いがたい快楽をともなう。

この行為の問題は、新しい手法への敵対者を増やし賛同者を減らす効果にある。古巣に残らざるを得ない人にとって、そこをけなされることは耐え難い苦痛である。移行を検討できる人は対立を知ることで、それを見送るかもしれない。まだ議論は尽くされておらず新しもの好きが騒いでいるだけ、と。

この誘惑に負けてやらかした場合はなるべく深く悩んで、そのことを忘れないように心がけている。枕に顔を埋めてジタバタするわけだ。ああ、やらかしてしまった!という感じで。

活況を演出する

大昔に在籍していたプロジェクトで、知見を貯めるとかソフトウェアのリリース ページ作成などの目的で Wiki の採用が提案された。提案者は私ではないのだが、初めて触れる Wiki の機能性に感心してすぐさま賛同した。

そして運用がはじまった。しかし一部の賛同者が利用するだけで一向に広まらない。折にふれて Wiki ありますよ〜すばらしいですよ〜と宣伝してみるのだが、反応は冷ややかである。

そこで我々は考えた。

  • 使われないのは誰も使っていないからだ
  • この状態で書き込むのは新雪を踏むようなもので、気後れするもの仕方ない
  • 我々が書きまくろう
  • ジョークさえも許容しよう
  • 使ってよいという雰囲気を醸成するのが重要

というわけで、例えば海外チームのメンバーを紹介するのにヒッピー風とあれば、ヒッピーをリンクしてその説明を書いたりした。あと砂場というページを練習用に公開した。昔のことなので記憶が曖昧だが、Sandbox の和訳としてはじめから用意されていたページだったかもしれない。そこに冗談混じりのテキストのあることが重要だった。

しばらく、おそらく数ヶ月ぐらいかかった気がするけど次第に他のメンバーも書き込むようになった。ちょっとした技術的なテクニックとか考察なんかも充実してきて、ちゃんと分類したいということで PukiWiki へも移行した。他に内製の BTS もあったのだけど、そこに書かれないような情報は Wiki に蓄積されてゆき、当初の目標は達成された。

この経験から、あるシステムを普及させたい場合、活況であることの演出は非常に重要と考えるようになった。現職ではそのために以下の施策を実施している。

  • なんでもチケット化
    • ミーティングで議論が発生しそうな時は「それ、チケットで!」
    • なにか購入したいものがあるとき「稟議はチケットで!」
    • チケットが気軽に作成できて便利なものであることをアピール
    • 目的、担当者、期限のあるものなら大抵はチケット化できることをアピール
    • チケットに関わる機会を増やすことで自然と活況になる
  • チャットによる様々な通知
    • Redmine 自体の変化が活発であることを明示
    • 放置されていませんよ、ちゃんと生きていますよ、ということを演出
    • 空回りしている可能性も否めないが、続けることが大事
  • 様々なレポートの Wiki 記載
    • 現職ではセミナー参加を推奨している
    • 業務時間に出席することもあり、レポートを書くことが暗黙の義務となっている
    • レポートは Wiki に書かれ、その更新も通知している
    • これは筆者、読者の両方で関わっているが、かなり楽しい
    • アクセスログを見るに、読者数は多い
  • 議事録ドリブン
    • 私が司会者となるミーティングは基本的に議事録ドリブンで運用している
    • 議題と議事録は Wiki に書かれる
    • ミーティング中の発言が記録されて Wiki に反映される
    • 参加している感を強調
    • ジョークも記録しますよ、と言っているのだけどそれは遠慮されている
    • 司会と書記を兼ねるのは厳しいものがあり、タイピング速度の問題もあって、これをできる社員が 2 名しかいないのが難点

マメなサポート

これまでの内容と被る部分もあるのだけど、Redmine に関する質問や悩みは可能な限り迅速に対応している。基本はチャットだがテキストのやりとりが苦手な社員には口頭での相談も可。

ときには社員本人の席を訪れ、30 分ぐらいマンツーマンで Redmine に関する指導をすることもある。

普段、自分の利用している環境で直に説明すると高度な機能でも理解してもらいやすい。ついでにチケット化されていない業務を質問して、それをどのように Redmine 管理へ持ってゆくかを提案したりもする。

私のメイン業務はソフトウェア開発なので、こうしたサポートのコストは問題に感じられるかもしれない。しかし私は社全体で強くなることを目標としており、業務の効率化も立派なハックと考えている。そのために Redmine を提案したのだし、こうしたコストを捻出するためにメイン業務の見積もりはかなりの余裕を持たせている。

こうした考えに至ったのは、かつて在籍していたプロジェクトのリーダーの影響である。Wiki や議事録ドリブンもその一部で、その方はこうしたファシリテーションを非常に重視していた。実際、それを受ける側として効果を実感したこともあり、私もそれを踏襲している。

おわりに

つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索とはてブの反応はよい刺激になった。

Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。

幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。

もし感想や Redmine 導入についての相談などがあれば、本記事のコメント欄や Twitter などでどうぞ。