なぜ君の仕事は遅いのか。デキる先輩から学んだ“考えているフリ“をやめる6つの方法 vol.2 仕事を依頼された瞬間に、期日と成果物を確認せよ

こんにちは！マネーフォワードでHR領域のQAエンジニアをしている森田です。
前回の「頭を使うタスクと手を動かすタスクを分けよ」に続き、2つ目の考フリやめ方（かんふりやめかた。「“考えているフリ“をやめる6つの方法」の略）になります。

vol.1 頭を使うタスクと手を動かすタスクを分けよ
vol.2 仕事を依頼されたその瞬間に、期日と成果物を確認せよ　💎今回💎
vol.3 10分考えて分からなかったら聞け
vol.4 30分で終わるタスクはすぐ着手せよ
vol.5 隙間時間にはタスクの整理をせよ
vol.6 自分にとってベストな睡眠時間と集中タイムを把握せよ

仕事内容がよく分からない・・・

・依頼されたこのタスクのここの部分ってどういうことなんだろう？
・企画内容を考えているけど、いい案が全然思いつかない...
・○○について調べたいけど、どうやって調べたら良いか分からない
・もはや何をしたら良いのか分からない

皆さんもこんな壁にぶち当たったことがあるのではないでしょうか。

私も例に漏れず、何回もこれらの壁にぶち当たりました。
失敗を繰り返しつつ、デキる先輩のやり方を盗み見した中で気づいたのは、仕事の依頼をされた瞬間に「期日」と「成果物のイメージ＝仕事の終わり」を確認せよ、ということでした。

自分と他人でイメージしているものは違う

仕事を依頼する人と仕事を依頼される人は、別の人間です。

社会人歴も違えば、経験を積んだきた企業や業界も違うかもしれません。同じ企業で時間を過ごしてきたとしても、学生時代の過ごし方は違うし、物事の思考方法も違うでしょう。育ってきた国が違うこともあるでしょう。

何が言いたいのかというと、
「自分と他人でイメージしているものは違う、ということを理解した上でコミュニケーションを取るのが大事」ということです。

話を戻しましょう。
2年目の私が経験した「テスト計画書のフォーマット化」というミッションを題材にして、新人とデキる先輩がそれぞれどう取り組むのかを観察します。

※（）の中は頭の中のセリフであり、相手には伝わっていません。

新人の場合：とりあえず持ち帰って、自分で考えてみる

QAグループのリーダー（以下、リーダー）：「今、各自でテスト計画書を作っているけど、チームメンバーも増えてきたし、フォーマットを統一したいんだよね。<新人>さんもテスト設計とテスト実行はだいぶ数もこなせるようになってきたし、改善業務としてテスト計画書のフォーマット化をやってみない？」

新人：「ありがとうございます！ぜひやってみたいです！ちょっと自分で考えてみます」（褒められて嬉しい！次もがんばろう！）

会話はここで終わり、新人さんは自席で考え始める。

新人の頭の中：

・そもそもテスト計画書ってどんな項目が必要なんだろう？自分の思いつくものを書き出してみよう。
・そういえば、いつまでに作れば良いのか聞くの忘れちゃったけど、きっと言わなかったから急ぎじゃないんだろうな。1週間後にフォーマットの案を持っていけば良いかな。

リーダーの頭の中：

・既に各メンバーが書いているテスト計画書の項目を合体させれば、スピーディーにフォーマットができそう。そんなにかっちりしたフォーマットが作りたい訳ではないんだよね。
・1週間くらいで完成できるかな。
・完成したら、チーム内で説明会もしてもらおう。

既に嫌な予感しかないですね。

そして1週間後。。。

新人：「テスト計画書のフォーマットを作成しました！」

リーダー：「おっ、ありがとう...（期待していた内容と全然違うぞ）...えっと、この項目はどうやって洗い出したのかな？...まずは、チームメンバーみんながテスト計画書にどんな項目を入れているのかの情報を集めてくれるかな？...」（続く）

認識のズレによる差し戻し、やり直しの時間って本当にもったいない

1週間かけて、新人なりのテスト計画書フォーマットを作成したのですが、残念ながら差し戻されて、最初からやり直しになってしまいました。この、仕事を依頼する側とされる側の認識のズレによるやり直しの時間って本当にもったいないですよね。

そして、残念ながら新人が頑張ったこの1週間という時間は「考えているフリ」認定をせざるを得ません。どんなに本人が一生懸命やっていても、「テスト計画書のフォーマット化」というミッションへの道筋という観点では一歩も近づいていないからです。（本人の成長という点では意味はあったとは思います）

新人だけが悪いわけではありません。ただ、自分が仕事を受ける側の人だとして、仕事を出す側の他人を変えることは容易でありません。なので、自分の行動を変えることで、どうスピーディーに成果を出していけるか、という風に考えましょう。

デキる先輩は、依頼を受けた瞬間、「期日」と「成果物のイメージ＝仕事の終わり」を確認する

さて、デキる先輩は、どのように進めていくのでしょうか。

QAグループのリーダー：「今、各自でテスト計画書を作っているけど、チームメンバーも増えてきたし、フォーマットを統一したいんだよね。<デキる先輩>さんにテスト計画書のフォーマット化を主導してほしんだけど」

※補足※
デキる先輩は、リーダーから仕事を依頼される前に、自分で問題を発見し、解決策を提案します。が、今回は新人と比較しやすいように、依頼された形式で話を進めます。

デキる先輩の頭の中：

・なんでフォーマットを統一したいんだろう？
・いつまでにフォーマットが完成することをイメージしているんだろう？（期日）
・フォーマットを作ったらこの仕事は終わりだろうか？

リーダーの頭の中：

