「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしいのでリンクをメモ。

【参考】
RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

はてなブックマーク - RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

【1】IoT企業特有の問題点を読むと、ハード業務はWF型開発、ソフトウェア業務はアジャイル開発なんだよなあ、と改めて思う。

(引用開始)
IoT企業特有の問題

1. タスクが複数の開発レイヤーにまたがりまくる
2. お問い合わせ対応も横断的
3. ハードとソフトで開発サイクルが違い過ぎる
(引用終了)

ハード業務は文字通り、硬くて融通が利かない。
出荷してしまうと、元に戻せないしリセットも出来ないから、前工程で品質を100％くらいの気持ちで作らざるを得なくなる。

また、IoT企業でなくても、最近のメーカーはどこもソフトウェア開発部隊を持っている。
すると、今までの製造業の文化とソフトウェア開発の文化は全く違うので、製造業の成功体験をソフトウェア開発に持って行って、だいたい失敗する。
最近の日本で、人工知能やデータマイニングが弱いからソフトウェア開発を強くしよう、という話が多いのは、たぶん製造業の成功体験に引きずられすぎて、ソフトウェア開発はアジャイルな開発スタイルが向いている、という発想に持ち込めないからだと思う。

【2】色んなツールを試した結果、Redmineを選択して成功したらしいが、そのメリットが下記に書かれている。

(引用開始)
1. 気軽に横断的なプロジェクトがつくれる、そこに小さいプロジェクトをネストできる
2. ガントチャートが標準でついている
3. カンバンのプラグインも充実している
4. 当然ソースをいじって自分たちなりのカスタマイズができる
(引用終了)

ハード部隊やソフト部隊、カスタマーサポートのように、業務の内容も業務に携わる従業員の気質も全く違う場合、ただでさえ作業の連携は悪い。

ハード部隊の人はとにかく真面目で、軍隊のような組織に近く、チーム連携を重視する。
ソフト部隊の人はとにかく自由で、自己主張が激しい部分がある。
カスタマーサポートの人は対人関係のやり取りが強く、営業マンに近い。

そんな多様な気質のチームの間で、一つのツールで作業のやり取りや情報共有を一元管理したくなる。

Redmineのメリットを読むと、複数プロジェクト機能・ガントチャート機能がデフォルトであること、カンバンはプラグインで機能追加できることがあげられている。
確かに、全く気質の違う人種のチームが複数ある場合、一つのプロジェクトにまとめてチケット管理するよりも、別々に管理する方が、チケットを起票する人達もやりやすいと思う。
つまり、機能別組織に複数プロジェクト機能を対応付けて、それぞれのレイヤーで作業をチケット化して、管理する方がチケットの粒度もまとめやすいし、プロジェクトごとにチケット管理の特徴を出しやすい。

【3】但し、「導入にはRedmineエバンジェリストみたいな人が必要」という指摘がすごく心に残る。

(引用開始)
ただここで大事なことを言っておくと、やはり導入にはRedmineエバンジェリストみたいな人が必要がだと思います。
正直いなかったらやってなかったですね。
今は調整しつつめざせSpreadSheet撲滅という感じです。
(引用終了)

「導入にはRedmineエバンジェリストみたいな人が必要」の意味は、IoT企業の業務とRedmineの機能をどのように対応付けて、自分たちがやりたい開発プロセスをRedmineで実現するか、というフィットギャップ分析が重要であり、それが出来る人がRedmineエバンジェリストなのだ、と僕は理解している。

Redmineはオープンソースでありながら、機能も豊富でUIも使いやすいし、WF型開発でもアジャイル開発でもサポートデスク管理にも使えるという柔軟性を持つ。

しかし、多様な業務を、唯一つのRedmine運用ルールに当てはめることは当然無理であり、破綻する。
それぞれの場面で、Redmineの優れた機能をどのように使い分けて、運用の効果を引き出すか、というノウハウが必要なのだろう。
この辺りのノウハウも、色んな事例から抽出してプラクティスないしパターンとしてまとめてみたい。