こんにちは、estie でソフトウェアエンジニアをしている riano_ です。
この記事は estie 真夏のアドベントカレンダー 7日目の記事です。
estie に入社して、ちょうど 1 年が経ちました。という趣旨のちゃんとしたブログは、もう少ししたら公開したいと思って書き始めているのですが、今日は普段の仕事の中で漠然と考えていることを書き連ねてみます。軽い読み物のつもりでぜひお楽しみください。
「あなたが落としたのは、金の斧ですか？それとも銀の斧ですか？」
この質問に対する正解が、金の斧でも銀の斧でもないことは、多くの方がご存知であることと思います。しかし、仕事の中で、あるいは日常生活の中で、「A を取るか、B を取るか」という質問が与えられたとき、それ以外の選択肢を自然に考えることが出来る人は多くはないでしょう（僕も意識しないと出来ません）。
世の中には、二者択一に見える選択が溢れています。
例えば、ソフトウェア開発の現場において。よく語られるトレードオフとして、品質と速度の話があるように思います。「品質を犠牲にして最速で成果を出すのか、速度を犠牲にして最高の品質を目指すのか」といった形で問われることが多いでしょうか。そして大抵は、「要はバランス」という、一定程度正しくも、ありふれた結論に帰着するのかもしれません。しかし、両者は本当に両立できないのでしょうか？あるいは、本当にトレードオフの関係にあるのでしょうか？
「品質と速度は実はトレードオフではなくて、品質が高いからこそ速度が上がるという側面がある」と、とある先輩が言っていました。整理されたコードであれば、読みやすさによって実装者の誤解や迷いを減らし、振る舞いの把握を容易にします。明快な設計がなされていれば「この機能はどこに置くべきか」という悩みが無くなり、あるいはそれを発端にして個々人の思想がぶつかり合うことも無いでしょう。そして何より、仕様そのものをできる限りシンプルに保つことで、何度も何度も複雑な仕様を確認し、「ここはこれで間違っていないよな、こうすることで壊れる箇所はないよな」と確認する手間さえも減らします。つまり、品質は速度を産むのです。
一方で、「速度が品質を産む」というのもまた真であると僕は思っています。時に複雑な要求となる仕様を、シンプルな仕組みで実現していくためには、何より試行錯誤が重要です。とりあえず意図した通りに動くものを作ったり、あるいはそのような仕組みを構想したりすることは、シンプルな解法にたどり着くための第一歩であり、これを速く実現することがその後の試行錯誤の時間を産み出すのは言うまでもありません。その時間は、設計や実装を見直してコードの品質を高めることにも使えますし、あるいは、社内の他のメンバーやお客様からのフィードバックを得てユーザー体験の面で改善を行う猶予にもなります。
つまりどうやら、これらはトレードオフではなく、むしろ「速度が品質を産み、品質が速度を産む」というサイクルが存在しているように見えます。
二者択一のように語られていながら、実は相互に正の影響を与えあっている ────── ソフトウェア開発に限らず、世の中には似たような例がいくつかあるのではないかと思います。
ではなぜ、それらを相反するもののように捉えてしまうことが多いのでしょうか？これは僕の仮説ですが、「速度を産むほど十分な品質を作ることも、品質を産むほど十分な速度を作ることも、単純に難しいから」という一面もあるのではないでしょうか。速度を産むための品質、つまり明快な設計やシンプルな仕様整理は、経験や試行錯誤の結晶であり、きっと誰もが簡単に考え出せるものではありません。そして品質を産むための速度も、個人の圧倒的な思考力と実装力、あるいは開発チームとしての綿密なタスク整理と徹底的な合理化によって支えられるものです。
estie では、「速度が品質を産み、品質が速度を産む」というサイクルは、もはや手の届くところまで来ているように感じます。4-5 月頃、僕の所属しているチームが関わるプロダクトは設計上の大きな転換点を迎えていました。新たなお客様のご要望、そしてビジネス上の理由から、データモデルの設計を大きく変更する必要があり、それに合わせて一部の技術要素を置き換える必要があったのです。プロダクト全体にまたがるこの改修の計画は、それゆえにいくつもの負債を浮き彫りにもしました。そして、これらを完全にやりきり、お客様に提供できるようになるのは早くても 7 月末か 8 月だろうと見積られていました。しかし、一方では何度も設計変更案を作っては懸念を洗い出して磨き上げ、もう一方では怒涛の勢いで技術要素の置き換えを進めながら、さらに価値提供に必要な改修範囲を適切に絞り込み、必要な作業の流れを整理してチーム全体の実装力を活かしきるといった多方面の努力により、この大きな改修は 6 月末にリリースできました。そしてそれは、チームとプロダクトに時間的猶予をもたらし、積み上げられた負債解消やオペレーションコストの軽減を一気に進め、コードとプロダクトの品質を高めることへと繋がりました。そして今、チームの次の展開へ向けての準備が整いつつあります。
思えばこれまでの人生でも、二者択一を選ぶことは苦手でした。それが優柔不断なのか、欲張りなのかは分かりません。A と B の分配は、A も B も増やす方法を真に考え尽くしてからやればいい。世の中は、まだその限界には行き着いていないと、僕は感じています。もちろん、両方を追いかけること、両方を諦めないことは簡単なことではありません。簡単なのであれば、誰も二者択一なんて考えないでしょうから。それでもその方法を考え抜くことが、一つの信念であり、estie というフィールドで挑むことのできる一つの挑戦なのだと思っています。シンプルで、それゆえに難しい理想を、いつか形にする日まで。
