IFを定義して、コードとチームを守れ！/protect-code-and-team-link-and-motivation

リンクアンドモチベーション登壇資料（2026/03/05）
IFを定義して、コードとチームを守れ！

#シネマ de LT会 #リンモチ

===========================================
【イベント情報】
■イベントページ
https://aeon.connpass.com/event/384637/

【株式会社リンクアンドモチベーション】
■お問合せ先
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
■開発組織の公式X
　https://x.com/LinkandM_dev
=============================================

Transcript

1. © Link and Motivation Group 株式会社リンクアンドモチベーション ブランド統合ユニット プラットフォーム推進グループ 大塚 友章 IFを定義して、コードとチームを守れ！
2. © Link and Motivation Group 自己紹介
3. 3 © Link and Motivation Group 自己紹介 大塚 友章（@big_mound_26） 株式会社リンクアンドモチベーション ブランド統合ユニット プラットフォーム推進グループ • 2016年：（株）TKCに新卒入社 ◦ 電子取引/インボイスのサービス開発 • 2022年：（株）リンクアンドモチベーションに中途入社 ◦ モチベーションクラウドの認証と組織管理をする マイクロサービス開発チームのテックリード
4. 4 © Link and Motivation Group 好きな映画
5. 5 © Link and Motivation Group 好きな映画 シャークネード - 気候変動によって発生した竜巻によって空を舞う人喰い鮫をテーマにしたB級ホラー - 要は「JAWS」 「デイ・アフター・トゥモロー」 - シリーズ６まで作られている（シリーズ6は時空を超えて鮫が襲ってくる ） 画像はイメージです
6. © Link and Motivation Group はじめに
7. 今日話したいこと
8. プラットフォームを開発時に IFを明確にしなかったことで バグを頻発させた時の学び
9. 9 © Link and Motivation Group 弊社のプラットフォームとは？ - 複数のサービスで「認証」「従業員」という情報を扱うので、これらを共通で管理する仕組 みを作った - この仕組みのことを今回は「プラットフォーム」と呼ぶ
10. © Link and Motivation Group 当時の状況
11. 11 © Link and Motivation Group プラットフォームと各サービスの連携開発時 プラットフォーム作った！ 連携しましょう！ 各サービス 開発者 OK! ただパッと見、どう開発したらいいか 想像つかないな〜 わたし
12. 12 © Link and Motivation Group プラットフォームと各サービスの連携開発時 確かに、内部実装知らないと難しいな... OK! 自分で各サービス側も作ってみます！ 各サービス 開発者 よろしく！ わたし
13. 13 © Link and Motivation Group プラットフォームと各サービスの連携開発時 確かに、内部実装知らないと難しいな... OK! 自分で各サービス側も作ってみます！ 各サービス 開発者 よろしく！ わたし 結果、バグを生みまくって爆死 ⇨ マイクロサービスの原則として、 他サービスの開発をするのはNG！ 起こるべくして起こった
14. © Link and Motivation Group 何がよくなかったか
15. 予兆はあった
16. 16 © Link and Motivation Group プラットフォームと各サービスの連携開発時 各サービス 開発者 よろしく！ わたし 確かに、内部実装知らないと難しいな... OK! 自分で各サービス側も作ってみます！
17. 17 © Link and Motivation Group プラットフォームと各サービスの連携開発時 各サービス 開発者 よろしく！ わたし 確かに、内部実装知らないと難しいな... OK! 自分で各サービス側も作ってみます！ サービス間のIFがよくなかった
18. 18 © Link and Motivation Group 当時のIF プラットフォームで変更された「データだけ」を渡すIFだった。そのため、 - プラットフォームを利用するサービスは、過去に取得した従業員情報と比較し、 「何があった」かを判断する必要があった - 渡されたデータに対して「何をすべき」かを判断する必要があった プラットフォームの 実装見ないとわからん...
19. © Link and Motivation Group 解決編
20. 20 © Link and Motivation Group 「何が起こるか」 だけ伝える 良いIFとは? 相手の実装を知らずに 開発できる 「誰が何をやるか」が明確 How（実装）ではなく What（振る舞い）を公開 IFだけ守れば、裏側は自由に 変えられる（疎結合） IFを公開する側の責務と利用する 側の責務が分離される 内部実装を知らなくても、利用側が迷わず開発できる「契約」
21. 21 © Link and Motivation Group ❶何が起こるか IFを再定義する IFは以下のように定義 ❷呼び出し側は何をすべきか + プラットフォーム側で発生する 出来事をドメインの言葉で伝える そのイベントに対して各サービスが行う べき処理を明確にする
22. 22 © Link and Motivation Group 開発体制も分離される - IFが契約として成立したことで、開発体制も自然と分離される プラットフォーム 開発 自サービスの開発 自サービスの開発 自サービスの開発
23. © Link and Motivation Group おわりに
24. 24 © Link and Motivation Group 境界が曖昧になる時、設計を疑え！ （シャークネードのように？） 開発体制の境界が曖昧になっている時、 IF(契約)も曖昧になっているサイン！ 明確なIFを定義することでチームもコードもバグから守れ！
25. 25 © Link and Motivation Group 1つだけ告知を…！ • リンモチ、採用・広報頑張ってます！ • もしよければ、「技術広報公式X」のフォローをお願いします！