1.
情シス必要論
～Re:Birth～
2018/9/21
徹底討論！
情シス必要・不要論
~これまでの情シスと明日
からの情シス~
山下 光洋

2.
自己紹介
山下光洋
@yamamanx
Blog : www.yamamanx.com
・ソフトウェア開発会社でIBMさんのBP
・ナイトレジャー会社,エネルギー会社で情シス
・AAI(AWS認定インストラクター)、
IT Terchnical Training Engineer@Trainocate
ヤマムギ(勉強会) , JAWS-UG,
JAWS-UG IoT関西支部, kintone Cafe大阪,
JP_Stripes, MasterCloud
The八番街ベース
緑のLv16 LvLv37

3.
だいたい毎日呑んでます。今日も後ほどお願いしますm(_ _)m。
クラウドプラクティショナーとは
こんなクラウドプラクティショナーはいやだ
ゲットしようぜ！クラウドプラクティショナー

4.
JAWS FESTA 2018
JAWS FESTA 2018
2018.11.03(土) 13:00–18:00

5.
IT人材育成会議
2018.10.24(水) 14:00–17:00
ベルサール新宿グランド

6.
では本日のアジェンダです
・情シス不要論とは
・情シス必要論
・実践結果(+つまづきポイント)
・今思うこと

7.
情シス不要論とは
・2013年頃からささやかれている。(もっと前かも)
・システム導入は事業部門が直接やればいい。
・システム開発を内製するなら事業部門がやればいい。
・情報システム部門を担当にするメリットはない。
などなど、システムの導入/開発には情報システム部は不要で、
事業部門が直接やればいい、その方が早く確実である。
という論。

8.
情シス不要論とは
・2013年頃からささやかれている。(もっと前かも)
・システム導入は事業部門が直接やればいい。
・システム開発を内製するなら事業部門がやればいい。
・情報システム部門を担当にするメリットはない。
などなど、システムの導入/開発には情報システム部は不要で、
事業部門が直接やればいい、その方が早く確実である。
という論。

9.
なぜ情シスが
不要と言われているのか
(不要論からの抜粋です)

10.
なぜ情シスが不要と言われているのか(不要論より)
自社ビジネスに貢献できないから
・事業を知ろうとしない
・現場を知ろうとしない
事業部門のIT活用に対して
・「忙しくて対応出来ない」という
・セキュリティ、ガバナンスを盾に断る
・管理することが成果だと考えている

11.
なぜ情シスが不要と言われているのか(不要論より)
運用だけで手いっぱいだから
運用にとらわれその運用を改善する事なく
ブラックボックス(秘伝のタレ)化させる。
そしてさらにその運用から手が離せなくなる。

12.
なぜ情シスが不要と言われているのか(不要論より)
経営層からすると何をしているか見えないから
「どうせ理解されない」、と説明しない。
会社の方向性と合っているかずれていないか確認をしない。
場合によってはやっている事自体が
会社にとって意味があるのかどうかも
経営層から見ると懐疑的となってくる。

13.
なぜ情シスが不要と言われているのか(不要論より)
とってつけたROIを掲げるから
根拠の薄い工数改善を時給換算などして数字を報告している。
ただしそれによる会計上の数値は何も変化していない。

14.
なぜ情シスが不要と言われているのか(不要論より)
丸投げしかしないから
SIerへの丸投げしかしない。
取次だけであれば担当部門としての必要性はない。
提案精査もなければ要件取りまとめもしない。

15.
なぜ情シスが不要と言われているのか(不要論より)
逆に抵抗勢力となっているから
クラウドやOSSを事業部門が使いたいと言っても、
自分たちが扱う事が出来ずに理由をつけて抵抗する。
もしくは自分たちの運用業務がなくなる事を恐れる。

16.
なぜ情シスが不要と言われているのか(不要論より)
ITを知らないから
昔は知っていたかも知れないが、
外に出なくなり、勉強もしなくなり、自社業務しかしなくなり、
その世界に慣れてしまい危機感がなくなる。
(ゆでガエル現象)
世の中の変化にもついていけず、
事業部門よりもITについての知識が足りないことも。。。。

17.
なぜ情シスが不要と言われているのか(不要論より)
開発が出来ないから
開発をやらなくてもいいと本気で思っている。
思いつきの丸投げを「企画」や「設計」と呼んでいる。

