おしながき
- メンバーは3〜5名、協力企業は1〜2名の小規模チーム
- メインは某小売店の大規模ECサイト案件統括(開発は外部委託)
- サブで基幹連携等を担う周辺業務システム開発・運用
- マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る
- 上長指示により残業削減へ
そんな2〜3年前のお話です。
改善"前"のタスク運用
※あくまで改善"前"の話です。
基本はRedmine + Kanbanプラグインでタスク(チケット)運用。
ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。
- 作業に伴うタスク発行の徹底
- 進捗状況の逐次反映
- そして、運用ルールの入念な教育(五十六メソッドを採用した)
当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが…
おかしいな だれもチケット きらないよ
運用開始から一ヶ月。タスク管理が全く定着しない。
メンバーはおろかPM自身もチケットを切ってくれないので(当時最大の負荷がPMに集中していた)、私が「みんなのチケット管理するマン」として御用聞きをしまくる「あ、これ一番ダメな奴だ」な状況と化した。
参考までに、当時のメンバーからよく出た発言を以下に示す。
メンバーの声
ケース1:「そもそもコレ何のタスクだっけ」
タスクの長期保留により内容が失われるパターン。
丁寧さを心掛けたのでそれなりに詳しく内容は記述されていたのだが、それでも文面だけでは「つまり何のこっちゃ?」な状況は度々発生した。むしろ、「長文を書かなければいけないタスク」 ≒ 「長期化しやすい面倒なタスク」なので、肥やし化して解消されず忘却される率が高かった。
- ポイント①:タスク忘失防止には「記述の丁寧さ」よりも「粒度」が遙かに重要である。
ケース2:「そもそもコレ何でやるんだっけ」
手段や内容は覚えているが、目的が失われるパターン。
大抵は「タスク作成直後は実施に妥当性があったけど、今は状況が変わって必然性が無くなった」という場合に生じる。これもまた「大きなタスク」ほど発生率が高かった。
- ポイント②:タスクには「鮮度」が存在する。
ケース3:「で、コレ誰がやるんだっけ」
メンバー全員がピリつく瞬間である。これもまた「大きなタスク」ほど発生率が(略
タスクを切った直後と現状が異なるので、「最初のアサイン対象者が動けない」という状況も少なくない。結果として無関係のメンバーが押しつけられることとなり、「何で俺がこんなことを」と不満が溜まる傾向にあった。
- ポイント③:「鮮度が落ちたタスク」は争いの火種になる。
ケース4:「そもそもどうやってタスク切ればいいんだっけ」
五十六メソッド大敗北の瞬間である。お前さん、最強のOJTメソッドじゃなかったのか…?
詳しくヒアリングすると「基本の記載テンプレはわかるけど、物事の要旨を押さえた文章に自信が持てなくて書きにくい」ということらしい。一応五十六メソッドに従い、ポイントを事前共有した上で実際の記述を見せ、私自身のバックサポート付きで記述指示まで実施したのだが…それでも誰も書きたがらない。
「ナレッジとして残る」という事実が、「丁寧に書かなければならない」 → 「億劫な気分になる」という最悪のスパイラルを生んでしまったようだ。
- ポイント④:テクニックが必要なタスク運用は回らない。
失敗の統括
失敗から得た学びを以下にまとめる。
- タスク忘失防止には「記述の丁寧さ」よりも「粒度」が遙かに重要である。
- タスクには「鮮度」が存在する。
- 「鮮度が落ちたタスク」は争いの火種になる。
- テクニックが必要なタスク運用は回らない。
つまり、
- 適当にタスクが書けて
- タスクが簡単なのですぐに終わって
- テクニックが無くても簡単に回せる!
という運用方法を考えればいいんだね! なるほど〜!
腕を振り回して叫びたい気持ちを抑えて手段を考える
メンバーの意識の低さを問題にするのは簡単だが、こちとらエンジニア上がりなのでそのような手段は最も嫌悪するところである。何より自己保身のためにエンジニア最大の美徳を忘れてはいけない。
プログラマの三大美徳の一つ:怠惰
全体の労力軽減のために、自らの苦労を惜しんではならない。
…というわけで当初の理想は捨て置き、教科書無視の「これしかない」という方法論を模索した。みんなのチケット管理するマンが最終的に達した結論は次の通りである。
「次に手を動かす作業」だけタスクとして扱う
ややこしいことは一切せず、「次やること」だけ淡々とTodo管理ツールに投げ込み、回す。多少アレンジしてはいるが、基本的な原則はこれ以外に存在しない。
例えば、世間では「ナントカ案件の要件定義」「ナントカの設計」という題名のタスクを作るのが一般的かと思う。当手法ではこれらのような作業範囲が曖昧で重いタスクは作ってはいけないことにしている。
上記のような「要件定義」であれば、
- 顧客にヒアリングする日程を決める
- ヒアリング議事をまとめる段取りを付ける
- ヒアリング議事をまとめる
- 顧客に議事を承認してもらう
- 要件のドラフト資料をまとめる段取りを付ける
- 要件のドラフト資料を作る・・・
等々、作業者にとって完了しないことが難しいくらい低粒度のタスクに切り出してタスク管理ツールに登録する。もしも「状況が整理できていないので直近作業がわからない」という状況なら、「状況を整理(または計画)する」というタスクを切る。
加えて、直前タスク以外は極力登録させない。先々のタスクを登録しないと不安になるかもしれないが、現在のタスクが終われば自然と次のアクションは見えてくるので気にしなくても問題ない。
当然、「タスク管理によるナレッジ整理」なんて考えないし「タスクの詳細内容」も書かない。要は書き捨てである。
※代わりに「○○作業の手順書を作る」等のタスクを切り出し、ナレッジを適切に取りまとめる体制を維持する。
- 適当にタスクが書けて
- タスクが簡単なのですぐに終わって
- テクニックが無くても簡単に回せる!
以上の条件を満たせていることがおわかりだろうか?
そんな単純な運用で案件が回るの?
安心してください。超回りますよ!
タイトルの通り、改善後のPJではメンバーの残業時間が50%以上軽減された。
日常のタスクはみるみる解消され、少しでも気を抜くと作業在庫がなくなるような状況すら発生した。マジで見違えるような改善である。
何故、このような単純な運用が効果的なのか?
実際に確認できた効果を交えて詳しく紹介してみよう。
速攻でタスクが終わるのでゲーム性が発生する
人間は行動のレスポンスが発生しないと物事に対する興味を失ってしまう。一方、この管理手法はタスクの回転速度が異様に速いので、常に「タスク発生」 → 「終了」というレスポンスの嵐に晒されることになる。ミニゲームを次々とこなすような感覚がメンバーに芽生え始めるわけだが、このような状況下では脳内の報酬系が活発に働き十分な達成感が獲得できる。 ※いわゆる「中毒性」って奴である。
加えて、「タスク = 即時潰すもの」という刷り込みが発生するので鮮度も落ちにくい。「このタスクなんだっけ」「なんでやるんだっけ」という会話からもおさらばである。
メンバーが躊躇せずにタスクを作成できる
単純タスクしか発生しなくなるので、改善前のような「タスク作成に対する迷い」「恐れ」がなくなる。すぐ終わる故に「作っておいて終わらなかったらどうしよう」「このタスクを他メンバーにアサインするのは迷惑では?」といった余計な引け目も発生しない。
「やる気を出すにはとりあえず作業を始めること」とはよく言われるが、タスク追加が「作業の始まり」として機能するので「作業始めたくねーなー」という気分で案件がグダりにくいことも特長である。
案件のヘルスチェックが捗る
タスクが「即終了する粒度」で切られているので、「未終了タスクの増加」という単純な尺度を当てはめるだけで負荷集中や難課題が発見できる。粒度が細かい分担当替えも容易なので「負荷の軽いヤツ or 得意なヤツに任せよう」という建て付けも立案しやすい。
メンバーのセルフマネジメント能力が向上する
通常の案件において「次のステップは何か」「どう段取ればよいか」ということをメンバーは考えてくれないし、たとえ考えたとしても適切な結果を導き出せるとは限らない。マネージャと異なり状況を俯瞰できないので当然である。
一方、この管理手法であれば「メンバーでも簡単に追加可能なレベルの粒度」にタスクの大きさが限定されるので、メンバーの能動的なタスク登録が進む。
前述のゲーム性も相まって個人が段取り上手化するので、最終的にマネージャの負荷が激減するレベルまでメンバーのセルフマネジメント能力は向上した。
メンバー個人の市場価値も上がり一石二鳥である。
総括!
- タスク管理は気軽に参加できる仕組みを整えよう!粒度を低くするやり方がオススメだよ!
- 意識が高い運用計画を最初に作るとコケるのでやめようね!
- 「メンバーのやる気がない」とお嘆きのあなた!知恵を絞れば意外と何とかなるよ!
- 何よりも「仕事に快感を覚える仕組み作り」が大事だよ!メンバーを中毒にして組織に貢献させよう!(危険思想)
オマケ:ところで、何故こんな手法を?
その手の知識を持っている方ならお気付きかもしれないが、この手法は「目先のことだけを一つずつやる」というADHD向けのタスクマネジメントをベースにしている。
程度の差こそあれ、問題なく一般生活を送れている健常者でもストレスや職場環境次第で「やるべきこと」に右往左往するパターンは多い。あえて「タスク管理が苦手な人向けの手法」を使うことで、個々人のムラを無くすことが当手法を採用した目的の一つである。
※なお、似た手法をビジネスに持ち込んでいる人は既にいて、私の完全なオリジナルというわけではないので誤解無きように。
なお、本文に書いたとおり、人は「やり始める」と側坐核が反応して「やる気」が発生する。つまり「物事を始められない時間」とは「活力がない時間」であり、「気軽な気持ちで仕事に取りかかれる環境作り」は「活力に満ちた職場作り」とほぼイコールなのだ。
マネージャのタスク管理一つでかくも職場満足度は大きく左右されるのである。まる。
すばらしい。
すぐに真似したくなる、真似できそうと思わせてくれる、というのがポイント高いですね。
重箱の隅ですが、最後の方のまとめは「統括(とうかつ)」じゃなくて「総括(そうかつ)」がふさわしいかな?と思いました。
http://imimatome.com/kotobanoimi/kotoba128.html
>重箱の隅ですが、最後の方のまとめは「統括(とうかつ)」じゃなくて「総括(そうかつ)」がふさわしいかな?と思いました。
誤字の指摘ありがとうございます!
ビックリマークまで付けてて恥ずかしいですね!修正しました!
目からウロコです。
すぐに真似したいです。ありがとうございます!
@niwatolli3
是非是非!手法としてはまだまだマイナーなので、どんどん広めちゃってください!
いいですね!
ちなみに「タスクたくさん作るのめんどくせー」みたいな人は現れなかったのでしょうか?
小さな、すぐできる具体的アクションに切り分けて、とにかく手を付けるのはGTDを初めとした多くの手法で取り入れられてると思うんですが、チームでエクストリームに導入するという点がとても面白いですね。しかも直近ベースで組み立てるというのがとてもいいなと思いました。
質問があるのですが、これって最初からすんなり浸透した感じですか?細かく管理しなくても「タスクはこの粒度で登録します」みたいなルールの徹底だけでうまく運用できたのか、それとも導入の為に苦労したこととかはありました?
タスク管理の核心突いてますね〜
"「次に手を動かす作業」だけタスクとして扱う"
この概念が無い人と共有タスク管理すると破綻するイメージ。
ちなみに変更後もRedmineなんでしょうか?
WrikeやBacklog、Asana辺りでも何とかなりそうなので検討してみます。
@kuri_hei
この手の質問は社内でもよく出ました。
いくつかの案件に適用した結果としての経験則ですが、この手法を使うとタスク工数は一つあたり2〜3h程度に収束します。つまり、8h勤務なら一人につき約2〜3タスク/day発生しますが、「詳細を書かない」ルールもあるのでほとんど負担無しです。実際、運用メンバーから「面倒」と言われるケースはほぼありませんでした。(ただし、未経験者から「面倒そう」と言われるパターンはちらほら散見されたので、誤解を解消するための説明は念入りに実施しました)
@erukiti
運用導入は改善前に比べればずっと楽でしたね。
一方、改善前の方がタスク管理として「きちんとしてる感」があるので、形式主義的な外部の人から疑念を示されるパターンも…。最終的に当記事のような「運用の歴史」「理論」を丁寧に説明して理解を求めました。
@nishiotsutomu
(効率性等とは関係ない諸般の政治的事情で)最近はサイボウズLiveを使ってます。
運用形態が単純なのでどんなツールでもそこそこ回る印象です(むしろ機能がリッチだとノイズが増えて邪魔になるかも…)。記事内のRedmineはもちろん、最悪Excel等の最終手段でもイケるかと!