LINE 株式会社の 田籠 聡さん (id:tagomoris) の講演。昨年の Cloudera World Tokyo 2013 では Norikura のお話をされていたので今回もそうかなと思ったけど全然そんなことはなく今回は社内システムもちゃんと考えて作ろうねというお話。最近、社内システムのこと考える機会も増えてきたので興味深く聞かせていただきました。
Dev of Ops, by Ops, for Ops
- 社内システムほど他システムとの連携を考えよう
- 社内システムでは JSON API を使おう
- 実装は必要なとことから必要なことをやろう
Open Web API
- トラフィックやレスポンスタイムが重要な指標
- いろんなところから使われるのは良いがコストは誰が払うのかという問題？
- 互換性の問題、FB など API が結構ころころ変わる
- 制限がかかるようにもなってきた
Closed Web (社内システム)
- 機能 > 性能
- 想定される使用期間は長く、問題点はあっても長い間放置されがち
- ターゲットユーザーは自分。人事系のシステムだったりしても一番使う人は人事部ではなく社員だったりする
何が問題なのか？
- 情報と権限の分断 : 誰が何を見られるかわかりづらい
- 情報と機能の冗長化 : 同じ情報がいろんなところにある
- UX の欠如 : 社内システムほど適当に作られている（たしかに！）
- 自動化の障壁
- アップデートが不可能、IE とかマクロとか
社内システムの連携方法を考える
- 案1 : DB を直接見る -> 密結合になってしまう
- 案2 : SOAP/CORBA... -> SOA （複雑）
- 案3 : RPC プロトコル (ProtocolBuffer, Thrift, XML-RPC, MessagePack-RPC...)
- シンプルにしたい
- 権限の分断を最小限に
- 機能・情報には複数の参照方法を持たせた方が良い（例えばブラウザからのアクセスと API）
- Angular みたいなクライアント JS などを使って API を UI からたたいて表示するように作るのも良いのでは
- モジュール化。単機能システムを連携させる、アップデートが容易な状態を保つ
- 社内システムほど他システムとの連携を考えよう。機能を API として提供する。
- コストやパフォーマンスはさほど問題にならない
- API 互換性を保つ
- プロトコル -> Http を最優先で選んで良いのでは？curl 叩いてのテストのしやすさ。
- データ構造 -> JSON
- 意味の一貫性（返り値の意味等）
- クライアント案件の普遍性、不変性
- 長期運用においてきちんとアップデートできる
- 見た目のわかりやすさ、データ内容のわかりやすさ
- ドキュメントは風化するし属人性も強い。自分の目で見られるのが重要
- curl is great, テストが容易。100ページのドキュメント読むよりまず叩いて簡単に確認できる
社内システムの作り方
- 動くことが大事。ドキュメントは大事か？
- 今欲しい機能を作る
- 機能を切り刻んで優先度をつけて作る
- 修正単位を最小化する
- 今要らないのなら後でやれば良い。いつでもできる
- 後でやれば良いのなら今後いつ必要になるか考えない
- 要件定義は難しいから後回しにする
- 積極的にさぼる
- アーキテクチャの割り切りが開発、運用を加速する
- 開発運用の前提がアーキテクチャをシンプルにする
- ビジネスのインパクトを考えると、社内システム程いろいろ試しやすい場所は無い
所感
新規開発については言わずもがなで、例えパッケージ買ってくるにしても今後はこういう視点はあるべきだと思う。
あとは旧世界の遺物みたいな既存システムとデータをどうするかとか、全社的な取り組みな以上はちゃんと部門（ユーザー）を横断して企画運用できる体制と自社開発できる体力、そして業務効率化への理解が必要…と書いていて最近の社内向けビッグデータ活用事例（e.g., GREE さんのゲーム解析基盤）とかってまさにそういう条件が揃ってできてるのかしらと勝手に納得しました。
それと最後の優先度云々の話は個人的には社内システム開発に限らずいつも胸に抱いていたい感じのメッセージだと思っています。
あと内容と関係ないですが畳み掛ける感じのプレゼンに若干病み付きになりつつあります。
