SlideShare uma empresa Scribd logo
1 de 8
Baixar para ler offline
第 9 回 SIA 研究会(例会)レポート

                     「ベテラン編集者からの激励」



 12 月 16 日に第 9 回システムイニシアティブ研究会(例会)が開催されました。
当会初年度の最後の例会でもあり、「ベテラン編集者が語る! システムイニシアティブこの 1 年」というタ
イトルでいつもと少し違う「トーク セッション」が行われました。

 講師は、インプレスビジネスメディア社の田口さんと日経 BP 社の谷島さん。日経コンピュータの編集
長として日本の IT トレンドを伝え、問題提起をしてこられたお 2 人は、システムイニシアティブ研究会の
理事でもあります。

 他のイベントなどではまずない講師の組み合わせなのですが、途中のパネルディスカッションからは、
ガートナージャパンのアナリスト山野井さんも飛び入り参加していただき、会がさらに盛り上がりました。


まず最初に谷島さんから、今回のセッションの基調となるお話をいただきました。
編集者らしく「言葉の定義」からはじめ、システムイニシアティブを 5W1H で整理してくださいました。

  「システムイニシアティブ」を 5W1H で整理
 [Who]
  Who]

 システムイニシアティブ研究会のサイトをみると「ビジネスを成功に導くために、主体的にシステムを開
発するシステム担当者の活動です。」とあるが、イニシアティブをとるのは情報システム担当者だけだろ
うか?
 もともと「ユーザー」という言葉はあまり好きではない。「情報システムを使う」ことが最初に来ているよう
に見えるから。事業をしている人たちがいて、その人が何かをするために IT を使うというのが本来の順
番であるはず。システム部門でない、ユーザー企業の中のユーザーがイニシアティブをとるという取り方
もある。もうひとつは、経営者がとるイニシアティブもある。これまでは当会であまり話をしていない。もっと
広げると、ユーザーには、企業のお客様も入る。製造業であればその会社の製品を使う人でもあり、
サービス業であればそのサービスを受ける人。こうした会社の外にいるユーザーが主体的に使うという
こともある。ということで、「誰が」ということを考え始めると、答えは「全員」になると思う。
 さらに、いわゆるユーザー企業からシステム開発を受注している会社の主体性は何か、協力ソフト会
社の主体性は何か、ということもある。
 今話した人たちが、それぞれ主体性を発揮する。システム部門ががんばるだけではだめなのでは、と
思う。
[How]
  How]

 この会に参加している人に共通していることは、情報システムを開発したり、使ったり、発注したり、と
いった 2011 年現在の「全体のやり方」がいいとは思っていないということ。何か変えなければいけないと
思っている。変えると言うことは意志を持って何かをすること。
 「○○マネジメント」という言葉がたくさんあるし、そのための方法論やツールもある。主体性をもってク
ラウドを利用するということもあるだろう。というわけで How においても何でも入ってしまう。
 1 年の活動を振り返ると、やや「開発」の話が多かった。情報システム責任者が主体性をとるときに、
自分の持っているシステム資産をまず把握して「何がどうなっているのか」をよくみて、それから手を打っ
ていく。開発以前の現状把握から主体性につながっていくと思う。


 [What]
  What]

 最も悩ましい。「主体性をとって、そもそも何をするのか」の議論が足りていないのではないか。20 年
前に田口さんが書かれた「アプリケーション・デザイン」という書籍の前半は What の話だった。その後、
How の話ばかりになってきている。テクノロジーの進歩が速いので記者はそれを追いかけるので精一
杯になっているせいもあるが、そもそも何するの、という話が抜けている。



  2 年めのシステムイニシアティブ研究会に対して
 今後の方向は 2 つある。1つは「システムイニシアティブ」とはこういうものだときちんと定義して、その
定義にそって深く研究する。もう1つは「システムのイニシアティブ」という、これ以上大きいものはない名
前をつけたのだから、もっと大きく行く。
 私としては、後者で行くべきと思っている。さまざまな研究会を見ていると、もともとの主旨はすばらし
いし、やっている人たちもすばらしいのだけれども、失礼ながら「たこつぼ化」していきがち。特化しすぎ
て狭くなり、ちょっと関心がある人がのぞいてみようと思っても、入りにくい雰囲気が醸し出されてくる。
 システムイニシアティブというテーマに関係する「Who」は多数おられる。経営者がこの場で来て話を
してくれるぐらいになればいいなと思う。そういう広い話ができる場はない。今参加している方々は IT 部
門の方が多いと思うが、まずは同期の業務部門の方といっしょに参加してはどうだろうか。


次に、田口さんから、日経 BP 時代に遡って業界の史実を振り返りながら、日本の IT 業界、ユーザーの
これまで、とこれからを語って頂きました。
日本の IT、何かおかしいぞ?
      IT、何かおかしい
        、何かおかしいぞ?
 日経 BP 時代、2000 年前後に「IT 業界に広がるモラルハザード」という記事を企画し、掲載した。
ユーザーが弱くなっているのを背景に、ベンダーも「この程度でいいか」といったプロにあるまじきモラル
ハザードが起きつつあったことに、警鐘を鳴らした。
 一方で、「IT エンジニアを襲う心の病」で、IT エンジニアの過重労働とストレスをとりあげた。
 その後、IT 技術者向けに、技術ではなく、コアスキルやヒューマンスキルの情報を伝える雑誌「日経
