PHP Conference Japan 2019 でチームに設計を取り入れた話についてLT登壇しました

これは エキサイト Advent Calendar 2019 の9日目の記事です。

はじめに

先週の12/1(日)に PHP Conference Japan 2019 があり、そこでチームにクリーンアーキテクチャっぽい設計手法について導入してみた話でLT登壇してきました。

そのときの総合的な(?)内容に関しては前回ブログを書きました。 ohshige.hatenablog.com

社内等でのLTはよくやっていて好きな方ではあるのですが、外部の大きなカンファレンスに登壇するのは初めてでした。

経緯

これまではLTであれ登壇は一切考えていなかったのですが、同期が登壇したり、弊社に技術カンファレンスの文化を根付かせようと後輩が一生懸命が頑張ってくれたり、そういう風潮になってきたので、「俺もやりたいぞ」と考えるようになりました。
そんなこんなで、プロポーザルを出して無事に採択されたので、登壇することになりました。

その後輩の文化形成の頑張りはこちらにまとまっています。 qiita.com

「運用経験ばかりのメンバーと新規開発で初めてしっかりと設計から開発までを経験した話」

LTの内容はこちらです。

新規開発の際にクリーンアーキテクチャを導入するためにチームで取り組んだことを紹介するような内容で、詳細なクリーンアーキテクチャの設計論に関しては発表していません。

背景

しばらく前に「cocorus」というリラクゼーションアプリをリリースしました。
これは寝たまんまヨガというアプリをフルリニューアルしたアプリで、裏側としてはほぼ新規開発と同じような感じでした。

今回の話は、このcocorusアプリのAPIを作成したときの話です。

なぜ取り入れようと思ったのか

せっかく新規開発をするなら、これまではしっかりとやってこなかった設計をしっかりやれたらと思ったのがきっかけです。
これまでは既存サービスの運用・開発が多く、どうしてもファットコントローラーになってしまい、密結合でテストが書きづらいものばかりでした。
このようなアプリケーションとは決別したいという思いが強く、Webの世界やDBとの分離をしっかりと行い、本質的な処理に集中できるような設計にしようとチームメンバーを説得しました。

そこで出てきたのがたまたまクリーンアーキテクチャでした。
そのため、クリーンアーキテクチャだったのは本当に偶然で、上述した通り基本的にはポート&アダプターの思想であれば良く、もしかしたらヘキサゴナルアーキテクチャや独立したコアレイヤーパターンなどになっていたかもしれません。

チームに受け入れてもらうために何をやったか

チーム発足時にクリーンアーキテクチャの良さを熱烈にアピール

本質的な処理に集中できたり、テストが書きやすくなったり、なぜクリーンアーキテクチャを採用すると良いのかということをアピールしました。

全エンドポイントのモックを事前に作成

リリース日は決まっていてアプリサイドの実装ももちろんあるので、事前に全エンドポイントのモックを作成して提供することで、アプリサイドの進捗に影響が無いようにしました。
アプリサイドがモックAPIを使って作業を進めている間に、サーバサイドは慣れないクリーンアーキテクチャで実装を進めたり議論を進めたりするようにしました。

導入しやすいように基礎部分のサンプルを自ら実装

APIの基礎部分のサンプルを最初に自ら実装して、チームメンバーにはそれを参考にして実装を進めてもらいました。

率先してすべての Pull Request に目を通す

サンプルを参考にして実装を進めてもらいつつ、そこで出てきたPRは自らすべて目を通すようにしました。
これによって、チームメンバーが理解出来ているか、方向性が間違っていないかなど、早い段階で気付ける体制にするようにしました。

わからないことがあればその都度議論する

設計やクリーンアーキテクチャに明るいメンバーは自分も含めていないため、正解というよりもベターな解を求めるために、何かわからないことがあればその都度チームメンバーで必ず議論するようにしました。
これによってベターな解を得るだけでなく、納得感も得るようにしました。

非クリーンアーキテクチャ至上主義

クリーンアーキテクチャは採用していますが、必ずしもクリーンアーキテクチャにこだわりすぎないようにしました。
良いところはもちろん採用しますが、難しいところ合わないところは無理に採用せず他の方法を使うようにしました。

最終的にどうだったか

新規開発だったためゼロベースで設計から開発まで進められたのはとても良かったと思います。
これが、既存サービスへの導入であれば、もっとかなり苦戦したはずです。

基本的にいろんなタイミングで議論するようにしましたが、その議論を受け入れてくれるようなチームメンバーであったのは大変助かりました。
「議論してる暇があれば実装を進めた方が良い」などの思い違いがあればもっと苦労していたかもしれません。

今回はAPI作成で返却値はJSONと決まっていたので、プレゼンターの設計は妥協しJSON決め打ちにしました。
最初からモリモリでやると大変なことになってしまうのが常なために、妥協して進めることに決めたのは良かったですし、今のところ特に問題も置きていません。

わからないことがあればその都度議論するようにしましたが、トランザクションやバリデーションなど結局何が正解でどうすれば良いかわからないということもいくつかありました。
そういう点では設計やクリーンアーキテクチャに明るいメンバーがいないチームに導入することの限界も感じてしまいました。

とは言え、総合的に見れば成功したように感じます。 が、このような設計は日々の運用の中で何かしら生きてくるものがあるものなので、新しい設計に挑戦して良かったクリーンアーキテクチャで良かったと思える日が来ることを信じています。

おわりに

今回は初めて大きな技術カンファレンスにLTとして登壇しましたが、とても良い経験になりました。
こういうカンファレンスなどの懇親会はぼっちが怖くて参加に苦手意識があったのですが、登壇者だと意外と皆さんから話しかけていただけるのでぼっち回避にもなりとても良かったです。

次はLTではなく普通のトーク枠で登壇したいところです。