コネヒトCTO伊藤が語る！ママリとCakePHPの今までとこれから

　コネヒトが開発しているママ向けQ&Aアプリ／情報メディア「ママリ」では、CakePHPを開発当初から使用しています。2014年にサービス提供を開始し、今に至るまでにはフレームワークのバージョンアップ対応における苦労、技術的負債の解消などいろいろなことがありました。今回「CakePHP」をテーマにCTO伊藤のインタビューをお届けします。

ママリで使用している技術って？

ママリで使用している技術スタックを教えてください。

まず、モバイルアプリの技術スタックで言うと、iOSアプリはSwift、AndroidアプリではKotlinを使用しています。Webの技術スタックはフロントエンドではReactをメインで使っていて、バックエンドでは、主にPHPでフレームワークはCakePHPを使用しています。インフラはAWSでECSを用いたDockerコンテナを利用しています。他にも機械学習のシステムではPythonを使ったり、最近は一部でGoやNode.jsを使ったりなんかもしています。ざっくり言うとこんな感じです。

フレームワークでは、どうしてCakePHPを使用しているのですか？

　ママリの開発は当初からCakePHPを使用しています。最初に使い始めた理由は、2014年当時、創業者CTOである島田がひとりで開発するといった状況下でビジネスをいち早く立ち上げる必要があり、早くプロトタイプを作ることができる関係で採用をしたときいています。

　いまでも採用をしているのは、CakePHPの「設定より規約」を重視しているところが個人的にはチーム開発において効果的だと考えているからです。チーム開発は、どうしても個々人によってコードのブレが出てくることもある。だから、フレームワークレベルである程度「縛り」を入れることで同じような設計やコードになり、それが開発スピードの速さ、品質の担保につながり、全体的に開発スピードが速まります。ここ数年、PHPのフレームワークと言えば、Laravelに人気が集中しています。Laravelも優れたフレームワークですが、CakePHPと比較すると開発者の自由度が高いフレームワークです。ですので、プロジェクトによってアーキテクチャや構造が異なる場合もあります。逆に、CakePHPはフレームワーク本体といかに協調するかという制約があるため、結果としてどのプロジェクトでもほとんど同じような構造になります。ですので、CakePHPの仕様さえ理解していれば、プロジェクトが変わったり、新しい人が入ってきたりした場合でも、キャッチアップの時間が短く済むので、スキルのポータビリティ性が高いと感じています。

　もうひとつ冒頭でも述べたようにシンプルなアプリケーションがサクッと作れる点も使い続けている理由の一つです。こちらもLaravelとの比較になりますが、LaravelはDIの仕組みが充実しているため、レイヤードアーキテクチャやクリーンアーキテクチャとの相性がよく、複雑なビジネス要件でも綺麗なアプリケーションを作ることが出来ます。確かに、外部システムとの連携が多くなったり、いわゆるサービスクラスが必要になったりすると、CakePHPの規約の外に飛び出す必要があります。しかし、僕らが開発するようなアプリケーションの場合、ほとんどはシンプルなMVCの構成で十分なことが多いと考えています。UNIXの哲学にも「90%の解を目指す」という言葉がある通り、どんなに複雑なビジネス要件にも100%対応できるコードより、サービスの成長を第一に費用対効果を最大化させるコードが大切だと思っていて、CakePHPはそういった面で非常に素晴らしいフレームワークだなと感じています。

ママリのCakePHPについて

CakePHPのバージョンをこまめにバージョンアップしているのはなぜですか？

　一番はメジャーアップデートに即対応できるようにという考え方からしていますね。当たり前のことではありますが、メジャーアップデートすると開発効率がよくなることはもちろん、パフォーマンスの向上、セキュリティのリスク軽減などメリットがたくさんあるので、アップデートすること自体がとてもいいことだと思っています。例えば、CakePHPが2系から3系からバージョンアップしたときは、いわゆる「配列地獄」から解放されたり、名前空間がサポートされたり、Composerが標準になったりと一気にモダンなフレームワークに生まれ変わりました。その中でもマイナーバージョンやパッチバージョンがリリースされたときにも対応しているのは、メジャーアップデートの際にもあまり時間をかけずにできるようにしたいからです。

　ビジネスサイドからみると、マイナーバージョンなどのアップデートはサービスのレスポンスがよくなるなど目に見えるような効果を感じづらく意味がないように見えるかもしれません。ただ、開発サイドからみるとメジャーバージョンがリリースされた時にだけ対応していると一度に修正するコードのボリュームが多くなり、時間がかかってしまう。そこでこまめにアップデートをしておくことで、メジャーバージョンが出た際にも即アップデート対応できるような開発環境づくりを心掛けています。例えば、インフラ環境をコンテナ化することで、簡単に開発環境が構築出来るようにしたり、本番環境と開発環境の差分をなくすことで検証コストを削減したりしています。また、最近はcomposer updateの自動化（使っているライブラリにアップデートがあった場合、自動でPull Requestが作成される）も行っています。

△コネヒト開発ブログにて、アップデートの変更内容の振り返りなどを定期的に発信

それは、前からそうだったんですか？

　いや、そんなことはないんです。過去の反省をふまえ、今の状態になっています。
　ママリのGitHubのリポジトリで一番メインシステムであるアプリが利用するWebAPIはもともと、CakePHP2系で開発されていました。2016年頃に3系がリリースされており、うちもバージョンアップ対応に取り組もうとしましたが、当時のインフラ構成の関係上、検証コストが高く頻繁にバージョンアップ出来ていなかったため、古いバージョンを使わずCakePHP3系のプロダクトを新たに立ち上げるという形で対応をしました。当時の開発部メンバーは、3系の知識や経験がない状態でとても大変で、半年程度かけてリプレイスしました。リプレイスはエンジニアリング的には楽しさややりがいがあります。ただ、ビジネス的にはユーザー体験を向上させるということはありますが新機能の開発などに時間を費やしていないため、プロダクトの価値向上まで生み出せていない。よりユーザーの体験、価値を向上させていくための開発に時間を費やすためにも、フレームワークのバージョンアップに時間をとられないように開発を進めないといけないという教訓があり、今の形になっていますね。

