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

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

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

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

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

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

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


ITコーディネータへの挑戦

ちょっと前のことになりますが、私はこの9月から土日を利用してITコーディネータのケース研修(全6日間)を受けてきました。正式な認定は年明けになるのですが、とりあえず研修を修了して試験にも通過したことでITコーディネータに一歩近づいたと言えます。

そもそも私はITコーディネータにあまり興味を持っていませんでした。が、ある日ある方にITコーディネータ資格の取得を強く勧められ、取得を目指すことにしたのです。しかも、私の知らない間にITコーディネータの制度が変わっていて、ケース研修も以前は15日間もあったものが6日間と短縮され、その分資格取得までに必要な費用も抑えられており、以前よりは敷居が低くなった印象を受けました。とはいえ、全く見ず知らずの人と濃密な討議を強制されるというのは、さすがに不安も覚えます。

ケース研修ではどんなことをしたかというと、ITコーディネータには一種の教科書であるプロセスガイドラインというものがあるのですが、そこに定義されているプロセスを一通り疑似体験するというものです。架空の中小企業の設定資料があり、その資料を読み込んでその企業をコンサルティングする…というのではなく、架空のコンサルティングを通してプロセスガイドラインを学ぶというのが主な目的です。

そうは言っても、演習では本来の目的を忘れてつい議論になってしまうこともあり、最初のうちは演習の時間配分が難しく、成果物が最後まで仕上がらないことが多かったです。やはり方法論についての議論というのは楽しいもので、ついのめりこんでしまいますね。しかし、徐々に本来の目的を意識しながら演習を行うことが出来るようになり、枝葉末節の議論は割り切って先に進めるようになりました。ただ、ケース研修を終了したとはいえ、あくまでも疑似体験であるため、これでいきなりバリバリIT経営のコンサルティングができるというわけではないですが、何をすればよいかという全体像をつかんだという感じがしています。

試験の方は11月にケース研修を修了するので、本当は2月ごろに試験を受けようかと思っていたのですが、ケース研修受講生の半数は既に試験に合格していたという事実と、ケース研修の熱が冷めないうちの方が受かりやすいのではないかという考えから、急きょ11月中に試験を受けることにしました。ケース研修の修了から一週間後に試験を設定してしまったので、短期間という制約の中で出来る準備としてはあまりなく、わざわざ問題集を買っても最後までできないだろうと思い、ネットで公開されているサンプル問題や想定問題をひたすら解いてプロセスガイドラインのおさらいに努めました。

これで万事うまく行く、とは思っていませんが、この体験が間違いなく今後の糧になるだろうと思っています。