Embed Size (px)
DESCRIPTION
本番用はこちら http://www.slideshare.net/tagomoris/devsumi2014-tagomoris
Citation preview
社内システムの構造と設計実装のはなし
Developers Summit 2014 [13-B-3] devsumiB20140213tagomoris (TAGOMORI Satoshi)
TAGOMORI SATOSHI (TAGOMORIS)LINE CORP
DEVELOPMENT SUPPORT TEAM
まとめ
社内システムほど他システムとの連携を考えよう
つまり機能をAPIとして公開しよう
社内システムではHTTP JSON APIを使おう
実装は必要なところから必要なだけやろう
Webサービス今昔
Web20 とかマッシュアップ全盛期
OAuth 全盛期
WebAPI 制限期
Open WebにおけるAPI
トラフィックレスポンスタイム
誰がコストを払うの
互換性
API提供元もやり直したくなることは(よく)ある
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
TAGOMORI SATOSHI (TAGOMORIS)LINE CORP
DEVELOPMENT SUPPORT TEAM
まとめ
社内システムほど他システムとの連携を考えよう
つまり機能をAPIとして公開しよう
社内システムではHTTP JSON APIを使おう
実装は必要なところから必要なだけやろう
Webサービス今昔
Web20 とかマッシュアップ全盛期
OAuth 全盛期
WebAPI 制限期
Open WebにおけるAPI
トラフィックレスポンスタイム
誰がコストを払うの
互換性
API提供元もやり直したくなることは(よく)ある
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
まとめ
社内システムほど他システムとの連携を考えよう
つまり機能をAPIとして公開しよう
社内システムではHTTP JSON APIを使おう
実装は必要なところから必要なだけやろう
Webサービス今昔
Web20 とかマッシュアップ全盛期
OAuth 全盛期
WebAPI 制限期
Open WebにおけるAPI
トラフィックレスポンスタイム
誰がコストを払うの
互換性
API提供元もやり直したくなることは(よく)ある
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
Webサービス今昔
Web20 とかマッシュアップ全盛期
OAuth 全盛期
WebAPI 制限期
Open WebにおけるAPI
トラフィックレスポンスタイム
誰がコストを払うの
互換性
API提供元もやり直したくなることは(よく)ある
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
Open WebにおけるAPI
トラフィックレスポンスタイム
誰がコストを払うの
互換性
API提供元もやり直したくなることは(よく)ある
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
社内システムの機能認証
資産管理
動作状況モニタリング
データ蓄積
可視化
情報共有
プロトコル変換
便利UI提供
バージョン管理
helliphellip
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
何が問題なの情報と権限の分断どこになにがある どこで検索すればいいの
情報と機能の冗長化同じ社内でいくつパスワード持たせるんだよ
利用者の効率を考えないシステム勤怠入力300人の労力 gtgtgtgt 人事3人の労力
自動化の妨げになるシステムそこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステムUIを持つシステム rarr クライアント更新も不可に
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
社内システムの連携DBを見る
SOAP CORBA
猫も194780子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer Thrift XML-RPC
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
Make it simple権限 分断を最小限にしよう
全員参照できてよい情報がほとんどでは
機能 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化 単機能システムを連携させよう
アップデートが容易な状態を保つ
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
1 社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
Closed WebにおけるAPIトラフィックレスポンスタイムデータ量が通常小さく問題になりにくい
誰がコストを払うの会社
互換性これが最大の問題API互換性を維持 + UIのアップデート
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性不変性
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
Protocols of internal APIThrift Protocol Buffers MessagePack-RPC
IDL
Performance
FTP RSH SSH
HTTP
SOAP XML-RPC MessagePack over HTTP
JSON
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
長期運用を前提にしようアップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる
テストの容易さ
curlで叩きたい
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
テスト容易性まじだいじ自動テストではなく人が試すこと
百聞は一見に如かず
ちょっと試して何が返ってくる何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
FacebookですらRPCはHTTPでよい (expresto)
疎結合
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
2社内システムではHTTP JSON APIを使おう
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
実装
社内システムですよ
自分達で作り自分達で使います
動くことが大事
ドキュメント大事
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
優先度使う機能使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら
いま欲しい機能
簡単に実装できるいますぐには使わない機能
欲しい気がするけど微妙な機能
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
優先度ハックまあ忙しいよね
それ本当にJSON APIひとつ追加する30分も割けないくらい忙しいの
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本当にそんなに難しい
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
逆優先度ハック切り刻まれた細かい機能追加タスク
それ今いらないなら後でやればいいのでは
だっていつでもできるでしょ
後でやればいいなら今後何が必要か考えなくていいのでは
(将来の)要件定義は難しいなら後回しにしよう
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
3実装は必要なところから必要なだけやろう
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
アーキテクチャと開発運用の関係
アーキテクチャの割り切りが開発運用を加速する
開発運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
ビジネスへのインパクト社内システムほど試しやすい場は無い
誰か損する
誰もが得するでしょ
顧客は自分
自分が嫌なものは作らないでしょ
自分が使いたいものを使えるでしょ
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
TO MAKE IT SIMPLEMAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE
LETrsquoS DO WITH YOUR OWN SYSTEMS
