ファインディの4年にわたる技術的負債の返済を読みました。

このスライドでは技術的負債が生まれてた背景として以下が挙げられています。

お金がなかったので 1 回目のリリースが大事だった
新規開発が優先で負債を解消するための採用ができなかった
当初の仕様から大きく変わったときにそのまま機能を利用してしまった

これは、今年プロダクトの 1st リリースを迎えた自分の会社というか自分のチームにとってもドンピシャなことでした。

プロダクトがリリースされていない以上、自分は会社の利益に貢献できていないわけで、言い方は悪いですがタダ飯を食べている状態です。そんな中でいち早く利益を生み出すためにできる限り早くリリースしたいと考えるわけです。しかし、1st リリースには一度にサービス丸ごと（＝たくさんの機能）をリリースするわけなので、「これじゃ上手く動作しない...。これを修正するにはここを直して...となるとここもこうして...」みたいな感じで開発中に仕様変更が多々発生します。となるとやっぱりどうしても妥協した実装やクリティカルではないがアンチパターンと言われるような実装を仕方なくしてしまうことになります。まぁ、これはしょうがないと思っています。中身はどうあれ仕様通り動くものを作って会社の利益に貢献することが大事だなと考えているので。このあたりは自社開発の会社で働くことでより強く意識するようになりましたね。

さて、スライドの中では様々な技術的負債に対して改善策を挙げ、それを実施することで時間はかかったがそれらを改善することができたということですが、エンジニアの数が増えて技術的負債の解消と試作開発を同時に行える体制になったということが負債解消の要因の一つとして挙げられています。

本題

前置きが長くなってしまいましたが、ここから本題！

1st リリースを迎えたらエンジニアリリースはどうするべき？

リリースのために一時的にエンジニアリソースを業務委託等を利用して増やすのはよくあるケースだと思います。1st リリースを迎えれば一旦の目標は達成できたので業務委託を減らしてコストを減らすということも考えられるかと思います。

個人的にはエンジニアを減らすことはあまり推奨されないと思っていて、その理由として

「1st リリースを迎えた = サービス完成」ではない
実装を知る人間を減らすのは危険

があると考えています。

「1st リリースを迎えた = サービス完成」ではない

1st リリース段階のサービスというのは「必要最低限の機能しかない」ということが往々にしてあると思います。つまりこれからは新機能追加や既存機能改修、インシデント対応等をやっていく必要があり、1st リリース時と同程度のリソースは必要であると思っています。さらに、プロダクトを運用してみないと分からない問題も出てきます。例えば、リリース作業時間がかかるので自動化したい、パフォーマンスが悪い部分があるので改善したいなど...

これらに加えて 1st リリース開発時に不可抗力的に積み上がってしまった技術的負債の解消も行いたいわけなのでエンジニアリリースが減るのはサービスの成長の足枷になるのではと考えています。

実装を知る人間を減らすのは危険

1st リリース開発というのは前述の通り仕様変更やそれに伴う「仕方無しの実装」が多々生まれてしまいます。「なんでこの実装になっているのか」という経緯含めてシステムに関する知識を蓄えて人がいなくなってしまうのはチームにとってマイナスであると思っています。どれだけ丁寧にドキュメントを作っていたとしても実際に作っていた人がいなくなるのは辛いです。実際にリファクタリングや既存機能改修では実際にその機能を担当した人がやるか少なくともレビューに入ってほしいところです。もちろんチームメンバー全員にそのあたりを共有できていれば話は別ですが、それにも多少の時間はかかります。

言いたいこととしては、「サービスリリースしたからチーム縮小ではなく、サービスを成長させるためにチームも成長させていきたい」ということですね。

ちなみにこの「チームも成長させていきたい」という点について少し補足すると、「技術的負債の解消と試作開発を同時に行えるエンジニアリソースをもちつつ、ゆくゆくは個々人がフロントエンドやバックエンドなど自分の担当領域を超えて開発や会話ができるようになると良い」という意味です。エンジニアリソースがない中で「チームとして成長するために個々人が分野を超えてタスクをこなせるようになろう！」だとエンジニアの負担が一気に増えてしまい良くないと思っているので、この優先順位は間違えないようにしたいですね。

最後に

自分はマネジメント系の話にはどちらかと言えば興味がないのですが、今回紹介したスライドを見て個人的に思うところがあったので色々書いてみました。

1st リリースの中で積み上がった技術的負債を解消する暇がなく、そのようなコードの上に新機能のコードが積まれていきそれが繰り返されていく...開発者としては心地悪いですし、将来的なデリバリー速度の低下、品質の低下にも繋がってしまいます。

ただこれに全員が気づくのはもう少し未来の話で、スライドでも言及されていましたが、手遅れな展開になる前に「開発もしつつ、少しずつ技術的負債の解消もしていく」ことが必要だと思っています。そのためにも「1st リリースを迎えたから今後の機能開発は 1 st リリースよりは少なくなるしエンジニアリソースを減らしても大丈夫だろう」という考えは捨てて「将来困らないように、新機能開発と技術的負債の解消を並行できるようにメンバーのタスクを調整しよう」と考えられるようにならきゃなと思ったという話でした。

Recent Posts