投稿

CIOって?

イメージ
  かつては、仕事柄、大手の情報システム関連企業(主にシステム開発会社やパッケージソフトウェア会社)主催の講演会や勉強会に出席することが多くありました。 たいていは、午後から始まり、ゲストスピーカーの講演がひとつかふたつ、次に、主催企業の製品説明のプレゼンテーションがひとつかふたつという内容です。そしてその後、参加者を交えての懇親会(立食)が行われます。 私は、目的無しに世間話をするのがあまり得意ではないので、乾杯の後、少しの軽食を口にしながらビールを飲んで時間を潰すのを常としていました。 情報システム部門の責任者を集めたある講演会後の懇親会の席で、いつものように手持無沙汰でいると、ひとりの男性が「名刺交換を」と近づいてきました。その方は、私より3~4歳くらい年上に見えました。私も知っている某中堅製薬会社の情報システム部長ということでした。 その方曰く「私は、ずっと営業畑で支店長まで勤めたのですが、急に物流部長の命を受けて本社に入り、3年後に、今度は、情報システム部長などというものに追いやられてしまいました。コンピュータのことは全くの素人なのに。サラリーマン人生がこれで終わるのは淋しいです」 初対面の私に対して「追いやられてしまいました」という表現で自己紹介されたことに大いなる違和感と失望を感じましたが、この方にとって情報システム部長は「Career Is Over (CIO)」だったようです。 こんな上司を持った部員がかわいそうですよね。 🙉

社内情報システム部門のコミュニケーション

イメージ
「コミュニケーション」は、仕事上よく使われる言葉です。営業部門で働いている方は、日々、顧客とのコミュニケーションに工夫されていることだと思いますし、話し上手な営業の方とのコミュニケーションの場面では、ついついセールストークに引き込まれたりします。 社内の IT 部門でも「コミュニケーション」は大事な要素です。 IT 部門内のコミュニケーションはもちろんですが、社内のシステム利用部門もシステム化のための要件確認などでのコミュニケーションの相手になりますし、予算獲得や会社のデジタル化 / システム化のための方針策定には経営層もコミュニケーションの対象になります。 また、外部のベンダもコミュニケーションの大事な相手です。この記事では、外部のシステム開発ベンダとのコミュニケーションの2つのポイントについて解説したいと思います。   【第1のポイント】 相手が誰であれ、コミュニケーションの一番大事なポイントは「お互いの考え方や思考プロセスを理解すること」です。これは、対ベンダの場合にもあてはまります。 たとえば業務システム開発の場合、発注側(社内 IT 部門)も受注側(外部システム開発ベンダ)も「要件への適合性」「適正な原価」「期限内の納品」「品質の確保」は言葉として同じものを目指しますが、その内容には微妙な違いがあります。 一番わかりやすいのは価格です。受注側はできるだけ原価を抑えたいと考え、発注側は良いものをできるだけ安く買いたいと考えるのは当然です。また、要件についても、受注側はドキュメント(要件定義書)に書かれたものが「要件」ですが、発注側はドキュメントに書かれた要件の背景までを「要件」と考える傾向があります。 このように発注側はシステムが完成してリリースした後の利用部門の顔を思い浮かべるのに対して、受注側ではシステムを納品することが最終目標になる(納品後のメンテナンス契約も有りますが)という点で、大げさに言うと価値観が違うのです。価値観を合わせるための事前コミュニケーションに十分な時間を取りましょう。 【第2のポイント】   RFP に対する回答(提案書)をもとに協議する際には、社内 IT 部門で使う用語とベンダが使う用語のすり合わせをしましょう。  共通フレームなどで定義されてはいるものの、よく問題になる例のひとつが「プロジ

EUCと隠れIT(ShadowIT)