IT プロフェッショナル」という雑誌も立ち上げた。エンジニアが専門用語をまくし立てるのではなく、ビジ
ネスの話ができ、ファシリテーションができるようになってほしいという思いから。
 2005 年には、編集長として日経コンピュータを担当した。日経コンピュータはユーザー企業の読者が
減少傾向にあった。誌面品質はさておき、購読数が減っているということは、ユーザーが IT に関わる情
報を必要としなくなった、言い換えれば IT が関心事ではなくなったということかも知れない。主体性にも
関わる問題だが、その背景にあることの一つが、丸投げに近いアウトソーシングであると考え、「アウト
ソーシングの終焉」という記事を掲載したりした。
 話はそれるが、ICT 国際競争力ランキングや国連の電子政府ランキングでは日本は下位。それでも
よい経営ができ、事業が伸びていればいいわけだが、現実にはそうはいってない。一方で、ベンダーが
儲けているのかというとそうでもない。
 IT に関して言えば、クラウド以前にも SOA など、さまざまな技術やアーキテクチャがでてきたが、全部
消化不足。それでユーザーがハッピーならいいのだが、そうでもない。
 そんなわけで「何かおかしいぞ?」という思いがある。ユーザー企業の問題は「ベンダー依存」「自己
責任意識が希薄」ということがよく言われるが、最大の問題は「IT そのものへの関心が低い」ということで
はないかと思う。


 また、システム工学的アプローチがなくなっている。1980 年代は「システムエンジニアリング」という言
葉があった。90 年代はじめには「データモデリング」をしっかりやろうというムーブメントもあった。それ以
降 2000 年代にかけては、そういうことが話題にならなくなった。そもそも工学であるはずの IT が、工学
になっていない。たとえば、建築業界には設計図があり、積算根拠が明快。それが 100 年前からあった
のかというとそうではない。業界でエンジニアリングをして積み上げてきた成果だ。


 IT も 50 年になるが、いまなお、全エンジニア、ユーザーが共通で読める設計書はなく、積算根拠も
ない。(2004 年にまとめた、IT をとりまく問題の図を示し)今も全く変ってない。しわ寄せがエンジニアに
いき、SE は 3K、最大で 42K と言われる仕事になり、東京大学の情報処理系の大学院では席に空きが
ある状態が常態になった。
ERP パッケージにしても、製品そのものに問題があったら世界中で使われる製品になっていないと考
えられないか?
 日本の販売会社、コンサル、ユーザーが、使いこなせなかったのではないか。IT に関する関心が薄
れるとともに、情報リテラシーも軽視してきたのではないか。




そして日経コンピュータの編集長を離れ、まだやることがあると考え「IT Leaders」を立ち上げた。そのと
き、田口さんが考えたのは…

  IT を使いこなすには
    IT がこれからもっと企業の武器になるとすれば、ユーザーが自ら使いこなせるようになること

    そのためには、ベンダー丸投げから脱却し、自分でシステムで選ぶ眼をもつこと

 ユーザーが IT を評価する眼をもてば、ベンダーも「いいものを作れば評価してもらえる」と製品力、
サービス力を磨いて勝負していく、という方向へ変わると考えている。
 欧米においては、IT のプロの CIO がいて、経営者から IT に関する全権をまかされ、それを支える
チームがいる。その人達が、「こうしてくれ」とベンダーに伝える。日本もこういう構造になってほしいという
のが私の期待。
 経営者が IT を詳細に理解するのは無理。ただ「こういうことをやりたいんだ」と具体的に、強烈に打ち
出す経営者になってほしい。結果をみて「これではだめだからおまえ何とかしろ」といっているだけでは
ないだろうか。


ユーザーは、製品、技術、サービスをちゃんと知った上で、使いこなすこと
 Oracle11g を特集したときには、中身を徹底的に調査した。自分もずっとわからなかった。「高すぎる」
とはよく聞くが、なぜ高いのか。ものすごく精緻なしくみがあるからだということが、Oracle 社内にもなかっ
た 1 枚の絵を作成して、はじめて理解できた。
 企業システム部門の人も、プログラムを書いた経験があった方がいい。実際に書かないとしても、プロ
グラム言語毎の特徴や、どんな場合に向くのかを知っておくべき。


そして、ガートナーの山野井さんも飛び入りで、3 氏によるパネルディスカッションと なりました。日米比
較はおもしろいので、よく行われますが、以下のような議論がありました。
谷島 さん:    「そもそも構造が全く違うので、比較には意味が無い。
            日米比較に一喜一憂するのではなく前に進もう」


  山野井 さん:   「どうしても米国が進んでいて、日本が遅れていると見られがちだが必ずしもそう
            ではない」


  田口 さん:    「比較のための比較をするのではなく、米国をはじめとしていろんな国から学ぶべ
            きで、メディアとしてはそういう情報が行き渡るようにしたいと思っている」
