はじめに
こんにちは、8月からマネージャーにジョブチェンジ（？）したマツダです。
今日は敬愛する t-wada さんのスライド「質とスピード」を参照しながら、私のこれまでの実体験を振り返りながら答え合わせをし、今後目指すべき開発スタイルを探っていきたいと思います。
成功体験
私の過去の成功体験の中で一番大きいものは、やはり上場を経験できたことでしょう。
まだ数人しか社員がいなかったとあるゲーム会社に入社させてもらって、あっという間に250人規模まで成長。 設立から3年弱でマザーズ（当時）に上場、その1年後には勢いそのままに東証一部（当時）に市場変更したのでした。
その時の成功要因は、なんといってもスピード、タイミング。
1ヶ月足らずで新しいタイトルを開発し、そのジャンルの「1番手」になることで、大手が入ってくる前に市場を制圧することに成功できたのがすべてといっても過言ではありません。
一方、コードはとてつもなくひどいものでした・・・。
- 10,000行のメソッド
- 数百個以上の条件分岐
- コピペの嵐
- もちろんテスト皆無
スピードに全振りしたがために大きな技術的負債を抱え、結局「10,000行のメソッド」については私が在籍した4年間の間、一度も改変されることはありませんでした。 （ゲームの中核のシステムを担っていたにもかかわらず・・・！）
でも、この成功体験をしてしまったのが原因で、t-wadaさんのスライドにも出てくる
- 「あとでクリーンにすればいいよ。先に市場に出さなければ！」（Robert C.Martin「Clean Architecture」）
- 「今は大事な時期だからスピード優先で、コードの質は下げても構わん」（nekoyaさんのポストより）
という言葉にも違和感なく、「そうだよね、スピード命だよね」と思うようになっていたのでした。
もうひとつの成功体験
それから数年たったある日、私はたった4人しかいない小さな会社に入社しました。
しかも正社員のエンジニアは私1人だけ。
その会社は、いわゆるグループウェアとビジネスチャットの合いの子のような大きなシステムを自社開発していたのですが、私が入社する少し前にエンジニア組織が崩壊してしまったらしく、かろうじて業務委託の方1人で運用を回している状態でした。
もちろん、新機能追加などできるわけもなく、顧客からの要望リストは溜まっていく一方。
そんな状態で、当時の社長は思い切った経営判断を下すのです。
「2年かけて、リアーキテクトする。その間、新機能追加は一切行わない」
私と業務委託さんのたった”1.5人”で2年間、死にものぐるいで”クリーンなコード”を書きまくりました。
具体的には
- クリーンアーキテクチャに基づいた疎結合なテストしやすいコード
- もちろんテストはユニットテスト、スキーマテスト、統合テスト、フロントはVRTなどもすべて完備
- 徹底的に自動化。アプリのデプロイなども
- ”名前”にこだわる。1つのエンドポイントの名前付けだけで半日以上議論したことも
- レビューも妥協なし（まぁいいか、でApproveしない）
という感じで、まさに「質」に全振りした状態でした。
結果的に2年以上の間、顧客にはほとんど新しい価値を提供できなかったわけで、一見失敗と受け取られてもしょうがないエピソードのように見えます。
が、今になって考えると、とんでもない「質」の効果に気づきました。
- リアーキテクトする前に何度も計画が頓挫していた”スマホアプリ版”のリリースに成功
- リアーキテクト後は”1.1人”くらいの工数で運用も新機能開発もできていた（もしコードが汚ければ、体感10-15人は必要なイメージ）
- とにかくバグが少ない（＝顧客も安心して使える）
顧客の数はけっして多くありませんでしたが、それでもエンジニアの工数が”1.1人”であれば十分に黒字化はできており、これもひとつの成功と呼べるのではないでしょうか。（10-15人だと大赤字）
悩みの答え合わせ
こうした2つの成功体験を積んで、私の中では「質とスピード、結局どちらが正義なのだろう」という悩みが尽きませんでした。
そこに明快な答えを出してくれたのが、今回紹介したt-wadaさんのスライドです。
- 質とスピードはトレードオフではない
- 内部品質への投資の損益分岐点は「1ヶ月」以内にやってくる
- テスト自動化の損益分岐点は「4回」
- 内部品質を犠牲にしたとき、失われるのは「保守性（理解容易性、変更容易性、テスト容易性）」
というわけで、質とスピードはどちらも正義、が正解なのです。
保守性を高めるための読書ガイド
では、具体的にはどうすれば内部品質を犠牲にせずに保守性の高いコードを書けるのでしょうか。
すべて説明すると、社内勉強会の30分という時間にはおさまらないので、おすすめの本を紹介して終わることにします。
理解容易性
理解容易性とは、その名のとおり、そのソフトウェア（コード）が理解しやすいか否かです。
下記のような本を読むことで、理解容易性の高いコードを書くことができます。
変更容易性
変更容易性とは、その名のとおり、そのソフトウェア（コード）が変更しやすいか否かです。
下記のような本を読むことで、変更容易性の高いコードを書くことができます。
テスト容易性
テスト容易性とは、テストが書きやすい、安定した結果を得られる、などの性質をあらわす言葉です。 （具体的にはISO 25010で規定されているので調べてみてください）
下記のような本を読むことで、テスト容易性の高いコードを書くことができます。
紹介した本はすべてiimon社内にあります！ 興味を持っていただけたらぜひ読んでみてください。
宣伝コーナー
弊社ではエンジニアを募集しております。
ぜひカジュアル面談でお話ししましょう！
ご興味ありましたら、ご応募ください！
