ERPとこれからのアプリケーション開発 2016年9月14日.

Presentation on theme: "ERPとこれからのアプリケーション開発 2016年9月14日."— Presentation transcript:

1 ERPとこれからのアプリケーション開発 2016年9月14日

2 ERP

3 ERPとは 3

4 ERPシステム 登場の歴史的背景 ERP メインフレーム時代 部分最適 複製システム・分散システム時代 部分最適 ERP時代 全体最適
業務 業務 業務 業務 業務 業務 業務 業務 業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 新規業務 業務 機能 業務 機能 業務 機能 業務 機能 SYS SYS SYS SYS SYS SYS SUB SYS SUB SYS SUB SYS 業務 機能 統合マスター データベース ERP 業務 機能 部分最適 から 全体最適 へ 【図解】コレ１枚でわかるERPの歴史 1960年代に入り、ビジネス用途で使えるコンピューターが、普及しはじめます。当時、業務は、電話や紙の伝票の受け渡しで行われていましたが、その業務の流れをコンピューターのプログラムに置き換えようという使い方です。当時は、個々の業務の現場で使われている紙の伝票の流れに合わせて、プログラムのフローを設計したことから、業務個別に最適化されたシステムが作られてゆきました。 ただ、このようなシステムであっても、電話や伝言、紙の伝票での業務処理に比べれば、作業の生産性は劇的に向上したことから、情報システムの開発需要は、どんどん増えてゆきます。ただ、当時は、ユーザー企業の情報システム部門が、それぞれ独自に自社の業務に合わせてプログラムを内製するのが普通であったため、この需要に追いつけなくなってゆきました。 この状況を打開するため、最初から個々の業務に最適化された情報システムを作るのではなく、既に完成し稼働しているプログラムをコピーして、新しい業務に合わせて変更しなければならない部分だけを修正し、需要の増加に応えていたのです。それでも、完全に業務の流れに対応できないときは、人的な運用で代替することで凌いでいました。 また、1980年代に入り、小型のミニコンピューター（ミニコン）やオフィース・コンピューター（オフコン）、パーソナルコンピュータ（パソコン）が登場します。当時業務システムとして使われていた大型のメインフレームでのシステム開発では、要望してもすぐに開発してもらえず、コストも掛かることから、業務部門は、独自にこれら小型のコンピューターを導入し、さらにパッケージ・ソフトウェアを使って個別システムを構築するようになります。 このような取り組みにより、情報システムの適用範囲は拡大してゆきましたが、部分最適なシステムが増えたために、業務間の連係がうまく行えなかったり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えるようになったのです。 そんな中で、業務の重複や無駄を廃し、業務の効率化を図りたいという需要が高まってゆきます。また、エンロン事件やワールドコム事件のような、大規模な不正が大きな社会問題となったことなどもあり、内部統制への関心も高まります。そのために一貫性や完全性が保証されたデータで経営や業務状況を把握したいという需要も増えてゆきました。 そこで、これまで業務個別に最適化され開発されてきた情報システムを全社最適の視点で再構築しようという気運が高まります。そこで、全社最適の観点での業務プロセスを再構築し、業務個別に構築されていたマスターデータを全社で統合したデータベースに集約するとともに、その統合化されたデータベースを中核に業務システムを構築する「ERP（Enterprise Resource Planning）システム」が、注目されるようになったのです。 現場の業務をそのままシステム化 元の書類の流れに合わせたシステム 部分最適なシステム構築 様々な部門が様々なシステムを導入 重複業務（顧客マスター登録など） 別々のDB（顧客データなど） システム間でデータの互換性が無い 業務 機能 業務 機能 部門SYS 部門 SYS 部門SYS 業務 機能 業務 機能 業務 機能 業務 機能 業務のシステム化 業務システムの適用領域拡大 業務システムの統合化

5 個別業務システムとERPシステムの違い 個別業務システム ERPシステム 販売 生産 ・・・ 販売 生産 ・・・ 統合データベース ・・・
会計 人事 ・・・ 会計 人事

6 ERPシステムとは 人事 生産 販売 会計 人事 生産 販売 会計 個別業務システム ERPシステム 業務個別に
プロセス 個別 システム 個別 システム 個別 システム 個別 システム ERPシステム 人事 生産 販売 会計 業務システム 経営 個別DB 個別DB 個別DB 個別DB 全社統合DB データベース 業務個別に プロセス・データの整合性を確保 会社全体として業務間の プロセス・データの整合性を保証 【図解】コレ１枚でわかるERPシステム ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法のことです。このERP経営を実現するための情報システムが、ERPシステムです。 業務個別に作られた情報システムは、それぞれ、台帳や帳票を収めたマスターファイルと業務処理を行うためのプログラムで構成されています。このようなシステムの場合、個々の業務処理には最適化されていますが、他の業務間の連係がうまく行えなかったり、似たような業務を重複して行っていたり、データの不整合や二重入力といった弊害が増えたりと、いろいろな問題を抱えることになります。例えば、「顧客情報」は、お客様の購買情報を管理し、販促キャンペーンでチラシを郵送するために販売システムで使われます。また、お客様に荷物を輸送する必要がある場合は、物流システムにも必要ですし、請求書を発行し、入金を確認するためには、会計システムでも使われます。しかし、マスターファイルが、個別に管理されていると、顧客情報が変更されたり、商品を販売したことで情報が更新されたりした場合、関係する全てのデータを書き換えなくてはなりません。また、ある業務システムのプログラムが修正された場合、影響をうける他の業務システムのプログラムを洗い出し、それを修正しなくてはなりません。 一方、ERPシステムは、会社全体で統合化されたマスター・データベースを用意します。全ての業務処理は、この統合化されたデータベースを使用します。そのため、データの一貫性は保証され、データの不整合や二重入力の手間はかかりません。また、データ相互の関連は、業務の流れ（ワークフロー）と一体となってデータベースに格納されますので、業務プロセス全体の整合性も保証されます。 さらに、データが全て一元的管理され、常に最新の状態に保たれていることから、会社全体の動きや状況をリアルタイムで捉えることができます。 ただ、このようなERPシステムを構築するためには、既に業務毎に個別最適化された業務プロセスを見直し、会社全体で最適化された業務プロセスに再構築しなければなりません。このような取り組みをBPR（Business Process Re-engineering）と言います。また、個別に作られたマスターファイルを整理し、統一のデータベースに作り直さなければなりません。 既に個々の業務の現場に最適化されたシステムが稼働し、それに馴れている人たちからは、抵抗されることも少なくありません。会社全体が抱える課題や現状についての危機感を正しく共有し、経営トップの強力なリーダーシップの元に取り組まなければ、実効性のあるERPシステムを構築することは、困難と言えるでしょう。 特　徴 処理にタイムラグが発生 二重入力によりマスターの分散 個別設計・構築 データやプロセスの不整合 個別維持管理による運用負担 プロセス全体の可視性なし リアルタイム処理 マスターの統合 全体最適化された設計・構築 データやプロセスの整合性を保証 プロセス全体の可視性を確保

