コーディングに関する名著『リーダブルコード』（オライリー・ジャパン）の序章は、次のように始まる。

コードは理解しやすくなければならず、シンプルで無駄の無いことが重要だということを、この名著は教えてくれる。

ただ一方、自身の開発現場が「美しいコード」で溢れているかと問われたらどうだろうか。ついつい「複雑なコード」を書いてしまいがちなエンジニアは、少なくないはずだ。コードはシンプルで無駄の無いことが重要であることが分かっていても、なぜ「複雑なコード」は生まれてしまうのか。

その答えをくれるのが、書籍『脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック』（オライリー・ジャパン）だ。著者のマーク・シーマンさんによると、「脳に収まるコード」を書くポイントを習得することで、複雑なコードが生まれにくくなり、開発が持続可能になるという。

果たして、その真意とは。本著の翻訳者であり、アジャイルコーチとして数々の実績を持つ吉羽龍太郎さん(@ryuzee)に話を聞いた。

株式会社アトラクタ
Founder兼CTO/アジャイルコーチ
吉羽 龍太郎さん(@ryuzee)

野村総合研究所、Amazon Web Servicesなどを経て現職。アジャイル開発、DevOps、組織開発を中心としたコンサルティングやトレーニングが専門。Scrum Alliance認定スクラムトレーナー。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）など、訳書に『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『チームトポロジー』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）、『ジョイ・インク』（翔泳社）など多数

エンジニアの「善意」が複雑さにつながることもある

ーーそもそも、なぜ「複雑なコード」が生み出されてしまうのでしょうか。

これが実は面白くて、決してネガティブな理由からだけではないんです。というのも、エンジニアが新しく学んだことをコードに反映させるプロセスを繰り返す限り、複雑なコードは生み出されるからです。

例えば、ユーザーからフィードバックを受けたり、あるいは日々技術書を読んでスキルアップに励んだりすることで、エンジニアは新しい知識をどんどん蓄えていきますよね。そうして身に付けた知識でプロダクトをより良い形にしようと考えるのは、エンジニアであれば当然のことです。

しかし新たな知識を得ることで、開発の初期段階で「最善」と考えられていた設計や実装が、時間が経つにつれて「陳腐なもの」や「時代遅れのもの」に感じられることがあります。そうなるとエンジニアとしては、これを改良したいという衝動に駆られるでしょう。

ここで問題が発生します。新しい知識や技術を取り入れるためにコードに変更を加える際、既存の機能や設計との互換性を維持しなければならないため、そのバランスを取るために追加のコードや調整が必要になります。意図的に複雑なコードを追加するつもりはなくても、こうした調整や修正が積み重なることで、結果としてコード全体が複雑化してしまうのです。

ーーエンジニアの良かれと思った行動が、かえってコードの複雑さを助長することもあるのですね。

はい。とはいえ、ネガティブな理由で複雑なコードが生み出されてしまうケースも当然あります。

ビジネスサイドからの「とにかく早くリリースしたい」「リリースしてから直せばいい」という要望を受けて、今ひとつの品質でプロダクトをリリースしてしまうケースなどは、その代表例でしょう。

本来は、品質を高めることによってスピードも上がるものだと思います。しかし一部の現場では「質を落とせば早く開発できる」という認識が蔓延してしまっていることで、いわゆる「見切り発車」が行われることもしばしばあります。

エンジニアはビジネスサイドの要望に耳を傾けつつも、後々チームの仲間や自分自身が困らないように、常に綺麗なコードで納品する努力をしなければなりません。

ーー複雑なコードが生まれてしまうと、開発現場にどのような弊害が生まれるるのでしょうか。

いくつかの弊害が考えられますが、中でも顕著なものは、開発や保守のスピードが著しく低下してしまうことですね。

そもそも複雑なコードとは、多くのモジュールやクラスに依存していたり、条件分岐やループが多くロジックが複雑で理解しがたいものを指します。そのため、コードの全体像を把握することだけでもかなりの労力が掛かりますし、「どこをどう触ると何が起きるのか」が一目で判断できません。

するとシステムに何か変更を加える必要が生じた際、まずコードの構成を調査して、その影響範囲を特定するという、本来は必要の無い作業を強いられることになります。その結果、改修対応に取り掛かるタイミングが遅れてしまうといったケースはよくあります。

コードは正しく機能すれば良いわけじゃない

ーー『脳に収まるコードの書き方』では、複雑なコードを回避することの重要性が提唱されていると伺いました。この「脳に収まるコード」とは、具体的にどのようなコードを表しているのですか？

一言で言うと、人間の短期記憶に収まる範囲で書かれたコードです。

具体的には、「モジュールの中で7個以上のことはやらない」といった制約を掛けることによって、人間が内容を瞬間的に把握できるコードになると提唱されています。わざわざ全体像を抑えなければ理解できないようなコードは、その構造を長期記憶に一旦移動してから処理する必要があるので、脳に大きな負荷が掛かります。

