タスクをこなすときの4つのポイント

システムエンジニアにはコードを書く以外にもさまざまなタスクを抱えることがあります。数年間経験を積んで、どんな種類のタスクでも基本に忠実になることで、タスクの精度をあげることができるのではないかと思うようになりました。タスクを行う上でのポイントを４つに分けて整理していきます。

本稿では、先輩や上司からタスクをもたったと想定して、タスクをもらったときから完了するまでの間で、気を付けるポイントを整理しました。

# 1.期待値の把握
ビジネスをする上で大事なことは「相手の期待を超えること」です。ですが、期待とな何でしょうか？「超える」ためには、相手との期待をすり合わせておく必要があります。そのため、タスクをもらって気を付けるポイントは、もらった瞬間に訪れます。

タスクをもらった瞬間に気を付けるポイントは **「期待値を把握すること」** です。期待値を把握し、自分の成果が期待を超えたときポジティブな評価になります。逆に、期待値の対象を取り違えたりして、別のことに注力すると評価されないことになります。

## 把握ポイント
期待値を把握する上で、共通認識を得た方がよいポイントは以下の4つです。

:::note info
1. その仕事の背景や目的：なぜやるのか？経緯は？
2. 具体的な仕事の成果イメージ（完成像）：完成像は何？パワポ10スライド？ドキュメント1枚？
3. クオリティ：3日の100点？3時間の60点？
4. 優先順位・緊急度（期限）：今日まで？後でもよい？
:::

まず、「背景や目的」を知っていれば、情報の取捨選択がしやすくなり、相手が喜ぶコアなポイントをおさえやすくなります。期待値を外すという失敗の確率を下げることにも一役買ってくれます。

2つ目の「具体的な仕事の成果のイメージ」とは、成果物の完成像のことです。完成像の指示まではされないことが多いので、自分で案を検討しアウトプットの形を提示したうえで、粒度や表現方法などのイメージをすり合わせます。作業の内容があっていても、出力を間違えると大惨事になるので、特に注意したいです。

3つ目の「クオリティ」はスピード感と正確性に通じます。早く粗いアウトプットがほしい（概要や傾向をざっくり知りたい）のか、時間をかけて正確なアウトプットがほしい（重要な判断の材料にしたい）のか、相手の期待値を割り出す手がかかりになります。

4つ目の「優先順位・緊急度」は「期限」に関するすり合わせです。次のアクションがはじまる時間とも捉えられますし、作業時間の総量を区切るという意味にもなります。時間感覚をあわせて、必要なタイミングにアウトプットを出せるようにします。

この4つの把握ポイントをおさえておけば、期待値を大きく外すことはなくなるはずです。

## 混ぜるな危険　手段と目的
上述の把握ポイントの1つ目に「背景や目的」があります。背景や目的をすり合わせするのは、自分で手段と目的を間違えないためにも重要です。視野が狭くなると、手段と目的を間違えて捉えて作業してしまうことがあり、その結果、期待値に届かない成果物を作成してしまうことになります。

例えば、システム開発のプロジェクトで設計フェーズだったとします。設計のアウトプットは「設計書」です。手段と目的を間違えて、設計書を作ることを目的として作業を進めると、検討量が少ない「作業化」して、品質の良くない設計書が出来上がります。最初に目的や背景のすり合わせをすることで、本来求めていることを知り、さらに、このタスクが次どうなるかを想像します。想像することが期待値を超えるためのヒントになり、結果を出すことにつながります。

# 2.アプローチを考える
タスクをもらって期待値を確認した後はどうしますか？すぐにタスクに着手したくなるかと思います。しかし、まだ着手するには早いです。 **着手する前に「どう考えたら、答えがでるか」筋道を考えます。** これが気を付けるポイントの2つ目になります。

筋道を考えるメリット1つ目は、全体像が見えるため見当違いの作業をする可能性を減らせることです。さらには行き当たりばったりの作業で時間を無駄にする可能性も減らせます。メリット2つ目は、作業の難易度や作業量を見積れることです。事前に対策を検討しやすくなり、完成の精度をあげてくれます。

## 考え方を考える 
筋道を考える手順としては、「大きな設計図を描いて細部に落とす」ことです。作業内容ではなく、作業の要素を洗い出し、全量を把握します。次に作業可能な粒度に整えるために、タスクを分割します。さらに、分割したタスクに順番をつけていきます。

ここで先ほどの「期待値の把握」が役に立ちます。目的や背景から、どこから手を付けるか想像することもできるでしょうし、完成像から作業イメージの解像度を上げることもできそうです。クオリティの情報から粒度の大きさを調節したり、優先順位の情報から順位をつけたり、そもそも作業を省略するという発想もでてくるかもしれません。

要素を洗い出した後、粒度を整えるのが地味に難しいです。イメージとしては、パワーポイントで発表するときにの「アジェンダ」を作っていく作業に近いです。抽象度が高い過ぎると前後のつながりがみえづらくなりますし、具体的過ぎるとバランスが悪くなります。考え方を考えた結果、あくまでも作業手順をつくっていくので、作業がわかるレベルに並べるのが無難です。