7 「ERP」と「ERPシステム」と「ERPパッケージ」
ERP Enterprise Recourse Planning あるべき姿のひな形を使って、経営や業務の全体最適化を加速 企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を 適切に分配し有効活用する計画を重視する経営手法 ERP システム ERP経営を実現するための 情報システム ERP パッケージ ERP経営を支える理想的な業務プロセスをパッケージ化した情報システム 業務分析や業務プロセスの標準化(BPR)に手間やコストがかかり、実現が困難 【図解】コレ１枚でわかるERPとERPシステムとERPパッケージの違い 「ERP」と「ERPシステム」と「ERPパッケージ」の違いをご存知でしょうか。よく似た言葉ですが、それぞれに意味が違います。歴史的な背景を踏まえながら、その違いを解説します。 ERP ERP（Enterprise Resource Planning）とは、企業経営の基本となる資源要素（ヒト・モノ・カネ・情報）を会社全体で一元的に把握し、それを適切に分配して有効活用する計画手法であり、その計画を重視する経営手法です。 ERPという言葉は、製造業における資材所要量計画 (MRP：Material Requirements Planning) といわれる生産資材を管理し、計画する手法から派生した言葉で、資材以外の人員、設備など製造に必要なすべての資源を管理し、さらに、企業全体の在庫、決済、資産の管理を行うように発展したのがERP（企業資源計画）です。情報システムそのものを意味する言葉ではありません。 ERPシステム ERP経営を実現するための情報システムです。ERP経営を実現するためには、会社全体で業務の重複や無駄を排除し、部門個別に最適された業務プロセスではなく、会社全体として最適な業務プロセスを実現しなければなりません。そのためには、徹底した業務分析と業務プロセスの改革、標準化に取り組まなくてはなりません。この取り組みは、BPR（Business Process Re-engineering）と呼ばれています。ERPシステムは、このBPRを実施した結果明確にされた、全体最適化された業務プロセスを前提に構築される情報システムです。 ERPパッケージ 企業規模が大きくなればなるほど、部門の利害はぶつかり、部門を越えた会社全体での最適化をめざすBPRは困難を極めます。加えて、ビジネス環境の変化は、業務プロセスを常に変化させ、全体最適を維持するために業務プロセスの継続的見直しと最適化を行うこと（BPM：Business Process Management）は、容易ではありません。その変更に合わせてERPシステムに手を加え続けるとなると、手間もコストも膨大なものになってしまいます。そこで、登場したのか、ERPパッケージです。 ERPパッケージは、ERP経営を支える理想的（ベストプラクティス）な業務プロセスを予めパッケージ化した情報システムです。 ERPパッケージには、ERP経営を実践する上で必要となる業務プロセスや全社データを一元的に把握、管理するためのデータ構造のひな形が、業種や業務に応じたテンプレートとして、予め用意されています。このテンプレートを使い、業務の変革をすすめ、ERP経営の実現を加速しようというのです。 本来であれば、ERPパッケージが提供するベストプラクティスに沿ってBPRを推進すれば、ERP経営が実現できるわけですが、既に個別最適化された業務プロセスを持つ各業務部門が、それに合わせることは容易なことではありません。そんな現実を踏まえながら、最低限のテンプレートのカストマイズ、および、独自開発システムで対応できれば、ERPパッケージ導入の効果を享受することが可能となります。 ERPパッケージを、自社独自の基幹業務システムを開発するに当たり、最初から全てを作るのではなく、パッケージの機能を流用することで開発生産性を高めるための手段と捉えている企業もあります。しかし、それは、ERPパッケージ本来の目的でありません。「ERP経営実現を加速するための手段」ととらえ、カスタマイズや追加独自開発を極力少なくする取り組みを行わなければ、本来の価値を引き出すことができないことを理解しておく必要があります。

