SEが激務の場合の解決策は５つ。時間とリスク管理が主なポイント

どうも！ひよこSE（@PiyoOct）です。

という人向けの記事です。

「SEが激務なのはなぜ？３つの理由を詳しく解説【ほぼPJの環境のせい】」という記事でも書きましたが、激務になる原因はプロジェクトのせいであるケースがほとんど。

だとすると、SEにできる解決策は

1. 時間が過ぎるのを待つ
2. リスク管理は徹底する

の２つが主なポイント。

さらに細分化すると、５つあります。

SEが激務の場合の解決策は５つ。時間とリスク管理が主なポイント

SEが激務の場合の解決策は５つです。

現在進行形で、激務な状態な人は、

みたいに思っている人もいるかもしれませんが、時間で解決されるケースが一番多いです。

「ウソつくな！」と思っている人もいるかもしれませんが、ひよこSE自身がこのパターンです。

その１：SEの開発納期が過ぎて激務から解放（時間で解決）

納期が忙しいなら、過ぎてしまえば一気に楽になる！

SEが激務になる原因の一つとして、「SEが激務なのはなぜ？３つの理由を詳しく解説【ほぼPJの環境のせい】」という記事でも書きましたが、「納期が迫ると激務になりがち」だと説明しました。

・・・ということは。

案外、単純な話。

納期さえ過ぎてしまえば、逆にヒマになってしまうことが往々にあります。

※そもそも運開（運用開始）できていない。テストも未完など、大炎上している場合は論外です！

知らないうちに暇になるので、その時に休む

つい、この前まで夜の11時くらいまで仕事していたのが、あら、不思議。

開発が終わったとたんに、

となります。

今は信じられないかもしれませんが、知らないうちに暇になっちゃうことが、SEという仕事に案外あるりがちなのです。

その２：別プロジェクトに異動して激務から解放（時間で解決）

別プロジェクトに異動して激務から解放されるケースも多いです。

別プロジェクトは天国のこともよくある

別プロジェクトに異動すると、そのプロジェクトが天国であることがあります。

要は、個人の問題ではなく

1. 見積もりが甘かったり
2. 仕様変更をあっさり受け入れちゃったり
3. 単純に納期が近かったり

みたいにプロジェクトやその環境に原因がある場合は、別のプロジェクトでは全くそんなことがなかったりします。

ひよこSE自身、このパターン

ひよこSEは、入社してすぐのプロジェクトで夜の11時まで作業していました。

しかし、異動後は定時帰り。配属されてすぐは、「本当にいいのかなぁ」と思ってました。

いいんです。それで。

そもそも、正しく工数が見積もられて、その通りにやれば、残業はなかなか発生しないので（理屈の上では）。

その３：認識の共有は必ず図を使ってすること（リスク管理で解決）

SEが激務なのが、「時間で解決する」と口で言われても、今が激務ならつらいですよね。

仕事のやり方を変えて激務を多少ではありますが、リスク管理で多少はマシになるかと。

そのうちのひとつが、SE同士の認識の共有です。

口だけの説明は危ない

例えば、お客様の要望をもとに、「どんなシステムにしようか」を決める機能設計をイメージしてください。

空中戦（口だけ）で、

とお客様や、プロジェクトのメンバーに伝えたいことを「口だけで」説明しようとしても、まず伝わらないでしょう。

後戻りを少なく。認識の共有は必ず図を使ってすること

そこで、下記のように、図にして説明するようにします。（内容は適当です。）

普通に話すよりも少し時間がかかりますが、作りたいものが図になってるので、確実性が高いですよね。

このようなフロー図があれば、

1. いつでも見ることができますし
2. 全員が同じ認識で作業できるので

余計な手戻りは少なくなります。

その４：タスクの責任者は必ず明確にすること（リスク管理で解決）

タスクの責任者は、必ず明確にしましょう。

「誰がボールを握っているか（やるのか）わからない」状態が最も怖い

一つのタスクに対して、「誰がボールを握っているか（やるのか）わからない」状態が最も怖いです。

Aくんは、

Bさんは、

みたいなことは、割と起こります。

ボールの行方を常に明確にする

お互いに、「誰かがなにかをやるのを待っていた」状態だとすれば、解決策はいたってシンプル。

必ず、

1. タスクの責任者
2. 今現在、誰が作業しているのか

など、ボールの行方を常にSE全員に見える状態に、明確にしましょう。

その５：タスクは細分化して工数を見積もること（リスク管理で解決）

タスクは細分化します。細分化したうえで、工数の見積もりをすることが重要。

例えば、画面の入力内容を登録する機能を作るとして、

とするようじゃ、実装するSEがかわいそうです。

実際は、

• 画面の作成とJavaScriptに5時間
• SQLの実装に7時間
• ボタン押下時の処理に10時間

のように、「プログラミング」からタスクを必ず細分化しましょう。

こうすることで、実際にSEが実装を始めたときに

1. 進捗の遅れを早期の段階で発見
2. 早い段階でのリカバリ策の決定

が、しやすくなります。

【おまけ】転職によってSEの激務から解放されるかは微妙

システムエンジニアの激務から、転職することによって解放されるかは、正直微妙です。

転職をしたところで、激務かはプロジェクト次第

そもそも開発が激務であるかは、プロジェクト次第。つまり、会社を変えて解決するかが疑問です。

同じ会社でも、部署によって激務度が変わるのと同様、システムエンジニアはプロジェクトによって、忙しさが異なります。

転職するなら、

1. 給料などの待遇がいいこと
2. 会社の業績がいいこと
3. 他でも戦える武器（設計、PM経験など）があること

の３つは必須だと、個人的には考えてますが、今回の激務問題からは外れるので省略します(*´ω｀)。

社内SEへの転職は開発から解放されるだけで、激務かは会社次第

社内SEは、なんとなくホワイトそうなイメージを持っているかもしれません。

そもそもですが、社内SEとは「どこかの企業の情報システム部門に所属すること。」

さらに言えば、社内SEへの転職は「開発から解放される」だけで、激務かは会社次第。

ひよこSEが、社内SEについて知っていることをまとめた下記の記事を読んでみてくださいね。

SEが激務の場合の解決策についてまとめ

SEが激務の場合の解決策についてまとめます。

念押しをしますが、「時間で解決される場合」が多く、個人レベルでできるリスク管理を意識しながら乗り越えるしかありません。

こういう時はただひたすらつらいですが、無理しない程度に、かわしていくのが吉です。