イメージ
(前もって言っておきますが、私は、逆説的な「情報システム部門不要論者」です。その意図は、記事の最後に書きます) EUCという3文字略語があります。End User Computingの略でPCと表計算ソフトがポピュラーになってから定着したことばです。情報システム部門がホストコンピュータ系システムの仕事やインフラまわりの仕事が多く、社内のPC利用者の細かいお世話まで手が回らないので「パソコンの表計算ソフトなどを使ってできる仕事は情報システム部門に頼らずに自分でやって!」という意味で、よく言えば「利用部門にとっては小回りが利く」ということになります。 「EUCの促進と指導は情報システム部門の仕事だ」と論じた本もあるくらいです。 でも、実はここには難しい問題が内在しています。 EUCと言っている間は良いのですが、利用部門内にいるPC好きの社員が表計算ソフトに飽き足らず、Microsoft Accessなどをつかって簡単なデータベースを作り、業務アプリケーションのようなものに手を出し始めるのです。そして、それがエスカレートすると、データベースにフロントエンドのWebシステムをつけて「ユーザフレンドリなシステム」が完成するのです。ここまでくるとEUCを越えてEUD(End User Development)になってしまいます。情報システム部門は全体最適を求めるという性質(使命?)があり、個別部門向けのシステムの最適化に手を出す余裕はありません。これに端を発するEUC/EUDの問題には次のようなものがあります。 情報システム部門が提供する業務アプリケーションとEUCで必要な データが二重入力 される。 それに気づいたEUC部門(この記事では社内利用部門をこう呼ぶことにします)は元システムからの データのダウンロードやリアルタイムのリンクを情報システム部門に求める ようになる。 それに情報システム部門が対応しないため、EUC部門が、 直接、外部ベンダに問い合わせ をかけ、発注まで行ってしまうという 組織のガバナンスを逸脱する 事態が発生する。 また、発注という方式ではなく、 外部ベンダやテンプスタッフを常駐させる ケースもある 外部ベンダが 情報システム部門ではなく、 直接、利用部門にアプローチ するようになる この際に必要な 情報システム化の予算もEUC部門で保持 することにな

社内情報システム部門の名称と所属位置

イメージ
このブログのページビュー「 社内情報システム部門への想い 」にも書いていますが、私が最初に所属した情報システム部門の名称は「経理部電算課」でした。そろそろ我が社もコンピュータ化しなければと思った経営陣が1983年に設立した部署(私は1984年から所属)で、私が異動した時は、課長(経理部経理課長と兼務)と、1年上の先輩と、私と、全く仕事をしない女子社員の4名でした。名称からわかるように「まずは経理業務を新しい情報システムで合理化」が目的で、翌年、部長が採用され、課長が兼務でなくなり、情報システム部に格上げされました。 その後転職した会社での所属は当初「情報システム部」だったのですが、役員が「情報システム部門はもっとサービス精神を持つべきだ」という考えの人で「情報サービス部」という名前になりました。「サービスはタダ」と無意識に思ってしまう日本人のひとりとしては、あまりうれしい名前ではありませんでした。 次の転職先の会社では「情報システム部」。最後にもう一度転職した会社も「情報システム部」でした。ただし、最後に勤めた会社では途中から「IT部」という名称になりました。ドイツ人のCIOが「ビジネスがどうのこうのと言わず、もっとITとしてのテクニックを磨け」という考え方の人でした。 1点付け加えないといけないことは「全ての組織において最上層はCFOだったこと(CIOもCFOにレポートしていた)」です。これは多くの企業でも同じかもしれません。 これが私のケースとしての所属部署の名称の変遷ですが、実は単に名称が変化しただけではなく、技術の変化とも微妙にリンクしています。 「経理部電算課」時代は、まさに、会計を中心とした業務のコンピュータ化が注目されていたころでした。そして、「情報サービス部」の時代にはパソコンが普及し始めた頃です。その後は「情報システム部」時代が続きますが、キーワードとしては「インターネット、ERP,SFA,CRM」に加えて「MIS(Management Information System)、SIS(Strategic Information System)、DSS(Decision Support System)などのバズワードが闊歩する」という感じです。「IT部」の時代になると「5G、モバイル、ユビキタス」というように業務のシステム化が一巡し、RPAの足音が近

業種/業態と情報システム部門の分類