日米 CIO 比較は無意味、だけど学ぶべきものは学ぼう。
    米国の情報システム部門は日本の 10 倍、人数がいる。桁違い。日本は外部にいるベンダー
    とあわせて同じくらいになる。 そういう環境で、ほぼ 100%自社の社員を使う米国のプロの
    CIO と、1 割ぐらいが自社の社員で 9 割の外部ベンダーを使う日本の CIO では、役割が違う。

    日本の CIO は事業部門出身が 8 割、そのうち 6 割ぐらいが他の事業と兼任。これは実は日
    本ユニークな状況。 米国は IT 専門で、人材の流動性も高い。業務のことを知らないことも多
    い。

    米国のいいところは、メリハリと割り切り。バックオフィス系などのある程度パッケージでいい部
    分は ベンダーにおまかせ、丸投げだが、サービスレベルなどはきちんと精査。一方で、証券
    会社のトレーディングシステムなどの、自分たちの業務の心臓部分は内製する。

    インドのシステムイニシアティブの例。ICICI 銀行(インド最大の民間銀行)は通常の情報シス
    テム部門は置かず、CIO は CEO が兼任。エンジニアはすべて業務部門に吸収されている。
    これはエンドユーザー部門がイニシアティブをとる極端な例だが、実は合理的。GDP が伸び
    ているインド国内では、競争に勝つにはスピード重視なので、現場に極力近い位置に IT 人
    材がいたほうが柔軟性・即応性が高い。業務部門ごとに勝手にシステムを作るので、その分、
    全社的なガバナンスや標準化が緩くなるが、新興急成長市場で IT を競争の武器に競うので
    あれば、とりあえずそれでもかまわないということ。イニシアティブのとり方には、いろんなやり方
    がある。


  [イニシアティブをとるには]
   イニシアティブをとるには]
 我々は人がいいので「メディアがこう言っている」とか「アメリカが」「他社がこうしている」などと言ってし
まうが、それが主体性から遠のいてしまう原因。
システムイニシアティブをとるには、
       経営者が「これをやりたい」ということ

       システム部門が「アメリカはどうか知らないけど、我々はこれが一番いいと思うからこれでやる」
       ということ


     システムイニシアティブのムーブメント
※ システムイニシアティブ研究会のような会ができるということは、日本が「変わって来ている」ということ
だ、と山野井さんはいいます。


 日本企業の CIO に日々取材をする中で、CIO の考え方が変ってきているとか。「ベンダーにお金を
使いすぎているのではないか。」「主体性を失っているのではないか」と考えている人が増えているそう
です。

 会場からの質問をうけて、これから「システムイニシアティブ」をムーブメントにしていくためにはビジネ
ス側の人を巻き込むことであり、ビジネス側の人との共通言語で話をすることだ、という意見がでました。


     イニシアティブをとるべき領域
 会場から、「ユーザーとしてこういう技術力持たないとベンダーマネジメントできないという話はわか
る。でも、ほんとにそんなことできるのか。どういうレベルまでやらないといけないか」という質問がありまし
た。


3 氏からの回答は、以下のとおり、


谷島 さん:

 中核のビジネスシステムを動かす人なのだから、社内で雇用したほうがいい。理想論としては、設計
開発運用全部やった方がいいのだが、すべてはできないとなると、私は運用を残すべきだと思う。オペ
レーションを子会社にするのはよくないし、意味が無い。
 メリハリで外に出すものがあるのはいいが運用をしないとシステムの課題がわからないし、どう変える
べきかも見えないから。
 地味に見えるが、IT を使いこなしといったとき、運用は根幹だと思う。
田口 さん:

 アウトソーシングは、最初はいい。両者とも、間違いなく熱い思いを持って始めるが、冷めていく。日
産は 5 年前にやめて、5 年間かけてアウトソースから主体性を取り戻してきた。日本たばこも子会社を
データに売却した後、海外の会社を買収するなかでガバナンスが効かなくなって、経営企画から 40 人
をぬいてシステム部門を新規につくり、主体性を取り戻した。
 私も運用に関してはキーだと思う。ただ、仮に 3 人しかいなくても、「イニシアティブ」はあらゆる分野
でとれると思う。運用ばかりに人をさいてしまって、ベンダーからの提案を評価できないのでは主体性を
もっているとはいえない。
 丸投げからの脱却に成功した企業が、みんな最初にやっているのは可視化。システム資産の可視
化、データの可視化をやるとやるべきことが見える。


山野井 さん:

 アウトソーシングは、1 社依存からマルチソーシングになってきている。その中で一部は内製に戻す
傾向。何を残すかという点で、運用保守というのはその通り。性格にいえば、「キモ」のシステムは内製
開発、運用すべき。一方で全部のシステムを運用すべきかといえば、それは効率性と経営資源の最低
配分の中で外だしできるところは出してメリハリをつける。
 それから、情報設計は、IT 部門しかできないと思っている。あるユーザーは、「テクノロジーをおっても、
ベンダーにはかなわない。業務知識は、現場の方が圧倒的に知っている。情報システム部門の差別化
ポイントは、情報設計だ」と言っていて、その通りと思う。モデリング、データを全社俯瞰的に見ることが
できるのは情報システム部門だけ。


 IT 業界に対する熱い思いと熱い議論が繰り広げられた、とても濃い 2 時間半でした。