バージョンアップの進め方において気をつけていることはありますか？

　現在、ママリは2018年に出産をしたママの3人に1人がご利用いただくアプリにまで成長し多くのユーザーが日々、悩みや不安を投稿しユーザー同士が支え合う場になりつつあります。バージョンアップにおいて、社内の管理システムから行い、ユーザーへの影響範囲を最小限にできるよう運用していますね。

　2系から3系へのバージョンアップについてはまずアプリ「ママリ」のシステムで対応し、その後社内の管理システムも対応しました。ここで、3系に合わせることができたこともあり、今は社内の管理システムで最新バージョンにした後、ユーザー影響のある「ママリ」のシステムのバージョンアップを対応するというフローにしています。もし、社内の管理システムで反映させた後にバグが起こったとしても影響範囲が最小限に済みます。
　このフローができたことで、PDCAを回しながらすぐユーザーが使うプロダクトにも反映ができるのでアップデートコストが下がったと感じています。

細かくバージョンアップをすることは、開発メンバーのモチベーションにつながるんですか？

　うーん、正直細かいバージョンアップに対応すること自体が嬉しいということはあんまりないかもしれないですね。ただ、ちゃんと対応しておくことでエンジニアが不幸にならないというのはあると思います！

それはどういうことですか？

　定期的にバージョンアップしていないと、過去の自分たちのようにリプレイスをしないといけない状況になる。だけど、リプレイスって強い意志がないと進められないのでリプレイスできないまま古いバージョンのものを使っていると開発効率も悪くモチベーションが下がり、プロダクトの負債も溜まっていく。そして何よりユーザーへの価値還元もできづらくなるといった悪循環に陥るこの状況はエンジニアが不幸になりえるなと考えています。
　システムのバージョンアップって「割れ窓理論」だなーと思っています。「割れ窓理論」は例えば、学校で窓がひとつも割れていないと割らないように気をつけるけど、半分くらい割れていると割れている状態に慣れてしまい、どうでもよくなっちゃう、というようなものなのですがシステムのバージョンもそれと同じで常に最新に準じていると保つのが普通になると思っています。ですので、これからも今の状況をうまく保ちエンジニアが健全な状態でユーザーのために開発ができる環境にしていたいと思いますね。

ちなみに今後もCakePHPは使用していきますか？

　はい、もちろんです！2系から使用し続けているのでCakePHPの資産が社内に蓄積されているし、社内にコントリビューターも在籍しています。今後、別の言語を部分的に導入することはあると思いますが、しっかり積み上げてきた資産をちゃんと活かし続けたいと考えています。
　もうすぐ4系が正式リリースされると思うので早いタイミングでメジャーアップデートに対応していきたいと思っています。

コネヒトはCakeFestにスポンサーをしています！

積極的にエンジニアカンファレンスのスポンサーをしていますよね。それはどうしてですか？

　会社としては、PHPカンファレンス2016が初めてのスポンサーだったと思います。今期は一番多く9つのスポンサーを実施します。ママリを開発するにあたって、CakePHPをはじめとするOSSを使っており、技術コミュニティの恩恵を受け、そのコミュニティのおかげてサービスを成長させることができていると考えています。シンプルに恩返しをしたいし、恩返しをすることでまた技術コミュニティが発展し、またそこから新しい何かが生まれサービスが大きくなるという循環をつくりたいと考えています。

△PHPカンファレンス北海道 2019でLTをしている様子

　僕がCTOに就任したタイミングで、技術コミュニティになくてはならない開発組織を目指すために「ス・マイル制度」という新しい制度をスタートいたしました。ここからもコネヒトの開発組織が技術コミュニティを大切にしていることがわかると思います。
「ス・マイル制度」の詳細はこちらからご確認ください。

CakeFestでは、CTO伊藤さんも講演しますよね！どんなお話をする予定ですか？

　個人で開発したCakePHPのライブラリがありまして、OSS開発についてお話する予定です。おそらく、エンジニアの方だと一度はOSSをつくってみたいなと思ったことはあると思うのですが、実際手を出せていない方も多いのではと思っています。そこで、OSS開発をはじめる一歩になるようにどういう手順でどんなふうに作るのか、どんなところを意識したらいいかなどを発表しようと考えています。
　僕の講演をきいたらCakePHPでOSSがつくれるようになっている！・・・・かもしれないです（笑）
　10日16時45分に講演するので、是非ききにきてください！

さいごに

伊藤さん、締めの一言をいただけますか？

　今年、日本で初めてCakeFestが開催されることもあるので、改めてCakePHPに注目が集まるといいなと思っています。これから新しく4系がリリースされたり、日頃からOSSへのIssueやコントリビュートに対して多くの人が議論したり、Pull Requestをレビューしたりするなど、CakePHPのコミュニティは多くのエンジニアたちで成り立っています。
　特にコネヒトの開発組織としては、技術コミュニティへ貢献していきたいということもあるので、「CakePHPといったらママリだよね」という存在となり、「あのママリが使用している技術だから自分たちのサービスにも取り入れていこう」と思ってもらえるような存在になっていきたいと思っています。CakePHPが使われたサービスが増えていくように、コミュニティ自体を盛り上げていけたらと思います！