野良システム乱立の無法地帯を防ぎ、継続的な改善を進めるために情シスに必要な役割とアクションとは。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
市民開発における情報システム部門(以降、情シス)の役割を説く、連載「情シスがリードする『幸せな』デジタルの民主化組織の作り方」。前回は、「デジタルの民主化」には業務部門自らの開発だけではなく、システム開発や導入に知見を持った情シスとの「協創」が不可欠であることをお伝えした。
今回は、協創のカギを握る情シスの役割に焦点を当てる。
情シスはどうあるべきだろうか。ITを駆使して経営レベルで社内をリードすることか。すぐ現場へ駆け付けるべくフットワークを軽くすることか。
私たちドリーム・アーツは、全社で利用できるプラットフォーム型のサービスを提供していることもあり、さまざまな企業の情シスとやりとりをしてきた。その経験からいえるのは、同じ情シスでもその姿はさまざまであるということだ。
「現場からとても信頼があり、頼られている。すてきだな」と思える情シスがいる。一方で、商談の場では自己紹介以降一言も発言をしないので、私たちと現場とで進め方のすり合わせをしていると、役割分担の段になって急に威勢がよくなり、意地でもボールを持つまいと言い訳に終始する情シスもいる。
私たちは、情シスは二極化していると考える。
1つは、ITの力を駆使して経営戦略の下支えをする「先進型情シス」。イノベーション情シスや生み出し型情シスといえる。DX(デジタルトランスフォーメーション)戦略部やIT戦略部と呼ばれる部署がこの役割を担っていることが多い。
もう1つは、言われたことをやる「旧来型の情シス」。現場から挙がった課題をきっかけに初めて動く社内御用聞きで、課題はそのまま下請けベンダーへ丸投げしがちだ。ソリューション型情シスやベンダーマネジメント型情シスといえる。
もう少し具体的に見ていこう。
旧来型の情シスは、現在担当している業務以外は増やすことはもとより減らそうともしない。とにかく現状維持を望む傾向にある。そのため社内改善や現場改善の取り組みによって自分が忙しくなろうものなら、全力で止めにかかってくる。取り組みの実施が決定したら、今度はその役割を外注することに全力を注ぐ。
本来こういった外注は、SIerに依頼するのが通例だが、私たちSaaSベンダーへもこういった情シスからは声が掛かることがある。彼らは、現場からいわれたオンプレ基幹システムなどの連携要件を丸投げしてくる。
しかしSaaSを使ってサービス間連携を実現したい場合は、オンプレ時代のようにシステム連携のために製品に手を入れてベンダーに開発させて実現するような密結合ではなく、サービス間で役割と責任を分け、各サービスが公開したAPIを使って利用者が自由に連携用の仕組みを開発する疎結合が主流だ。その開発する仕組みを提供するSaaSすらある。
そもそも、SaaSベンダーが顧客ネットワーク上に存在するオンプレシステムへ連携する機能を作ったところで、ネットワークが到達しない。到達するということは、外部からの攻撃の対象になり、その防御の仕組みが必要となるのだ。
旧来型情シスは、こういったことも分からずとにかく自分に降ってきたミッションを丸投げしようとする。特徴的なのは、私たちに対して「こんなことをやってくれるか?」という質問が多いことだ。
Copyright © ITmedia, Inc. All Rights Reserved.