8 ERPシステムの全体像 ERPシステム 統合データ アナリティクス 可視化 可視化・分析・計画 アプリケーション 営業・販売 経理・財務
効率的義用務運営 リアルタイム経営 内部統制 ERPパッケージ利用のメリット ベストプラクティスの活用 法律・制度変更への迅速な対応 構築に関わる期間とコストの削減 経営 営業・販売 可視化 可視化・分析・計画 アプリケーション 経理・財務 営業・販売 アプリケーション アナリティクス 経理・財務 アプリケーション 統合データ 倉庫・物流 アプリケーション 調達・管理 アプリケーション 【図解】コレ１枚でわかるERPシステムのメリット ERPシステムの価値は、以下の3つだといえるでしょう。 効率的業務運営 従来業務ごとに分散し、分断されていたマスターデータ（製品や取引先など）や取引データ（各種伝票など）を、統合データベースによって一元管理できます。そのため、全ての業務処理は、単一のデータを参照し、更新されるため、ある業務処理が実行されると同時に、そのデータに関連する全ての業務にもその更新が反映されます。 例えば、顧客情報が更新されると、それを使用する販売、会計、出荷などの全ての業務システムが、更新された同一のデータをすぐに利用できるため、業務プロセス全体で直ちに整合性が担保され、部門間の連携がスピーディに行えます。また、同じデータを複数の業務システムに個別に入力する、あるいは転記すると言った手間がなくなり、業務の効率化が実現されます。 また、販売、生産、会計など複数の業務をつなぐ処理手順（ワークフロー）も統合データベースで管理されます。そのため、業務の流れとデータ更新の整合性が常に担保されることから、正確で円滑な業務処理が実現されます。 リアルタイム経営 業務に関わるデータは、常に全体として最新の状況が反映されていることに加え、売上や原価、在庫や進捗などの数字も全て一元的に管理されているため、会社全体の状況をリアルタイムで把握することが可能になります。BI（Business Intelligence）アプリケーションなどを使用し、経営や業務の状況を分析、可視化し、経験や勘ではなく、データに基づく意志決定を正確、迅速に行うことを可能とします。 内部統制 統合データベースによるデータの整合性の保証、また、ワークフローに基づく利用者権限や利用履歴の一元管理により、会社の業務全般にわたっての内部統制が、容易に行える環境を整えます。 これらパッケージとして導入する場合、以下の３つのメリットを享受することができます。 ベスト・プラクティスの活用 ERPパッケージの開発元や導入支援企業は、多くのユーザーでの実務経験を収集し、それぞれの業種や業務に応じたベスト・プラクティスのテンプレートを提供しています。 ERPパッケージには、業務処理に必要な基本機能をプログラムとして実装していますが、それらをどのように使用するかをプログラムそのものに手を加えることなく、パラメーターやスクリプト言語によって設定できます。その設定のセットが、テンプレートです。このテンプレートを使うことで、他社のノウハウやベスト・プラクティスを利用することで、自社のERP経営に向けた業務改革を加速させることができます。 法律・制度変更への迅速な対応 自社で独自の情報システムを構築する場合、税務や会計などの法律や制度が替わるたびに、プログラムの改修が必要になります。ERPパッケージでは、このような変更をパッケージの開発元が実施し、対応してくれます。そのため、制度変更への対応の負担が少なく、迅速に対応することができます。 構築に関わる期間とコストの削減 ERPパッケージを導入するに当たっては、現状業務の分析と整理、ERPパッケージが提供するテンプレートとのギャップを明らかにしなくてはなりません。その上で、変えなくてはならない業務プロセスは何か、テンプレートの何をカスタマイズするか、追加すべきプログラムは何かを明確にします。 本来であれば、ERPパッケージが提供するベストプラクティスに沿って業務改革（BPR：Business Process Reengineering）し、パッケージをそのまま利用することが導入コストと期間という点では望ましいと言えますが、既に各企業において最適化された業務プロセスを変更することは容易ではありません。そんな現実を踏まえながら、BPRを推進することで、独自開発を減らすことができれば、導入・構築に関わる期間短縮とコスト削減の効果を大きくすることができます。 生産・製造 アプリケーション 人事・給与 アプリケーション 倉庫・物流 調達・管理 ERPシステム 倉庫・物流 調達・管理

9 ERPのグローバル展開と ２層ERP（Two-tier ERP） 9

10 ERPの理想と現実 2層ERP 理 想 Global Single Instance / One Global Standard 現 実
理　想 国内外のグループ企業の全拠点に同一ERPシステムを導入し、データフォーマットを統一、業務やデータの連係を円滑に行う。その結果、業務処理を効率化でき、経営状況をリアルタイムで把握できるようにする。 Global Single Instance / One Global Standard 拠点毎に個別最適なパッケージを導入 親会社のシステムをひな形とする 親会社のマスターに合うようにデータを変換する 2層ERP 2 Tier ERP 【図解】コレ１枚でわかる２層ERP 企業活動のグローバル化に伴い、経営資源もまたグローバルに全体最適を求められるようになりました。その対応として、国内外のグループ企業の全拠点に同一のERPシステムを導入することで、データフォーマットを統一し、業務やデータの連係を円滑に行うことで、業務処理を効率化し、経営状況をリアルタイムで把握できるようにしようというニーズが高まってきました。全拠点を単一の企業組織のように扱おうというこの考え方は、Global Single Instanceと呼ばれています。 しかし、本社とは異なる事業を行っていたり、海外の地元企業との合弁会社であったり、商習慣が異なっていたりする拠点においては、業務フローやデータ構成が本社と異なることは避けられません。このような拠点に同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまうことがあります。 また、本社は、大企業であっても、海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コスト的に見合わず、その維持管理に、十分な人材を割くこともできません。 また、国によっては、政治情勢や経済状況の変化が、日本のようには予測できず、事業を直ちに統廃合しなければなければならないといったことも考えられます。そのため、本社と同一の大規模なERPシステムを全拠点に導入することは、大きなリスクを伴うことになります。 このようなリスクを回避し、グローバルでの全体最適をめざす手段として登場したのが、「2層ERP（Two-tier ERP）」という考え方です。 2層ERPとは、本社で稼働している大規模なERPシステムとは別に、各拠点の事業内容や規模に応じて最適なERPシステムを導入し、本社のERPシステムと、一定のルールに基づきデータの組み替えを行い円滑なデータ連携を図ろうというものです。本社のERPシステムを「1st tier ERP（または、コアERP）システム」、各拠点のERPシステムを「2nd tier ERPシステム」と呼びます。 各拠点は、それぞれの業務や規模に合わせてERPシステムを選定できるため、先に挙げたリスクを回避できます。加えて、本社は、各拠点のERPシステムのデータをコアERPシステムに容易に取り込むことが可能となり、グローバルな全体最適を実現しやすくなります。 各拠点のERPシステムは、コアERPシステムとのデータ連携が可能であれば、様々なERPパッケージの中から選定することができます。ただ、本社からの運用支援や連携を効率よく行うために、できるだけ同一のものを採用する傾向にはあるようです。 昨今、2nd tier ERPシステムをクラウド版のERPシステムで導入しようという動きが増えています。クラウド版のERPシステムは、サーバ購入や運用管理要員の雇用のためのコストがかからず、短期間での導入できます。更に、ビジネスの展開に合わせて、機能や性能の伸縮を柔軟に行うことできるため、ビジネスの不確実性が高い海外拠点で導入するには、最適な選択肢となっています。このような理由から、クラウドERPを利用した2層ERPの採用は今後増えてゆくものと考えられます。 現　実 本社と同一の大規模ERPシステムの全拠点導入は大きなリスクを伴う 本社と異なる事業、地元企業との合弁、商習慣の違いにより、業務フローやデータ構成が本社と異なる。 同一のシステムを導入すると、現場の業務内容とERPシステムの機能とのギャップを人手による運用で埋めなくてはならず、逆に業務負担が増えてしてしまう。 海外の拠点は、小規模な組織で運用されていることもあり、本社と同様の大規模なERPシステムでは、コストに見合わず、その維持管理に、十分な人材を割くこともできない。 政治情勢や経済状況の変化が予測できず、事業を直ちに統廃合しなければならないことも考えられる。

