[ポエム] 世の中にクソコードが蔓延しているのは CTO が不在だから¶
前書き¶
この文章は現場の空気感を反映しているとは思いますが、特に裏付けのない思いつきです。
背景¶
受託経験を積む中で数多くのつらコードを見てきました。あまりにも多いので、私はこれはシステム開発における普遍的な問題なのではないかと思いました。そして、何故つらコードが生まれるのかを考えた末一つの考えに至りました。
「CTO がいないからや！」
と。
つらコードの定義¶
つらコードの要件は具体的には「１関数・１クラスのコードが長すぎる」「コメントがない」「コードの流れがわからない（スパゲッティーコード）」などいくつかありますが、突き詰めると「人が読めない」コードと言い表せると思います。
コードというのは基本的に「人に読まれる」ことを前提とするべきです。機能を拡張する場合やバグを修正する場合、コードを読んで何がどこに影響しているかを正しく把握する必要があります。良いコードはこのコードとその影響範囲の因果関係が把握しやすい（つまり読みやすい）ものであり、つらコードはわかりにくいという枠を超えて、何時間読み込もうが意味がわからないコードと言えます。 2
システムの担当者が変わる、あるいは保守を開発とは別の会社に依頼するということは通常に起こり得ることであり、何より書いた人間自身でも自分のコードを忘れるものなので、コードはエンジニアが一般的な知識範囲で理解できる状態が望ましいと言えます。実装者は（何があっても死なずにシステムを守り続ける人外の存在でもなければ）他人あるいは将来の自分が読みやすいコードを書くべきだと思います。
CTO の不在¶
何故CTOの不在がつらコードを生み出すのかというと、つらコードが生まれる要因を考えた時にその責任が全て CTO にあると考えられるからです。
まずつらコードが生まれる要因を列挙し、それぞれ考察したいと思います。
単純にスキルが足りていない
将来の保守性など考えている余裕がない
新しい技術やフレームワークに対する知識不足
つらコードを書いても評価に影響しない
採用をミスっている
1. 単純にスキルが足りていない¶
実装者に「コードが人に読まれる」という発想自体がない、あるいはあってもどう書けば他人が理解しやすいかが分かっていない場合です。
他人が読んで理解できるかどうかは他人に読んで判断してもらうのが一番なので、この場合、コードレビューが有効になるはずです。
しかし、コードレビューをどのような観点で行うのかがレビュワー・レビュイー双方で明確になっておらず、レビューが（ただPM・リードエンジニアの好みに合わせるような）意味のないものになっているパターンもあります。この場合レビューのやり方について客観的に評価し、指導あるいは提案する人物が必要になります。
あるべき品質やチーム体制を提示し、不足があれば教育を行う責任は誰にあるでしょうか？
CTOです
2. 将来の保守性など考えている余裕がない¶
優れたエンジニアでも人間なので、追い詰められると判断を誤ったり、場当たり的な対応を良しとしてしまいます。そもそも今日を生きることに精一杯の人間は明日のことなど考えられません。つまり何が言いたいかというと、スケジュールが厳しければある程度クソでもしょうがないのです。
しょうがないのですが、これは将来にわたって苦しめられる問題を生む可能性を持っています。何故なら「多少コードに問題があってもそれだけでは書き直す機会が与えられない」からです。コードを変えるということはすなわちその分エンジニアが働くことになり、さらに変更に応じたテスト作業、受け入れ作業が発生します。「コードがクソなので直したいですお金ください」と言われてすんなり払ってくれるクライアントがどれだけいるでしょうか？クライアントとの信頼関係によっては成立する場合もあると思いますが、根本的な問題は（強要でもされていない限り）スケジュールの引き方を間違えた側にあるとしてタダで直せやくらいまで言われかねません。
現実的には追加開発時の費用や保守費用で「ちょっとずつ」直していくか、直すことを諦めて場当たり的な対応を続けることが多いのではないでしょうか？何れにせよ担当するエンジニアには苦行になるでしょう。
一方、苦行であってもチーム内で改善する意識が共有できていれば楽しい、あるいはやりがいのあるものにもなり得ます。
技術面の考慮をしていない無理なスケジュールに対して待ったを掛け、妥当なスケジュールを提示する責任は、誰にあるでしょうか？
CTOです
3. 新しい技術やフレームワークに対する知識不足¶
優れたエンジニアでも新しい技術やフレームワークに対しては間違った使い方をすることがあります。
人間なので、ミスはするものなのですが、2. で触れたように一度納品したものに手を加えるのが難しいものです。
これに対して取れる対応としては「使ったことがない技術には調査期間を設ける」「試作したものを他人に評価してもらう」などが考えられますが、実際に作ってみないと判断が難しいものでもあり、ある程度発生するものとして受け入れるしかないように思います。
新しい技術の導入可否において責任を持っているのは誰ですか？
一般的にCTOと言われますが、これは避けようと思って避けられるものではないので、作った後にチーム内の改善意識をどう持っていくかという話になると思います。
4. つらコードを書いても評価に影響しない¶
私が知っている会社で（そんなにいろんな会社知ってるわけでもないですけど）つらコードを書いたら減俸されるような会社はありません。
逆説的には減俸されないのだからいくらつらコードを書いてもいいことになります。
社員評価において、技術的な評価を下す責任は誰が持ちますか？
CTOです
5. 採用をミスっている¶
言わずもがなですが、上述したような外的な要因を除けばつらコードはつらコードを書く人間から生まれるので、採用時にそういう人間を取らなければ良いということになります。
社員採用において、技術的な評価を下す責任は誰が持ちますか？
CTOです
はい¶
全てがCTOの責任ではありませんでしたが、概ねCTOの責任でした。
何が言いたいのか¶
特定のCTOが悪いっていう話をしたいのではなく、つらコードが存在し続けるということはCTOが責任を果たせていない可能性が高いので、見直した方がよろしいのでは？という問題提起に近いです。それもまた差し出がましい話ではあるのですが。
つらコードでも問題ない（財布は痛まない）のでは？と思われるかもしれませんが、具体的な損失として、エンジニアが流出します。
つらコードに向き合うことに楽しさややりがいを感じることもできますが、これは前向きな改善ができている場合です。チームメンバーがつらコードを生み出す状態が続いている、つまり１歩進んで２歩下がるような状態でやりがいを見出すことはできないでしょう。エンジニアの在籍期間を伸ばす手段の一つとして、つらコードは修正していく（そういうチーム作りをする）べきでは、と考えます。
そもそも、単純な利益だけを見ていたら開発期間は際限なく短くした方が良いのは当然で、経営判断に別の視点を入れるためにCTOが存在しているはずなのだから、CTOは別のCXO (Xは任意のアルファベット)からは損失に見える提案をしていく必要があるし、CXOは利益だけで却下せずにCTOの提案に耳を傾けるべきでは？と思います（いや、現実的にどうかとか、知らないですけど）。
最後に¶
そもそも要件定義がクソ・設計がクソでコードがクソ化するんやっていう話もあるんですが、際限ないのでこの辺で
Footnotes