<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>企業システムの手綱</title>
    <link rel="alternate" type="text/html" href="https://el.jibun.atmarkit.co.jp/masamune/" />
    <link rel="self" type="application/atom+xml" href="https://el.jibun.atmarkit.co.jp/masamune/atom.xml" />
    <id>tag:el.jibun.atmarkit.co.jp,2019-03-18:/masamune//209</id>
    <updated>2016-04-28T00:49:45Z</updated>
    <subtitle>上場企業の情報システム部長が、基幹システムを開発／運用する毎日で感じたこと</subtitle>

<entry>
    <title>柔軟化～　スイッチャビリティの追求</title>
    <link rel="alternate" type="text/html" href="https://el.jibun.atmarkit.co.jp/masamune/2010/02/post-2589.html" />
    <id>tag:el.jibun.atmarkit.co.jp,2010:/masamune//209.5417</id>

    <published>2010-02-02T19:45:00Z</published>
    <updated>2016-04-28T00:49:45Z</updated>

    <summary>　わたしは企業の情報システムを十余年、情報システム部門の責任者として見てきました...</summary>
    <author>
        <name>正宗ヒデヲ</name>
        
    </author>
    
        <category term="業界動向" />
    
    
    <content type="html" xml:lang="ja" xml:base="https://el.jibun.atmarkit.co.jp/masamune/">
        <![CDATA[<p>　わたしは企業の情報システムを十余年、情報システム部門の責任者として見てきました。数多の失敗や試行錯誤を繰り返す中で、会得した企業の情報システムを運営していくための原理原則がいくつか存在します。そのうちのひとつを紹介したいと思います。今回、第1回目のコラムで紹介する原理原則は、わたしの中でも最も重要なものです。</p>

<p>　それは、｢スイッチャビリティの確保｣とわたしが名づけているものです。</p>

<p>　このことはほとんどITの教科書に載ってはいません。それには理由が2つあって、1つはあまりにシンプルな原理なので細かく説明するまでもないこと、もう1つは顧客を囲い込みたいベンダにとって好ましいものではないからです。したがって、ホテルなど貸しきって頻繁に開催される大手SIerのセミナーなどでは教えてくれません。</p>

<p>　それでは、「スイッチャビリティの確保」について説明します。</p>

<p>　スイッチャビリティの確保とは、<span style="color: #ff0033;"><strong>お金さえ出せば、保守業者、ハードウェア、パッケージソフトを切り替えることができるように常にシステム全体を維持しておくこと</strong></span>です。<br /><br />　「お金さえ出せば切り替えられるのは当たり前だ」と思われた読者の方がいたら、それは誤りです。切り替えられないシステムを2つ説明します。それぞれ、「不発弾システム」「殿様システム」と呼びましょう。<br /><br /><strong>（1）不発弾システム</strong><br /><br />　企業の情報システムには、リスクが大きすぎ、そのリスクに見合うコストが算出できないシステムや、あるいはリスクを読みきることができないため引き受けるベンダがないアンタッチャブルなシステムが、1つや2つあるのが普通なのです。それは住宅地の地下に埋まっていて、いつ爆発するかわからない不発弾のようなシステムです。<br /><br />　老朽化も極まり、契約書がない、仕様書がない、保守契約は切れ、担当者SEは不在で……。理由はいろいろあります。動いているのが、奇跡のようなシステムです。<br /><br /><strong>（2）殿様システム</strong><br /><br />　1つのベンダに依存しており、好ましくない状態を継続せざるを得ないシステムです。<br /><br />　担当SEの能力が低いのは明らかなのにもかかわらず、彼しかもっていない経験値があるため（本当はないのかも知れないが）、変更できない。品質が悪くトラブルばかりであるのに、一向に改善策をとってくれない。変更依頼をしたいが、見積もりが異常に高額で、「実施したくない」というのがみえみえ。ことあるごとに高額な追加費用を要求される……。<br /><br />　ベンダに実際に足元を見られてしまうケースもあるでしょう。言いなりにならざるを得ないという意味で「殿様システム」とします。<br /><br />　以前から付き合いのある友人の情報システム部長は、わたしにこぼします。<br /><br />　「正宗さん、困っているのです。当社の販売システムは昔からの付き合いの業者しかわからない状態になっていて、品質は悪く、費用もいわれるがままに支払わざるを得ない状態になっているのです。できれば切り替えたいのですが、彼らから情報をもらわないと切り替えることもできないのです」<br /><br />　よくある話です。</p>

<p><span style="font-size: 1.2em;"><strong><span style="color: #66cc33;">■</span>スイッチャビリティ確保のメリット</strong></span><br /><br />　不発弾システム、殿様システムに情報システム部が牛耳られないうちに、細かいリスクテーク、細かい投資をして、スイッチャビリティの確保に努めるべきです。<br /><br />　スイッチャビリティの確保とは、<span style="color: #ff0033;"><strong>お金さえ出せば、保守業者、ハードウェア、パッケージソフトを切り替えることができるように常にシステム全体を維持しておくこと</strong></span>でした。<br /><br />　スイッチャビリティを確保したときのメリットは明確です。<br /><br />　ベンダが不適格なとき、またベンダの倒産や業務縮小などの事態が発生しても、他のベンダに切り替えることができるため、リスクを大幅に小さくできます。<br /><br />　ベンダから納得できない費用を請求されたとき、診療のセカンドオピニオンのように、他ベンダに相見積もりをとることで費用の妥当性を検証することができます。経営に対する費用答申の際にも、この手段をとると非常に納得性が高くなります。<br /><br />　実際にスイッチするかどうかは、総合的に判断すればよいわけで、スイッチのコストとリスクを勘案して、そのまま継続するもよし、思い切ってスイッチする決断をしてもよいと思います。<br /><br />　競合状態にあることを現ベンダに伝えることで、緊張感が生まれます。現ベンダからも、よい提案、よい費用を引き出せることは間違いありません。わたしは、この方法が一番スマートなコスト低減策であると思っています。見積もりに難癖をつけて値引きをするのは、スマートではありませんし、おそらく次回案件の見積もりは値引きプレミアムをのせられて、狐と狸の化かし合い、ムダな交渉時間を費やすことになるでしょう。<br /><br /><span style="font-size: 1.2em;"><strong><span style="color: #66cc33;">■</span>スイッチャビリティ確保の進め方</strong></span><br /><br />　「スイッチャビリティの確保」は、簡単なことではなく、中期的、戦略的に実施し続ける必要があります。わたしは、このことこそが情報システム部長のやることのすべてとさえ思います。他の決断は情報システム部の信頼できる部下や、雇ったITコンサルタントでもできるかもしれませんが、「スイッチャビリティの確保」の舵取りは情報システム部長しかできないと思います。<br /><br />　なぜ、情報システム部長しかできないのか。それは情報システム部長が企業システム全体を把握し、中期的に責任をもち、リスクをとらなければならない存在だからです。CIOは、責任とリスクはとれると思いますが、具体的な「スイッチャビリティの確保」のためのロードマップを描くのは難しいでしょう。CIOは短期的な成果が求められるため、即効性のない投資には消極的になりますし、ロードマップを描くときに把握すべき「地雷システム」「殿様システム」は情報システムの現場にかなり近いところに存在しているため、具体的なリスクを想像するのが難しいからです。<br /><br />　では、具体的な対処と予防のポイントをみていきましょう。</p>

<p><strong><span style="font-size: 1.2em;color: #3399ff;">■</span><span style="font-size: 1.2em;">対処のポイント</span></strong><br /><br /><strong>1．不発弾システムの処理</strong><br /><br />　不発弾システムは忘れたい存在ですが、目を背けず、計画的に小さなリスクをとっていくしかありません。<br /><br />　ブラックボックスのシステムであれば、ホワイトボックスに近づける努力をします。担当者をつけて、マニュアルを作成する、入出力仕様書を作り直す、など時間をかけて実施します。その実行のプロセスで、担当者にそのシステムに関する知見が蓄積し、徐々にリスクが読めるようになります。リスクが読めれば、次の一手は打てます。リスクが顕在化したときの対応策を準備することもできますし、使い続けるシステムであれば、リスクが顕在化する前に予算化してリプレースなどの対応をします。<br /><br /><strong>2．殿様システムからの解放</strong><br /><br />　現在のベンダに、中期的に切り替えを検討することを宣言しましょう。まず、ベンダに対し、「あなたの会社以外に委託することも検討することにしました」と宣言からはじめます。準備はそれから始めてもよいと思います。<br /><br />　宣言すると、いじわるをされるのではないか、そう考えたくなります。わたしの経験からすると、実際にはそのようなケースはあまりなく、慌ててよい提案をしてくるケースが多いです。まれに、「大変なことになりますよ」と脅されたり、経営陣に直訴されたりすることもあるかもしれません。それに屈することなく、むしろ、その程度の対応しかできないベンダであったことがはっきりして良かったと解釈し、早めに決別する意思を固めるくらいでありたいものです。<br /><br />　いままで長い間それなりにつきあってきたベンダに対し、宣告するのはつらいし、怖いことです。でも、ずるずるとつきあい続けるのは、リスクがますます巨大化していくことを知るべきです。<br /><br />　もし、さまざまな選択肢を検討した後の最終判断で現ベンダと継続するとなったとしても、ギクシャクした関係が継続するわけではなく、以前より一段高いレベルでベンダと付き合うことができ、真のWin-Win関係の第一歩がはじまるだろうとわたしは確信しています。<br /><br /><strong><span style="font-size: 1.2em;color: #3399ff;">■</span><span style="font-size: 1.2em;">予防のポイント</span></strong><br /><br />　予防できれば、それに越したことはありません。「不発弾システム」「殿様システム」を抱えることがないのですから。わたしが考えるポイントを順不同で列挙してみます。</p>

<ol><li>オールインワンパッケージで全業務をカバーさせず、適切な規模のシステムに分断して構築すること。1つのパッケージブランドにこだわらないこと</li>

<li>複数会社が保守できるパッケージソフトを利用すること</li>

<li>データセンターの委託とアプリケーションの保守委託を分けること</li>

<li>システムの担当者が属人化しないよう、複数体制にするか、ローテーションすること</li>

<li>マイナーな技術は避けること</li>

<li>包括契約ではなく、システムごと、委託業務分類ごとに契約を分けること</li></ol>

<p>　以上、ポイントをいくつか挙げてみましたが、これらの対策が成立するかどうかはシステムの内容や規模など状況によって変わります。万能の「勝利の方程式」はありません。実務経験に基づいたリスク判断で、一手一手打っていくしかありません。その実務経験こそ情報システム部長に要求されることだと思いますし、リスク判断できるということが情報システム部長の存在意義なのだとわたしは思います。<br /><br />　あえて言えば、スイッチャビリティ確保のために情報システム部長に欲しいのは、実務経験にプラスして、勇気ということになるでしょう。不発弾を処理する勇気と、お殿様に決別を告げる勇気です。<br /><br />　わたし自身の評価はわかりませんが、わたしは勇気をもった情報システム部長でいたいと思います。</p>

<p class="MsoNormal" style="margin: 0mm 0mm 0pt;"></p>

<p class="MsoNormal" style="margin: 0mm 0mm 0pt;"></p>

<p class="MsoNormal" style="margin: 0mm 0mm 0pt;"></p>

<p class="MsoNormal" style="margin: 0mm 0mm 0pt;"></p>

<p></p>]]>
        
    </content>