18.
なぜ情シスが不要と言われているのか(不要論より)
ベンダーに対してBtoBでないから
ベンダーコントロールとか言っている。
提案は無料で当たり前だと思っている。
発注した後は食べ放題でも頼んだかのように見積もり外の依頼
を要求する。

19.
なぜ情シスが不要と言われているのか(不要論より)
すべてが他人事
当事者意識がない。
守っている運用でさえもその手順は引き継いだもので、
何かあっても自分には責任はないと言い張る。
報告をし、承認を受ける事を責任回避と思っている。
高いコストをかけ社外から保証を買う事でしかリスクヘッジが
出来ないと思っている。

20.
なぜ情シスが不要と言われているのか(不要論より)
一体何が出来るのか分からないから
人事部門の問題ともとれますが、
社内全般にITスキルが不足しているため、
情報システム部員のスキルを測ることが誰もできない。
新しいシステムやサービスの構築/開発もないので、
具体的に何が出来るのかが誰も分からない。

21.
突然ですが
・昔はお客様企業の業務要件を満たすためのソフトウェアを開発していました。
お話をする窓口は常に情報システム部ご担当者でした。
情報システム部
ご担当者
情報システム部
ご担当者
情報システム部
ご担当者

22.
こんな事がありました
・とあるソフトウェアを開発して納品しました。
要件は情報システム部ご担当者がまとめたものでした。
そのソフトウェアを利用する部門は情報システム部ではない部門でした。
情報システム部
ご担当者

23.
こんな事がありました
・リリース後、要件から機能が多々不足している事が判明。
情報システム部ご担当者から無償での改修交渉が入るが、
会社としては応える事が出来ず、
使われる事のないソフトウェアをリリースした、
という悔しさしか残らない経験となった。
情報システム部
ご担当者
利用部門
ご担当者

24.
こんな事がありました
・当時、許されはしませんでしたが、
開発段階で利用部門ご担当者と直接話ができていれば、
少なくとも必要な機能を実装したソフトウェアがリリース出来ていた、かも。
となると、この会社のシステム導入において、
情報システム部ご担当者は不要かも、という事になる。
利用部門
ご担当者

25.
こんな事がありました
・とはいえ、当時のガチガチなウォーターフォールな開発では、
直接話が出来たからといっても機能不足が起こっても致し方ない事もあると思います。
なので不足してしまった機能を、追加で予算をかける事が出来ないのであれば、
リリース後に情報システム部がブラッシュアップすれば良いのでは。
情報システム部
ご担当者
利用部門
ご担当者

26.
そして当時(2009年)は
「利用部門がフォームとビューぐらい作れるようにすればいい」
フィールドなどをドラッグ&ドロップでキャンバ
スに自由配置して、フォームをデザインし、その
フォームで登録したレコードをビューで一覧表示
するWebアプリケーションを開発したりしました。
今思えば情シス不要というか、ソフトウェアを作
る手段、役割をユーザー部門も担うべきという思
いが、当時の自分にもあったのだと思います。

27.
情シス必要論

28.
情シス必要論
「情シス」が
「必要」ではなく

29.
情シス必要論
「必要」とされる
「情シス」になる

30.
第2のIT部門論もありますが
変わらない既存の情シスは置いといて、
第2のIT部門を作ってデジタルビジネスを
担えば良い、というお話もありますが、
そうではなく、
自らが変わって自社のデジタルビジネスを担う
情シスというか「1エンジニア」になれば良いと思います。
そのために
「必要」とされる「情シス」になる。
これを「情シス必要論」と呼ばせてもらいます。

31.
「必要」とされる「情シス」になる
自社ビジネスに貢献する
・事業を知る
・現場を知る
事業部門のIT活用提案を受け入れ一緒にやってみる。
実現するためにどうすればいいかをとにかく考え実現し、
結果を事業部門とともに振り返る。

32.
「必要」とされる「情シス」になる
事業や現場を知るためには会話も重要ですが、要望に対してプロトタイプを提供して
見てもらってフィードバックを得る。それにより潜在的な真実の要望確認につながり、
より事業と現場を知る事が出来ると思います。

