SESEのキャリア

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

どうも!ひよこSE(@PiyoOct)です。

SEって激務。どうにかしたい!

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

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

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

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

の2つが主なポイント。

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

スポンサーリンク

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

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

  1. SEの開発納期が過ぎて激務から解放(時間で解決)
  2. 別プロジェクトに異動して激務から解放(時間で解決)
  3. 認識の共有は必ず図を使ってすること(リスク管理で解決)
  4. タスクの責任者は必ず明確にすること(リスク管理で解決)
  5. タスクは細分化して工数を見積もること(リスク管理で解決)

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

先が見えないよ・・・

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

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

今は、わりと楽なプロジェクトにいます!

その1:SEの開発納期が過ぎて激務から解放(時間で解決)

SEの激務から解放

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

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

・・・ということは。

案外、単純な話。

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

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

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

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

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

することねぇ、、、

となります。

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

一瞬でも暇になると、それはそれで罪悪感も生まれたり・・・。そこは、しっかり休みましょう!

スポンサーリンク

その2:別プロジェクトに異動して激務から解放(時間で解決)

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

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

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

開発SE
開発SE

前いたプロジェクトはなんだったんだ、、、

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

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

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

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

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

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

いいんです。それで。

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

ふ~ん。ホワイトなプロジェクトもあるんだ。

今では、20時を過ぎると、「遅いなぁ」と感じますね!

その3:認識の共有は必ず図を使ってすること(リスク管理で解決)

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

たま~に、明るいうちに帰れるのがうれしかったり(苦笑)。とにかく、踏ん張りどころ!

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

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

口だけの説明は危ない

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

空中戦(口だけ)で、

開発SE
開発SE

△〇×※△・・・

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

人によって解釈は様々!空中戦だけは、NGです!

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

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

SEは図で説明

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

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

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

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

その4:タスクの責任者は必ず明確にすること(リスク管理で解決)

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

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

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

Aくんは、

Aくん
Aくん

BさんがOKしてくれるのを待っていたのに

Bさんは、

Bさん
Bさん

Aくんが報告してくれるのを待っていた

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

時間だけが過ぎていくパターン。恐ろしい・・・。

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

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

必ず、

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

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

その5:タスクは細分化して工数を見積もること(リスク管理で解決)

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

もし、任せられたら激務にならないためにも、しっかりと!

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

プログラミングに3日!

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

実際は、

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

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

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

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

が、しやすくなります。

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

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

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

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

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

転職するなら、

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

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

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

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

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

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

ホワイト率は高めだとは思います。きちんと、社内SEの仕事を理解しているところに行くべし!

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

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

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

  1. SEの開発納期が過ぎて激務から解放(時間で解決)
  2. 別プロジェクトに異動して激務から解放(時間で解決)
  3. 認識の共有は必ず図を使ってすること(リスク管理で解決)
  4. タスクの責任者は必ず明確にすること(リスク管理で解決)
  5. タスクは細分化して工数を見積もること(リスク管理で解決)

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

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

コメント

タイトルとURLをコピーしました