【身体編】エンジニアの職業病
眼精疲労がひどい
まずは身体の不調という観点から3つご紹介しましょう。
1日中モニターを見続けるエンジニアにとって、眼精疲労は最も身近な職業病の一つです。現代ではスマホを使うのが当たり前になっていることもあり、仕事以外でも画面を見る時間が自然と増え、目が休まらないなんてこともあるでしょう。
加えて、コードを書いているとき、エラーの原因を探しているとき、ドキュメントを読み込んでいるときなど、気づけば何時間も目を休めておらず、視力が低下するということも珍しくありません。
目の疲れが積み重なると、頭痛や肩こりを引き起こすこともあります。スクリーンの輝度を調整したり、定期的に遠くを見て目を休める習慣を取り入れたりするだけでも、症状を緩和できます。
眼精疲労対策として有効な方法に、「20-20-20ルール」というものがあります。これはアメリカ眼科学会などでも推奨される対策で、20分ごとに20フィート（約6m）先を20秒見るというルール。目の疲れやドライアイの緩和に役立つとされています。この記事を読むのを一度やめて少し遠くを見るだけでも効果があるので、比較的取り入れやすい対策です。
最近ではブルーライトカットメガネや目薬を常備するエンジニアも増えています。仕事道具のこだわりと同様に、目のケアグッズへのこだわりも、エンジニアあるあるの一つといえます。ただし画面を見る時間がかなり長いため、完全に防ぐのは難しいのが現実です。
意外とマウス操作が多く、腱鞘炎になりやすい
非エンジニアの人は「エンジニアはキーボードしか使わないのでは？」と思いがちですが、実際にはマウス操作が多いです。ブラウザでの調査、GUIツールの操作、図の作成、コードレビュー時のスクロールといった作業の積み重ねが、手首や指に負担をかけ続けています。
手首が自然な位置に来ない状態でマウスを操作し続けると、手首と手の筋肉に負担をかけることになります。この結果、いわゆる「マウス腱鞘炎」と呼ばれる手首の腱鞘炎を引き起こすことがあります。特に負担がかかると手首や親指の付け根にしびれが生じ、症状が進むと手全体や腕全体にまでしびれが広がります。
腱鞘炎は一度発症すると完治に時間がかかるため、予防が重要。腱鞘炎予防と使い心地の追求で、職場に自前のマウスを持ち込んでいるエンジニアも多いのではないでしょうか？
現役エンジニアに人気のマウスと言えば、エルゴノミクス（縦型）マウスやトラックボールマウス。手首をひねらずそのまま使えるだけでなく、ブラウザの進む・戻る操作が手元でできる5ボタンタイプのマウスを使っている人も多いです。どちらを使うかは好みもあるので、エルゴノミクスマウス派が多い職場・トラックボール派が多い職場で分かれるかもしれません。
座り作業が多すぎて、肩と腰がガチガチ
エンジニアの仕事は、ほぼ座り作業です。特に納期が近かったり、難しいバグと格闘していたりすると、気づけば何時間も同じ姿勢で過ごしていることがあります。その結果として、肩と腰のコリがほぼ慢性化してしまうのです。
腰痛・肩こりともに、長時間座ることによる筋肉の硬直と運動不足が主な原因です。また、猫背・巻き肩など姿勢が悪い場合も痛みが慢性化しやすくなります。この痛みから集中力が低下し、生産性も落ちる可能性があります。
対策として、高機能チェアや昇降デスクを導入して環境を整えるエンジニアも増えています。しかし元をたどれば運動不足が原因なので、定期的に立ち上がってストレッチするなど運動習慣をつけることも重要です。
姿勢を見直して症状を緩和するか、ストレッチを積極的に取り入れるか、はたまた姿勢矯正ができるクッションや椅子を導入するか……。自身の働く環境からどの対策がいいか、一度考えてみましょう。
関連記事
【仕事中編】エンジニアあるある
フローチャートがとにかく長くなりがち
続いて、業務中によく起こりがちなことを取り上げていきましょう。
ある程度自分で設計を行うようになると、フローチャートを準備する場面も多くなります。処理の流れを可視化しようと思って描き始めたフローチャートが、気づけばA4用紙に収まらないほど巨大になっていた経験はありませんか？
エンジニアは条件分岐や例外処理を細かく考える癖があるため、図が複雑になりやすいのです。「この場合はどうする？」「あの例外は？」と考えるうちに、図はどんどん枝分かれします。整理しようとすると余計に複雑になる悪循環に陥ると、どうしようもなくなります。
手書きで収拾がつかなくなり、Excelやスプレッドシートに移行しても「数百行」「数十列」に及ぶほど分岐が増え、膨大な量のまま完成することもよくあるでしょう。
このあるあるは、エンジニアあるあるの中でも共感を集めやすいエピソードのひとつです。
コード内に意味不明なコメントが入りがち
コードを読み返したとき、「// これ重要（理由不明）」のような謎コメントに遭遇したことはありませんか？書いた本人でさえ意味を思い出せないコメントが至る所に残されているのはエンジニアあるあるといえます。
コメントは本来、コードの意図や注釈を未来の自分や他のエンジニアに伝えるためのものです。しかし締め切りや疲労のせいで、とりあえず残した走り書きが積み重なっていきます。
よくよく見ると、日本語ではなくローマ字でコメントが残されているなんてこともよくあります。新人の頃に担当したコードが巡り巡って自分が触ることになり、当時のコメントを見て赤面することも少なくありません。
「後で整理しよう」が永遠に実行されないのも、よくある職業病のひとつです。
単純なミスを見つけるのに1日かかりがち
何時間もデバッグに費やしてようやく見つけたバグの原因が、スペルミスや全角スペースだったときというのは、エンジニアなら誰でも一度は経験するあるあるです。探している間はストレスを抱え、見つけたときは「こんな単純なことに気づかなかったのか」と自己嫌悪に陥るエンジニアも多いでしょう。
集中しているとき、人は意外と単純なミスを見落としがちです。特に疲れているときほど、見えているのに気づかない現象が起きやすくなります。ペアプログラミングや第三者のレビューが効果的なのは、こうした認知的な盲点を補えるからです。
先輩エンジニアが天才に見えがち
入社してしばらくの間、先輩エンジニアの動きが神がかって見えることがあります。コードをさっと読んで問題の箇所を指摘し、ものの数分で修正してしまう姿に、「自分には無理では」と思ったことがあるエンジニアも多いはずです。
実際には、先輩も同じようなミスを繰り返し、膨大な経験から「勘」と「経験」を地道に磨いてきた結果なのです。キャリアステージが上がるにつれて、自分もかつての先輩のように見られる側になります。「天才に見えた先輩と同じミスをしている自分」に気づくのも、エンジニアのあるあるです。
コードを書く前のリサーチで時間が溶けがち
「まず調べてから実装しよう」と思ってドキュメントを読み始めたら、気づけば2時間が経過……。そんな経験はありませんか？
エンジニアは情報を収集・整理する習性があるため、実装前のリサーチに過剰な時間をかけてしまいがちです。ある程度使い慣れている言語でも、新しいコマンドを使おうと調べていたら数時間経っていた、ということもあるのではないでしょうか？
「完璧に理解してから着手したい」という完璧主義的な傾向も、時間を溶かす要因のひとつです。プログラマーのあるあるネタとしても定番で、「実装より調査に時間がかかった」という経験は多くのエンジニアに共通します。
【日常編】エンジニアあるある
街中でブルースクリーンが出ているとエラー内容が気になる
駅の案内板や商業施設のデジタルサイネージがブルースクリーンを表示しているのを見つけると、思わず近づいてエラーコードを確認してしまう……。エンジニアなら思い当たる場面ではないでしょうか。「STOP: 00007E」などのコードを見かけると、反射的に原因を推測してしまうのです。
看板の誤字やWebサイトのUIの違和感にも気づいてしまうのと同様で、エンジニアの「エラーを探す目」はオフにしづらいものです。せっかくの休日なのに仕事モードになってしまった、と苦笑いするのもエンジニアあるあるといえます。
パソコントラブルで頼られがち
「エンジニアだから詳しいでしょ」と、家族や友人からパソコンの修理やスマートフォンの設定を頼まれる経験は、多くのエンジニアに共通します。ソフトウェア開発の知識と、家電製品の使い方サポートはまったく別のスキルなのですが、そうした区別は伝わりにくいのが現実です。
「プリンターが動かない」「無線LANにつながらない」といった相談に毎回乗るうちに、ITサポート担当のような立場になっているエンジニアも少なくありません。
ネットワーク系でない限り、専門外の分野についてはそこまで詳しくないと感じるエンジニアも多いでしょう。しかし、非エンジニアからすれば、ネットワーク系だろうが、オープン・Web系だろうが、エンジニアはパソコンに詳しいだろうという認識を持っています。
頼られること自体は悪くないのですが、「それは専門外です」と言いにくい空気があるのも、あるあるといえます。
システム障害のニュースを聞くと心も胃も痛い
近年、大手金融機関での大規模システム障害や、有名企業を狙ったランサムウェア感染による被害がたびたびニュースになります。
大規模なシステム障害のニュースを見ると、「原因はなんだろう」と考えながら同時に「担当チームは大変だな」と胃が痛くなる……。エンジニアあるあるの中でも、特に経験年数を重ねた人ほど共感するエピソードです。障害のニュースが出ると職場で話題に出やすいのも、エンジニアならではです。
自分自身が過去にインシデント対応した経験があると、ニュースを他人事として見られなくなります。「あのとき自分たちが徹夜でリカバリーしたときと似ている」「あの規模の障害なら復旧に何時間かかるだろう」と、つい職業的な視点で分析してしまうのです。
同時に、「うちでこうなったらどうなるんだ……」という恐怖を覚えるまでがワンセット。この危機感が仕事に役立つので、適度に恐怖心は抱いておきましょう。
【勘違いポイント編】エンジニアあるある
意外とコミュニケーションをとる場面が多い
最後に非エンジニアの人に勘違いされやすい内容を2つ取り上げましょう。
非エンジニアの人の中には「エンジニアは黙々と一人でコードを書いている」というイメージを持つ人が少なくありません。ところが実際には、要件のヒアリング、設計の議論、コードレビューでのフィードバック、進捗確認のミーティングなど、思った以上に多くのコミュニケーションが発生します。
特にチームで開発を進める現場では、仕様の認識を合わせるための会話が不可欠です。「なんとなくコードを書いていればいい仕事」ではなく、言語化・共有・調整の能力が問われる場面が多いのがエンジニアという職種の実態です。開発工程の上流にいるようなベテラン勢は、技術に詳しくない営業や顧客に技術的なことを分かりやすく伝える場面も出てきます。
転職の際に「コミュニケーション力」が求められるのも、こうした理由からです。
AIは便利だけど、そこまで信頼できない
「AIがあればエンジニアはいらなくなる」という言説をよく耳にします。しかし、現場のエンジニアの感覚は少し異なります。AIツールはコードの補完や定型処理には非常に便利な一方で、出力されたコードをそのまま信頼するのは危険です。
AIはもっともらしい誤りを生成することがあります。特に複雑なビジネスロジックやシステム固有の要件が絡む場合、AIが提案するコードが実際の要件を満たしているかどうかを、人間が判断・検証する必要があります。情報収集をするうえでも、AIは活用するものの信用しすぎない運用が大切。AIに依存しすぎない姿勢がエンジニアには求められます。
「AIに任せれば終わり」ではなく「AIを使いこなすのもエンジニアの仕事」という感覚は、現場の多くのエンジニアが実感していることです。
関連記事
まとめ
身体的な不調から思考のくせ、日常の行動パターンまで、エンジニアの職業病はさまざまです。「これって自分だけ？」と思っていたことが、実は多くのエンジニアに共通するあるあるだったと分かると、少し気持ちが楽になることもあるでしょう。
職業病は確かに大変な面もありますが、それはエンジニアとして真剣に仕事に向き合ってきた証でもあります。身体のケアは後回しにせず取り組みながら、思考のくせは笑い飛ばす余裕を持てると、働き方がもう少し楽になるかもしれません。
