豆蔵 技術顧問

寺嶋 一郎

私の略歴

１９７９ 積水化学 生産技術部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-0521http://www.sekisui.co.jp/

【積水化学グループの事業展開：売上構成】

4,941億円

3,722億円2,276億円

※2015年3月期連結ベース

405億円

セキスイハイム(ユニット住宅）ができるまで

生産依頼図

工場生産体制

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子会社の売却を経営企画が考えていた・・・

積水化学のＩＴ部門の再編（２００４年～）

戦略的アライアンスの目的

事業競争力強化・ｸﾞﾛｰﾊﾞﾙ化をＩＴでさらに加速

積水化学工業新たな領域での

法人分野の事業拡大

ＮＴＴデータ

本格的なＩＴサービス企業への成長・発展

セキスイシステムセンター、アイザック

3社の事業提携による「Win-Win-Win」の実現

新・情報子会社の基本戦略

• アライアンス(資本提携)により

• 事業拡大と体質強化のスピードアップを図り

• 早期自立化に向けた成長路線に乗せる

１．内販新規分野の開拓

２．外販比率２０%超への挑戦

３．企業体質の強化(人材、技術、管理)

アウトソーシングの管理人材育成

ＩＳＡＣ 積水化学としての課題SSC

業務を知りかつITを知った開発・運用ができる強い新会社を目指す

積水化学のＩＴ部門は経営・事業に密着した企画に専念

今後、IT子会社のあり方はいかに！？

本社・情報システム部を任されて → 現在まで

IT革命が叫ばれた２０００年に情報システム部長に就任３名でスタート

それまではIT子会社（SSC)社長が情報システム部長を兼任

まずはIT部門の構造改革

評判の悪いIT子会社とITに対するアレルギー

当時不況でもあり、IT子会社の売却を経営企画が考えていた・・・

さらに、並行してやらなければと思った２つのテーマ

イントラ革新 ： インターネットが脚光を浴び、Web技術が普及

ERP理念の実現 ： 当時、ERPの導入がスタート

コーポレートIT部門として追い続けた２つの主なテーマ

① イントラ革新

－ イントラネット活用したグループでの情報共有の推進 グループの理念や方針の共有

将来の知識経営に向けた基盤整備

→ 自社開発のメール・グループウェアをグループ全社に導入

