空でのプロダクト改善について考えてみた

※会社ブログからのお引越しです。

さいしょに

随所で語り尽くされてることですが、わたしなりの考えをまとめておきます。どうかお付き合いください。

プロダクトの品質とコードの品質について

極端な話、スパゲティコードであってもユーザに価値を提供できているのであればプロダクトとしての品質は保たれていると考えられます。しかし、そのような状態が続く場合のコストを考えた場合、長期的にユーザへ価値を届けるためのスピードはだんだんと遅くなっていきます。

リリース当初はきれいだったコードも、新機能追加や改修といった過程を経て複雑性（改修コスト）は増大していきます。何がきれいで、何が汚いかは個人や組織の考えによって様々ですが、個人的には影響範囲が限定されていることがまず大事だと思います。

DDDやユースケース駆動開発をはじめ、いろいろな設計手法が生み出されてきましたが、目指しているところはみな一緒です。今日も世の中の素晴らしいエンジニアの方々が手法やノウハウを提案し実装されているでしょう。

当初は簡単な修正でも、安易に手を入れることで後々の自分たち（もしくは引き継いでくれた後任者）にのしかかってきます。たとえば以下のような判断をせざるを得ない場合もあると思います。

・修正規模としては小さいのに影響範囲を調べる工数が増えてしまった
・本当は消したいんだけど依存関係がもはやよくわからない状態で、安全のためとりあえずそっとしておいた

この結果、すぐにユーザーに届けられるはずだった機能も、リリースサイクルの期間が昔に比べて増えてしまうことになります。

この時間経過によるコストをなるべく小さく維持し続けることで、プロダクト価値を高める（＝プロダクトの改善）方に注力し、マーケットフィットをさせていきたいわけです。

後で効果が出ることは上の図を見ればわかりますが、目下の空において重要なことはいかにPMFするか、です。いかにコードをきれいにしたところでユーザーに受け入れてもらわなければ本末転倒です。ですが、PMFを達成した後、このプロダクトを同じスピード感をもって継続的に開発できるでしょうか。

地道な努力と、EasyよりもSimpleを

改善は1日にしてならず、とはよく言ったもので、やはり地道なところからコツコツやっていくしかありません。また、簡単にできるからといってその修正が良いというわけでもありません。

パターン1）出し分けを入れたいのでmain()の処理に if を追加するケース。

条件文をメソッドあるいはクラスに分けられないか考えてみましょう。これによって判定処理ロジックの影響範囲を閉じ込めることができます。

パターン2）ある画面に表示されてる一部のモジュールは不要になったのでHTMLから消した。

HTMLから消すだけで十分でしょうか。バックエンドで定義している変数は使っていますか？その変数を出力しているメソッドやモデルはどうでしょうか。今後使うかもという希望は多くの場合叶いません。

こういった簡単な修正も塵も積もれば山となるで大きくなっていくわけです。基本的にはレビューをちゃんとしましょうで済むのですが、こういった行動を意識してやるかやらないかで未来はかなり変わってくると思います。
安易にできる修正よりもこれからのプロダクト開発を行いやすく保っていける修正方法をまずは考え、修正コストが少しかかったとしても実践していくことが大切です。コードの改善は日ごろの開発で吸収し、プロダクトの改善に時間を割きましょう。

どれくらいの時間を払うのか

見直しを始めると時間がいくらあっても足りません。現状のスピードを維持しつつコードの品質も保っていくためにはどれくらいの時間をリファクタにあてればよいのか。
正確に測ってはないですが工数の10％くらいをあてることが多いです。1週間でつくるものであれば半日程度です。幸いにも空は1分1秒を急いでリリースするような文化はなく、リリース日は”来週の水曜あたり”と少し濁してコミュニケーションしているのでなせる業かもしれません。
仮に10％で収まりきらない大きな負債と戦う場合は、10%の時間でできる分を削りましょう。そこをやれるだけのリソースはまだないですが、放置しないということが重要です。
（ただ、人数が多いわけではないのでみなさんの力をぜひ貸していただきたい）

さいごに

普段の開発の中で最善を尽くそう！ということでした。
現状での主役はあくまで「開発」という行為であり、その一環として改善もしていこうねというスタイルでやっています。
気になった方、共感していただいた方、力貸してもいいよという方、ぜひ仲間になってください！