Upgrade to Pro — share decks privately, control downloads, hide ads and more …

作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking ab...

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

Yoichi Kawasaki

June 27, 2024
Tweet

More Decks by Yoichi Kawasaki

Other Decks in Technology

Transcript

  1. ここでの「必要のないもの」とは • 本質的な課題を解決しないもの • 利用者のユースケースを実現しないもの • 冗長なもの • 代替可能なもの •

    過剰なもの(将来的に不要になる) • 維持管理が難しいもの(将来的に不要になる) @postman_japan イシューからはじめよ ――知的生産の「シンプルな本質」 https://amzn.to/3XK87VU
  2. YAGNI - 必要になるまで作らない YAGNI (You ain't gonna need it) 実際に必要となるまでは追加しない方がよいとするExtreme

    Programming (XP)にお ける原則 Yagni https://martinfowler.com/bliki/Yagni.html 推定・仮説に基づいて作る機能の3つの分類とそれぞれ YAGNIを無視した場合に発生する4種類のコスト • 構築コスト • 修理コスト • 維持コスト • 遅延コスト • 正しくない機能 • 間違って作られた正しい機能 • 正しく作られた正しい機能 @postman_japan
  3. 標準化されている / 相互運用性のあるものを選ぶ • 標準化 / 相互運用性のあるもの ◦ インターフェース、フォーマット、プロトコル ◦

    世界標準、組織標準 • 標準化 / 相互運用性のある世界はスケールする ◦ 学習コスト、コラボレーションコスト低減 ◦ 柔軟性、拡張性の向上 ◦ エコシステムの有効活用 / 巨人の肩の上に立つ • 独自技術・仕様のデメリット ◦ (将来的に) コスト高、属人化、技術的負債 @postman_japan
  4. その時点でのベストな技術スタックを選ぶ 技術的にイケてる(卓越)かどうかだけでなく、チーム 能力、制約などのバランスも加味する • 技術的な卓越性 ◦ 将来性、成熟度、パフォーマンス、セキュリティ、サポー ト、エコシステム • チームスキル・経験(練度)

    ◦ チーム練度、学習曲線、外部リソースが調達可能か • 制約事項(コスト・スケジュール) ◦ 保守性、開発・運用・ライセンス費用など ◦ 時間的制約 https://speakerdeck.com/twada/understanding-the-spiral-of -technologies-2023-edition 技術 卓越性 チーム スキル 制約 事項 @postman_japan 技術 選定 …
  5. 組織的開発における重複を排除する 組織開発における重複や重複がもたらす不要な開発の例 • 機能の重複開発 ◦ リソースの無駄遣い ◦ 統合時に互換性や一貫性の問題の原因になる • ドキュメンテーションの重複

    ◦ リソースの無駄遣い ◦ 互換性や一貫性の問題の原因になる • ツールやプロセスの重複 ◦ 全体的な効率低下、一貫性低下 ◦ 組織全体の改善が進みにくくなる @postman_japan
  6. 組織内における重複を排除する 重複 / 車輪の再開発を排除するための施策例 • コミュニケーション強化 ◦ チーム間インタラクションを通じた知識・スキル・自立性の 向上、重複排除 ◦

    チームトポロジーのチーム間の 3つのインタラクションモー ド:コラボレーション、ファシリテーション、 X-as-a-service • ツールとシステムの統合 ◦ 一貫性、効率性向上につながる • 標準化とガイドラインの策定 ◦ 同じ目的のツール、プロセスの標準化 ◦ 一貫性、効率性向上につながる チームトポロジー 価値あるソフトウェアをすばやく届ける 適応型組織設計 https://amzn.to/3KXKhyA @postman_japan
  7. 100点の品質の追求は難しい 複雑で不確実性が多い今日のシステム環境において、100点の品質追求は難しく、また 割に合わないことが多い • 多様な技術の統合・連携 ◦ クラウド、オンプレミス、モバイル、 IoTデバイスなど ◦ 異る技術の統合は複雑性を増大させる(サービス障害、ネットワーク遅延・断絶)

    • 継続的に更新される環境 ◦ クラウド、クラウドネイティブなプロダクトは頻繁なアップデートが前提 ◦ それに依存するシステムは頻繁なアップデートに追従が必要 • 急速な技術進化 ◦ 新しいツール、フレームワーク、プログラミング言語など前よりもよいものが日々登場 ◦ それに伴いアーキテクチャの正攻法も変化 • ビジネス環境の変動 ◦ 市場の変動、競争の激化、新しい規制や法令の導入など ◦ システムの適用を難しくし、不確実性を増大 @postman_japan
  8. ほどよい80点の品質を目指す戦略 100%の品質よりもほどよい80点の品質を高速かつ継続的に改善するアプローチ • 堅牢性よりも機動性と回復性 ◦ 障害の発生は可能な限り早期に検知する ◦ 障害から迅速に回復しダウンタイム時間を抑える (自己回復力や冗長性 )

    • 継続的テスト・改善 (Fail Fast) ◦ ライフサイクルの早いフェーズからテスト ◦ フィードバックを迅速に反映して逐次改善する • 目標設定と優先度付け ◦ どの程度の追求すべきか目標設定と優先度付けを行う @postman_japan
  9. “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
  10. Fail Fast - 問題の早期発見と対処 実践方法 - APIファースト (APIの場合) - テスト駆動開発

    (TDD) - 継続的インテグレーション (CI) - スクラム ⇒ アジャイル開発の基本理念と一致 Fail Fastの目的 - 問題の早期発見と対処 - リスクの最小化 - フィードバックの迅速化 - 継続的な改善 Define Design Develop Test Deploy Observe Distribute check check check check check ライフサイクルの後ろのフェーズになればなるほど改修コストが大きい @postman_japan
  11. フィードバックループと新陳代謝 • 一度作った終わりではなく、ソフトウェアライフサイクルにおける課題をフィードバッ クを元に継続的に改善させる • システムを新陳代謝させていくことが生存の鍵 • そのためには新陳代謝しやすい構造にしておくことが重要 計画 設計

    テスト 実装 デプロイ 監視 観測 問題 対処 要件定義 (RTO/RPO) 障害識別 回復性実装 信頼性のある デプロイ フィードバック 改善 分析 ポストモー テム 回復性テスト 反応&対処 アラート @postman_japan
  12. 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
  13. 目標設定と優先度付け リソースは有限。目標設定と優先度付けしてほどよい品質を目指す • SLO / SLA設定 ◦ 追求すべき品質目標の定量化と、リソースの配分や優先順位付けを行う ◦ SLO

    (Service Level Objective): 期待されるパフォーマンスレベルの定義 (例: 99.9%の稼働時間、 応答時間が1秒以下など) ◦ SLA (Service Level Agreement): 品質レベルやサービスレベルを文書化した契約 • サーバ監視からサービス監視へ視野を広げる ◦ サーバの故障ではなくユーザーが実際にどのようにサービスを利用できているかを直接評価 ◦ メトリクス(例:ユーザーのレスポンスタイム、エラーレートなど)を追跡 ◦ 外形監視、E2Eテスト、SLO/SLI、カオスエンジニアリング @postman_japan
  14. ビルディングブロックの活用メリット・デメリット メリット • 開発速度向上 • コスト削減(規模にもよる) • 保守性向上 • 新陳代謝しやすくなる

    ビルディングブロックの活用には次のようなメリット・デメリットが存在する: デメリット • カスタマイズ性 • パフォーマンス(最適化の観点) • 学習コスト(ものによる) • 依存性(ロックインの懸念) 「作りすぎない技術」というコンテキストにおいて特に際立った活用メリットは「新陳代謝し やすくなる」ことです。最適なパーツを取り込んで自己を進化させることができます @postman_japan
  15. モジュール分離の考慮ポイント アーキテクチャによって考慮ポイントは変わってくる。サービスを分離する場合、システム は大きく複雑化されるため、考慮ポイントは増える 参考 モジュラーモノリス • モジュールの境界設定 • モジュール間のインターフェース •

    データ一貫性管理 • テスト戦略 • デプロイメント戦略 マイクロサービス • サービスの境界設定 • サービス間のインターフェース( API) • データ一貫性管理 ◦ 分散トランザクション ◦ 結果整合性 ▪ pub/sub ▪ イベントオーケストレーション • サービス間通信の回復性管理 • テスト戦略 • デプロイメント戦略 @postman_japan
  16. 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
  17. ソフトウェアコンポーネントの共通語としての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.
  18. APIはプロダクト (API as a Product) • APIをプロダクトとしてAPI中心で考える ◦ APIは主要ソフトウェア構成要素、主要ビジネスアセット ◦

    APIがビジネスにもたらす価値に焦点を当てる ◦ 内外サービスをAPIを通じて活用しビルディングブロックで構築 • APIファースト採用のために必要な取り組み ◦ APIライフサイクル全体で取り組む ◦ APIの継続的な保守・運用のためのチーム体制を構築する @postman_japan APIファーストの世界 https://api-first-world.com/ja/
  19. 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
  20. 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
  21. PostmanはAPIプラットフォーム • APIライフサイクルの管理 • APIガバナンスの策定・実施 • コラボレーションの促進 What is an

    API platform? https://www.postman.com/api-platform/ API利用者と提供者に対して次のことを支援: