RedmineはITソリューションの一つ~情報システム部門のタスク管理とIT全般統制 #RxTstudy
第5回RxTStudyで @akahane92さんのスライドが素晴らしいのでリンクしておく。
@daipresentsさんの楽天の事例と同じくらいのインパクトがあると思う。
【参考】
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索
情報システム部門のタスク管理やシステム監査、内部統制などにRedmineを導入した事例について講演されている。
ここまで自社のRedmineの運用事例を詳しく細かく公開されているのは非常に参考になる。
面白いと思った点は二つある。
一つは、ITSが持つチケット管理の特徴をうまく業務に当てはめていること。
一つの事案を複数のチケットに対応づけたり、チケットの種類やワークフローに相当するトラッカーを4種類に絞って運用したり、作業履歴やトレーサビリティをシステム監査に使うなど、ITSの特徴を理解して、業務に適用している。
いわゆるERP導入におけるフィットギャップ分析を、自分たちの情報システム部門の業務とITSに当てはめて実践されたのだろうと思う。
その意味では、RedmineをERPとみなした事例として、かなり成功した事例に相当するのではないだろうか。
もう一つは、社員の行動が局所最適化から全体最適へ変わったこと。
最初は単にチケットに記入して記録するだけかもしれない。
だが、チケットに作業履歴が残ることによって、他メンバーとコミュニケーションできる共有の基盤ができる。
いつでも過去の作業を検索できることによって、現状の作業をより深く理解することを促すこともできる。
つまり、きちんとしたインフラさえあれば、メンバーは自ら行動して、目の前の問題を自発的に解決していくようになる。
ファシリテーションでよく言われる「解けない問題を解ける問題に変換すれば人は自然に問題を解決する方向へ動き出す」という言葉を連想させる。
個人的には、どんなチケット集計機能が有効だったのかを知りたい。
蓄積されたチケットはナレッジないし資産であり、その資産を有効活用するには、いろんな観点のビューがあると便利だ。
それらのビューを意思決定の支援のために使うのが本来の目的だから。
アジャイル開発でも品質管理でも、有効なビューは既に提示されている。
例えば、アジャイル開発なら、タスクボード・バーンダウンチャート・パーキングロットチャート・バックログなどのビューがあり、そのビューはどの状況で使うと有効なのか、は既にその界隈では知られている。
品質管理でも、信頼度成長曲線、管理図、テストケース消化曲線などのビューをどのように使えば有効なのか、も既に知られている。
でも、それ以外の場面でチケット管理システムを使う場合、どんなビューを使うと便利なのか、というノウハウはまだまだ足りない。
例えば、IPAが公開した定量的プロジェクト管理ツールは、その一つの事例を示していると言えるだろう。
Redmineをアジャイル開発に適用するだけでなく、IT企業の業務全般へ適用するノウハウはもっと可能性があると思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「プロジェクトファシリテーション」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想(2020.08.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント