この記事は、Bill One開発Unit ブログリレー2025の第20弾になります。
はじめに
Bill One Engineering Unitで経理AXサービス「Bill One」を開発している河端です。
認知負荷の高いコードを、皆さんも見たことがあると思います。
- 大量の分岐が1ファイル内でネストしており、どういった処理をしているのかが分からない。
- 似たような変数名や複雑な変数名が羅列されている。
- mainブランチで記載されたままのTODOコメントが放置されている。
- （ドメイン駆動開発を採用している場合）ドメインにロジックが集約されておらず、ApplicationServiceにロジックが大量に漏れ出ているetc...
認知負荷の高いコードを読む側の体験談は数あれど、書いた側の経験談はあまり存在していないようです。
世の中から認知負荷の高いコードがなくなることを祈って、以前私がそのようなコードを書いた際の経験を本記事で書こうと思います。
どんなコードだったのか
先に言い訳させてください。
当時、特定の時期に1日あたりチーム全体で100時間程度の負荷となっている運用作業がありました。その運用負荷を低減させるためになるはやで対応する必要があり、チームタスクと並行して運用を自動化したコードを実装していました。（本記事における認知負荷の高いコードです🥺）
私が書いたコードはこんな感じでした。
- 境界の異なる責務が、全部ApplicationServiceに寄せ集められていた
- 業務ルールと制御フローがごちゃっと混ざっていた
- 「なんでここでこの判断をしているのか」がコードから分からなかった
- 安全に直すには、コード外の前提知識が必須だった
- ネストが非常に深くなっていた
認知負荷が非常に高いコードですね...。
リリース後のフロー
さて、認知負荷の高いコードを書いた後の流れを見ていきます。
記載したコード自体にバグはなく、最終的に1日あたり最大80時間程度の運用負荷を削減できました。
1. 感謝される
運用負荷を大きく下げているので、めっっっちゃ感謝されました。
Sansanでは「Unipos」というサービスを利用しており、感謝をメンバーに伝える仕組みがあります。
その仕組み上で感謝のコメントが大量に集まりました。
（画像上の一部内容を削除しています）
上記は一例ですが、他にも大量に感謝の声がありました。
いや〜やっぱり感謝をされるのは嬉しいですねぇ
2. リファクタリングのお伺いが立つ
しばらくすると、当時その領域の修正を主導していたチームメンバーのMさんから、リファクタリングの相談が来るようになります。
「この処理、少しリファクタリングお願いしてもいいですか？🙇🙇🙇」
「処理構造を変えたいんですが、お願いしてもいいですか？🙇🙇🙇」
この段階では空気はかなり穏やかで、どっかで対応しますよ〜とヘラヘラしていました。（申し訳ありません）
3. "お伺い" が "催促" に変化する
しばらく2の状態が続いていると、徐々に温度感が上がってきます。
「そろそろお願いしたいです。」
Mさんはメンバーへの依頼時に、いつも🙇という絵文字を付けてくれる物腰が柔らかい人なのですが、依頼文から 🙇 の絵文字が消えることになります。
この時対応していればよかったのですが、プロダクト機能開発業務などとの兼ね合いもあり、対応する時間をなかなか取ることができませんでした。（改めまして、本当に申し訳ありません）
4. 怒りのPR reviewが飛んでくる
ある日。
Mさんから突然PR review依頼が飛んできました。内容を確認すると私が当時書いたコードに修正を加えたPRでした。
これはまさか...と思っていると、次々とPR review依頼が飛んできます。"review時間確保"と記載された謎のミーティングが組まれています。その後はしばらく、泣く泣く大量のPRをreviewすることになりました。（重ね重ね、本当に申し訳ありません）
何が悪かったのか
さて、なぜこうなってしまったのでしょうか。
認知負荷の高いコードを書いたこと自体が一番の問題だったわけではありません。
コード自体は、"運用負荷を下げる"という価値を生み出していましたし、運用観点ではなくてはならないものでした。
問題はその後、認知負荷の高いコードを放置したことです。
そういったコードを書いてしまうような状況はあります。ただし、その場合はセットで、下記をあらかじめ決めておく必要があります。
- いつ直すのか
- 誰が責任を持つのか
これを決めないまま放置すると、コードの属人化が進んだり、ミスコミュニケーションが発生したりします。
まとめ
認知負荷の高いコードを書くこと自体は、必ずしも悪ではないです。でも、認知負荷の高いコードを放置するのは悪です。
今まさにそういったコードを書いている人もいるかもしれません。それ自体は事情もあるので仕方ない部分もあると思います。
でも、放置だけはしないでください。
組織のために、なにより未来の自分のために...。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
