23
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

最近自分がしていたのは「作業」であって「仕事」ではないと気づいた話

23
Posted at

はじめに

突然ですが、皆様は「作業」と「仕事」の違いを意識されたことはありますか?

エンジニア2年目の私は、今年の8月頃から新しいプロジェクトの立ち上げに伴い、半PdM/スクラムマスター的な役割を任せていただくことになりました。その中で、いままでエンジニアとして業務をしていた頃と、求められる役割や立場、日々の業務内容自体も大きく変わったのですが、そこで突きつけられたのは、

  • いままでの自分の業務全般に関する思考の浅さ、狭さ
  • HOWにこだわり、ただイチ作業を早く完遂させることへの執着
  • 総じて「今のPJでは全くバリューが出せてないのでは」といった無力感

などといったものでした。

それでも無我夢中で目の前の業務に打ち込んできましたが、正直、今でも日々モヤモヤすることは多いです。その中で「そもそも、自分が何にモヤついていて、何が起因しているのか。それらはどうすれば解決するんだろうか」と、自分なりの自己理解と言語化を模索してきました。

そんな時、今の自分にグサリと刺さるような言葉に多く出会い、学びとして昇華している最中でありながらも、本記事では、自戒を込めたポエムとして記します。

社会人として当たり前の内容も多く、稚拙な内容かもしれませんが、もし同じような悩みの粒度でモヤついている方がいれば、その方への何かの気づきのきっかけになれれば幸いです。

1. 「作業」と「仕事」の定義を再考する

これまで私は、エンジニアの業務として「決められた仕様に対してどう実装するか」を考え、PRを出し、レビューをもらってマージする。チームメンバーの進捗も管理しつつ、納期までにPJを完遂できるよう日々実装する……という流れをスムーズに行えるよう、技術のキャッチアップに励んできました。

しかし今振り返ってみると、良くも悪くも、これまでの自分はあくまで作業に没頭しており、その作業が完了すること自体に快感を覚えていることが多いのだと気づかされました。

ここで私が今考えている「作業」と「仕事」の定義を整理します。

作業とは:「外部に正解があるもの」や「思考を必要としない、手を動かす単純作業」をこなすこと

正解がすでにどこか(仕様書、過去のコード、Web上の記事、あるいは上司の頭の中など)にあったり、事前に定められた手順を適用して行動する行為と捉えています。私の業務で言うと、「仕様に対して、言われた通り、仕様通りに実装できているか」を基準として動く状態です。必ず答えがある、小中高のテスト勉強にも通ずるものがあると思います。

仕事とは:「目的」に対して、思考し意思決定をすること、答えを導き出すこと

正解がない、あるいは複数の正解がある状況で、目的に対してベストな選択肢かを自分の頭で考え、提案し、決断する行為だと捉えています。それは、その先にいる相手(顧客、チーム)に価値を提供するために、付加価値を生み出す活動とも言えるかもしれません。要は、最終的に誰かに価値を届けるために、どうすれば良いかを自分の頭で考えつつ行動する、価値創造の活動であると考えています。


ここでお伝えしたいのは、「作業=悪、誤」「仕事=良、正」ということでは決してありません。無論、作業が大事なタイミングもありますし、「作業だけしている人がダメ」といった考えではありません。あくまで、いまの自分の置かれている立場や状況、業務内容を考慮すると、自分にとっては「作業だけでなく、仕事をもっとできるようにしようぜ。自分の仕事に対して責任感を持とうぜ」という反省に至っているという背景です。

その中で、下記の言葉が自分の中でとても染みました。

経営者や上司が目的を話していても、「で、結局私はどんなふうに仕事をすればいいんだっけ」「その中で、私のすることは具体的に何ですか?」などを、先行して考えてしまう。そういう人ほど、目的からずれてしまうのです。これは、上司からのオーダーをMISSIONに変換する前に、HOWに変換してしまっているのだと思います。
引用元: 目的を見失わない処方箋

書いてあること自体は単純で当たり前と感じやすいですが、恥ずかしい話、自分は無意識にHOWばかりに目がいってしまいがちになり、日々の業務の中でも目的が見失いがちになっていたことが多いなと改めて反省しました。

2. 「仕様通り」は責任の回避でもある

「仕事(目的の追求)」をすべきだと分かっていても、つい気づいたら「作業(手段の実行)」に没頭し、本来の目的とズレてしまうケースは多々あります。

特にエンジニアである以上、コードを書くこと、技術的なアプローチを行うことは重要な役割の一つです。そのため、「何のために(WHY)」を問い直すプロセスよりも、どう作るか(HOW)への興味関心が強くなる傾向にあるのは自然なことでもあり、逆にHOWを突き詰めるのも醍醐味の1つだったり、そういうスペシャリストもいるでしょう。

しかし、前述の通り、「とりあえず言われた通り、仕様通りのものを作った」というスタンスは、今の自分の立場やチーム状況においては適していないと痛感しました。


「オーダーに対して適切な成果物」を出すことは、一見誠実に見えます。しかし、そこには「もし失敗しても、指示通りやったのだから自分のせいではない」という無意識の責任回避が一定含まれているのではないでしょうか。

