私達まともなソフトウェアエンジニアは、まともなソフトウェアを作ろうとする。ソフトウェアエンジニアには、アプリのエンジニアだったり、サーバーサイドエンジニア、リサーチエンジニアなども含む。
まともなソフトウェアエンジニアは、テストコードを書く。ドキュメントを書く。CIも整備する。まともなクラス設計を考える。スケールするDB設計をする。ここでは、「まともなソフトウェアエンジニア」を「優秀なエンジニア」と定義し、「テストコードがあり、ドキュメントがあり、CIも整備され・・・」なソフトウェアのことを「まともなソフトウェア」と定義しよう。
つまり、優秀なソフトウェアエンジニアは、まともなソフトウェアを作る(※必要条件)。
まともなソフトウェアを作るのは、時間がかかる。テストコードを書けば、それだけ時間がかかる。クラス設計を議論しても時間がかかる。
なぜ私たちはまともなソフトウェアを作らないといけないのか。
もちろん「まともなソフトウェアを作ってない会社に勤めたくないから」とか「単純に作るべきだと思うから」というのも理由としてあるし、実際それは正しい。「まともなソフトウェアじゃないと品質低くて提供できないでしょ」も正しい。けど、もう少し深掘りしながら、なぜまともなソフトウェアを作るべきかを考えてみたい。
私たちはまともなソフトウェアを作るべきで「ない」のか
まずは逆説的に、まともでないソフトウェアを作る場合のことを考えてみる。
まともでないソフトウェアはテストを書かなくていい。CIも整備しない。ドキュメントは書かない。クラス設計は適当。DBも逐次てきとーに作っていこうか。議論も不要。コードレビューもやめよう。
まともでないソフトウェアを作るのは、余分な時間をかけずに済みそうだ。まともなソフトウェアを作る金が100万円だとしたら、まともでないソフトウェアは30万円くらいで作れるかもしれない。
やったね! どうやら、まともでないソフトウェアを作るべきみたいだ。
まともでないソフトウェアの問題点
まともでないソフトウェアの問題点は明確だ。
まず、テストコードが書かれていない。テストコードのないソフトウェアの品質は良くないだろう。将来の改修でデグレ(過去、動いていたものが動かなくなること)を起こすかもしれない。試していなかったパターンでエラーが起きるかもしれない。
CI環境も整備されていない。つまりデプロイは毎回手動でやらないといけない。ミスが起きるかもしれないし、デプロイするたび時間がかかる。
レビューも設計もないので、コードの品質もひどい。それでは後から入った人が困るだろう。どんどんクラスが肥大化していって、改修もしづらくなるかもしれない。
まともでないソフトウェアの問題点の問題点
ここまではあたりまえ体操だが、もう一歩うがった見方をしてみる。果たして、まともでないソフトウェアの問題点は、本当に問題なのか?
テストコードが書かれてないと、どれくらい困るだろうか。人によって意見が異なるだろうが、自分の経験上、完全に一人で作っている場合や、運用を考えなくていい場合、テストコードがなくて困ることはあまりない(※完全に一人かつ運用を考えないというのは、かなり限定的な条件だ。つまり一般的には必要だと考えている)。要は、自分個人の記憶以上にスケールする必要がないとき、テストコードはなくても困ることは少ないと思う。
CI環境がないと、困るだろうか? これもサーバー規模があまり大きくなければ、正直あまり困らない。例えば、ssh して、git pull して、restart かければ良い。もしくは、自分の手元からそれらを自動化する簡単なシェルスクリプトがあれば、時間もかからない。
コード品質は、一人で作っているときであれば、気にしなくても短期的には困らないものの最たる例だろう。オレオレ設計は、オレの中で最大級にスケールする。
要は、短期的に一人でやる場合であれば、まともでないソフトウェアを作ってもあまり困らない、というのが正直なところなんじゃないかと思う(だから私含めてみんなサボるんだ……)。
なぜ、まともなソフトウェアを作るべきなのか
ここで「なぜ私たちはまともなソフトウェアを作るべきなのか」という疑問に対する私個人の答えを言うと、チーム開発を円滑にするためであったり、長期的に運用するため、ということだ。
「チーム開発を円滑に」というのは、今現在一人で作っている場合にも当てはまる。「長期的に運用」というのは、作り始めでも当てはまる。本当に今作っているソフトウェアを成長させたくて、人を増やしてチームを大きくしたくて、一年後もコードを書いていたいなら、やっぱりまともなソフトウェアを作るべきなんだと思う。そして、「チームのため」という目的のためにこそ、あるいは「チームのため」という目的を意識しながら、まともなソフトウェアを作るべきであり、まともなソフトウェア開発は、チーム開発に還元されるべきであると思う。
逆に言えば、まともでないソフトウェアを作ろうとしているのであれば、それはチームを大きくしたくないということであり、今後運用したくないということだと思う。
何故こんな疑問を書いたか
冒頭に言ったとおり、まともなソフトウェアを作るのは時間がかかる。まともでないソフトウェアは時間がかからない。(本当に優秀なエンジニアは、まともなソフトウェアを短時間で作るだろう、というツッコミは置いておく)
まともなソフトウェアを作りたいが、実際のビジネス要件は「早く、早く」であることも多い。そのためには単純に、テストやCI、ドキュメント、設計に掛ける時間を削ることもできるだろう。けれどもそれを安直に受け入れていいとは、どうしても思えなかった。
裏返して、ビジネス的視点で考えたとき、「僕がまともなソフトウェアを作ろうとするのは、どう正当化できるだろうか?」という疑問があった。だって自分が経営者だったら、速く成果物を作る人を評価するでしょ?
そういったバランスの中で、「なぜまともなソフトウェアを作らなければいけないのか」を考えることで、適切に“まともさ”にこだわることができるんじゃないかと思った。
まとめ
- まともなソフトウェアを作るのは時間がかかる
- チーム開発や運用を考えるならば、まともなソフトウェアを作るべきである
- というか、「チーム開発や長期的な運用のため」を意識して、まともなソフトウェアを作りたい
補遺
こんなことを書くと、「経営者はまともなソフトウェアを書かせろ!」とか「おいあいつまともなソフトウェア書いてないじゃないか」とか「まともなソフトウェアはわしが育てた」とか言っているかのごとしですが、そういうのは全くないし、一切の皮肉を含んでいません(汗 あくまで、自分が開発する上で何考えないといけないんだっけ、っていう思考の出発点のつもりです。
ちなみに自分がいるプロジェクトは、テストコードがあって、後からジョインしたら大変助けられたパターンです。