会社は、ITより速く変われない｜なぜ「ちょっと変えたい」が大工事になるのか
「新しいサービスを始めよう」
「料金体系を変えよう」
「この業務を一本化しよう」
経営会議で議論が進み、方針が決まる。「よし、来期からやろう」
ところが、ITの話になった途端、時間の流れが変わります。
「まず影響範囲を調査します」「他システムとの連携を確認する必要があります」「そこだけ変更するのは難しいです」
そして最後に、「半年くらいは見てください」となる。
経営会議では30分で決まった。でも、実現するのは半年後。
少し皮肉な話ですが、この「半年」が、その会社の本当の変革スピードです。
会社は、経営、組織、人材、業務、制度、ITなど、さまざまなものが組み合わさって動いています。そして変革するとき、会社はそれらの平均速度では動きません。一つでも動かないものがあれば、そこで止まります。
企業の変革スピードは、最も変更に時間がかかるものによって決まる。
そして多くの企業で、その一番遅いものがITになっています。
会社は、ITより速く変われない。
これはIT部門の問題ではありません。経営のスピードの問題です。
壁紙を変えたいだけなのに、柱まで工事になる
経営側からすると、不思議に思うことがあります。
- 「入力項目を一つ増やしたいだけ」
- 「料金の計算方法を少し変えたいだけ」
- 「この業務だけWebからできるようにしたい」
ところが、その「だけ」が簡単ではない。
データベースに影響する。帳票にも影響する。別のシステムとつながっている。しかも、どこまで影響するのかすぐには分からない。
だから、「まず調査します」から始まります。
家に例えるなら、壁紙を変えようとしたら、「この壁紙、壁と一体化しています」と言われるようなものです。
では壁ごと変えようとすると、「この壁、柱とつながっています」さらに、「柱を触るなら、天井にも影響します」となる。
壁紙を変えたいだけだったのに、気がつけば大工事です。
問題は、いろいろなものがつながっていること自体ではありません。システムなのですから、つながっているのは当然です。
問題は、
- どこが壁で、どこが柱なのか
- 何と何がつながっているのか
- 一つ変えたら、どこまで影響するのか
それが分からないことです。
私は、これを自社のITの「設計構造」が見えていない状態だと考えています。
古いシステムだから問題なのではありません。古くても構造が分かっていれば、手を入れ続けることはできます。逆に最新技術で作られていても、構造が分からなければ、変化には強くありません。
その家を建てたのは誰か
ここで、少し耳の痛い話があります。
壁紙を変えるだけで柱まで工事しなければならない家。なぜ、そんな家になったのでしょうか。
最初からそうだったとは限りません。
- 「とにかく来月までに作ってほしい」
- 「今回は暫定対応でいい」
- 「その整理は売上につながらないから、来期にしよう」
- 「システムのことはベンダに任せておけばいい」
一つひとつは、その時点では合理的な判断だったのかもしれません。納期を守らなければならなかった。予算にも限りがあった。目の前の事業を優先する必要があった。だから「今回はこれでいこう」と判断する。
その判断自体が間違いだったとは限りません。問題は、その「今回だけ」が10年積み重なることです。
壁紙と壁がくっつき、壁と柱がくっつき、柱と天井がくっついていく。そして何年か後、経営会議でこう言います。
「なぜ、こんな簡単な変更に半年もかかるんだ？」
少し意地悪に言えば、ITが会社を遅くしたのではなく、会社の意思決定の積み重ねが、遅いITを作った。という側面もあります。
システムには、その会社が過去にしてきた判断が残ります。急いだ判断。先送りした判断。予算を削った判断。ベンダに任せた判断。
そう考えると、ITは単なる道具ではありません。ITは、過去の経営判断の履歴でもあるのです。
「変えられる構造」はタダでは手に入らない
では、変えやすいシステムを作ればいい。話はそれほど簡単ではありません。
変えられる構造を維持するには、コストがかかります。
目の前の新機能を一つ増やすより、構造を整理した方がよいことがある。今すぐ作るより、一度立ち止まって整理した方がよいこともある。短期的には売上を生まない部分に、予算を使わなければならないこともある。
そして何より、「とりあえず今回だけ」を断る必要があります。
これは技術者だけでは決められません。経営判断です。
もちろん、すべてを美しく設計する必要はありません。事業にはスピードが必要です。時には、将来の改修コストを承知したうえで、暫定対応を選ぶこともあるでしょう。
急いで作るということは、将来の改修コストを先送りして、今のスピードを買うことでもあります。財務に例えれば、一種の「借金」です。
借金そのものが悪いわけではありません。事業機会を逃さないために、あえて借金をする経営判断もあります。
問題は、借りたことを忘れ、返さないまま利息だけを払い続けることです。
ITも同じです。重要なのは、「早く作るか、きれいに作るか」という二択ではありません。今ここで速さを優先した結果、将来どんな制約が残るのか。それを理解したうえで選び、あとで返すべきものを忘れないことです。
経営者が聞くべき3つの質問
経営者がプログラムを理解する必要はありません。「Javaなのか」「PHPなのか」「AWSなのか」といった技術の細部まで知る必要もありません。
その代わり、私は少なくとも3つのことを聞くべきだと思っています。
1．自社でシステムの構造を説明できるか
ベンダに聞かなければ、何と何がつながっているのか分からない。担当者が退職すると分からなくなる。仕様変更のたびに、まず外部へ調査を依頼する。
これでは、システムを所有していても、構造の主導権を持っているとは言えません。
すべてを内製する必要はありません。しかし、自社の事業を支えるITの構造まで、完全に外部任せにしてよいのか。これは経営が考えるべき問題です。
2．小さな変更を、小さな変更として実行できるか
一箇所を変えるたびに、システム全体の調査や改修が必要になっていないか。事業の変更単位と、システムの変更単位が大きくズレていないか。
「ちょっと変える」が本当に「ちょっと」で済むこと。これは、事業スピードに直結します。
3．「今作るもの」以外にも投資しているか
IT予算は、どうしても新機能や新システムに向かいます。成果が見えやすいからです。
一方で、
- 構造を整理する
- 不要なものを切り離す
- 古くなった部分を作り直す
- 設計情報を残す
こうした仕事は、翌月の売上を増やしてくれるわけではありません。だから後回しになりやすい。
しかし、それを何年も続ければ、やがて「何かを変えるたびに半年かかる会社」が出来上がります。
変えるための余白にも、投資が必要なのです。
「何ができるか」ではなく「どれだけ変えられるか」
新しいシステムを選ぶとき、私たちは「何ができるか」を熱心に比較します。この機能があります。この業務を自動化できます。これだけ効率化できます。もちろん、それも重要です。
しかし、企業は変わります。顧客も変わる。商品も変わる。組織も変わる。競争環境も変わる。
だから、本当に長く使うシステムなら、もう一つ聞いておくべきことがあります。
「事業が変わったとき、このシステムも一緒に変われるか？」
そして、もう少し厳しく言えば、
「変えられなくなったとき、必要な部分だけ切り離せるか？」
全部を作り直さなくても、古くなった部分だけを捨て、新しいものに差し替えられる。壁紙を変えるために、家を建て直さなくていい。
変えられる設計とは、部分的に捨てられる設計でもあります。
今日どれだけ多くの機能を持っているかだけではありません。明日、会社が違う方向へ進もうとしたとき、それを邪魔しないこと。
IT投資で手に入れるべきなのは、完成したシステムだけではありません。次に変わるための余白です。
変革の速い会社とは、経営会議で物事が早く決まる会社ではありません。決めたことを、早く形にできる会社です。
会社は、ITより速く変われない。だからITの設計構造は、技術者だけに任せておく話ではないのです。
そのIT,次の変化について来られますか？
システムの価値は、「今、何ができるか」だけでは決まりません。
事業を変えたいときに、どこまで早く、安全に変えられるかも重要です。
「少し変えるだけなのに時間がかかる」
「影響範囲をベンダに聞かなければ分からない」
「どこから手をつければよいか判断できない」
そんな状態なら、一度システムそのものではなく、「変えられる構造になっているか」という視点から整理してみませんか。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
