My External Storage

ソフトウェアエンジニア向けTips。Qiitaにもメモ

Developers Summit2014[13-B-3] 社内システムの構造と設計、実装の話

[13-B-3] 社内システムの構造と設計、実装の話

開発支援Gに所属。サービス提供、分析など社内サービス全般。
livedoor BlogなどLINE以外も幅広くサービス提供

Dev of Ops,by Ops, for Ops.

アジェンダ

  • 社内システムほど他システムとの連携を考えよう。
  • 社内システムはJSON APIを使おう。 

Web2.0 マッシュアップ全盛期

OAuth流行で支配的に(認証を連携して「来ました」とかツイートしたりとか)
しかし、WebAPIの制限が多くなってきている。プログラムからのCall制限などもあった。
オープンなWebAPIではトラフィック、レスポンスタイムが重要になる。
そしてその大規模サービスのバックエンドサービスとなった場合、誰がコストを払うのか?
互換性も依存先にAPIに変更が入ると困る。公開元が納得できなくてAPI変更することも。。。ていうかみなさんしますよね!

では社内システムは

だいたいが社内イントラネットを利用したClosed Webシステム。
機能>性能。有限社員なので、性能が問題になることはない。
社内システムは長生きする。欠点はわかっているが、放置されがち。
社内システムなので、ターゲットユーザーはまず自分自身。自分が使う。
人事システムだったら、人事が設計するが、結局はヘビーユーザーは勤怠を入力する人である。
そして、機能は多岐にわたる。

では何が問題なのか?

情報と権限の分断

情報を入力・管理する人と、情報の権限を持っているが異なっている。(認証とか人事情報とか)

情報と機能の冗長化

社員名簿が何種類もあったり、同期が遅かったり、パスワードが一元化されてなかったり

UXの欠如

インターフェースがクソ!

自動化の障壁

既存のシステムの古い部分が壁となる。(いちいち認証したりとか)

全部入り:アップデート不可能

IE8しか動かないとか!!

解決策としてはDBを直接編集、SOAPCOBRASOAなどあったが。。。
RPCプロトコルも社内というよりも、大規模サービルに対する方法。

社内システム連携:Make it simple!

権限:分断を最小限に

閲覧権限にどれだけ階層があるのか?参照に関してフラットにしていけばよい(大企業はべつだろうが)

機能:情報には複数の参照方法を

例えばブラウザで見る。WebシステムならばAPIが必ずあるはず。
参照元が公開APIを叩く仕組みになっていれば、WebUIとデータが結びつくことはない。

モジュール化:単機能システムを連携させる。アップデートが容易な状態を保つ

オブジェクト志向のようなもの。無意識な巨大化はメンテが不可能になる。

社内システムほど他システムとの連携を考えよう。機能をAPIとして公開しよう

最初からAPIとして作成しておけば、インターフェースだけみて連携操作ができる。自動化などができる。
APIを守っていれば、他のシステムとの連携に不備なくアップデートができる。保守性があがる。

トラフィック、レスポンスタイム

なかなか無いので、割愛。

コスト

会社が払うので割愛。

互換性

疎結合で小さいビューならば変更が容易。ひとつのビューに複数の機能がマージされているとひとつの変更が大きく影響をおよぼす

API互換性

プロトコル、データ構造、意味の一貫性、クライアント要件の不変性/普遍性
ドキュメントに頼ると長生きシステムなので、腐敗化していく。

プロトコルクロースドウェブAPI

HHTPプロトコルならば、浸透しているし、しばらくなくならないだろう。
データの書式はどうするのか?JSONが一番いいんじゃないのか。

長期運用

データの所在や管理情報の一番安全な管理方法はベタに自分で確認できること。ドキュメントは陳腐化する
個人的な感覚だとJSONの書式がベストなのでは。XMLとかは見た目がわかりにくい。

きちんとしてアップデート、容易さ、データ内容の把握

移行時にどう確認するのか。

テストの容易さ

コマンドラインから直接手で容易に確認できるデータ形式はあまりない。
RESTなどならわかりやすい。

百聞は一見にしかず

  • 1 time curl >>> 100 pages docs
  • ease to try >>> performance
  • losely coupled >>> strict protocol(疎結合の重要性)

社内システムではJSON APIを使おう

社内システムの実装

社内システムは動くことが大事。
ドキュメントよりはわかりやすい動作のほうが大事。
利益がないので「こんなこともあろうかと」はいらない。
利用率調査をするだけでもマイナスになる。

社内案件なので、優先度ハックが可能。
自分たちで優先度を考えることができる。
機能を切り刻むことができる。
修正単位を最小化する。
切り刻まれた機能追加のタスクを個別に片付けることで、柔軟な開発、後回しにすることもできる。

JSONならあとでDB叩けばできるはず。それならば、あとでも対応できる。
ただ、後回しにできるものは結局不要なことが多い。。。

必要なものを必要なときにだけ作ればいいのではないか

アーキテクチャを割り切ることで開発・運用を加速する。

いつでもだれでも使えるAPI,細分化されたタスクのほうが、多少見栄えが悪くても運用効率はよい。
開発・運用の前提がアーキテクチャをシンプルにする。

ビジネスへのインパクトとしては社内システムほど試しやすい場はないので、実験には最適である。

まとめ

まず自らの環境でシンプルなものを試す、自分たちが使いやすいものをつくる。
開発・運用の前提が、アーキテクチャをシンプルにする。