こんにちは！株式会社東京ファクトリーの執行役員CTOのIkawaと申します。

　東京ファクトリーでは製造業を中心としたお客様向けにSaaSプロダクト『Procceedクラウド』提供しています。この記事ではプロダクト開発の観点から東京ファクトリーがどのような会社かご紹介します。今回のテーマは「チーム開発における”良いコード”とは」です。

背景

　MVP開発開始から2年余り、弊社SaaSプロダクト「Proceedクラウド」はこれまで機能拡張を積極的におこなってきた中で、コードベースはいわゆる「技術的負債」が溜まってきてしまっている状態です。状況を改善するために開発チームとして認識を合わせ、以下のような取り組みを実践しています。

実装の速さより読みやすさを重視する

　特にアジャイルでのSaaS開発においては、ソースコードの大部分は何度も繰り返し読まれ、保守され、改修されていきます。たとえ実装に手間や時間がかかるとしても、ソースコードが読みやすくなる・保守改修しやすくなるなるのであれば、開発組織全体で見た総合的にかかる長期的なコスト（=その機能のために費やす時間時間）は短くなります。したがって東京ファクトリーでは、手早く機能を実装することよりも、時間がかかっても読みやすいコードを書くことに重きを置いています。

　一般的に読みやすいコードを記述するためには、リーダブルコードなどの優れた書籍や、各言語のベストプラクティスなどを参考にするとよいでしょう。一方で全てのエンジニアあらゆる観点から常に読みやすいコードを書くのは、容易ではありませんし、開発する対象や開発手法・チームによって効果の出やすい点は変わってきます。

「どのように書くか」「どこに書くか」をチームで一致させる

　「読みやすいコード」を書いたとしても他の人から人から見たら読みやすいコードではないかもしれません。たとえ読みやすい綺麗なコードを書く技術を究めたとしても、どのような視点で問題を捉えて分割していくかによって、読みやすいコードは変わってくるはずです。したがって継続的なチーム開発の中では、各々が綺麗なコードを書くスキルを身につけることに加えて、「チームの誰が書いても同じようなコードになる」ように仕組みを作っていくことが大切です。

　また、読みやすいコードを実現するための観点として、大きく以下の2点が挙げられると考えています。

1. コードを読んで機能の内容がすぐにわかること
2. 各機能のコードがどこにあるかすぐにわかること

　これらは、プログラムを実装するときの言葉に置き換えると、 1. はコードをどのように書くか、2. はコードをどこに書くかということに対応しています。これらをチームで一致させることて「（チームにとって）読みやすいコード」を実現させることができます。

実際の取り組み（命名規則とモジュール依存制約）

　段階的に（かつ効果的に）読みやすいコードの実現を目指すために、変数名等の命名規則と、各モジュールの配置規則を作成しています。

　コードをどのように書くかという観点では、まずは変数名や関数名が適切に名付けられることが大切であると考えています。「適切な名付け」には用語集や他のソースコードとの整合性も観点に含まれるため、適切に名付けられれば統一された実装になりやすくなります。命名規則を用意し、コードを読んで機能の内容がすぐにわかるように試みています。

　コードをどこに書くかという観点では、アプリケーション全体としてはクリーンアーキテクチャベースでのレイヤ定義を行い、フロントエンドコンポーネントについては関心を持つモデル単位でのパッケージ切り分けを行なっています。例えば新しく機能追加するときには、どこにコードを追加すべきかをなるべく一意に特定できるように心がけています。また一部各モジュールから依存できるパッケージをLinterでルールとして設定し、規則に則らないコードを機械的に検知できる仕組みを試験的に導入しています。

開発チームメンバー募集

東京ファクトリーでは開発チームメンバーを募集しています。

• 読みやすいコードを重視している環境で働きたい
• リファクタリングが得意だ
• チームでの開発ルール整備をしてみたい

など、少しでも興味があれば、ぜひご応募ください！