技術的負債の一種であるスパゲティコードとは何か?その内容と解決法を解説

スパゲティコードの概要

スパゲティコード(Spaghetti code)は、プログラムやソースコードを制作したプログラマー以外は解読困難であるコードを意味する俗語で、技術的負債の一種であると言えます。名前の由来は、スパゲティのようにロジックが絡み合っていることから名付けられました。
スパゲティプログラムとも、継ぎ足しされた秘伝のタレなどと呼ぶ人もいます。

スパゲティコードは、プログラムの手直しを難しくし、システムの保守・機能追加がしづらくなるため、一般的には好まれません。スパゲティコードを記述するプログラマーは、他の人から「やっつけプログラマー」として見られ、敬遠されがちです。そのプログラマー自身しか解読できないコードを使用してしまうと、他のプログラマーがコードの手直しをすることができなくなります。

しかし後述するように、第三者に対する可読性を追求しない場合は、スパゲティコードであるかどうかを意識しないことにより、スピード開発ができたり、開発コストが安く抑えられたりするなどのメリットもあります。
これが原因となり、スパゲティコードを根絶することは難しいことになっています。

なお近頃は、jQueryなどのJavascriptライブラリで、スペースや改行のない、可読性を欠くコードが配布されていますが、こうしたコードはスパゲティコードとは呼びません。jQueryなどに見られる可読性のないコードは、あくまでダウンロード時間の短縮を目的としてスペースや改行を無くし、ファイルの容量を圧縮した結果であり、一般的なスパゲティコードとは経緯が異なります。
また、圧縮されたとはいえ、

スパゲティコードの特徴

スパゲティコードの特徴は、コードの可読性が低いことですが、単に「コードの書き方が洗練されていない」というだけでなく、開発の試行錯誤の跡がそのまま残されているように、あちこちの変数を操作したり、書きかけのコードが残されていたりと、関連するコードをすべて読まなければ(場合によっては、すべて読んだとしても)内容がわからないような状態をさします。

ノンプログラマーの方にもわかるように、通常の言葉でスパゲティコードを表現すると、だいたい以下のような言葉になります。

俺はランニング状態で足を止める。敵からの位置はそう遠くはなく、「近い」という言葉が「近い」という意味を超越するほどの近さで、敵に近づく。
敵が俺の瞳に飛び込んだ。敵は一つも俺に気づいていない。
俺は敵の腹にワンパンを決める。豪快なパンチ。それはパンチとは思えないほどの豪快さで一般市民がこのパンチを見たら「これが本当に人間の成せる技か?」と目を丸くしてしまうほどに一般市民との力の差は離れており、それほどまでに豪快な雰囲気を俺は体中から発散させていた。

やる夫が小説家になるようです」より

これは過去にネットで話題になった物語で、小説家を目指す主人公が作った悪文です。
誰もこの文を読んで「読みやすい」とは思わないですし、「何が言いたいの?」と感じてしまうでしょう。
その理由としては「文法の誤り」「言葉同士の矛盾」「同じ言葉が繰り返されて、結局何をしているのかがわからない」「言っていたことと逆のことが後で記されている」というようなものが挙げられます。

スパゲティコードも同様で、コードとして読めなくはないけど、結局何をしているのか把握できないというというのが特徴として挙げられます。

スパゲティコードのデメリット

スパゲティコードを記述するプログラマーは敬遠されがちですが、なぜ敬遠されてしまうのでしょうか?
ここでは、スパゲティコードのデメリットについてご紹介します。

トラブル対応が困難になり、保守性を下げる

スパゲティコードを作ってしまう一番のデメリットは、保守性が著しく下がることです。
スパゲティコードでも仕様や要件を満たしていると、動作に支障は出ません。
しかし、可読性が低いため、トラブルが発生したときに実行順を追って問題箇所や原因を特定したり、修正するのが難しくなってしまいます。
さらに修正することで、予期せぬ影響を与えてしまい、新しいバグの原因になったりするなど、トラブル対応を完了させることが難しくなってしまいます。

大きな損害につながる

スパゲティコードのシステムを使うということは、何をしでかすかわからないロボットと仕事をするようなもので、いつ停止したり、暴走したりするかわかりません。
大きなプロジェクトの場合は、システムが一瞬止まるだけで億単位の損失が出ます。システムの不具合で損害が出た場合、損害賠償金を請求されてしまう可能性もゼロではありません。
スパゲティコードを記入するのは個人の自由ですが、組織で働く以上は損失が出ないように規則に従った方法でコーディングしなければいけません。

機能追加が難しくなる

スパゲティコードが存在することにより、よく問題として挙げられるのは、機能の追加が難しくなることです。
例えば、クライアントがシステム完成後に機能追加を希望することがあります。このような機能追加をする場合、スパゲティコードだと、どこに手を加えたらよいのかがわからず、機能追加が難しくなってしまいます。

周囲に迷惑をかけてしまう

大きなプロジェクトに参加する場合は、さまざまなプロジェクトメンバーと関与して力を合わせてシステム開発を行っていきます。チームワークを大切にするために、周りの人が解読できるコーディングを心掛けなければいけません。
例えば、スパゲティコードを書いたプログラマーが休みの時にトラブルが起きた際、チームの他のプログラマーが対応しなければならないということもありますが、その際に必要以上の負荷をその対応するプログラマーにかけてしまうことになってしまいます。
こうなってしまうと周囲に迷惑をかけてしまいますが、それだけでなく、代わりのプログラマーで対応できないという場合には、スパゲティコードを書いた本人が最悪の場合休みの日でも対応しないといけなくなり、自分の時間も犠牲にしてしまうことになります。

