Redmineをどうも好きになれない人のための、20%の基礎を抑えれば、80%位の業務に対応できると気がついた長話。

ゆきあ

この記事はRedmine アドベントカレンダー10日目に登録された記事です。

◾️はじめに

どんな技術にも、80%の事が出来るようになる、
20%のよく使う基礎というものがある。

例えば、
プログラミングならifとループと配列と、インプットとアウトプットを覚えれば、極論何でも出来るように。

計算の記号であれば四則演算と%を覚えておけば、日常生活に支障をきたさないように。

とりあえず天気の話から始めれば、大抵のアイスブレイクは何とかなるように。

htmlもCSSも、よく使うタグは割と固定的であるように。

「そこまで覚えると、あとはもう楽しくなる」という、20%のコアで基礎的なラインがある。
それはRedmineも例外ではない。

そして結論から言うと、トラッカーとロールとワークフローがRedmineの20%である。

ただ、そもそもランナーズハイ状態にならないとマラソンが苦行であるように、
「何でbacklogじゃダメなんだよ。。あっちの方がアイコンやデザインが可愛くて、フレンドリーなのに」みたいな状態だと、この20%は乗り越えられない。

足を怪我している人はそもそも走れない。
Redmineを楽しいと感じるためには、
はじめの20%を走り切るために確認したり、
確認したら、整えたりすべきいくつかの条件がある。

最近、その事に気がついた。

という訳で、
この記事では、まず幾つかの理解や誤解のポイントを説明したい。
大きくはBakcklogの卒業、究極の銀弾の不在、設計→設定が1:Nの関係、という3点である。

その後、トラッカー・ロール・ワークフローの捉え方について、凄くざっくりとお伝えする。

技術理解として看過できない点があれば掣肘頂けると大変にありがたい。


◾️Backlogの卒業

結論は、Backlogでいいなら、Backlogでいい。
組織間で違う目的で利用し、声掛けで解決しない時が、backlogを卒業する時だ。

さて、Redmineの記事ではあるが、
入門にあたってはbacklogの話は避けて通れない。(余談だが司馬遼太郎は好きだ。)

というのも、日本の90%が従業員30名規模の会社であるとするなら、
backlogが最も業界標準的であろうため、
backlogの次の候補としてRedmineに触れるケースが多いと想定されるからだ。

では、backlogには出来なくて、Redmineの得意な事とは、何だろうか。
これに答えられるようになるのが、一番初めの準備だ。

色々な回答があると思うが、僕の見つけた回答は、
ワークフロー機能、つまり権限や承認による、
組織的な統制の設計自由度が高いこと、である。

例えばbacklogには、カスタムフィールド機能がある。これはRedmineにもある。
しかし、例えばA部署には記入して欲しくないし、
何なら見せる必要もないんだけど、
B部署では管理上そのカスタムフィールドは必ず入力する、という場合があると思う。
例えば営業に依頼された案件の担当者は、営業に指名されたくない、とか。

しかしbacklogでは、A部署もB部署も等しくその項目をシステム上では閲覧・入力・編集が出来る。

つまり、

運用ルールはシステムに反映する機能はないので、
運用でカバーしてね！

というのが、backlogのコンセプトであり、使い方の骨法と言える。

そして、backlogの運用が出来ていて、不満がないなら、僕はRedmineを無理して使う必要はないと思っている。

例えば、
関係者の力関係がシンプルでフラットで、
人数も少なくて、週一の朝礼や二社間での定例会議で関係者全員が集まるような、
運用ルールの設定や周知の声掛けが物理的に声が届く規模感。
backlogは2社で使うけど、同一目的のためにチームになって頑張ろうね！という感じ。

こんな感じなら、もう全然backlogで良いと思う。

物理的な条件が変わらない限り、
つまりチームがチームのままでいられるなら、
Redmineに引っ越して便利さを探すよりも、
飲み会とかゲームやレクして相互理解を深めた方が良いとすら思うし、
極論Slackとかでスピード感を上げるというのも肯定されると思う。

けども、どんなサービスにもスケーリングの限界はある。
物理学では、空を浮くための力学は、重さが変わると
摩擦力、浮力、重力と原則が変化していく。

