先日、新任マネージャから、仕事の進捗共有のやり方についての相談を受ける機会がありました。
進捗状況の把握は、チームをマネジメントする立場にとって非常に重要です。状況を正しく把握することで、適切にメンバーの支援やリスク対策を行うことができます。
なるべく正確な進捗共有には「タスクばらし」が有効です。曖昧な進捗把握によってトラブルが起きることを避けるためにも、「タスクばらし」による小口化は欠かせません。
目次
進捗は報告より「共有されていること」が大事
「進捗どうですか」に対して、「いま●●%くらいです」と返ってくるやり取りはよくありがちですが、これでは進捗報告を受ける側にしてみると、状況を把握するには不十分です。
本稿では「タスクばらし」が、なぜ進捗共有に有効なのか解説します。
なぜなら、多くの仕事の途中経過は単純に「何％」と表現できるものではないからです。
90%まで来たと思ってから、思いがけないアクシデントが起きて進まなくなるというのは、よくあることです。
特に、新しく取り組む仕事や不確実性の高いクリエイティブな仕事の場合、報告をする側も受ける側も、全体像における落とし穴の存在が見えていないことが往々にしてあります。
そんな時に「いま50％です」と言っても、残りの50%にかかる時間が、それまでと同じと考えて良いかどうかはわからないものです。そもそも報告の時点で、本当に50%まで進んでいるかどうかは、報告する当人の主観に過ぎません。
このような曖昧な進捗共有ではプロジェクトの実態が把握できず、スケジュールの遅延や過重労働を引き起こしかねません。
そもそも大事なことは、進捗の報告ではありません。マネージャを含めたチーム全体で、進捗の状況を正しく把握できていることです。そのために報告があります。
「できた」「できなかった」で進捗を判断する
チーム内で着実に仕事が進んでいるかどうか、把握するために欠かせないのが「タスクばらし」です。
「タスクばらし」の基本は、大きなタスクを小さく分解していくことです。小口化すれば、どんなものでも把握しやすくなります。
小口化のポイントは、進捗報告の期限にあわせてタスクを区切ることです。1週間単位で進捗共有する場合は、1週間以内にできる分量をタスクとして切り出します。
この際に、終わったかどうか明確にわかるような具体的な項目にすることが重要です。
そうすると進捗報告は「できた」「できなかった」の二択になります。
できていれば問題ないし、できなかったなら原因を究明し、対策をとった上で次のアクションに繋げられます。
気をつけたいのは、もし全部で1ヶ月かかりそうな仕事だった場合でも「毎週25%ずつ進める」ではなく、1週間以内で終わる単位まで小口化することです。
例えば、何かウェブサイト向けの記事を書くとしたら「来月に記事を掲載する」というタスクではなく、「企画案を作る」「取材する」「構成を作る」「原稿を書く」「レビュー後の推敲する」「入稿作業する」といった形まで「タスクばらし」をします。
そうした上で、1週間ごとの進捗共有で、「できた」「できなかった」を確認していきます。そうすれば間違いなく、どこまで進んでいるか把握できます。滞っているタスクがわかれば、マネージャとしても手助けできます。
こうして「タスクばらし」を徹底することで、マネージャはプロジェクト全体を適切にマネジメントできるようになり、メンバーは一人で抱え込むこともなくなります。
ソフトウェア開発における設計は「タスクばらし」
「タスクばらし」はもともと、ソフトウェア開発の現場から生まれた手法です。
ソフトウェア開発は、非常に不確実性が高いことが特徴です。数ヶ月にわたる大きなシステムを作らねばならない場合、進捗状況をパーセンテージで伝えても、関係者で把握はできず、不安は解消されません。
そこで、着実に動くソフトウェアを毎週の単位で作っていくことで、動いているものを見て進捗状況を把握することができるようになります。
これがアジャイル開発と言われる開発手法の考え方の一つです。それをビジネスモデルに組み込んだものが、私たちソニックガーデンが提供する「納品のない受託開発」です。
「納品のない受託開発」では、毎週お客さまと定例ミーティングを行います。そこでは1週間の成果を、動くソフトウェアを使ったデモで共有し、また次の1週間で作ってくるものの検討をし、ミーティング中に設計までを行います。
ソフトウェア開発における「設計」という行為は「タスクばらし」そのものです。どういった構造にして、どういった順序で作っていくのか分解することで、プログラミングの際につまづきそうな部分をなくしていきます。設計が終わったら、見通しのついた状態で見積もりができていることが理想です。
それが何ヶ月もかかる範囲まで設計するとなると、どうしても不確実さは残ってしまいます。そこで1週間の範囲までに小さくすることができれば、ほぼ間違いなく見通せるようになります。ある意味では、毎週納品を繰り返すのが「納品のない受託開発」と言えるでしょう。
単位を変えれば、誰でも使える「タスクばらし」
「タスクばらし」してからの進捗共有はソフトウェア開発に限らず、多くのケースで活用できるため、チームをマネジメントしていく必要のある人にとっては有用な手法です。特に新任マネージャにとっては、日々の仕事の助けになるはずです。
ここまでは1週間ごとの単位で、進捗の把握をする説明をしてきましたが、これは主に現場のマネージャに必要なタスクの単位です。
もっと経験の浅いメンバーのマネジメントをする場合は、毎日の単位で進捗共有をする必要があるかもしれません。その場合マネージャは、大きなタスクを1日単位に「タスクばらし」するサポートをしたほうが良いでしょう。
また、たとえば経営者みたいな立場になると、もっと長いスパンの進捗把握で十分になってきます。月に1度や、3ヶ月に1度くらいの頻度で、どういったプロジェクトが終わっているのか、これから始まるのか見ていくことになります。
複数のプロジェクトの把握については、ロードマップを使うと便利ですが、それについてはまた別の機会に。