## チェックを入れることの威力

作業手順を作成したら一度チェックを入れます。依頼主に「この方法でアプローチを考えるがどうか」と意見をもらいます。ここでアプローチについて合意をとっておくと、期待値に沿ったものを作る確率がさらに上がります。さらに、抜けている要素や効率的な順番などの指摘をもらえれば、失敗の確率も減らせることができます。

また、アウトプットの完成像をさらに高める方法として、2~3割アウトプットの全体像を見通せたときにチェックを入れることも効果的です。アウトプットの見せ方や詳細なロジックの組み立てなどについてすり合わせをします。作業手順のすり合わせか、2~3割できたときのすり合わせのどちらか1回はやっておくと、アウトプットが期待値に沿うまたは、超えやすくなります。

すり合わせの一番のメリットは、失敗の確率を減らせることにあります。「間違っていない」という確証は、品質保証をある程度保証してくれることになります。無理無駄を排除し、効率的な作業にもなるので、おすすめです。

# 3.質疑応答で問題解決を図る
実際にタスクを消化する作業の時間に入りました。合意した作業手順に従って作業を進めていきます。当然、一人で解決できないことも発生しますので、他の人と質疑応答をして解決を図ります。この質疑応答で問題解説を図る際にも気を付けるポイントがあります。**その気を付けるポイントとは、「いかに相手の時間を取らずに解決までいたれるか」** です。

質問する相手もタスクを行っている最中です。その合間に時間をもらっているので、自分の問題解決にかかる時間は最小限にする工夫をします。質疑応答で時短ができそうなところは、最初の質問です。情報を端的に伝えることができれば、相手からの逆質問や自分の言葉の再解釈の時間を減らすことができます。

## 前提って揃ってる？
タスクを振った人は、振ったタスクの内容に精通していると思い込みがちですが、実際タスクを振った人は、タスクの概要や大まかな作業イメージくらいまでしか知りません。先輩といえど、そもそも、どんなタスクをやっているのか、あまり知らない場合もあります。いきなり、エラーの内容を話をしても相手はついていけません。そのため、質問をする際には「相手はタスクについて何も知らない」という前提で質問を組み立てていきます。

必要であれば「期待値」や「作業手順」も共有した方がよい場合もあります。もし今日中に提出することが期待値なのであれば、迅速に対処しないといけない場合もあります。そして、タスクを解決する上で、前提条件がそろっていないと先輩もアドバイスをしづらいですし、何が起きているのか正確に把握するまでに時間がかかってしまいます。

## 伝わるように話す
問題が発生して自力で解決できないので、原因や解決方法を尋ねるときを想定します。このときに、相手の時間をとらないように、伝わるように話す必要があります。

「伝わるように」というのは、別の言い方をすると、「相手に逆質問させないこと」といえます。逆質問は問題解決するための検討材料が足りない状態の表れなので、あらかじめ必要な情報を整理して伝えることが伝わるように話す秘訣です。必要な情報の整理ポイントを以下のようにまとめました。

:::note info
1. 結論:何をどうしたいのか？何を聞きたいのか？
1. 発生事象:何が発生したのか？問題が発生した内容、エラーログの内容、何をしてエラーが発生したのか、操作方法や作業内容など
1. 経過:エラーが発生後、何を調べて何を試したのか
1. 仮説:調べた結果を踏まえての自分なりの仮説（自分なりの意見）を用意※可能であれば
:::

結論をまず初めに話します。「結局、何を知りたいのか。どんな状態になればよいのか」を述べます。例えば、「この○○エラーを解消したい」などです。

次に、どんな状態なのか、何が発生したのか事象の説明をします。エラーの話であれば、どんな条件のもと、どんな操作をしてどんなエラーが発生したのか、そして、エラーログの内容を伝えます。

さらに、問題が発生してから自分で何を調べて、どんな対処をしたのかを伝えます。これによって、同じ検証を先輩がしなくても済み、解決方法の選択肢を減らせることになります。

そして、可能であれば、問題の所在や解決策など自分なりの仮説を伝えられるとベストです。ただ、仮説をたてるのは経験がものを言うことが多いので、省略してもかまいません。

さらに、メモとして箇条書きでも言語化しておくとよいです。頭の中で考えたときはまとまっていても、いざ先輩に話してみると、全然まとまっていないときがあります。それに、言語化するとこれで伝わるか検証しやすくなります。別視点として先輩からすると、メモを見せてもらった方がよいときもあります。

# 4.ほうれんそうのほうを徹底する
進捗確認のためのミーティングを行うことがあります。このミーティングでチームのメンバーがそれぞれタスクの進捗を確認し、スケジュール通りに進んでいるのかをチェックします。スケジュール通りになっていない場合は、どうやったらスケジュール通りに進むのかを検討し、対策を打っていくことになります。

