情シス必要論
5.3K Views
May 25, 24
スライド概要
〜情シス不要論に物申す〜 情シス必要論 AWSだからこそ出来る情シス革命
2016/5/18 JAWS-UG大阪で発表した資料です
開発ベンダーに5年、ユーザ企業システム部門通算9年を経て、2018年よりトレノケート株式会社でAWS Authorized InstructorとしてAWSトレーニングコースを担当し、毎年1500名以上に受講いただいている。プロトタイプビルダーとして社内の課題を内製開発による解決もしている。 AWS認定インストラクターアワード2018・2019・2020の3年連続受賞により殿堂入りを果たした。 APN AWS Top Engineers、APN ALL AWS Certifications Engineers、AWS Community Buildersに数年にわたり選出。 個人活動としてヤマムギ名義で執筆、勉強会、ブログ、YouTubeで情報発信している。 その他コミュニティ勉強会やセミナーにて参加、運営、スピーカーや、ご質問ご相談についてアドバイスなどをしている。
関連スライド
各ページのテキスト
~情シス不要論にモノ申す~ 情シス必要論 AWSだからこそ出来る情シス革命 第14回勉強会 「DIY」 〜自社内システムを作る 側からの物申す〜 山下 光洋
自己紹介 山下光洋 @yamamanx Blog : www.yamamanx.com ・ソフトウェア開発会社で IBMさんのBP ・ナイトレジャー会社で情シス ・エネルギー会社で情シス立ち上げ ←今ココ 好きなAWSサービス : RDS JAWS-UG OSAKA , JAWS-UG IoT関西支部 コアメンバー kintoneCafe,TwilioJP-UG,DevLOVE関西,RxTStudyなどに出没してます。 緑のLv14 The八番街 Bass AppleMusic,LINE MUSIC,AmazonMusic,AWA,レコチョク,GooglePlayなどで配信中
毎日呑んでます。 今日ものちほど呑みましょう
PR
モノタロウさんお世話になってます
では本日のアジェンダです ・情シス不要論とは
では本日のアジェンダです ・情シス不要論とは ・情シス必要論
情シス不要論とは ・2013年頃からささやかれている。(もっと前かも) ・システム導入は事業部門が直接やればいい。 ・システム開発を内製するなら事業部門がやればいい。 ・情報システム部門を担当にするメリットはない。 などなど、システムの導入/開発には情報システム部は不要で、 事業部門が直接やればいい、その方が早く確実である。 という論。
情シス不要論とは ・2013年頃からささやかれている。(もっと前かも) ・システム導入は事業部門が直接やればいい。 ・システム開発を内製するなら事業部門がやればいい。 ・情報システム部門を担当にするメリットはない。 などなど、システムの導入/開発には情報システム部は不要で、 事業部門が直接やればいい、その方が早く確実である。 という論。
なぜ情シスは 不要と言われるのか (不要論からの抜粋です)
なぜ情シスは不要と言われるのか(不要論より) 自社ビジネスに貢献できないから ・事業を知ろうとしない ・現場を知ろうとしない 事業部門のIT活用に対して ・「忙しくて対応出来ない」という ・セキュリティ、ガバナンスを盾に断る
なぜ情シスは不要と言われるのか(不要論より) 運用だけで手いっぱいだから 運用にとらわれその運用を改善する事なく ブラックボックス化させる。 そしてさらにその運用から手が離せなくなる。
なぜ情シスは不要と言われるのか(不要論より) 経営層からすると何をしているか見えないから 「どうせ理解されない」、と説明しない。 会社の方向性と合っているかずれていないかも確認しない。 場合によってはやっている事自体が 会社にとって意味があるのかどうかも 経営層から見ると懐疑的となってくる。
なぜ情シスは不要と言われるのか(不要論より) とってつけたROIを掲げるから 根拠の薄い工数改善を時給換算などして数字を報告している。 ただしそれによる会計上の数値は何も変化していない。 偽りの業務改革を続けている。
なぜ情シスは不要と言われるのか(不要論より) 丸投げしかしないから SIerへの丸投げしかしない。 取次だけであれば担当部門としての必要性はない。 提案精査もなければ要件取りまとめもしない。
なぜ情シスは不要と言われるのか(不要論より) 逆に抵抗勢力となっているから クラウドやOSSを事業部門が使いたいと言っても、 自分たちが扱う事が出来ずに理由をつけて抵抗する。 もしくは自分たちの運用業務がなくなる事を恐れる。
なぜ情シスは不要と言われるのか(不要論より) ITを知らないから 昔は知っていたかも知れないが、 外に出なくなり、勉強もしなくなり、自社業務しかしなくなる。 世の中の変化にもついていけず、 事業部門よりもITについての知識が乏しい。
なぜ情シスは不要と言われるのか(不要論より) 開発が出来ないから 開発をやらなくてもいいと本気で思っている。 思いつきの丸投げを「企画」や「設計」と呼んでいる。
なぜ情シスは不要と言われるのか(不要論より) ベンダーに対してBtoBでないから ベンダーからバカにされている事にも気づかずにベンダーコントロー ルとか言っている。 提案は無料で当たり前だと思っている。 発注した後は食べ放題でも頼んだかのように見積もり外の依頼を要 求する。
なぜ情シスは不要と言われるのか(不要論より) すべてが他人事 当事者意識がない。 守っている運用でさえもその手順は引き継いだもので、 何かあっても自分には責任はないと言い張る。 報告をし、承認を受ける事を責任回避と思っている。 高いお金で社外から保証を買う事でしかリスクヘッジが出来ないと 思っている。
なぜ情シスは不要と言われるのか(不要論より) 一体何が出来るのか分からないから 「エンジニアですから」といった顔をして、 コミュニケーションが出来なくてもいいとしている。 そのエンジニアですら疑念されているので、 第3者から見たときに、 もはや何が出来る人なのか分からなくなっている。
突然ですが ・昔はお客様企業の業務要件を満たすためのソフトウェアを開発していました。 お話をする窓口は常に情報システム部ご担当者でした。 情報システム部 ご担当者 情報システム部 情報システム部 ご担当者 ご担当者
こんな事がありました ・とあるソフトウェアを開発して納品しました。 要件は情報システム部ご担当者がまとめたものでした。 そのソフトウェアを利用する部門は情報システム部ではない部門でした。 情報システム部 ご担当者
こんな事がありました ・リリース後、要件から機能が多々不足している事が判明。 情報システム部ご担当者から無償での改修交渉が入るが、 会社としては応える事が出来ず、 使われる事のないソフトウェアをリリースした、 という悔しさしか残らない経験となった。 ・部分的に使って運用 (手作業)でカバー と思ってたけど、 面倒なのでもう使わない ・最低限これが出来ないと運用は無理 情報システム部 ご担当者 利用部門 ご担当者
こんな事がありました ・当時、許されはしませんでしたが、 開発段階で利用部門ご担当者と直接話ができていれば、 少なくとも必要な機能を実装したソフトウェアがリリース出来ていた、かも。 となると、この会社のシステム導入において、 情報システム部ご担当者は不要かも、という事になる。 利用部門 ご担当者
こんな事がありました ・とはいえ、当時のガチガチなウォーターフォールな開発では、 直接話が出来たからといっても機能不足が起こっても致し方ない事もあると思います。 なので不足してしまった機能を、追加で予算をかける事が出来ないのであれば、 リリース後に情報システム部がブラッシュアップすれば良いのでは。 情報システム部 ご担当者 利用部門 ご担当者
そして当時(2009年)は 「利用部門がフォームとビューぐらい作れるようにすればいい」 フィールドなどをドラッグ &ドロップでキャンバスに自 由配置して、フォームをデザインし、そのフォームで 登録したレコードをビューで一覧表示する Webアプリ ケーションを開発したりしました。 今思えば情シス不要というか、ソフトウェアを作る手 段、役割をユーザー部門も担うべきという思いが、当 時の自分にもあったのだと思います。
情シス必要論
情シス必要論 「情シス」が 「必要」ではなく
情シス必要論 「必要」とされる 「情シス」になる
第2のIT部門論もありますが 変わらない既存の情シスは置いといて、 第2のIT部門を作ってデジタルビジネスを 担えば良い、というお話もありますが、 そうではなく、 自らが変わって自社のデジタルビジネスを担う 情シスとなれば良いと思います。 そのために 「必要」とされる「情シス」になる。 これを「情シス必要論」と呼ばせてもらいます。
「必要」とされる「情シス」になる 自社ビジネスに貢献する ・事業を知る ・現場を知る 事業部門のIT活用提案を受け入れ一緒にやってみる。 実現するためにどうすればいいかをとにかく考え実現し、 結果を事業部門とともに振り返る。
「必要」とされる「情シス」になる 事業や現場を知るためには会話も重要ですが、要望に対してプロトタイプを提供して見ても らってフィードバックを得る。それにより潜在的な真実の要望確認につながり、より事業と現 場を知る事が出来ると思います。
「必要」とされる「情シス」になる 運用は自動化する、もしくはアウトソーシングする インフラ運用はクラウドを利用する事で自社の運用負荷を軽減でき る。 ある意味、アウトソーシングであり、それでも残る運用は自動化して、 運用に費やしていた手を空ける。
「必要」とされる「情シス」になる 基本的構成で負荷分散を行っておき、 常時対応するための運用コストをかけ なくても良いようにしておく。
「必要」とされる「情シス」になる もし何かあっても、 自動で復旧出来るようにしておき、 障害が発生しても何もしなくてもいいぐ らいを目指す。
「必要」とされる「情シス」になる 経営層へ何をしているかの見せる化をする 定例MTGでとにかく時間を抑えてもらう。 ホワイトボードや掲示できるように理解してもらい、 進捗ややっている事を社内に貼り出す。
「必要」とされる「情シス」になる 何の優先度を高くしていて、 何が終わって何が終わって ないかを見えるように貼り 出しています。
「必要」とされる「情シス」になる ROIをするなら明確にする。 数値化できないものは無理に数値化しない。 どの科目のどの数値を変える事を目的としているのかを利用部門に 明確に出してもらう。 情シスが数字を作って押し付けない。 なければなくてもかまわないが目的だけは明確にしてもらいそれが達 成できたかを利用部門と共に振り返り、改善する。
「必要」とされる「情シス」になる 丸投げしない 丸投げするならとことん丸投げする。(逆に関与しない) 事業部門とベンダーで直接話をしてもらって、 他のシステムと連携出来るようにAPIだけ確保する。 もしくはデータベースだけは触れるようにしておく。 といった最低限の条件だけ明示するため、契約条件を決定するため の打ち合わせには入り、後は好きにしてもらう。
「必要」とされる「情シス」になる 抵抗勢力とならない 事業部門が自分たちが知らないものでも使いたいと言ったら、 それを調べてもらう。使ってみてもらう。 意見を問われれば言う。 それを使う目的に対して本当に正しいと考える提案はする。
「必要」とされる「情シス」になる ITを知る とにかく勉強する。 自分が知らなくていい事は何もない、ぐらいに思う。 全世界ITエンジニア順位を上げる。 とにかく知っていれば、事業部門は何を使ったらいいと思うか、 という、ところについてまで頼ってきてくれるはず。
「必要」とされる「情シス」になる JAWS-UGだけでなくコミュニティや勉強会で、 知らない事を知る。 そしてそれについてしゃべる、アウトプットする。 トイレや風呂や電車、起きてすぐとかのすきま時間で本 を読む、RSSを読む。
「必要」とされる「情シス」になる 開発をする 自分たちで作るべきもので作れるものは自分たちで作る。 ※作るべきもの = 競争力を向上させるもの = 差別化が必要なもの 環境や使っているツールはやっているとこに聞けばいい。 (DevLOVE勉強会でテーマになる事が多い) 少人数でも足らないものから作っていけばいい。 仕様外だから、予算外だからであきらめない。
「必要」とされる「情シス」になる Lamdaはアプリケーションサーバを構築する必要はなく、コードを書けばすぐに動く。 現在はPython,Java,Node.jsが書ける。 初期費用どころか毎月最初の100万件のリクエストまで無料。 とにかくなにか自動化するというときにやってしまえばいい。
「必要」とされる「情シス」になる もちろんEC2やRDSを使ってOSを構築してその上で開発するのもあり。 EC2はAMIから作れば必要なミドルウェア、ソフトウェアがインストール済のインスタンスが 10分もあれば余裕で稼働させられる。 RDSは誤解を恐れずにいうと、データベースの専門知識がなくても運用出来るデータベー ス。 もちろんAWSの勉強は必要。
「必要」とされる「情シス」になる ベンダーに対してWin-Winである 足らない部分を手伝っていただいている、 助けていただいている事を認識する。 結果、お互いに価値が残るプロジェクトを目指す。 軋轢はよくないが、ちょっと嫌われたぐらいで、 めげない、ぶれない、くさらない。 自分の気持ち一つでなんとかなる事は早めにクリアにしておく。
「必要」とされる「情シス」になる すべてを自分事 稼働しているシステムの他社保証がどうであろうが、 自分が果たすべき責任として稼働させる。 自分たちで作るべきもので作れるものは自分たちで作る。 ※作るべきもの = 競争力を向上させるもの = 差別化が必要なもの
「必要」とされる「情シス」になる 出来る事を明確にし 出来ない事を知り 出来るようにする コードを書ける人が日本語ぐらい話せないはずがない。 あいさつや会話ぐらい出来て当たり前。 それをやらない事で本来の仕事の阻害要因となるぐらいなら、 さっさとやってしまえばいい。 それよりも他に出来ない事があるなら出来るようにする。
「必要」とされる「情シス」になる ・他社ベンダーと比較されて必ず勝つ ・信じられて頼られそれに全力で応える ・面白そうだと思ってわくわくしてもらう ・自分自信が一番仕事を楽しむ
「必要」とされる「情シス」になる lambdaとAPI Gatewayで作ったslack bot
必要とされる情シスとは QuickSight まだプレビュー未公開だがやってみたい。 ユーザー主体のBI
何かはじめようと 思われた方へ
始める際の社内調整/稟議の通し方 ・具体的な反対理由を聞いてそれに回答する 調整はこれに尽きるのではないかと思います。 ・自信を持って報告する。 資料から絶対的な自信がにじみ出るほどに書き込む。 全力で主張するべき。自分のお金じゃないので自分の意思は何もな くて会社が決めたものに従いますよ、のような姿勢だと決裁する側も 不安では？
始めた後の進め方 ・プロトタイプはNo稟議 予算コスト内で会社のために良いと考えた事を実行する事ぐらいの 信用は、仕事をする上で持ちえておくべき。 ・予算 AWSの見積もりツールで最大構成で見積もり。
まとめ
情シス必要論 「必要」とされる 「情シス」になる
そしてその先は ソフトウェア開発の一部が標準スキルとなり、 自分で使うものは自分で開発する時代に。 (クラウドサービス + アドオン開発) ITが特別なものではなくなるので、それこそIT部門とし ては不要になり、ITエンジニアが必要な時代に。 「必要」とされる「ITエンジニア」になる。
きっかけはこの言葉から 「思っている事、 やろうとしている事は、 口に出してまわりに 言った方がいいですよ」
きっかけはこの言葉から 「思っている事、 やろうとしている事は、 口に出してまわりに 言った方がいいですよ。」 株式会社MonotaRo 牛島さん 2015/7/5 Ajile Japan 2015大阪サテライト懇親会にて
参考文献など ・「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/
ご清聴ありがとうございました。 Special Thanx to…..