作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era

Presentation Slides for 開発生産性Conference 2024
Session title: 作りすぎない技術 - API時代の開発努力の在り方について考える (session page)
Date: 2024/06/28

Session Description:
APIを中心とした現代の技術環境において、過剰な設計開発や技術の導入を避けつつ、効率的かつ効果的に開発を行い、生産性を上げるためのヒントとなる考え方、開発プラクティス、設計思想などをご紹介します。

Transcript

1. All rights reserved by Postman Inc 作りすぎない技術 API時代の開発努力の在り方について考える Presentation slides for 開発生産性Conference 2024 川崎庸市 Postman株式会社
2. Technology Evangelist Postman株式会社 川崎 庸市 / Yoichi Kawasaki @yokawasa @postman_japan
3. はじめに 開発生産性を高めるためには、単に速度を追求するだけではなく、質と効率を両立させ ることが肝要です。そのためには無駄な作業を省き、価値のある成果を生み出すための 戦略をしっかり考える必要があります。 ここでは、APIを中心とした現代の技術環境において、過剰な設計開発や技術の導入を 避けつつ、どこに重点を置き、効率的かつ効果的に開発を行い、生産性を向上させるた めのヒントをご紹介します。 @postman_japan
4. 本日のゴール • 「作りすぎない技術」の考え方や実践方法を理解いただく • 今後の開発活動の参考にしていただく • フィードバック（共感、反論、指摘など）をいただく @postman_japan
5. 必要のないものは作らない
6. ここでの「必要のないもの」とは • 本質的な課題を解決しないもの • 利用者のユースケースを実現しないもの • 冗長なもの • 代替可能なもの • 過剰なもの（将来的に不要になる） • 維持管理が難しいもの（将来的に不要になる） @postman_japan イシューからはじめよ ――知的生産の「シンプルな本質」 https://amzn.to/3XK87VU
7. YAGNI - 必要になるまで作らない YAGNI (You ain't gonna need it) 実際に必要となるまでは追加しない方がよいとするExtreme Programming (XP)にお ける原則 Yagni https://martinfowler.com/bliki/Yagni.html 推定・仮説に基づいて作る機能の3つの分類とそれぞれ YAGNIを無視した場合に発生する4種類のコスト • 構築コスト • 修理コスト • 維持コスト • 遅延コスト • 正しくない機能 • 間違って作られた正しい機能 • 正しく作られた正しい機能 @postman_japan
8. 標準化されている / 相互運用性のあるものを選ぶ • 標準化 / 相互運用性のあるもの ◦ インターフェース、フォーマット、プロトコル ◦ 世界標準、組織標準 • 標準化 / 相互運用性のある世界はスケールする ◦ 学習コスト、コラボレーションコスト低減 ◦ 柔軟性、拡張性の向上 ◦ エコシステムの有効活用 / 巨人の肩の上に立つ • 独自技術・仕様のデメリット ◦ (将来的に) コスト高、属人化、技術的負債 @postman_japan
9. その時点でのベストな技術スタックを選ぶ 技術的にイケてる（卓越）かどうかだけでなく、チーム 能力、制約などのバランスも加味する • 技術的な卓越性 ◦ 将来性、成熟度、パフォーマンス、セキュリティ、サポー ト、エコシステム • チームスキル・経験（練度） ◦ チーム練度、学習曲線、外部リソースが調達可能か • 制約事項（コスト・スケジュール） ◦ 保守性、開発・運用・ライセンス費用など ◦ 時間的制約 https://speakerdeck.com/twada/understanding-the-spiral-of -technologies-2023-edition 技術 卓越性 チーム スキル 制約 事項 @postman_japan 技術 選定 …
10. 車輪の再発明をしない @postman_japan
11. 組織的開発における重複を排除する 組織開発における重複や重複がもたらす不要な開発の例 • 機能の重複開発 ◦ リソースの無駄遣い ◦ 統合時に互換性や一貫性の問題の原因になる • ドキュメンテーションの重複 ◦ リソースの無駄遣い ◦ 互換性や一貫性の問題の原因になる • ツールやプロセスの重複 ◦ 全体的な効率低下、一貫性低下 ◦ 組織全体の改善が進みにくくなる @postman_japan
12. 組織内における重複を排除する 重複 / 車輪の再開発を排除するための施策例 • コミュニケーション強化 ◦ チーム間インタラクションを通じた知識・スキル・自立性の 向上、重複排除 ◦ チームトポロジーのチーム間の 3つのインタラクションモー ド：コラボレーション、ファシリテーション、 X-as-a-service • ツールとシステムの統合 ◦ 一貫性、効率性向上につながる • 標準化とガイドラインの策定 ◦ 同じ目的のツール、プロセスの標準化 ◦ 一貫性、効率性向上につながる チームトポロジー 価値あるソフトウェアをすばやく届ける 適応型組織設計 https://amzn.to/3KXKhyA @postman_japan
13. 80点を目指す 「100点の品質」よりも「ほどよい品質 (80点)」を「継続的に改善」するアプローチで
14. 注意: 80点は目安。必ずしも合格点ではない • 製品やサービスの性質 ◦ 医療機器、航空機制御などミッションクリティカル系では最高水準の品質が求められる • ユーザーの期待とニーズ ◦ 特定の市場や顧客セグメントでは、高い品質が要求される • リスクとコスト ◦ バグや不具合が発生した場合のインパクト ◦ リソースやコストの制約 前置き @postman_japan
15. 100点の品質の追求は難しい 複雑で不確実性が多い今日のシステム環境において、100点の品質追求は難しく、また 割に合わないことが多い • 多様な技術の統合・連携 ◦ クラウド、オンプレミス、モバイル、 IoTデバイスなど ◦ 異る技術の統合は複雑性を増大させる（サービス障害、ネットワーク遅延・断絶） • 継続的に更新される環境 ◦ クラウド、クラウドネイティブなプロダクトは頻繁なアップデートが前提 ◦ それに依存するシステムは頻繁なアップデートに追従が必要 • 急速な技術進化 ◦ 新しいツール、フレームワーク、プログラミング言語など前よりもよいものが日々登場 ◦ それに伴いアーキテクチャの正攻法も変化 • ビジネス環境の変動 ◦ 市場の変動、競争の激化、新しい規制や法令の導入など ◦ システムの適用を難しくし、不確実性を増大 @postman_japan
16. ほどよい80点の品質を目指す戦略 100%の品質よりもほどよい80点の品質を高速かつ継続的に改善するアプローチ • 堅牢性よりも機動性と回復性 ◦ 障害の発生は可能な限り早期に検知する ◦ 障害から迅速に回復しダウンタイム時間を抑える (自己回復力や冗長性 ) • 継続的テスト・改善 （Fail Fast） ◦ ライフサイクルの早いフェーズからテスト ◦ フィードバックを迅速に反映して逐次改善する • 目標設定と優先度付け ◦ どの程度の追求すべきか目標設定と優先度付けを行う @postman_japan
17. “Done is better than perfect” – Mark Zuckerberg Design for Failure - Running Containerized Microservices on AWS (amazon.com) https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html “Everything fails all the time.” – Werner Vogels Done is better than perfect https://medium.com/@chihweitang/done-is-better-than-perfect-6cc86635ccdd @postman_japan
18. 機動性と回復性を重視する 障害は可能な限り早期に検知し被害を最小限に抑えることを目指す • MTTR (平均復旧時間)：障害発生〜復旧までの平均時間 • 可観測性（オブザーバビリティ） MTTR = Mean Time To Repair MTBF = Mean Time Between Failures どれだけ早く復旧するか どれだけ壊れにくいか UP DOWN 復旧 MTTR MTBF @postman_japan
19. 機動性と回復性を重視する • リリースまでのリードタイムを短くして、高速フィードバックループを回す ◦ コード化（x-as-code）、継続的テスト、CI/CD • ある程度完成したら一部をリリースして様子をみて、ダメなら戻す ◦ Blue/Green、カナリアリリース • 障害の発生は可能な限り早期に検知し回復へのアクションに移す ◦ 監視・観測、セルフヒーリング、オートスケール @postman_japan
20. Fail Fast - 問題の早期発見と対処 実践方法 - APIファースト (APIの場合) - テスト駆動開発 (TDD) - 継続的インテグレーション (CI) - スクラム ⇒ アジャイル開発の基本理念と一致 Fail Fastの目的 - 問題の早期発見と対処 - リスクの最小化 - フィードバックの迅速化 - 継続的な改善 Define Design Develop Test Deploy Observe Distribute check check check check check ライフサイクルの後ろのフェーズになればなるほど改修コストが大きい @postman_japan
21. フィードバックループと新陳代謝 • 一度作った終わりではなく、ソフトウェアライフサイクルにおける課題をフィードバッ クを元に継続的に改善させる • システムを新陳代謝させていくことが生存の鍵 • そのためには新陳代謝しやすい構造にしておくことが重要 計画 設計 テスト 実装 デプロイ 監視 観測 問題 対処 要件定義 (RTO/RPO) 障害識別 回復性実装 信頼性のある デプロイ フィードバック 改善 分析 ポストモー テム 回復性テスト 反応＆対処 アラート @postman_japan
22. OODAループ - 意思決定のフレームワーク • John R. Boyd 元米軍大佐が提案した戦場で勝利するためのフレームワーク • OODA(Observe-Orient-Decide-Act) を継続的に繰り返し、迅速に意思決定を行う • 不確実性の高い状況においては PDCA (Plan-Do-Check-Act)よりも常にシステムの課題や存在意義 を 認識し、方向づけ、意思決定、行動を繰り返す OODAループがフィットしていると言われている ◦ OODAループ: 計画ではなく先に観察。迅速な意思決定が必要な時に適している ◦ PDCA : ゴールや工程がはっきりしている時に適している https://en.wikipedia.org/wiki/OODA_loop John Boyd’s OODA loop 観察 方向づけ 意思決定 行動 参考情報 @postman_japan
23. 目標設定と優先度付け リソースは有限。目標設定と優先度付けしてほどよい品質を目指す • SLO / SLA設定 ◦ 追求すべき品質目標の定量化と、リソースの配分や優先順位付けを行う ◦ SLO (Service Level Objective): 期待されるパフォーマンスレベルの定義 (例: 99.9%の稼働時間、 応答時間が1秒以下など) ◦ SLA (Service Level Agreement): 品質レベルやサービスレベルを文書化した契約 • サーバ監視からサービス監視へ視野を広げる ◦ サーバの故障ではなくユーザーが実際にどのようにサービスを利用できているかを直接評価 ◦ メトリクス（例：ユーザーのレスポンスタイム、エラーレートなど）を追跡 ◦ 外形監視、E2Eテスト、SLO/SLI、カオスエンジニアリング @postman_japan
24. ビルディングブロック Building Block
25. ビルディングブロックとは？ ソフトウェア開発において基本となる概念で、特定の機能を持つ再利用可能なコンポー ネントやモジュールのこと。これらを活用し効率的に組み合わせることで、開発時間の短 縮とプロセスの単純化、全体の生産性向上が望める • フレームワーク • ライブラリ • クラウドサービス • マイクロサービス • データ処理基盤 https://en.wikipedia.org/wiki/Building_blocks_(toy) @postman_japan
26. ビルディングブロックの活用メリット・デメリット メリット • 開発速度向上 • コスト削減（規模にもよる） • 保守性向上 • 新陳代謝しやすくなる ビルディングブロックの活用には次のようなメリット・デメリットが存在する： デメリット • カスタマイズ性 • パフォーマンス（最適化の観点） • 学習コスト（ものによる） • 依存性（ロックインの懸念） 「作りすぎない技術」というコンテキストにおいて特に際立った活用メリットは「新陳代謝し やすくなる」ことです。最適なパーツを取り込んで自己を進化させることができます @postman_japan
27. ビルディングブロックに必要な設計特性や原則 • システムは独立したモジュール群で構成され、小さな単位で交換可能になっている （高い変更容易性） • 各モジュールは適切な単位に分離・分割されている（高凝集、関心の分離） • 各モジュールのI/Fは実装と分離され、結合度は弱い（疎結合） Interface Business Logic Database 各モジュール @postman_japan
28. システムの更新頻度と変更容易性について 変更容易性が低いシステムにおいて • 更新がほとんど発生しない場合、変更容易性の影響は少なく、ビルディングブ ロックで構築するメリットは低いかもしれない • 変更頻度が高い場合は、変更容易性の低さそれ自体が技術負債の種となり、ビ ジネスの競争力低下につながる可能性が高くなる ◦ 局所的な改善がやりづらい ◦ 特定箇所の問題が広範囲に波及しやすい ◦ リリースコストが高い @postman_japan
29. モジュール分離の考慮ポイント アーキテクチャによって考慮ポイントは変わってくる。サービスを分離する場合、システム は大きく複雑化されるため、考慮ポイントは増える 参考 モジュラーモノリス • モジュールの境界設定 • モジュール間のインターフェース • データ一貫性管理 • テスト戦略 • デプロイメント戦略 マイクロサービス • サービスの境界設定 • サービス間のインターフェース（ API） • データ一貫性管理 ◦ 分散トランザクション ◦ 結果整合性 ▪ pub/sub ▪ イベントオーケストレーション • サービス間通信の回復性管理 • テスト戦略 • デプロイメント戦略 @postman_japan
30. MACHアーキテクチャ Microservices-based, API-first, Cloud-native SaaS, Headless • マイクロサービス、API ファースト設計、クラウドネイティブ活用、ヘッドレス構成の 4 つで、迅速な開 発、スケーラビリティ、柔軟性、セキュリティなどを実現 • フロントエンドはバックと分離されAPIを通じてデータを取得し、柔軟にUI構築が可能 What is MACH Architecture? https://www.sunriseintegration.com/learn/what-is-mach-architecture API-first : APIを最初に設計・開発するアプ ローチ。サービス間の通信や外部システムとの 統合が容易になり、再利用性と一貫性が向上 Headless: フロントエンドとバックエンドを分離。フ ロントエンドはAPIを通じてバックエンドからデータ を取得し、自由にUIを構築可能 API時代の ビルディングブロック @postman_japan
31. コンポーザブルアーキテクチャ Composable Architecture • アプリケーションを再利用可能なコンポーネントとして設計する設計原則 • コンポーネントの組み合わせることに焦点を当て、ビジネスの変化への迅速な対応を重視 • コンポーザブルアーキテクチャの中核要素はAPIファースト How do composable, headless and MACH compare? The key differences explained https://commercetools.com/blog/how-do-composable-headless-and-mach-compare-the-key-differences-explained API時代の ビルディングブロック
32. アーキテクチャと開発コストの関係 Composable Software Architectures are Trending: Here’s Why？ https://blog.bitsrc.io/composable-software-architectures-evolution-b8a40322bb99 参考
33. API時代の正しい作り方 Application Programming Interface APIとはインターフェース
34. ソフトウェアコンポーネントの共通語としてのAPI テクノロジーの進化でより重要性が増すAPI • モバイル、クラウド、クラウドネイティブ技術 • マイクロサービス、イベント駆動アーキテクチャ • 5G技術、IoT • AI @postman_japan AIの時代において、全てのマジックはAPIを 通じて起こる。APIが提供されていることが重要 In The Age Of AI, Everything Is An API https://www.forbes.com/sites/forbestechcouncil/2023/09/18/in-the-age-of-ai-everything-is-an-api APIs act as a kind of lingua franca for different software components, providing a set of rules and protocols for them to communicate. In the AI context, they serve as the bridge between intelligent systems and the services they need to access. This is crucial for enabling “context-aware” interactions. It’s one thing for a chatbot to claim it can check real-time weather updates; it’s another for it to actually pull this data from a weather service and present it in a user-friendly manner. This magic happens through APIs.
35. APIを中心としたサービス戦略 APIファースト @postman_japan
36. 正しいAPI(インターフェース)の抽象化とデザイン APIはレゴブロックに似ている。APIは、利用者のニーズに基づいて、抽象化され分解さ れた機能がブロックとして提供されることが望ましい。そして、利用者のユースケース は、そのブロックを組み合わせて開発される UML Sequence Diagrams: An Agile Introduction - Seminar use case https://agilemodeling.com/artifacts/sequencediagram.htm
37. APIファーストの世界 https://api-first-world.com/ja/ @postman_japan
38. APIはプロダクト (API as a Product) • APIをプロダクトとしてAPI中心で考える ◦ APIは主要ソフトウェア構成要素、主要ビジネスアセット ◦ APIがビジネスにもたらす価値に焦点を当てる ◦ 内外サービスをAPIを通じて活用しビルディングブロックで構築 • APIファースト採用のために必要な取り組み ◦ APIライフサイクル全体で取り組む ◦ APIの継続的な保守・運用のためのチーム体制を構築する @postman_japan APIファーストの世界 https://api-first-world.com/ja/
39. APIファースト開発モデル • 焦点はAPIの設計（システムの抽象的な「契約」） • コードを書く前にAPIを設計・構築し、モック、ドキュメント、テストも作成 • 設計フェーズでフィードバックループを通じて設計内容を洗練化 API-first software development for modern organizations　 https://medium.com/better-practices/api-first-software-development-for-modern-organizations-fdbfba9a66d3 API設計 テスト APIドキュメント 作成 モック作成 実装 コーディング 統合 テスト実行 監視実行 サーバー環境 Dev Stage Prod モック活用 テスト ドキュメント 活用 コードリポジトリ モックを元にレビューや フィードバックを受け 設計内容を洗練させる check-in デプロイ エンドポイント にテスト API開発環境 @postman_japan
40. APIファーストな開発プロセスに関する意見 API Spec Documentation Mocks Tests Code Stubs Client SDK Defining & Designing Building Testing Deployment Monitoring & Observing Existing Code • APIファーストは実装を開始する前にインターフェースの詳細設計を完了させるため、不確実性と相 性が悪いBig design up front (BDUF)のアプローチ に似ているという意見もある。しかし、API ファーストではその後のプロセスでアジャイルの手法を取り入れることで、不確実性に強い開発が可 能であり、アジャイル開発と十分に相性が良いと考えることができる • 外部システムや多数のサービスに依存するアプリ開発においてインターフェースが不明瞭なまます すめることは逆に非効率であり、その後の開発を不確実なものにする可能性が高い @postman_japan
41. PostmanはAPIファースト開発 の実践をサポートする APIプラットフォーム
42. PostmanはAPIプラットフォーム • APIライフサイクルの管理 • APIガバナンスの策定・実施 • コラボレーションの促進 What is an API platform? https://www.postman.com/api-platform/ API利用者と提供者に対して次のことを支援：
43. APIファースト開発を支援するAPIプラットフォーム API提供者と利用者のAPI開発ライフサイクルを支援 @postman_japan
44. Postman API Platform Landscape @postman_japan
45. まとめ
46. 我々のリソースは有限です。その中で効率的かつ効果的に開発を行い、生産性を向 上させるためには、過剰な設計開発や技術の導入を避けることが重要です。また、限 られたリソースの中でどこに重点を置くのかを明確にすることも不可欠です。 みなさまの今後の開発の参考になりましたら幸いです。 @postman_japan
47. Postmanイベント Postman API Night(勉強会)＆ワークショップ https://postman.connpass.com/ Please Follow us - Postman イベント情報 Postman Japan X https://twitter.com/postman_japan
48. ご清聴いただき、ありがとうございました @postman_japan