kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

社内システムの構造と設計、実装のはなし@デブサミ2014

勉強会 インフラ デブサミ

2/13(木)、14(火) に目黒の雅叙園で開催された「Developers Summit 2014」の参加レポート#4です。

f:id:kentana20:20140214183727p:plain

社内システムの構造と設計、実装のはなし（田籠聡〔LINE〕）

@tagomorisこと田籠さんは人気のログコレクタであるFluentdやストリームデータに対してSQL的処理ができるNorikraをはじめとした様々なOSSのコミッタとしても有名で、Fluentdユーザなら一度は田籠さんのブログやプラグインに辿り着いた事があるのではないでしょうか。

そんな田籠さんによる社内システムについてのセッション。社内システムだからこそ、考えなければいけないことがいっぱいあるよ！という有り難いお話。

Webサービスの昨今

Web2.0マッシュアップ全盛期だった時代からOAuthが流行して支配的になった。WebAPIについては負荷が掛かり過ぎるとサービス提供に影響が出てしまうため、GoogleMapのように利用が制限されつつある（単位時間当たりのAPI呼び出し回数に上限値が設けられたり、超えた場合は課金されたりするようになった）。

社内システムの特性

  • ClosedなWebシステム（であることが多い）
  • 利用者（利用環境・利用人数）に限りが有る場合が多いため、性能よりも機能が優先されやすい
  • ライフサイクルが長い（構築後、運用が始まるとなかなかリプレースや機能変更が行われない）
  • 認証、データ蓄積、解析、可視化、便利機能・便利UIなど、様々な機能を要求される
  • エンドユーザは自分たちである

社内システムの問題点

  • 情報と権限の分断
    • 「誰が何を閲覧できる」とか「どこに何があるか」などがわかりづらくなってくる
  • 情報と機能の冗長化（無駄な冗長化）
    • 社内にパスワードが複数あったり、システムごとにオペレータが別々に作られてたりとか、無駄な意味での冗長
  • UXの欠如
    • 画面項目の多さ、煩雑さ
  • 自動化の障壁
    • 権限によって表示されたり、されなかったり、認証が必要だったり
  • 全部入り（アップデート不可能）
    • Excelマクロとかでゴリゴリ作りこまれたシステムはアップデートの障壁になる

社内システムとの連携

  • DBを直接参照
    • 別システムのDBを直接参照・更新するような作りにすると密結合になってしまい、負の遺産へ繋がってしまう
  • SOAP
    • @tagomorisさん曰く「なかったコトにしたい」
  • CORBA
    • @tagomorisさん曰く「こんなんあったな。。」
  • SOA!!
    • 一時期はよく言われたが、SOAソフトウェアが高コストだったり、認証の仕組みを考えたりと色々手間がかかる

社内システムのプラクティス（Make It Simple）

  • 権限
    • 権限の分断を最小限に
  • 機能
    • 1つの機能について「Web画面」と「API」など、複数の参照方法を確保する
  • モジュール化
    • 単機能をモジュールに区切り、モジュール同士を連携させることでメンテナンスしやすい状態を保つ

社内システムほど、外部システムとの連携を考えよう

  • API互換性 API互換性を保つことが大切。互換性を保った状態であれば、内部やプラットフォームのリプレイスを容易に行うことができる
  • 長期運用 長期運用を考慮して、メンテナブルな状態を保つ必要がある

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

  • データの見やすさ（JSON） アップデートのしやすさ≒データの見やすさ　なので、JSONが良い

実装は必要なところから必要なだけやろう

  • 動くことが大事 とにかく、「動くこと」が大事。100ページのドキュメントは誰も読まない。100ページのドキュメントより、1つのサンプルの方がわかりやすい。これは若干言い過ぎかもしれませんが、方向性には賛成です。「動くものを大事にする」アジャイルの考えに沿っています。
  • 「こんなこともあろうかと」的な機能はいらない（優先度ハック） 「いま、必要なもの」を作ってリリースすることが重要。
    • いま、必要な機能を並べる
    • 機能を切り刻む
    • 刻んだ機能を疎結合にして、優先順位を決める
    • 修正単位を最小化する こんな感じで「優先度をハックする」とお話をされていました。良い表現です。
  • 将来の要件定義は難しい（逆優先度ハック） 「いまはいらない」のであれば、後でやればよい。「今後何が必要か」はいま考えなくてよい。間違いないです。最小単位が大事だと思いました。

開発・運用・アーキテクチャ

  • アーキテクチャの割り切りが開発を加速させる（疎結合に振ることが大事）
  • 社内システムほど、試しやすい場は無いので色々なチャレンジができる（顧客は自分たちなので、ビジネスへのインパクトも少ない）

まとめ（個人的な主観）

  • 社内システムは他システムとの連携が多いのでJSON APIで疎結合なシステム構成にする
  • いま、必要な機能にフォーカスして最小単位で開発・修正を行う
  • 色々試せる場なのだから、社内システムだからと手を抜かず（Excelマクロとかのやっつけではなく）シンプルで機能的な構成にする

所感

田籠さんのスライドは普段は英語が多いのですが、今回はデブサミだったから（色々な立場の人が多く集まる場だから）か、日本語のスライドでした。社内システムって、本当に手を抜いて（コストをかけずに）作ることが多いので、今回の視点・観点はとても重要だと思いました。Excelマクロとか、かなりグサっとささる部分が多いのでこういった考えを社内に浸透させて、社内システムもシンプルで健全な状態を維持できるようにしなければいけないですね。

また、「試す場」という観点も今までの仕事ではあまり考えてきてないと反省させられました。自分の場合、試してみたくなったらユーザ側のPVが少ない部分でやってみようとか、主導線ではないユーザ画面で試そうとかんがえることが多かったので、「社内システムで試す」ということも考えの1つとしてこれからの開発に向き合おうと思います。