Comments
Description
Transcript
IT - QCon Tokyo
豆蔵 技術顧問 寺嶋 一郎 私の略歴 １９７９ 積水化学 生産技術部 FA（マイコンによる制御） 生産管理 １９８６ 特別研修制度にてＭ．Ｉ．Ｔ．へ留学 人工知能の研究 １９８８ 情報子会社ＩＳＡＣへ出向 主に住宅のシステム化を推進 ２０００ 積水化学 情報システム部長 全社IT統括、基盤・共通システム刷新、グループITガバナンス ２０１６ 定年退職 積水化学グループについて 積水化学工業株式会社（SEKISUI CHEMICAL CO.,LTD.） 1947年3月3日 1,000億円 代表取締役社長 根岸 修史 23,886名（2015年3月期連結ベース） 11,127憶円（2015年3月期連結ベース） 879億円（2015年3月期連結ベース） 大阪本社 〒530-8565 大阪市北区西天満2丁目4番4号 06-6365-4122 東京本社 〒105-8450 東京都港区虎ノ門2丁目3番17号 03-5521-0521 http://www.sekisui.co.jp/ 【積水化学グループの事業展開：売上構成 】 4,941億円 405億円 2,276億円 3,722億円 ※2015年3月期連結ベース セキスイハイム(ユニット住宅）ができるまで 生産依頼図 完成 HAPPS /TAPPS 工場生産体制 据付け（組み立て） 生産技術部、MIT留学時代 8ビットマイコンを活用し、ノイズ耐性の強い制御システムを内作 ハードからソフトまで手作りで、すべてがわかる 独自のリアルタイムOSを搭載した、ダイレクト制御 独自プロトコルでのマイコン間通信 群管理、生産管理（新工場のシステム）への取り組み ハードとソフトの基本原理を知り、コンピュータに魅せられる！ MITに留学、コンピュータサイエンスを学ぶ 偶然積水化学が人工知能ビジネスに参画することとなりAIを勉強 無限の可能性を秘めたソフトウェア開発の魅力を実感 ～ ソフト開発はわくわくして楽しむもの ～ IT子会社時代（ISAC) -1 人工知能をビジネスにできないかと作った会社→ISAC 独自のProlog（論理型言語）を開発したベンチャー企業を買収 まずは積水の（主に住宅）の事業で人工知能技術を活用 最大のテーマはユニット住宅の部品展開 外部仕様を書けないのでベンダーに発注出来ず！ MIT時代に勉強したオブジェクト指向技術を活用 内製でシステム開発 → 大量受注を可能に、新製品上梓に無くてはならないシステムへ ユーザ部門と連携、問題の本質を深く知り、それを解決する わかりやすいイノベーションがあれば業務改革は成功する！ IT子会社時代（ISAC) - 2 住宅の開発支援システムの開発を支援 PDM、PLMのような仕組み（その頃はPDMという概念なし） 大手ベンダーに委託 大きなコスト、多人数での開発 導入後もトラブり、ベンダーロックイン状況に 数年後、その仕組をUNIXからPCへマイグレーション 再度、スクラッチから開発、少数精鋭での開発 仕様は決まっていたが、それにしても工数は１桁以下、品質も良い システムのコスト・パフォーマンスは開発のやり方で桁違い！ アーキテクチャを重要視し、少数精鋭の開発チームが理想 本社・情報システム部を任されて → 現在まで IT革命が叫ばれた２０００年に情報システム部長に就任３名でスタート それまではIT子会社（SSC)社長が情報システム部長を兼任 まずはIT部門の構造改革 評判の悪いIT子会社とITに対するアレルギー 当時不況でもあり、IT子会社の売却を経営企画が考えていた・・・ 積水化学のＩＴ部門の再編（２００４年～） 業務を知りかつITを知った開発・運用ができる強い新会社を目指す 積水化学のＩＴ部門は経営・事業に密着した企画に専念 戦略的アライアンスの目的 新・情報子会社の基本戦略 3社の事業提携による「Win-Win-Win」の実現 積水化学工業 事業競争力強化・ｸﾞﾛｰﾊﾞﾙ化 をＩＴでさらに加速 ＮＴＴデータ 新たな領域での 法人分野の事業拡大 • アライアンス(資本提携)により • 事業拡大と体質強化のスピードアップを図り • 早期自立化に向けた成長路線に乗せる １．内販新規分野の開拓 ２．外販比率２０%超への挑戦 ３．企業体質の強化(人材、技術、管理) SSC ＩＳＡＣ セキスイシステムセンター、アイザック 本格的なＩＴサービス企業への成長・発展 積水化学としての課題 アウトソーシングの管理 人材育成 今後、IT子会社のあり方はいかに！？ 本社・情報システム部を任されて → 現在まで IT革命が叫ばれた２０００年に情報システム部長に就任３名でスタート それまではIT子会社（SSC)社長が情報システム部長を兼任 まずはIT部門の構造改革 評判の悪いIT子会社とITに対するアレルギー 当時不況でもあり、IT子会社の売却を経営企画が考えていた・・・ さらに、並行してやらなければと思った２つのテーマ イントラ革新 ： インターネットが脚光を浴び、Web技術が普及 ERP理念の実現 ： 当時、ERPの導入がスタート コーポレートIT部門として追い続けた２つの主なテーマ ① イントラ革新 － イントラネット活用したグループでの情報共有の推進 グループの理念や方針の共有 将来の知識経営に向けた基盤整備 → 自社開発のメール・グループウェアをグループ全社に導入 Smile (際立つ知識経営基盤）の構築経緯 WEBメール機能強化とBCP対応 2013 Smileの狙い AWS移行による機能強化とBCP(DR)対応 間接業務の削減・効率化 （標準化） ナレッジマネージメント （理念伝達・風土改革・知識開拓） グローバル情報共有 （単一ドメイン・Know-Who管理） IaaS移行で生産性の無いハード更新から脱却 グローバル対応と単一ドメイン化 2008,2012 社員証システムグローバル対応や iSmileによるインターネットダイレクトアクセス Smile(イントラネット) 2004 グループ全体への情報発信源とし、 グループ経営の礎となる基幹システムへの入り口 Smile(メール) 2004 Smile(グループウェア) 2005 ビジネスに欠かせないセキュアーなメールシステム ※容量拡大（ギガメール対応）で更に活用促進 SmileNET 2005 会議室・文書管理・スケジュール等全ての 間接業務の効率化とコミュニケーションを支援 セキュリティ(監査含む) 2005 高速・2重化・低価格なネットワークとして 国内積水グループ全社へ展開 (電子)社員証情報 （約23,000人） 個人情報・機密情報保護を推進 ウィルスゼロへ！ Smileの主な機能 ポータルサイト 電子メール スケジュール(自分・他のSmileユーザのスケジュール) コンテンツブラウズ・購読リスト(コンテンツを探す・購読する) 掲示板・会議室(連絡・案内・ディスカッション) 施設予約(会議室・設備 利用予約) 行事予定(会社・部所・グループ単位のスケジュール) 文書管理(ファイル管理・共有) マイフォルダ(個人用ファイルスペース) CMS以外は全てOSS ブックマーク(Smileオンラインブックマーク) 内作 TODOリスト(作業管理) 開発言語はPearl 来客対応(来客スケジュール) SmileWEB会議(オンラインWEB会議) 確認依頼(記事・文書の確認依頼) ワークフロー(利用グループ設定) 携帯版Smile(スケジュール・施設予約・メール転送設定ON/OFF) 回覧 電子メール一斉送信 アジャイル開発＆DevOpsの実践 コーポレートIT部門として追い続けた２つの主なテーマ ① イントラ革新 － イントラネット活用したグループでの情報共有の推進 グループの理念や方針の共有 将来の知識経営に向けた基盤整備 → 自社開発のメール・グループウェアをグループ全社に導入 ② ERPの理念の実現 － グループ全社への共通基幹システムの導入 － 経営の見える化、経営の意思決定支援 業務改革、業務標準化 → 会計／デリバリーの共通システムをグループ全社に導入 【以前の基幹システムの姿】 １９９５年 基幹業務はメインフレームにて処理 グループウェアはパソコン通信方式 メインフレーム中心 FAX,TEL 代理店 営 業 所 FAX,TEL 大手 顧客 ＶＡＮ 会計端末制御 デリバリ センターサーバ ホスト デリバリ マスター ホスト デリバリ 通信機能 ホスト 販売管理 デリバリ 会計 ホスト 人事・給与 デリバリ ホスト グループウェア（パソコン通信方式） AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 生産・物流 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 【会計システムの再構築】 １９９９年 ・会計機能をオープン化 ・連結会計システムのパッケージ導入 ・グループウェアの運用外部委託 連結会計システム パ 会計システム 会計システム 会計 （業務系） （情報系） FAX,TEL 代理店 FAX,TEL 大手 顧客 ＶＡＮ 営 業 所 デリバリ ＤＷＨ センターサーバ ホスト デリバリ マスター ホスト デリバリ 通信機能 ホスト 販売管理 デリバリ ホスト 人事・給与 デリバリ ホスト パ グループウェア（外部委託） AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 生産・物流 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 【販売管理システム再構築】 ２００３年 ・販売管理能をインターネット技術でオープン化 ・電子メールをオープンソースで構築開始 連結会計システム パ 会計システム 会計システム 会計 （業務系） （情報系） 代理店 FAX,TEL 営 業 所 代理店 販売システム （Ｗｅｂ型） センターサーバ マスター 販売管理 通信機能 Internet 大手 顧客 人事・給与 グループウェア（外部委託） パ AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 生産・物流 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 【人事・給与システム再構築】 ２００６年 ・給与計算をパッケージ化、工場システムのホスト統合 ・グループ社員管理をグループウェア上に構築 連結会計システム パ 会計システム 会計システム 会計 （業務系） （情報系） 代理店 FAX,TEL 営 業 所 代理店 販売システム （Ｗｅｂ型） センターサーバ マスター 販売管理 通信機能 Internet 大手 顧客 グループウェア（オープンソース化） 人事 給与システム 人事システム 給与 パ 統合AS400 統合AS400 生産・物流 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 AS400 【汎用機の撤廃】 ２００７年 ・メインフレーム全廃 ・工場システムのホスト統合 連結会計システム パ 会計システム 会計システム 会計 （業務系） （情報系） 代理店 FAX,TEL 営 業 所 代理店 ＤＷＨ 販売システム（Ｗｅｂ型） マスター 販売管理 通信機能 Internet 大手 顧客 統合AS400 統合AS400 生産・物流 統合AS400 グループウェア（オープンソース化） 人事 給与システム 人事システム 給与 パ AS400 AS400 AS400 AS400 【基幹システムの革新】 ２００８年 グループウェアとＢＩツールの連動による柔軟な『見える化』実現 基幹システム革新による新たな付加価値の追求 連結会計システム パ 会計システム 会計システム 会計 （業務系） 代理店 FAX,TEL 営 業 所 代理店 （情報系） ＤＷＨ 統合AS400 販売システム（Ｗｅｂ型） マスター 販売管理 通信機能 Internet 統合AS400 生産・物流 統合AS400 大手 顧客 『見える化』 AS400 AS400 AS400 AS400 グループウェア（オープンソース化） ERPを使わずに使いやすい基幹システムをスクラッチ開発 人事 人事システム 給与システム 給与 パ 本社・情報システム部を任されて → 現在まで IT革命が叫ばれた２０００年に情報システム部長に就任３名でスタート それまではIT子会社（SSC)社長が情報システム部長を兼任 まずはIT部門の構造改革 評判の悪いIT子会社とITに対するアレルギー 当時不況でもあり、IT子会社の売却を経営企画が考えていた・・・ さらに、並行してやらなければと思った２つのテーマ イントラ革新 ： インターネットが脚光を浴び、Web技術が普及 ERP理念の実現 ： 続々とERPパッケージを導入する日本企業 標準化の推進、グローバル対応、クラウド化 等々 ２０１６年３月 定年退職 「私がやってきたこと、そこから学んだこと」ITLeaders連載中！ 【第1回】 【第2回】 【第3回】 【第4回】 【第5回】 【第6回】 【第7回】 【第8回】 【第9回】 積水化学入社、ITの醍醐味を手を動かして知る MITに留学、しんどいことこそリターンも大きい 人工知能ビジネスを目指したIT子会社～そこで住宅事業の難題に挑戦 IT子会社で様々なシステムを開発しながら学んだこと 情報システム部長に就任、四面楚歌の中でIT部門の構造改革を断行 なぜ積水化学では電子メールからグループウェアまで内製したのか 「見える化」を主体としたセキュリティ対策の推進とその効果 オープン化による基幹システム刷新の経緯と成果 全社ICT標準化の推進と成果、そしてITスタッフの頑張りについて思うこと 日本企業のIT部門を強くするためのお手伝い ＜やりたいこと＞ 企業経営におけるITへの期待は、「省力化・効率化」から「いかに顧客の潜在・健 在ニーズに応えて、ビジネスそのものを変えていけるか」といった領域へシフトする 中、ベンダーに丸投げし、予算管理しかしてない手配師のようなIT部門から脱却 し、経営視点を持ち、ビジネス部門から信頼される強いIT部門に変わっていくた めの支援を行いたい。 ＜活動＞ TERRANET 代表 豆蔵 技術顧問 ソラコム 顧問 ビジネスシステムイニシアティブ協会 副理事 PC・ネットワークの管理・活用を考える会（PCNW) 幹事長 IIBA日本支部 代表理事（予定） デジタル化とは？ VUCAワールド 同時多発の新技術の出現 Volatility – 変動性 Uncertainty – 不確実性 Complexity – 複雑性 Ambiguity – 曖昧性 クラウド AI・機械学習 ビッグデータ ３Dプリンタ ロボット ドローン ただのバズワードではない！ 今、デジタルの世界で何がおきているのか クラウド IoT アイディア ソフトウェアが ソフトウェア ビジネスそのもの になる！ AI・機械学習 ビッグデータ Software eat the world! ソフトウェアこそが重要なことに気づく時が来た！ デジタル時代はクラウドネイティブな「ソフトウェア」がビジネスのコア Uber、Airbnbなどのビジネスは「ソフトウェア」そのもの しのぎを削る自動運転はソフトウェアが勝負！ 新たな「ソフトウェア」は内製が当たり前 アジャイル、DevOps等の新たなスタイルでの開発 優秀なソフト技術者をどう集めるかが勝負 「アイディア」と「ソフトウェア」が世界を変える！ デジタル時代こそIT部門が浮上するチャンス！ それなのにIT部門の劣化が進んでいる？ ベンダーに丸投げ状態のIT部門 企画までベンダーに提案を求める 技術は社員でなくベンダーからの常駐社員が担っている モチベーションが上がらず、閉じこもりがちになるIT部門 大半が保守・運用の仕事 現場に行きたがらない 人材がタコツボ化 業務部門とのローテーションが進まない 他部門からIT部門に来てもなかなか仕事になじめない 様々な課題を抱える悩めるIT部門 日本企業のIT部門の課題 Ⅰ システムの導入でイニシアティブがとれない・・・・ Ⅱ 経営層、他部門で認められず地位が低い Ⅲ ITを取り巻く環境の変化への対応に苦慮 Ⅱ、Ⅲ、Ⅰの順で考えていきます・・・ Ⅱ 経営層、他部門で認められず地位が低い 日本の経営者はITが嫌い？ IT人材の育成に苦慮 経営に向かって、工夫して、 ITはわからないといって自慢？するトップは日本だけ わかりやすくITを語れ！ お金はかかるし、トラブルがあればその責任を問われるのでITには関わりたくない 大幅な費用増やトラブル等で、なにか失敗しないと経営の注目を浴びない・・・ 目指すべきIT部門の姿を描き、 ユーザー企業にITをやりたいとして入社する人はいない・・・ それに向けての人材育成を 専門家として尊敬されず（ただの便利屋と見られる）モチベーションが低い コボル・プログラマーから企画型人材へのシフトは困難を極める！ IT子会社は可能ならインソースせよ！ 日本独自の中途半端なIT子会社の存在 デジタル時代の開発は内製化が必須 IT子会社がIT部門の足を引っ張っている・・・？ ありたい姿を明確化し、自助努力で強いIT部門になる！ Ⅲ ITを取り巻く環境の変化への対応に苦慮 セキュリティやBCPなど多様な要請に対応 セキュリティやBCPは経営マター システム導入以外の仕事（個人情報保護、内部統制etc)の増加 経営を巻き込んだ取組が必要 投資対効果をどう説明し、誰が意思決定をするのか ITのグローバル化への対応 これまでの国内の仕事しかしてこなかったIT部門での初めての経験 グローバル化の目的を明確に！ 見える化が実現するまでの苦難の道のり ～連結経営の支援～ 世界の中で日本だけが特別なIT環境 クラウドから、IoT、AI、ビッグデータへの対応 → デジタル化 セキュリティにこだわれば、NOとしか言えないIT部門 大変だが、IT部門が大きく ビジネス部門がIT部門を無視してクラウドで先行、止められないシャドウITの拡大 飛躍できる可能性が！ IoT、AI、ビッグデータというが、どこから手を付けていいかわからない 後ほど デジタル化に向けIT部門はどう変わればいいのか・・・ Ⅰ システムの導入でイニシアティブがとれない・・・ ・ オープン化・パッケージ化の流れに追従しきれない・・ IT部門が実力を 結果として、ITベンダーへの過度な依存( 内製からアウトソーシング) 汎用機からオープンシステムの採用へ 手作りからパッケージやクラウドの利用 技術についていけずにITベンダーにおんぶに抱っこ（手配師化の進行） 企画や上流までITベンダーに依頼（何か良い企画を提案してよ） つけるしかない！ ITベンダー依存を繰り返し、IT部門は崩壊していく・・・？ 本来はITが目的ではなく、ビジネス革新や業務改革が目的のはず なのに、IT導入する対象のビジネスもよく知らない・・・ どうやったら、ITのイニシアティブを取り戻せるのか・・・ システム開発でイニシアティブがとれないわけ ～ ITの導入で評判が悪いから・・・ ～ ① 真のシステム化のニーズが捉えられていない 要件定義が その機能は必要なのか？ 目的と手段がごっちゃになっていないか？ 目指すべき効果が本当に得られるのか？真のニーズを捉えていない ② ニーズに対して最適な設計がされていない コストは妥当？その機能のために、本当にこのツールが必要なの？ 最適のITアーキテクチャ になっていない 重要性に応じた「つぼ」を押さえた設計がなされてるか？ ③ ソフトウェアの品質に問題がある 要望した機能が、きちんと動くか？ バグがでたら、すぐに直せるのか？ 開発標準やプロセス に問題あり ERPパッケージ導入の結果・・・ 以下の様な謳い文句にトップダウンで導入を決定・・・ 導入するだけで経営の意思決定支援ができる 導入するだけでベストプラクティスに基づいた業務改革ができる ただ、ERPを導入するだけで上記が実現されるわけがない！ どういったデータから何を指標として意思決定するのか 具体的にどんな業務改革ができて、その効果は？ グローバル企業はシェアドサービスのためだけに使っている・・・ ①経営からは効果を求められ ②ユーザーからは文句ばかり ③予算が一桁増で金銭感覚麻痺 三重苦 IT部門はどうやって実力をつければ良いのか ～ベンダーの丸投げから脱却するために～ ビジネスに貢献し、価値を持ち続ける仕組みを構築する ビジネスを分析し、問題の本質を解決するシステム導入へ イノベーションを創出する環境整備を始めよ ビジネスに貢献し、価値を持ち続ける仕組みを構築するために BA（ビジネス・アナリシス）を学ぶべし！ ニーズを定義し、ステークホルダーに価値を提供するソリューション を推奨することにより、エンタープライズにおけるチェンジ（変革）を 可能にする専門活動（IIBA） プログラミングは無理というなら、 IT部門はまずビジネス・アナリシスを 「超上流工程」 「経営とITとの架け橋」 とも言われる 学び武器にせよ！ ビジネス（業務）とITの両方に精通している人材が行う仕事 そうした専門スキルを持つ人材 ⇒ ビジネス・アナリスト（BA) BAに必要な知識とスキルの標準（知識体系） ⇒ BABOK （超）上流は大事で、IT部門こそがやるべき仕事 IT部門はどうやって実力をつければ良いのか ～ベンダーの丸投げから脱却するために～ ビジネスに貢献し、価値を持ち続ける仕組みを構築する ビジネス・ アナリシス ビジネスを分析し、問題の本質を解決するシステム導入へ イノベーションを創出する環境整備を始めよ ITの目利きを集めよ！ ITをよく知らなければイニシアティブはとれない 目指すITアーキテクチャを明確化し、あるべき姿を追うべし ＩＴアーキテクチャの重要性 企画 •全工程を理解しつつ（少なくとも話は理解できる） システム設計 •どんな技術を使い 外部設計 •どんな開発手法で 内部設計 求められているシステムを実現するのか。 コストの大部分は、 実はここで決まる！ プログラミング テスト ビジネス・アナリスト ＩＴアーキテクト 運用・保守 こんなシステムが 欲しい こう作りましょう 実装エンジニア 保守まで考えて確 実に作ります IT部門はどうやって実力をつければ良いのか ～ベンダーの丸投げから脱却するために～ ビジネス・ ビジネスに貢献し、価値を持ち続ける仕組みを構築する！ アナリシス ビジネスを分析し、問題の本質を解決するシステム導入へ イノベーションを創出する環境整備を始めよ ITの目利き（ITアーキテクト）を集めよ！ ITをよく知らなければイニシアティブはとれない 目指すITアーキテクチャを描き常に追求すべし ITアーキ テクチャ 開発プロセスを見直し、新たな開発スタイルにもチャレンジせよ！ SoR と SoE SoR（System of Record) 統合基幹業務システム（ERP）に代表されるように、顧客が製品やサービスを “買ってから”を処理、格納するためのもの SoE（System of Engagement) 顧客情報管理システム（CRM）やマーケティングオートメーション、SNSを通じて 消費者向けに情報を提供するといったように、顧客に製品やサービスを“いか に買ってもらうか”を狙うもの → ビジネスに直結し、競争力に寄与するIT 攻めのIT ： ビジネスに直結し、競争力の源泉となるIT IT部門は SoE にどう取り組むべきなのか？ IT部門としてSoEへ取り組むには大きな変革が必要 これまでのSoRのマインドセットでは立ち行かない 受動的、保守的、官僚的 → 積極的、チャレンジ精神、ベンチャー精神 SoE領域でのシステム構築の特徴 新たな開発スタイル インフラの終焉（クラウド） ウォータフォールからアジャイルへ 開発して終わりではないDevOps 新たな契約形態 請負型開発から準委任契約 内製化（ IT子会社から精鋭メンバーを逆出向） マインド・セットの変化 オープンイノベーション デザイン思考、システム思考 IT部門は SoE にどう取り組むべきなのか？ IT部門としてSoEへ取り組むには大きな変革が必要 これまでのSoRのマインドセットでは立ち行かない 受動的、保守的、官僚的 → 積極的、チャレンジ精神、ベンチャー精神 SoE に対しては、バイモーダルの取り組み SoR（モード１） と SoE（モード２） で 組織を分ける バイモータル モード１（SoR) と モード２（SoE) モード１はこれまでの従来のIT部門のやり方 業務を安定的に回すため求められるのは、信頼性、安定性、可用性 要件定義で決めた要件に対応しシステムを構築（ウォータフォール開発） システム導入後はIT部門の運用チームが管理し安定運用を担う IT部門にとってユーザー部門が“顧客” モード２はスピード、俊敏性を最重視 製品やサービスを購入する顧客の声や実情等、外部環境の変化に対応 スピード重視のアジャイルと開発と運用チームが連携して進める“DevOps” ユーザー部門はIT部門にとって顧客ではなく、ビジネス上の“パートナー” ビジネスとITが完全に一体化し、探索、施行を繰り返す IT部門は SoE にどう取り組むべきなのか？ IT部門としてSoEへ取り組むには大きな変革が必要 これまでのSoRのマインドセットでは立ち行かない 受動的、保守的、官僚的 → 積極的、チャレンジ精神、ベンチャー精神 SoE に対しては、バイモーダルの取り組み SoR（モード１） と SoE（モード２） で 組織を分ける SoE:IT子会社から精鋭メンバーを逆出向、事業部門に IT部門から派遣（ex.) 悪貨が良貨を駆逐しないようなマネージメントが必須 SoEも小さいうちはシャドーITだが、それが大きくなると支障が・・・・ SoEとSoRは最終的には緊密な連携が必須 SoEの準備をする中で、並行してSoRの整備も求められる！ IT部門はどうやって実力をつければ良いのか ～ベンダーの丸投げから脱却するために～ ビジネス・ ビジネスに貢献し、価値を持ち続ける仕組みを構築する！ アナリシス ビジネスを分析し、問題の本質を解決するシステム導入へ イノベーションを創出する環境整備を始めよ ITの目利き（ITアーキテクト）を集めよ！ ITをよく知らなければイニシアティブはとれない 目指すITアーキテクチャを描き常に追求すべし ITアーキ テクチャ 開発プロセスを見直し、新たな開発スタイルにもチャレンジせよ！ 開発・運用 ビジネス・フロント（SoE）のシステム構築に向けて、今から準備を！ プロセス 変化に対応すべく、基幹システム（SoR)の再構築を含めた整備を IT部門がIT導入でイニシアティブをとれるために（まとめ） ビジネス・アナリシスを学び、システムの目的と価値を明確化する 新たな開発スタイルを取り入れ、SoEの内製化に向けて舵を切る 優秀なITアーキテクトやプログラマーを得て、内製化の一歩を進める ウォータフォール型開発からの脱却し、アジャイルやDevOpsなどの新たな開発 スタイルを取り入れる SoRがSoEとスムーズに連携できるように再構築を含め整備しておく 「超高速開発ツール」などを活用も含め、SoRのリファクタリング＆内製化 今こそ、デジタル化に向け、新たなチャレンジを！ 日本の改善（TPS)が影響を与えたアジャイル開発 ちなみに アジャイル開発こそが、 ソフトウェア工場から脱却し プログラマーを開放する！ デジタル時代にIT部門が向かうべき方向（最後に） ビジネスに貢献する企画の実現に注力すべし 全社を俯瞰できるIT部門こそが、会社を変革できる企画を実現できる ビジネス部門と連携したイノベーティブな企画部署の設置 エンタープライズ・データの提供者であれ！ データは最後に残るもので、データマネージメントに注力すべし データ・アナリシスを行う専門チームの設置 実力をつけ、ITの活用でイニシアティブをとれる力を持つ！ SoE領域のシステム構築に向けて今から準備を！ IT部門でカバーする領域を広げ全体最適を目指せ デジタル時代こそ、IT部門が主役になれる！ ご清聴ありがとうございました ITについてもっと深く学びませんか？ 世界標準の知識体系（BOK）等に学ぶ Enterprise Architecture BABOK 要求工学 ITIL SWEBOK ITABOK PMBOK DMBOK Enterprise Arichitecture の フレームワーク BABOK ITABOK DMBOK SWEBOK ITIL PMBOK 知っておくべきITトレンドとしてのテーマ デジタル時代にIT部門が向かうべき方向（最後に） ビジネスに貢献する企画の実現に注力すべし 全社を俯瞰できるIT部門こそが、会社を変革できる企画を実現できる ビジネス部門と連携したイノベーティブな企画部署の設置 エンタープライズ・データの提供者であれ！ データは最後に残るもので、データマネージメントに注力すべし データ・アナリシスを行う専門チームの設置 実力をつけ、ITの活用でイニシアティブをとれる力を持つ！ SoE領域のシステム構築に向けて今から準備を！ IT部門でカバーする領域を広げ全体最適を目指せ デジタル時代こそ、IT部門が主役になれる！ ご清聴ありがとうございました よく指摘される日本のＩＴ業界の問題点 プログラマーを大事にしない「ソフトウェア工場」 大手ベンダー・インテグレーターは上流工程へシフト プログラマーを軽視、単価も下落 高単価を稼げる工程だけを社員で（コンサルティング、システム分析） 多層構造の中で実装・製造工程は下請けに丸投げ 元請け→下請け→孫請け→・・・ 労働集約型、人月単価の世界 → 女工哀史の世界か・・・ 顧客には良い事しか語らない・・・ パッケージなどのコンセプトは素晴らしいが、実際はどうなのか？ ベンダーは自己利益の最大化へ動く 首根っこを押さえ、ベンダーロックインへ やはり、企業のIT部門がしっかりするしかない！ システム導入はうまくいかないことのほうが多い システム構築をITベンダーに依頼したけど・・・ 担当者が何度も変わり、その都度業務を説明している スケジュールが大幅に遅れ、予算もオーバーしてしまった ITベンダーが言われるままにシステムは構築したけど・・・ バグばかりで実用にならない 実際の業務と食い違いがあり、使えなかった 業務の変化に合わせて改修しようとしたら、大きな費用がかかる ITベンダーに勧められパッケージやERPを導入したが・・・ 必死で導入することで精一杯で、当初の目的は達成できていない 想像以上に膨大なコストがかかった それがIT部門の評価を下げている・・・ 動かないシステム 使えないシステム ＩＴ業界の何が問題なのか？ 真のニーズに基づいた提案になっているのか？ あくまでもパッケージやツールは手段 本当に最適なシステムの提案ができているか？ ＩＴアーキテクチャがコスト/パフォーマンスを決める システムの品質にきちんと責任を持とうとしているのか？ プログラミングの軽視（下請けに丸投げ） ユーザとベンダーのファジーな関係？ 日本固有のIT子会社の存在もやっかい・・・ 請負型から開発のスタイルを変えていくしかない？ 真のニーズに基づいた提案になっているのか？ 現場の言うことをそのまま鵜呑みにしていないか？ 経営の観点から、IT部門はシステ 様々な角度から本質のニーズを掴むべきムの目的と価値を明確にすべし 個別最適になってはいないか？ 現場のニーズをすべて聞いてはいないか？ 何が幹で何が枝葉なのか、経営の視点で見ているか？ 目的と手段を履き違えていないか？ システム化の要のところを、丸投げしていないか？ ITベンダーやコンサルは、どうしても他人事 企業のIT部門こそが、真のニーズを分析し要件にまとめるミッションを持つ 本当に最適なシステムの提案ができているか？ 目指すべきITアーキテクチャを 手段と目的を混同していないか？ 見定めるべし！ パッケージやツールはあくまで手段で導入が目的ではない 優秀なＩＴアーキテクトに設計して欲しい！ ＩＴアーキテクチャが違えば、コスト/パフォーマンスは段違い システムの品質にきちんと責任を持とうとしているのか？ 工程毎の分業体制によるコミュニケーション・ロス 分業体制を脱却し、新たなる 実装の分からないSEがシステムを設計 開発スタイルを導入すべし 業務の分からないプログラマーがプログラミング 製造工程を単価の安い外注へ丸投げしている弊害 あるべき開発の姿（私の経験からの仮説） 同一担当者(グループ)が用件定義から実装までを一貫して担当 全員がＳＥでありプログラマーであるべき！ プログラムのできる人間が設計 実装まで考慮した設計が可能 業務を理解したうえでのプログラミング 仕様書に表現できない“行間”もプログラミング 将来の拡張を予測したメンテナンス性の高いプログラミング 担当者のスキル向上やモチベーションの維持にも貢献 ユーザーの反応が直接体感できる ソフトウェア本来の創造性を尊重 こういった中から優秀なＩＴアーキテクトが生まれてくる・・・ 優秀なＩＴアーキテクトの条件 頼れるＩＴアーキテクトとはどんな人？ 業務の話がわかる システム設計ができる プログラムも書ける 実践経験がないと、本当には解らない 特に業務としてのプログラミング経験は必須 「昔やってました」は、すぐ陳腐化 問題意識 もって2～3年 このサイクルを回 ＩＴが本質的に好き す必要がある 調査・研究 実験 実践 あるべき開発スタイルの仮説（一貫型開発） 古典的開発モデル 一貫型開発モデル プログラマはデキが悪い 開発参加者のレベルは平均的に高い 開発者は設計もプログラミングも行う 完全分業 上流工程は間違えない（でも実際は間違える） 完全な設計はありえない 文書はコミニュケーションの一手段 文書がすべて（実際は全て伝えきれない） 大規模開発向き 中小規模開発向き 人が財産 組織と業務ルールが財産 外部設計者 文書 文書 文書 内部設計者 文書 文書 文書 開発が解らない 業務SE 大量の文書 プログラマ 文書 文書 文書 ユーザが解らない 開発SE 開発者各々にとっての個別最適 ＩＴアーキテクトは育たない 文書 文書 文書 外部設計者 内部設計者 必要最低限の文書 文書 開発もできる 業務SE プログラマ 文書 ユーザを理解した 開発SE 全体最適 ＩＴアーキテクトが育つ 要件定義、設計から実装までの一貫生産 通常のテストスタイル 実装が分からないから 作れない仕様 オーバースペックな使用 となってしまう場合がある 目指すべきスタイル 業務分析 実装まで考慮した最適設計が可能 設計 業務を理解していないから 仕様書の字面以上のプログラムにはならない 業務を理解していないから 仕様書の字面以上のテストはできない プログラミング テスト 業務を理解しているので、 業務分析のモレや設計ミスも発見できる場合が多い →少ない手戻りで仕様の修正が可能 業務を理解しているので、 仕様書の“行間”や将来の拡張も考慮できる 業務を理解しているので、 仕様書の行間を含めたテストができる →実業務に耐えるシステム 運用 工程毎に担当者やチーム変わる場合が多いため、 上流工程担当者は、運用の状況を把握できない →問題点や改善点が設計にフィードバックされない 運用状況を直接体感できる →問題点や改善点を設計にフィードバック “バグを作らない”開発スタイル 通常のテストスタイル 目指すべきスタイル 実装技術の裏づけがあって 始めて実現可能 低いプログラム品質 動けばOK 細いチェックはしない プログラミング プログラミング 単体テスト プログラミング時にプログラム単位で 徹底的にチェックするため、最小の 手戻りで、高品質のプログラムが可能 結合テスト 結合して動作することの確認程度で十分 単体テスト 結合テスト 個々の単体プログラムの動作を含めてチェック ビッグバンテストに近い場合が多い テスト量により品質が決まる スケジュールの遅れをテスト量削減で吸収 この段階でも、単体プログラムのバグが見つかる場合も多い システムテスト システム全体で動作することの確認程度で十分 システムテスト デジタル時代にIT部門が向かうべき方向（最後に） ビジネスに貢献する企画の実現に注力すべし 全社を俯瞰できるIT部門こそが、会社を変革できる企画を実現できる ビジネス部門と連携したイノベーティブな企画部署の設置 エンタープライズ・データの提供者であれ！ データは最後に残るもので、データマネージメントに注力すべし データ・アナリシスを行う専門チームの設置 実力をつけ、ITの活用でイニシアティブをとれる力を持つ！ SoE領域のシステム構築に向けて今から準備を！ IT部門でカバーする領域を広げ全体最適を考える デジタル時代こそ、IT部門が主役になれる！ ご清聴ありがとうございました デジタル化に向けIT部門はどう変わればいいのか IT部門に求められる役割の変化 これまで（IT中心） 今後（ビジネス中心） 役割 ICTの構築・運用・維持 業務変革推進、ビジネスモデル革新 エンタープライズデータの管理と活用 姿勢 現状業務をそのままシステム化 ユーザ要求に対応する受身型 業務プロセス、ビジネスモデルの変革が目的 その結果としてのICT導入 視点 個別部門効率化（部門視点） 結果としての部分最適 全組織横断でのプロセス最適化（経営視点） 全体最適の追求 スコープ 国内のみ グローバル 手法 システム開発・保守・運用 ベンダーマネージメント サービス調達・提供・管理（利用）、クラウド活用推進 エンタープライズデータの提供・受入 立ち位置 部門との合意形成重視 社内ICT専門家 手配師 変革の担い手（イノベーションを担う組織） 社内コンサルタント サービス・プロバイダー リーン思考の７原則 １．ムダをなくす：これが基本 ２．品質を作り込む：後から高めるのではなくあらかじめ作りこむ ３．知識を作り出す：知識を作り出し，共有する ４．決定を遅らせる：最も情報量の多い状態で決定、誤った判断を減らす ５．速く提供する：これにより４が実現できる ６．人を尊重する：部品や機能でなく，人間として遇する ７．全体を最適化する：部分ではなく，全体を最適化する ・顧客の目で「価値」を定義し、その「価値の流れ」を可視化する ・それを「エンドツーエンド」で「細く、速く」流れるようにする ・その流れの改善活動を、現場で実際に仕事をしている人々が行う ご清聴ありがとうございました