親交のある上場企業の役員の方とランチをして情報交換をさせて頂いた中で、「IT予算は情シス部門より事業部のほうが多い会社が増えています」「事業部と直で仕事する会社さんも増えています」と教えて頂きました。
どういった背景がその現象を引き起こしているのか、少し考えてみたいと思います。
寄せては返す、情シス不要論
情シス不要論はSAPのようなERPパッケージが日本に入ってきた時(20年ぐらい前ですかね？)から言われているように思います。私がこの業界で仕事を始めたのが2003年で、SAPは1990年代のエンタープライズITの「花形」でした。
主な不要論の主張は以下の通りです。
- 事業部のビジネス(売上)に貢献していない
- 自分達で実装しないので、システムの開発力がない
- 仕様策定能力や、ベンダーの目利きが出来ない
- システム運用ならプロの外注を活用したほうが良い
情シス不要論の骨子を乱暴に言えば、ITを買ってきて使うだけなら購買部と何ら変わりないので、専用の組織や人員は不要という主張です。
Amazon Web Service(通称AWS)を始めとしたクラウド技術の台頭で、運用作業が「黒船」によってどんどん自動化できるようになりました。クラウドサービスを活用すれば、ITインフラの全体図がそのまま設計図として残すことが可能です。必要なリソースはいつでも追加できますし、インターネットに接続しないプライベートなネットワークを構築するのもお手の物。
IT部門の責務である「会社のみんなが、普通に仕事ができる環境を整えること」は、とても価値が有ることです。その一方で、ITインフラの構築と維持管理のコストは、金額面でも工数面でも低下しています。そこに貴重な人的リソースをつぎ込む意味が無くなっていると言っても、過言ではないでしょう。
自社に最適なITをデザインするために
上記の不要論で、私が違和感を覚えたのが「ハードウェアなら買ってきて終わりもわかるが、ソフトウェアは買ってからがスタートではないか」という点です。ExcelやAccessのようなOfficeソフトでさえ、買っただけは何も出来ません。真っ白なキャンバスが目の前にあるだけです。
ソフトウェアを活用するためには、明確な利用シーンをイメージして、現在困っている課題を解決する道筋がなければなりません。 その道筋を立てられるのは情シス部門であるはずなのに、乱暴な不要論が出てくるのはどうしてなのか、と。必要とされるためには何が必要であるのか。情シス不要論が蔓延るような風潮は、日本だけなのではないのか。そんな疑念を頂いています。
同時に、不要論が蔓延る一因が、中小企業におけるIT部門(情シス部門)が、本業ではないIT技術に対する知見が薄いことにあると見ています。
IT活用を阻害する３つの要因
利用するソフトウェアが自社に最適なのか、メリットやデメリットはどこにあるのか。そういった議論が上手くいかない or 空回りするパターンは相場が決まっています。
- 「ITを導入すると、どんなメリットがあるのか」⇔「具体的にどんなことをしたいのか教えてくれ」
- 売上を増やしたい・生産性を高めたいという思いはあるが、現状分析が不足しており具体的な施策まで落とせない。
- ITエンジニアが社内にいないため、自社のためのオリジナルなITシステムを開発／運用し、維持管理や改善をしたことがない
最も多いのは「ITを導入したらどんなメリットがあるのか」対「それはやりたいことによって違うから、具体的な利用イメージ提示して欲しい」の平行線の議論です。 乱暴な例えですが「うまいものを食べたい」対「何が食べたいんですか？」という会話に近いものがあります。
こうなってしまうのは、悪いことではなく自然なことだと考えています。自社のビジネス課題を解決するITをデザインするためには、結構なプロセスをたどる必要があるからです。当方は、この流れで整理しています。
- 「お客様が言っていること」は何か
- 「なぜそんなことを言っているのか、背景に何があるのか」
- 「課題は何なのか、何に困っているのか」
- 「ソフトウェアで解決するためには何が必要なのか」
- 「必要なものを揃えるにはどんな方法/技術/機能が必要なのか」
- 「最もROIに合う解決策は何か」
一般的な中小企業において、上記のような検討や導入を何度も繰り返し行い、IT技術に知見のある人材は、まずいません。本業と関係がないからです。
しかし、どんなに優れたIT活用のコンセプトを作っても、自分達でITシステムに必要な仕様を的確にまとめる事が出来ないようでは、IT導入に失敗するリスクは高まります。 ITの世界においては「頼んだものと違う」という不幸なすれ違いが至る所で発生しています。
目に見えない不定形な成果物を手に入れ、かつそれを改善し運用していくのは、知恵と体力が必要です。
ITの目利き力は一長一短で身につかない
付加価値(何が価値であるかを見いだすのは大変なことですが)を生むためのIT活用を行うには、一般的に以下のような検証が必要になります。
- 付加価値を生むことが妨げになっている課題は、何なのか
- その価値を実現するために、課題をどうやって解決すればよいのか
- その解決策を実行すると、どんな嬉しいことがユーザーにあるのか
これらはIT技術とは全く関係がないので、エンジニアではない方が構想立案することができるはずです。実装技術や方法は、この段階では問う必要がありません。しかし、上記のビジネス要求からITサービスとして必要な要件に落とし込むためのスキルがどうしても必要になります。
事業会社には、一般的なITエンジニアとは異なるIT専門職と言いますか、守備範囲といいますか、IT戦略から運用のあり方までの良し悪しを判断・決断できるハイスキルな人材が求められ、今後様々な業種で必要となるでしょう。ノウハウで差別化出来れば、競争優位に直結するからです。
PoCをやってみよう
結論から言えば、IT活用はやってみないと何も分かりません。酸いも甘いも、実際に目で見て手で触れて感じた満足感・喜び・苛立ち・不満が集積されることで、感じられるようになります。
IT企画で最も難しいのは「こういうことがやりたい」から「じゃ、こういうITシステムがあればいい」に行間を埋める所です。 一般的には要件定義と言いますが、この工程で最も重要なのは仮説の検証です。
ITを使ってこういうことがやりたい、こんなITがあればもっと価値を生み出せる、という仮説が正しいかどうかを確かめるには、プロトタイプ(試作品)を用意する必要があります。Webのサービス等でコンセプトにピタッと合うものがあれば、やってみるべきです。もちろん、予算の上限はつけるべきですが。ITを使いこなしている中堅/中小の事業会社は驚くほど少ないので、少しの改善で大きな競争力・コストダウンを得られる可能性も少なくありません。
IT技術の活用の幅が広がれば広がるほど、情シス部門の期待(及び責務)は今まで以上に大きくなります。自社の経営資源を最適化するためのITデザインを行うのが、必要とされる情シスの姿です。そこには様々な制約がありますので、袖を合わせる作業が必要です。その行いのことをPoC(Proof of Concept)と言います。
不確実な未来を掴むために、展望は大きく考えて実行は小さく始める。Think Globaly, Act Locallyという言葉がありますが、そのコンセプトを元に「こういった利用シーンが現場でできるなら」という展望を踏まえ、その為のITデザインは何から手を付けていけばいいのか、どんなソフトウェアを手に入れるべきなのかのゴールを共有し、確実なものにする。
そのノウハウを当社は持っています。ITを仕事にするプロとしてのプライドもありますが、皆さんと一緒に日本のIT活用力を挙げる試みをご一緒できれば幸甚です。