SPACE フレームワークで振り返るモニクル GraphQL リプレース

2023-11-16 tsukiji.graphql #2 @オンライン でお話したスライドです。
イベントページ: https://tsukiji-graphql.connpass.com/event/298830/

Transcript

1. SPACE フレームワークで振り返る
   モニクル GraphQL リプレース
   株式会社モニクル
   塚田 翔也 / @gabu
   2023-11-16 tsukiji.graphql #2
   

   View Slide

2. 自己紹介
   ・塚田 翔也 / TSUKADA Shoya / @gabu
   ・札幌から来ました！
   ・名古屋出身、札幌に移住して3年目
   現在は、お金の診断・相談サービス「マネイロ」を開発している
   株式会社モニクルで CTO をやっています。
   4年前に1人目エンジニアとして入社して、事業の成長に合わせて
   エンジニア採用も進め、現在エンジニア12名の開発組織となっております。
   いわゆるスタートアップのシリーズBぐらいの会社です。
   

   View Slide

3. サービス紹介
   

   View Slide

4. 会社紹介
   

   View Slide

5. きっかけ
   

   View Slide

6. システム構成の変遷
   実際はもうちょっといろいろあり
   ますが割愛
   

   View Slide

7. リアーキテクトと開発生産性について by Yosuke Furukawa さん
   https:/ /speakerdeck.com/yosuke_furukawa/riakitekutotokai-fa-sheng-chan-xing-nituite
   

   View Slide

8. REST から GraphQL へリプレース
   という「リアーキテクト」と
   「開発生産性」への影響について
   

   View Slide

9. 最近話題の SPACE フレームワークと
   照らし合わせて振り返ってみます
   

   View Slide

10. SPACE フレームワークとは
    開発生産性について考えるためのフレームワーク
    ・Satisfaction and well-being（満足度と幸福度）
    ・Performance（パフォーマンス）
    ・Activity（アクティビティ）
    ・Communication and collaboration（コミュニケーションとコラボレーション）
    ・Efficiency and flow（効率とフロー）
    

    View Slide

11. SPACE フレームワークのポイント
    ・開発生産性を1つの指標だけでは測れないので、複数の指標を組み合わせま
    しょう。
    ・5つ全てが必須ではなく、チームや組織にとって重要なものを少なくとも3つ選
    んで自由に組み合わせましょう。
    ・それぞれに具体的な指標は定義されていないので、これまたチームや組織に
    とって重要なものを考えて定義しましょう。
    

    View Slide

12. あらかじめご了承ください
    まだモニクル社として SPACE フレームワークを導入して開発生産性を継続的に
    計測している訳では無いので、今回は
    「GraphQL 移行が SPACE フレームワークの各項目にどんな影響があるか考え
    てみた」
    的な発表になります。
    本当は既に導入済みで、before/after こんな変化がありました〜という発表がで
    きれば良かったのですが、申し訳ありません󰢛󰢛󰢛
    

    View Slide

13. Satisfaction and well-being（満足度と幸福度）
    満足度とは、開発者が自分の仕事、チーム、ツール、文化にどれだけ充実感を感
    じているかということであり、幸福度とは、開発者がどれだけ健康で幸せである
    か、そして仕事がそれにどのような影響を与えているかということである。
    例えば、生産性と満足度は相関関係にあり、満足度が生産性の先行指標となる可
    能性がある。
    

    View Slide

14. Satisfaction and well-being（満足度と幸福度）
    例）従業員の満足度、および従業員が自分のチームを他の人に薦めるかどうか。
    => 開発メンバーから「GraphQL を使いたい」「GraphQL はあんなことやこん
    なことが良いんですよ」という声をきっかけに検討を開始して、移行したので満
    足度は高そう。実際にアンケートもしてみました。
    

    View Slide

15. Satisfaction and well-being（満足度と幸福度）
    Fragment Colocationの開発スタイルを早期に導入したおか
    げで、各Reactコンポーネントが期待しているデータを過不
    足なくサーバーへ要求できるようになったのが最高でした
    （しかもクライアントまで自動生成できる！）
    @Nkzn
    

    View Slide

16. Satisfaction and well-being（満足度と幸福度）
    単純で理解しやすいリソース構造をバックエンドから独立し
    て再モデリングできるので、スキーマが安定する！サーバー
    サイドはresolver中心のフレームワークで、その明確さが素
    晴らしい！さらに、クライアントサイドでは、個々のニーズ
    に合わせてカスタマイズされたコードを作成できるので、こ
    れ以上便利なことはないですよ！
    @ka2n
    

    View Slide

