本文へスキップ
I'm Shuo
戻る

仕事の責任について語るとき、私たちは何を語っているのか?

この記事は中国語版を AI が翻訳したものです。内容に相違がある場合は中国語版を正とします。

現場で直接プロジェクトを率いることから離れて久しい「技術系マネージャー」の私ですが、ここ数日、所属プロジェクトで起きた出来事によって、思考を再び泥臭い協調の現場へと引き戻されることになりました。

今の職場の文脈において、私の考えが完全に「ポリティカリー・コレクト」と言えるかはわかりません。ですが、これは偽らざる実感であり、反省でもあります。厳しい残業もなく、業務量も比較的適正なチームにおいて、なぜ最も基本的な「仕事への責任感」を語ることが、これほどまでに贅沢なことになってしまったのでしょうか。

01. ルール遵守を盾にした「我が身可愛さ」が、真面目な人を疲弊させる

発端は、プロジェクトにいる二人の同僚でした。

同僚 A と同僚 B は業務ライン 1 を共同で担当しており、さらに B は業務ライン 2 も兼務していました。ここ数日、A がプロジェクトマネージャー(PM)のもとに駆け込んできました。精神的に限界寸前といった様子です。A によると、B は業務ライン 1 の仕事をほとんど分担してくれず、声をかけても何かと理由をつけて逃げてばかりいるとのことでした。たまに成果物を出してきても質が低く、仕上げや後始末の多くが A に降りかかっていました。真面目で責任感の強い A は、許容量をはるかに超える業務を背負い込み、心身ともに疲れ切ってしまったのです。

PM の説明はこうでした。「B が担当する業務ライン 2 で突発的なトラブルが起きて手一杯だったのは確かだ。チームの人数も限られていて、どうにもならなかった」。

私自身、B のことを知らなかったわけではありません。これまでの印象でも、彼は個人の権利を極めて重視し、有給休暇の消化を徹底して守る一方で、第三者から見ると明らかに全体への責任感に欠ける人物でした。彼の仕事は常にギリギリ合格点止まりです。完全に投げ出すわけではないものの、周囲から「良い」あるいは「期待以上」と評価されるような成果を自ら出そうとは決してしません。

職責上、私は B と 1 時間ほど腹を割って話しました。やりとりは終始平行線でした。私が率直に疑問をぶつけ、彼が一つひとつ反論し、最後にタスクを再調整しました。B の論理は極めて典型的でした。

話し終えたあと、私も自分を省みました。色眼鏡で彼を厳しく責めすぎていないだろうか、と。

答えは否でした。B の言い分は、法規や社内規定、人事評価の基準に照らしても手続き上の不備は一切なく、完全にルール通りです。しかしチームの協調とは、法律条文の解釈ごっこではありません。全体のバランスの上に成り立っているものです。

残業を強制されることもなく、8 時間で十分カバーできる業務量において、その構造は残酷です。誰かが 80% しか本分を果たさず、あるいは 60 点スレスレでやり過ごすなら、その穴は必ず別の真面目な人が 120% の負荷を背負って埋めることになります。

一時的に仲間の穴を埋めるのは助け合いです。しかし、誰かの不作為を長期にわたって尻ぬぐいさせられるのは、責任感ある人への理不尽な懲罰であり、チーム崩壊の引き金になります。昔から「乏しきを憂えずして等しからざるを憂う」と言いますが、職場で最も人を傷つける不公正は、「ルール遵守」を隠れ蓑にした責任逃れの中にこそ潜んでいます。

結局、仕事をサボっていると彼を責め立てる立場には立てませんでした。私はただ一言、言葉を贈りました。「一日坊主なら一日鐘を突く。けれど大事なのは、心を込めてその鐘を突くことだよ」と。

02. お世話係がいなければ、エンジニアは対話すらできないのか?

続いて、第二の出来事が起きました。

B が有給休暇を申請してきました。正当な権利ですから、何のためらいもなく承認しました。しかしタイミングが極めて微妙でした。業務ライン 2 の課題はまだ完全には片付いておらず、プロジェクトは厳しい納期に直面していたのです。

PM が私のところへやってきて、言い淀みながら言いました。「B が休みに入ったのですが、同僚 C のモジュールは B の上流にあって、今手が止まっています。C と D は、私(PM)も近々休暇を取ると聞いて、いっそのこと私が休暇から戻るまで作業を保留にしようと言い出しました。でも戻る頃にはもう納期です……私の休暇、取り下げたほうがいいでしょうか」

私は深い無力感を覚えました。

たとえ B が一時的に不在だとしても、C と D も技術の鎖を構成するプロフェッショナルです。明確な前後の依存関係があるにもかかわらず、なぜ二人のプロのエンジニアが「調整役が間に立ってくれないと、この仕事は進まない」と思い込んでしまうのでしょうか。