11 2層ERP(2-Tier ERP)の考え方 ERPの目指す理想型 本 社 2層ERPの考え方 本 社 子会社 子会社
本　社 子会社 2層ERPの考え方 本　社 子会社 同一経営プロセス/同一アプリケーシュン 同一勘定科目・管理基準 複数企業体が、同一企業体のごときオペレーション 個別経営プロセス/個別アプリケーション 本社勘定科目・管理基準に準拠 複数企業体の個別オペレーション／データ組替連携

12 Two-tier ERP (2層ERP)の構成
親会社 ERP Business byDesign 子会社

13 1st Tier 2nd Tier 2層ERPの仕組み データ変換のためのインターフェイス (Core ERP) 販売 生産 物流
大企業向けパッケージ 販売 生産 物流 統合データベース 購買 会計 人事 データ変換のためのインターフェイス 2nd Tier 中小向けパッケージ クラウドERPなども活用 1st Tierとのインターフェイス 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース 販売 生産 物流 購買 会計 人事 統合データベース

14 ERPと EA・BPR・BPM 14

15 部分最適なシステム構築 サイロ化 現場の業務をそのままシステム化 ・元々の「書類の流れ」に合わせたシステム ・部分最適なシステム構築
・様々な部門が様々なシステムを導入 ・重複する業務（顧客マスターの登録など） ・別々のDB（顧客データなど） ・システム間でデータの互換性が無い 1964年に発表された世界初の汎用機であるIBM System360は、「360度全ての用途に使える」コンピュータでした。 生産管理・販売管理・会計処理などをひとつのシステムで行うことができました。 1台のマシンで全てのアプリを動かすわけですから、開発・運用もほとんどの場合ひとつの会社が請け負います。 システム構成や他のアプリも熟知していますから、アプリ間の連携がとれない、などという事態は起こらなかったわけです。 しかし、メインフレームは数十億円もするシステムですから、導入できる企業は限られています。 1970年代以降、ダウンサイジングの波が起こり、コンピュータの価格が劇的に下がり、それまでコンピュータを導入できなかった企業にも浸透しはじめたのです。 その結果、事業部門毎に様々なシステムが入ることになりました。IT部門が頑張って整合性をとろうとする動きもあったでしょうが、全ての面倒を見ることはできません。 様々なシステムが、個々の事業部門の要求仕様に従って構築されたのです。どうしても、他部門のシステムとの統合にまで考えがおよばないケースもあったでしょう。 システム毎にメーカーが違ったり、開発業者が違うケースもあります。導入時期が違えば、使う技術も変わります。 しかし、発注元である現場部門としては、自分達の要求が満たされることが第一の目的です。 要求仕様をどう作るかというと、皆さんも経験があるでしょうが、現場でどういった業務を行っているかをヒアリングするのがまずは第一歩です。 その業務の流れを、そのままコンピュータ化するのがシステム開発です。いわば「その時点での『書類の流れ』をシステム上に実装したもの」ということができます。 このようなシステムの作り方だと、他のシステムとの連携も、必要最小限しか考慮されないでしょう。部門内の業務をメインに考えられた「部分最適のシステム」ができあがります。 そうなると、顧客マスターの登録業務を会計部門でも営業部門でも製造部門でも行っていたりすることになります。 各々の部門が「顧客マスター」のデータベースを持ち、どれが本物のマスターなのかが分からなくなります。正確な顧客リストが出せなくなるわけです。 うっかりすると、各マスター間で互換性が無く、名寄せもできない、などということが起こっても不思議ではありません。 このように、お互いに連携が不足で、孤立化した状況を「システムのサイロ化」などと言います。サイロとは、北海道などに良くある、牧草を入れておく塔のような建物のことです。お互いに孤立してますよね。 サイロ化

16 Business Process Re-engineering
ビジネスプロセスの改善に注目 企業改革を目的としてビジネスプロセスを見直し ビジネスプロセスの視点で職務、業務フロー、管理機構、情報システムを再設計するという経営コンセプト ビジネスプロセスの考え方は1980年代に製造業の品質管理手法として考案されたシックスシグマが最初 1990年に元マサチューセッツ工科大学教授のマイケル・ハマー（Michael Hammer）がHarvard Business Review誌に論文を発表 BPRの原点は古典的なビジネス構造の否定 「重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直す」 1990年代終わりになると、非連続的な大改革が逆に大混乱を招く 1997年、MITシステムダイナミックス・グループが 「リエンジニアリングの70％は失敗」などと報告 BPRという考え方は、EAよりも少し後、1990年に元マサチューセッツ工科大学教授のマイケル・ハマーが発表した論文が始まりとされます。 ただ、ビジネスプロセスという考え方そのものの歴史はもう少し古く、1980年代にモトローラやGEなどが取り組んだ品質管理手法であるシックスシグマが取り入れたのが最初と言われています。 ハマーは、高度に専門化され、プロセスが分断された分業型組織に見られる職能別の古典的なビジネス構造を全面的に否定し、プロセス志向の新たな組織構造・価値観・評価システムをゼロから作り出すことを勧め、抜本的な変化を起こすための一連の手順としてBPRを考え出しました。 BPRの定義は「コスト、品質、サービス、スピードのような、重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス・プロセスを根本的に考え直し、抜本的にそれをデザインし直すこと」です。 これは要するに「既存のやり方は全部駄目」という考え方で、BPRの導入はまず既存のプロセスの破壊から始まったのです。 このため、BPRを導入しようとした企業の多くが「プロセスの見直しのしすぎ」で混乱に陥り、97年にはBPRの70%が失敗に終わったという報告が出されました。 しかし、逆に言えば30%の企業では効果があったとも言えます。業態や取り扱い製品の違いなどによるものなのでしょうが、BPRの考え方そのものが間違っていたわけではなく、やり方がよくなかったということでしょう。