17. Satisfaction and well-being（満足度と幸福度）
    クライアントで必要なリソースを必要な分だけ取得すること
    ができ、一度定義したリソースを別のクエリでも活用できる
    のが便利です！
    また、graphql-rubyを使えばActiveRecordのモデルをその
    ままGraphQLに直結させたかのような書き味でクエリや
    ミューテーションを作成することができ、爆速で開発が進め
    られました！
    @sugoi_wada
    

    View Slide

18. Satisfaction and well-being（満足度と幸福度）
    コードの自動生成やplaygroundでドキュメントも自動で作ら
    れててクライアントから柔軟にデータを取得できるのが便利
    で開発効率が良いところが好きです！！！チーム内でスキー
    マ定義から設計の認識を合わせやすくとても満足していま
    す！
    @20092014
    

    View Slide

19. Satisfaction and well-being（満足度と幸福度）
    クライアントサイドで必要なデータを柔軟に取得できるよう
    になり、スキーマの定義から実装までスマートにおこなえて
    嬉しいです！！
    スキーマなどから返却されるデータがすぐに分かり、さらに
    コンテンツに応じて複数のリクエストを1つにまとめること
    もできるのも推しポイントです！！！
    @kubio
    

    View Slide

20. 満足度は高そうですね
    

    View Slide

21. Performance（パフォーマンス）
    パフォーマンスとは、システムやプロセスの成果である。ソフトウェア開発者の
    パフォーマンスを定量化するのは難しい。
    なぜなら、個人の貢献を製品の成果に直接結びつけるのは難しいからである。大
    量のコードを生産する開発者は、高品質なコードを生産していないかもしれな
    い。高品質なコードが顧客価値を提供するとは限らない。顧客を喜ばせる機能
    が、必ずしもプラスのビジネス成果につながるとは限らない。
    たとえ特定の開発者の貢献がビジネス成果に結びついたとしても、その開発者
    が、よりインパクトのある仕事を選択する権限を持っていたのではなく、よりイ
    ンパクトのない仕事を割り当てられていた可能性があるため、必ずしもパフォー
    マンスを反映しているとは限らない。
    

    View Slide

22. Performance（パフォーマンス）
    例）品質。信頼性、バグのなさ、継続的なサービスの健全性。
    => GraphQL にしたからといって信頼性が上がるとも限らないかなぁ。
    型チェックでビルド時に実装のポカミスを防げるというのはあるものの、実行時
    は・・・ということで直接的に効果があった気はあまりしません。
    

    View Slide

23. Performance（パフォーマンス）
    例）インパクト。顧客満足度、顧客導入と維持、機能利用、コスト削減。
    => GraphQL にしたからといって顧客満足度が上がるかなぁ、通信回数が減って
    体験が良くなるというのはありそうだけど、REST でも工夫すれば何とかできそ
    うなものだし。
    ということで、この観点でもぱっと関連付けて何か考えるのは難しそう。
    

    View Slide

24. Activity（アクティビティ）
    アクティビティとは、業務遂行の過程で完了したアクションやアウトプットの数
    である。
    開発者のアクティビティは、正しく測定されれば、開発者の生産性、エンジニア
    リングシステム、およびチームの効率について、貴重ではあるが限定的な洞察を
    提供することができる。開発者が行う活動は複雑で多様であるため、その活動を
    測定したり定量化したりすることは容易ではありません。実際、エンジニアリン
    グシステムや環境全体にわたって、開発者の活動のすべての側面を包括的に測定
    し、定量化することはほとんど不可能です。しかし、よく設計されたエンジニア
    リング・システムは、ソフトウェア開発ライフサイクルのさまざまなフェーズに
    沿ったアクティビティ・メトリクスを取得し、開発者のアクティビティをスケー
    ルで定量化するのに役立ちます。
    

    View Slide

25. Activity（アクティビティ）
    例）設計とコーディング。設計文書や仕様書、作業項目、プルリクエスト、コ
    ミット、コードレビューの量や数。
    => GraphQL 化の影響を単体で考えるのは難しいですが、REST よりも決まって
    いることが多いので「逸脱した設計や実装が減る => 手戻りが減る => 開発効率
    アップ => 結果的に各指標がプラスになる」ということはあるかもしれない。
    例えば、REST って純粋なリソースではない独自のエンドポイント、例えば
    /api/v1/mypage とか（mypage ならまだかわいいですが...これが乱立する
    と...）を割りとシュッと作れちゃうと思うのですが、一方で GraphQL はリソー
    スドリブンでスキーマを定義して、クライアントサイドでは欲しいリソースをま
    とめてフェッチできるので、そういう「まとめ API」が減る性質はありそう。
    

    View Slide

