そのタスクを本当にやりたいか

ITコーディネータの吉田聖書よしだみふみです。

タスク管理の手法にはいろいろありますが、
その中でも有名なのは
緊急度と重要度のマトリクスで
整理する手法でしょう。

Read the rest of this entry »

「みんなでやる」は誰もやらない

ITコーディネータの吉田聖書よしだみふみです。

プロジェクトを進めていくうえで、
役割分担を明確にするというのは
基本中の基本です。

担当者が曖昧なタスクは
責任が曖昧なまま放置されることになります。

Read the rest of this entry »

ドキュメントは7~8割の完成度を目標に

ITコーディネータの吉田聖書よしだみふみです。

職種によっては、様々な資料(ドキュメント)を作成する一方で、
部下やチームメンバーにも作成してもらうことがあるでしょう。
その時、暗に100%の完成度を求めていないでしょうか。

Read the rest of this entry »

管理することは監視することとは違う

ITコーディネータの吉田聖書よしだみふみです。

「管理」という仕事はよく誤解されているのではないか
と思うことがあります。
ラインの管理職だったり、
「ナントカ管理」と呼ばれる業務であったり、
ごく普通に使われるにもかかわらずです。

Read the rest of this entry »

本当はこの仕事をやりたくありません

ITコーディネータの吉田聖書よしだみふみです。

以前、ある管理職の方から
「技術的な」課題が山積しているので手伝って欲しい
ということで、紹介を受けて支援に入った時の話です。

Read the rest of this entry »

かんばんボード(タスクかんばん)のレーン設計

以前、かんばんボードを導入する肝はレーンの設計にあるということを述べたのですが、では具体的にどのようにレーンを設計すべきかというテーマについて考えてみたいと思います。

レーンとレイヤーのイメージ

レーンとレイヤーのイメージ

その前に、レーンをさらに横のレイヤーに区切って使うかどうか迷うと思いますが、個人で導入する場合はともかく、チームで導入する場合にはレイヤーに区切った方が良いです。また、区切るとしてもメンバー毎のレイヤーとするか案件毎のレイヤーとするか迷うのですが、案件毎にした場合、時間の経過による案件の増減に合わせてレイヤーを増減させなければならず、それはそれで運用に手間がかかります。メンバー毎のレイヤーにしておけば案件の増減に比べればメンバーの増減は少ないと思いますので、比較的手間はかかりません。それとメンバー毎としておけば、メンバーの生産性と抱えている作業量についてもある程度可視化できるので、チーム運営はしやすくなります。

そうはいってもメンバー毎のレイヤーにすると、案件ごとの状況が見えなくなってくることがあります。(だから案件毎のレイヤーにしたいという衝動に駆られるのですが。)私はタスクかんばんは目の前の仕事を片付けるためにチーム運営を円滑化するツールだと理解しているので、案件毎の進捗管理などはWBS(ガントチャート)のような全体を俯瞰できるツールを使って補う方が良いと考えています。

オーソドックスなレーン設計はToDo、Doing、Doneです。ToDoはやるべきことで未着手のタスク、Doingは現在仕掛中のタスク、Doneは仕上がったタスクです。タスクを付箋に書き出し、ステータスが変化するごとに貼るレーンを変えていきます。あるいはチーム内で完結する現場であればこれだけで事足りてしまうかもしれません。週次でマイルストーンを決めてToDoに落とし込み、週末にToDoが全て捌けてDoneに移動していればよいのです。週末(または週の頭)にはチームでミーティングを行い、翌週(または今週)やるべきタスクを棚卸してToDoに貼り付けていきます。

しかし、業種業態や活動の目的によってチーム外の関係者の多少が違うので一括りには出来ません。チーム内だけで完結しない場合、先ほどの3つのレーンだけでは管理できない局面があります。それは、チーム外の関係先に依頼するような場合、こちらの都合ですぐに返事があるわけではありません。つまり相手のタスクが終わるのを待っている状態、自分ではなく相手がボールを持っているということを表現する必要があります。そのタスクを例えばWaitingのように表します。

また、逆にチーム外の関係者から依頼を受けるパターンや、自分が完遂した作業を確認してもらったり承認してもらったりするパターンがあると思います。既に自分の手を離れていて、最後の確認や承認を待っているという状態です。そのタスクを例えばFinishingのように表します。ここまではメンバー毎のタスクです。


かんばんボード(タスクかんばん)導入の肝

タスク管理の手法というのはいくつかあると思うのですが、その中の一つに「かんばんボード」(あるいはタスクかんばん、タスクボードとも言うらしいですが)という見える化によるタスク管理手法があります。基本はアナログですが、タスクかんばんを実現するアプリも存在するようです。

かんばんボードの原理は簡単で、チームが持っているタスクを全て付箋に書き出してホワイトボードに貼り付けるのですが、ステータスによって貼り付ける位置を変えていくというものです。でも、これを本格的に取り組もうと思っても教科書的なものが見当たらない。ネットで調べると多少それらしきものは見つかるのですが、いざ取り組んでみようと思うとなかなか難しいのではないかと思います。

やってみると分かるのですが、実はかんばんボードを使いこなす肝はレーン(ステータス)の設計ではないかと思うのです。レーンというのはボードを縦に区切った言わば列のことで、通常はステータスを割り当てています。(但し、必ずしも列という形にこだわる必要はなく、自由にレイアウトを決めて良いと思います。)Redmineなどのタスク管理ツールでタスクを管理する時もステータスの設計が使い勝手に影響してきますよね。

例えば参考になるのが以下のサイト。
Web開発チームをタスクボードだけで見える化する 5つのコツ
http://engineer.blog.lancers.jp/2012/07/task_board_tips/

文献を見る限り一番オーソドックスなレイアウトはToDo、Doing、Doneという3つのレーンで区切る方法。ですが、杓子定規にこれを運用する必要はなく、現場の判断で変えて良いと思いますし、変えていくべきです。タスクのステータス設計にはどんな業務を対象とするかによっていくつものバリエーションがあり得ます。例えば開発現場でも設計工程と開発・テスト工程とでは管理すべきタスクが異なりますよね。

まずは導入しようと思う時に、この現場ではどのようにステータスを管理・運用しているかということを分析することになります。業務によっては併せてワークフローの設計もした方が良いケースもあります。具体的なステータス設計の例は追々ご紹介できたらと思います。