こんにちは。ウィルゲートで開発を行っている岡田 (@okashoi) です。
私の所属するソリューションチームでは web アプリケーションフレームワークとして Laravel を採用しています。
以前に CakePHP との比較を行った際にも取り上げたとおり、Laravel は目的に合わせて柔軟に拡張できる仕組み提供しているのが特徴です。
個人的にはその豊かな表現力が好きな一方で、特にチーム開発においてはその自由度の高さゆえ、設計方針についてメンバー間の認識のすり合っていないと道を見失いやすいというデメリットも抱えています。
この記事ではソリューションチームにおいて、道に迷わずに（迷っても再び戻って来られるように）Laravel を使っていくために実施した取り組みを紹介していきます。
目次
この記事の元ネタ
この記事は 2018/03/14 に開催された「【 ヒカ☆ラボ 】【Laravel5、CakePHP3など】ベンチャー企業のリアルなPHP事情」でお話した内容をベースとしています。
◆イベントページ
◆スライド
www.slideshare.net
背景・解決したかった課題
2017年4月に新規プロダクト開発が始まって以降、ソリューションチームはこれまでに多くのメンバーを受け入れてきました。
多様な背景を持ったメンバーの中には、 Laravel 未経験の人がいることも少なくありません。
そんな状況下で開発を進める上で避けたかったのが
- Laravel が提供している機能を本来想定されていない方法で使ってしまう
- Laravel が提供している機能で実現できるものを自前で実装してしまう（車輪の再発明）
という 2 点です。
いずれもバグの原因になったり、メンテナンスコストが増加*1したりするおそれがあるからです。
課題を解決するための取り組み
この課題を解決するべく、チームで以下の 3 つの取り組みを実施しました。
- ドキュメントの整備
- 実装前の方針すり合わせ（設計レビュー）
- 「コーディングに関する相談会」の定期実施
ドキュメントの整備
まずは方針を明文化し、判断の基準が明確になっている必要があります。
大きく分けてふたつの形式のドキュメントを作成しました。
ひとつはテキストベースのいわゆる「ドキュメント」で、Confluence にディレクトリ構成やコーディング規約などの基本的なドキュメント、 ひいては「こういう処理はこのクラスに書く」「コードを書く際にはこういったことを意識する」といったの設計のベストプラクティス的な抽象度の高い内容もまとめました。
ただし、テキストの情報だけでは冗長な表現や伝わりにくい部分が出てきてしまいます。
そこで、もうひとつのドキュメント形式である「ガイドライン」と称した具体的なコード例も準備しました。
これは同じリポジトリ内に、実際に「動作する」*2コードの形で実装方針を示したものです。
コードの途中で適宜「ガイドライン」という文字列を含んだコメントをはさみ、意味や意図を説明しています。
また「ガイドライン」を作成したプルリクエスト自体が URL を持つ 1 つのドキュメントになる、という性質も持っています。
実装前の方針すり合わせ（設計レビュー）
今までの「実装する」→「プルリクエストを出す」→「レビューする」という開発フローでは、実装完了し、プルリクエストが出されるまで実装方針のズレに気づくことができません*3。
これでは一度書いたコードを修正するという手間が発生するばかりか、最悪の場合「時間が無い」という理由で方針のズレを内包したままマージしなければならない、ということになりかねません。
そこで、実装を始める「前」に方針のすり合わせを行うべく、簡易的な設計レビューを行うようにしました。
各自、実装を始める前に所定のフォーマットに実装内容をまとめ、それをもとにレビューを行うことで「規約・方針に則っているか？」「Laravel が提供している機能を正しく使えているか？」の認識をすり合わせます。
このフォーマットを制定する際には、実装内容をまとめるために時間が掛かり過ぎず、かつ議論したい要点を抑えられるように、項目の洗い出しを工夫しました。
「コーディングに関する相談会」の定期実施
「コーディングに関する相談会」と称して、毎週30分間チームメンバーが集まってコーディングに関することを何でも気軽に話せる時間を設けました。
この取り組みは前者ふたつの「プロジェクトの実装方針についての認識すり合わせ」というアプローチとは異なり、「コーディング一般についての認識すり合わせ」「ノウハウの共有」を通じて課題の解決を試みたものです。
相談会をより有意義なものにするため、開催にあたっては以下のような工夫をしています。
- 他のチームのメンバーも参加可能にする
- 特定の形式にこだわらない（単なる議論だけでなく、モブプログラミングを取り入れるなど）
- 特定の人・考え方を批判しないようにする
特に最後の「特定の人・考え方を批判しないようにする」は、参加メンバーが気兼ねなく意見を出せるようにするうえで大切だと考えています。
この手の議論をしていると、つい「こんなことも知らないの？」「その考え方はイケてない！」というような言葉が口をついて出そうになることがありますが、そんなときはお互いに指摘しあって止めよう、と取り決めています。
取り組みをふりかえって
これらの取り組みを通じて、先に挙げた課題を解決して Laravel を「みんなで、きちんと」使うことができるようになってきたと感じています。
例えば、チームメンバーの実装面の不安を解消できる仕組みを作ることができたことにより、新しい概念（チームで初めて使う Laravel の機能など）を取り入やすくなっています。
また副次的な効果として、以前よりもメンバー間で「良いコード」について会話する機会が増えました。
プルリクエストや前述の「相談会」の場に限らず、普段の作業中でも「ここの実装ってこうしたほうがいいですかね？」という会話が生まれるようになり、チーム全体で同じ方向を向いてきたように感じています。
一方で「ドキュメントの量が膨大になり、どこに何があるか把握しにくい」「設計レビューが出来る人が不足している」という課題も出てきているので、引き続き「みんなで、きちんと」開発していくための取り組みを続けていきたいと思います。
