はじめに
株式会社Works Human Intelligence Advent Calendar 2025 の7日目の記事です。
WHIでエンジニアをしている @185shingeki と申します。
弊社WHIには 「Work Fun!（遊び心で仕事を楽しむ）」 というバリューがあります。
アドベントカレンダーのテーマもまさに「Work Fun!を体現する」なのですが、正直なところ、「Work Fun!」についてそこまで真剣に考えたことはなかったです。
でもそれなりには楽しくやっている方だと自覚していますし、半期ごとの他者評価で「楽しみながら仕事をしている」と評していただくこともあります。
じゃあ実際に私がエンジニアとして日々をどうやって楽しみ、どうやって「Work Fun!」を体現しようとしているのかを真剣に考えてみようと思いました。
今回は、私が実践している 「エンジニアとして楽しく働く自分なりの5つのコツ」 を紹介したいと思います。
「仕事＝ゲーム」と捉えてみる
まず大前提のマインドセットとして、私は 「仕事＝ゲーム」 と捉えるようにしています。
一種のゲーミフィケーションってやつかもしれないですね。
参考）
例えば、何かの開発をした後に動作確認を行うときも、ただ漫然とやるのではなく、「どうしたら最も効率的か？」「組み合わせ数や手順を最小化するルートはどこか？」と考えます。これはRTA（リアルタイムアタック）のチャート構築にも似た楽しさがあります。
「飽き」との戦い
ただ、私は飽き性なところがあり、楽しめるはずのゲーム（仕事）にさえも飽きてしまうことがあります。
そんな時、尊敬する先輩の言葉を思い出すようにします。
「どうせやるなら楽しく！ 遊びに真剣になれるヤツは仕事も楽しめる」
ダラダラするより、真剣にやった方がゲームも面白いですよね。
仕事も同じで、真剣に遊ぼうとするからこそ没頭できるのだと思います。(Special Thanks @Hokuto-Niimura )
つまり、ゲームとして楽しむためには、すこし逆説的な感じがしますが、真剣に仕事と向き合わないといけないのです。
また、もうひとつ感銘を受けた言葉に、プロゲーマーであるウメハラさんの講演動画の一節があります。
「ゲームに飽きたんじゃない、成長しないことに飽きたんです」
先輩の言葉と、ウメハラさんの言葉。
この2つは私の中で強くリンクしています。
というのもただ日々のタスクをゲームっぽくこなすだけでは、いずれ飽きが来ます。
そこに「真剣さ」と、それによる「昨日の自分よりできるようになった（成長）」という実感があるからこそ、「Work Fun!」は持続するのだと思います。
これから紹介する残りの4つのコツも、この「エンジニアリングというゲーム」を真剣にプレイし、飽きずに成長し続けるための攻略法のようなものだと思ってもらってもいいです。
日々のプロセスも「エンジニアリング」する
エンジニアの武器はプログラミング言語だけではないはずです。
「ボトルネックを見つけ、仕組みで解決する」という思考プロセス自体が最大の武器です。
私は、日々のコミュニケーションや会議体といった「プロセス」もシステムの一部と見なし、エンジニアリング（改善）の対象にしています。
チームの規模が拡大した際、実際に以下のようなアプローチを行いました。
デイリーMTGの「並列処理化」
チーム人数が増え、全員参加のデイリーMTGが長大化し、コミュニケーションコストが増大していました。
参考）
そこで、ブレイクアウトルームを活用した「チーム内チーム制」を提案して導入しました。
小さな相談や共有を並列で処理できるようにしたことで、MTG時間がタイムボックスに収まるようになりました。
それだけではなく、全員に対して「自分のために時間を使わせてしまっている」という感覚になることがないので、分けた後のほうが相談しやすくなったという話も聞きました。
開発プロセスの「オブザーバビリティ」向上
ふりかえりの質を高めるためにFindy Team+をチームにも導入してみたりもしました。
※といっても社内ですでに先行して導入していたチームがいたおかげで、自分がやったのはチームメンバーにアカウントを発行してもらったのと、振り返りにどのように組み込むのかを考えたということだけです。(Special Thanks @irongineer )
PRのライフサイクルやレビュー状況を可視化（モニタリング）することで、感覚論ではなくデータに基づいて「どこのフェーズでどれだけ時間がかかっているのか」を議論できるようになりました。
コンテキストスイッチという「オーバーヘッド」の削減
弊チームでは、日々朝と夕方にオンライン上で集まる時間があります。（DailyMTGもこれに含まれます）
これ自体は相談のしやすさにつながっていて良いのだと思っています。
ただうっすら皆、「まとまった作業時間があった方が開発は進むよね」という感覚は共有されていました。
そこでリモートワーク下でのコラボレーションと、まとまった作業時間の確保を両立させるため、「MTGなしの曜日」を提案しました。
コンテキストスイッチによるオーバーヘッドを減らし、生産性を高める工夫です。
「MTGが長い・意味がない」と嘆くのではなく、「どうリファクタリングしよう？」と捉え直すことで、組織課題の解決もパズルを解くような楽しみに変わります。
自分なりの「仮説」を持って挑む
そもそも、エンジニアにとって一番楽しい瞬間っていつでしょうか？
あくまで私の場合はですが、「こうしたらうまくいくんじゃね？」と考えたことを実際に試して、予想通りに動いた瞬間 です。
逆に言えば、自分なりの「仮説」を持たずに作業をするということは、この「正解した時の快感」を放棄しているのと同じです。
ただ言われた通りに手を動かすだけでは、そこに「Fun」は生まれません。
自分なりの仮説（攻略ルート）を立てて、それがバチッとハマった時の快感こそが、楽しく働くための原動力になります。
例：AWS CDKのデプロイ短縮
最近、AWS CDKの NodejsFunction を使ってLambdaをデプロイしていた時、デプロイに異様に時間がかかっていました。
ここで「まあそんなもんか」と流さず、ログを眺めたりすることで「ESBuild周りのバンドリング設定がボトルネックになっているのでは？」と仮説を立てました。
実際に設定を見直してみたところ、デプロイ時間が劇的に短縮しました。
この瞬間、最高に楽しかったです。
「仮説検証サイクル」を高速で回す
ただ、仮説を持つことは大事ですが、システムが巨大で複雑になればなるほど、仮説の検証は難しくなります。
プログラムは基本的に「入力・処理・出力」の組み合わせですが、規模が大きくなると変数が絡み合い、ボトルネックが見えなくなるからです。
だからこそ、私は 「Divide and Conquer（分割統治）」 や 「Start Small, Scale Fast」 を忘れないようにしています。
いきなり全体を作り込もうとするのではなく、まずは最小単位まで問題を切り分け、「こうすれば動くはず」という仮説を小さく検証します。
そうすることで、もし仮説が外れていても、傷が浅いうちに即座に「間違いだ」と気づくことができます。
この「間違いに気づくまでのリードタイム」をどれだけ短くできるかが、開発のスピード、ひいては楽しさを左右する重要な要素です。
開発者がユニットテストを整備するのも、単なる品質保証のためだけではなく、この「気づき」を高速化し、安心して攻める（機能開発・不具合修正・リファクタリングする）ための土台作りと言えるのではないでしょうか。
仮説検証のサイクルを小さく、高速に回すことで、この成功体験の頻度を高めることができます。
「ブラックボックス」を開けてみる
クラウドサービスやライブラリは、複雑な技術を「抽象化」し、私たちユーザーから難しい部分を隠蔽してくれています。
このおかげで開発スピードを上げられているのですが、同時にその中身は「ブラックボックス」になってしまうこともあります（というよりもそういう風に甘えてしまっているのかもしれません）。
ただブラックボックスとして受け入れたまま、サービスを「雰囲気」で使うのではなく、あえて中身を学び直すことが楽しさに繋がるケースも多いです。
というのも、エンジニアが日々扱うサービスやライブラリそのものが教材に値するからです。
例：Route 53 と DNS
先日、Amazon Route 53を使って新しい環境を構築する機会がありました。
これまでは既存環境の運用がメインで、Route 53も雰囲気で触っていたのですが、今回は「急がば回れ」の精神で、一度立ち止まってDNSの入門書を読んでみました。
すると、「AWS独自のお作法」に見えていたものが、「標準的なDNSの仕組みをAWSがどう実装しているか」という視点に変わりました。
結果として、構築作業の手戻りが減っただけでなく、今まで存在しなかった手順書を作成してチームに残すこともできました。
また、もしかすると「AWSのRoute 53の使い方」しか知らないと、AWS以外の環境になった場合、「やり方がわからない」と拒否反応が出てしまっていたかもしれません。
しかし、「DNSの仕組み」という裏側を理解していれば、たとえ他のクラウドサービスを触るようになったとしてもキャッチアップにそこまで時間がかからずに使えるようになるはずです（たぶん・・・）。
使い回しがきく普遍的な知識を得ることは、エンジニアとしての自信と楽しさに直結すると信じています。
おわりに
ここまで、私がエンジニアとして楽しく働くために意識している5つのコツを紹介しました。
このように改めて書いてみると、「与えられた仕事をただこなすのではなく、自分から主体的に攻略しにいっている」 というのが根底に共通していたりするのかもなとも思いました。
ゲームが楽しいのは、自分でコントローラーを握って操作しているからです。
（他人のゲーム配信をみるのも楽しいけど、それはゲームよりもむしろ配信を楽しんでいる感じですね）
仕事も同じで、やらされ仕事ではなく、自分からプロセスを見直し、仮説を立て、仕組みを理解しにいくことで、景色はガラリと変わります。
この記事が、少しでも皆さんの「働くを楽しく」するヒントになれば幸いです。
※あくまで「自分なりのコツ」なので、NotForMeと感じられた方々はごめんなさい。
もしよかったらあなたなりの楽しみ方をコメントで教えてもらえると嬉しいです。
Work Fun!