システムエンジニアが長時間働くことは「真面目」なのだろうか

あなたが思う「真面目」が自分が担当する仕事に対して期待されているアウトプットをすることだ、と考えているなら、まず、仕事に対する姿勢がワタシと同じか近いので会話をしてもずれたりしないと思うのでこのまま話を続けられそうです。
もし、あなたが「真面目」に対して長時間働くことや無茶をすることがその振る舞いだと考えているなら、残念ながらワタシとは違う「真面目」という意味の言葉を使っているので、言葉の意味を合わせるところから始める必要があるのでちょっと大変そうです。

まじ‐め【真‐面‐目】
［名・形動］《「まじ」は「まじまじ」の「まじ」と同じか》
１うそやいいかげんなところがなく、真剣であること。本気であること。また、そのさま。「―な顔」「―に話をする」
２真心のあること。誠実であること。また、そのさま。「―な人柄」「―に暮らす」
引用　

まじめ【真面目】の意味 - goo国語辞書

真面目の意味は引用のように２つあって、１つ目の意味がワタシのいう「真面目」に近いのです。一方、長時間働くことや無茶をすることが「真面目」として言葉を使っているならそれは引用の２つ目の意味を取り違えて使っているのではないのかな、と思ってしまうのです。

長時間働くことや無茶をすることを「真面目」と思ってしまうのか

辞書の２つ目の意味に「また、そのさま。」とありますよね。これが曲者なのです。
例えば、AさんとBさんの二人のシステムエンジニアがチームにいました。Aさんは自分の担当する仕事を長時間働いてアウトプットしています。Bさんは、Aさんと同程度の仕事を１日もかからずに終えて、定時になったらさっと帰ってしまいました。
さて、AさんBさんのどちらが「真面目」に仕事をしているのでしょうか。それともどちらも一緒に「真面目」なのでしょうか。

引用した辞書の１つ目の意味で「真面目」を使っているのなら、いいかげんでない、集中して、本気で仕事をしていることが前提になります。
この前提を元にAさんとBさんの仕事ぶりを評価し直したらどうなりますか。

いいかげんでなく短時間で終わらせる方が「真面目」という考え方
ワタシが使っている意味の「真面目」で評価をすれば、「真面目」に仕事をしているのはBさんです。集中して、いいかげんでもないアウトプットをより少ない工数でアウトプットしてるからです。片やAさんは、Bさんと同じ程度の仕事をしているのに長時間働いてアウトプットしています。長時間働くことが計画工数を超過しているとしたら、もしかしたら、「真面目」の意味の「本気」で仕事をしているか疑わしくなってしまいますし、もしかしたら、担当している仕事がAさんが持っている技術とミスマッチしてアサインしてしまっているのかを疑ってしまっても仕方がない状況です。
さて、Aさんは「真面目」に仕事をしているのでしょうか。Bさんを「真面目」に評価できない人は何をみて「真面目」と判断しているのでしょうか。

「真面目」は長時間椅子に座っていることではない
以前にも書きましたが、これまで一緒に働いたシステムエンジニアのみなさんは、自分の仕事が終わると直ぐに次の仕事を入れようとします。プロジェクトの進捗が立て込んんでいたり、誰かが助けを求めていて人手が足らないのであればそうしたことは優先してやっていただく方が良いです。
でも、スケジュールどおりに進んでいるとしたらどうでしょうか。ワタシはある事例を聞いてから計画以上に進める必要がないのであれば無理に前詰めしないことにしました。

「工事現場で嫌われる監督っているんだよ。その日の作業が早く終わると翌日の仕事を入れてしまうんだよ。それで嬉しいのは誰かって。現場の職人は誰についていけばいいかよく見ているよ。せっかく早く終わったんだったらその日はさっさと帰らせるべきだ。そうしないと、どんなに急ぎの仕事であっても間に合わせてくれないようになってしまうんだ。わかるだろう、早く終わったら次の日の仕事を入れられてしまうからさ」

これを聞いてから、計画している以上に無理に前詰めすることはやめました。もちろん、建て混んでいる場合は別です。でもそうでないときはそんなことをしないようにしました。

これ、ジレンマというか自分との戦いみたいなものですけどね。少しでも早く終わった方がいいって心理が自然と働いてしまいますから。
そうした前倒しで進むことはそれほど頻繁にはないのですが、でもそうしたことがあったときには全く違うことをやってもらうようにしました。それは、将来、彼らチームのメンバが使う情報の収集や開発環境の整理やプロジェクト情報のリポジトリの整頓やツールの改良などなど。そう、彼らの将来のために時間を使うことです。

戸惑いますよ。普段は詰め込まれるだけ詰め込まれるプロジェクトしか経験していないのですから。でも、それをすることで実はプロジェクトの将来の不確実性を提言しているのですよね。その場で「手順書にないエラーが出た」と慌てるより、環境差異での振る舞いの違いを検証しておくなどは、手順の見直しやチェックポイントの設定にもつながるので作業品質が上がるのです。こうした考え方は、回り回ってプロジェクトに還元されるのです。