最後に、木内会長から初年度の締めくくりのメッセージを頂きました。


 IT Leaders 創刊号から「是正勧告」という記事を書いていて、「ベンダー丸投げをやめよう」「過度なベ
ンダー依存をやめよう」「当事者意識をもってシステムを考えよう」と、言ってきた。
 当り前のことを言わないといけないのは、実際そうなってないから。
 ユーザーが衰退している。ユーザー企業が衰退したら、日本のベンダーをだめにする。
 だが、皆の考えが変っている傾向は見えている。最近、私が大手ベンダーの社内会議に講演者とし
て呼ばれたりする。ベンダーの社長は「耳の痛い話だが、変らないといけないと思う」と言ってくださる。
 こういう活動を少しずつでも地道にやっていこうと思う。
システム部門は、全体を俯瞰できる立場にいるのだから、価値の高い仕事ができるはず。来年もよろ
しくお願いします。



                                           以上

Mais conteúdo relacionado

Destaque

第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料
第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料
第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料Tae Yoshida
 
第15回SIA例会プレゼン資料
第15回SIA例会プレゼン資料第15回SIA例会プレゼン資料
第15回SIA例会プレゼン資料Tae Yoshida
 
第7回SIA研究会(例会)プレゼン資料 堀野様
第7回SIA研究会(例会)プレゼン資料 堀野様第7回SIA研究会(例会)プレゼン資料 堀野様
第7回SIA研究会(例会)プレゼン資料 堀野様Tae Yoshida
 
第6回SIA研究会(例会)プレゼン資料
第6回SIA研究会(例会)プレゼン資料第6回SIA研究会(例会)プレゼン資料
第6回SIA研究会(例会)プレゼン資料Tae Yoshida
 
Fo shao corporation
Fo shao corporationFo shao corporation
Fo shao corporationalben1983
 
ITGM#4 Технический долг 2.0
ITGM#4 Технический долг 2.0ITGM#4 Технический долг 2.0
ITGM#4 Технический долг 2.0Maxim Shulga
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料Tae Yoshida
 
第8回SIA研究会 JTB情報システム 野々垣様
第8回SIA研究会 JTB情報システム 野々垣様第8回SIA研究会 JTB情報システム 野々垣様
第8回SIA研究会 JTB情報システム 野々垣様Tae Yoshida
 
FitNesse+PowerSlim on Windows
FitNesse+PowerSlim on WindowsFitNesse+PowerSlim on Windows
FitNesse+PowerSlim on WindowsMaxim Shulga
 
第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料Tae Yoshida
 
Discrimination at work
Discrimination at workDiscrimination at work
Discrimination at workalben1983
 

Destaque (11)

第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料
第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料
第4回SIA研究会(例会)プレゼン資料1_ m2 soft 紹介資料
 
第15回SIA例会プレゼン資料
第15回SIA例会プレゼン資料第15回SIA例会プレゼン資料
第15回SIA例会プレゼン資料
 
第7回SIA研究会(例会)プレゼン資料 堀野様
第7回SIA研究会(例会)プレゼン資料 堀野様第7回SIA研究会(例会)プレゼン資料 堀野様
第7回SIA研究会(例会)プレゼン資料 堀野様
 
第6回SIA研究会(例会)プレゼン資料
第6回SIA研究会(例会)プレゼン資料第6回SIA研究会(例会)プレゼン資料
第6回SIA研究会(例会)プレゼン資料
 
Fo shao corporation
Fo shao corporationFo shao corporation
Fo shao corporation
 
ITGM#4 Технический долг 2.0
ITGM#4 Технический долг 2.0ITGM#4 Технический долг 2.0
ITGM#4 Технический долг 2.0
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
 
第8回SIA研究会 JTB情報システム 野々垣様
第8回SIA研究会 JTB情報システム 野々垣様第8回SIA研究会 JTB情報システム 野々垣様
第8回SIA研究会 JTB情報システム 野々垣様
 
FitNesse+PowerSlim on Windows
FitNesse+PowerSlim on WindowsFitNesse+PowerSlim on Windows
FitNesse+PowerSlim on Windows
 
第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料
 
Discrimination at work
Discrimination at workDiscrimination at work
Discrimination at work
 

Semelhante a 第9回SIA研究会(例会)レポート

国際観光コンベンションシンポジウム2016
国際観光コンベンションシンポジウム2016国際観光コンベンションシンポジウム2016
国際観光コンベンションシンポジウム2016Masao Mori
 
社内SNSと巻き込み力
社内SNSと巻き込み力社内SNSと巻き込み力
社内SNSと巻き込み力八木橋 パチ
 
エンジニアのキャリアを考える
エンジニアのキャリアを考えるエンジニアのキャリアを考える
エンジニアのキャリアを考えるMKT International Inc.
 
日本のITがナゼ海外企業に勝てないのか~序章~
日本のITがナゼ海外企業に勝てないのか~序章~日本のITがナゼ海外企業に勝てないのか~序章~
日本のITがナゼ海外企業に勝てないのか~序章~kojirokishi
 
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由Hironori Washizaki
 
BtoBマーケティングにおけるML/NLPの活用
BtoBマーケティングにおけるML/NLPの活用BtoBマーケティングにおけるML/NLPの活用
BtoBマーケティングにおけるML/NLPの活用Akira Kitauchi
 
IBMサイトに見る オウンドメディアの コアと変化
IBMサイトに見る オウンドメディアの コアと変化IBMサイトに見る オウンドメディアの コアと変化
IBMサイトに見る オウンドメディアの コアと変化Toshio Yamashita
 
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~Saharu Doi
 
AIとロボットが変える人の未来
AIとロボットが変える人の未来AIとロボットが変える人の未来
AIとロボットが変える人の未来良治 富田
 
かかってこい
かかってこいかかってこい
かかってこいg3akk
 
Webの勉強会#12
Webの勉強会#12Webの勉強会#12
Webの勉強会#12MarlboroLand
 
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~法林浩之
 
The 12th picmet japan_minitalk
The 12th picmet japan_minitalkThe 12th picmet japan_minitalk
The 12th picmet japan_minitalkKunio Shirahada
 
201009 破壊と創造の人事Final
201009 破壊と創造の人事Final201009 破壊と創造の人事Final
201009 破壊と創造の人事Finalmeyuimo
 
データ分析スクリプトのツール化入門 - PyConJP 2016
データ分析スクリプトのツール化入門 - PyConJP 2016データ分析スクリプトのツール化入門 - PyConJP 2016
データ分析スクリプトのツール化入門 - PyConJP 2016Akinori Kohno
 
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)Members_corp
 
Discussion IA Meetup Japan featuring IAS17
Discussion IA Meetup Japan featuring IAS17Discussion IA Meetup Japan featuring IAS17
Discussion IA Meetup Japan featuring IAS17Concent, Inc.
 
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいこと
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいことMLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいこと
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいことRakuten Group, Inc.
 

Semelhante a 第9回SIA研究会(例会)レポート (19)

国際観光コンベンションシンポジウム2016
国際観光コンベンションシンポジウム2016国際観光コンベンションシンポジウム2016
国際観光コンベンションシンポジウム2016
 
社内SNSと巻き込み力
社内SNSと巻き込み力社内SNSと巻き込み力
社内SNSと巻き込み力
 
エンジニアのキャリアを考える
エンジニアのキャリアを考えるエンジニアのキャリアを考える
エンジニアのキャリアを考える
 
日本のITがナゼ海外企業に勝てないのか~序章~
日本のITがナゼ海外企業に勝てないのか~序章~日本のITがナゼ海外企業に勝てないのか~序章~
日本のITがナゼ海外企業に勝てないのか~序章~
 
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
 
BtoBマーケティングにおけるML/NLPの活用
BtoBマーケティングにおけるML/NLPの活用BtoBマーケティングにおけるML/NLPの活用
BtoBマーケティングにおけるML/NLPの活用
 
IBMサイトに見る オウンドメディアの コアと変化
IBMサイトに見る オウンドメディアの コアと変化IBMサイトに見る オウンドメディアの コアと変化
IBMサイトに見る オウンドメディアの コアと変化
 
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~
【資料】AIとデータプラットフォームがもたらす世界 ~Fintech, HRtechの最新事例と合わせて~
 
AIとロボットが変える人の未来
AIとロボットが変える人の未来AIとロボットが変える人の未来
AIとロボットが変える人の未来
 
かかってこい
かかってこいかかってこい
かかってこい
 
もういちどOSSのことを思い出してみよう
もういちどOSSのことを思い出してみようもういちどOSSのことを思い出してみよう
もういちどOSSのことを思い出してみよう
 
Webの勉強会#12
Webの勉強会#12Webの勉強会#12
Webの勉強会#12
 
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~
ITの話ができる仲間を作ろう ~IT業界とコミュニティ活動~
 
The 12th picmet japan_minitalk
The 12th picmet japan_minitalkThe 12th picmet japan_minitalk
The 12th picmet japan_minitalk
 
201009 破壊と創造の人事Final
201009 破壊と創造の人事Final201009 破壊と創造の人事Final
201009 破壊と創造の人事Final
 
データ分析スクリプトのツール化入門 - PyConJP 2016
データ分析スクリプトのツール化入門 - PyConJP 2016データ分析スクリプトのツール化入門 - PyConJP 2016
データ分析スクリプトのツール化入門 - PyConJP 2016
 
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2014年10月号(♯54)
 
Discussion IA Meetup Japan featuring IAS17
Discussion IA Meetup Japan featuring IAS17Discussion IA Meetup Japan featuring IAS17
Discussion IA Meetup Japan featuring IAS17
 
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいこと
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいことMLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいこと
MLOps Yearning ~ 実運用システムを構築する前にデータサイエンティストが考えておきたいこと
 

