無限に増え続ける仕事、忙殺を回避するには

## 仕事は無限化する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/426622/2ce380ee-5ad5-28dd-ec7a-35891a898eeb.png)


エンジニアやマネージャーは多くの場合でしっかりと意識しないと、仕事は無限に増えていってしまうのではないかと思います。

* システムの不具合報告の対応
* 既知の課題や問題への取り組み
* 人材マネジメント
* 業務フローの見直し
* 他部署とのコミュニケーション

やるべきこと、やらないといけないことは常に山積みです。

仮にもし、目の前のタスクが一瞬で片付いたとしても、考え方次第でいくらでも生み出されます。

* 業務効率化の手法はないか
* ボトルネックになっている部分への対策はどうするか
* 採用計画とそれに伴う施策の策定と実施
* 新規顧客の開拓とそれに伴う営業ツールの準備

## 役に立ちたい、助けになりたい

ビジネスにおいて、困った状況というのは起きるものです。
無理なスケジュールだが、どうしても変更できない。
要求が難しく、それに対応できる適任者がいない。

顧客からそのような相談を受けたときに、なるべく解決してあげたいと思います。
「平日はもう時間がとれないが、次の土日であれば差し込めるかも。そうすると目的は達成できるかもしれない。」

しかし、そうやって無理にタスクを積み上げていくと、長期的には負債を溜めていくだけではないかと考えを改めるようにしました。

## 会社組織として仕事を請けることに注力する

過去の実績を評価され、ご指名いただけることは大変喜ばしいことです。
ただし、それが組織ではなく、個人としての名指しに偏ると組織として機能しなくなります。

> If you want to go fast, go alone. If you want to go far, go together.
> 早く行きたければ一人で行け、遠くへ行きたければみんなで行け

このような言葉がありますが、まさに短絡的に成果をあげるか、長期的に成果をあげるか、持続可能かどうかを示唆した良いことわざです。

## 溢れる限界まで多くの仕事を抱え込むリスク

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/426622/15a93bfa-0b00-e27f-f892-f74684c88978.png)


持ち物が増えれば増えるほど、担当する業務が増えれば増えるほど、どこかに想定外の事が発生し予定は狂いやすくなります。

タスクを詰め込むだけ詰め込んだ中では、想定外のことを吸収する時間がどこにもない状態となります。

こうなると顧客との期待や約束を守れなくなるリスクが非常に高くなります。

## 色々と見直した

直近の1,2年は本気で考えを改めて見直しました。

### 基本的な業務の時間の中で収まる仕事量に

想定外の出来事や、ビジネスにおいて強烈なインパクトがあるようなケースは別ですが、基本的な想定業務時間内にて収まる仕事量を上限として請けることを強く意識するようにしました。

### 組織全体をうまく巻き込める仕事かどうか

上限を意識した場合は、いくつもの仕事をお断りすることになります。
限りあるリソースの中で、どのような仕事であれば請けることができるか判断する必要がありますが、個人で戦う必要がある案件ではなく、会社のメンバーのリソースを有効活用できるかどうかを意識するようにしました。

### 任せる決意とコミュニケーションの流れの見直し

伝言ゲームは間に人が入れば入るほど難易度が上がります。
間に人が介在すればするほど、重要な情報が欠落したり、要望がねじ曲がってしまったりする可能性が高まってしまいます。

短略的に考えれば、実装を担うエンジニアが顧客を理解し、自身でヒアリングし、ドキュメントを起こし、ファシリテーションやプレゼンテーションまで実施して、合意形成まで出来れば効率良いように思います。

しかし、これをやってしまうと人を選ばないような難易度の低い作業や細々とした作業も、一身に受ける状態となり、極限に多忙を極めると、これらを他者に割り振るコストさえ払えなくなります。
依頼し、説明し、確認するのであれば、数分で自分がやってしまったほうが早いと。

これは終わりの始まりです。
下記の不等式から抜けられなくなるのです。


```
"人に助けをもとめて、実際に自分の負担が減るまでに自分が負うコスト" > "減る負担分のコスト"
```

このため、多くの案件で体制を下記のように変更しました。

#### Before


```mermaid
flowchart LR
    Customer[顧客] --> Director[ディレクター]
    Director --> TechLead[技術チームリーダー（私）]
    Customer --> TechLead
    TechLead -. 可能なら作業依頼 .-> TechTeam::[技術チーム実装担当者]
```

* ディレクターの機能を技術チームリーダー（私）が兼任することもあった
* 前述のとおり他者に割り振るコストが払えず、また期待どおりの成果が挙げられない場合は、実装までやることも

#### After

```mermaid
flowchart LR
    Customer[顧客] --> Director[ディレクター]
    Director --> TechTeam[技術チーム実装担当者]
    TechTeam -. 報告・相談 .-> TechLead[技術チームリーダー（私）]
    Director -. 相談 .-> TechLead
```

* 請負案件はなるべく顧客との接点に自分以外の人に立ってもらうように
* 社内からはディレクターと実装担当者の間に入って品質管理を期待されますが、「そもそも要件と違う」、「明らかにエラーがある」など人を選ばず確認出来ることに忙殺されると、やはり「自分でやってしまったほうがよっぽど楽」問題が発生します
* 考え方があっているか、そもそもやり方が不明、などの場合に作業者から相談してもらうようなフローとしました

### マイクロマネジメントしないように

https://qiita.com/koji-yamauchi/items/3c41b835c7b23295aa65

上記にも記載しましたが、先導型リーダーシップに走りすぎて、指示者の能力の限界が、組織の能力の限界になってしまわないように意識しています。

例えば、「XXXの技術において、私はあまり知見がないので、あなたが社内で一番詳しい人になってください。そして社内にナレッジが共有できるよう文書化してください。」などのようにしています。

https://qiita.com/koji-yamauchi/items/80d7e735f3e4c5608aa9

上記の「マイクロマネジメントで機会を奪わないように」にも記載しましたが、進め方の道筋までこちらでつくって、作業化して作業だけの依頼をしてしまってはコンフォートゾーンは広がりません。

マイクロマネジメントで学びの機会を奪わないように意識するようになりました。

## 結果として

### 周りが頼もしくなった

しっかりと周りへ頼れるようになりました。

暗黙の期待ではなく、「私はこういうことを期待している」と言語化するようにしました。
皆がそれを実現するために創意工夫を行い、しっかりと考えてうまく相談や報告をしてくれるようになりました。
早くから信頼して任せるべきだったということと、学びの機会を奪っていたことに反省です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/426622/3272e4cc-f1bc-b551-8ea9-e50a5afe43ae.png)

### 家族との時間を確保できた

一時期はタスクの消化を優先するあまり、家族との時間が取れず子供を公園へ連れていくことも難しい状態でした。

今では家族全員で旅行にいく機会を定期的に設けることが出来て、「あぁこんなにも喜んでくれるのであれば、もっと早くからこうするべきだったな。」と思います。

![DSC_0854.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/426622/71b26a80-af36-48de-c42d-7b95cce96269.jpeg)
$\tiny{去年はこれまでの罪滅ぼしを兼ねて4泊5日石垣島旅行に。子供からは今でも「まるで天国だった」と言われます。}$

### インプットの時間を確保できた

基本的に土日に業務を行わないようにした分、この時間を使って沢山の本を読むことが出来ました。

### 心身の調子がすこぶる良くなった

一時期は仕事の詰め込み過ぎによって体調も優れませんでしたが、今は快適な状態が続いています。
そして普通に食事がとれるようになったので随分と太りました。

### 長期的な目線を持てるようになった

常に目の前のことに手一杯で、やらなければいけないこと、約束事をこぼれ落としてしまわないかという恐怖と不安におそわれていました。

今は、多くの仕事をチームとして対応できるようになったおかげで、採用計画や今自分にできることはなんだろうと深く考えれる余裕ができました。

## まとめ

### 問題を先送りするだけの対応を行わない

売上を上げるために、限界を超えて稼働する。というのは、向き合うべき問題を先送りしているだけです。
そうしないと成り立たないのであればビジネスモデルか組織構造に間違いがあるのでしょう。
手をいれる必要があるものを、解決すべき問題を見えなくするように頑張っているだけに過ぎません。

### 持続可能かどうかを考える

綱渡りな仕事や生き方は例外対応に非常に弱いです。
持続可能な組織構造なのか、ビジネスなのか、どのようなチームになるべきかをしっかりと考え、言語化しなければならないと思います。