「人数半減の中で総開発量UPを実現させた秘訣 by エイチームコマーステック Advent Calendar 2023」の8記事目(18日目)は村林がお送りします。よろしくお願い致します！
我々は少数人数でエンジニアを運営しています。トータルの工数が少ないため、当然やれることが限られてしまいます。
今までご紹介してきた効率化によってやれることは増えましたが、それでもすべてのやりたいことを実施するのは困難で取捨選択が必要になります。
今回の記事ではその取捨選択で重視している考え方の一部をお伝え出来たらと思います。
負債と工数のバランス
何らかの開発をするときに設計Aだときれいだけど開発工数がかかる、設計Bだとわかりにくいけど開発工数が短縮できる。このような選択で迷ったことはありませんか？
エンジニアであれば自分たちの作品(=ソフトウェア)をきれいに保ちたいという心理が働くでしょうから、開発工数が多少かかっても後に負債を残す設計にはしたくないという心理はあるでしょう。
一方で我々はビジネスの観点から見れば、早くユーザに使ってもらうということが重要であり、開発工数短縮が重要事項です。
この「負債」と「工数」はそれぞれ対立します。どちらが間違っていてどちらが正しいか？というのは一概に言えるものではありません。
「負債」と聞くと何やら悪いもののように聞こえますが、必ずしもそうではありません。前述したとおり負債を許容することで開発スピードが上がりビジネスが加速し儲けにつながる場面も存在します。一方で、負債の種類や量によってはその後の開発スピードを大きく落としてしまったり、重大な不具合に繋がるようなものもあります。
我々は少数組織であるため負債を完全につぶすために時間を使っても、負債がたまって開発効率が落ちても、問題が致命的になってしまいます。つまり、うまく負債を使えるかどうかで、ビジネスが加速するか、衰退するかがかかっています。
まず、我々の組織では「許容すべき負債」と「許容すべきでない負債」があることを全員の共通認識としました。
そのうえでこのような選択のシチュエーションが発生した際に、徹底的に議論をすることにしました。幸いなことに以前のお伝えしたコミュニケーションの改善でこれらのことが非常に気軽に話せるようになっていたので、多くの選択を抜けもれなく話すことができています。
またこれから開発しようとしている機能が一時的なものなのか、利用が拡大していくものなのかで大きく判断が変わる可能性もあります。場合によってはビジネスを考えている非エンジニアメンバーからの意見も募りながら判断をしています。
ソフトウェア規模を抑えるということ
当たり前の話ですが、規模が大きなソフトウェアになればなるほど、追加開発や管理の工数が増加していきます。これらを小さく保つことが少数組織で運営する一つのカギになります。
使っていない機能や、コードを削除するのは当然行います。負債の話を前述しましたが利用していないコードがあるのは許容すべきでない負債だと認識しできる限り早く対処を行っています。そのコードが生んでいるビジネスインパクトが全くありませんし、比較的対応が容易であるためです。コードの削除は静的解析やE2Eの整備もしたので気軽に行うことができるようになっています。
使っている機能やこれから作ろうとしている機能の見直しも必要だと考えています。利用価値の低いと思われる機能や他機能と統合できそうな機能は対応します。当然利用している方々がいるため、エンジニアの独断では判断ができません。そのためビジネスの方針を考えているメンバーへ機能を消したいという話をエンジニアからしに行きます。
これらのことを行ったことで、機能開発も当然続けていたにも関わらずソースコードの増加量に変化がありました。
これまでフロントエンドのコード行数は単調に推移し続けてきましたが、このような意識に改めたことにより減少傾向へと変化しました。
今後も増加と減少を繰り返しながらなるべくソフトウェアを肥大化させることなく運営していくことで、少人数組織でも開発し続けられる環境を目指していきます。
最後に
我々のような少数組織ではすべての開発を理想通り行うことは困難です。そのため一定設計においても、要件においても諦める必要が出てきます。何を諦めるかはエンジニアだけではなく、ビジネス観点の考えも持たないと判断を失敗してしまいます。エンジニアとビジネスを考えているメンバーの距離を近くにすることで、ビジネスを考えているメンバーの話を気軽に聞けますし、エンジニアにも様々な情報が入り自力での判断もしやすくなります。
今回の記事では諦めることも重要という話をしました。次回記事ではより具体的にやめたことやその理由を紹介する予定です。
ご興味ある方はぜひご購読をお願いします！