</entry>

<entry>
    <title>「情報システム部長」というエキサイティングなポジション</title>
    <link rel="alternate" type="text/html" href="https://el.jibun.atmarkit.co.jp/masamune/2010/01/post-30c4.html" />
    <id>tag:el.jibun.atmarkit.co.jp,2010:/masamune//209.5416</id>

    <published>2010-01-28T21:02:00Z</published>
    <updated>2016-04-28T00:49:45Z</updated>

    <summary>　はじめまして。正宗ヒデヲと申します。 　自己紹介をいたします。現在、外食・サー...</summary>
    <author>
        <name>正宗ヒデヲ</name>
        
    </author>
    
        <category term="キャリア" />
    
    
    <content type="html" xml:lang="ja" xml:base="https://el.jibun.atmarkit.co.jp/masamune/">
        <![CDATA[<p>　はじめまして。正宗ヒデヲと申します。</p>

<p>　自己紹介をいたします。現在、外食・サービス業に分類される上場企業に勤めています。社内システムを担当するいわゆる「情報システム部」に所属しており、現役の情報システム部長です。転職を経験しており、前職は出版社で情報システム部長をしていました。</p>

<p>　情報システム部勤務歴は20余年、うち情報システム部長歴は通算9年。大きなプロジェクトも数多く経験していますし、成功も失敗も喜びも悲しみも経験値として重ねていますので、客観的にはベテランの情報システム部長にカテゴライズされてしまうでしょう。</p>

<p>　わたしのコラムですが、企業の情報システム部長はどういう価値基準で日ごろ何に注意し、どんな行動をしているのかを読者に伝えたいと思っています。</p>

<p>　わたしの立場は、</p>

<ul><li>もし読者がソフトハウス、SIer、コンサルティング会社などに勤めているのであれば、発注元の責任者</li>

<li>もし読者が業務部門の社員であれば、情報システム部の責任者</li>

<li>もし読者が社内SEであれば、上司</li>

<li>もし読者が企業の社長であれば、部下</li></ul>

<p>にあたると思っています。</p>

<p>　身近な存在ではないかもしれませんが、現在の企業において情報システム部長の影響力は、潜在的には大きなものだと思っています。また、本来はエキサイティングなポジションであるにも関わらず、その存在が魅力的な主人公として語られる場面は少ないように感じます。</p>

<p>　多くの情報システム部長が、基幹システムを安定運用し続ける責任の重さを感じ、コスト削減・要員削減圧力に悩み、テクノロジと経営の融合に苦慮しています。そのために表面上現れる行動は、執務机で眉間に縦じわを刻んで腕組みをしているか、役員室を右往左往しているか、あるいは新しいテクノロジーに浸って浮世を忘れているかということに……。</p>

<p>　みなさんの脳裏に情報システム部の部長が思い当たるようでしたら、その彼（彼女）を想定して、「ああ、こんなことを考えているんだ」と何らかの発見をしてもらえたならば、わたしのこのコラムを書く動機と合致します。</p>

<p>　じゃじゃ馬のような企業システムを巧みな手綱さばきで乗りこなす情報システム部長。そんな理想をイメージして、「企業システムの手綱」とコラムのタイトルを付けました。</p>

<p>　今後とも、よろしくお願いします。</p>]]>
        
    </content>
</entry>

</feed>