33.
「必要」とされる「情シス」になる
運用は自動化する、もしくはアウトソーシングする
インフラ運用はクラウドを利用する事で自社の運用負荷を軽減
できる。
ある意味、アウトソーシングであり、それでも残る運用は自動
化して、運用に費やしていた手を空ける。

34.
「必要」とされる「情シス」になる
基本的構成で負荷分散を行ってお
き、
常時対応するための運用コストを
かけなくても良いようにしておく。

35.
「必要」とされる「情シス」になる
もし何かあっても、
自動で復旧出来るようにしておき、
障害が発生しても何もしなくても
いいぐらいを目指す。

36.
「必要」とされる「情シス」になる
何をしているかの見せる化をする
定例MTGでとにかく時間を抑えてもらう。
ホワイトボードや掲示できるように理解してもらい、
進捗ややっている事を社内に貼り出す。
何のために何をしていて何が終わって何がまだか、
優先度、方向がずれていないかを「見せる化」する

37.
「必要」とされる「情シス」になる
ROIをするなら明確にする。
数値化できないものは無理に数値化しない。
どの科目のどの数値を変える事を目的としているのかを利用部
門に明確に出してもらう。
情シスが数字を作って押し付けない。
なければなくてもかまわないが目的だけは明確にしてもらいそ
れが達成できたかを利用部門と共に振り返り、改善する。

38.
「必要」とされる「情シス」になる
丸投げするならとことん丸投げする
逆に関与しない。
事業部門とベンダーで直接話をしてもらって、
他のシステムと連携出来るようにAPIだけ確保する。
もしくはデータベースだけは触れるようにしておく。
といった最低限の条件だけ明示するため、契約条件を決定する
ための打ち合わせには入り、後は好きにしてもらう。

39.
「必要」とされる「情シス」になる
抵抗勢力とならない
事業部門が自分たちが知らないものでも使いたいと言ったら、
それを調べてもらう。使ってみてもらう。
意見を問われれば言う。
それを使う目的に対して本当に正しいと考える提案はする。

40.
「必要」とされる「情シス」になる
ITを知る
とにかく勉強する。
自分が知らなくていい事は何もない、ぐらいに思う。
とにかく知っていれば、
事業部門は何を使ったらいいと思うか、
というところについてまで頼ってきてくれるはず。

41.
「必要」とされる「情シス」になる
コミュニティや勉強会で、知らない事を知る。
そしてそれについてしゃべる、アウトプットする。
トイレや風呂や電車、起きてすぐとかのすきま時間
で本を読む、RSSを読む。

42.
「必要」とされる「情シス」になる
開発をする
自分たちで作るべきもので作れるものは自分たちで作る。
※作るべきもの = 競争力を向上させるもの = 差別化が必要なもの
環境や使っているツールはやっているとこに聞けばいい。
(勉強会でテーマになる事が多い)
少人数でも足らないものから作っていけばいい。
仕様外だから、予算外だからであきらめない。

43.
「必要」とされる「情シス」になる
Lamdaはアプリケーションサーバを構築する必要はなく、コードを書けばすぐに動く。
現在はPython,Java,Node.jsが書ける。
初期費用どころか毎月最初の100万件のリクエストまで無料。
とにかくなにか自動化するというときにやってしまえばいい。

44.
「必要」とされる「情シス」になる
もちろんEC2やRDSを使ってOSを構築してその上で開発するのもあり。
EC2はAMIから作れば必要なミドルウェア、ソフトウェアがインストール済のインス
タンスが
10分もあれば余裕で稼働させられる。
RDSは誤解を恐れずにいうと、データベースの専門知識がなくても運用出来るデータ
ベース。
もちろんAWSの勉強は必要。

45.
「必要」とされる「情シス」になる
ベンダーに対してWin-Winである
足らない部分を手伝っていただいている、
助けていただいている事を認識する。
結果、お互いに価値が残るプロジェクトを目指す。

46.
「必要」とされる「情シス」になる
すべてを自分事
稼働しているシステムの他社保証がどうであろうが、
自分が果たすべき責任として稼働させる。
自分たちで作るべきもので作れるものは自分たちで作る。
※作るべきもの = 競争力を向上させるもの = 差別化が必要なも
の

