見出し画像

Redmine運用成功率の方程式

この記事について

この記事は、2020年12月2日にLycheeRedmineユーザー会2020で登壇した際に発表した内容を記事にしたものです。

講演名は『Redmineの運用成功率の方程式と、Lycheeプロダクトの関係性。~本当に酸素ボンベが必要ですか?~』と題しまして、
Redmineに興味がある、Redmineを簡単に使いたい、そのためにLycheeを使ってみたいという過去の私のような初心者ユーザーを想定した登壇内容でした。

資料はこちらです。

その結果、なんというか、ユーザー会での登壇なのに商品の必要性を投げかけるという、割とアクロバットな内容になってしまいました。

本稿では、記事タイトルの通りRedmineの運用成功率の方程式をご紹介していますが、記事としては講演の構成を少し意識していますので、やや枕が長い感じになっています。
Lycheeユーザー会に参加したつもりになって読み進めて頂ければ幸いです。

また、本記事はRedmiineアドベントカレンダー2020の4日目に登録されています。

LycheeRedmineとは、株式会社アジャイルウェアが提供している、Redmineの有料プラグインの商品ブランドです。
ガントチャートをMS Projectのようにリッチな感じにしたり、CCPMやら工数リソース管理が出来たりと、便利な機能を追加することが出来ます。

まず、Redmineって難しいですよね・・・。

この間発売された、Web Designing 2020年12月号の特集「超図解!Webビジネス33ツール」において、「プロジェクト/タスク管理ツール」のコーナーではRedmine、Backlog、Trello、Slack(小冊子でMicrosoftTeams)が取り上げられていました。

WebDも随分と扱うネタが変わったんだなぁ・・・。と思ったりしたのは余談なのですが、タスク管理ツール的に有名処というと、やっぱりそのあたりかと思います。(Jiraファンの人には毎度大変申し訳ないが)

ただ、知名度がある=使いやすい訳ではありません

Redmineの難しさというのは割と郡を抜いていまして、少なくともBacklogの取り回しの良さと比べると、カップラーメンとスーパーマーケット並に難易度が変わります。

何を言っているのか良く分からないとは思うんですが、その辺りの触りについては、詳しくは以下の記事を入口にしていただければと思います。

Redmineは簡単ではありません。
しかし、15年の長きに渡って利用され続けているプロダクトではあります。

ということは、それだけでもう、プロフェッショナルに愛されまくりであることの証左ではあるのですが、
公園に行くような難易度認識と軽装で、登山をしはじめるのは不幸な話です。

タスク管理ツールの隆盛も、情報化社会とかデジタル化とかIT革命とかDXとか、なんかそういうヤツ(雑)の潮流の一旦だとすると、かつては専門家が使っていたものが一般化していくという流れの中にあります。
その垣根が曖昧になって、裾野が広がっていくんでしょうし、公園と山、行きたい所を選べる自由があるのはいいことです。

ただ、山は美しさと同時に厳しさを併せ持つ。

山道で薄着をしていれば、場違いな装備で来ちゃったな、くらいの事は理解すると思うんですが、
Redmineの場合、なんで寒いのか本気で見えにくい。

富士山に背広やハイヒールで登山しちゃう人が、増えないといいなぁと思っています。

Redmine運用成功率の方程式

有料プラグインというのは、やっぱり商業的なものなので、営業さんの口上も相まって、初心者さんなんかは『これを買えば山頂まですぐに登れちゃうかも!?』なんて思ってしまう場合もあると思います。
少なくとも私は過去、そう思っていました。

それが酸素ボンベを見てロープウェーを想起するような都合のいい幻想なのか、
実はそういう認識のお客さんが多くて契約継続率がテーマになっているのかは、中の人ではないので分かりません。

けど、有料プラグインを使うなら、やっぱりRedmineの利用における基礎体力が必要になる事だけどは事実です。

でも基礎体力と言ったところで、漠然とはしている。

じゃぁ式に因数分解しながら整理してみればいいんでないの?と思いついて、こねくり回した結果、
私の考える方程式は、このようなものになりました。


Redmineの運用成功率 =
(信用貯金力 × 業務設計力 × Redmineの理解度) × 技術力

※技術力は1以上の整数、それ以外の変数はMAXの値が100%になります。
※方程式には人の数だけ諸説あります。

各変数の内訳はこんな感じになります。

信用貯金力
仲間の数やレベル、やるき、組織、立場、上司、決済権

業務設計力
業務に対する理解度、プロセスの再構築や最適化。

Redmineの理解度
Redmineの基本的な仕組みや考え方の理解

技術力
Web、サーバ、プログラムなどの技術理解と実践力

