テクノロジー
日報管理システムをRedmineで作る手順を雰囲気で理解しよう
はじめに
こんにちは、IT企画推進部のA.Hです。
IT企画推進部は、デジタルテクノロジー戦略本部内の教育や組織活性を主に担当する部署で、入社した新卒の研修の企画・運営などを担当しています。
例年、マイナビ社に入社したWeb/IT系の新卒は、入社後3か月程度の研修に入りますが、その研修期間中は、研修の最後に日報を提出して一日を締めくくります。
今年からは、新卒研修の日報を管理するシステムとしてRedmineを設定し、提供致しました。
その導入に至った背景、設計の考え方、実際の設定の雰囲気などを書いてみようと思います。
導入の背景
さて、一口に日報といっても、会社の業種や規模によって、日報の提出先や確認フローなどは様々かと思います。
そもそも日報管理にシステム？と思う方もいらっしゃるかも知れません。
例えば、チャットツールにチャネルを作り、今日学んだことを新卒が投稿して、それに先輩がコメントやスタンプをつける、という形式でも、十分に日報として成立します。
実際、去年まではチャットやスプレッドシートの活用によって日報活動を行っていました。
現在のマイナビ社はデジタルテクノロジー領域に大変に力を入れており、新卒採用を積極的に行った結果、2022年度は数十名程度のWeb/IT職の新卒が入社することとなりました。
・・・そうなってくると、ファイルベースでの更新・閲覧は一覧性や可読性、更新検知において段々と窮屈になってきます。
日報は、新卒の学びの定着のための振り返りであると同時に、先輩からのコメントをもらうコミュニケーションの場でもあります。
また、少し考えてみれば、『あるテーマにそって投稿が行われ、関係者が閲覧してコメントを行う』という行動パターン自体は、エンジニアであれば管理ツール・プロジェクト管理ツールの中で、日々実践しているおなじみの行動です。
新卒はWeb/IT職で、先輩達も当然Web/IT職です。
だったらRedmineで良くね？と思い立ったのが、導入の経緯です。
じゃ、なんでRedmineなの？BacklogとかAsanaじゃだめなの？
- ITSを日報報告に使うなら、まだリテラシーが低い新卒が混乱しないために、通常よくある機能（例えば工数、開始日・終了日とか）を削るような方向になる。 ⇒ツールの自由度が求められる。
- 新卒は書く人、先輩は読む人。通常の開発のようにメンバーが同じ権限ではなく、ロールが全く異なりやる事も異なる。特に、新卒は出来ることを限定して迷わないようにしたい。⇒運用ルールが極力システムで表現できる。
- 多分、多少の改善はあれど来年も同じことをやる可能性が高い。構造だけコピーして使いまわしたい。
- お金を掛けたくない。何故ならお金を掛けたくないから。
上記の要求に答えるプロダクトは、正直Redmineくらいしか思い当たりません。
多少の予算があれば機能的にはJiraは選択肢になると思いますが、「多くの先輩にみてもらう」という要件と、アカウント課金は相性が悪すぎます。
日報を掲示板の延伸的な感覚で使う分には、運用ルールの徹底がなされればどのようなBTS/ITSでも使えると思いますが、ただでさえ入社して色々な事を詰め込まれる新卒、日々の業務で忙しい会社の先輩達に、ルールを覚えてもらうことを期待するのは酷というものです。
エンドユーザーに提供する機能を削り、統制を提供するという観点においては、やはりRedmineに軍配があがります。この部分において、BacklogやAsanaは最適解ではないと思います。
などと色々と理由を書きましたが、勿論、
新卒の日報管理のためだけにド新規のシステムなんて入れてられないという話もあります。
幸い、別用途で管理者権限を持つRedmine環境を持っているため、日報管理という業務を理解して、それをRedmineの設定に落とし込めれば、ITSで実現できるな、と思えたわけです。
日報管理という業務
端的には、『新卒が日報を書き、先輩や、研修運営チームはそれを確認してコメントする』だけです。
文字に起こせば当たり前のことを書いていますが、少なくともユースケースに登場しそうなアクターが三種類も登場しています。
もう少し具体的に考えてみます。
新卒のやること
新卒は、Web/IT職採用とはいえ、完全なる初心者です。
基本的には何も知らないし、不都合なことをやりうる可能性があることを想定して考慮します。
まず、新卒は自分の書いたチケットは編集できても、他の新卒が書いたチケットは編集できてはいけません。
開発の課題管理であれば、他の人が書いた誤りを訂正出来るので良いですが、今回は新卒研修なので他の人が編集したり、誤って消したりしないようにする必要があります。
また、Redmineは一度削除したチケットを復元する機能は標準では存在しないため、そもそもチケット削除の権限を取り上げる必要があります。
BTS/ITSそのものにも慣れていません。日報記入に関係がない項目は極力画面から消します。
長い目で見ればトラッカーやステータスなどはしっかり教えたい所ですが、今回はそれすらも意識させないように消します。
私達の研修では、先輩役はローテするので新人は自身の先輩を知り得ません。
なので、「担当者」欄も、今はいりません。
一方で、例えばKPTなど必ず入力してほしい項目は記入されて欲しいです。
同期の新卒が書いた日報は、見せることも見せないようにすることも出来ます。
私達は、「良い日報は他の新卒にも真似をしてほしい」と考えているので、見せるようにします。
先輩のやること
先輩は、日報は書きませんので、新規チケットを作成したり、誰かのチケットを編集する必要はありません。
コメント（注記）が出来ればよいです。
運営研修チームのやること
運営管理者は、ふるまいはほとんど先輩と同じですが、万が一に備えてチケットを追加編集する権限は持っておきたいところです。
Redmineの設定への落とし込み
日報管理にまつわることは、何となく伝わりましたでしょうか。
ユースケースを考える時、私はユーザーの行動を起点に機序を想像するんですが、
Redmineのどのあたりの機能でそれを表現するかは、因数分解をするような感じで、あてはめていきます。
Redmineの機能の全体像
まず、Redmineの全体像を簡単にご紹介致します。
界隈では鉄板ですが、JAXAの方がまとめた下記の図をご確認下さい。
引用：https://www.jss.jaxa.jp/about_coda/
Redmineの仕組みは、上図の通り複層的です。
この辺りの仕組みは管理者権限を得てもシステム内で特に説明がないため、割と初見殺しな部分です。
それだけに色々な使い方が出来るのですが、とりあえず一つだけ、太字の部分を覚えて下さい。
上図の「論理的な定義」に含まれるものは、Redmineの環境単位で共通の設定です。
あるプロジェクトAとBで、トラッカーXを使っているとしたら、トラッカーXの修正はプロジェクトAとBに影響を与えます。
新しいRedmine環境なら、自由にトライアンドエラーをすればいいと思います。
既存のRedmine環境においては、必ず先輩の管理者権限の指示やシキタリに従ってください。
プロジェクト全ての設定を一律で変更出来るのは、メリットであると同時に、
下手に触ると、それはもう凄いことが起こります。
慣れないうちはサンドボックスを用意するか、使いまわさずに独自のものでやりましょう。
という訳で、日報を実現するためにRedmineのどこをいじるかを考えながら設定していきます。
ロールの考え方
文字通り、権限をつかさどる機能です。
Redmineのロールの仕組みは、70を超える細かい機能の利用有無をそれぞれチェックして、
ロールに好きな名前をつけることが出来ます。
例えば、新卒のロールを設定する画面はこんな感じです。
新卒は自分の書いたチケットは編集できても、他の新卒が書いたチケットは編集できてはいけません。
上記要件に関連する設定は、この辺りです。
「チケットの編集」なら、誰が書いたチケットでも編集可能ですが、「自分が追加したチケットの編集」は、自分が書いたチケットでなければ編集が出来ない権限です。
（ちなみに、両方適用すると強い方の前者が適用されます。）
Redmineは一度削除したチケットを復元する機能は標準では存在しないため、
そもそもチケット削除の権限を取り上げる必要があります。
これもチケットトラッキング周りです。上の図のチケットの削除をオフにします。
Redmineにはゴミ箱による一時退避のような機能はありませんので、基本的にはオフを推奨します（二度目）
今回は新卒・先輩上司・運営と3つの役割が存在していますので、
この3つを設定していくことになります。
試しに、先輩上司のロール設定を見てみましょう。
今回の日報管理には下記の要件がありますので、
先輩は、日報は書きませんので、新規チケットを作成したり、
誰かのチケットを編集する必要はありません。
コメント（注記）が出来ればよいです。
チケットの追加にチェックが入っていません。
おまけ：他の新卒が書いたチケットを見せたくない場合。
日報とは別に、後続課程の新卒向けのインターンシップの報告書については、ネタバレ防止などの観点から他の新卒が書いた日報は見れないように変更しました。
この設定は「表示できるチケット」の項目を「作成者か担当者であるチケット」に設定することで実現します。
ただし、1つのロールでは1通りなため、別のロールとして定義して提供しました。
ロールで出来る事の雰囲気が伝われば幸いです。
トラッカーの考え方
トラッカーは『行動パターンの大分類』です。
今回は新卒からの日報以外の行動パターンはありませんので、トラッカーは「日報」だけがあれば大丈夫です。
トラッカーの設定画面はこんな感じです。
Redmineは、標準フィールドすら使わないことが選べます。
一般的な開発用途であれば、担当者や日付情報などは必須ですが、その日かけば期日もなにもなく、新卒が書いたものを先輩は寄ってたかって読むので担当者も不要。
BTS/ITSそのものにも慣れていません。日報記入に関係がない項目は極力画面から消します。
なので、標準フィールドでは説明だけが残ります。
一方、研修担当としては書いてほしい事は色々ありますので、
カスタムフィールドとして項目を定義します。
今回の研修においては、KPTと自由記入欄を分け、振り返ってほしいことをしっかり入力してもらうようにシステム側で制御をしています。
Redmineは、アカウント情報に事業部や例えば趣味などのカスタムフィールドを拡張することは出来ますが、チケット内に拡張したアカウント情報をLookupするような機能はありません。
なので、新卒は毎回配属事業部を入力しなければならないのでちょっと面倒です。
まぁ書いて覚えることもあるだろうということで。。。
配属事業部やチーム名は、後々一覧画面などで検索する時に必要なため、つけています。
カスタムフィールドの考え方
一方で、例えばKPTなど必ず入力してほしい項目は記入されて欲しいです。
チケットの入力項目のカスタマイズをしたいのであれば、カスタムフィールドです。
先述の通り、トラッカーが定まると、その行動パターンで必ずやってほしいことの土台が何となく見えてきます。
研修日報は、できたこと、できなかったことなど書いてほしいことが明示的です。
帳票項目については、カスタムフィールドを利用することで帳票っぽく仕上げていきます。
例として、Keepの項目のカスタムフィールドはこんな感じです。
一度カスタムフィールドを設定した後、形式を切り替えるは出来ませんが、
こんな感じの選択肢があります。
おまけ：特定の人にしか見せたくないフィールドを作りたい
デフォルトでは表示の項目は「すべてのユーザー」が選択されていますが、特定のロールのみ表示するという制御が出来ます。
この部分です。
例えば、社外からの問い合わせに対して、社内でのやりとりを問い合わせしてきた人に見せたくない場合など、同じチケットでも閲覧ロールによって情報を出し分けしたい時などに活用します。
私達の日報管理システムでは特に出番はありませんでしたが、
新卒インターンシップの報告書トラッカーにおいては、メンター⇒管理職と情報を申し送りしたので、その時に活用しました。
ステータスの考え方
ステータスは、チケットの考えうる状態のことです。
例えば、お仕事は「未着手」⇒「対応中」⇒「完了」というフローなのであれば、ステータスはその3つを設定します。
日報にはどういう状態が考えられるでしょうか？
まず、新卒の研修が終わった直後、これから日報（のチケット）を書く場合、『未着手』の状態です。
研修日報をすべてチケットとして予めセットするのであれば、
まだ誰も手をつけていない『未着手』という状態ですが、
『研修終了後、15分以内にチケット追加して書いて下さいねー』という場合、
未着手である時間はほとんど存在しないため、『記入済み』という状態から初めてもいいかも知れません。
日報が『記入済み』になったら、先輩上司や運営チームは一定期間の間でチケットを確認してコメントを書きます。
先輩上司と運営チームのどちらが先にコメントを書くか分からないので、一定期間が終了したら、チケットを終了の状態に変更すれば良さそうです。
ステータスの詳細画面はこんな感じで、
Redmineのステータスでは、「終了したチケット」としてステータスを設定すると、
チケットの検索一覧で完了したチケットとして扱われます。
チケット一覧は未完了のチケットのみ表示する設定になっていることが多いので、
もう対応する必要がないチケットを一覧から消し込むことで、先輩上司や運営チームはコメントが捗りそうです。
ステータスの一覧画面はこんな感じです。
この一覧では、このRedmine環境に登場する全てのステータスが表示されています。
日報という業務の流れにおいては、記入済みと完了だけで良いと決めたので、
どこかでこの業務の流れ、ワークのフローを指定してやる必要があります。
おまけ：進捗率の2つの考え方
Redmineは、チケット個別に進捗率を手動入力するモードと、ステータスにデフォルトの進捗率を持たせて手動管理しない、二つのモードがあります。
このモードは環境で単一設定のため、どちらかしか選べません。
管理 ＞ 設定 ＞チケットトラッキングから選べます。
ワークフローの考え方
ワークフローとは、トラッカーとロール別に、カスタムフィールドやステータスの制御を行う設定画面です。
この機能により、新卒は余計な項目の表示を削る、操作できないようにする、完了ステータスに変更できないようにする、などの運用ルールをシステムの機能として設定することが出来ます。
日報トラッカー×新卒のステータス遷移はこんな感じです。
新しいチケットは「記入済み」のみで作成可能で、作成済みから勝手に完了できないようにしています。
一方で、運営ロールは完了しても良いし、誤って完了した場合は記入済みに戻せても良いので、こんな感じになります。
新卒ロールに戻って、フィールドに対する権限タブを見てみましょう。
制約をたくさん入れているのでこんな感じです。
プロジェクトの考え方
チケットは必ずプロジェクトに紐づきます。
プロジェクトでは、使用する機能モジュール、紐づけるユーザーとそのロール、トラッカーとカスタムフィールド、などを定義します。
親子構造にして親が子のチケットをすべてみる、といった事も可能ですが、今回は新卒用の1つのプロジェクトがあれば大丈夫そうです。
モジュールの設定
例えば、ロール側でニュースの機能に権限を振っていたとしても、プロジェクト側でニュースのモジュールをONにしていなければ、このプロジェクトではニュース機能は提供されません。
上図、チケットトラッキングは日報そのものが入ります。wikiはこのシステムの利用マニュアルを記載していて、ファイルはその記事内に添付するためのファイルのために利用しています。
メンバーの設定
メンバー欄は個人情報が満載なので割愛しますが、選んだユーザーがどのロールかを必ず設定します。ここで、誰がどのロールかをプロジェクトに設定していきます。
チケットトラッキングの設定
チケットトラッキングのタブでも、このプロジェクトで使うトラッカーやカスタムフィールドを明示的に指定します。
運用管理者の頭が良ければよいほど、業務フローの派生を単一のトラッカーの設定に落とし込んで提供できるんだと思います。（遠い目）
これらを抜かりなく設定すると、利用者の皆様にもおなじみの、
こんな画面がやっと使えるようになります。
チケットの入力画面はこんな感じに仕上がりました。
終わりに
本記事、解説以上マニュアル未満なので雰囲気と謳っていますが、
設定をする時の考え方や雰囲気、伝わりましたでしょうか？
他にも細かい設定やらTipsはたくさんあるのですが、
Redmineの管理者権限がざっくりとやる流れの説明としては以上です。
「へぇ、こんな仕組みになっているんだ」
「あ、こういう事が出来るなら使ってみようかな」
と、思って頂ける方が一人でもいれば嬉しいです。
・・・てか、めんどくさくね？
・・・まぁ、手間はかかりますよね・・・。
でも、エンタープライズな本格的なものって、大体そういうもんじゃね？という気もします。
Backlogがインスタントラーメンだとすると、Redmineはラーメン屋のラーメンです。
Backlogなら「運用ルールはこうだからね！」だけで終わるもんを、わざわざ運用設計して設定しているので、そりゃ手間暇がかかります。かつ、上手く作れないならカップ麺のほうが美味しいです。運用してれば変更管理もあります。それも手間っちゃ手間。
でも、運用ルールだけで運用できる範囲には限界があります。
限界を超えて声掛けしたりルールを周知したり教育したりミスをダブルチェックするより、
システム制御の方が楽になる、という損益分岐点のようなものが必ずあり、
規模と戦うのであればRedmineのような複雑さが頼もしく、結果的には楽が出来る、という事もあると思っています。
個人的には、カップラーメンより上手いラーメンが作れるなら、そりゃ作ってあげたいという気持ちもあります。根っこはエンジニアだもん。
一方で、やはり運用管理者に一程度の知識経験を求める所から、自由度が高く複雑で難しいのは事実です。
業務フローが頻繁に変わる時期や、個々人で全然違う業務フローの人たちが同じチームです、といった場合、運用者が伴走することのコストは増大します。
また、インフラの運用の側面でもメジャーアップデートへの対応やプラグインの互換性など、それを乗り切るだけのリソースが必要にはなります。
インフラ面においてはホスティングサービスへの移管で軽減されますが、代償としてSQLの直叩きとかメール受信結果をチケットに起票する系の機能は、恐らく使えません。
なにより、UXにおいてはRedmineの管理者権限の機能を理解している人の有無が大きいです。
手作りでも不味いなら仕方ないです。Backlogには勝てません。
お急ぎの新規プロジェクトでRedmineの運用管理経験者がいないのであれば、僕はBacklogを勧めます。
でも、大規模向けなのにオープンソースで無料です。タダです。
今回は扱っていないですがプラグインによる拡張性もあり、
日本の開発陣の貢献によって2006年からの開発も現在に至るまで連綿と続いていて、
プロダクトとしての安定感も抜群。
AWSのLightsailでもWordPressみたいな感じでサクっと利用可能です。
謝辞
マイナビ社として、Redmineは数多く利用しているOSSの中の1つで、このプロダクトに支えられているプロジェクトが社内には沢山存在します。
改めて、過去から現在までの全ての開発者と開発コミュニティの方に感謝御礼を申し上げます。
※本記事は2022年12月時点の内容です。