47.
「必要」とされる「情シス」になる
出来る事を明確にし
出来ない事を知り
出来るようにする
出来るようにならなければならない事は、
山程ある。

48.
「必要」とされる「情シス」になる
・他社ベンダーと比較されて必ず勝つ
・信じられて頼られそれに全力で応える
・面白そうだと思ってわくわくしてもらう
・自分自身が一番仕事を楽しむ

49.
実践結果
(+つまづきポイント)

50.
実践結果
自社ビジネスに貢献する
事業、現場を知る
・雑談でもいいのでとにかく相談を受け付けた
・「出来ない」と言わない
・「出来る」ために何が必要かを考え、会話した
・業務を可能な限りまきとった
・動くものを提示してそのまま使ってもらった
・事業部門から情シスに異動してもらった

51.
実践結果
自社ビジネスに貢献する
事業、現場を知る
・雑談でもいいのでとにかく相談を受け付けた
・「出来ない」と言わない
・「出来る」ために何が必要かを考え、会話した
・業務を可能な限りまきとった
・動くものを提示してそのまま使ってもらった
・事業部門から情シスに異動してもらった
現場の意識に変化

52.
実践結果
Before
・「出来ない」と言われたから
手作業でしている。
・直接言うと上司を通してと言
われて上司に言うと報告書を作
るように言われてそんな時間は
ないので出来なかった。
・とりあえず自分たちでなんと
かするしかない。
・人の目が一番正確だ。
After
・相談すればなんとかしてくれ
る。
・とりあえず相談してみる。
・システムに頼ってみる
・一度作ったら終わりではない
からバグや課題があれば一緒に
改善を考える

53.
実践結果
Before
・「出来ない」と言われたから
手作業でしている。
・直接言うと上司を通してと言
われて上司に言うと報告書を作
るように言われてそんな時間は
ないので出来なかった。
・とりあえず自分たちでなんと
かするしかない。
・人の目が一番正確だ。
After
・相談すればなんとかしてくれ
る。
・とりあえず相談してみる。
・システムに頼ってみる
・一度作ったら終わりではない
からバグや課題があれば一緒に
改善を考える
(一部の変化)
一方では、
忙しくなりすぎて
→やるやる詐欺化

54.
実践結果
運用の自動化、クラウドアウトソーシング
・画面からデータを読み込んでデータベース化
・データベース間の連携
・個人情報の名寄せ
・メール報告(SendGridAPI)
・DM送信(SendGridAPI)
・イレギュラーのパラメータ化
・祝日の自動取得(GoogleCalendarAPI)
・サーバーの自動停止/起動などなど

55.
実践結果
運用の自動化、クラウドアウトソーシング
・画面からデータを読み込んでデータベース化
・データベース間の連携
・個人情報の名寄せ
・メール報告(SendGridAPI)
・DM送信(SendGridAPI)
・イレギュラーのパラメータ化
・祝日の自動取得(GoogleCalendarAPI)
・サーバーの自動停止/起動などなど
運用負荷の軽減
作業の信頼性向上

56.
実践結果
Before
・現場が手作業で行っている。
・サーバーの停止忘れによる予
算外の課金。
・手作業で行ったものは作業前
に承認を経て、手動での確認し
確認完了の承認。
After
・情シスでまきとって自動化。
・現場の操作を軽減(クリック数
を減らす)自動化。
・サーバー停止を自動化。
・結果のチェックを自動化。

57.
実践結果
Before
・現場が手作業で行っている。
・サーバーの停止忘れによる予
算外の課金。
・手作業で行ったものは作業前
に承認を経て、手動での確認し
確認完了の承認。
After
・情シスでまきとって自動化。
・現場の操作を軽減(クリック数
を減らす)自動化。
・サーバー停止を自動化。
・結果のチェックを自動化。
コストをかけずに
行ったため
基本内製開発
→属スキル化

58.
何をしているかの見せる化をする
・自分たちの今やるべきことは「自動化」と伝える
・何が終わって何がまだか何をするか貼り出す
・バズワードはバズワードになる前に抑える
・ITコスト一覧表を囲んで議論する
実践結果

59.
何をしているかの見せる化をする
・自分たちの今やるべきことは「自動化」と伝える
・何が終わって何がまだか何をするか貼り出す
・バズワードはバズワードになる前に抑える
・ITコスト一覧表を囲んで議論する
実践結果
見えにくかったところ
を見えるようにする

