ECナビ KAIZEN会を実施しました

こんにちは。 ECナビ のコンテンツ新規開発や運用などを行っている @pinkumohikan です。

技術的負債を返済するためにECナビで行った取り組み 「ECナビ KAIZEN会」 が、予想通り効果があったのでその話をしたいと思います。

※ ここでは、開発者のモチベーションを下げたり開発の効率を悪くする仕様や設計、実装のことをまるっと全部引っくるめて、技術的負債と表現しています。使われ続けている = 価値を生んでいるコードに対して「技術的負債とはなんだ!」というご意見もあるかとは思いますが、それについては価値を生んでくれているコードに対してもちろん私たちも感謝しています。一方で、コストを抑えつつ、継続的に開発するためにはこれらを改善する必要があることをご理解頂き、目をつぶって頂ければと思います。

背景

システムは長年拡張、改修されることによって技術的負債がたまります。 システムを継続的、かつ効率的に運用・開発していくためには、技術的負債を返済し、健全な状態に保つ必要があります。

しかし、技術的負債の返済そのものはユーザに対して直接的に価値を提供しないため、返済のために貴重なリソースを割くということに対してエンジニア以外から理解を得られにくかったり、ビジネス的成長と天秤にかけれて返済が先延ばしになることがあります。私たちECナビの場合はまさに後者で、2004年のリニューアルオープン以来、サービスとして成長させることにウェイトを置いた開発を行ってきました。

中長期的なサービス成長のために継続的に開発していくことを考えたときに、このままでは新人が入ったときの教育コストが教える側も教えられる側も大きく、またレガシーな記法や古いライブラリの利用を強いられることによって開発者のモチベーションが低下することが継続的な開発の足かせになる、という危機感が高まってきました。

それ以降、ボーイスカウトポリシーで地道に改善はしてきましたが、10年以上運用し続けられてきたサービスを日々の機会だけで改善しきることは不可能です。そこで、がっつりと技術的負債の返済に取り組む機会として「ECナビ KAIZEN会」を実施することになりました。

なにをやったのか

初めての試みということもあり細かくはルールは定めずに、ECナビに関連するシステム(コード)をビジネス上の優先度一切無視で改善して良いものとして、個人のやりたいこと、やるべきと思うことを自由におこなう時間を設けました。

例えば、

  • 技術的負債返済系
    • 200x年代のレガシーコードをモダンに書き直す (リファクタリングする)
    • スケジュールの都合などで、改善できる余地を残したままリリースしてしまっていた機能 / テストケースを修正・追加する
  • 開発効率向上系
    • よく使う実装をユーティリティやヘルパーとして切り出したり、まとめる
  • その他
    • パフォーマンスの問題が出ていたけどクリティカルでないため放置されていた部分をチューニングする

といったことをやるイメージです。

会のスタンスとしては「未来への投資」なので、今やっておけばいずれ誰かが幸せになるのであれば、どの部分のコードを触るか、どういう風に改善するか、といったことは各自の判断に委ねられます。新卒であろうと同様です。

どのようにやったのか

ECナビ KAIZEN会の実施にあたっては、以下のような要綱で行うことになりました。

(1) 丸一日をKAIZEN会のために使う

  • 一つのことを改善するためだけに集中して時間を使うことが必要
  • 割り込みタスクなどで集中が阻害されることを危惧して、実施日は原則としてミーティングはNG

(2) 終日会議室で作業を行う

  • いつもと雰囲気を変えて見たら効率が上がるかも?という仮説

(3) 改善の大小は問わないが、その日のうちに仕上がるものだと気持ち良いかも

  • 2回目をやるか未定だったので、空いた就業時間で続きをやるとなると後々辛くなりそうなため

関係各所と調整してくださったみなさん、ありがとうございました!

当日は前説として趣旨の説明を行い、それ以降はお昼と振り返りの時間以外は全部作業時間として、KAIZEN活動に勤しみました。

KAIZEN会による成果物については当然、何でもかんでも改善すれば良いというわけでは無く、それが本当に改善なのか、ベストな方法なのかを考えた上で手を動かし、コードレビューを経たあとリリースすることになります。そのため、「こういうのあるといいよね」「この実装のココ、改善できそうだよね」という話をGitHub Issueでディスカッションしたあと、PullRequestが上がってくるスタイルが多かったように思います。

君は何をしたの?

歴史的経緯によってスキップされるようになったユニットテストを修正してグリーンにすることに取り組みました。びっくりするほど地味ですが、個人的にとてもためになったと感じています。

よかったこと

(1) 日常業務で触れないコンテンツに触れられた

  • ECナビほどの大規模サービスになると、日常業務では触れない部分がでてきます。例えば、運用作業の必要のないコンテンツ(機能)などです。サービスの全体像を把握し、仕事の幅を広げる意味では、そういうコンテンツを知ることにも価値があります。

(2) まだ見ぬ青い(グリーンな)未来への第一歩

  • ユニットテストを全走させた時にグリーンではなくイエローになるのは気持ちの良いものではありません。まだイエローのテストはいくつかありま すが、地道に改修していこうと思います。

芋づる式に「せっかくだからここも直したい!」というポイントがでてきて、改善欲を抑えるのはなかなか大変でした。

まとめ

1日間という時間的制約からそこまで大きな規模のことはできませんでしたが、古より伝わりしコードをリファクタリングしたり、テストコードを書き足したり、内部的に使っている開発ツールに機能拡張をしたりといった成果が得られ、技術的負債の返済に間違いなく効果がありました。

技術的負債の返済方法について検討されているかたは、私たちのように思い切って "がっつりと技術的負債の返済に取り組む機会" を設けてみてはいかがでしょうか。

最後までお読み下さりありがとうございました。