26. Communication and collaboration（コミュニケーションとコラボレーション）
    コミュニケーションとコラボレーションは、人々やチームがどのようにコミュニ
    ケーションし、どのように協働するかを捉えるものである。
    ソフトウェア開発は、チーム内およびチーム間の広範かつ効果的なコミュニケー
    ショ ン、調整、コラボレーションに依存する、協調的かつ創造的なタスクであ
    る。さらに、チーム内およびチーム間の情報の流れ方は、業務の効果的な調整と
    統合に必要な文書の可用性と発見可能性に影響を与えます。より効果的なチーム
    は、適切な問題に取り組み、新しいアイデアのブレーンストーミングに成功しや
    すく、あらゆる選択肢の中からより良い解決策を選択する。
    

    View Slide

27. Communication and collaboration（コミュニケーションとコラボレーション）
    例）文書や専門知識の発見しやすさ。
    => REST 時代に OpenAPI(Swagger) までは使ってなかったので、API ドキュメ
    ントの整備が面倒&実装と乖離することがありました。そこまで API が多くな
    かったので OpenAPI 化してなかったというのもありますが...
    GraphQL に移行した結果、GraphQL ではコードファーストでもスキーマファー
    ストでも成果物としてスキーマが定義され、そのスキーマとコメントがそのまま
    ドキュメントにもなるので一石二鳥でした。※もちろん OpenAPI でも同様にス
    キーマを定義してそれがドキュメントになると思うので、その点ではどちらでも
    良かったかもしれないです。
    

    View Slide

28. Efficiency and flow（効率とフロー）
    最後に、効率とフローは、個人であれシステムであれ、中断や遅延を最小限に抑
    えて仕事を完了させたり、進捗させたりする能力を把握するものである。これに
    は、チーム内およびチーム間の活動がどの程度うまく編成されているか、継続的
    な進捗がなされているかなどが含まれる。
    この生産性の概念化は、多くの開発者が仕事をするときに「フローに入る」こ
    と、あるいはフローを見つけ最適化することの難しさについて語るときにも同じ
    ように語られる。個人の効率性は、中断のない集中時間や、価値創造アプリ内の
    時間（例えば、開発者が統合開発環境で過ごす時間は、「生産的」な時間とみな
    される可能性が高い）によって測定されることが多い。
    

    View Slide

29. Efficiency and flow（効率とフロー）
    => GraphQL 化の前からバックエンドとフロントエンドでチームを分けず、全員
    が両方を開発するスタイルでやっていた。
    例えば、追加開発のためにフロントエンドとバックエンドで話し合って、スキー
    マを決めて、バックエンドが開発してくれるまでフロントエンドはモックで開発
    をして、それぞれ開発ができたら統合して、テストして...
    というプロセスではなく、
    同じ人・チームが、スキーマを考え、バックエンドを実装し、フロントエンドを
    実装し、テストをして完成。
    というプロセスなので、フロー効率が元々良かった。
    

    View Slide

30. Efficiency and flow（効率とフロー）
    => 一方で REST 時代は OpenAPI を使わずに自前で社内用の npm パッケージ
    （独自の API クライアントライブラリ）を介してフロントエンドから通信してい
    たので、GraphQL 化移行はそのパッケージを準備したり、フロントエンド側で
    パッケージのバージョンを上げたりせずに、graphql-codegen で一気にフロン
    トエンドのコードを自動生成できるようになったので、その点は開発効率が格段
    にアップしました。※もちろん OpenAPI でも同様のことができたと思います。
    

    View Slide

31. まとめ
    S
    P
    A
    C
    E
    Satisfaction and well-being（満足度と幸福度）
    自分たちが使いたいツールを使っているので満足度や幸福度は高い。より良くしていこう、もっと
    活用しようというモチベーションを持ちやすい。
    Performance（パフォーマンス）
    「開発効率アップ => リリースが速くなる => ビジネスにプラス」という効果はありそうなもの
    の、大きなインパクトとまでは言えなさそう。でも開発スピードは確実に上がった。
    Activity（アクティビティ）
    GraphQL の仕様に準拠することになり「設計や実装で迷いや手戻りが減る => 開発効率アップ」と
    いうことで、アクティビティにはかなりプラスになっていそう。
    Communication and collaboration（コミュニケーションとコラボレーション）
    API に関してのコミュニケーションやコラボレーションを全て GraphQL を拠り所にして行えるよう
    になったのが最高。Rails のようなレール味を感じる。
    Efficiency and flow（効率とフロー）
    もともとフロー効率の良い開発プロセスを取っていたが、バックエンドとフロントエンドのやりと
    りをより効率よく開発できるようになって嬉しい。
    

    View Slide