例えばLineという仕組みは手紙やメールよりも技術後発的で便利である。
家で飲み会を主催する分には最適なツールではあろうが、会社の関係者20人の忘年会を調整するとなると、結構怪しくなってくる。
Lineではなく候補日に◯×△をつけるような調整サービスを使いたくなってくるだろう。
さらに、1000人で会社行事をやるとなった場合、そもそも偉い人を除いて個人の意思を問う事に意味がないので、Webページでの告知と参加の厳命通達がソリューションとなる。

「みんなでお酒を飲む」というだけなのに、「みんな」が膨れると今まで動いていたサービスは機能しなくなる。

だから、どんなシステムにも、許容限界量となる「みんな」の閾値がある。
しかしその閾値の精緻な値は誰にも分からない。

だからシステム職は楽しい訳だけど、
backlogにもスケーリングの限界があるとするなら、
それはどんな形で忍び寄ってくるんだろうか？

人数増、モラルマナーの欠如した人格の登場などでも結構揺らぐし、割とストレスフルだと思うが、
決定打になると考えるのが組織と組織のような話になる時だ。

端的にいうと、物理的に声をかけるコストが高過ぎて現実的ではなくなった時が、backlogの卒業契機だと思う。

具体的には、
立場や権限の異なる人が、プロジェクトの遂行とは違う目的(事前の影響チェックや、内部監査)で登場しはじめる時や、三社、四社と関係者が増えた時。
みんなで飲み会やゲームのレクとかは最早ジョークにもならず、
とにかく関係者に役割に徹して貰わないと、もう色々不味いことになる、という時。

チームがチームでいられなくなり、働き方を変えなければいけなくなった時。
それが、backlogを卒業しなければならない時だと思う。


◾️究極の銀の弾丸などない。

この章の結論は、
Backlogが外食のファミレスでいうところのサイゼリアだとすると、Redmineは家飯なので、
理想とそれを実現出来るかはあなた次第であるという点だ。

怪文書にしか見えないかも知れないが、
しばらくお付き合い頂きたい。

backlogというものは、役割や権限がフラットなチームのために提供されているサービスである事を説明したが、
これは言い換えると、
ヌーラボという会社は、役割や権限がフラットなチームが利用した時、最大限のUXを提供出来る様に、
最適な設定作業をサービス利用者全員に提供している状態であると言える。

Redmineというのは、役割や権限が多種多様である一方で、
何が最適かを考えてUXを提供するヌーラボさんの中の人に該当する人が初めからは居ない状態で始まる、という事を意味している。

Redmineをインストールした直後と言うのは、
最低限の設定しかされていないので、ここから自分の組織に合わせて最適化していかないと、勿論、backlogの方が、なんか良かったよね。。という話になってしまう。

どういうことかを、料理に例えて説明したい。

僕は最近サイゼリアというファミレスが結構好きだ。
非常に安価な価格設定で、高級食材は扱わないが、ボロネーゼも野菜ソースも味付けに創意工夫があり、定番レシピの力を引き出しきったかのような料理を提供している。子供はパクパク食べる。

なので、税抜き399円のサイゼリアのボロネーゼよりも、美味しいボロネーゼを自宅で調理して食べるというのは結構難しい。
サイゼリアの企業努力を実感する事だろう。

多分、料理経験のない人の作る、家飯のボロネーゼはサイゼリアのボロネーゼよりも満足度が低い。
それでも、自分が美味しいと思うボロネーゼを追求して、食材や調理法に拘っていけば、サイゼリアよりも金と手間が掛かったとしても美味しいものが食べられるようになる。

Redmineも同じことで、
とりあえず入れただけのRedmineには、backlogほどの価値はない。
プロジェクトの業務や組織、意思決定を理解した上で、管理するために必要なルールをRedmineに落とし込んで行くことをしないと、Redmineを使う意味や面白さが分からない。

だから最悪のパターンなのは自分がRedmineの管理者権限を持てないような場合だ。
プロジェクトのキックオフの時に、受注側についでのように作ってもらったRedmineを使っていて、問題が顕在化した時にカスタムフィールドが増えたりするようなやつ。

お客さんである限り、料理の腕は上がらないし、
自分が食べるものでないのなら、美味しい料理を作る必要がないように、
管理者権限がない利用者である以上、Redmineに何が出来るかは気が付けないし、
管理者を他の人に(ましてや社外の人に)任せているなら、自分の課題解決の主導権を放棄している事に等しい。