60.
実践結果
Before
・何をしているか見えない
・何にいくらかかっているか見
えない
After
・何をしているか見える
・コスト削減対象を決める
・目標コストを決める

61.
ROIをするなら明確にする
・改善の敷居を下げる
以前はハードコーディングされた定数一つ触るだけで、
100万の見積もりだったので、いわゆるシステム人質状態。
これを内製で行うことで1日あれば出来てしまう、
社内経費数万円にしてしまう。
あとはその価値に見合う改善かどうかを
部門に精査してもらう。
(工数だけで考えると愚かな判断になることが多い)
→人の手を介さないリアルタイムな処理の価値。
実践結果

62.
ROIをするなら明確にする
・改善の敷居を下げる
以前はハードコーディングされた定数一つ触るだけで、
100万の見積もりだったので、いわゆるシステム人質状態。
これを内製で行うことで1日あれば出来てしまう、
社内経費数万円にしてしまう。
あとはその価値に見合う改善かどうかを
部門に精査してもらう。
(工数だけで考えると愚かな判断になることが多い)
→人の手を介さないリアルタイムな処理の価値。
実践結果
現場のアジリティを
向上して成果を
見えやすく

63.
「必要」とされる「情シス」になる
フィールドを配置して簡単にフォーム作成
(事業部門が作れる)

64.
「必要」とされる「情シス」になる
・スタンダードコース : 1,500/User/月
無料お試し期間に自由に試してもらう
社内外勉強会を18回開催
社内向け勉強会→クローズドで具体的な使い方を提示
社外向け勉強会→オープンで他社参加者、登壇者と意見交換
し、社外の使い方と刺激を提示
使い方はユーザーが考え、そして作る コーディングや外部連携は情シスが担当
使いたい人だけアカウントを発行
使う必要がない、使っても改善できない人は無駄なのでアカ
ウントを作らない(強制しない)

65.
「必要」とされる「情シス」になる
・スタンダードコース : 1,500/User/月
無料お試し期間に自由に試してもらう
社内外勉強会を18回開催
社内向け勉強会→クローズドで具体的な使い方を提示
社外向け勉強会→オープンで他社参加者、登壇者と意見交換
し、社外の使い方と刺激を提示
使い方はユーザーが考え、そして作る コーディングや外部連携は情シスが担当
使いたい人だけアカウントを発行
使う必要がない、使っても改善できない人は無駄なのでアカ
ウントを作らない(強制しない)
残業1時間減らすだけ

66.
実践結果
Before
・情シスが決めて事業部門に押
し付けるROI
・使えば使うほど効率が落ちる
システムの利用率？？？
After
・事業部門は使うことでのROI
・情シスは実現するためのROI
・価値は使う人が一番わかる
・何が課題でどうすれば解決で
きるかは担当者が一番知ってい
る

67.
実践結果
Before
・情シスが決めて事業部門に押
し付けるROI
・使えば使うほど効率が落ちる
システムの利用率？？？
After
・事業部門は使うことでのROI
・情シスは実現するためのROI
・価値は使う人が一番わかる
いろんなものが
ついてこない
→先走り

68.
抵抗勢力とならない
・自分が使いたい、使いたくない、で選ばない
・事業部門が使いたいのならそれを使ってもらう
・アドバイスを求められれば選択肢は提供する
・社内普及に協力する
実践結果

69.
抵抗勢力とならない
・自分が使いたい、使いたくない、で選ばない
・事業部門が使いたいのならそれを使ってもらう
・アドバイスを求められれば選択肢は提供する
・社内普及に協力する
実践結果
シャドーITの知ってる化

70.
実践結果
Before
・特定部門が使うシステムを情
シスが上申して稟議を通す
・特定部門はその部門の意思関
係なくシステムを使わされる
・いやいや使いながら自分たち
で使いやすいシステムを勝手に
使う
・シャドーIT化
After
・自分たちが使うシステムを自
分たちで上申して稟議を通す
・自分たちで選択したのでとに
かく使う
・情シスは何を使っているのか
知っている