17 ビジネスプロセス ひとまとまりの目的が定義できる 入力と出力がある 何度でも繰り返せる 販売管理のビジネスプロセス 効果が測定できる
受注 請求 入金 出荷 効果が測定できる 階層化されている ところで、ビジネスプロセスとは何か、というのは、実は大変に難しい問題なんですが、ここではあまり深いところまでは行かずに、ビジネスプロセスとは何かを考えて行きましょう。 例えば、とある企業における販売管理の業務プロセスを考える場合、こういった流れになったとします。受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 この販売管理プロセス自身、さらに細かいプロセスから構成されます。例えば、請求処理であれば、金額・納期の確認や請求書の発行、発送といったプロセスに分解できるでしょう。 一方で、このプロセスは、より上位のプロセスの一部でもあります。営業活動や製造・在庫管理などと連携しています。 ビジネスプロセスの要件としては、一連の作業をひとまとめにして、ひとつの目的を達成できること、というのがあります。 そして、情報の入出力があること。どういった情報が必要で、プロセスの終わりにどういった情報を出力するかを明確に定義できなければなりません。 さらに、必要な情報さえ揃っているならば、ビジネスプロセスの単位で独立してそれを繰り返すことができること。 硬化が測定できるというのは、アウトプットが明確でそれを定量化できるということです。 そして、ご覧のようにビジネスプロセスは階層化されています。 このように業務手順を分解してビジネスプロセスに落とし込むことにより、業務の流れが可視化され、繋がりが明確になり、どのような情報がどのように流れているのかがわかるようになります。 それらが明らかになることにより、ビジネス環境の変化が起きた場合に、どこを直せば良いかがすぐにわかり、変化に柔軟に対応できるようになります。 さらに、このようにビジネスプロセスを明確にしておくことにより、ITシステムへの実装がやりやすくなります。このあとお話しするSOAに結び着くわけです。 ビジネスプロセスを考えるときに特に難しいのが、どこまでをひとつのプロセスとして切り出すか、という「粒度」の問題なんですが、ITシステムとして考える場合には、開発するシステムの目的とか業務内容によって都度考えて行く、ということにしかなりませんので、ここでは突っ込みません。そここそが難しい、という問題はあるわけですけれども。 業務の流れ、繋がりを可視化 変化への柔軟な対応 ITとの連動 (SOA)

18 ビジネスプロセスの継続的な見直し ① ② ③ ① 受注 受注処理 生産 受注 受注処理 生産 例外処理 構成チェック 構成チェック
「望ましい」業務プロセス 書類 「望ましい」 業務プロセスでは効率が悪い 環境の変化により「望ましい」業務プロセスに戻す必要がある 受注 構成チェック 受注処理 生産 ① 問題 発生 例外処理 「修正した」業務プロセス 書類 しかし、ビジネスプロセスの見直しは、一回行ったらそれで終わり、ということにはなりません。具体的な例を挙げてご説明します。 ある製品の受注処理を行う場合の本来望ましい業務プロセスな上のようなものだったとします。 前提として、この製品は構成が難しく、きちんと動かすためには受注した構成を1度工場でチェックするのが望ましいとします。 またこの当時は本社と工場の間がオンライン化されておらず、校正チェックのためには受注書類を1度向上に郵送しなければならないとします。 このような場合受注して書類を工場にいったん送りそれがおおきであればもう一度本社に戻して受注処理を行った後に最終的に生産のためにもう一度工場に送るというプロセスになります。あまりやりそうにない話ですがビジネスプロセスをご理解いただくための例としてお考え下さい。 しかしこの書類のやり取りを郵送で行っていると、いかにも時間がかかります。そこでこの企業では、オーバーヘッドを減らすために、受注処理前の校正チェックを行わないというプロセスを考えました。受注書類を工場に送ると同時に、本社で受注処理をしてしまうのです。そうすれば書類を送るのは1階ですみます。 構成が間違っていた場合には、受注処理をやり直すことになりますが、その可能性が10分低い場合には有効な考え方です。 さて、時代が進み、本社と工場がコンピュータネットワークで接続されかとします。環境の変化です。この場合には書類のやり取りによる時間のロスが発生しませんから、本来望ましい業務プロセスに戻す必要があります。そうすれば例外処理もなくなり更に効率化望めるからです。 しかし大にしてこの望ましい業務プロセスの変更は行われないことが多いようです。業務プロセスの修正から時間が経ってしまうとなぜその業務プロセスを採用しているのか、誰も疑問を持たなくなりますし、過去の経緯を知っている人も少なくなってしまうからです。このため本来望ましい業務プロセスがあるにもかかわらず、効率の劣る業務プロセスを使い続けるという結果になってしまいます。 オーバーヘッド の低減 ネットワークの普及・高速化などの環境変化

19 BPRからBPMへ BPR BPM BPR継続のための仕組み 改善・再ち構築 分析 モニタリング 設計 実効 業務内容や業務構造・手順を
根本的に見直して売り上げの 拡大やコスト削減を目指す 一連の活動 これがBPRの問題点です。BPRはビジネスプロセスを根底から見直すと言う作業を行いますが、それを継続するという考え方が抜けていました。 これを改善したのがBPM、Business Process Managementです。 BPMではPDCAサイクルを回してBPRに継続的に取り組むための仕組みを作ることを要求しています。