その進捗を報告するに、タスクをこなす上で4つ目のポイントがあります。 **4つ目のポイントは、「報告を徹底する」です。** この「徹底する」というのは、「進捗状況として必要なことを報告しきる」ことです。端的に、必要なアウトプットを出すことに注力します。

## 報告って何を言えばいいの？
進捗状況の確認は何のために行うのでしょうか？最終的な納期に品質よいアウトプットを出せるように、スケジュール通りに進捗しているか確認（問題が発生したら対策をする）するために行っています。こうした理由のもと進捗確認を行うので、「いつ終わるの？or間に合うの？」がわかるように報告します。

:::note info
1. 進捗率
1. 今日行ったタスク内容
1. 残りのタスク内容
1. オンスケor遅延（リカバリープラン）
1. 相談事項(課題や懸念事項の相談)
1. 連絡事項（勤怠連絡など）
:::

「進捗率」からタスク進捗の全体感がわかります。正確な数字ではなくざっくり示すことが多いです。ただ、「90％は実装がほぼできていて動作確認が残ってる状態」というように基準をリーダーとそろえておくとよいです。

「今日行ったタスク内容」で1日の作業内容を報告します。タスクの具体的な内容を詳しくというよりは、前述の作業手順くらいの単位で報告します。「残りのタスク内容」で未着手のタスクをざっと報告します。

そして、オンスケなのか、遅延なのかを述べます。遅延の場合は、リカバリープランを提示するまでがセットです。タスク内容の順番を組み替えたり、作業時間を増やしやり自分で取り組める範囲でリカバリープランを考えます。
それでも難しい場合は、次の報告事項の「相談事項」で、自己努力で遅延を解消できない見込みであることを伝えます。他の人にタスクを持ってもらったり、個人の課題からチームの課題に昇格させて、問題の解決を図ります。そして、連絡事項は勤怠の連絡などを行います。

上記のような進捗状況を伝えてきることで、「報告を徹底」することができます。コツがいるので、進捗報告のミーティングの前に報告内容のメモをつくっておくとスムーズです。ちなみに、リーダーのような報告の聞き手は実施内容や残タスク、その他Gitの状況やチケットの更新状態などから、進捗率の報告との整合性を考えていて、報告を盛ったり、改変するとだいたいわかるので注意しましょう。

## 簡潔に話す
上述した報告内容は報告の仕方を工夫しないと、ダラダラと長く話してしまいがちです。進捗報告にあまり時間をかけたくない（作業時間をとりたい）ので、少しでも端的に話すようにします。端的に話す工夫としては例えば以下のようなものがあります。

:::note info
1. 事実と意見はわける
1. 数字を使う
1. 1文を短く話す
:::

進捗として報告してほしい内容は「事実」です。自分の解釈が入っている「意見」は進捗報告にはあまりそぐわない場合が多いです。「いい調子です」とか報告されても、ポジティブな状況とはわかりますが、その判断があっているのか検証ができず信憑性がわからないので、聞き手は困ってしまいます。

数字を使って報告することも端的に状況を伝えることになります。「担当チケットは全8件あって、内3件が完了しています。完了した3件の内容は～」のように話すと、順序だてて端的に伝えられます。

1文を短く話すことは就活の時のアドバイスに聞こえるかもしれませんが、ダラダラ長らく話す人の特徴は1文が長いことです。そのため、「○○は△です。」と短く述べることを意識して話します。報告がうまい人はだいたいこれらのポイントを守って話しているので、周りの人がどんな言い方をしているのか聞いてみましょう。

＊

基本に忠実になるだけでも、かなりの量を思考しないといけないかもしれません。でも、考え続けることが期待を超えることの近道になると信じてます。こちらの記事が誰かの役に立ったらうれしいです。

最後まで読んでいただいた方、ありがとうございました。

# 参考文献
大石哲之（2014年）『コンサル1年目が学ぶこと』ディスカヴァー・トゥエンティワン
Qiita KNR109(2022年)「新卒1年目に使ったエンジニア質問テンプレート」,
<https://qiita.com/KNR109/items/550b52ff980c0c32bf2a>2024年6月6日アクセス.
Qiita old-stone(2018年)「【SIer新人向け】研修では教えてくれないノウハウ集」
<https://qiita.com/old-stone/items/6221824566116710453f>2024年6月6日アクセス.
Qiita nuco_bk（2023年）「【11万文字越え】プログラミング初心者に贈る即戦力ガイド」<https://qiita.com/nuco_bk/items/27f5ad03d0c4b41241fc>2024年6月6日アクセス.
ウィルゲート(2024年)「エンジニア基礎 ウィルゲート2024年度エンジニア新卒研修」
<https://speakerdeck.com/kotomin_m/ensiniaji-chu-2024nian-du-ensiniaxin-zu-yan-xiu-8571fa94-7ebf-44fc-a5cd-302763118aee>2024年6月6日アクセス.