71.
ITを知る
・時間があれば勉強会に行く。
・知ったことを会社で試す。
・試したことをアウトプットする。
・毎日1,000件近くのRSSフィードを浴びる。
実践結果

72.
ITを知る
・時間があれば勉強会に行く。
・知ったことを会社で試す。
・試したことをアウトプットする。
・毎日1,000件近くのRSSフィードを浴びる。
実践結果
個人の評価(特に社外)UP

73.
今思うこと

74.
そもそもの原因は自分に
・「定時内は本番」
・「練習(勉強)は時間外」
・「自己選択式」
・「自己投資」
・自立、自主性の押し付け

75.
「失敗して学ぼう」
学びたいと思わないと
誰も失敗したくない。

76.
「知識よりも知恵が大切」
でもその知恵には、
知識の選択肢が必要。

77.
今思うと
・支援が必要
・自立した独学でも偏る
・ベースラインをあわせる
Best Practice
Well-Architected

78.
・やるやる詐欺
・属スキル化
・非協力
・先走り
・大炎上
つまづきポイントへの解決策

79.
・やるやる詐欺 →エンジニア育成
・属スキル化 →エンジニア育成
・非協力 →CIO
・先走り →CIO,エンジニア
・大炎上 →内製→CIO,エンジニア
つまづきポイントへの解決策

80.
なぜ内製がいいか
企業知識に長けていて
各部門との信頼関係があり
既存システムの運用を知り尽くし
社内のデータへの有識度が高く
理念、事業への想いのある人が
作ったサービスと、そのエンジンが
他社に負けるはずがない。

81.
どうやって内製化するか
■ 情報システム部門の役割を変える

82.
どうやって内製化するか
■ 情報システム部門の役割を変えるサービス開発

83.
自己紹介も兼ねてクラウドと自分のなれそめを
企業向け業務ソフトウェア開発 情シス 情シス
AA
I
経歴

84.
ここ数年
サービス開発

85.
ここ数年
サービス開発

86.
ここ数年
サービス開発

87.
ここ数年

88.
自分を変えたアドバイス
「思っている事、
やろうとしている事は、
口に出してまわりに
言った方がいいですよ。」

89.
自分を変えたアドバイス
心の方向指示器

90.
思っていることは言ったほうがいい
・言うだけはタダ
・「出来ない」と決めつけた時点でそれは出来ない
・何がしたいか、なぜしたいか、
ちゃんと話せば人は聞いてくれる
・無言実行もいいけど、
言っておいたほうが協力を得られる、
信頼感も生まれる、
(そして自分も追い込める)

91.
まとめ
・アーキテクチャは組織に従う(コンウェイの法則)
・だから組織を変えなければ歪が生じる
・個人で出来ることは限界が近くにある
・でも個人から始める分かりやすい実績は効果大
・昨日の非常識は明日の常識
・今日生まれた技術がスタンダードになる

92.
参考文献など
・「SEは死滅する」 / 木村岳史 著
・Team Geek / Brian W. Fitzpatrick,Ben Collins-Sussman 著,角 征典 訳
・ITpro 「極限暴論」
http://itpro.nikkeibp.co.jp/search/index.html?q=極言暴論
・ITmedia 「情シス”ニュータイプ”の時代」
http://www.itmedia.co.jp/keywords/ntp_gen.html
・ZDNet Japan 「IT部門はどこへ向かうのか」
http://japan.zdnet.com/cio/sp_15uchiyama/
・logmi クラウドファーストは、常識やんね(と東急ハンズは思ってます)
http://logmi.jp/series/クラウドファーストは、常識やんね（と東急ハン
・SlideShare MonotaROとIT -いまとこれから-
http://www.slideshare.net/monotaro-itd-pr/monotaroit-20150320-devlove
・「システム内製化の罠」 / 大石蔵人之助の「雲をつかむような話」
http://blog.serverworks.co.jp/ceo/

93.
まとめ
人間の歴史の中で、
何かを始めるのに
今ほど最高のときはない。
今こそが、未来の人々が振り返って、
「あの時に生きて戻れれば」
という時なのだ。
まだ遅くはない。

94.
JAWS FESTA 2018
JAWS FESTA 2018
2018.11.03(土) 13:00–18:00

95.
ご清聴ありがとうございました。
Special Thanx to…..