20 Enterprise Resource Planning
EA→BPM→ERP 理念 Enterprise Architecture 巨大な組織(enterprise)の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論あるいは、そのような組織構造を実現するための設計思想・基本理念(architecture) 全体最適 プロセス ある仕事のスタートから完了までの流れを業務単位（プロセス）に分解して検証し、新しいプロセスが必要になった場合にもできるだけ他のプロセスに影響を与えないように挿入するなど、改善や再構築をしながら常に分析し、ビジネス効率を高めること。Enterprise Archtecture による全社的最適化との連携も重要。 分析 設計 実効 モニタリング 改善・再構築 BPM これまで話してきたように、EAは全体最適を目指すという「理念」です。 このEAの中の、ビジネスプロセスの見直しとそれを継続的に行う仕組みを取り入れた上で、EAが定める4つのアーキテクチャを定義し、全体最適なITシステムを開発するという考え方がERP、その考え方に基づいて構築されたシステムがERPシステムです。 つまり、全体最適なERPシステムの構築のためには、まず全社規模でのBPRを行い、それを元にアプリケーションアーキテクチャ、データアーキテクチャ、テクノロジアーキテクチャを作成することが必要になるということです。これは大変な作業です。 手法/ システム ERP Enterprise Resource Planning BPRに基づき全社最適化を行い、各業務システム間の連携まで含めてシステムを開発する考え方とそのための統合型パッケージ

21 開発と運用

22 アプリケーション開発・変更への迅速な対応 本番環境への迅速な移行・継続的デリバリー
なぜDevOpsなのか？ ビジネス・スピードの加速 アジャイル開発 Agile Development アプリケーション開発・変更への迅速な対応 eXtreme Programing,Scrum,Test Driven Development　など DevOps Development/Operation 本番環境への迅速な移行・継続的デリバリー Chef,Jenkis,Hashicorp　など 【図解】コレ１枚で分かるSDI 道路や鉄道、電気や電話、病院や学校など、私たちの生活や社会を維持する基盤を、インフラストラクチャー（インフラ）と呼んでいます。 クラウドやモバイルなど、ITサービスも、業務を処理するサーバー、データを保管するストレージ、通信を担うネットワーク機器、これらを設置するデータセンターなどのITインフラに支えられています。 ITインフラは、従来、ITサービス毎に、個別に調達・構築するものでした。しかし、このやり方では、変化の激しくなった市場に即応することはできません。また、不確実なビジネスの先行きを見通すことも難しく、必要となる機能や規模を予測することも困難です。 ITの需要が衰えることはありません。一方で、需要が読めないままのITインフラの調達・構築は、これまでに無く大きなリスクを伴うようになりました。 この状況を打破する技術として「仮想化」が注目されています。予め標準的な構成のITインフラを用意しておけば、そこから必要となるシステム資源を取り出し、自由に調達・構成できるソフトウェア技術のことです。 インフラを構成する全てのハードウェア資源に「仮想化」の技術を使えば、「ソフトウェアでシステム構成を設定、定義できるインフラ」が出来上がります。このようなインフラを「SDI（Software-Defined Infrastructure）」と言います。 SDIを使えば、サーバー、ストレージ、ネットワークのハードウェア、それ設置する設備、安定して稼働させる運用を気にすることなく、必要な時に、必要な構成で、その能力や機能を使えるようになります。これにより、ITインフラの調達や構築に掛かる時間は大幅に削減され、変更にも即応できるようになるのです。 このようなSDIを個々の企業で個別に構築することもできますが、それでは、各企業が膨大な設備投資を担わなくてはなりません。ならば、このSDIを複数の企業で共用すればいいわけです。例えば、私たちが電気を使うとき、発電所の設備や運用を気にすることがないように、そして、使った分を電気料金のように支払えているのと同じようにITインフラを使えれば、個々の企業が個別に大きな設備投資をしなくてもすみます。 そこで、SDIに、システム資源の使った分を計測し課金する機能や容易に使いこなすためのメニューを用意したサービスが登場しています。それが、パブリック・クラウドのひとつであるIaaS（Infrastructure as a Service）です。AWS（Amazon Web Services）やNTTコミュニケーションズのcloudn（クラウド・エヌ）、IBMのSoftLayerなどがこのサービスです。 もちろん、個別の構成や運用にこだわる企業は、独自にSDIを構築する場合もあります。このような仕組みをプライベート・クラウドと呼びます。そして、そんなふたつのSDIを組み合わせて、コストパフォーマンスの高いITインフラを構築しようというという使い方もあります。これをハイブリッド・クラウドと呼んでいます。 SDIは、こんなクラウド・コンピューティングを支える技術でもあるのです。 SDI Software Defined Infrastructure インフラ環境の迅速な調達・構築・変更 OpenStack,vCloud Air,Azure Stack　など

23 これからの「ITビジネスの方程式」 情報システムの 品 質 成　果 生産量 スピード 最大 ビジネス

24 不確実性のコーン 4.0x 倍の振れ幅 2.0x 16 1.0x 0.5x 0.25x プロジェクトフェーズ 見積金額の変動幅 システム企画
要件定義 基本設計 詳細設計 プログラミング 4.0x 　倍の振れ幅 2.0x 16 1.0x 0.5x 0.25x 初期の プロダクト定義 承認された プロダクト定義 要求仕様 設計仕様 詳細設計 研修された ソフトウエア スティーブ・マコネル著「ソフトウェア見積り 人月の暗黙知を解き明かす」

25 理想の結果 実際の結果 システム開発の理想と現実 品質 品質 納期 費用 納期 費用 品質の低下 納期とコストの厳守 Quality
Delivery 費用 Cost 納期 Delivery 費用 Cost

26 早期の仕様確定がムダを減らすというのは迷信
要求の信憑性 変化への即応と高い品質を両立する 「アジャイル開発」 への期待と関心が高まっている！ 要求変化の スピードが 加速 全ての要件をあらかじめ決めなくてはならない 「ウォーターフォール開発」 では、この変化への対応が難しくなってきた！ 経過時間

27 早期の仕様確定がムダを減らすというのは迷信
ほとんど／決して使われていない： 64% 常に／しばしば使われている： 20% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