イメージ
  情報システム部門とひと言で言っても業種や業態、企業規模によって役割が違います。これは、とても重要なポイントで、仮に、今、この記事を読んでいる方が就活中や転職活動中の人であれば、この考え方無しではうまくいかないのではないかと思いますし、既に就業中の方であれば、そのキャリア(career raddar)にも大きくかかわってきます。以下に3(+1)の分類をしてみようと思います。実際にはこれらの複合形になっていますので、企業をきっちりと分類できるわけではありませんが、イメージは掴んでいただけると思います。 Ⅰ.情報システムを売上の原資にしている会社 :システムインテグレータ/システム開発会社と呼ばれるような情報システムを売っている会社のことですが、その社内にも情報システム部門はあります。企業規模にもよりますが「情報システムを売っているのに社内システムは陳腐」では困るので、この情報システム部門は高度な技術力や情報システムリテラシーが要求されます。 Ⅱ.情報システム無しではビジネスが成り立たない会社 :銀行や証券会社などの金融系の会社、ネットショッピングの会社が代表例ですが、ここの情報システム部門はシステムの停止が許されない・1円の狂いも許されないというシビアな世界で仕事をしなければいけません。特に金融系はシステム開発のプロジェクトも大規模で、期限や品質の重視は想像に難くありません。 Ⅲ.情報システムを利用することで競争優位を追求する会社 :ここには様々な種類の企業が分類されます。私もこの分類の会社の情報システム部門に所属していましたが、他の分類以上にビジネスセンスが要求されますし、競争優位のためのイノベーションをもとめられることも多くあります。またそのため「攻めと守り(セキュリティなど)」をバランスよくコントロールすることも大切なスキルです。 Ⅳ.情報システムが事務系の仕事を支える会社 :これは他の3つの分類とは毛色が少し違っており、情報システム部門の大きさ(小人数)、情報システム化レベル(あまり進んでいない)、経営方針(情報システムを重視しない)という特徴の会社です。「ひとり情シス」という言葉がありますが、ワンオペで情報システムの管理をしているという例もあり、最低限の情報システムを整えることがミッションとなります。 上記の分類には含めていませんが、「(情報システムの利用

情報システム部門の仕事内容

イメージ
  定年退職をして、もう既に5年が過ぎたというのに、きょうも妻が、話していた話題に関連して「ねえ、システムエンジニアをやっていたんでしょう?」と確認するように聞いてきます。妻は会社勤めの経験がなく、聞かれるたびに面倒くさくて「まあ、そんなものかな」と答えていた私も悪いのですが、結婚して40年以上もたつのに、夫の職業を知らないというのはどういうわけでしょうか。たぶん、会社組織に馴染みのない人でも、営業、人事、経理、生産なら仕事内容もうっすらわかると思うのですが、「情報システム部門」というのは、たしかに、わかりにくい職種です。 そこで、きょうは妻にこんな説明をしました。「プログラムも作ったし、システムエンジニアもやったけど、それなりの年になってからはプロジェクトマネジャーもやったし、それとは別に部門の管理もやってたけどね」。ところが、どうも自分でもこの説明に消化不良気味なのです。理由はもっともっといろんなことをしてきたという自負があるからです。そのうえ、妻は、プログラムもシステムエンジニアもプロジェクトマネジャーもその意味は理解できていません。 せめて近親者には理解してもらいたくて、なるべく簡単な表現で「情報システム部門」の説明を考えてみたいと思います。 人事部門は「会社全体のヒトの管理をする」、生産部門/営業部門は「売るための製品であるモノを作って管理し、それを売る」、経理部門は「会社のカネを全体的に管理する」、といえばわかります。つまり経営の3資源である「ヒト・モノ・カネ」に直接かかわる部門です。 じゃあ、「情報システム部門」だから「会社全体の情報(経営の第4資源)を管理する」と言えばいいようなものですが、情報は発生部署/収集部署が責任を持って管理するのが一般的です(企業によって違います)ので、しっくりきません。じゃあ「会社全体のシステムを管理する」ではどうでしょうか。今度は「システムって何?」という質問が返って来ます。 これでどうでしょう。 「社員が仕事を効率的に進めたり、高度な仕事をしたり、顧客満足を追求するためにコンピュータやネットワークを使った仕事のしくみを整える仕事」。 一応、ほとんどの業種の情報システム部門にあてはまると思うのですが如何ですか。 (別の記事で「業種ごとの情報システム部門の位置付け」について書こうと思っています。その記事の後でこの定義の不足