Smile (際立つ知識経営基盤）の構築経緯 Smileの狙い

間接業務の削減・効率化（標準化）

ナレッジマネージメント（理念伝達・風土改革・知識開拓）

グローバル情報共有（単一ドメイン・Know-Who管理）

(電子)社員証情報 （約23,000人）

Smile(メール) 2004

ビジネスに欠かせないセキュアーなメールシステム※容量拡大（ギガメール対応）で更に活用促進

SmileNET 2005

高速・2重化・低価格なネットワークとして国内積水グループ全社へ展開

セキュリティ(監査含む) 2005

個人情報・機密情報保護を推進ウィルスゼロへ！

Smile(グループウェア) 2005

会議室・文書管理・スケジュール等全ての

間接業務の効率化とコミュニケーションを支援

Smile(イントラネット) 2004

グループ全体への情報発信源とし、グループ経営の礎となる基幹システムへの入り口

グローバル対応と単一ドメイン化 2008,2012

社員証システムグローバル対応やiSmileによるインターネットダイレクトアクセス

WEBメール機能強化とBCP対応 2013

AWS移行による機能強化とBCP(DR)対応

IaaS移行で生産性の無いハード更新から脱却

Smileの主な機能

ポータルサイト 電子メール スケジュール(自分・他のSmileユーザのスケジュール) コンテンツブラウズ・購読リスト(コンテンツを探す・購読する) 掲示板・会議室(連絡・案内・ディスカッション) 施設予約(会議室・設備利用予約) 行事予定(会社・部所・グループ単位のスケジュール) 文書管理(ファイル管理・共有) マイフォルダ(個人用ファイルスペース) ブックマーク(Smileオンラインブックマーク) TODOリスト(作業管理) 来客対応(来客スケジュール) SmileWEB会議(オンラインWEB会議) 確認依頼(記事・文書の確認依頼) ワークフロー(利用グループ設定) 携帯版Smile(スケジュール・施設予約・メール転送設定ON/OFF) 回覧 電子メール一斉送信

CMS以外は全てOSS

内作開発言語はPearl

アジャイル開発＆DevOpsの実践

コーポレートIT部門として追い続けた２つの主なテーマ

① イントラ革新

－ イントラネット活用したグループでの情報共有の推進 グループの理念や方針の共有

将来の知識経営に向けた基盤整備

→ 自社開発のメール・グループウェアをグループ全社に導入

② ERPの理念の実現

－ グループ全社への共通基幹システムの導入 － 経営の見える化、経営の意思決定支援

業務改革、業務標準化

→ 会計／デリバリーの共通システムをグループ全社に導入

【以前の基幹システムの姿】 １９９５年基幹業務はメインフレームにて処理

グループウェアはパソコン通信方式

デリバリホスト

AS400

ＶＡＮ大手顧客

代理店

FAX,TEL

センターサーバ

会計

マスター

FAX,TEL営業所

通信機能

会計端末制御

デリバリホストデリバリホストデリバリホストデリバリホスト

人事・給与

AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400

生産・物流販売管理

グループウェア（パソコン通信方式）

メインフレーム中心

【会計システムの再構築】１９９９年・会計機能をオープン化・連結会計システムのパッケージ導入・グループウェアの運用外部委託

デリバリホスト

ＶＡＮ大手顧客

代理店

FAX,TEL

センターサーバ

マスター

FAX,TEL営業所

通信機能

デリバリホストデリバリホストデリバリホストデリバリホスト

人事・給与

会計システム（業務系）

会計システム（情報系）

会計

AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400

生産・物流販売管理

連結会計システム パ

グループウェア（外部委託） パ

ＤＷＨ

【販売管理システム再構築】 ２００３年・販売管理能をインターネット技術でオープン化

・電子メールをオープンソースで構築開始

大手顧客

代理店

センターサーバ

マスター

FAX,TEL

営業所

通信機能

人事・給与

販売システム（Ｗｅｂ型）

Internet

代理店

AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400AS400

生産・物流販売管理

会計システム（業務系）

会計システム（情報系）

会計

連結会計システム パ

グループウェア（外部委託） パ

【人事・給与システム再構築】 ２００６年・給与計算をパッケージ化、工場システムのホスト統合

・グループ社員管理をグループウェア上に構築

大手顧客

代理店

センターサーバ

マスター

FAX,TEL

営業所

通信機能

Internet

代理店

給与システム

統合AS400

AS400AS400AS400AS400AS400AS400AS400AS400AS400

生産・物流

統合AS400

AS400

パ

販売システム（Ｗｅｂ型）

販売管理

会計システム（業務系）

会計システム（情報系）

会計

連結会計システム パ

グループウェア（オープンソース化）

給与人事システム人事

【汎用機の撤廃】 ２００７年・メインフレーム全廃

・工場システムのホスト統合

大手顧客

代理店 FAX,TEL

営業所

Internet

代理店

統合AS400

AS400AS400AS400AS400

生産・物流

統合AS400

統合AS400

販売システム（Ｗｅｂ型）

マスター

通信機能販売管理

会計システム（業務系）

会計システム（情報系）

会計

連結会計システム パ

給与システムパ

グループウェア（オープンソース化）

給与人事システム人事

ＤＷＨ

【基幹システムの革新】 ２００８年グループウェアとＢＩツールの連動による柔軟な『見える化』実現

基幹システム革新による新たな付加価値の追求

大手顧客

代理店 FAX,TEL

営業所

Internet

代理店

統合AS400

AS400AS400AS400AS400

生産・物流

統合AS400

統合AS400

販売システム（Ｗｅｂ型）

マスター

通信機能販売管理

会計システム（業務系）

会計システム（情報系）

会計

連結会計システム パ

給与システムパ

グループウェア（オープンソース化）

給与人事システム

人事

『見える化』

ＤＷＨ

ERPを使わずに使いやすい基幹システムをスクラッチ開発

本社・情報システム部を任されて → 現在まで

IT革命が叫ばれた２０００年に情報システム部長に就任３名でスタート

それまではIT子会社（SSC)社長が情報システム部長を兼任

まずはIT部門の構造改革

評判の悪いIT子会社とITに対するアレルギー

当時不況でもあり、IT子会社の売却を経営企画が考えていた・・・

さらに、並行してやらなければと思った２つのテーマ

イントラ革新 ： インターネットが脚光を浴び、Web技術が普及

