作業ではなく、仕事をせよ

この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。

（補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです）

毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。

心構え：作業ではなく、仕事をせよ

まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。

仕事というのは「ある目的を達成するための行動」
作業というのは「ある計画や手順のもとにおこなう行動」

仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実施する行動が「作業」ですね。

箱をAからBに動かしてほしい

例えば引っ越しの最中に「箱をAからBに動かしてほしい」ということを言われたとします。

目の前に箱があり、Aの位置もBの位置もわかっているなら、これはもちろん作業です。言葉を正確にするなら「あなたの手が空いているようなので、いますぐ、この箱を手で持ち上げてAからBに動かしてほしい」という感じでしょうか。これは作業の依頼なので、もちろん、作業をすればいいと思います。

でも、もし、あなたが

何を運ぶのかわからない
どこに行けばいいのかわからない

という場合、それは依頼が曖昧だからなのでしょうか？

作業依頼が曖昧なのではなく、仕事の依頼と捉える

ここで大事なのは、計画が曖昧で正確な手順も把握できないのは「作業の依頼が曖昧だから」ではないということです。

依頼者があなたを「作業者」として雇っていて「私に言われたこと以外はしないでください。頭を使わず、ただ従ってください」と依頼しているなら「作業依頼が曖昧です」という返事は正解です。コンパイルエラーと一緒ですね。そんなプログラミングをした依頼者が悪いです。

でも、「一緒に仕事をしている」なら「作業指示が曖昧だからできません」ではすみません。仕事をしているのであれば、依頼を作業に落とし込むことをやってほしいです。作業依頼が曖昧なのではなく、仕事の依頼と捉える。それが作業者を抜け出して「仕事ができる社会人」になるための道です。

仕事を作業に落とし込む3つのステップ

では、どうしたら仕事をすることができるでしょうか？そのために僕の経験から学んできた3つのステップを説明します。

理解する：複数の視点で立体的に整理する
提案する：複数の選択肢を考える
計画する：タイムボックスでフィードバックを受ける

（もちろん、これは僕のやり方なので、これが正解だとか、これじゃなきゃダメだ、とは思いません。仕事術は人それぞれ、自分の性格によって最適なものを見つける必要があります。これも1つの方法だと思って読んでもらえるとうれしいです）

1.理解する：複数の視点で立体的に整理する

「依頼が曖昧なわけではない」とは書きましたが、理解できないことがあるのは確かです。では、何が起きているのでしょうか？

依頼というものは背景の上でおこなれてます。つまり、依頼者からすれば「こういう背景があるから、この言い方で通じるな（て欲しいな）」と思っているわけです（よほどイジワルな人でもない限り）。つまり、依頼が曖昧と感じるなら、その背景に分からないことがあるはずです。

なので、まずは、その背景の「分からないことを分かるようにする」ことが大事になります。

そのためには依頼の情報の形を変えて、立体的に理解して不明点を洗い出すのがよいです。立体的にするためには依頼の形を変えて、複数の視点から依頼を整理します。形を変える基本はストーリーと相関図です。

ストーリー：時間の流れの中で要素の関係を表現する（プロセス、時間軸、動的）
相関図：時間を抜いて、要素の関係を表現する（空間軸、静的）

ドラマなどでもあると思いますが、ストーリーは話の展開として時間軸に進んでいく一方、人物相関図というのは、その時点での関係性をズバリと書いてあります。

では、まずはストーリーで表現してみましょう。自分や他人が行う作業を順番に記載します。言われたままですが「Aに移動し、箱を持って、Bに移動し、箱を置く」というだけですね。

こう書いてみると「ここからA」「AからB」は、どのぐらいの時間で移動できるんだろう？ということが疑問になります。場所を知らないのは良いとしても、移動時間が分からなければ作業予定の立てようがないですね。

では、次に相関図に表現してみましょう。こちらは登場する要素同士の関係性を考えてみます。登場するのは、自分、箱、A、Bの4つなので、それらの関係を記載します。

相関図で見ると、自分が箱を持ったり、置いたりするのだなと思いました。これは果たして1人でできるのでしょうか？箱が重かったり、巨大じゃないか？壊れやすいものじゃないか？ということが気になりました。これらの箱の特性によっても作業が変わってきそうです。

それでは、2つを組み合わせてみましょう。

組み合わせて考えてみると、相関図では箱はAに置いてあり、Bに置きにいく必要があります。では、Aのどこに置いてあり、Bのどこに置くのでしょうか？行けばわかるものでしょうか？鍵が掛かっていたりしないのでしょうか？誰かに協力してもらわないとダメかもしれません。

