antiタスク分解論

世の社会人の方々はなぜ作業をタスク化するのでしょうか？

それは多人数による作業分担を可能にするためです。

そしてなによりも作業見積もりを出すためです。

何かを始めるとき、それがいつ終わるのか、目安が必要です。

作業分量がわからないと、どれだけのリソースをアサイン(大人語)すればいいか分かりません。

成果物の内容が大雑把になればなるほど完成までの時間を予測しにくくなります。

「面接予約システム」だけだといつ完成するか予測しづらいですが、「登録日時の降順でユーザー一覧を表示する」であればなんとなく実装時間を予測できます。

このように、作業単位が細ければ細かいほど作業にかかる時間の予測がしやすくなります。

自分が自宅から会社まで歩いてどれくらい時間がかかるのか？はパッとは分かりませんが、最寄り駅から次の駅までの距離であればなんとなく所要時間の目処が立ちます。

その距離と所要時間を足がかりにして、あとは会社までの各駅間の距離を調べれば、会社までのそれぞれの駅間の所要時間の目処も立つようになります。

自宅から会社まで5駅だとすると、まず「A駅〜B駅」「B駅〜C駅」「C駅〜D駅」「D駅〜E駅」の4つの工程に分けることができます。

その中で「A駅〜B駅」で所要時間の目処をつけて、残りの駅間の時間も算出していきます。

それらをすべて合計すれば全体のおおよそ時間を算出することができます。

全体の工程を細かく区切ることにより、見積もりの精度を上げて、さらにそれを合算することにより全体の見積もりも算出できるようになります。

これが社会人の方々がタスク化を行う理由です。

全体を分解すればするほど、自分たちの仕事がいつ終わるかの正確な目安を得ることができます。

ゴールの見えない道を進むより、辿り着くべきゴールが決まっている道を進む方が安心感があります。

社会活動においては予算やリソースも限られているわけですから、ある程度、これはどれくらいで完成するか？という目安がないと走り出せないわけです。

たしかアジャイルやスクラムもそのような課題設定のもとに生みだされた開発手法だったと思います。

作業単位をなるべく細かく短く区切って、そこから作業時間を算出していって、工程を進めるごとに作業精度を上げていって、徐々に完成までの見積もり精度を上げていきましょう。最初から全行程の正確な見積もりは無理ですよ。そもそも最初に作ろうとしたものと最終的に出来上がるものは別物になりますよ。──といった感じです。

タスク分解はとても便利でいいものですね。

みんながタスク化して仕事を進める理由が分かりましたね。

今日書きたいことはそれくらいです。

……いや違います。真逆のタイトルを付けていました。

タスク分解にもデメリットはあるのです。

今回はそのデメリットのお話です。

前置きがクソ長くなりました。

このブログ内では何回も書いている気がするのですが「言葉」は世にある全てを表しているわけではありません。

タスク化は言ってみれば「作業の言語化」でもあります。

ということは言語にならなかった情報はすべて作業タスクから抜け落ちてしまうのです。

少し雑な例えになりますが、αシステムを作るためにA機能とB機能とC機能にタスクを分解してそれぞれに担当者を付けたとしましょう。

αシステムの仕様には上記の3機能しかないものとします。

であれば、全然問題のないように思えます。

「A+B+C＝α」なんだから何も問題ないのでは？と思うことでしょう。

しかし実際の「システム」はそんなに単純なものではないのです。

たいていのシステムは「フレームワーク」と呼ばれる開発基盤上に機能を載せていく感じで作られます。

そのフレームワークを準備するのは誰なのか？初期設定はどうするのか？そもそも開発環境は誰が作るのか？

などなど、実際に仕事を始めようとすると結構な量の細々した、タスク化されていない作業が発生します。

作り始めたら作り始めたで、A機能とB機能と同じ処理が存在するので処理をモジュール化(共通化)したい、みたいなことも発生します。

そうなるとA機能担当者とB機能担当者との間でタスクに存在しないコミュニケーションコストがかかってしまいます。

また、A機能作成中にA`機能も必要なことが判明するかもしれません。

作り終わったら作り終わったで、それぞれの機能をまとめてαシステムとして統合する作業が発生します。

3つの機能が相互に連携していないと一つのシステムとは呼べません。

タスクの連携にまつわるコストの話はこちらをお読みください。

このように目に見える表面上の作業は各機能作成だけですが、実際の作業となると実に様々な「やらなければいけないこと」が発生します。

完成までにおける実際に必要なすべてのタスクを事前に全てタスク化するのは人類には不可能なレベルで難しいことです。

実務をやり始めて、初めて「やらなければいけないこと」が可視化されるのです。

実作業前のタスク分解化には限度があるのです。

それを踏まえた上で先ほど挙げたアジャイルやスクラムという開発手法が提案されたのです。

タスクに分解したとしても、それを合計したものが全体全てになると思ってはいけないのです。

人類には、実行する前の段階で実作業上で発生するすべての作業を正確に定義する、などということはできません。

さらにタスク化には「作業を効率化させる作業」や「品質を向上させる作業」が発生しにくいという欠点もあります。

先ほどの例だと「処理のモジュール化をしたい」となったとしても「そもそもタスクになってないし、やったら互いに余計な作業が発生するから、気づかなかったことにしよう」となる可能性が高くなります。

この例に限らず「こうすればもっと良くなる」と思ったとしても「でもそれはタスクとは関係ないし、やったら余計に時間かかるし、やった結果、後で問題になったらやだな」となってしまって結局やらなくなります。

リーダーなりマネージャーに提案すればいいじゃん、と思うかもしれませんが、大抵の人は自分に与えられたタスクでいっぱいいっぱいなのでこれ以上仕事は増やしたくないのです。

タスクの分解化は見積もりと作業分担化が可能になる多大なメリットがあります。

しかし、タスク化されなかった作業によるオーバーヘッドの発生や、作業全体や最終的なゴールに対して作業員の意識が向かなくなるデメリットも発生します。

1から100まで発生する作業すべてを完璧にタスクに落とし込めない限り、タスク化の恩恵だけを受け取ることができないのです。

しかし、ほぼ全てがオートメーション化している工場などは、タスク分割による恩恵を最大限受けていると言えます。

刺身の上にタンポポを乗せる人は作業全体や最終的なゴール、ましてや隣のラインの人が何をしているのかすら気にする必要はないのですから。

Tag: 仕事