全ての会社や業務にフィットする設定になったRedmineは、何処にもない。
自分で作るしかない。

究極の銀の弾丸は、どこにも無い。
けど、自分なりの銀の弾丸を拵えた人たちが沢山いる、というのが、Redmineの世界である。


◾️設計→設定。これ、一度では終わらない。


この章の結論は、
Redmineの設定とは、まだないものを想定しながら作らなければ行けないので、一度に全ては設定出来ないという話だ。

まず、設計と設定は別物である事を確認しておきたい。
(余談だが、司馬遼太郎は好きである。)

設計というのは「このRedmineを、どういう人に、どのように使ってもらおう」という話である。

ここで求められるのはRedmine以前の話で、
ホワイトボードや紙とペン、エクセルとかで、「誰がどういう時に何をするのか」を網羅的に捉える事で、全体像を描けるか、という話だ。

UMLでいうとシークエンス図とユースケース図の概念を知っていると有利だ。
もしDocbaseとかKibelaを利用してるなら、PlantUMLではシークエンス図の分岐でユースケースを補完していくのがある程度実践的かも知れない。(MTG中にささっと描けると非技術者からのウケがいい)

とにかく「誰が」「どういう時に」「何をするか(裏を返せば、何が出来ないか)」を洗い出す事が、Redmineの設計では重要だ。

というのも、これの洗い出しが出来ていないのなら、
トラッカー、ロール、ワークフローの設定が出来ないはずなので、永久にRedmineの設定が終わらない。

これについてはRedmineが、というより、顧客の要望から本当に必要なものを見切って提案する能力の話なので、もう少し汎用的はビジネススキルの話でもある。

(追記:後日、要件定義に関する記事を後日書いたので、追記します。物凄く長いのでご注意下さい。)


さて、設計が終わったのなら、次は設定の話なのだが、
この設定作業は必ず一度では終わらない。

上手い人は一度で終わるとかそういう話ではなくて、
設定作業の途上では、依存関係のある、まだ無いものを想定しながら作らなくてはいけないから、いろいろな設定画面を行ったり来たりする必要がある。

というのも、Redmineの設定は基本的に相関関係の設定のあるものしかない。

例えば、ロールはトラッカーと関係している。
ロールを作ったらトラッカーを後できっちり定義してやる必要がある。
ロールはプロジェクト毎にユーザに与えられるから、ユーザーの設定も必要、

という具合で、何もない所から作る方が作業量が多い。

自分の実現したい状態から、Redmineの設定作業をリストアップするのは、割と因数分解のような感覚に近いかも知れない。

初めの手応えを得るまでが遠い。
けど、その状態が正しい。
慣れてないだけだし、慣れていく。
慣れていくほど楽になる。

サッカーで言えば、ある程度ボールを真っ直ぐ蹴れない事にはパス練習に付き合ってくれる人が困っちゃうので、人がいる体裁でボールを蹴り込むような感覚だ。

そういうものだと思って設定作業を何度もして、体で覚える必要がある。


さて、何度も何度も出てくるトラッカーとロールとワークフローって一体何者なんだよ。。。
という話について、いよいよこれから説明する。


◾️トラッカーとは行動パターンの大分類である。


(ちなみに状態の分類がステータス、意味付けがカテゴリである)

backlogからRedmineにやって来ると、トラッカーって何やねん？お前、本当の名前は種別とか、カテゴリーだろ？かっこつけてんのか？みたいな気がするもんである。

いや、ところが、Redmineの世界では、トラッカーとカテゴリーはもう全くの別物で、
重要度は
トラッカー>>>越えられない壁>>>カテゴリー
である。

あと、カスタムフィールドを使わないbacklogユーザーは、そもそも種別とカテゴリーは似たようなものと認識しているかも知れない。

という訳なので、カテゴリーというものは一旦忘れてしまおう。

Redmineにおいて、トラッカーというのは意味付けを除いて利用者の行動パターンを表したものだ。
行動パターンが変わらないのなら、トラッカーは一緒にしておいた方がいい。

例えば営業から内勤部隊に対して、どういう問い合わせがあるかを分析して、Redmineを拵えようとしているとする。
営業からは、質問が飛んできたり、調査の依頼が来たり、商品のご意見とかが飛んでくるとする。

この時、

うーん、後から分類したくなるかも知れないなー