第9回SIA研究会(例会)レポート

  • 1. 第 9 回 SIA 研究会(例会)レポート 「ベテラン編集者からの激励」 12 月 16 日に第 9 回システムイニシアティブ研究会(例会)が開催されました。 当会初年度の最後の例会でもあり、「ベテラン編集者が語る! システムイニシアティブこの 1 年」というタ イトルでいつもと少し違う「トーク セッション」が行われました。 講師は、インプレスビジネスメディア社の田口さんと日経 BP 社の谷島さん。日経コンピュータの編集 長として日本の IT トレンドを伝え、問題提起をしてこられたお 2 人は、システムイニシアティブ研究会の 理事でもあります。 他のイベントなどではまずない講師の組み合わせなのですが、途中のパネルディスカッションからは、 ガートナージャパンのアナリスト山野井さんも飛び入り参加していただき、会がさらに盛り上がりました。 まず最初に谷島さんから、今回のセッションの基調となるお話をいただきました。 編集者らしく「言葉の定義」からはじめ、システムイニシアティブを 5W1H で整理してくださいました。 「システムイニシアティブ」を 5W1H で整理 [Who] Who] システムイニシアティブ研究会のサイトをみると「ビジネスを成功に導くために、主体的にシステムを開 発するシステム担当者の活動です。」とあるが、イニシアティブをとるのは情報システム担当者だけだろ うか? もともと「ユーザー」という言葉はあまり好きではない。「情報システムを使う」ことが最初に来ているよう に見えるから。事業をしている人たちがいて、その人が何かをするために IT を使うというのが本来の順 番であるはず。システム部門でない、ユーザー企業の中のユーザーがイニシアティブをとるという取り方 もある。もうひとつは、経営者がとるイニシアティブもある。これまでは当会であまり話をしていない。もっと 広げると、ユーザーには、企業のお客様も入る。製造業であればその会社の製品を使う人でもあり、 サービス業であればそのサービスを受ける人。こうした会社の外にいるユーザーが主体的に使うという こともある。ということで、「誰が」ということを考え始めると、答えは「全員」になると思う。 さらに、いわゆるユーザー企業からシステム開発を受注している会社の主体性は何か、協力ソフト会 社の主体性は何か、ということもある。 今話した人たちが、それぞれ主体性を発揮する。システム部門ががんばるだけではだめなのでは、と 思う。
  • 2. [How] How] この会に参加している人に共通していることは、情報システムを開発したり、使ったり、発注したり、と いった 2011 年現在の「全体のやり方」がいいとは思っていないということ。何か変えなければいけないと 思っている。変えると言うことは意志を持って何かをすること。 「○○マネジメント」という言葉がたくさんあるし、そのための方法論やツールもある。主体性をもってク ラウドを利用するということもあるだろう。というわけで How においても何でも入ってしまう。 1 年の活動を振り返ると、やや「開発」の話が多かった。情報システム責任者が主体性をとるときに、 自分の持っているシステム資産をまず把握して「何がどうなっているのか」をよくみて、それから手を打っ ていく。開発以前の現状把握から主体性につながっていくと思う。 [What] What] 最も悩ましい。「主体性をとって、そもそも何をするのか」の議論が足りていないのではないか。20 年 前に田口さんが書かれた「アプリケーション・デザイン」という書籍の前半は What の話だった。その後、 How の話ばかりになってきている。テクノロジーの進歩が速いので記者はそれを追いかけるので精一 杯になっているせいもあるが、そもそも何するの、という話が抜けている。 2 年めのシステムイニシアティブ研究会に対して 今後の方向は 2 つある。1つは「システムイニシアティブ」とはこういうものだときちんと定義して、その 定義にそって深く研究する。もう1つは「システムのイニシアティブ」という、これ以上大きいものはない名 前をつけたのだから、もっと大きく行く。 私としては、後者で行くべきと思っている。さまざまな研究会を見ていると、もともとの主旨はすばらし いし、やっている人たちもすばらしいのだけれども、失礼ながら「たこつぼ化」していきがち。特化しすぎ て狭くなり、ちょっと関心がある人がのぞいてみようと思っても、入りにくい雰囲気が醸し出されてくる。 システムイニシアティブというテーマに関係する「Who」は多数おられる。経営者がこの場で来て話を してくれるぐらいになればいいなと思う。そういう広い話ができる場はない。今参加している方々は IT 部 門の方が多いと思うが、まずは同期の業務部門の方といっしょに参加してはどうだろうか。 次に、田口さんから、日経 BP 時代に遡って業界の史実を振り返りながら、日本の IT 業界、ユーザーの これまで、とこれからを語って頂きました。
  • 3. 日本の IT、何かおかしいぞ? IT、何かおかしい 、何かおかしいぞ? 日経 BP 時代、2000 年前後に「IT 業界に広がるモラルハザード」という記事を企画し、掲載した。 ユーザーが弱くなっているのを背景に、ベンダーも「この程度でいいか」といったプロにあるまじきモラル ハザードが起きつつあったことに、警鐘を鳴らした。 一方で、「IT エンジニアを襲う心の病」で、IT エンジニアの過重労働とストレスをとりあげた。 その後、IT 技術者向けに、技術ではなく、コアスキルやヒューマンスキルの情報を伝える雑誌「日経 IT プロフェッショナル」という雑誌も立ち上げた。エンジニアが専門用語をまくし立てるのではなく、ビジ ネスの話ができ、ファシリテーションができるようになってほしいという思いから。 2005 年には、編集長として日経コンピュータを担当した。日経コンピュータはユーザー企業の読者が 減少傾向にあった。誌面品質はさておき、購読数が減っているということは、ユーザーが IT に関わる情 報を必要としなくなった、言い換えれば IT が関心事ではなくなったということかも知れない。主体性にも 関わる問題だが、その背景にあることの一つが、丸投げに近いアウトソーシングであると考え、「アウト ソーシングの終焉」という記事を掲載したりした。 話はそれるが、ICT 国際競争力ランキングや国連の電子政府ランキングでは日本は下位。それでも よい経営ができ、事業が伸びていればいいわけだが、現実にはそうはいってない。一方で、ベンダーが 儲けているのかというとそうでもない。 IT に関して言えば、クラウド以前にも SOA など、さまざまな技術やアーキテクチャがでてきたが、全部 消化不足。それでユーザーがハッピーならいいのだが、そうでもない。 そんなわけで「何かおかしいぞ?」という思いがある。ユーザー企業の問題は「ベンダー依存」「自己 責任意識が希薄」ということがよく言われるが、最大の問題は「IT そのものへの関心が低い」ということで はないかと思う。 また、システム工学的アプローチがなくなっている。1980 年代は「システムエンジニアリング」という言 葉があった。90 年代はじめには「データモデリング」をしっかりやろうというムーブメントもあった。それ以 降 2000 年代にかけては、そういうことが話題にならなくなった。そもそも工学であるはずの IT が、工学 になっていない。たとえば、建築業界には設計図があり、積算根拠が明快。それが 100 年前からあった のかというとそうではない。業界でエンジニアリングをして積み上げてきた成果だ。 IT も 50 年になるが、いまなお、全エンジニア、ユーザーが共通で読める設計書はなく、積算根拠も ない。(2004 年にまとめた、IT をとりまく問題の図を示し)今も全く変ってない。しわ寄せがエンジニアに いき、SE は 3K、最大で 42K と言われる仕事になり、東京大学の情報処理系の大学院では席に空きが ある状態が常態になった。
  • 4. ERP パッケージにしても、製品そのものに問題があったら世界中で使われる製品になっていないと考 えられないか? 日本の販売会社、コンサル、ユーザーが、使いこなせなかったのではないか。IT に関する関心が薄 れるとともに、情報リテラシーも軽視してきたのではないか。 そして日経コンピュータの編集長を離れ、まだやることがあると考え「IT Leaders」を立ち上げた。そのと き、田口さんが考えたのは… IT を使いこなすには IT がこれからもっと企業の武器になるとすれば、ユーザーが自ら使いこなせるようになること そのためには、ベンダー丸投げから脱却し、自分でシステムで選ぶ眼をもつこと ユーザーが IT を評価する眼をもてば、ベンダーも「いいものを作れば評価してもらえる」と製品力、 サービス力を磨いて勝負していく、という方向へ変わると考えている。 欧米においては、IT のプロの CIO がいて、経営者から IT に関する全権をまかされ、それを支える チームがいる。その人達が、「こうしてくれ」とベンダーに伝える。日本もこういう構造になってほしいという のが私の期待。 経営者が IT を詳細に理解するのは無理。ただ「こういうことをやりたいんだ」と具体的に、強烈に打ち 出す経営者になってほしい。結果をみて「これではだめだからおまえ何とかしろ」といっているだけでは ないだろうか。 ユーザーは、製品、技術、サービスをちゃんと知った上で、使いこなすこと Oracle11g を特集したときには、中身を徹底的に調査した。自分もずっとわからなかった。「高すぎる」 とはよく聞くが、なぜ高いのか。ものすごく精緻なしくみがあるからだということが、Oracle 社内にもなかっ た 1 枚の絵を作成して、はじめて理解できた。 企業システム部門の人も、プログラムを書いた経験があった方がいい。実際に書かないとしても、プロ グラム言語毎の特徴や、どんな場合に向くのかを知っておくべき。 そして、ガートナーの山野井さんも飛び入りで、3 氏によるパネルディスカッションと なりました。日米比 較はおもしろいので、よく行われますが、以下のような議論がありました。
  • 5. 谷島 さん: 「そもそも構造が全く違うので、比較には意味が無い。 日米比較に一喜一憂するのではなく前に進もう」 山野井 さん: 「どうしても米国が進んでいて、日本が遅れていると見られがちだが必ずしもそう ではない」 田口 さん: 「比較のための比較をするのではなく、米国をはじめとしていろんな国から学ぶべ きで、メディアとしてはそういう情報が行き渡るようにしたいと思っている」 日米 CIO 比較は無意味、だけど学ぶべきものは学ぼう。 米国の情報システム部門は日本の 10 倍、人数がいる。桁違い。日本は外部にいるベンダー とあわせて同じくらいになる。 そういう環境で、ほぼ 100%自社の社員を使う米国のプロの CIO と、1 割ぐらいが自社の社員で 9 割の外部ベンダーを使う日本の CIO では、役割が違う。 日本の CIO は事業部門出身が 8 割、そのうち 6 割ぐらいが他の事業と兼任。これは実は日 本ユニークな状況。 米国は IT 専門で、人材の流動性も高い。業務のことを知らないことも多 い。 米国のいいところは、メリハリと割り切り。バックオフィス系などのある程度パッケージでいい部 分は ベンダーにおまかせ、丸投げだが、サービスレベルなどはきちんと精査。一方で、証券 会社のトレーディングシステムなどの、自分たちの業務の心臓部分は内製する。 インドのシステムイニシアティブの例。ICICI 銀行(インド最大の民間銀行)は通常の情報シス テム部門は置かず、CIO は CEO が兼任。エンジニアはすべて業務部門に吸収されている。 これはエンドユーザー部門がイニシアティブをとる極端な例だが、実は合理的。GDP が伸び ているインド国内では、競争に勝つにはスピード重視なので、現場に極力近い位置に IT 人 材がいたほうが柔軟性・即応性が高い。業務部門ごとに勝手にシステムを作るので、その分、 全社的なガバナンスや標準化が緩くなるが、新興急成長市場で IT を競争の武器に競うので あれば、とりあえずそれでもかまわないということ。イニシアティブのとり方には、いろんなやり方 がある。 [イニシアティブをとるには] イニシアティブをとるには] 我々は人がいいので「メディアがこう言っている」とか「アメリカが」「他社がこうしている」などと言ってし まうが、それが主体性から遠のいてしまう原因。
  • 6. システムイニシアティブをとるには、 経営者が「これをやりたい」ということ システム部門が「アメリカはどうか知らないけど、我々はこれが一番いいと思うからこれでやる」 ということ システムイニシアティブのムーブメント ※ システムイニシアティブ研究会のような会ができるということは、日本が「変わって来ている」ということ だ、と山野井さんはいいます。 日本企業の CIO に日々取材をする中で、CIO の考え方が変ってきているとか。「ベンダーにお金を 使いすぎているのではないか。」「主体性を失っているのではないか」と考えている人が増えているそう です。 会場からの質問をうけて、これから「システムイニシアティブ」をムーブメントにしていくためにはビジネ ス側の人を巻き込むことであり、ビジネス側の人との共通言語で話をすることだ、という意見がでました。 イニシアティブをとるべき領域 会場から、「ユーザーとしてこういう技術力持たないとベンダーマネジメントできないという話はわか る。でも、ほんとにそんなことできるのか。どういうレベルまでやらないといけないか」という質問がありまし た。 3 氏からの回答は、以下のとおり、 谷島 さん: 中核のビジネスシステムを動かす人なのだから、社内で雇用したほうがいい。理想論としては、設計 開発運用全部やった方がいいのだが、すべてはできないとなると、私は運用を残すべきだと思う。オペ レーションを子会社にするのはよくないし、意味が無い。 メリハリで外に出すものがあるのはいいが運用をしないとシステムの課題がわからないし、どう変える べきかも見えないから。 地味に見えるが、IT を使いこなしといったとき、運用は根幹だと思う。
  • 7. 田口 さん: アウトソーシングは、最初はいい。両者とも、間違いなく熱い思いを持って始めるが、冷めていく。日 産は 5 年前にやめて、5 年間かけてアウトソースから主体性を取り戻してきた。日本たばこも子会社を データに売却した後、海外の会社を買収するなかでガバナンスが効かなくなって、経営企画から 40 人 をぬいてシステム部門を新規につくり、主体性を取り戻した。 私も運用に関してはキーだと思う。ただ、仮に 3 人しかいなくても、「イニシアティブ」はあらゆる分野 でとれると思う。運用ばかりに人をさいてしまって、ベンダーからの提案を評価できないのでは主体性を もっているとはいえない。 丸投げからの脱却に成功した企業が、みんな最初にやっているのは可視化。システム資産の可視 化、データの可視化をやるとやるべきことが見える。 山野井 さん: アウトソーシングは、1 社依存からマルチソーシングになってきている。その中で一部は内製に戻す 傾向。何を残すかという点で、運用保守というのはその通り。性格にいえば、「キモ」のシステムは内製 開発、運用すべき。一方で全部のシステムを運用すべきかといえば、それは効率性と経営資源の最低 配分の中で外だしできるところは出してメリハリをつける。 それから、情報設計は、IT 部門しかできないと思っている。あるユーザーは、「テクノロジーをおっても、 ベンダーにはかなわない。業務知識は、現場の方が圧倒的に知っている。情報システム部門の差別化 ポイントは、情報設計だ」と言っていて、その通りと思う。モデリング、データを全社俯瞰的に見ることが できるのは情報システム部門だけ。 IT 業界に対する熱い思いと熱い議論が繰り広げられた、とても濃い 2 時間半でした。 最後に、木内会長から初年度の締めくくりのメッセージを頂きました。 IT Leaders 創刊号から「是正勧告」という記事を書いていて、「ベンダー丸投げをやめよう」「過度なベ ンダー依存をやめよう」「当事者意識をもってシステムを考えよう」と、言ってきた。 当り前のことを言わないといけないのは、実際そうなってないから。 ユーザーが衰退している。ユーザー企業が衰退したら、日本のベンダーをだめにする。 だが、皆の考えが変っている傾向は見えている。最近、私が大手ベンダーの社内会議に講演者とし て呼ばれたりする。ベンダーの社長は「耳の痛い話だが、変らないといけないと思う」と言ってくださる。 こういう活動を少しずつでも地道にやっていこうと思う。