冷静と情シスのあいだ - 急成長のベンチャーで見過ごされがちな情報システムの技術的負債の返し方

株式会社LITALICO インフラエンジニアの@ko1です。 LITALICO Engineers Advent Calendar 2016 20日目の記事となります！

今回のテーマ

LITALICOが急成長する中で起きてきたことをベースに、会社が急成長する中で特にシステム導入について起きがちな問題とその対策について書いてみました。

• 起きがちな問題点
• システムの技術的負債とは？
• システム負債を返すために取り組んできたこと

起きがちな問題点

会社が急成長していると、社員や事業所が急激に増えたりしていくとおもいます。システム部門としてはいろいろと悩みどころが多くなりやすいと思います。

ネットワークやサーバーインフラ、PC/デバイスの管理、全体のセキュリティなどいろいろな面で問題が起きると思いますしLITALICOでも様々な闘いの歴史がありますが、今回は・・
システム導入と運用に関わる部分にフォーカスして書いていきます。

システムの技術的負債とは？

社内で新たなシステムを開発/導入するときは、以下のようなことが発生しやすいと思います。

• とにかく動けば何でもいいから急いで導入したい！

  • すぐ切り替えるし、暫定的に利用しようということで仮のシステムを導入したが、結局代替システムが現れることはなく、ずっと使い続けられることになった。
  • その結果、ふたを開けるのも恐ろしいゾンビのようなシステムが。。

• とにかく安いものにしてほしい！

  • とにかく安いものを探して導入してみた。
  • その結果、保守も何もなく逆に運用コストが高くついた。また、必要な機能を追加しようとすると比較していたものより結局高くついた。。

• 何でもできるみたいだから、これ入れとこう！

  • 何でもできそうって聞いたから特に要件定義はせず導入してみたけど、何かこれ、、思ったのと違う・・！
  • 結果、業務の実態や変化にあまり対応できず、非常に使いづらいものだった。。

• これも、これもとなぜか現状の業務フロー以上に要件が増えた

  • それまでの業務でも改善できたはずなのになぜかシステム化するタイミングで急に要望が爆発
  • 要件が定まらずシステム導入が中途半端になり、なぜか悪いのはシステムという評価に。。

・・やばいですね。エンジニアだったらとても冷静でいられない話ばかりです。
この結果発生したシステムたちを、「システム負債」と呼んでいます。

システム負債を返すために取り組んできたこと

では、そのシステム負債をどうやって返していくか、です。

1. 全体像をつかむ

今社内にどんなシステムがあるか。実は意外ときちんと把握するのは難しいものです。

• このようなポイントについてまとめていくと良いです

  • システムの分類
  • システムの利用目的/概要
  • 利用部署
  • 連携システムとその方式

• まとめる際にこのような工夫も必要だと思います

  • 人/モノ/金などの大きなくくりで情報の流れを整理する
  • システム導入/改廃が行われるときに情報が集まるしくみを作る

全体像をつかむことで、無駄になっているもの、業務上のリスクになるものも可視化できるため、負債がそもそもどこにあるのかがわかりやすくなります。

また、ミクロに見たときの最適化だけでなく、マクロで見たときに会社として情報の「血流」を良くしていくためにどうしたら良いかというのが見えやすくなります。

2. 本当にそのシステムが必要か、を見直す

システムは一般的には、業務を自動化して効率化していくために導入すると思います。

良いシステムを導入すれば、すべての課題が解決するという考えてしまいがちですが、それは幻想です。

例えば、対象業務がシステム導入/切替すべきかどうかについて、以下のような流れで考えてみると良いと思います。

このような観点で分解して考えていくと、あえてシステム化しない方が良い、あるいは、そもそも廃止しても良い業務もあるということに気づくと思います。

無駄を削減することで、業務の流れをシンプルにしていくことができ、負債となるようなシステム導入も防ぐことができます。

3. 費用対効果を定量的に見積もる

要件に合致しているということを前提とした上で、システム化によりどれだけの時間を削減できるか、費用を削減できるか、ということも重要なポイントです。

導入したシステムでコスト削減効果が出せないのであれば、意味がありません。

また、システム導入は大体においてプロジェクトとして実施することになると思いますので、プロジェクト管理上も定量的な効率化目標を掲げておくのは良いと思います。

なぜかというと、人は抽象的でイメージしづらい目標を達成することは難しいですが、明確な目標をイメージできると達成イメージが湧きやすいからです。
(「働きやすい会社を作る」と、「残業時間を30%削減する」どちらがイメージつくでしょうか？)

4. スモールスタートにする

成長期で事業の変化が激しい場合、しっかりとした要件定義が難しいと思います。
その段階で重厚なシステムを選んでしまうと、しばらく経ったときに全く役に立たないということも起こり得ます。

1. 人の手で作業フローを組み立ててみる
2. 整理した業務プロセスをそのままシステム化するのではなく、事前に業務を改善する
3. 改善後の業務について効率化できる部分をシステム化していく
4. ある程度流れが固まってきたところで追加システム投資の判断をする

というような業務自体の見直しが発生することを意識したステップバイステップでの組み立てをしていくことが必要です。

基幹システムだと難しいのでは？と思う方もいると思いますが、最近はSaasも揃ってきており規模に応じて取りうる手段が増えてきているため、環境は非常に良くなってきていると思います。

要件定義時の要件爆発を防ぐためには、個人的には2番が最も重要だと思っています。
「今変えられるものは今改善する。システムを変えれば全てが良くなるというような詰め込みをしない」ということが必要です。

まとめ：「攻めの守り」の情シス！

情シスは守りの部署というイメージが強いかと思いますが、この記事で書いてきたようなことを実現するには、「攻めの守り」というのが必要ではないかと思います。

急成長している会社では、人も組織も追いついていかないことが多く、規模感に合わないシステムになってしまったり、業務が属人化したり、問題の種はいたるところにあると思います。

ただ、システム担当者が長期的な会社の成長を見越した上で必要な改善を積み重ねていければ、社員全員が幸せに働ける環境を作ることができ、結果としてお客様への価値にもつながっていくと思っています！

次回は..

明日は、@YudaiTsukamotoさんの「独断と偏見で選ぶ、新人プログラマが読むべき技術書20選」です。よろしくお願いいたします！