28 ウォーターフォール開発とアジャイル開発（１）
動くソフトウェア ソフトウェアを使う ユーザー ユーザーは はじめて本気 リソース 開　発 テスト マジ 真面目に考える よく分からない 本気で検証 改修を要求 膨大なドキュメント 納期遅延 品質問題 要件定義 保守 時間

29 ウォーターフォール開発とアジャイル開発（２）
ソフトウェアを使う ユーザー リソース マジ！ マジ！ マジ！ マジ！ 動くソフトウェア を作り続けるれば ユーザーはずっと本気 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア マジ！ マジ！ マジ！ マジ！ マジ！ 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア マジ！ マジ！ マジ！ マジ！ マジ！ マジ！ 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア マジ！ マジ！ マジ！ マジ！ マジ！ マジ！ マジ！ 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 動くソフトウェア 時間

30 ウォーターフォール開発とアジャイル開発（３）
反復（イテレーション）1 要件 リリース Continues Integration 品質の作り込み 反復 2 設計 リリース 反復 3 コーディング 単体テスト 【図解】コレ１枚でわかるアジャイル開発 ユーザーの要求は時間とともに変化します。ビジネス・スピードが加速するなか、この要求が変化するスピードもまた速まっています。いま、情報システムの開発には、このような変化への即応性がこれまでになく求められているのです。 しかし、従来は、作るべきシステムの要件を「すべて」決めてしまってから開発をスタートする「ウォーターフォール」手法が主流でしたが、このようなやり方では対応できない事態も増えてきたのです。そこで、注目されているのがアジャイル開発です。 アジャイル開発の本質は、「全部作らない」ことです。これが、ウォーターフォール開発と本質的に異なる点です。アジャイル開発は、「業務上必要性が高い機能や業務プロセスを選別し、優先順位を決めて、そこにリソースを傾注することで、本当に使うシステムのみを作り上げよう」という考え方です。結果として、短期間、高品質での開発が実現するのです。 一方、ウォーターフォール開発は、「全部作る」を前提とします。そのため、ユーザーの要求がすべて決まらなければ開発に着手できません。そのため、将来使うかもしれない機能とともに、推測を交えて仕様を固めてゆきます。また、いったん作り始めると、途中で変更することは難しく、すべてを作り上げることが優先されます。変更や品質保証は全部コードを書き終えた最後の最後に対応しなければなりません。 アジャイル開発の手法を使っても、「全部作る」のであれば、ウォーターフォールと本質的には何も変わりません。アジャイル開発は「全部作らない」かわりに、短期間・高品質・変更への柔軟性を担保しようというもので、「全部作る」こととトレードオフの関係にあのです。 アジャイル開発では、「ビジネス価値の高い＝業務を遂行上必須」のプロセスを実現する機能に絞り込んで開発対象を決めてゆきます。「必要かどうかわからない」、「あったほうがいいかもしれない」は、作りません。そして、おおよその工数と期間の見通しを立てて開発を始めます。 ビジネス価値で優先順位を決められた機能を順次完成させてゆくため、途中で優先順位が変われば入れ替えることができるので、変更要求に柔軟に対応できるのです。 重要なところから完成させるので、重要なところほど早い段階から検証されバグは徹底して潰されます。また、後期になるほど重要度が低くなるので、問題が生じても全体への影響は少なく品質は高まります。 アジャイル開発の狙いを整理すれば、次の３つになるでしょう。 予測できない未来を推測で決めさせず、本当に使うシステムだけを作ることでムダな開発投資をさせない。 変更要求に柔軟に対応し、納得して使えるシステムを実現する。 納得できる予算と期間の中で最善の機能と品質を実現する。 そもそもアジャイル開発が生まれるきっかけは、1986年に日本の経営学者である野中郁次郎氏と竹内弘高氏が、日本の製造業の高い生産性と効率を研究した論文をハーバード・ビジネスレビュー誌に掲載したことにあります。それを読んだジェフ・サザーランド（Jeff Sutherland）氏らが、システム開発への適用を考え、1990年代半ばにアジャイル開発の方法論としてまとめました。ですから、アジャイル開発には、伝統的な日本の「ものづくり」にある、「不断の改善により、品質と生産性の向上を両立させる」という精神が、埋め込まれているといっても良いでしょう。 リリース 最初に要件をあらかじめ 全て決めてから開発 反復 4 結合テスト ビジネス上の重要度で要件の優先順位を決め、これに従って必要機能を順次開発 リリース リリース

31 ウォーターフォール開発とアジャイル開発（５）
「MVP（Minimum Viable Product：仮説を検証することができる最低限のプロダクト）」かつ、ビジネス価値の高い機能・プロセスを優先して開発する。 ◎ 〇 △ Ｘ 反復　１　ビジネス価値　◎ 反復　２　ビジネス価値　〇 反復　３　ビジネス価値　△ 反復　４　ビジネス価値　Ｘ 31

32 ウォーターフォール開発とアジャイル開発（６）
要求仕様 リソース 納期 前提条件 プラン ドリブン型 バリュー ドリブン型 コストと納期を守ること 機能と品質を実現すること リソース 納期 ゴールは何か？ 実現仕様 ウオーターフォール アジャイル リスク 要件 設計 コーディング 単体テスト 結合テスト 原理的に 不良が起きない 納期が守られる リスク 反復1 反復2 反復3 反復4 時間 時間 32

33 DevOpsの目的 従来型のアプローチ 業務上必要とされるであろう全ての機能を実装 これからのアプローチ
機能開発・単体テスト （受注処理） 物理マシンに依存 機能開発・単体テスト （出荷処理） 結合テスト 移行 稼働 運用 機能開発・単体テスト （元帳管理） これからのアプローチ ビジネス価値が高く実際に使うプロセスのみ実装 プロセス開発・テスト （受注〜出荷） 運用 プロセス開発・テスト （請求処理） 運用 Continuous Delivery ビジネス価値の迅速な提供 プロセス開発・テスト （例外処理） 運用

34 Infrastructure as Code
DevOpsの目的 これからのアプローチ ビジネス価値が高く実際に使うプロセスのみ実装 プロセス開発・テスト （受注〜出荷） 運用 プロセス開発・テスト （請求処理） 運用 Continuous Delivery ビジネス価値の迅速な提供 プロセス開発・テスト （例外処理） 運用 アジャイル開発 ビジネス・プロセス単位で開発 価値の高いプロセス順に順次開発・リリース ビジネス価値をいち早く実現する コンテナ仮想化 インフラ依存をなくし動作を保証 仮想マシンより小さいサイズ 開発から本番以降への時間を短縮 クラウド コンピューティング DevOps Development + Operation Infrastructure as Code 変更への即応性を確保 移行・稼働を迅速・確実に実施 テストと本番の環境差を無くす

35 DevOps（Development + Operation）
反復1 要求 設計 開発 反復2 要求 設計 開発 Continuous Integration 反復3 要求 設計 開発 企画 要求 設計 開発 移行 稼働 運用 EOL 企画からEOL迄、一貫したプロセスの見える化と管理 ITサービスを提供する関連情報の一元化（共有化） Build, Test, Deployの手順化＆自働化の検討 Continuous Delivery DevOps（Development + Operation） 一個流し 移行 稼働 運用 開発と運用の同期化ができなければ、 ビジネス・スピードに追従できない 【図解】コレ1枚でわかるDevOps 業務システムは、当初の仕様通り完成させて完結するものではありません。使っているうちに不具合が見つかることもあるでしょう、あるいは、業務手順の変更や新たなニーズに対応するために修正や機能追加が必要になることもあります。 不具合が見つかり対応すること、あるいは、業務手順を見直しシステム・ロジックを変更することは、ビジネスを健全に機能させ、さらに売上を伸ばし、お客様の満足度を高めるためには、即応できてしかるべきです。 しかし、開発チームは、他にもバックログを抱え、その要望にすぐに応えることはできません。また、仮にプログラムの開発や修正ができても、不慮の操作によるシステム障害を避けるため、開発チームには本番システムを操作する権限を与えられていないのが一般的です。 システムを操作する権限を持つのは、安定的にシステムを稼働させる役割を担う運用チームです。開発チームが変更を本番システムに反映するためには、運用チームに依頼しならないのです。しかし、運用チームは、多くの業務システムを少人数で対応していることが多く、全ての要望に直ちに応えることができません。また、安定稼働のために、頻繁にシステムを変更することを嫌います。 このような両者の対立が、ビジネスの柔軟性とスピードを阻害することになります。 そこで重要になるのが、開発(Development)と運用(Operation)の連携を強化し、一体となって運営するための取り組みです。これを「DevOps」と呼んでいます。 以前紹介したアジャイル開発は、ビジネス・ニーズの変化に即応し業務システムを開発あるいは、修正するための取り組みです。しかし、運用チームが開発あるいは修正されたシステムを本番システムに直ちに反映できなければ、ビジネス上の効果をいち早く享受することはできません。この事態に対処するためには、開発したシステムを直ちに本番システムに反映するための開発チームと運用チームの役割の見直し、あるいは、開発者自身の判断で本番システムに移行しても障害を起こすことなく安定運用が担保できる仕組み作りが必要になります。 「DevOps」は、このような一連の取り組みにより、ビジネス・ニーズに即応して開発したシステムの本番への移行を不断に繰り返してゆく「継続的デリバリー（Continuous Delivery）」の実現を目指しているのです。 継続的デリバリーとは、ビジネス・ニーズにいち早く対応し、変化にも即応できるアジャイル開発の「反復型の開発（Iterative Development）」や「継続的インテグレーション（Continuous Integration）」と、本番システムへの移行を開発・テスト後、直ちに行えるようにする「継続的デプロイ（Continuous Deployment）」の組合せと言えるでしょう。このような仕組みを実現することで、ビジネス・ニーズに即応できるシステムが実現できるのです。 ITがもはやビジネスの前提となりつつある中、ITの即応力はこれまでにも増して重要視されるようになりました。その意味からもDevOpsへの取り組みは、その必要性を高めてゆくことになるでしょう。

36 システム資産・運用の歴史的変遷 自社資産・自社運用 SaaS PaaS PaaS IaaS サービス・運用委託 1960〜 2010〜
ビジネス・プロセス ビジネス・プロセス ビジネス・プロセス ビジネス・プロセス データ データ データ データ アプリケーション アプリケーション アプリケーション アプリケーション SaaS API プラットフォーム プラットフォーム PaaS PaaS インフラストラクチャ IaaS サービス・運用委託 1960〜 2010〜 2015〜 2016〜

37 APIエコノミー（1） API API アプリケーション プログラム アプリケーション プログラム サービス サービス
プログラムの機能を呼び出し、その実行結果を戻り値として受け取る アプリケーション プログラム 　　　　 アプリケーション 　　　　プログラム APIの呼び出し API Application Program Interface 戻り値の返信 お店やプレイスポットを検索するFoursquareで取得した位置情報を Uberに送りタクシーを配車してもらう。 サービスの機能を呼び出し、その実行結果を戻り値として受け取る サービス サービス APIの呼び出し API Application Program Interface 戻り値の返信

38 APIエコノミー（2） サービス サービス サービス サービス サービス サービス サービス サービス Foursquare+Uber
独自機能 独自機能 独自機能 Foursquare+Uber 会計管理+地方銀行 自動車会社+損害保険 FoursquareからUberで車を手配 観光地での迅速な配車サービス リアルタイムの会計情報で与信 中小企業への迅速な融資 運転の丁寧さで保険料率を変動 支払リスクの低減と事故の削減

39 API Gatewayサービス API Gatewayサービス APIの作成 APIの配布 APIの保守 APIの監視 APIの保護
IBM サービス サービス サービス API API API API Gatewayサービス APIの作成 APIの配布 APIの保守 AWS APIの監視 もちろんAmazonも、APIに注目しています。IBMとよく似たサービスの提供を始めました。 APIの保護 API API API サービス サービス サービス

40 ネットコマース株式会社 180-0004 東京都武蔵野市吉祥寺本町2-4-17 エスト・グランデール・カーロ 1201
　東京都武蔵野市吉祥寺本町2-4-17 エスト・グランデール・カーロ 1201