「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の優れた機能をどのように使い分けて、運用の効果を引き出すか、というノウハウが必要なのだろう。
この辺りのノウハウも、色んな事例から抽出してプラクティスないしパターンとしてまとめてみたい。
| 固定リンク
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント
初期の勉強会で,大和田さんと意気投合しました.「○×プロバダーにRedmineはよく合う」と,
外資系企業が考えるプロバイダーの組織構成って,日本企業から見たら横断的です.
投稿: @tech_machii | 2016/04/27 00:57