メールマガジン(2010/08/25 第4号)

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                                   
              E S M ニュース              
                         2010/08/25  第4号 
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

◇ Contents ━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇
┃◆【連載】人材育成、講師の視点から[4]
┃ ~タスク粒度の考え方~
┃◆【ご案内】プライベートセミナーを開催します(9/22)
┃ 『「無手勝流」から脱却せよ!
┃ ソフトウェア開発を成功に導くための三層プロセス
┃ =TOC思考プロセス・CCPM・チームファシリテーション=』
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇

このメールは、株式会社永和システムマネジメント社員と名刺交換をさせて頂
いた方に送付しています。今後このようなメールが不要な方は、末尾の案内を
参考に解除依頼をお送りください。

◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇
【連載】人材育成、講師の視点から[4]
~タスク粒度の考え方~
◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇

こんにちは、天野勝です。
私は、コンサルタントという職業柄、人にものを教える「講師」という仕事を
することが多いです。現場カイゼンの導入教育や、C言語でのテスト駆動開発
と、かなり多岐に渡っています。
この連載では「講師」をしていて気づいたことを私の視点で発信していきます。

■タスクを2時間以下に分割する
現場カイゼンの導入教育の中で、やるべきタスクを付箋に書きだして、タスク
ボードで管理する方法を教えています。この管理方法の中で、最も効果があり、
そして最も受講者から不評なのが「タスクを2時間以下に分割する」というもの
です。この話をすると、以下のような反応がかえってくることが多々あります。
(1)そこまで細かくタスクに分けるのは時間がかかる
(2)そこまで見積精度は高くできない
(3)10分程度のタスクばかりだと貼るところがなくなる
確かに、「タスクを2時間以下に分割する」という文面だけ見れば、当然の反応
だと思います。しかし、このように分割してもらうのにはそれなりの理由があ
るのです。

■基礎知識
ここで、この後必要になる考え方を紹介しておきます。

◇バッファはマイルストンの前に置く
TOCのCCPM(Critical Chain Project Management)は、プロジェクトのマネジメ
ント手法であり、その中のいくつかの考え方はチーム運営に大いに役に立ちま
す。その最たるものが、バッファ管理の手法です。詳しくは参考書籍をご覧く
ださい。[*1]
ごく大雑把に、この管理手法を説明すると、各タスクの作業予定工数を50%の確
率で完了する工数で見積もり、マイルストンの前にバッファとなる工数を用意
するというものです。

◇完全Done
タスクには完了条件が決められおり、完了条件を満たせばそのタスクは完了と
します。さらに、仕掛中のタスクの中間的な進捗は管理しません。つまり「こ
のタスクは30%完了している」という言い方はせずに、終わっているか、終わっ
ていないかだけで進捗を管理します。詳しくは参考書籍をご覧ください。[*2]

◇残時間による進捗把握
タスクが完了していない場合、そのタスクの進捗状況を確認したい場合があり
ます。このような場合は、どれだけタスクを行ったかではなく、そのタスクを
完了させるのに後どれだけの時間がかかるかを把握します。どれだけやったか
ではなく、どれだけ残っているかを把握するという考えです。

■2時間にこだわる必要はない
前提として仕事のサイクルとして1週間を基準とし、これをマイルストンとしま
す。アジャイル開発のイテレーションととらえていただいても問題ありません。
そして1日に仕事に費やせる時間については最大6時間とします。

見積り精度についてですが、1/2~2倍(-50~+100%)のぶれがあるとします。つ
まり、2時間と見積ったタスクは、実際には1時間~4時間になってしまいます。
もしみっちり3日間、18時間かかると見積ったタスクの場合、2倍の36時間かか
るとなると、6日間かかってしまいます。週の最初からそのタスクに着手しても、
マイルストンには間に合わなくなります。そして、「完全Done」の考え方にそ
うと、そのタスクは未完了です。何%終わっていようが、未完了と考えます。
もし、何%終わっているか判断できるならば、タスクはもう少し細かく分けら
れるのではいでしょうか。
その反対に、9時間で完了することもあります。これはこれで、ハッピーなので
すが、このときによく発生するのが「早期完了の未報告」です。早く終わった
ら、次のタスクに取り掛かるのが理想的ですが、もともとの18時間というのは、
「タスクに費やしてもよい時間」ととらえてしまい、ぎりぎりまで作業をして
しまうことがあります。

バッファの時間として、週の終りにどれだけの時間を用意しておくのが妥当で
しょうか?タスクが6時間であれば、2倍まで時間が増えると考えると、最終日
の前日の最初にタスクに着手するとしても、最終日はまるまる一日バッファの
時間にするのがよいでしょう。一方で、タスクが2時間であれば、バッファの時
間も2時間となります。このバッファの時間は、もしかしたら使わない時間かも
しれません。ですから、マネジメントの視点で見れば、この時間は短いほどう
れしいはずです。では、バッファの時間を短くするにはどうすればよいでしょ
うか? 単純な答えとしては、タスクの時間を短くすればよいのです。そして、
バッファとして積む予定の時間を計画の時間に回せばよいのです。

上記の話は、見積り精度が-50~+100%の場合ですので、もっと見積り精度が向
上してくればこの限りではありません。また、1日に働ける最大時間の増減に
よっても、適切なタスクのサイズは変えたほうがよいでしょう。

■細かく分けることの副次的効果
チームごとに週に1回計画の時間を取り、その中でタスクを細かく分けていきま
す。ここでのポイントは、複数人でタスクを分けていくということです。この
タスクを分ける時間を複数人で共有することで、仕事の内容だけではなく、仕
事の進め方も共有できます。知識伝承が行えます。