真の意味で仕事に対して責任感を持つということは、「そのオーダーが目的に対して不適切だと思えば、上司やPdMに対してもNOと言い、エンジニア目線での別の提案をする」までを含むことであり、大事なのは、型を守ることではなく、「今のチーム状況なら、あえて型を破ってでもこの議論をすべきだ」と目的のために決断することにあるのだと気づきました。

まさに、一緒にPJを進めているPdMとの1on1時にも、「大事なのは、プロジェクトを成功させる気持ち、スタンス。バックエンドのこのタスクを前に進めるというより、PdMといっしょに仕事を進める気持ちが何より大事。もちろん両者とも重要だけど、根幹はここ気持ちとスタンスを持っていれば、おのずと視野は広がるよ」とフィードバックを頂きました。

3. 自分の現在地を「提案のレベル」で測る

少し話が飛びますが、「作業」から「仕事」へとシフトするために非常に参考になったのが、以下の記事です。スライドの中で紹介されているレベル感は、まさに「作業」と「仕事」の境界線を明確にしてくれるなと思います。

スクリーンショット 2025-12-23 23.33.37.png

引用元:提案のレベルを上げる / Raising the Level of Proposals - Speaker Deck

記事内にもある通り、「提案レベルを上げておくと選択肢が広がり、自分でコントロールしている感覚が増えて気持ち的にも楽」は、まさに自分も「何事も自分でコントロールできない、分からないことが多すぎると楽しむ気持ちより、不安やストレスを感じがち」な特性なので、言い得て妙だなと感じました。

そして、何度も言いますが、現場の状況やチームによっては求められることが上記のスライドで言うレベル0のこともありますし、「レベル0=悪」 というラベルを貼りたいわけではありません。

ただ、以前の私は、PdMから仕様の穴を指摘されるまで気づけないことが多かったり、自身の知見不足から技術的な意思決定に対しての不安や、「とりあえずどうしましょう?」と聞き返したりするような、まさにレベル0の状態でした。

しかし、自分の置かれている状況や役割を考慮すると、最低でもレベル2〜3を目指さなければならないし、自分だけで決められないことを提案するレベルを上げることが、今後の自分にとって大きな自信にもなると思います。この記事で書かれている内容は、新規PJを進めるにあたっての、自分の思考停止状態を暴いてくれるきっかけとなりました。

少し過激な表現ですが、「最低でもレベル2以上でなければ、自分自身はバリューすら出せず、チームにいる意味がない」くらいの危機感すら覚えています。

4. 「ただ頑張る」のではなく「努力」を積み重ねる

その上で、じゃあ日々反省を活かしながら前に進むために頑張りましょう!という話なのですが、「ただ頑張る」と「努力」の違いについては、しっくりくる言語化された以下の記事がとても参考になりました。

頑張ることは、「とにかくやること」だ。方向も考えず、効率も考えず、ただ時間とエネルギーを投入する。

努力することは、「正しい方向に向かって、苦しみを引き受けながら、行動し続けること」だ。方向を意識し、フィードバックを得て、修正しながら進む。効率を考える。戦略を立てる。ただ、考えるだけでなく、実際に動く。これは、頑張ることとは違う。しかし、努力には「やること」が含まれている
引用元: おい、努力しろ - じゃあ、おうちで学べる

「考える」ことは苦しい作業です。特に、自分は今まで日常で積み重ねてきた思考量(累積思考)が多くなく、脳が汗をかくくらい思考する経験値がまだまだ足りてないと感じています。今までも、忙しさを理由に考えることをやめ、心地よく、やった気持ちになれる「ただ頑張る」ことに逃げてしまいがちです。

しかし、その思考の負荷を引き受けて初めて、自分の中の判断基準(自分の背骨)が形成されるのだと思います。その負荷から逃げずに、

  • 一つひとつの意思決定に「自分の言葉」を乗せていくこと
  • 「日頃から思考を積み重ねておく」そして、それを「引き出しやすい状態に構造化しておく」こと

上記を続けて、ようやく自身の役割であるプロジェクト推進や、チーム、組織へのバリューを出せるような人材へのスタートラインに立てるのではと思います。

おわりに

総じて、センチメンタルなポエム(笑)になってしまいましたが、最近感じていたモヤモヤと、そのモヤモヤを晴らすためにどうすれば良いのかをざっと振り返りをしてみました。色々書きましたが、

  • 悩みすぎて時間を浪費するのはもったいない
  • それでも悩みが晴れないなら、思考を吐き出して客観視してみる
  • 兎にも角にも、愚直にバッターボックスに立って経験を積み、反省を活かす
  • やってみてうまくできたら「自信」うまくできなかったら「経験」くらいのスタンスで努力を続ける

考えすぎて手が止まるのも嫌なので、上記のエッセンスを自分に言い聞かせてます。

仕事の仕方が激変したこの数ヶ月、不甲斐なさやもどかしさ、焦りを感じる毎日ですが、自分の仕事に対して真の意味で責任を持ち、一歩ずつ思考を積み上げていきたいと思います。

最後までお読みいただきありがとうございました!

参考文献

23
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?