自分の「次の人」が楽しく働けるように

はじめに

アドベントカレンダーのテーマは「Work fun!」を体現する。
このテーマについて考えるうちに、楽しさは個人のマインドセットだけでは成立せず、快適な開発体験という土台の上にこそ芽生えるのだと感じるようになりました。

モチベーションを削る出来事が続けば、「楽しむ」気持ちは自然と弱ります。安心できる環境がない状態では楽しさは長続きしないと感じました。

具体的にどんな瞬間に楽しさが遠のいたのか。主にソースコードに関して、個人的な「気づき」と、それを踏まえた「次の担当者が楽しく働くために必要だと感じたこと」をまとめます。

モチベーションを削られたこと

• ソースコードが“記号化”しており、解読を強いられる

  • 変数名やクラス名が str1, flag, tmp2 といった記号や独自のローマ字略語、さらにはタイポのままなど、名付けから役割が読み取れない
  • その名前が指すものは何かを調べることが必要になる

• 副作用の範囲が不明確で、挙動の予測が困難

  • 1メソッドが数千行に及び、渡したオブジェクトが深い階層の private メソッド内で共有渡しにより書き換えられる、あるいはグローバル変数やシングルトンでシステムの状態が暗黙的に変更される
  • 「Aを直したら無関係なはずのBが壊れる」という現象が起きる

• 過剰な分岐により、処理の意図（ビジネスロジック）が把握できない

  • 1ファイル／1メソッドに if や switch が多用され、ネストが深くなっている
  • ビジネスロジックの意図がコードの複雑さに埋もれている

積み重なった結果として

これらが常態化していると、業務の多くが調査や影響範囲の特定に費やされることもありました。前に進んでいる感覚が持てず、その結果、メンタルを大きく削ることになると感じました。

次の人が「楽しく」働くために必要だと思ったこと

今の環境を劇的に変えることは難しくても、最低限でも効果があると感じた要素は以下の通りです。

• 変数名を、暗号ではなく“意味のある言葉”にする

  • コードを読むだけで仕様の意図が伝わるよう、役割に基づく命名をする。これだけで「解読」が「読書」に変わり、認知負荷が下がります。

• 副作用を抑え、データの流れを明確にする

  • 引数で渡されたオブジェクトを内部で書き換える（破壊的変更）のを避け、可能な限り「計算結果を戻り値として返す」実装に変える。これだけでデータの変化が追いやすくなり、「いつの間にか値が変わっている」という恐怖を減らせます。

• 複雑な分岐には、せめて“なぜこうしたか”のコメントを添える

  • コードに意図や背景を残す。意思決定の前提（制約）も短く記す。仕様の手がかりとなります。

まとめ

「楽しむ」気持ちを持つためには、まずその前提となる安心と快適さが必要だと感じています。

少しずつ整え、次の人が同じ苦しみを味わわずに済むようにすること。
それが今の私にとっての前向きな姿勢につながり、「Work fun!」を体現することになると感じました。