タスクを細かく分けるのは良いのですが、やりすぎは禁物です。細かく分けす
ぎてしまうとそれはそれでデメリットが出てきます。例えば、冒頭の受講者の
反応のように、タスクボードに貼りきれなくなるというのもありますし、細か
く分けるとそれにかかる時間も長くなってしまいます。タスクボードで運用し
ている場合は、複数のタスクをまとめて1枚の付箋に羅列するという運用がよい
でしょう。

発見的な仕事の場合はこの限りではありません。
研究や調査など、完了条件やかかる時間が見積れないような仕事とは相性はよ
くありません。しかし、このような発見的な仕事であっても、その中には完了
条件が明確で、作業時間を見積れるタスクがあるはずです。このようなところ
だけでも切り出しておくと、他の人が手伝いやすくなります。そうすれば、発
見的な仕事に費やせる時間を増やすことができます。

■まとめ
最初に挙げた、受講者の反応に対する解はこのようになります。

(1)そこまで細かくタスクに分けるのは時間がかかる
⇒時間がかかるのは致し方ありません。進捗が遅れるというリスクを考えると、
時間をかけてでもタスクを細かく分けるべきです。また、分けることで知識
伝承が行われるという副次的効果も期待できます。
また、慣れてくればタスクに分ける時間は短くなります。

(2)そこまで見積精度は高くできない
⇒見積り精度が高くないからこそ、2時間程度に分けるのです。見積り精度が
高くなれば、大きいタスクでも問題ありません。
また、慣れてくれば見積り精度が高くなります。

(3)10分程度のタスクばかりだと貼るところがなくなる
⇒小さいタスクを寄せ集めて、ひとまとめに管理するのをお勧めします。

皆様のお仕事を進める際のヒントになれば幸いです。

■参考資料
[*1] 『TOC/CCPM標準ハンドブック』
http://www.amazon.co.jp/dp/479802659X/
[*2] 『アート・オブ・アジャイル デベロップメント』
http://www.amazon.co.jp/dp/4873113954/

◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇
【ご案内】プライベートセミナーを開催します(9/22)
『「無手勝流」から脱却せよ!
ソフトウェア開発を成功に導くための三層プロセス
=TOC思考プロセス・CCPM・チームファシリテーション=』
◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇

ソフトウェア開発は、他業種のプロジェクト型開発業務に比べ、マネジメント
が難しいといわれています。各社、研修を行ったり、資格取得者を増やしたり、
PMOを設置したりと、マネジメント力の強化に向けてさまざまな取り組みを行っ
ています。それにもかかわらず、順調に進むプロジェクトはまれで、次から次
へと発生する問題に対して自己流のやり方、いわば「無手勝流」で何とかカッ
トオーバーする、というのがほとんどではないでしょうか。

このような状況でソフトウェア開発を成功させるためには、次の「三層のプロ
セス」を確立し、それぞれを連携させながら、開発を進めることが不可欠です。

・マネジメントプロセス:何を開発し、プロジェクトをどのように評価するか
・プロダクトプロセス:どの開発手法でプロジェクトを進め、管理するか
・オペレーションプロセス:日々の開発業務をどのように遂行していくか

本セミナーでは、「三層のプロセス」を確立・連携させ、ソフトウェア開発を
成功に導くための考え方、実践方法をお伝えします。

『「無手勝流」から脱却せよ!
ソフトウェア開発を成功に導くための三層プロセス
=TOC思考プロセス・CCPM・チームファシリテーション=』
日 時:2010年9月22日(水) 13:30~17:00(13:00受付開始)
場 所:株式会社ビーイング 新宿オフィス セミナールーム
参加費:無料(事前申込制)

▼講師
加藤立朗 株式会社永和システムマネジメント 技術顧問
西原 隆 ゴールシステムコンサルティング株式会社 チーフコンサルタント
天野 勝 株式会社永和システムマネジメント コンサルティングセンター長

▼詳細情報およびお申込みはコチラ↓
https://sec.tky.esm.co.jp/2010/08/25/private_seminar11/

◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇
私たちのホームページ
◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇

『コンサルティングセンター』 https://sec.tky.esm.co.jp/
 システム開発に潜むムダを取り除き、システム開発に関わる全ての人が適正
 な価値を持続的に得られるよう、支援します。コンサルティング領域や、セ
 ミナーのご案内などを掲載しています。

『Ruby x Agile』 http://ruby.agile.esm.co.jp/
 Rubyやアジャイル開発に関する最新のトピックスや活動実績を紹介していま
 す。現場のメンバーのブログも掲載しています。

『永和流プロジェクト運営術』 http://agile.esm.co.jp/scrum/
 プロジェクト運営に関して私たちが提供しているサービスを紹介しています。
 スクラムという開発手法の解説も掲載しています。

『永和システムマネジメント 組込みグループ』 http://et.esm.co.jp/site/
 オブジェクト指向やアジャイルといった永和の強みをETの現場でも活用すべ
 く活動中です。メンバーのブログやETロボコン関連のコンテンツも掲載中です。

◇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━◇◇
◆ ご意見・ご感想は、このメールに返信ください。
◆ 配信解除は件名「配信解除」にてこのメールに返信ください。
アドレス変更は件名「アドレス変更」、本文に配信希望メールアドレスを
記載の上、このメールに返信ください。
◆ 免責事項・個人情報保護方針はコチラを参照ください。
http://www.esm.co.jp/terms/index.html
◆ 発行:株式会社永和システムマネジメント
〒110-0005 東京都台東区上野2丁目7番7号上野HSビル8F
http://www.esm.co.jp/
Copyright (c)2010 Eiwa System Management, Inc. All Rights Reserved.

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中