・既に各メンバーが書いているテスト計画書の項目を合体させれば、スピーディーにフォーマットができそう。そんなにかっちりしたフォーマットが作りたい訳ではないんだよね。
・1週間くらいで完成できるかな。
・完成したら、チーム内で説明会もしてもらおう。

新人さんの時と同様、この時点では、2人の認識にはまだズレがあります。

デキる先輩：「分かりました。期日感ってどんな感じですか？」

リーダー：「1週間くらいで、スプレッドシートでフォーマットが完成していると助かるな」

デキる先輩：「であれば、最初の2,3日でテスト計画書の項目を洗い出すので、そのタイミングでお時間ください。方向性にズレがないかと、項目の過不足がないかの認識を合わせたいです。その後の2,3日でフォーマットの体裁を整えれば、1週間で終わると思います」

リーダー：「（頼もしい！）ばっちりだね！頼んだよ！」

デキる先輩：「ちなみに、フォーマットを統一したい理由や背景ってなんですか？」

リーダー：「（言われてみれば、ちゃんと考えてなかったかも...）そうだね、新人QAメンバーが今後も入ってくる予定だから、新しいメンバーとベテランメンバーとのテスト計画書の質の差をなるべく減らしたいんだ。チーム全体のスキル底上げともいうかな」

デキる先輩：「確かにそうですね。だとすると、各項目の説明やサンプルがあった方が良さそうですね。項目の量にもよりますが、少し時間がかかってしまいそうです」

リーダー：「あー、今回はまずスピーディーにフォーマットを1つにまとめることが大事だと思ってるんだ。丁寧なかっちりしたフォーマットにする必要はなくて。もちろん、説明は欲しいんだけど、再来週から始まる次の案件からこのフォーマットを使っていきたいから、1週間で出来る範囲で構わないよ。フォーマットは随時ブラッシュアップしていけば良いし、項目の説明は、最初は口頭でみんなに説明することもできるから。そうそう、このフォーマットができたら、チーム内で説明会を実施してほしいんだ」

デキる先輩：「（かっちりフォーマットを作るのかと思ってたけど、スピード重視なんだな）（フォーマットを作って終わりだと思ってたけど、説明会をして内容をメンバーに理解してもらうまでが依頼内容なんだな）了解です！スピード重視ということなので、体裁はあまり気にせず、項目の洗い出しと説明を書くのに時間を割くようにします。チーム内説明会の予定も先に入れておきますね」

「期日」を確認する

新人もデキる先輩も、最初の段階ではリーダーとの認識のズレがありました。2人のアクションはどこが違ったのでしょうか？

1つは、依頼をされた瞬間に期日を確認することです。

仕事のスピード感がズレていることほど両者にとって不幸せなことはありません。今日中なのか、2,3日中なのか1週間くらいなのか、それ以上なのか。しっかり認識を合わせましょう。

成果物のイメージ＝仕事の終わりを確認する

期日よりもこちらの方が重要。

両者のバックグラウンドが違うほど、イメージしている成果物もズレやすいのです。ズレて当たり前、ということを肝に銘じて、仕事を依頼された瞬間に成果物のイメージをすり合わせましょう。

「テスト計画書」という言葉ひとつをとっても、人によってイメージしている内容は違うはずです。

どんな項目を書く想定なのかを羅列するなど、可能な限り自分が考えている詳細な内容をその場で確認してしまいましょう。

その利点は2つあります。
1つは、その時点で方向性がズレていれば軌道修正できる。
もう1つは、この時点で自分の考えを説明できないのであれば、理解不足であることが自分にも相手にも分かる。

成果物の具体的なイメージが湧いておらず、その場で説明できないのであれば、求められている期日感にもよりますが、遅くとも2,3営業日以内には、成果物のイメージファイル（テスト計画書の項目と記入例）を共有して、方向性や内容がズレていないか確認しましょう。

理解が追いついていないということが相手（仕事を依頼した人）にも伝わると最初はこうしたら良いよ、とアドバイスをもらえるかもしれませんし、もっと詳細に説明をしてくれるかもしれません。

（おまけ）リーダーになった私が気をつけていること

今では、チームメンバーにお願いすることが多くなってきました。その時も、「期日」と「成果（物）のイメージ」（どこまで達成することを期待しているのか）をすり合わせるようにしています。

自分で全て説明するだけでなく、スケジュール感が分かるものを簡単に作成してもらうなど、どこまで理解しているのかが分かるような問いかけをするようにしています。言葉で説明が難しい場合は、「自分の中で40点の段階で、一度見せてほしい」と言ったりします。

また、何のためにその依頼した仕事が必要なのかの「WHY」の部分を伝えることも大切にしています。

日々、スピーディーに問題解決を行っている環境においては、「WHY」の認識が合っていれば、それをどう実現するかの「HOW」と、何を実行するかの「WHAT」には大きなこだわりはないことが多いからです。メンバーに主体的に考えて進めてもらうことで、メンバー自身の成長につながりますし、自分よりも良いアイデアや成果を出れば、自分を含めてチームへの刺激になります。

おわりに

今回は、仕事の内容が分からない...自分なりに考えてやってみたけどやり直し...という状態にならないようにするコツをお話しました。

もちろん自分で考える時間も必要なのですが、問題の解決策や新しい企画を考えるのと、あのタスクの内容ってどういうことなんだろうと考えるのでは、同じ「考える」に見えても、実は内容の質は全然違います。考えた結果のアウトプット量が違ってきますよね。

同じ「考える」時間ならば、前者の問題の解決策や新しい企画を考えるところにたくさんの時間を使いたいですよね。

次回は、考フリやめ方の3つ目として、「10分考えて分からなかったら聞け」についてお話します。

こんな仕事の進め方に興味を持っていただいた方、共感していただいた方、カジュアルにお話してみませんか？ご連絡お待ちしております〜。