ERP理念の実現 ： 続々とERPパッケージを導入する日本企業

標準化の推進、グローバル対応、クラウド化 等々

２０１６年３月 定年退職

「私がやってきたこと、そこから学んだこと」ITLeaders連載中！

【第1回】 積水化学入社、ITの醍醐味を手を動かして知る

【第2回】 MITに留学、しんどいことこそリターンも大きい

【第3回】 人工知能ビジネスを目指したIT子会社～そこで住宅事業の難題に挑戦

【第4回】 IT子会社で様々なシステムを開発しながら学んだこと

【第5回】 情報システム部長に就任、四面楚歌の中でIT部門の構造改革を断行

【第6回】 なぜ積水化学では電子メールからグループウェアまで内製したのか

【第7回】 「見える化」を主体としたセキュリティ対策の推進とその効果

【第8回】 オープン化による基幹システム刷新の経緯と成果

【第9回】 全社ICT標準化の推進と成果、そしてITスタッフの頑張りについて思うこと

日本企業のIT部門を強くするためのお手伝い

＜やりたいこと＞

企業経営におけるITへの期待は、「省力化・効率化」から「いかに顧客の潜在・健在ニーズに応えて、ビジネスそのものを変えていけるか」といった領域へシフトする中、ベンダーに丸投げし、予算管理しかしてない手配師のようなIT部門から脱却し、経営視点を持ち、ビジネス部門から信頼される強いIT部門に変わっていくための支援を行いたい。

＜活動＞ TERRANET 代表

豆蔵 技術顧問

ソラコム 顧問

ビジネスシステムイニシアティブ協会 副理事

PC・ネットワークの管理・活用を考える会（PCNW) 幹事長

IIBA日本支部 代表理事（予定）

デジタル化とは？

VUCAワールド

Volatility –変動性Uncertainty –不確実性Complexity –複雑性Ambiguity –曖昧性

同時多発の新技術の出現

クラウドAI・機械学習

ビッグデータ

３Dプリンタ

ロボット

ドローンただのバズワードではない！

今、デジタルの世界で何がおきているのか

アイディア

ソフトウェア

クラウド

AI・機械学習 ビッグデータ

ソフトウェアがビジネスそのもの

になる！

IoT

ソフトウェアこそが重要なことに気づく時が来た！ デジタル時代はクラウドネイティブな「ソフトウェア」がビジネスのコア

Uber、Airbnbなどのビジネスは「ソフトウェア」そのもの

しのぎを削る自動運転はソフトウェアが勝負！

新たな「ソフトウェア」は内製が当たり前

アジャイル、DevOps等の新たなスタイルでの開発

優秀なソフト技術者をどう集めるかが勝負

「アイディア」と「ソフトウェア」が世界を変える！

Software eat the world!

デジタル時代こそIT部門が浮上するチャンス！

それなのにIT部門の劣化が進んでいる？ ベンダーに丸投げ状態のIT部門

企画までベンダーに提案を求める

技術は社員でなくベンダーからの常駐社員が担っている

モチベーションが上がらず、閉じこもりがちになるIT部門

大半が保守・運用の仕事

現場に行きたがらない

人材がタコツボ化

業務部門とのローテーションが進まない

他部門からIT部門に来てもなかなか仕事になじめない

様々な課題を抱える悩めるIT部門

日本企業のIT部門の課題

Ⅰ システムの導入でイニシアティブがとれない・・・・

Ⅱ 経営層、他部門で認められず地位が低い

Ⅲ ITを取り巻く環境の変化への対応に苦慮

Ⅱ、Ⅲ、Ⅰの順で考えていきます・・・

Ⅱ 経営層、他部門で認められず地位が低い 日本の経営者はITが嫌い？

ITはわからないといって自慢？するトップは日本だけ

お金はかかるし、トラブルがあればその責任を問われるのでITには関わりたくない

大幅な費用増やトラブル等で、なにか失敗しないと経営の注目を浴びない・・・

IT人材の育成に苦慮

ユーザー企業にITをやりたいとして入社する人はいない・・・

専門家として尊敬されず（ただの便利屋と見られる）モチベーションが低い

コボル・プログラマーから企画型人材へのシフトは困難を極める！

日本独自の中途半端なIT子会社の存在

IT子会社がIT部門の足を引っ張っている・・・？

ありたい姿を明確化し、自助努力で強いIT部門になる！

