GraphQLを使ったスキーマ駆動開発を実践する理由

- GraphQLには難しい点がたくさんある
- 人類にはまだGraphQLは早い

といった話を至るところで聞きますが、株式会社iCAREではGraphQLを使った、スキーマ駆動開発に取り組んでいます。

GraphQLを導入したのは約2年前で、現在はVPoEの安田が当時導入を推していたそうです。

今までもスキーマ駆動開発は実践されてきましたが、プロジェクトの進め方である問題が生じました。

フロントエンドエンジニアの開発がスタートできなかった

プロダクトオーナーから要求や仕様をデザイナーがデザイン化し、そこから出来上がったデザインを元に、プロダクトオーナーの確認を経て、開発がスタートするといった流れになっていました。

スキーマ駆動開発とはいえ、システムのデータベース構造について詳しいのはサーバーサイドエンジニアで、その構造をRuby on RailsのModelsに落とし込み、GraphQLのスキーマ定義としてフロントエンドエンジニアに共有されてきました。

それにより、フロントエンドエンジニアはサーバーサイドエンジニアの実装に対して待ち時間が発生していました。

その間に非優先なタスクを拾い、消化する事も重要ですが、プロダクトロードマップで事業成長にとって優先度の高いプロジェクトを最速で作ることができない状況はよくありません。

プロジェクトメンバーの作業を止めない

そこでVPoE安田の鶴の一声で、フロントエンドエンジニアが直接プロダクトオーナーから仕様や要求を聞き、そこからデザイナーさんはデザインを作ります。(ここではフロンエンドエンジニアがガワを作成できる程度のデザインで問題ありません。)

サーバーサイドエンジニアとフロントエンドエンジニアで共同して、スキーマ定義を行うようにしました。

その後、フロンエンドエンジニアがGraphQL Mock Severを立ち上げ、サーバーサイドの実装が完了する前に、実装をスタートすることができます。

その結果、フロントエンドエンジニア、サーバーサイドエンジニア、デザイナーの三者が並走しながら、プロダクト開発を進めることができ、プロジェクト全体で誰一人足を止めることなく進めることができています。

まだ新しいフローによる開発プロジェクトは始まったばかりで、今後この開発のやり方は進めていく中で、良い点悪い点がはっきりしてくると思います。

その辺りは効果検証をしながら、GraphQLの具体的な活用例も交えて情報を公開できたらなと思います。GraphQLが好きな人募集しています👍

スキーマドリブンでプロダクト開発をしたいエンジニアは株式会社iCAREの採用情報をチェックしてみてください採用絶賛強化中です🙆‍♂️

株式会社iCAREの募集・採用・求人情報 - Wantedly