MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから
Microsoft Plannerを使ってみたら、Redmineと違って使いにくかったと感じたのでメモ。
その理由は、自分の用途に合っていないだけ。
ラフなメモ。
【参考】
Microsoft Plannerの活用事例紹介!ガントチャートでチーム運用状況がすぐわかる! - エク短|Extan.jp
【1】Plannerは、簡易なToDo管理ツールと思った方がいい。
Plannerのチケットは、下記で決められていて、カスタムフィールドは増やせない。
・バケット・・・プルダウンで選択する。選択肢は自由に設定できる。
例えば「機能」「顧客」に使う。
Redmineで言えばカテゴリ。トラッカーではない。
この機能が一番大事。
・タグ・・・2個以上自由に設定できるラベル。
タグなので、種類に使う。
Redmineにタグはないので欲しい。
・進捗状況・・・固定のステータス。未着手→進行中→完了で決まっている。
ステータスが固定なので、ワークフローを自由に設定できない。
結局、課題管理に向かないし、現場でカスタマイズしたいワークフロー管理を実現できない。
・担当者・・・複数のユーザを割り当てられる。
・優先度・・・固定の優先度。Redmineの優先度と同じ。
・開始日、期日・・・Redmineと同じく、予定日と実績日は同じ。
・メモ・・・説明欄。
・チェックリスト・・・チケットにチェックリストを作れるのは便利。
しかし、実際に運用してみると、タスクボードにチェックリストは表示されないので、逐一開かないと、チェックリストをどこまで消し込んだのか分からない。
【2】Plannerを使ってみて、ToDo管理以上の進捗管理には向かないと分かった。
Plannerのアンチパターンもある。
【2-1】バケットをステータス代わりに使うアンチパターン。
バケットにワークフローのステータスを割り当てると、Plannerのダッシュボードに円グラフや棒グラフで表示されるのは良い。
しかし、バケットにワークフローのステータスを割り当てる本来の意図は、Plannerの進捗状況は固定ステータスで使いにくいので、その代わりにバケットで制御しようとしているわけだ。
すると、実際の運用では、チケットをCloseする時、バケット=完了、進捗状況=完了の2つを設定する必要があって、割と操作が面倒。
こういう運用は、昔のBugzillaやMantisを思い出す。
BugzillaやMantisでも、Statusとは別に、Resolutionフィールドがあって、Resolutionでバグの解決状態をわざわざ設定する運用があった。
僕はこの運用が嫌いだった。
Redmineのように、ステータス1個で完了にすれば、わざわざ2つの項目で完了の意味をもたせる必要はない為だ。
また、バケットを複雑化したワークフローのステータスに割り当てると、複数のトラッカーのワークフロー制御をしたくなってきて、10個以上のステータスをバケットに割り当ててしまう。
すると、2本上のトラッカーのステータスが混じっているので、バケットから選ぶときに混乱してしまう。
結局、複雑化したワークフローや、複数の業務のワークフロー管理には向いていない。
【2-2】チェックリストをステータス代わりに使うアンチパターン。
チェックリストは、作業リストを分解して、それぞれの細かい作業を割り当てて、細かい作業が終われば消し込んでいく。
当初使っていた時は、自分1人の作業をチケットに書き、その作業をチェックリストに分解して消し込むのはやりやすかった。
しかし、チェックリストとは、結局、1個の作業の流れの中で、今どこまで作業を消し込んでいるのか、というステータスを表しているだけに過ぎないと分かった。
また、チェックリストの項目が10個以上あると、正直使いにくい。
普通は、チェックリストは上から順に消し込んでいくべきだが、10個以上あると、歯抜け状態のような形で消し込むケースが増える。
チェックリストの状況を一目で把握しにくくなる。
さらに、チェックリストはタスクボードに表示されないので、チェックリストが作業順序に並んだ作業の進捗状況を表しているならば、逐一チケットを開かなければ、その状況は分からない。
【2-3】タグをステータス代わりに使うアンチパターン。
タグにステータスを表示させる運用も考えたが、ワークフローのステータスが10個あった時、10個のタグが初期状態で表示されていてそれを1個ずつ消し込んでいくとか、ステータスが進むごとに以前のタグを消しで新しいタグを付け直すとか、運用は煩雑すぎる。
現実的でない。
【2-4】こういうアンチパターンを考えていると、結局、現場で管理したいステータス管理をPlannerでどのように実現すべきか、という問題に苦労しているのが分かってくる。
つまり、Plannerのステータスが固定である為に、現場で出てくる複雑なワークフロー管理をPlannerにフィットさせるのが非常に難しいのだ。
【3】Plannerでは、バケットの使い方が重要みたい。
なぜなら、ユーザが自由にカスタマイズできる機能は、バケットしかないから。
その他の機能は固定ステータスや担当者、期日のように、すでに用途が限られているからだ。
バケットに、分類すべき業務を設定すれば、ダッシュボードで担当者別・ステータス別にグラフ化してくれる。
つまり、バケットには、ToDoリストのタスクを分類したい観点を割り当てるべき。
【4】PlannerのタスクボードをExcel出力した場合、注意すべき点が色々出てくる。
Plannerのチケットに2個以上のタグを付けると、1セルに複数のタグがカンマ区切りで表示される。
つまり、1セルに入ったタグをExcelマクロで分割して取り出す、という操作が必要になってくる。
タグを使いすぎる時は注意。
同様に、担当者も2人以上割り当てられるので、1セルに複数の担当者名がカンマ区切りで出力される。
【5】Plannerで一番不満なのは、Redmineのクエリに相当する機能がないことだ。
全チケットのタスクボードと、自分にアサインされたタスクボードの2つしか選べない。
フィルタでバケット、日付、担当者などをフィルタリングできるが、その検索条件を保存できない。
だから毎回フィルタリングする必要がある。
結局、より複雑なクエリが欲しければ、Excel出力して、Excelデータをいじくり倒すしかない。
【6】こんなことを考えていると、Plannerの設計思想はタスクかんばんなので、そもそも複雑なワークフロー管理をしようとするのが間違っているのだろう。
Plannerをタスクかんばんとして扱うならば、小さな作業を割り当てて、1チケット=1担当者でアサインし、基本は1日1内にCloseする運用にすべきだろう。
そうでなければ、数多くの情報をチケットに詰め込められないので、すぐにタスクが溢れてしまうからだ。
ToDoリストであるからには、どんどんCloseして消し込んでいった方がいい。
つまり、PlannerはGTDと相性がいいのだろうと思う。
タスクをどんどん書き出して、日々消し込んでいくが、毎週の週次レビューで全チケットを見直す。
換言すれば、日々の業務をPlannerに落とし込んで運用できた場合、その業務はかなりルーチン化されていて、細分化されたタスクになっているだろう。
そういうフィットギャップ分析についても考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント