JSUG 2018 BTC

JSUG
API時代の仮説検証開発の提言とツール
～API編～
株式会社ビッグツリーテクノロジー＆コンサルティング
SI事業部アーキテクチャG
音森一輝

2Copyright © 2018 Bigtree Technology&Consulting Ltd. All Rights Reserved.
自己紹介

音森一輝
（株）ビッグツリーテクノロジー＆コンサルティング
（BTC）
新卒2年目
早稲田でくまさんを作る
およいで
うたって
おさけをのむ
自己紹介

従来の開発

従来の開発
開発あるある
要件定義設計開発テスト運用・保守
クライアント
ベンダ
試しに画面
レイアウト
作ってみま
した！
ここの
イメージは
ちょっと
違う…
こんな感じ
で設計して
みました！
ユーザ属性
が1つ抜け
てた…
実装の都合
上、設計を
変えさせて
ください！
検証環境で
触ってみた
いんだけど
バグ要望バ
グバグ要望
要望バグバ
グバグ要望
序盤で漏れなく検討する必要がある

まず
プロジェクトのあるある

それから
ちょっと未来の開発手法

実例

2つの粒度のプロジェクト
実例
粗粒度細

実例1

プロジェクト概要
• 半年間設計／プロト開発、一年間本開発
• 複数ベンダのAPIと連携する
• フロントとAPIの開発
実例1
フロント
API
API ベンダA ベンダB
データ
細かいところまで仕様が決定している

並行開発システムの特徴既存
なし設計書あり
本番も叩ける環境検証も叩けない
読めるソースコード読めない
実例1
ベンダA ベンダB
全く性質の異なるAPI

設計書
環境
ソースコード
実例1
コミュニケーションレイヤ
クライアント（APIを使う人）
ベンダ（APIを作る人）
どの層で議論するかは重要

ベンダA 「返戻値で成功したか判定してください」
私「なんだか挙動がおかしいです」
ベンダA 「返戻の形式を変えてしまいました」
私「修正が必要ですね…」
実例1
ベンダA・並行開発
実環境は叩けるけど、変更が生じる

私（APIを使う人）
ベンダA・並行開発（APIを作る人）
実例1
何が起こったか？
設計書
環境
ソースコード
環境を叩きな
がら開発を進
めていた
ソースを変
更して環境
に反映した
環境から返戻さ
れる値が異なる
ことに気づいた

設計書
環境
ソースコード
実例1
どうすべきだったか？
ソースを変更し
たので確認して
おいてください
環境に反映した
ので確認してお
いてください
設計書に反映し
変更について即時伝達すべき

ベンダB・既存
ベンダB 「設計書を見て開発してください」
私「検証環境はいつから叩けますか？」
ベンダB 「8月からでお願いします」
私「総合テスト（9月）直前ですね…」
実例1
設計書はあるけど、正しいかわからない

設計書
環境
ソースコード
ベンダB・既存（APIを作る人）
実例1
何が起こったか？
設計書を見な
がら開発を進
めていた環境を叩き
ながら開発
したかった
ソースコード
と設計書の乖
離があった
連携テスト
で確認

設計書
環境
ソースコード
実例1
どうすべきだったか？
ソース
コードを
公開
環境を
用意して
公開
設計書の
整備を
確実に
設計書の信頼性を担保すべき

実例2

実例2
コミュニケーション齟齬の危険性
• クライアントが遠方
• 対面で説明できない
• 要望はなんとなくしか決まっていない
• API仕様はBTCが検討
クライアント

実例からの課題点
仕様の粒度を細かくしたいクライアント
ベンダA
ベンダB
変更について即時伝達したい
設計書の信頼性を担保したい
粒度が荒い
粒度が細かい
ちょっと未来の開発手法

仮説検証開発

仮説検証開発
仮説
仮実装
入出力設計検証
仮説検証とは？
• クライアントの要望が正しいかどうか
• 仕様が正しいかどうか
• 動いてるシステムが正しいかどうか
正しいものに近付ける
万能ソリューション

仮説検証開発
仮説
仮実装
使う人
作る人
どんなシステム
にしたいか
イメージはあり
ますか？
完璧には具
体化できて
ない…

仮説検証開発
仮説
仮実装
入出力設計検証使う人作る人
試しにAPI
仕様書を
作ってみま
した！
この構造だ
とここの
項目が足り
ない…

仮説検証開発
仮説
仮実装
使う人
作る人
項目を加え
て実装しま
した！
実際に叩い
てみても
いいかな？

仮説検証開発
仮説
仮実装
入出力設計検証使う人作る人
検証環境にあ
げました！
おお！
イメージ
どおり！
仮説検証を繰り返し
齟齬をなくしていく手法

仮説検証開発を適用
仕様の粒度を細かくしたいクライアント
ベンダA
ベンダB
変更について即時伝達したい
設計書の信頼性を担保したい
①早い段階で検証する
③ドキュメントの乖離をなくす
②検証のサイクルを回し続ける

それらを支援するツール
あります

①早い段階で検証するクライアント
• REST APIを記述するためのオープンフレームワーク
• ymlファイルで管理（JSONも使用可）
• Swagger EditorでSpecificationを編集
• Specificationからコードを自動生成
Swagger

設計書
環境
ソースコード
遠方のクライアント（APIを使う人）
何をしたか？
Swaggerを使
用してエンド
ポイントや入
出力を整理
仕様が荒い段階から仮説検証を繰り返す
BTC（APIを作る人）
実際に叩いて入
出力を検討
開発
デプロイ
検証

Swagger デモ

• メリット
 実際に叩ける
 ymlファイルをgitで構成管理できる
• デメリット
 ソースコードと連携していない
 リビジョンへの対応が必要
Swagger

②検証のサイクルを回し続けるベンダA
• Springのソースコードから仕様書を自動生成できる
ツール
• アノテーションを付与して設定
• Swagger UIでクライアント画面を作成
• CIツールと組み合わせることで即時通知可能
SpringFox

設計書
環境
ソースコード
どうすべきだったか？（再掲）
ソースを変更し
環境に反映した
ので確認してお
いてください
設計書に反映し
変更について即時伝達すべき

SpringFox デモ

SpringFox
• メリット
 ソースコードと結びついた仕様書を自動生成
• デメリット
 動くコードかは保証できない

③ドキュメントの乖離をなくすベンダB
• Springのテストコードから仕様書を自動生成できる
ツール
• テストに成功した結果をドキュメントとして出力
Spring
REST Docs

設計書
環境
ソースコード
どうすべきだったか？（再掲）
ソース
コードを
公開
環境を
用意して
公開
設計書の
整備を
確実に
設計書の信頼性を担保すべき

Spring REST Docs デモ

Spring REST Docs
• メリット
 テストに成功した結果なので信頼性が担保
• デメリット
 設計ドキュメントには向いていない

設計書
環境
ソースコード
まとめ
3つのツールの関係
クライアント（APIを使う人）
Swagger
SpringFox
Spring
REST Docs
ベンダ（APIを作る人）
ソースコードから
ドキュメントを生成
モックやスタブの
生成が可能
ローカルでも
動かせる
実行すると
画面から
叩ける
テストコードから
ドキュメントを生成

まとめ
Swagger SpringFox
Spring
REST Docs
実装コスト
※ 小中大
即時性 × ○ ○
信頼性 × △ ○
※仕様の粒度が荒い場合
3つのツールを比較

まとめ
• 仕様が曖昧な、正解がわからない開発には
仮説検証開発
• 設計書、環境、ソースコードの各レイヤで
最大限効果を発揮するツールを選択
• プロジェクトのリソース（工数）や規模、
スピード感とのバランスを保つことも重要

仮説検証開発という仮説

ありがとうございました

JSUG 2018 BTC

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a JSUG 2018 BTC

Semelhante a JSUG 2018 BTC (20)

JSUG 2018 BTC