経営に向かって、工夫して、わかりやすくITを語れ！

目指すべきIT部門の姿を描き、それに向けての人材育成を

IT子会社は可能ならインソースせよ！デジタル時代の開発は内製化が必須

Ⅲ ITを取り巻く環境の変化への対応に苦慮 セキュリティやBCPなど多様な要請に対応

システム導入以外の仕事（個人情報保護、内部統制etc)の増加 投資対効果をどう説明し、誰が意思決定をするのか

ITのグローバル化への対応 これまでの国内の仕事しかしてこなかったIT部門での初めての経験 見える化が実現するまでの苦難の道のり 世界の中で日本だけが特別なIT環境

クラウドから、IoT、AI、ビッグデータへの対応 → デジタル化 セキュリティにこだわれば、NOとしか言えないIT部門 ビジネス部門がIT部門を無視してクラウドで先行、止められないシャドウITの拡大 IoT、AI、ビッグデータというが、どこから手を付けていいかわからない

デジタル化に向けIT部門はどう変わればいいのか・・・

セキュリティやBCPは経営マター経営を巻き込んだ取組が必要

グローバル化の目的を明確に！～連結経営の支援～

大変だが、IT部門が大きく飛躍できる可能性が！後ほど

Ⅰ システムの導入でイニシアティブがとれない・・・・

オープン化・パッケージ化の流れに追従しきれない・・ 汎用機からオープンシステムの採用へ 手作りからパッケージやクラウドの利用

結果として、ITベンダーへの過度な依存(内製からアウトソーシング)

技術についていけずにITベンダーにおんぶに抱っこ（手配師化の進行） 企画や上流までITベンダーに依頼（何か良い企画を提案してよ）

ITベンダー依存を繰り返し、IT部門は崩壊していく・・・？ 本来はITが目的ではなく、ビジネス革新や業務改革が目的のはず なのに、IT導入する対象のビジネスもよく知らない・・・

どうやったら、ITのイニシアティブを取り戻せるのか・・・

IT部門が実力をつけるしかない！

システム開発でイニシアティブがとれないわけ～ ITの導入で評判が悪いから・・・ ～

① 真のシステム化のニーズが捉えられていない その機能は必要なのか？ 目的と手段がごっちゃになっていないか？

目指すべき効果が本当に得られるのか？

② ニーズに対して最適な設計がされていない コストは妥当？その機能のために、本当にこのツールが必要なの？

重要性に応じた「つぼ」を押さえた設計がなされてるか？

③ ソフトウェアの品質に問題がある 要望した機能が、きちんと動くか？

バグがでたら、すぐに直せるのか？

要件定義が真のニーズを捉えていない

最適のITアーキテクチャになっていない

開発標準やプロセスに問題あり

ERPパッケージ導入の結果・・・ 以下の様な謳い文句にトップダウンで導入を決定・・・

導入するだけで経営の意思決定支援ができる 導入するだけでベストプラクティスに基づいた業務改革ができる

ただ、ERPを導入するだけで上記が実現されるわけがない！ どういったデータから何を指標として意思決定するのか

具体的にどんな業務改革ができて、その効果は？

グローバル企業はシェアドサービスのためだけに使っている・・・

①経営からは効果を求められ②ユーザーからは文句ばかり 三重苦③予算が一桁増で金銭感覚麻痺

IT部門はどうやって実力をつければ良いのか～ベンダーの丸投げから脱却するために～ ビジネスに貢献し、価値を持ち続ける仕組みを構築する

ビジネスを分析し、問題の本質を解決するシステム導入へ イノベーションを創出する環境整備を始めよ

ビジネスに貢献し、価値を持ち続ける仕組みを構築するために

BA（ビジネス・アナリシス）を学ぶべし！

ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにおけるチェンジ（変革）を可能にする専門活動（IIBA）

「超上流工程」 「経営とITとの架け橋」 とも言われる

ビジネス（業務）とITの両方に精通している人材が行う仕事

そうした専門スキルを持つ人材 ⇒ ビジネス・アナリスト（BA)

BAに必要な知識とスキルの標準（知識体系） ⇒ BABOK

（超）上流は大事で、IT部門こそがやるべき仕事

プログラミングは無理というなら、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アーキテクチャを描き常に追求すべし

