プログラマは「コードを読む」ことに労力を割いている

「手を動かす」という表現は、プログラミングに対する誤ったイメージを絶妙に反映した言葉選びだと、そう思えてなりません。目に浮かぶのは、キーボードに向かってカチャカチャと一心不乱にコードを打ち込むプログラマの姿でしょうか。映画に描かれるハッカーもカチャカチャカチャカチャッと、高速タイピングを駆使し、鬼気迫る攻防を繰り広げます。優秀なプログラマというのはとにかく「手」が早い。キーボードにもこだわりを見せる。「手を動かす」という言葉の通り、プログラミングとは「コードを書く」こと。これが一般的なイメージなのでしょう。

フィクションであればそれでもまあ良い。カーチェイスで巧みなハンドルさばきで追っ手を振り切る元諜報員の逃亡者のように、はたまた高度な呪文を次々と繰り出す老練な魔法使いのように、プログラマはコードを自在に操ってサイバー空間を制する。かっこいいじゃないですか。天才的な頭脳によるひらめきが瞬時にコード化されていくワケです。カチャカチャカチャカチャッ、ピッと。

プログラミングに対するイメージとしてこれほどまでに存在感のある「コードを書く」という振る舞いでありますが、実態はそうではありません。機能追加や機能改善を繰り返すソフトウェアプロダクト開発におけるプログラミングでは、コードを書くことよりもっと労力を割いていることがあるのです。それは、「コードを読む」ことです。もちろん、プログラミングは知識労働なので「考える」ことや「調べる」ことに多くの時間を割きますが、それと同じくらい時間を割くのが「コードを読む」ことなのです。この事実がホント、悲しいほど知られていません。ビジネスの競争力を左右するほどのインパクトを持つというのに……。

「コードを読む回数は、コードを書く回数の10倍以上」とも言われるぐらい、プログラミングは「コードを読む」ことに労力を要する活動です。

そうであるなら、既存のコードが読みやすければプログラミングの時間が短く、読みにくければ長くなることは明らかです。コードの読みにくさは技術的負債の一因となる。ソフトウェアプロダクトのマネジメントに失敗しないためには、この点を理解しておくことが必要条件でしょう。技術的負債の増大がソフトウェアデリバリのパフォーマンスを悪化させ、ビジネスの競争力を奪うことは今や誰もが知るところです。

プログラミング言語には、JavaやRuby, Python, PHP, JavaScriptなど、様々な種類が存在します。いずれにしても、「言語」と呼ぶからには日本語や英語といった自然言語と似た特徴を持っています。そのひとつに、何かを伝えようとするための表現方法が自在だという点が挙げられます。

コンピュータは、記述された文が正確でさえあれば言う通りに動いてくれます。表現方法は関係ありません。美しくエレガントな表現であっても、ひどく散らかった乱文であっても。

問題はここです。乱文でもコンピュータは瞬時に理解するけれど、人間なら理解するのに苦労する。コンピュータだけがコードの読み手ではなく、プログラマもコードの読み手なのです。

ソフトウェアプロダクトに対する機能追加や機能改善は、例えれば、長大な小説を一部の矛盾も無く改変するようなものです。物語を書き終えてから、新たに過去のエピソードを追加しようとすれば、物語のあらゆる箇所と整合性を取らなければいけません。著者であっても、書いた内容を一字一句すべてを記憶しているわけじゃないから、既存の文章を読み直しながら加筆修正を進めるしかありません。矛盾があれば物語が台無しになってしまいます。ましてやソフトウェアは、多くの人の手によって書かれ、そして日々書き換えられていきます。自分が書いたコードですら数週間もすれば記憶から薄れていくというのに、コードを読むことの苦労たるや！

IPAによると、ソフトウェアの新規開発プロジェクトで扱うコードの行数は54.７千行（SLOC）、改修・保守プロジェクトだと22.2千行（SLOC）が中央値ということです。単純には比較できませんが、文庫小説1冊あたりが数千行程度ですから、コード量の大きさがうかがえます。

IPA 『ソフトウェア開発データ白書2018-2019』p.92, 図表5-2-24

機能追加や機能改善というのは、これほどまでの超大作に手を加えようとする行為なのです。コードの可読性が低い状態を技術的負債のひとつと捉えることは十分に妥当だと言えます。コードを読むことに時間がかかると、機能追加や機能改善に要する時間も長くなるわけですから。プログラマが「リファクタリングが必要だ」と切実に訴える背景のひとつは、こういうことだったのです。

プログラマは、日々の開発に追われ過ぎるとコンピュータが理解できれば十分という低品質のコードを書いてしまいます。人間にとって理解容易なコードに練り上げるには少し時間がかかります。そんな時間は取ってられないから、動くコードが書けたらそれで良しとして次に移る。この繰り返しが可読性の低いコードを大量生産し、コードを読む時間が益々長くなってプログラマから時間を奪っていきます。そうすると、プログラマはまた一段と日々の開発に追われようになる……負の連鎖です。

じゃあコード品質改善のために時間を作って問題を解決しよう、そう考えるかもしれません。でもそれだけじゃ、きっと上手くいきません。高品質な文章を書くためにスキルが必要であるように、高品質なコードを書くにもスキルが必要です。そして、誰もが自身の文章力に問題意識を持っているとは限らないように、プログラマの誰もが自身のコード品質に問題意識を持っているとは限りません。

時間的余裕を作ること、問題意識を持つこと、スキルを上げること。ビジネスの成功を持続可能にしたいなら、この3つを揃えて正の連鎖を繋げることが必須となるでしょう。