目次
今回は、アピリッツの知識共有サイト「ナレッジベース」で公開されている内容をアピスピでも紹介します。
エンジニアとして活躍されている桑添敏生さんの記事です。
是非最後まで読んでください！（初版：2023年2月2日）
経緯・問題点
これはES部だからとか運用・開発だからというのは全く関係なく、
業務をする中で「何このめちゃくちゃなソースコード」という感想を持った方は少なくないと思います。
どうしてソースコードがある程度可読性があって保守しやすい必要があるのか、
なぜ、ソースコードがめちゃくちゃだとネガティブな考えが増えていくのか、
正直経験の浅さやボキャブラリーの少なさから、今までうまく言語化できていませんでした。
もやもやしていることはわかるのに、原因が掴めないことで
さらに焦ったりイライラしたりしてしまうので、しっかり考えてみた過程です。
試したこと
一度内容を整理するために、ゲーム業界で働く友人達に愚痴混じりで、
「ソースがめちゃくちゃで対応コストが高い」的な内容を相談してみました。
友人達もみんな業務内で似たような経験があり、
「その場しのぎ」や「悪循環」、「開発が進むとモチベーションが下がる」といった、
切り取るとネガティブな言葉ながら楽しんでいる雰囲気もある不思議な反応だったので、
こんなに似たようなワードが出てくるなら、誰かが上手く言語化してまとめているのでは？と思い調べてみました。
問題の解決
いろいろ調べてみた結果、思っていたことを一番言語化できていたスライドをSpeaker Deckにて見つけました。
・技術的負債は開発者体験を悪化させる ＠mtx2s
引用元：https://speakerdeck.com/mtx2s/technical-debt-and-developer-experience
内容をいくつか引用すると、
Q. ユーザー体験と開発者体験はよく似た特徴を持っている。
そして優れた体験が得られなければどうなるのか？
どちらも最後は離反に至ってしまう、、、
Q. なぜ開発が進むとモチベーション(開発する気)が下がってしまうのか？
・スライド内にはこの様に書かれています。
「レガシーコード」という言葉を聞いて皆さんは何を思い浮かべるでしょうか。
スパゲッティコードが原因で簡単なはずの機能追加で徹夜作業したことや、
士気を喪失してしまったこと、チーム全員がコードにうんざりしてどうでもよくなってしまった感覚
そのコードを改善しようと考える事すら嫌な気持ちになるかもしれません。
そんな手間をかけるのは無駄に思えるからです。
しかし、
どんなにモチベーションが下がっても結局は真正面から向き合うしかない…
でも、問題点や性質をしっかりと押さえておけば工数の振り方次第で上手く付き合えるかも…？
その点を考慮してスライドを読み進めていくと、
Q. その負荷がかかるコードの特徴はどのような場合なのか？
スライドには以下の特徴が例として記載されていました。
つまり技術的負債が増え続ける開発現場では、
リファクタリング(開発者の負担軽減)を行わずに 振る舞いの価値（新規機能の開発） を
優先させてしまっている。
おもむろに「立ち向かうしかない」とか「頑張れ」と言われるよりも具体的な問題が見えてきました。
しかし、開発の現場においては売上が出ないリファクタリングよりも、
新たに売上を生み出す新規開発が優先されるのは納得できます。
Q. なぜ売上(機能開発)優先だけを行うとマズいのか？
・スライドを引用すると、
答えとしては、
無理が積み重なって開発が止まってしまい、一時的な売上しか立たなくなってしまう からです。
そのため、最終的には全員がいい事なく終わってしまう事になります。
Q. さらにこのまま開発が進んだ場合に何が起きるの？
次に発生するのが開発者への負担となり、自分達が「悪循環」と呼んでいたものがこれに当たります。
最初に、
「無謀な開発」 が「技術的負債」を増加させて、
「技術的負債」が「開発速度」を低下させて、
「開発速度」が「無謀な開発」を頻発させるループが起きます。
さらに上のループがしばらく続くと、
「無謀な開発」が「欠陥・障害」を増加させて、
「欠陥・障害」が「開発速度」を低下させて、
「開発速度」が「無謀な開発」を頻発させるループも起きます。
その結果、全員ボロボロに…
こういった流れが原因で、
最初の画像の通り現場のモチベーションが下がり続けるのだと把握することができました。
結論
ずっと自分が抱えていた要因は「リファクタリング」を軽視した、
基盤が不安定なまま行い続ける開発作業だという事が今回の件でわかりました。
ただ、エンジニア以外の職掌にリファクタリングの重要性や定期的に行う必要があることを伝えて、 土台を構築するのはものすごく大変でコストが高いです。
しかし、人数は違えど全てのプロジェクトでこの部分を負担している人が必ずいるので、
まずは毎朝業務開始時に1関数を改修するなど、自分ができる範囲から
心理的、技術的な負担を軽減する手伝いをしてみようと思いました。
最後に
今回の話のオチとしては、 結局何を言っても自分自身が問題に向き合う必要がある事です。
スライドの最後の言葉として、
アーキテクチャを後回しにすると、システムの開発コストはますます高くなり、
システムの一部または全部が変更不能になるだろう。そのような状態が許されているなら、
ソフトウェア開発チームが自ら必要とするもののために懸命に闘わなかったという事だ。
案件や状況に文句を言いたくなる時もあるけど、一旦戦ってみようと思います。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
桑添さんありがとうございました！
アピリッツでは自分が得た情報や技術を積極的に共有し、それらを吸収しながら各々のスキルアップを目指しています。
アピリッツに少しでも興味を持った方、エントリーお待ちしております！
エントリーはこちらをチェック→〈https://recruit.appirits.com/〉