開発プロセスを見直し、新たな開発スタイルにもチャレンジせよ！ ビジネス・フロント（SoE）のシステム構築に向けて、今から準備を！ 変化に対応すべく、基幹システム（SoR)の再構築を含めた整備を

ビジネス・アナリシス

ITアーキテクチャ

開発・運用プロセス

IT部門がIT導入でイニシアティブをとれるために（まとめ）

ビジネス・アナリシスを学び、システムの目的と価値を明確化する

新たな開発スタイルを取り入れ、SoEの内製化に向けて舵を切る

優秀なITアーキテクトやプログラマーを得て、内製化の一歩を進める

ウォータフォール型開発からの脱却し、アジャイルやDevOpsなどの新たな開発スタイルを取り入れる

SoRがSoEとスムーズに連携できるように再構築を含め整備しておく 「超高速開発ツール」などを活用も含め、SoRのリファクタリング＆内製化

今こそ、デジタル化に向け、新たなチャレンジを！

日本の改善（TPS)が影響を与えたアジャイル開発

アジャイル開発こそが、ソフトウェア工場から脱却しプログラマーを開放する！

ちなみに

デジタル時代にIT部門が向かうべき方向（最後に） ビジネスに貢献する企画の実現に注力すべし

全社を俯瞰できるIT部門こそが、会社を変革できる企画を実現できる ビジネス部門と連携したイノベーティブな企画部署の設置

エンタープライズ・データの提供者であれ！ データは最後に残るもので、データマネージメントに注力すべし データ・アナリシスを行う専門チームの設置

実力をつけ、ITの活用でイニシアティブをとれる力を持つ！ SoE領域のシステム構築に向けて今から準備を！ IT部門でカバーする領域を広げ全体最適を目指せ

デジタル時代こそ、IT部門が主役になれる！

ご清聴ありがとうございました

ITについてもっと深く学びませんか？

BABOK

ITABOK

SWEBOK

PMBOK

要求工学

ITIL

世界標準の知識体系（BOK）等に学ぶ

DMBOK

Enterprise Architecture

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部門はシステムの目的と価値を明確にすべし

システムの品質にきちんと責任を持とうとしているのか？ 工程毎の分業体制によるコミュニケーション・ロス

実装の分からないSEがシステムを設計

業務の分からないプログラマーがプログラミング

製造工程を単価の安い外注へ丸投げしている弊害

本当に最適なシステムの提案ができているか？ 手段と目的を混同していないか？

パッケージやツールはあくまで手段で導入が目的ではない

優秀なＩＴアーキテクトに設計して欲しい！

ＩＴアーキテクチャが違えば、コスト/パフォーマンスは段違い

分業体制を脱却し、新たなる開発スタイルを導入すべし

目指すべきITアーキテクチャを見定めるべし！

あるべき開発の姿（私の経験からの仮説）

同一担当者(グループ)が用件定義から実装までを一貫して担当

全員がＳＥでありプログラマーであるべき！ プログラムのできる人間が設計

実装まで考慮した設計が可能

業務を理解したうえでのプログラミング 仕様書に表現できない“行間”もプログラミング

将来の拡張を予測したメンテナンス性の高いプログラミング

担当者のスキル向上やモチベーションの維持にも貢献 ユーザーの反応が直接体感できる

ソフトウェア本来の創造性を尊重

こういった中から優秀なＩＴアーキテクトが生まれてくる・・・

優秀なＩＴアーキテクトの条件

頼れるＩＴアーキテクトとはどんな人？ 業務の話がわかる

システム設計ができる

プログラムも書ける

実践経験がないと、本当には解らない

特に業務としてのプログラミング経験は必須

「昔やってました」は、すぐ陳腐化

もって2～3年

ＩＴが本質的に好き

問題意識

調査・研究

実験

実践このサイクルを回す必要がある

あるべき開発スタイルの仮説（一貫型開発）

開発参加者のレベルは平均的に高い

開発者は設計もプログラミングも行う

完全な設計はありえない

文書はコミニュケーションの一手段

中小規模開発向き

人が財産

開発もできる業務SE

ユーザを理解した開発SE

外部設計者 プログラマ内部設計者

全体最適ＩＴアーキテクトが育つ

文書 必要最低限の文書 文書

一貫型開発モデル

開発者各々にとっての個別最適ＩＴアーキテクトは育たない

外部設計者 内部設計者 プログラマ

文書

開発が解らない業務SE