プロジェクトメンバーにも関わらず、他の人が解読できないスパゲティコードを記入するプログラマーは「やっつけプログラマー」として周囲の人に多大な迷惑をかけて、敬遠されてしまうことも多いです。そのため、チームワークを大切にするためにも、スパゲティコードを記入しないように注意しましょう。

なぜスパゲティコードが発生してしまうのか?スパゲティコードをつくるインセンティブ

スパゲティコードは技術的負債である

様々なデメリットがあるにもかかわらず、スパゲティコードに悩まされる組織は後を絶ちません。
その原因はさまざまありますが、一言でまとめると、スパゲティコードが技術的負債であるからです。
技術的負債とは、「先送りにされた修正作業」を意味します。では、なぜ修正作業が先送りにされるかと言えば、修正したいときに人手が足らなかったり、スケジュールとの兼ね合いで大きな問題でないのなら対応しないという理由があります。

技術的負債は、長期的な視点で見るとデメリットしかありませんが、短期的には人手や時間の不足をごまかすことができます。まさに「負債」という言葉の通り、借金する時と同じく、短期的にはメリットがあると言えます。

スパゲティコードも、時間がないからリファクタリングを考えなかったり、人手不足から「とりあえず動作するならそのままでいいや」という意識から生まれた技術的負債であると言えるでしょう。

技術的負債については、以下の記事もご参照ください。

技術力・経験の少なさから

プログラマーの技術力・経験の少なさというのは、スパゲティコードを生み出す源泉になります。
「あまりきれいな書き方に思えないけど、どうすればいいのかわからない」という技術的な面から、可読性の低いコードを書いてしまうこともありますし、経験の少なさから今書いているコードがどれだけ保守性の低いことなのかがわからないということもあるでしょう。

めんどくさいという感情から

スパゲティコードが発生する理由の一つに、人間がもつ「めんどくさい」という感情も挙げられます。
例えば、会計システムを運用している場合、消費税が変わったときなどは影響が広範囲にわたるので、システム全体を考え直さねばなりません。
しかし、考える作業をめんどくさがって、場当たり的な対応をすると、コードはスパゲティ化していきます。

スパゲティコードはスパゲティコードを呼ぶ

もし「めんどくさい」という心がなくとも、すでにコードがスパゲティ化し、「何でこうなるのかよくわからないけど、とりあえず動かさないと」という状況があれば、ますます複雑なスパゲティコードができあがってしまいます。
このように、スパゲティコードはスパゲティコードを呼び、それゆえ、スパゲティコードを「継ぎ足しされた秘伝のタレ」と呼ぶ人がいます。

スパゲティコードの対策法

短期的にはメリットのあるスパゲティコードですが、他のプログラマーが解読できないコードを記述してしまうと様々なデメリットがあることは、上述の通りです。
そのため、プログラマーをはじめ、テクニカル・ディレクターやSE、プロジェクト・マネジャーは、スパゲティコードをつくらないように注意していかなければなりません。
ここでは、スパゲティコードを生み出さないための対策法をいくつか紹介していきます。

プロジェクトマネジメントを見直す

スパゲティコードは技術的負債の一種で、技術的負債とは借金のようなものであるとお話しいたしました。
技術的負債発生の過程は、会社であれば「マネジメントがうまくいっていないから借金をする」という状況と大差ありません。
同様に、技術的負債はプロジェクトマネジメントがうまくいっていないからこそ発生するという面もあります。
「プロダクトの品質はプロセスの品質から1)共通フレーム、3頁。 という格言のように、プロジェクトマネジメントやそのプロセスが良くないからこそ、スパゲティコードという技術的負債が発生してしまいます。
そいのため、スパゲティコードを回避するには、プロジェクトマネジメントを見直し、時間や人手が足りないということから、やっつけの仕事をするということが無いようにすることが大切です。

設計を明確にする

スパゲティコードを防ぐ一番の方法は、設計を明確にすることです。
技術力・経験の少ないプログラマーだと、この設計のアイデアが乏しいため、効率のよくないコードを書いたり、保守性の低いコードを書いてしまったりします。
そのため、プログラムの仕組みを考える「内部設計」をプログラマーを統括するエンジニアやテクニカル・ディレクター、経験豊富なプログラマーなどが考えていくことで、プログラマーがあれこれ考えて、努力の跡がそのままコードに残ってしまうということをなくすことができます

KISSの原則に従ったコーディングを行う

スパゲティコードを作らないために、コーディングする際は、KISSの原則を守りましょう。KISSの原則とは、 “Keep it simple stupid “、つまり「シンプルで単純にしよう」というアイデアです。
例えば、ひとつのスコープに複数の機能を設定しなければ、非常にシンプルなコードとなり誰でも解読できます。コードを変更する場合も、判定処理に単体テストをかけられるためバグも起きにくくなります。KISSの原則を守ることが、スパゲティコードの回避には必要不可欠です。

コードのレビューを行う

プログラマーが書いたコードをテストする際は、動作の確認をするだけでなく、そのコードの記述の良しあしをレビューにて確認することが大切です。
この工程が抜けているからこそ、プログラマーが手を抜いてしまったり、経験の浅いプログラマーが書いたスパゲティコードに気づくことができません。
チームのためにスパゲティコードを書かないよう新人プログラマーに伝えるとともに、それをさせないよう、レビューを行ったりとチームとして周囲のサポートが不可欠であると言えましょう。

   [ + ]

1. 共通フレーム、3頁。