整理すると、以下のようなことが「分からないこと」になりそうです。

どこに箱があるのか？1人で取りに行けるのか？
内容物は何か？1人で運べるのか？手で持てるものなのか？
Bの場所はどこか？移動手段は？
Bに行って、どこに置くのか？誰かにお願いするのか？

立体的に理解する

ストーリと相関図を書くにも、それぞれ「依頼を理解して表現する」ということをしています。しかし、1つの視点で理解するだけでは、正確に理解できていないことがあります。そこで、あえて複数の視点で理解したことを組み合わせることで、立体的に理解を深めていきます。この複数の視点を持つために「ストーリ」と「相関図」というのは非常にわかりやすいモデルになります。

おすすめはストーリーから書くことです。人間の脳は時間にそって考えるほうが得意です。あれやこれやといっぺんに考えると混乱してしまうからです。ですので、まずはストーリーを考えて、そこから相関図を起こし、さらにストーリーと相関図を組み合わせて確認します。

おそらく、あなたは引っ越しの手伝いをしているわけではないと思うので、ここで書いたことは比喩です。実装の依頼か、テストの依頼か、仕様変更の依頼か、仕事の内容はわからないですが、意識して複数の視点から立体的に理解しようすることで的確な質問ができるようになります。仕事をする上で、分からないことがあるのは全く問題ありません。問題なのは分からないことを分かろうとしないことです。

2.提案する：複数の選択肢を考える

理解が深まったことで、背景も共有ができれば、どのような手順にすべきかを考える必要があります。そのときに選択肢を増やすことで、さらに視野を広げるとよいです。その際に便利なのが四象限や窓と呼ばれているフレームワークです。

仕事を任されたのであれば、作業手順を整理するにあたり、そこには必ず選択の幅があります。しかし、まずは知っている手段の中でなんとかしようとしてしまいがちです。もしかすると、もっと効率的な方法があるかもしれません。窓のフレームワークを使うことで、思い込みを避けます。

例えば、以下のような窓が考えられます。

もちろん、運ぶ対象や場所の特性によってさまざまな考え方があるでしょう。どれが正解とか、常にこれということではなく、無理やり四象限にしてみて、自分が思いつく方法をマッピングしてみることで他の選択肢を検討することが大事です。

例えば左から3つ目の窓は「移動させる」ことすらない方法を検討しています。もし、何かをBに届けるのが目的なら、Aにあるものを移動させるのではなく、新しく購入して届けてもいいはずです。引っ越し荷物をしまう段ボールが欲しいだけなら、別にAにあるものを持っていく必要もないです。Bの近所の配送センターで買って届けてもいいでしょう。

窓のマッピングができれば「その手順が最適だと思った理由」が把握することができます。これも一緒に仕事をする上で重要なことです。手順に問題があった場合、それが「その手順にした理由」が問題なのか「理由は正しいが手順の選択が悪い」のかは大きな違いです。箱を「紙袋ではなくビニール袋にいれるべき」というときに、それが濡れているものだからなのか、冷蔵品で一緒に氷をいれるからなのかは大きな違いです。後者なら、ビニール袋＋氷ではなく保冷バックもよい手順になりますが、濡れているものなら意味がないですね。

3.計画する：タイムボックスでフィードバックを受ける

手順が明確になってきたら、それを計画に落とし込んで、実際の行動に移していきます。しかし、依頼を立体的に理解し、手順について複数の選択肢から自分が最適と思われる手順を選んでいても、その手順が絶対に間違いない品質で実行できるとは限りません。特にエンジニアリングは、対象物が変わっていくものなので「同じことの繰り返し」になることがなく、毎回が新しい作業手順になりがちです。そんな時は適切にフィードバックを受けることが必要になります。

フィードバックというのは、成果物を作って、それを有識者にレビューしてもらい、問題を発見する手法です。他人の視点を利用するのは、常に重要な手法です。上手にフィードバックを受けられれば、成果物の品質を効率的に高めることができます。

フィードバックは成果物に対して行われます。なので、成果物を作るための行動が先に必要になります。大事なことは、どのタイミングでフィードバックを受けるべきか、ということになります。レビューを受けるべきタイミングは成果物が完成した時でしょうか？半分できた時でしょうか？

経験が少ないうちは、一定の時間が経過したタイミングで強制的にフィードバックを得るべきです。なぜなら、手順が間違っているなら、そもそも「完成した」とか「半分できた」といった指標そのものが間違っている可能性があるからです。しかし、経過した時間だけは、誰にとっても同じもので、絶対的な指標になります。2時間やったらレビューしてもらうと決めたら、2時間後は必ず訪れるし、なによりも「2時間後にレビューしてください」という約束がしやすくなります。