しかし、常にコードを綺麗な構造に保つことができていれば、読むたびに頭の中に全体像を叩き込むような作業は不要です。作業時間が短くなる上に、見通しがスッキリするので、合理的な判断も下しやすくなるでしょう。

この本では「コードは書く回数よりも読む回数の方が多い」と書かれていますが、そのことをエンジニアは改めて認識する必要があります。

ーー自分のコードを読んだりメンテナンスしたりする、他の開発者のことを想像できているかどうかが大切ということですね。

はい。その意識を忘れないためには、自分の書いたコードに、変数名やメソッド名といった「名前」を適切に付けられるかをチェックすると良いかと思います。コードの動作や目的が明瞭な状態でないと、適切な名前を付けることはできませんから。実際、変数名やメソッド名が雑なチームはコードも複雑な傾向があります。

それから、単純に長いコードはシンプルにダメです。「何とか動くように頑張ったんだな」と思われてしまうような冗長なコードは、絶対に脳には収まりません。大きいメソッドを部分的にヘルパーに括り出すとか、一部を抽出してもっと見通しを良くするとか、後でコードを読むときのことを考えて作業した方が良いですね。

また本書で紹介されている「80/24ルール」を活用するのも、一つの方法です。これは、かつてターミナルのサイズが「80文字×24行」だったことに起因するプラクティスですが、そのサイズにメソッドを収めることは、単に長いコードを書くことを防ぐ上では便利な考え方だと思います。

ーーそのような「綺麗なコード」を書くためのテクニックは、本書でも多く紹介されているのでしょうか。

はい。本書は先人たちの経験則や他の人が開発したプラクティスが一冊にまとまっています。

例えば、テスト駆動開発でテストをドライバにしてコードを書くとか、バージョン管理でgitを使いこなすとか、静的解析でコードのメトリクスを分析し、コードの中での分岐を表す指標であるサイクロマティック複雑度を活用するといった話ですね。

しかも各々のプラクティスの相関も示されているので、綺麗なコードを書くためのノウハウを網羅的に理解できると思います。

チーム全体で「持続可能な開発」を心掛ける

ーー「綺麗なコード」を書けるようになるには、まずどのようなアクションから取っていけば良いと思いますか？

まずは、コーディングに対して正しい認識を持つことから始めると良いと思います。というのも、もしあなたが「要件を満たしたコードを書いたら、自分の仕事は終わり」と思っているのであれば、それは甘い考えと言わざるを得ません。

なぜなら、いつでも誰でもコードのあらゆる場所を触る可能性があるというのが、今のソフトウエア開発の基本的な考え方だからです。そして今回私が翻訳に携わった『脳に収まるコードの書き方』でも、「ソフトウエアは組織を持続可能にするものでなければならない」と書かれています。

だからこそ、開発を持続可能にしてプロダクトが成長し続ける状態を保つには、複雑なコードを生み出さないための努力が必要なんです。

ーーなるほど。何のために、誰のためにコードを書いているのかを、改めて意識し直す必要がありそうです。

はい。「自分以外の人が理解できるか」「将来自分がメンテナンスできるか」といった観点を持つことが、非常に重要です。

ですからコーディングの練習をする際には、一人きりで作業を完結させるのではなく、できれば自分が書いたコードを誰かに読んでもらい、フィードバックをもらうのが良いでしょう。客観的な視点を取り入れていくことで、徐々に脳に収まるコードを書けるようになります。

また、もしコードの複雑さで悩んでいるエンジニアがいたら、どうすれば持続可能なコードが書けるのかをチームで話してみるのはいかがでしょうか。もちろん個人のスキルアップは必要ですが、今携わっているプロダクトのコードそのものに課題を感じているのなら、一人で悩み続けるのはやめましょう。

ーーエンジニアが「綺麗なコード」を書けるようになるには、チームとしてのアプローチも欠かせないといえそうです。

その通りです。チーム全体のコードが良くないと感じるのならば、業務の中で練習時間を確保できるように環境を整えた方が良いですね。例えばアジャイル開発の計画を週次で立てているならば、全部の時間を開発に使うのではなく、10%〜20%はトレーニングに充てることをおすすめします。

チームが成長して「脳に収まるコード」を書けるようになれば、プロダクトが常にメンテナンスしやすい状態になります。すると安定したスピードで開発が進むので、ビジネスサイドも予定を立てやすくなり、事業計画全体がうまく回るようになります。

プロダクトのコードに課題を感じているエンジニアには、ぜひ「脳に収まるコード」のポイントを理解して、自分に足りないものを取り入れてもらいたいと思います。

取材・文／一本麻衣　編集／今中康達（編集部）

ソフトウエアは複雑さを増すばかりだが、人間の脳は限られた複雑さしか扱えない。ソフトウエアが思い通りに動くようにするには、脳に収まり、人間が理解できるコードを書く必要がある。

本書では、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践方法を解説。コードの腐敗や不必要な複雑さにつながる要因を避ける方法、コードの振る舞いを変更するための術、コードの問題を迅速かつ効果的に解決する方法まで幅広く紹介されている。

＞＞詳細はこちら