オブジェクト指向設計実践ガイドの輪読を始めてよかったこと

こんにちは。
石坂( @8miri_dev )です。

COUNTERWORKSのエンジニアチームで、オブジェクト指向設計実践ガイドの輪読を4月から始めました。

2ヶ月ほどやってきて、やってきて良かったと感じる部分が多くあるので、どんな意図で始めたのか・やり方・実感している効果等についてをご紹介します。

・なぜオブジェクト指向設計実践ガイドの輪読を始めたのか
・どんな風にやっているか
・実感している効果

なぜオブジェクト指向設計実践ガイドの輪読を始めたのか

最初のきっかけは、エンジニアメンバー内で「良い設計について学びたい」という声があがったことでした。

これはスタートアップあるあるだと思うのですが、立ち上げ時から少人数でゴリゴリと速度重視でコードを書いてきた時期が長かった経緯もあり、正直に言ってプロダクトの内部コード品質は高い状態ではないのが現状です。

事業の成長に伴って、開発人員も増え、継続的にユーザーへ価値提供し続けるための技術戦略もきちんと考えていく必要が生じてきた中で、チーム内でも「少し設計・コード品質をあげていく方向性に頭をシフトする必要があるよね」という話が度々出るようになっていました。

また、チームで開発しているプロダクトにおいて全体の設計・コード品質を保っていくためには、突出した個人がいるよりも、チームメンバー全員の設計・コーディングスキルを底上げしていくことがポイントになると考えています。

弊社では、品質重視の組み込み開発の現場でゴリゴリと設計の原理原則を学んで実践してきたメンバーもいれば、Webの現場で実践的な面を中心に取り組んできたメンバー、出自がフロントエンドで設計やオブジェクト志向には比較的あまり詳しくないメンバーがいたりと、メンバー間での設計・コード品質に関するスキルにはバラつきが大きい状態でした。

そういった背景があり、チームメンバー全員の設計・コーディングスキルを底上げし、かつ共通認識を形成することで開発・レビュー等を効率的に行えるようになるために、設計・コーディングに関する輪読会をやることにしました。

「オブジェクト指向設計実践ガイド」を選んだのは、良い設計を学ぶにはオブジェクト指向を学ぶことが近道であると考えたことと、弊社の開発言語がRuby/Railsであるため、Rubyコードで学ぶことで現場ですぐに実践可能になるためです。

どんな風にやっているか

下記のような形で回しています。

・担当は毎週持ち回り制

特定のメンバーがまとめる形にすると負荷が偏ってしまったり、当事者意識に差が出てしまったりするため、担当は持ち回り制にしています。

・各章の内容をまずkibelaにまとめる

本の内容をkibelaにまとめるのですが、そのまままとめるだけではあまり意味がないので、可能な限り社内プロダクトのコードを引用して良いパターンやアンチパターンについて説明するようにします。こうすることで、より実践的な理解ができ、アンチパターンについてはその後プロダクトの修正をそのまま進めることもあります。

kibelaにまとめるのは、後に参照できるようにするためと、オブジェクト指向設計実践ガイドは少し訳文が読みづらいので、より簡潔に理解しやすい内容に噛み砕くためです。

・まとめた内容について、全員で議論する

ソフトウェアの設計は絶対の正解があるわけでなく、一定の正解らしきゾーンはあるものの、ゾーンの中でどのポジションをとるかは、思想の違いによって時に宗教戦争のようになってしまうことがあります。これにより、レビュー時などに思いもよらぬコミュニケーションコストが発生することもあると思います。
そういったことを防ぐために、本の内容をたたき台にしてCOUNTERWORKSの設計としてのあるべき姿について、全員で議論します。

輪読はただ本の内容をまとめるだけでなく、全員であるべき姿を議論するプロセスを経てより実践的な知識になり、それを経て初めて業務において効果を発揮できる状態になると考えています。
ここで話した内容は、社内のアーキテクチャ指針や設計方針等の資料に反映しています。

実感している効果

今のところ、下記のような効果を実感しています。

・チームメンバーの設計やコーディングの品質が向上した

エンジニアチームには、COUNTERWORKSに入社してからバックエンド開発を学んだメンバーがいるのですが、特にそのメンバーは設計に関する知識が飛躍的に向上しました。
これにより、設計・コーディングの議論やレビューにおいて、コミュニケーションがスムーズになる効果が出ています。

また、現場で経験を積んだメンバーと一緒に実践的な議論をしながら学んでいるため、ただ本から知識を吸収するだけでなく、時には本に書かれている内容への反対意見や、本には書かれていない周辺知識なども聞けることで、独学で学ぶよりも実践的な形で身についていく印象があります。

・プロダクトコードに潜んでいる問題が見つかりやすくなった

その回のテーマに合う形で現場のプロダクトコードを引用して説明するようにしているので、現場のコードに潜む問題を見つけ出すことに役立っています。日常業務の中でも「あ、これはこの前やったアンチパターンだ」と気付きやすくなるため、コードの改善が進むようになりました。

また、どう解決するべきかもその場で議論して決めるので、解決までの速度も上がります。感覚的にはペアプロみたいな感じですね。

・開発モチベーションがわく

普段の業務はアウトプットを出すことに注力していることがほとんどですが、インプットが増えることでその知識を使ってみたい欲もわくため、結果的に開発そのものに対するモチベーションの向上につながっているという意見もありました。

まとめ

輪読はエンジニアにとっては一般的な取り組みだと思いますが、チームの状況に合わせた本を選んだり、実践と紐づくようにやり方を工夫するだけで、大きく成果が変わるなと思いました。

「オブジェクト指向設計実践ガイド」の輪読が終わった後は、DDD本(エリック・エヴァンスではなく、実践ドメイン駆動設計のほうです)の輪読をする予定なので、より変化に強い柔軟なプロダクトを目指して、設計力を向上させていきたいと思います。

COUNTERWORKSのエンジニアブログはこちら

Twitter( @8miri_dev )です