技術者とは本来、問題を解決する存在のはずです。しかし、いつの頃からか、ライン作業員のように退行してしまった人たちがいます。すぐ隣で笛を吹いてもらわない限り、前後の工程に決して目を配ろうとしないのです。

03. 200 行の手軽なコードと、エンジニアの「責任ライン」

今日、B はすでに自宅で休暇に入っています。幸い最低限の引き継ぎは果たしており、業務ライン 2 のタスクを整理した詳細なドキュメントを残してくれました。C と D もようやく何がボトルネックになっているかを明確にしてくれました。要するに、C がデータを処理して保存し、B のプログラムがそれを消費し、D が環境全体のデプロイを支援するという構造です。

私は久しぶりに IDE を開き、自ら C のコードを調べました。ロジックに致命的な問題はないものの、サーバーのリソース設計と設定に明らかな不備がありました。私は C と D をリードし、最初のデプロイ検証を通しました。同時に、B の休暇中、彼のドキュメントに沿って C や D と一緒に連携テストと本番反映までやり切るつもりです。単なる設定やリソースの問題なら、納期直前に破綻するのを待つまでもなく、自分たちで解決できます。

その過程で、私はもう一つの「責任感」のズレに直面しました。

C が担当するこのサービスが極端に計算リソースを食っていたのは、もともと海外チームが残した技術的負債と、冗長で乱雑なアーキテクチャのせいでした。私は C に対し、この機会に定評あるオブジェクト指向とデザインパターンを取り入れ、今後の業務拡張に耐えうる軽量で汎用的な標準フレームワークを組むよう提案しました。負荷を減らすため、私自身も AI を使って約 500 行のフレームワークのプロトタイプをまとめ、100 行のサンプルコードまで添えて渡しました。

ところが C の返事は素っ気ないものでした。「もらったコードは複雑すぎます。使うつもりはありません。自分で AI に作らせたコードなら 200 行で済みますから」。

私は無理に自分の案を押し付けはしませんでした。彼の視点からすれば、規律ある設計は「過剰設計」に見えたのかもしれません。しかし、最低限のラインだけは引きました。「自分のやり方でリファクタリングする前に、必ず C4 Model でソフトウェアのアーキテクチャ図を描き、システムコンテキストとコンポーネントの関係を私に説明してほしい」と。

コードの行数の多寡は、決してコードの良し悪しを意味しません。AI を使えば、とりあえず動く 200 行のスクリプトはあっという間に書けます。しかしシステムの拡張性や保守性、エッジケースの処理を無視するなら、その場しのぎの「アジリティ」は、後から引き継ぐ誰かに技術的負債を先送りしているだけにすぎません。生み出すコードの品質に責任を持つこともまた、エンジニアとしての基本的な職業倫理です。

04. 誰が真面目な人を「働きすぎ」に追い込んでいるのか?

現場の技術者から中間管理職へと歩んできた中で、私にはずっと持ち続けている、それほど厳しくない評価基準があります。

現在の管理方針において、私たちは労働時間を搾取していませんし、納期の見積もりもむしろ寛容なほうです。それでも納得がいかないのは、なぜ自分の合格ラインを「60 点万歳」まで引き下げてしまう人がいるのか、ということです。誰もあと一歩を踏み出そうとせず、75 点を目指す意欲すら見せません。

この極めて自己中心的な「最低限主義」は、本質的に、職業意識を持って真面目に仕事に向き合っている人たちからの組織的な搾取です。

最初から身を削ってまで突っ走りたい人など、職場にはいません。多くの場合、疲弊しきった「中核メンバー」は、他人が放り出した後始末を強いられ、宙に浮いた 40% の穴を埋めることを強いられた結果、環境によって無理やり「巻き込み役」に仕立て上げられているだけなのです。

本当の仕事の責任感とは、大仰な道徳の押し付けでも、退勤後の意味のない自己陶酔でもないはずです。それはごく素朴な契約精神にすぎません。「自分の持ち場において、胸を張れる成果を出すこと。そして協調の境目において、あと半歩だけ前に差し出すこと」。

もしチームが「我が身可愛さ」を世渡り上手と勘違いし、「無関心」を境界線の尊重と言い換えるなら、傷つくのはプロジェクトの進捗だけではありません。仕事に真摯で、心に情熱を持った信頼できる人たち自身です。そして、そうした平庸な逃避を仕組みで見抜けず、黙って支えてくれている人たちを守れないのだとしたら、それこそがマネージャーの最大の怠慢なのです。


この記事は CC BY-NC-SA 4.0 ライセンスの下で公開しています。転載の際は出典を明記してください。

この記事を共有:

前の記事
AIコーディング時代における個人開発の技術スタック再定義
次の記事
自作 Firefox ブックマーク同期ツール「bmsync」を作った