※この記事は「COUNTERWORKS Advent Calendar」の2日目の記事です。
株式会社COUNTERWORKSで2018年8月から業務委託として、2019年1月から正社員として働いているまったんです。
業務委託時代を含めると5年以上在籍している私は、現在最古参のソフトウェアエンジニアとなりました。
そんな私がカウンターワークスで働き始めた当初と比較して、組織として保守性の高いコードを書けるようになってきたと思うので、これまでに組織として行ってきたことについて紹介します。
この記事では次のような状態の方を対象者と想定しています。
- より保守性の高いコードを書いていきたい気持ちはあるが、どうしたらいいのか全くわからない
- 組織における良いコードの定義がぼんやりしていて、モヤっとしている
- 自分だけはなく組織として成長する必要があると考えている
保守性を高めていこうとした経緯
入社してからしばらく以下のような問題を抱えていました。
- ちょっとした仕様変更なのにコードはたくさんの変更を強制される
- ある変更をしたら思いもよらないところでバグが生まれた
- コードの理解が難しく何をするにも時間がかかる
おそらく殆どの組織で一度は似たような問題を抱えたことがあるようなものだと思います。
これらの問題の要因を探ったところ、コード品質に依るものと、そうではないものに分けることができました。
コード品質に依る問題はエンジニアだけで解決することができ、問題意識を持ったその日からでも少しずつ改善していけることから、組織としてコード品質を上げていこうとしました。
取り組んだこと
保守性を高めるために取り組んだことはざっくりと3つあります。
保守性を高める大義名分を考えた
組織として今までより保守性を高めるということは、エンジニアにとっては学習や不慣れなことをする負担が増しますし、一時的に生産量が落ちるためプロダクトオーナーや経営者にとっては短い目で見るとメリットがありません。そのため、大義名分がないと仲間が増えず、保守性向上を推進することが難しくなると思い、まずは大義名分を考えました。
当時は以下のように整理しました。
保守性が高いとコードを理解するのも変更するのも簡単になる
=> 時間あたりの生産量を高めることができる
=> ユーザーにも多くの価値を速く提供でき市場で優位に立てる
=> 売上の増加・給料の増加につながる
皆さんが大義名分を考える際には以下のt_wadaさんのスライドが役立つと思います。
結果として誰にも保守性を高めたほうがいい理由は聞かれず、私が良いと思うならやろう！と言ってくれましたが、仲間を増やす、他社に理解してもらう上では大義名分は用意しておいて損はないと思います。
知識を得ることを強制した
保守性を高めることは長い目でみないとメリットを感じにくいです。ほとんどの人間は短期的に利益を受けられないことに対して努力することは難しいと私は考えているので、本を渡して家で読んでおくように頼んでも、読んでもらえないと思いました。そのためマネージャーにエンジニアで読書する時間を作る許可をもらい読書会を開催しました。
読書会は週に一回一時間確保し、全員で同じ本を読み、1章読んだら各々の解釈を言い合ったり、コードを見せながら実際に知識を活かせるケースを確認したりして、全員で同じ知識を同じ解釈ができるように努めました。
本によっては、それなりの前提知識がないと理解が難しかったり、解釈が異なってしまう可能性のある記述・内容も少なくないため、解釈を統一するように意識したことはかなり良かったことだと思います。
良いコードのイメージを統一した
読書会も良いコードのイメージを統一することに通ずるのですが、良いコードとはどんなコードなのかというイメージ・解釈が組織内で似通っていないとコードを書く際もレビューする際も負担が大きいと考え、良いコードのイメージを統一しました。
私達は高凝集で自己記述的で情報・知識を閉じ込めたコードを書くことを重要視し、そんなコードの解像度をあげるために、読書会のあとに一週間の振り返り等を行う時間を設けました。
振り返り等の時間では、自身が受けたコードレビューで素晴らしいと思ったものを共有したり、自身が書いたコードがどうしたらもっと良くなるかわからないものを共有して意見をもらったりすることを行いました。
素晴らしいレビューの共有は、組織としてコードレビューの力を向上させることもできるし、共有された人も誇らしい気持ちになれるので非常に良いものでした。
また、新規メンバーが加入する際のオンボーディングでも、高凝集で自己記述的で情報・知識を閉じ込めたコードを良いコードの定義として伝えるようにもしています。
取り組みの効果
定量的に比較できてるわけではないのですが、様々な改善があったように感じます。主な改善点は以下です。
- コードの書き方で迷っている時間がかなり削減できた
- レビュー開始からマージされるまでの時間がかなり速くなった
- スプリントのベロシティが上がった
新卒1年目のメンバーは基本的にコードの書き方で迷って時間を溶かしたり、レビューでたくさんの指摘をされてマージするまでに数日かかるといった状態が数ヶ月続いているという問題を抱えている組織は少なくないと思いますが、弊社では新卒1年目のメンバーはチームに合流して1ヶ月ほどで自走できる状態になっています。
おわりに
保守性を高めることは良いことがたくさんあります。
スプリントのベロシティが低いと悩んでいる方、部下からリファクタリングしたいと言われているけど効果がわからなくて許可できていない方、コードを書くのに苦しみを伴っている方、この機会にぜひ保守性を高めることにチャレンジしてみてください。
We are hiring!!
COUNTERWORKS では一緒に働く仲間を絶賛募集中です。
今後の更なる成長のためには圧倒的に仲間が不足しています。皆さまのご応募お待ちしております！
ポップアップストアや催事イベント向けの商業スペースを簡単に予約できる「SHOPCOUNTER」と商業施設向けリーシングDXシステム「SHOPCOUNTER Enterprise」を運営しています。エンジニア採用強化中ですので、興味ある方はお気軽にご連絡ください！ counterworks.co.jp/
Discussion