仕事の経験が積まれてくると、こうした作業手順の選択ミスや実施ミスは減っていくため、フィードバックのタイミングを早める必要性もなくなってきます。むしろ、一定のレベルに達したら、とか、骨組みができてからといったこともできます。ただ、そういう経験が浅い時は、ともかく「時間がきたらレビューしてもらう」ほうが安全です。

おすすめのレビュータイミングは0時間、2もしくは4時間の2つです。

0時間というのは、作業を始める前に、その作業に名前をつけて共有します。例えば「箱を探します」という作業をすることを宣言します。その時点で、まずレビューを受けることが可能です。「いや、それ俺に聞けよ」と言ってもらえれば、それで作業完了です。

2もしくは4時間というのは目安ですが、ようは1日を2〜4つぐらいに区切って、その箱（タイムボックス）単位に作業を考えます。レビューの数は多い方が微調整ができます。かの有名なXP白本*1の冒頭で、著者のケント・ベックは母に教わった運転のコツを紹介しています。

「運転で大切なのは，車を正しい方向に進めることじゃないのよ．大切なのは，常に注意を払って細かく左右に方向修正していくことなの．」

運転とは、視界に映る要素や車の計器からのフィードバックを受けながらを、周辺環境とのインタラクションを行う行為です。自動車が何キロで、どの方向に進むべきかというのは、目的レベルでは目的地に向かう距離を時間で考えればいいことですが、まさに、今現在で走行中あれば、そんなことよりも周辺環境に沿った最適な手段であることが最重要になります。道が曲がっているなら、一旦は目的の方向から違う向きになるにせよ、道に従うべきです。

仕事の経験が積まれてくると、今の景色から次に起こることが予測できるようになりますし、計器に表示されている数字の意味もわかるようになってきます。そうでないなら、やはり、小さくフィードバックを受ける必要があります。作業に名前をつけて、タイムボックスに仕事を区切る癖をつけるとよいでしょう。

レビューは現場の状況を共有し、場合によって依頼そのものを修正することにも役立ちます。「言われた通りにやったのにできませんでした」は理由になっていません。あなたは依頼者よりも実際の作業現場の状況を正確に把握しています。ハンドルを握っているのはあなたであり、依頼者ではないのです。

「その道を通れ」と指示されても、道路が陥没しているなら通るべきではありません。それで車が壊れたら、悪いのは依頼者ではなく、あなたです。道路が陥没していることに気づいたら、すぐさま0時間レビューをします。「回り道をします。なぜなら道路が陥没しているからです」と宣言しましょう。そこで「あっちの道にしたらいいよ」とか「陥没なら、その車は進んで大丈夫」とか「そもそも、依頼を見直そう」と言ってもらうことが大事です。

ちなみに「タイムボックスでフィードバックを受ける」というのはアジャイルの考え方と同じです。作業の見積もり、作業の切り方、作業管理のコツなどはアジャイルの手法から学ぶことができるはずです。

3つの立場

最後に作業の実施について重要なことがあります。「立っている者は親でも使え」といいますが、仕事をする上で必要なのは「立ってなかろうが、上司も使え」というマインドです。

僕が2−3年目のころ、当時の上司は僕に対して「いいか、俺とお前には3つの立場がある」とよく話してくれました。

俺はお前の上司だ。だから、指示も命令もする
俺とお前は仲間だ。だから、一緒に問題を解決する
お前は俺よりも現場がわかっている。だから、現場の問題解決を俺に指示しろ

今のシステム開発において、上司が全てを把握し、部下よりも詳しいということはありえません。もしこれが、ひたすらに煩雑な事務手続きだったら違うかもしれません。上司の方が事務手続きに精通し、さまざまな問題への対応方法も完璧に理解していることもあるでしょう。でも、新しい技術が登場し、システム間連携は複雑化し、ユーザーの要求が多様化する中で、上司がさまざまな問題への対応方法も完璧に理解していることは少ないです。

こう言った状況では、上司を上司としてだけ捉えるのではなく、仲間であり、あるいは問題解決の依頼先として意識する必要があります。

自分で問題解決できないなら、問題解決できる人を見つけて、問題解決してもらうのも仕事です。あなたが一切作業をすることがなかったとしても全く問題ありません。なぜなら、依頼者が依頼したのは仕事であって、作業ではないのです。