とか思ったりして、
トラッカーを「質問」「調査依頼」「お客様ご意見」に分けたくなると思うが、ぐっと堪えよう。
実は営業から内勤への問い合わせという行動である事には変わりがないからだ。

もし、営業に入力してもらう内容が何も変わらないのなら、トラッカーは「問い合わせ」にしてしまって、
「質問」「調査依頼」「お客様ご意見」という問い合わせの意味付けをカテゴリにした方がいい。カテゴリは複数指定出来るし。
そして、意味付けは受け側しか整理する動機がないので、入力者にカテゴリ指定を完璧に期待しない方がいい。

Redmineのトラッカーという単位は、
トラッカー事にカスタムフィールドを設定したり出来る。(これはbacklogでいう種別と同じである。)

例えば、クレーム対応の時には、営業には企業名を必ず入力して欲しい、みたいな場合に、
「問い合わせ」トラッカーは自由記入欄しか設けず、「クレーム対応」トラッカーでは独自の記入欄を設ける事が出来る。

実践的にはクレーム報告で企業名を申告しない営業って何者なんだよ。。。という気もするし、凄くリアルな気もするが、
とにかく、Redmineで登場する人達の行動パターンを表すのがトラッカーで、違う行動パターンを管理したくなったら増やす事を考えるのがトラッカーだと覚えておこう。

なお、実務的にはとにかくトラッカーは少ないに越したことはない。
安易に増やすと後で面倒が増えることも覚えておいて欲しい。この点はワークフローで後述する。

◾️ロールとは、役割に名前をつけることである。

　
ロールというのは、Redmineそのものや、プロジェクトや、チケットなど、様々なものに対して何が出来るかを設定し、それに名前をつけたものだ。

例えばチケットの閲覧しかできない人を閲覧者、
チケットの報告は出来るけど削除はして欲しくない人を報告者にする、という具合。

何を出来るようにして、何を出来ないようにするか、
そしてその役割の名前をRedmineでは自由に決める事が出来る。

額面通りに「全員リーダー・全員メンバー」でいいなら、全員が等しい権能であるはずで、ロールを分ける必要はない。つまり、あんまり深く考える必要はない。

一方で、〇〇課の〇〇に機能名が入るような機能別組織の場合、課とロールは限りなく近いものになる。

んで、〇〇課の中には一般職のスタッフメンバーと、管理しているらしい管理職がいるはずなので、出来る事が違う。
Redmine上でも、出来る事が違う方がいい場合もあるだろう。(例:承認の表現、個人情報=プライベートチケットの閲覧とか)

つまり、ロールとは、あなたの組織次第で最適解が変わるものなのだ。

ただ、「とりあえず組織×メンバーと課長の掛け合わせ」を全部ロールに定義するのは、あんまりオススメ出来ない。

重要なのは設計時に見切った実態だし、やはりロールもトラッカーと同様、少ない方が良いからだ。

例えば課長がメンバーに業務を任せて育てたい場合。
管理職が忙しい時の常套句っぽい気もするが、
権限委譲に対して肯定的なスタンスが許されるなら、
機能別の課のためのロールはメンバーも課長も一緒で良いはずだ。
また、顧客対応を外注して外出しするとなったら、
役割自体は増えていないのだから、今まで使っていたロール転用可能なはずだ。

だから自分のRedmineに新しい利用者が増える時、その人達はどういう機能・権限を内包していて、Redmineではどの様に立ち回るのかを見切らなくてはならない。
その上で、既存のRedmine上の設定資産が使いまわせるのかをまず検討したい。

そして、あぁ、この人達は、やる事が違うらしいから、それなら分けた方がいいな、と腹落ちした時に新しく設定するのが、ロールであると覚えておこう。


◾️ワークフローとは、トラッカーとロールごとに、チケットの状態(ステータス)の変化を定義する事が出来る、最後の仕上げである。

いよいよ最後のワークフローの説明に入るが、
そのためにはやはり、まずステータスの説明を避けて通る事は出来ない。

もう何度も司馬遼太郎みたいな展開で大変申し訳ないとは思うんだが、こればっかりは説明を避けて通れない。

ステータスというのは、行動の状態を表したものだ。

まず、チケットとは必ず発生し、そして終了するもの、だとする。

もし、質問には必ず回答出来るなら、チケットの状態とはまだ回答されていない新規のものか、回答が終わった終了したものかの２つしか要らない。