実際にサンプルで計算してみよう!

早速、適用例を見ていきましょう。
「あー。それっぽいなぁ」と感じて頂けるといいのですが。

例1:推進部署で働くリーダー的存在が、Redmineをみつけて、よく分からんけど、やってみるぞ!みたいな場合

X = (0.8 × 1 × 0.1) × 1
X = 8%

このケースでは、元々職場や会社をよく知るリーダーが、Redmineを見つけてきた、という感じなので、

・仲間はいないけど、やる気と決裁権がある(0.8)
・業務理解はバッチリだぜ(1)
・でもRedmineは分からん。(0.1)
・技術系の専門職ではない(1以上なので1)

という想定です。

計算すると、結果は運用成功率は僅かに8%なのですが、
そりゃ手段が目的化してしまったら、1年後に廃墟になるのは簡単に想像できる訳で、それを運用の成功とは呼べなさそうです。

もし、Redmineの理解度が1だったのなら、確率が80%まで跳ね上がるのに・・・!というのが悔しいポイントです。

では次の例。

例2:
転職してきたRedmineが得意なエンジニア畑の人が、業務にRedmineを適用しちゃうぞ!の場合


X = (0.5 × 0.3 × 1) × 5
X = (0.15) × 5
X = 75%

この例では、転職してきた人は、

・信用貯金は無いけど、採用されている訳なので一定度の期待はある(0.5)
・業務は基本的な流れとかは分かるけど、知らん事の方が多い(0.3)
・Redmineの理解度はバッチリだぜ!(1)
・サーバの設定は余裕だし、検証用の環境作るのも苦では無いし、そもそもDockerとか使って環境構築作業そのものを効率化すればいいんでないの?(5)

というような想定です。

転職したてで信用貯金がなく、業務理解がおぼつかなかったとしても、技術力はトライアンドエラーへの挑戦コストを下げます。

技術力があると、上手くいかなくても、上手くいくまでやればいいじゃん?という行動が取りやすくなる、というのがポイントです。

ただ、この記事の最後で後述しますが、
Redmineが得意な人って業務知識が無くても凄い勢いでフロー理解して整理出来るので、実値はもうちょい上方修正な気はします。

なお、方程式は因数分解をする人や職場の文化によって、変数や係数は異なるものだと思います。

なので、「いや、こうじゃね?」とか、「いやこれが足りてないんでないの?」という観点があるのが自然で、それでいいんだと思っています。

色んな方程式があるんだろうなぁ、他の人の方程式も見たいなぁ、と思っているので、思いついたら是非教えて下さい。

方程式の精度や議論は一旦置いておいて、
重要なのは、

・足りてない要素を整理して認識する(済)
・足りてない要素を補う選択をする。
・Redmineの理解度ってなんやねん。

という3点です。

2点目の、足りてない要素を補う選択をする、という点について、
講演では、LycheeRedmineのプラグインや関連製品群が、信用貯金を稼ぐ・効率化する、業務設計やプロセス改善に有利に働く、Redmineの理解度を補う、技術力を補うの、どれにプロットされるかを勝手に整理してみました。

世の中に数多ある、フリーのRedmineプラグインも、もしかしたらこのような分類が実は出来るのかも知れないのですが、
今回のポイントは以下の部分です。

最近のアジャイルウェアさんの開発傾向としては、信用貯金を稼ぎやすくする商品群に力を入れていたのを見ると、よりハイエンド向けな空白地帯を開発してたんだなぁ、というような感想を持つんですが、まぁそれは余談として。

酸素ボンベを買えば、モチベーションになったとはしても、
山登りは上手くならないし、いる場所も変わりません。

Redmineの理解度を上げるプロダクトって、本とかコンサルティングとか知識や経験のような形態であって、有料製品を買っても理解度自体が上がる訳ではない、という話です。

Redmineの理解度を上げるにはどうしたら・・・?

さて、Redmineの理解度を上げたいと望む方にとっては、いよいよ本題なのですが、私の考える目指すべき状態理解度を上げる方法とを説明したいと思います。

目指すべき状態

Redmineの理解度において目指すべき状態とは、
「業務フローをこうしたいんだよねー」という相談を聞いて、
トラッカー・ロール・ワークフローといったRedmineの設定例をスラスラと頭の中で思い描いた上で、全体への影響が分かる状態です。

例えば、こんな相談を受けたとしましょう。

利用部門の上長が承認したチケットのみを完了出来るようにしたい。

この業務フローをRedmine上の設定で実現するには、
例えば以下の2つの設定例が思い描けます。

回答例A:

『上長承認』ステータスを追加して、『上長』ロールを作成。
現在利用しているトラッカーのワークフローで上長ロールのみ、
上長承認から完了に出来るように変更する。

