業務・課題・タスクの違いと、課題に焦点を当てる理由

本記事とは別で「ツールの使い分け」についてのナレッジ記事を制作しています。その記事を制作する中で、「Backlogには課題の進捗を書きましょう」と言う話をしました。その運用について理解してもらうために、業務・課題・タスクの違い、なぜ課題に焦点を当てるのかを説明します。その上で、関係するシステムの特徴やBacklogに書いてもらいたいことの詳細も説明します。

 

業務・課題・タスクの定義

それぞれの定義について説明します。

 

業務とは何か

業務は、仕事のまとまりや領域、役割を表す言葉になります。例えば、「マーケティング業務」「開発業務」「カスタマーサポート業務」「デザイン業務」など、事業の中で領域や役割を説明するために使われる言葉です。責任範囲を表現するために利用されたり、それぞれに対して専門職や部署ができたりする単位でもあります。ちなみに個人事業主の場合、一人で全ての領域をカバーする必要があり、それぞれの専門家に支援を仰ぐことも一般的です。

課題とは何か

課題は、理想（ToBe）と現実（AsIs）のギャップであり、解決すべき問題や達成すべき目標を指します。業務を遂行していく中で見つかった改善点や、プロジェクトで取り組むテーマなど、腰を据えて対応する必要がある内容を説明する際に使われる言葉です。課題に取り組む際は、まずAsIs/Tobeをきちんと理解するところから始まり、課題を明確に定義したうえでそれを解決する活動を実施していくことになります。ToBeは、働く人や組織の価値観によって変わりやすく、組織の規模に応じてAsIsの理解も難しくなります。

タスクとは何か

最後にタスクは具体的な作業の単位です。課題を解決したり業務を遂行したりするために実際に手を動かす個別の行動を指します。例えば、「公式ドキュメントを確認する」「有識者に不安事項を相談する」「成果物を顧客に提出する」のように、行動が明確でおよその作業時間が予想できます。

それぞれの関係性

同じ仕事でも、業務・課題・タスクという異なる視点で捉えることができます。

例えば、KnowledgeHubの記事執筆という仕事について考えてみると、業務視点では「ナレッジ管理」、課題視点では「新しく参画する人への説明コストを減らすには？」、タスク視点では「ツールの使い分け記事を書く」という関係があります。

地域勉強会の運営で例を考えると、業務視点では「地域活動」、課題視点では「地域の勉強会を継続していくには？」、タスク視点では「1月の勉強会のテーマを検討する」となります。他にもProjectMateの開発で例を挙げると、業務視点では「プロダクト開発」、課題視点では「チケット管理の定期作業を自動化するには？」、タスク視点では「定期発行機能の実装」となります。ちなみにProjectMateは、HeritageArrowで開発しているチケット管理支援ツールです。

それぞれの視点は互いに関係しています。業務を遂行する中で課題が見つかり、課題を解決するためにやるのがタスクです。逆方向に見れば、「タスクを何のためにやるのか」が課題に繋がり、「課題を誰が解決するのか」で業務に繋がります。

管理する仕組み

タスク・課題・業務を管理する仕組みやシステムが世の中にあります。
それぞれの違いと特徴を説明します。

タスクの管理と落とし穴

TODOリストは、タスクを管理するシステムです。私は個人のタスク管理システムとして、todoistを使っています。タスク管理システムを使うと、やることに集中できます。1日の最初にやることを書き出して適宜分解・順番の並び替えを行いつつ、手を動かすことに集中できます。タスクを中心に考えた際、手段が目的化しやすくなります。

タスクは何らかの業務や課題に紐づきます。しかし、タスクだけを眺めているとそのタスクが何のために存在しているのかを忘れてしまったり、タスクをこなす必要がなくなったことに気づかなかったりします。木を見て森を見ない状態になりやすいことに注意が必要です。

業務の管理と落とし穴

業務のためのシステムもあります。例えば、Figmaはデザイン制作業務のためのシステムと言えますし、GitHubはソフトウェア開発業務のためのシステムとも言えます。他にも、MoneyForwardクラウド会計は経理業務のためのシステム、SalesForceやHubSpotは営業管理のシステム、Zendeskは顧客管理のシステムです。

いずれのツールにしても、1番関心のある業務があり、それを効率的かつ効果的に達成するための様々な支援機能がついています。

これらのツールは専門家にとって使いやすいのですが、非専門家からすると分かりにくくなります。その結果、「ここから私の仕事」「ここからはあなたの仕事」という境界が生まれやすく、セクショナリズムが生まれ協働のしづらくなります。

課題管理による協働

課題を中心に考えると、「誰の仕事か」より「何を解決するか」が焦点になります。業務の境界を越えて、同じ課題に向き合うことになるからです。タスクは課題を解決するための手段として位置づけられ、やること自体が目的化しにくくなります。

「業務進捗」という言葉には、自分の領域で完結しているニュアンスがあります。一方で「課題進捗」と言うと、解決すべき問題がまずあって、それに対して何がどう進んだかを伝えることになります。視点が、自分の役割から、取り組んでいる問題そのものに移ります。

課題を中心に置くと、関わる人が同じ問題を見ることになります。デザイナーもエンジニアも、それぞれの業務は違っても、「この課題をどう解決するか」という共通の目的を持てます。業務の境界は専門性の違いとして残りますが、それは「ここから先は私の仕事ではない」という壁ではなく、それぞれの強みを持ち寄る分担として機能します。

HeritageArrowでは、各自の専門性を超えて協働するために課題に焦点を当てます。課題に焦点を当てると、業務としての効率化や標準化は相対的に後回しになります。また、専門性を深めるための時間も取りにくくなります。HeritageArrowでは、その非効率さを受け入れた上で、課題を中心に据えることを選んでいます。

Backlogに書いてほしいこと

ここまでの説明を踏まえて、Backlogに書いてもらいたいことを説明します。書いてもらいたいのは課題の進捗です。具体的には、やったこと、分かったこと、次はどうするかの3点です。

例えば、「○○をやりました」という作業報告だけで終わると、それは作業者として動いていることを意味します。そうではなく、開発者としての動きを期待しています。そのために、課題を解決するために作業を行ってほしいです。また、それを実行した立場から何が言えるのか、次に何をすべきと考えているのかに関する報告が欲しいとも思っています。やったことだけでなく課題の進捗を書くことで、業務の垣根を超えて、同じ課題、そしてその先のビジョンやアウトカムを見ながら会話ができる状態になります。

これは簡単なことではなく、それ相応の時間が必要ですが、それは効果的な活動を行うために必要なことだと考えています。

まとめ

この記事で説明した「課題に焦点を当てる」という考え方は、HeritageArrowのバリューにある「枠を超え、本質的な価値を追求する」「多様な視点を受け入れ、事業を共創する」に繋がっています。HeritageArrowでは、関わる方と早い段階でSOUNDカードを実施し、共通のアウトカムを描くことを大切にしています。課題の進捗を共有するのも、同じ考え方の延長にあります。業務の垣根を越えて、同じビジョンを見ながら共創していく。それが私たちの目指すところです。

HeritageArrowでは、同じミッションやビジョンを見つめながら一緒に活動できることを大切にしています。もし関心があれば、ぜひ声をかけてください。

—

なお、図は全てNanoBananaProで作成しています。