新規→終了
これでオッケーな世界。

しかし実際には、世の中即答出来る質問ばっかりじゃないし、誰かに確認をしたりする必要もあるだろう。

そうすると、

新規→対応中→完了

という3つの状態がある、ということになる。

ただ、この設定で運用すると、「回答されたものが勝手に完了になっちゃう！再質問あるかもしれないのに！」みたいな感じになるので、

新規→対応中→確認待ち→完了

というような、4つのステータスが必要そうだという話になる。

(そして完了されない既読チケットが量産されて行くのだが。。。)

ここまでの感じではbacklogと対して変わらないんだが、例えばこのプロジェクトに割と適当に回答する人がジョインしてしまい、しばらくすると現場から「なんかどうも、実情と違う回答貰ったんですけど。。。しかも何度も。。。」みたいな問い合わせが来たとする。

backlogベースだと、
恐らく「すいません、教育を徹底します」という運用ベースの話しか出来ないと思うが、
Redmineなら、

新規→対応中→上長精査待ち→確認待ち→完了

というように、
確認するワークフローを仕組み化して、
確認待ちにステータスを変更出来るのは現場に上長ロールだけに限定するので、必ず責任者の目に触れるようにします、といった対策が出来る。

それが窮屈でキツそうかどうかは、仕事の規模による。

例えば問い合わせ業務を外注する、新入社員や異動者が常時やってくるなど、教育コストの方が割高になるなら、この仕組み化は恐らく肯定されるだろう。

特に、JSOX系の対応で責任者の証跡を残さなければならない時などは、管理のために項目を増やすより、
項目の操作を制御して実効を管理する方が理にかなっている局面がある。

冒頭にも言及したが、
backlogでいいならこんなワークフロー機能は要らないので、使う必要はない。
ましてやRedmineでも無理に設定して悦に浸るような類のものではない。

けど、サービスが大きくなると、色々な負荷が増え、組織も変わり、関係者も膨張していく。
システムにはスケーリングがある。
ならば当然、組織にもスケーリングがある。

組織は組織されただけではチームにならないのなら、
組織を束ねて組織力を発揮するための仕組みが必要になる訳で、
そういう時に使うのが、ワークフローであり、ひいてはRedmineである。

◾️終わりに(まとめ)

まとめる。
・自分に完全にRedmineを自由に出来るシステム管理者権限があること
・Redmineでいくつかのプロジェクトを表現して設定していくこと
・その中で、トラッカーとロールとワークフローを設定操作し、体に入れること。

この3つの要素で、自分の場合はRedmineが好きになれた。
参考になれば幸いである。

そして、ここまで長文にお付き合い頂き、ありがとうございました。
まだ、Redmineを好きになれない人がこれを読んで、何かに気付いて頂ければ本望です。

◾️終わりに(ポエム)

正直自分は、ずーっとRedmineが好きになれなかった。

backlogみたいにアイコンがないし、既読アイコン付かないし、デザインは地味だし、使いやすいと思えない。
業者さんに建てて貰ったこのRedmine、なんて使いづらいんだろう、ユーザーにフレンドリーな感じが全然しないな、とか思っていた。

だから、Redmineというものは元来使いづらいけどオープンソースだからみんな仕方がなく使っているうちに、巷間に流布されていったもの、と長らく勘違いをしていた。
更に、この推論を正とするなら、有料のプラグインを入れれば解消されるんだ、と思っていた。
当然、全く解消されなかった。

これは勉強が足りないと思ったので、
その製品のRedmineのユーザー会に参加をした。

面白い話は沢山あったし、
よく分からない話もあった。
しかし、心底楽しそうにしている一部の登壇者の人達を見た。

あのユーザー会の日、Redmineというサービスの力を信じるエヴァンジェリスト--直訳すると福音伝道者だ。--と、割と臆面も無く名乗る人達の存在と、
その明るさと前向きさが、ずっと心に残っていた。

自分が見れていない風景を見れている人達を目撃した。
その事だけは、悔しいくらいに理解した。
その悔しさと憧憬の入り混じったものが無ければ、
きっと途中でRedmineを諦めていたと思う。

その福音は、確かに私にも届いた事を、彼らに感謝と共に述べて伝えたいと思う。

この記事が気に入ったらサポートをしてみませんか？