今回は、『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』を出版する森篤史さん（X：https://x.com/at_sushi_at）へのインタビューです。前編・後編の二部構成で公開します。前編の今回は、以下の大事な2つの点について、詳しくお伝えしていきます！
- 「そもそもなぜ良いコード（保守性が高いコード）を書く必要があるのか」保守性に対する目的を理解すること
- 原則や手法を覚えるだけでなく、それぞれの目的や利益を理解して、適切に取捨選択すること
きっとあなたは、この記事を読み終わったとき、“良いコード”についてもっと知りたくなっているはずです。
“良いコード”を始める前に。まずは目的から考える
では、そもそもなぜ良いコード（＝保守性が高いコード）を書く必要があるのでしょうか？まずは、保守性に対する目的を理解するところから始めてみましょう。
コードの読みやすさや、保守のしやすさなど様々なルールや方法がありますが、それ以前に、「なぜ、それを目指すべきなのか？」がはっきりしていないと、どんなに理屈を覚えても実際の現場で活用することはできません。
本の元となっている新卒研修「良いコードとは何か」を話したときにも、「どのようなコードのほうが好ましいのか」とか「設計はこうした方がいい」という技術的な内容より、「どうして高い保守性が必要なのか」に焦点を当てました。それは、「そういう視点があるんだ」と知ってもらうことの方が大事だと思ったからです。
実は、そんな僕にも“良いコード”を意識せず、とにかく動くものを作ることに集中していた時期がありました。
*ここでは本でも明記されているように、簡単に変更できる保守性が高いコードを「良いコード」と定義します。
「動く」けど、なぜかその先がうまくいかない...
高専時代の僕は、とにかく「まず動くものを作る」ことを重視していました。ハッカソンのように短期間でプロダクトを作ってプレゼンする経験を重ねていた僕にとって、まずは形にすることが最優先事項だったんです。面白いものができた手応えはあるのに、いざ、サービスとして育てようとすると急に手が止まってしまう。思うように進まず、楽しかった開発が急につまらなくなって、やめてしまう...そんなことが何度もありました。
そのときは理由がわかりませんでしたが、あとから振り返ってみると、それはコードの構造や書き方に原因があったんだと思います。“良いコード”じゃなかったから、続けられなかったんですよね。そんなふうに、もどかしさを感じながらも原因がわからないまま過ごしていた僕が、“気づく”きっかけを得たのは大学への編入後のことでした。
「なんだか読みづらいコード」から“良いコード”へ
大学へ編入すると、他の高専や大学内部生などバックグラウンドの異なる仲間たちと一緒に開発をする機会に恵まれました。そこで初めて、「森のコードはなんだか読みづらいな...」という言葉をかけられたんです。コードは「動かすためのプログラム」だと思っていた自分にとって、それは全く新しい視点で、衝撃でした。でもその一言が、“良いコード”への入り口になったのです。
そこからは、周りの人に教えてもらったり、読みやすさについて自分でも調べたりしながら、“良いコード”って何だろうという問いが徐々に深まっていきました。可読性、保守性、アーキテクチャやテスト...知れば知るほど、「あのときのあの失敗って、こういうことだったのか」と思うように。
そしてついに、“良いコード”とは、そのプロダクトの開発を続けるために他の人や将来の自分が読んで正しく理解できるコードなのだと気づいたのです。自分があとから触ってもつらくないし、他の誰かに引き継いでも「なるほど」って思ってもらえる。プロダクトの価値を育て続けていくための土台になるような”良いコード”に夢中になっていきました。
開発スピードや品質が上がる？原則やルールは目的・効果を理解すべし
ここからは、原則や手法、それぞれの目的や利益を理解して、適切に取捨選択する準備を進めていきましょう
大事なのは、難しい原則名やルールをただ覚えることではありません。できるだけ、その考え方を噛み砕いて、理解してみてください。もともと、学生時代の僕も原則の名前など難しい単語を覚えることは苦手でした。ただ、「なぜこの設計なのか」「なぜこの命名なのか」を噛み砕き理解することで、活用することができるようになっていったと思います。
もちろん、考え方は複数ありますし、携わるプロダクトや開発環境、事業フェーズなどそのシチュエーションによって「絶対にこれが良い！」と断言できないような部分もあります。だからこそ、本の中では、実際の開発現場で迷ったときに頼りになるような考え方や、順序立てて理解しやすい構成にこだわって、本を書き進めていきました。
僕自身も“良いコード”の考え方や適用する指標を知って、プロダクトの品質も開発スピードも変わったと実感してきました。僕が書いた本が、これから“良いコード”を始める方がその体験をする一助になったらと思います。
感覚を言語化すると“良いコード”はまだまだ極められる
そんな整理を進める中で、僕自身今まで曖昧で感覚で判断していた「依存性逆転の原則」を適用すべき指標が明確になりました。
SOLID原則のひとつDependency Inversion Principle（＝依存性逆転の原則）とは、「具体的な中身に直接依存するのではなく、抽象的なインターフェースに依存するようにする」という設計の方針のことです。このように、あとから中身を取り替えるのがすごくラクになる。これって、ソフトウェアの柔軟性が上がるから、コードが長く使えるようになるよね、という考え方です。
人によってどの場面で適用するかの意見が分かれがちな考え方です。本の中で言語化するにあたって複数人でかなりの議論を重ねました。その結果、「この場合はインターフェースを使った方がいい」「この規模や変更頻度ならむしろ使わなくていい」と細かく指針を整理することになりました。この議論は、僕自身の感覚を言語化する良いきっかけにもなりました。もともと感覚で捉えていた考え方を、言葉にして伝えることで、改めて自分自身が一番学ばせてもらった気がしています。この本は、僕にとっても“良いコード”を言葉で見つけていく旅のひとつでした。
いかがでしたか？
「今までわからなかったことが、ある日ふっとつながる瞬間がある」
森さんがそう語ってくれたように、『良いコードの道しるべ〜』は、きっとみなさんの気づきを引き出してくれるはずです。この記事が、そんな“気づき”のきっかけになれば嬉しいです。
後半の記事では、『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』の読み方や本に込めたメッセージを中心にお伝えしていきます。
書籍が気になった方は以下の森さんのnoteからぜひチェックです！