回答例B:

『上長承認』カスタムフィールドを追加し、『上長』ロールを作成。
現在利用しているトラッカーのワークフローで、上長ロールのみ、
上長承認を入力出来るように変更し、
未入力状態では完了ステータスに変更できないようにする

その上で、

トラッカーは共通で、プロジェクトごとに関係者が利用しているような環境の場合、環境利用者への影響が大きいのはどーっちだ?

こんなクイズに迷わずAと答えられる状態。

こんな状態であれば、Redmineの理解度はバッチリと言って差し支えないと思いますし、仲間がこのレベルなら自信を持って運用設計のヒアリング業務に送り出せます。

これが、目指すべき状態です。

私の考える、Redmineにおける良い修行の要件

・・・とは言っても、『そんなRedmine星人の常識を押し付けないでくれ・・・』という風に思われる方が、ここまで読み進めていることは理解していますので、最後のRedmineの理解度を上げる方法へ、話を進ます。

といってもですね・・・。

よい修行の方法はポコポコ増えないとは思うんです。

結局の所、私が思う良い修行は下記の3つとなります。

1.一人で修行しない。仲間を見つける。出来れば師匠を見つける。
2.Redmineでなきゃダメな理由を見つける。
3.最後は体で覚える。

1.一人で修行しない。仲間を見つける。出来れば師匠を見つける。

『とりあえず岩を斬ればいいじゃん鉄板だし』という人もいるとは思うんですが、
岩というのは「本人が思っても見なかったブレイクスルーが起きた、想像し得ない結果」であって、本人が「岩くらい斬れるんじゃね?」って思っていたとしたら、それは想像し得ない結果ではないので、岩の機能にならないんですよね。

鬼滅でもダイ大でもドラゴンボール(の場合は動かす?)でも、師匠が「そろそろ斬れる段階だ」というのを見越して与える課題が岩の形状をしているという事なので、つまり重要なのは岩ではなくて師匠という話になります。

さて、Redmineにおいても師弟のような関係性を固定する枠組みは、割と機能すると思っています。

理由は2つあります。
まずRedmineはOSSプロダクトなので、関わり方や使い方が本当に無数にあり、その上前提となる業務経験が人によって違いますので、結果的に解決手法や気付きとして語られことが、人によって結構バラバラです。

問題解決のアプローチが、レイヤーが浅そうな方から利用上の工夫、運用設計と設定、プラグインの利用や開発、DB、サーバ、環境、Redmine本体そのものと、もう多岐に渡ります。

そうすると、自分にピッタリの課題解決アプローチを、自分が知らないのに探求するという事になりますので、つまりは教育とか修行とかそういう話になっていくんですが、
この人のようなアプローチがいいかも、と、理想の師匠を勝手に定めてマネていくのが結果的には早道だと思います。

2点目の理由として、Redmineにおけるトラッカーという単語が非常に多義的な単語だからです。

Redmineにおいて、トラッカーという用語はある意味一番重要といってもいい単語です。

私の場合は、トラッカーとは「行動パターンの大分類です」という回答なのですが、
調べれば調べるほど、カテゴリーのようなものなのか、帳票を切り替えるものなのか、トラッキング用の目印なのか、Redmine特有の何かなのか、一体何なのかわからなくなってくると思います。

そして、私が思うに「それら全ての回答が正解」です。

・・・なんだか禅問答のように思うかも知れないのですが、例えば「国家」という単語を説明する時、実は大体どのような回答をしたとしてもそれっぽい回答として成立します。

回答が、『国家とは、税金だ』『国家とは、政治だ』『国家とは、人を大切にすることだ』『国家とは、甘さだ』『国家とは、みかんのようなものだ』だとしても、国家という曖昧模糊としたバカでかい主語だと、どのような言葉を紡いでも、それらは国家の一面を表した説明に聞こえてしまいます。

んで、トラッカーという単語も、実は同じようなことが起きているんじゃないか?だから、人が人に説明する中でしか、正解がないのではないか?
というのが私の仮説で、
今年の頭の方ではそんな変態的な話題が続いてTogetterにまとまったりしています。

Redmineの得意な人の語る、知識や経験や用語認識もバラバラだとすると、
その事を知らずに沢山の人のアドバイスを聞くと全員違うことを言っているようにしか聞こえなくなるので、
関係性を固定して、入ってくる前提が崩れない上でRedmineを習得するのが一番効率的だと考えています。

そう、それってつまり、一番理想の師匠は職場のRedmine使いの先輩ということになります。

