周辺システム: どこを内製することになるか
はじめに
街なかで自転車にのった配送屋さんを見るようになった。なぜトラックではなくて自転車が必要なのだろうか？トラックよりも自転車のほうが低コストであり、運転に技術もさほど必要ない。小回りが効くので、トラックよりも自転車が好まれるのだろう（もちろん、温室効果ガスを排出しないという利点もある）。
ITシステムにも配送を自転車で行うような領域は存在する。技術に先進的な会社ではAWSのlambdaやGASで通知を自動化しているだろう。また、SalesforceのようなCRMシステムからCSVを出力して、エクセルなどで分析している部署もあるかもしれない。そういったものはメインのシステムを中央として、周辺に展開していくことになる。そういったものを周辺システムと呼ぶ。
周辺システムの例
- DBの情報をredashを用いてCSVにダウンロードして、エクセルで確認する。この場合、redash及びエクセルが周辺システムにあたる。
- akerunの情報をスプレッドシートに出し、数式で出社者を確認する。この場合、googleスプレッドシートが周辺システムにあたる。
特徴
以下はすべて比較的な特徴である。
| 区分 | メインシステム | 周辺システム |
|---|---|---|
| 情報量・キャパシティ | 大量 | 少量 |
| 作業員 | 不要 | 要 |
| 主従関係 | 上位 | 下位 |
| 性能 | 高 | 低 |
| 作成タイミング | 先 | 後 |
| 工数 | 多量 | 少量 |
| 変化への対応 | 低速 | 高速 |
| 要求技術 | 高度 | 低度 |
| 管理者 | 少数 | 多数 |
どんなものにもあるように、課題も存在する。
課題1 虎を変更できない狐
多くの会社では先例を尊重するだろう。誰かがメインシステムから周辺システムを発展させ、その発展方法が先例として充実していく。しかしビジネスの変化に合わせてメインシステムを変更しなければならないときは存在する。より安価な基幹システムが現れたり、より高品質なものを契約せざるを得ない場合などに。
そういった際に周辺システムはその変更を遅滞させ、抵抗を生むだろう。メインのシステムには明確な管理者がいるだろうが、周辺システムに管理者の統一は難しい。
課題2 虎たちは離れており、集合しない
システム化の目標はシステム利用者の作業時間の削減と体験の向上だったが、SaaSを導入することはシステム間の谷を深化させていった。それぞれの虎はそれぞれの理想に向かい邁進していき、他システムと接続するための製品も隆盛を誇る。
システム間連携を行う製品の例
どこを内製することになるか
corp-engr以外のメンバーは、メインシステムか周辺システム、どちらかの対応がほとんどになるはずだ。corp-engrはメインシステムと周辺システム双方の対応を要求されることが多い。
そのため、メインと周辺システムのバランスを見れる稀な存在となる。この課題はGWSで解決するべきか？それとも自ら周辺システムへ展開するプログラムを作成するべきか。
可能な限り、周辺システムは減らすことが望ましいとは思うが、GWSやkintone、salesforceで業務すべてが解決できることはほとんどない。短期的な解決では、周辺システムの拡充が求められるだろう。メインシステムで解決できないかを探り、できなければ周辺システムを拡充させ、メインシステムの代替を模索する。
Discussion