「改善を止める上司」を無能だと思っていた話

クーロンです。

「問題があるなら直せばいい」

たぶん多くの人がそう考えると思いますし、昔の僕もそうでした。
むしろ、問題が見えているのに放置する方が無責任じゃないかとすら思っていました。

でも仕事を続けていると、世の中には「直さない方が良い問題」があることに気付かされます。

以前、僕が関わっていたゲーム開発の現場での話です。

そのプロジェクトは毎年のようにシリーズ作品を出していて、主要メンバーは10名程で固定されているものの、それ以外は派遣やフリーランスのスタッフが多い体制でした。

ある日、新しく参加したプログラマーが前任者が作ったコードを見て顔をしかめました。

そして少し見た後で、「これ、継承するより作り直した方が早いし、将来的にも安全ですね」と言ったんです。

そのプログラマーは、前任者のコードが如何にスパゲッティで解読が難しいが資料を作ってくれたので、素人目にもコードに問題がある事は理解できました。
読みにくい部分もありましたし、構造的にも整理されているとは言い難い状態でした。

プログラマーの立場から見れば、新しく組み直した方が今後の開発は楽になるでしょうし、保守性も向上するはずです。

話を聞いた僕も、「確かにその方が良さそうだな」と思いました。

ところがディレクターの判断はNOでした。
当時の僕は正直なところ納得できませんでした。

せっかく問題が見つかっていて、しかも改善案まで出ているのだから、直した方が良いに決まっていると思っていたからです。

でも今振り返ると、あの時に見えていた景色が違ったんですよね。

プログラマーはコードを見ていますが、ディレクターはコードだけではなく発売日や予算、チーム全体の進行状況まで見ています。

もし作り直した結果として予期しない不具合が出たらどうするのか。

その不具合が発売日までに解決できなかったらどうするのか。

修正のために他の作業が止まったらどうするのか。

そう考えると、「コードが汚いから直す」という判断だけでは足りないことが分かります。

もちろん、改善できるならした方が良いんです！
そんなことは誰だって分かっています！

問題は、その改善によって新しい問題が発生する可能性があることなんですよね。

実は似たような経験がもう一つあります。

数年続いている運営タイトルで、グラフィックデータの持ち方が少し古く・非効率だったことがありました。

新しく参加されたデザイナーはチーフに効率の良い管理方法をしたいと資料を作り、提案しました。

ところが、その提案も採用されませんでした。

今の仕組みは非効率だけれど、安定して動いている。
一方で新しい仕組みは効率的かもしれないけれど、本番環境で何が起きるかは分からない。

そうなると管理する側は、「少し不便でも安全な道」を選ばざるを得ないんです。

昔の僕は、こういう判断を見るたびに、「なんで改善しないんだろう」と思っていました。

でも経験を重ねるにつれて、少しずつ考え方が変わりました。
改善という言葉には、どこか正義の響きがあります。
改善に反対する人は悪者で、改善する人は正義な人に見えます。

でも現実のプロジェクトではそんな単純な話ではありません。

改善は未来への投資だからです。

投資にはリターンがありますが、同時にリスクもあります。

そしてマネージャーという立場になると、そのリスクに責任を持たなければなりません。

だから時には、「今は変えない」という判断が必要になります。

僕が経験則で思うのは、現場で働く人ほど改善したくなり、管理する人ほど慎重になることです！

どちらが正しいという話ではなく、見ているものが違うんですよね。

コードを見ている人と、プロジェクト全体を見ている人では、どうしても判断基準が変わります。

「改善は正しい。だけど、正しい改善が今やるべき改善とは限らない。」

これは僕が仕事をする中で何度も感じてきたことです。

本当なら改善したうえで十分な検証期間を確保するのが理想ですが、現実はそんなに余裕がありません。

だから改善を提案するなら、「良くなります」だけでは足りなくて、「どうやって安全に移行するのか」までセットで考える必要があります。

最近はシステムも開発体制も昔よりずっと複雑になりました。

開発する工数だけではなく、改善する工数や検証する工数まで含めて考えないと、プロジェクト全体が成立しなくなっています。

そう考えると、技術的負債そのものよりも、「なぜ組織は負債を抱え続けるのか」の方が興味深いテーマなのかもしれません。

実はこの話、ゲーム開発だけの問題ではありません。

会社組織そのものが抱える構造的な話でもあるので、その辺りはまた別の記事で書いてみようと思います。

それでは、また！