ただ、Redmineの問題点として、既存の管理者は運用しているRedmineが大切であればあるほど、新参者の無手勝流な人にシステム管理者権限を渡すことを躊躇します。

家の鍵を子供に渡すのって、結構不安だよね、とか、そんな感じです。

また、自分が会社におけるRedmineのファーストペンギンだぜ、なんて場合は、自分で頑張るしかない訳ですが、やっぱり一人は寂しいもんです。

さて、そんな時に頼りになるのがやっぱり外の世界なわけで、RedmineはOSSということもあり、「私の体験や知恵を後に続く人にお伝えしたいんだ!」という心の優しい人が、とにかく沢山います。

どこにいるかというと、こんな所にいます。

■SNS
Twitter(鉄板)
Redmine Free Salon(Slackワークスペース)

■イベント
redmine.tokyo (年2回)
Redmine大阪 (年2回)
Redmine Japan(年1回)
Lycheeユーザグループ(イマココ)

特にオススメなのがTwitterで、Redmineの事を呟けば、どこからともなく色々な先達が結集してきます。マジで。

そして、やっぱり外せないのはイベントです。
redmine.tokyo、そしてRedmine大阪は約10年の歴史がある老舗のユーザ会で、岩を切るどころか海や空間を切れそうな人達が参集する、最高峰のイベントです。

あるいは、いやそんなトップリーグはちょっと怖くてまだ行けないぞ・・・?という方は、Slackで質問して様子を探ってみるのもアリかも知れません。

Slackの主催者、僕なんですけども。

Redmineの魅力というのは、その実、人の魅力や面白さの総和です。
「この人は凄いなぁ」「タメになる事を言っているなぁ」という人を追っかける楽しみ方が、本当にオススメです。

2.Redmineでなきゃダメな理由を見つける。

話をもとに戻しましょう。
2つ目の点は、本当に人によって様々だと思うのですが、

私の見つけた理由は、
『ワークフロー機能、つまり権限や承認による、組織的な統制の設計自由度が高いこと』
というものでした。

ぶっちゃけBacklogのほうが簡単に使えますし、BacklogでいいならBacklogでいい、という一年前の結論は今も変わっていませんが、Redmineでしか出来ない事も結構沢山あります。

その辺りは、下記の記事を参照して頂ければと思います。

3.最後は体で覚える。

最後は勿論、反復練習です。

業務フローを満たすRedmineの設定を漏れなくやるには、
Redmineをある種のチームワークを実現するためのフレームワークだと見立てて、色々な設定をいったりきたりすることで、体に染み込ませていく時間が必要です。
私の場合はプロジェクトを30個位設定したら、体が覚えました。

そして、これを繰り返していると、業務フローをRedmineに設定しているつもりが、Redmineが業務フローの曖昧なところを可逆的に教えてくれるようになります。

あ、この人はワークフローが曖昧な状態で僕に相談をしているなぁ、とか、ロールという概念が曖昧な状態で悩んでいるなぁ、とか、
そういうのが自然に気がつく状態になります。

ここまで来たら、体が覚えているという状態といって差し支えないでしょう。

おわりに(まとめ)

という訳で、まとめます。

・Redmineって難しい。
・Redmineの運用成功率は方程式がある。自分に足りない製品を選ぶのが重要。
・有料プロダクトを買ってもRedmineの難しさは変わらない。
・Redmineの理解度がとっても重要だよ。
・理解度において、目指すべき理想の状態ってのがあるよ。
・理解度を上げるには、一人でやらずに、理由を見つけて、最後は特訓だよ
・理解度があがると、仕事の見え方が変わって面白いよ!

というお話でした。

最後に、Redmineが上手になると、どんな良いことがあるのかを語っていませんでした。

端的には、まず自分の業務が効率化したり改善したり、管理出来るようになったりするのですが、
自分の仕事をRedmineという共通言語で抽象化出来る事によって、様々な人が変換したノウハウや財産に触れられるようになります。

そのスピード感と爽快感と暖かさに夢中になった人達が、Redmineのユーザーイベントを10年以上の長きに渡って継続して、発展させています。

面白い海外ドラマの見分け方として、シーズンが長く続いている作品は面白いから続いているという法則があるそうなんですが、ユーザ会も同じだと思います。
面白くなきゃ、こんなに続かないです。

Redmineという共通言語を使って、技術も理学も人間工学も、ありとあらゆる話題が飛び交うのは、本当に楽しいです。

この記事が、あなたのRedmineライフの一助になったり、あわよくば初めのきっかけになれば本望です。

最後までお読み頂き、ありがとうございました。
講演を聞いていただいた方も、勿論ありがとうございました。
反応やコメント、本当に励みになります。

それでは、また何処かでお会いしましょう。

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