No more Death March

あるSEのチラシの裏 C# WPF

Excel職人が初めてRedmineを使って思ったことのメモ

今更ながらRedmineを使い始めたので色々とメモ

Redmineを使い始めた動機

 Redmineについては名前を聞いたことがある程度で最初からRedmine自体を覚えようとかそういった意識があったわけではない。所謂Excel職人なエンジニアなので今までタスク管理とかプロジェクトの進捗管理Excelでやっていたのだけどいい加減意識して改善しないとまずい状況になってきたという動機。

Redmineを見つけるまで

 手始めにガントチャートを手軽に作れる方法はないかと検索していて見つけたのがRedmine、他にも有名所のグループウェアの紹介サイトは山ほど出てきたけども今の社内でもある程度運用されているものがあるので可能な限り安価で手軽に人柱になる方法を考慮した結果Remineを試そうという結論に至った。

環境構築

 自分のスキル的にWindowsズブズブで0から学習してWebサービスを立ち上げるのは現実的ではない(ほんとは勉強したいところだけど・・・)、そこでWindowsへ導入する方法を検索したら最初に以下の記事がヒットした。

qiita.com

 どうやらオールインワンパッケージなるものが公開されているらしく、これなら自分のPCで検証出来そうと思いさっそくインストーラーをダウンロード

bitnami.com

 インストーラーを起動してぷちぷちするだけでRedmineにアクセスするところまでたどり着けた。

最初の最初にやったこと

 とりあえずはどういう機能がありそうか見た目で想像しながら色んなタブを表示してみる。唯一既定の設定が認証を不要とし匿名のアクセスを受け入れる形になっているようなので認証は必須とした。

 ある程度ページの構成が分かったところでプロジェクトを作っていくつかチケットを登録・編集しながらガントチャートとにらめっこしていた。

少し触ってみての感想

 率直に「いいなこれ」と思った。トラッカーやロール、カスタムフィールド等、プラグインを全く入れていない状態でもかなりのカスタマイズが効くし、プラグインをある程度使いこなせば市販のグループウェア相当の働きは十分にしてくれると思う。いやいや、市販製品だって使いこなせば・・・というのは事実だと思うが正直あれやこれや出来たとしても日常的に利用される機能ってのは極々シンプルなものになりがち。

懸念事項

 本題はここ、業務で取り入れていくうえで不安になった点があるのでいくつか書いていく。今後使いながら落としどころを探求していきたい。

UIが使いにくい

 自分がWebサービスをあまり使わないので慣れていないせいか入力のUIはかなり使いにくいな、と思った。慣れれば大丈夫だろうとも思ったけども人に勧める上で多少なりとも反発が起きそうな感じがした。しかしプロジェクトを管理する側の立場で当初の計画を立てるにあたって大量にチケットを入れるというのには不向きというだけで、日常的に小さいタスクの粒度で向き合う分には気にならないのかもしれない。

プラグイン入れるか否か

 魅力的なプラグインがたくさん公開されていて大変有難いことだけどどうしても互換性に関しては気になるところ、個人で使っている分にはがんがん入れちゃいましょうというところだけど組織で使っている以上プラグインにどっぷりつかっていたがある日を境にプラグインの更新が止まり、ハードや周辺ソフトのライフサイクルの事情からプラグインに依存していた部分は全て捨てなければなりません。となると辛い。
 標準の状態で多少の工夫で解決出来そうな問題であればその方が良いと思う。新しくメンバーが入ってきた時にもなるべく標準に近い形の方が習得や慣れにかかるストレスが少なくなるだろう。

祝日管理

 前項に付随して使い始めのこと誰もが最初に「あれっ?」ってなるところなんじゃないかと思う。祝日や会社の設立記念日等加味したうえでガントチャートの線が伸びてくれるかなぁ・・・くれないよなぁ・・・・
 とりあえず祝日周りのプラグインくらいは入れた方がいいだろうなぁ・・・と思いつつ祝日や有給をチケットという形で入れてみることとした。

