はじめに
こんにちは、初めまして、エンジニアのかどたみです。 弊社では顧客体験や従業員体験を改善するためのソリューションを提供するクラウドサービスEmotionTech CX・EmotionTech EXを提供しています。 機能追加を行いながらおかげさまで様々なお客様に使っていただけるようになっています。 しかしながら、開発当初、お客様の期待に応えるため機能の充足とスピードに重きを置いていたが故に技術的な負債が積み上がり、日を重ねるごとに機能修正、機能追加にかかるコストの増大と心理的安全性の欠如が問題となっていました。
- そもそも既存コードの仕様がわからない
- どのプログラムに何の処理が書いてあるかわからない
- 自動テストがない
- テストが存在し、変更後も通っているのにバグがでる
これらの課題についてこころあたりのある方や、担当のサービスが今まさに直面しているという方もいらっしゃるのではないでしょうか。 私もEmotion Techに転職してすぐにこの課題に直面し、開発することへのモチベーションを保つのが難しくなりました。そこで、設計の改善を行い、チームメンバーの多大な協力を得ながらなんとか、成功体験と言えるものが掴めたので、本記事ではこれらの課題解決のために行ってきたこととその結果、今後の課題について紹介していきます。
- 担当プロジェクトの設計に問題があると思っている方
- レガシー改善をしたいが、何から手を付ければいいかわからない方
このような方へ少しでも助けになれば幸いです。
何をしたか
配属当初、自分がバックエンドを主に開発していたのとチームの問題意識が強かったので、バックエンドの設計に関しての改善をやっていくことになりました。改善実行に至るまでの経緯と実行時の流れを紹介します。大きくまとめると以下になります。
- 設計に関する疑問点をチームで共有し、アクションを決めた
- 叩き台を作るためのインプットとそれに基づくアウトプットをした
- 議論を重ねてルールを明文化した
- 機能を実装してルールの疑問を解消するコードレビュー会をやった
一つずつ簡単に振り返ってみます。
設計に関する疑問点をチームで共有し、アクションを決めた
まず、現状の確認をするために配属時に感じた疑問点をミーティングで共有することにしました。
- どこに何が書いてあるかわからないので困っていること
- 社内資料のどこかに設計のルールがあるのかないのか
すると、他のチームメンバーも同様に困っていることが判明し、自分が認識していなかった課題もいくつか発覚しました。
- そもそも仕様を表すドキュメントがなく、修正、追加に時間がかかること
- 自動テストが網羅的ではなく、エラーが出ないことしかテストされていないものが存在していること
- 現状の設計に疑問を覚えたり、不安を抱えながらリリースしていること
設計に課題があって工数がかかるだけならまだしも、疑問や不安を抱えながら仕事をしなければならない状況は「すべての人々がイキイキと働ける世の中を創る」という弊社のミッションに反するものであり、絶対に解決しないといけないものだとも思いました。 チームメンバーからも設計改善はやっていった方が我々の心理的にも良くなると思うし、事業の成長スピードについていくための投資としては大事だという賛同する意見がもらえたので、着手することになりましたが、課題が洗い出せはしたものの、すぐに改善できるような状況ではなく、既存のコードをリファクタリングして機能改善をストップさせることは難しそうでした。 そこで、私が当時着手していた独立した機能を叩き台として設計改善をしてみるのが良いのではないかという結論に至り私がスタートを切ることに！
叩き台を作るためのインプットとそれに基づくアウトプットをした
今までも設計については意識してはいましたが、自分でいざルールを作ってみるとなると迷いがたくさん生じたので、設計についての記事や書籍(※1)を読み漁りました。 インプットを経て進行中のタスクに自分の考えた設計パターンを適応し、タスクが完了した後、社内のドキュメントとして以下を展開しました。
すると、悔しくも嬉しい反応が、、、！
「やりたいことはわかりますが、もっとこうした方が良いと思います。」 なんと経験豊富なシニアエンジニアの方がさらに細かい案を丁寧にまとめてくださったのです！ そこから動き出すために決めるべきことを抽出して議事録を作り再展開し、議論を始めることとなりました。
議論を重ねてルールを明文化した
まとめていただいた資料をもとに以下について細かい認識のすり合わせを行いました。
- 設計について
- コメントの書き方
- ディレクトリ構成とプログラムの責務
- ある責務のプログラム内に書いてはいけないことの例
- テストをどのように書いていくか
- 各責務に対するテストすべき項目
- テストの説明事項の書き方
- テストを読めば仕様が分かるようなテストの書き方
- 既存機能のテストはどうするか（結論：既存機能は修正点の使用を満たすテストのみを追加することに）
- 今後どのように進めていくべきか
結局先のミーティングの通り、既存のコードをリファクタリングして機能改善をストップさせることは諦め、新規機能開発から新たなルールを適応していくこととなりましたが、実際に書いてみないとわからないことや不明瞭な部分は無理にルールを作るのは辞めました。なぜなら、始めから完璧なものを目指そうとするよりも手を動かしつつ議論しながらブラッシュアップさせていった方が良いという結論に至ったためです。 議論の後、改めて簡単なコード例も追記して再展開し、メンバーから決まったことの抜け漏れなどの指摘をいただき叩き台が完成しました。 さらにありがたいことに、社長とPMからこれらの課題解決の理解が得られた上で工数の調整もいただけたため、新しいルールに沿った開発を行っていくことになります。
機能を実装してルールの疑問を解消するコードレビュー会をやった
チームメンバーが新機能に着手し、一通りの実装ができてきた段階でメンバーからの提案でコードレビュー会を行いました。レビュー会と言っても、ざっくばらんに話す形式で以下を目的としています。
- 実装の意図の共有
- 現行のルールでの不明点・不安点の明確化
- 以前の議論で決めきれなかったテストの細かい書き方について確認
- 上記をもとに設計ルールをブラッシュアップ
レビュー会は実装者一人につき１時間ほど行われました。もとの設計に問題があることが明確に共有できていたことで、何にも囚われることなく議論できましたし、同じ過ちを繰り返さないために些細なことでも確認しておいた方が良いという雰囲気があり不明点を共有しやすかったと思います。 この会によってかなりルール上の曖昧なものがかなり解消され、完成してからレビューするよりも手戻りも少なくなったと思います。
始めから完璧なものを目指そうとするよりも手を動かしつつ議論しながらブラッシュアップさせていった方が良いという結論に至った
にも関わらず、次のアクションに踏み出せていなかったのでこの提案には本当に感謝しています。
これらの流れを経てコーディングルールのver.1が完成し、メンバーはルールに則りコーディングを行っています。
結果
この取り組みによって、チームとしての状況は改善の方向に向かっていますが、もちろん実行していく中での反省点もありましたので、改善できた点や反省点などを挙げておきます。
改善できた点
- コードもテストも迷う部分が減ったため単純に開発スピードが上がったこと
- テストの説明を読めばプログラムの仕様が分かるようになったこと
- レビューをする際も迷いがなくなり、レビューで指摘されたことに対しても納得感が出るようになったこと
- 既存機能の修正時もテストの書き方が明確になっているのでカバレッジが上がり、バグが出にくくなったこと
実行してみて良かった点
- メンバー全体で課題が明確になりメンバーの向く方向が一致し、一体感がでたこと
- 自ら考えながらインプットとアウトプットをして、さらにそれをブラッシュアップさせる案を出していただくという経験ができたことで自らの成長と未熟さを実感できたこと
- 始めから改善ありきで議論が進んでいたため、意見出しの敷居が下がっていったこと
反省点
- ほぼ機能が完成の段階からレビュー会で決まったことを適応するのは手戻りが多かったため、レビュー会を1要素が完成したら開くなど、早めに行えれば良かった
- ルールは文章で決まっていたものの言葉だけでは迷いは生まれるので実装例をもう少し早い段階で増やせれば良かった
- やはりリモートという中で、ルールで決まっていないことの情報共有が遅れていることがあったので、定期的に進捗とどのような方針で開発しているか共有できれば良かった
この取り組みを通してチームの文化として成り立っていったもの
前項の良かった点にも通ずるのですが、この取り組みを通してチームの文化として成り立ってきたものがいくつかあります。
疑問点を一人で悩まず相談する空気ができた
昨今の状況でフルリモート勤務となり、改善中は一度も同じ空間で仕事をすることがなかったのですが、疑問点が出たらすぐにチャットで議論をし、わかりにくければすぐにテレビ会議で画面を見ながら課題共有と意見出しを行っています。 先ほどコーディングルールのver.1が完成したと言いましたが、もうすでにver.1の状態ではありません。
- 疑問を共有する
- チャットもしくはテレビ会議で議論する
- 必要があれば追記・修正する
のサイクルが回っているからです。このサイクルが気軽に回せることによってメンバーの心理的負担も解消されてきていると思います。さらに設計以外の課題もわからなければ一人で抱え込まずに共有して解決していくことが根付いてきました。 フルリモートになり、お互いの状況が常時わかる状況ではないからこそこのような文化はとても大事だと思います。
※改善・加筆の続くルールの資料
バックエンドのみならず、フロントエンドやDevOps、インフラ領域にまで改善の波が広がっている
これらの改善を部署に共有したり、レビュー会をチーム外にも公開することによって他のメンバーの刺激にもなっていると考えられます。
このような文化が根付いたことや1つの取り組みから改善が波及していくのは組織としてはとてもよい流れだと思うので絶やさずやっていきたいですね。
結果を踏まえた今後の取り組み
今回ルールを作ったバックエンドも既存の設計はまだまだたくさん残っているので、新しい設計に移行するタイミングなどをみつつテストを書いて行くことはどんどん推し進めていきたいですし、改善することで効果が出ることは分かったのでフロントエンド側の改善も推し進めようと思っています。その際は反省点を生かし、
- 新ルールを適応する際の進捗確認と問題の洗い出しを兼ねて雑談する機会を定期で設ける
- レビュー会も早いタイミングではじめて回数を重ねる
- 実際のコードをルールの実装例として含めてブラッシュアップしていく
を意識して改善していきたいと思います。
あとはせっかくできた文化を絶やさないようにしていくことですね。 実は今回取り決めたルールと同じような設計思想で作成されているプログラムも既存のものに存在していました。しかし、ルールが明文化されていないことによって思想が伝わらず、設計がブレていき秩序のないものになっていったと考えられます。 このことを鑑みると、ルールを作るだけで終わりではないことを痛感していますし、ルールを普及させると共に改善する文化や議論・質問しやすい雰囲気の継承も徹底していきたいと思います。
さいごに
いかがでしたでしょうか？ 機能追加に追われて設計が疎かになるのはよく聞く話ではありますが、実際に改善してみると想像以上の成果が得られます。ここまでの成果が得られたのはチームメンバーの力が大きいのですが、動いてみないことには何も変わらないので、現状の設計に疑問があるのであれば声を上げてみると良いのではないでしょうか。我々もまだまだ改善途上ですが、弊社の知見が誰かのためになれば幸いです。
Emotion Techでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。プロダクトに興味のある方、この記事のような設計改善に関わってみたい方、イキイキと働けるチームでプロダクトをより良くしていきたい方がいらっしゃいましたら、ぜひ採用ページからご応募をお願いいたします。
補足
※1 特に参考になった書籍と記事を記載しておきます。
- Clean Architecture 達人に学ぶソフトウェアの構造と設計 今更紹介するものでもないですが、設計を考える上での基本的な思想がわかりやすく纏まっていて良かったです。
- ドメイン駆動設計入門 Emotion TechではDDDを導入することにはなりませんでしたが、設計の基本となる責務の話やそれに基づく実例が多く大変参考になりました。
- サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ 乱立したサービスクラスは一体なんなのか、これを解決するにはどうすればいいのか考えさせられる記事でした。