ユーザが解らない開発SE

文書文書文書文書文書 文書文書文書文書

文書文書文書 大量の文書

プログラマはデキが悪い

完全分業

上流工程は間違えない（でも実際は間違える）

文書がすべて（実際は全て伝えきれない）

大規模開発向き

組織と業務ルールが財産

古典的開発モデル

要件定義、設計から実装までの一貫生産通常のテストスタイル 目指すべきスタイル

業務分析

設計

プログラミング

テスト

運用

実装まで考慮した最適設計が可能

業務を理解しているので、業務分析のモレや設計ミスも発見できる場合が多い

→少ない手戻りで仕様の修正が可能

業務を理解しているので、仕様書の行間を含めたテストができる

→実業務に耐えるシステム

実装が分からないから作れない仕様オーバースペックな使用

となってしまう場合がある

工程毎に担当者やチーム変わる場合が多いため、上流工程担当者は、運用の状況を把握できない

→問題点や改善点が設計にフィードバックされない

業務を理解していないから仕様書の字面以上のプログラムにはならない 業務を理解しているので、

仕様書の“行間”や将来の拡張も考慮できる

業務を理解していないから仕様書の字面以上のテストはできない

運用状況を直接体感できる→問題点や改善点を設計にフィードバック

“バグを作らない”開発スタイル

プログラミング

単体テスト

結合テスト

システムテスト

単体テスト

結合テスト

システムテスト

この段階でも、単体プログラムのバグが見つかる場合も多い

プログラミング

個々の単体プログラムの動作を含めてチェックビッグバンテストに近い場合が多いテスト量により品質が決まるスケジュールの遅れをテスト量削減で吸収

低いプログラム品質

動けばOK細いチェックはしない

通常のテストスタイル 目指すべきスタイル

プログラミング時にプログラム単位で徹底的にチェックするため、最小の手戻りで、高品質のプログラムが可能

結合して動作することの確認程度で十分

システム全体で動作することの確認程度で十分

実装技術の裏づけがあって始めて実現可能

デジタル時代にIT部門が向かうべき方向（最後に） ビジネスに貢献する企画の実現に注力すべし

全社を俯瞰できるIT部門こそが、会社を変革できる企画を実現できる ビジネス部門と連携したイノベーティブな企画部署の設置

エンタープライズ・データの提供者であれ！ データは最後に残るもので、データマネージメントに注力すべし データ・アナリシスを行う専門チームの設置

実力をつけ、ITの活用でイニシアティブをとれる力を持つ！ SoE領域のシステム構築に向けて今から準備を！ IT部門でカバーする領域を広げ全体最適を考える

デジタル時代こそ、IT部門が主役になれる！

ご清聴ありがとうございました

デジタル化に向けIT部門はどう変わればいいのか

これまで（IT中心） 今後（ビジネス中心）

役割 ICTの構築・運用・維持 業務変革推進、ビジネスモデル革新

エンタープライズデータの管理と活用

姿勢 現状業務をそのままシステム化

ユーザ要求に対応する受身型

業務プロセス、ビジネスモデルの変革が目的

その結果としてのICT導入

視点 個別部門効率化（部門視点）

結果としての部分最適

全組織横断でのプロセス最適化（経営視点）

全体最適の追求

スコープ 国内のみ グローバル

手法 システム開発・保守・運用

ベンダーマネージメント

サービス調達・提供・管理（利用）、クラウド活用推進

エンタープライズデータの提供・受入

立ち位置 部門との合意形成重視

社内ICT専門家

手配師

変革の担い手（イノベーションを担う組織）

社内コンサルタント

サービス・プロバイダー

IT部門に求められる役割の変化

リーン思考の７原則

１．ムダをなくす：これが基本

２．品質を作り込む：後から高めるのではなくあらかじめ作りこむ

３．知識を作り出す：知識を作り出し，共有する

４．決定を遅らせる：最も情報量の多い状態で決定、誤った判断を減らす

５．速く提供する：これにより４が実現できる

６．人を尊重する：部品や機能でなく，人間として遇する

７．全体を最適化する：部分ではなく，全体を最適化する

・顧客の目で「価値」を定義し、その「価値の流れ」を可視化する

・それを「エンドツーエンド」で「細く、速く」流れるようにする

・その流れの改善活動を、現場で実際に仕事をしている人々が行う

ご清聴ありがとうございました