プロジェクトの粒度

 これも悩ましいところ、ぱっと浮かぶのは部門毎にプロジェクトを分けるというところ。営業、開発、総務という大まかな区分があって、営業なら新規開拓か既存の顧客か、開発なら製品毎だったり製品毎でも1次リリース2次リリースみたいな区切りが想像出来る。
 これは組織の人数や事業所の具合なんかに大きく左右されるところと思われる、正解なんてないが注意しなきゃいけないのは考え無しにプロジェクトを乱立させるっていうのは悪手だろうなということ。他のグループウェアと同じように自分達の組織形態に合わせたノウハウの蓄積が必要になるところなんだろうな。とにかく管理管理と固執して最初っからガチガチに決めてさぁみんなでルール通りやろうぜは大体得るもの以上に失うものが多い失敗パターンの典型。
 まずは今自分が管理しているプロジェクトのそこそこ規模の大きいマイルストーンを一つのプロジェクトにして行くことにした。(所謂〇次開発単位程度の粒度)

小さくチケットを切るという癖とつけたい

 自分が開発する時は小さなミスであってもこまめにチケットを切って行こうと思っている。例えば〇〇画面作ってたらこういう部分でつっかかって〇時間かかっちゃったので気を付けようとか、体裁とか気にせずメモ帳でもエクセルでもなんでも良いから書き留めて置く、チームでの管理っていうのはなかなか難しいところがあるんだけども個人単位でもこういうナレッジを溜めておくと命拾いすることが本当に多い。
 こういう気づきをとりあえずチケットで残す癖をつけ、隙を見てWikiに落とし込んでいく、という風にすればメンバー同士でもノウハウを共有しやすくなるんじゃないだろうか。

小さい視点と大きい視点の明確な切り分け

 前項の話も大事なのだけど当然プロジェクトの状況を俯瞰して見たい。普段は個人レベルのナレッジとして、上長や経営者と共有する部分は大まかなレベルで。ガントチャートをスムーズに切り替えれるようにするにはどうするか、標準の状態で出来そうなことで思いついたのは二つ、まず、どちらも親チケットでフェーズを大まかに区分することには変わらない、空のプロジェクトにチケットを登録する時にExcel職人してた時と同じように報告の単位でチケットの木構造を作っていけば良い。
 二つの手段で違うのはここから、一つ目はトラッカーでチケットに「報告用」という目印をつけること。報告の単位に全て同じトラッカーを付けてガントチャートでトラッカー単位でフィルタリングしてやれば良い。が、ここで一つ踏みとどまった。「報告用」と一口にいっても大まかな分類でも今後その性質に基づいて切り分けをしたい場合が出てくるのではないか?ということ。 例えば同じプロジェクトでもある程度進行して行くと業務の性質毎にチームの作業を細分化する場合がある。そうなるとどうやってチケットに目印をつけるか、自然に思ったのはそりゃトラッカーで「〇〇業務」とかつけるだろうということ。「報告用」と目印をつける手段とはトラッカーというリソースが競合してしまう。
 そこで二つ目の手段として思いついたのはユーザーを使う方法、「報告者」というユーザーをプロジェクトに参加させて俯瞰するための粒度のチケットの担当者に割り当ててやる。そうすればトラッカーは作業内容な業務を分割するための目印として利用出来る。

カスタマイズは極力避けたい

 標準の状態でトラッカーを増やしたりカスタムフィールドを増やしたり工夫の余地は色々あるようだけどカスタマイズはなるべく避けてシンプルに使いたいなと感じた。エクセルの資料でも他のグループウェアでも安易にあれを追加これを追加とすると管理コストや入力コストがどんどん増えていく割に後からやっぱりいらなかったとかそもそもこれなんのためにやってるの?という状況になりがち。

さいごに

 大分だらだら書いてしまったけどまとめるとExcelであれやこれやファイルを管理するよりは断然良い感じ、しばらく使ってみてノウハウが出来たら社内に布教するかな。