発生条件から考える、仕事の構造と分類

なんらかのタスクのマネージメントを行う際に単一の手法で行えば全てOKみたいに思われがちだけれども、実際には全てのタスクを等しく扱うことは難しい。例えば、複雑な要件を満たすための開発要件と毎月やってくる月次の締めの作業を同様に扱えるかというと、そこはやはり別の管理手法が必要だ。

その際に仕事を大きく分けるとどのような区分になるのか？というのを自分なりに考えた結果、多くの仕事は３つに分類できると感じている。仕事における３つの区分は以下の通りである。

・依頼により発生する仕事（依頼型）
・特定の条件で発生する仕事（特定条件型）
・課題を解決していく仕事（プロジェクト型）

これを１つずつ見ていきたい。

依頼により発生する仕事

まずイメージしやすいのがこの仕事だ。誰かの依頼によって発生する仕事のことである。例えば「会食の予定が入ったので、予約をしておいてほしい」だったり「エンジニアが増えたのでGithubのプロジェクトに追加をしてほしい」のような仕事のことである。タスクのトリガーは「依頼」である。

この仕事に関しては、依頼主からの要望を直接的に解決することが大事で単一の人だけでなく、複数の人から同じような依頼がきて遂行をするようなケースが多い。抽象度が低く繰り返される仕事のため、事前の見積もりが取りやすい仕事でもある。そのためマニュアル化もしやすく、人依存にならないようなタスク設計にしやすい。

特定の条件で発生する仕事

そして次が特定の条件により発生する仕事だ。多くの場合は、時間があげられる。例えば「月末なので経費精算をしなければならない」のような仕事だったり「備品が切れてしまったので追加購入をする」などのような仕事だ。

このタスクのトリガーは「条件」であり、客観的に計測をすることができる。一方で、トリガーとなる条件設定が誤っていたり条件が満たされたことを発見できるような仕組みがないと見落とされるようなことになってしまう。ここを人依存で頑張っている組織もあると思うが、先に紹介をした「依頼により発生する仕事」と合わせてSaaS化されている領域である。また、この仕事も「特定の条件は何度も起きうること」を前提としているためマニュアル化しやすい領域である。

課題を解決していく仕事

そして最後が課題を解決していく仕事だ。多く組織においてこの仕事のことをプロジェクトと呼んでいたりする。開発要件であれば「ユーザーに新しいコンテンツを届けるためのニュースレターを実装する」だったり「SNSログインをできるようにする」と言ったようなものだ。どんな要件であっても、前提として解決をしたい課題がありそのために仕事は行われるべきものであるので、全てのプロジェクトはここに属するはずである。

そしてこの仕事の特徴的なところは、前者２つの仕事に比べて「決断」すべき領域が多いことである。実際になんらかの仕事によって問題を解決できるかどうかは最終的にやってみなければわからないことも多く、もしその課題が解決されていない場合は失敗としてみなされてしまう。そして組織においてはこれが責任という問題になっていくので、できる限り責任を追わないようにするために妙に複雑な意思決定フローになっていたりする。

と３つの種類を紹介してきたが、これは職種によって完全に分類できるものではない。上記の３つが絡み合って実際の仕事は行われているわけだし、どれかだけで仕事をしているようなケースはあまりないだろう。しかしながら、どの仕事が中心になるかは部署や職種によってある程度はかわってくるものであり、その結果、得手不得手がでてくるものだ。

自動化について

AIだったりRPAといった仕組みが活用されるのは、前者の２つの仕事である。だから、前者の２パターンの仕事がとにかく多いような状況であればそれをどうやってマネージメントするかの前に、SaaSを導入することや自動化を行うことでできる限りミスや抜け漏れをなくし効率化を進めていくことが本質的には大事だ。そのために３つ目の仕事である「課題を解決していく仕事」という仕事が発生をしてくる。

しかしながら、ここで問題が発生してくる。依頼を受けて仕事をする人や特定の条件で発生する仕事に慣れている人は、課題を解決する仕事を進めることに慣れていない。本来であれば自動化が進むべき領域ではあるけれど、思うようにすすまないのはその担当分野の専門的な知識なのではなく、仕事の進め方や考え方が本質的に異なってくるからだ。このあたりが「専門性」と「仕事の思想の違い」によるコンフリクトが発生する部分なのだと感じている。

仕事の構造との相性

またツールを導入する際もどの思想に合わせたシステムなのであるかというプロダクトの思想を読み解く必要がある。確かにシステムを導入する側としては単一のシステムで全ての仕事の構造を管理できるようにしたいわけだが、前提となる仕事の構造がことなってくるのでいまいちワークしないみたいなことになってしまう。

そのため「マネージメントがうまくいかない」といった問題がある場合でも、どういった構造の仕事をマネージメントしようとしているのか？という前提に立ち返る必要がある。そのための仕事を分類するためのフレームワークとして、この区分を提唱することにした。