FinTechの鍵を握る2つの技術 - Nomura Research Institute

2016
Vol.33 No.08
(通巻 392 号)
視
点
08
注目したい API とブロックチェーン
北川 園子
特集
FinTechの鍵を握る2つの技術
金融分野の API エコノミー
─ オープン API が生み出す革新的なサービス ─
遠藤 圭 介 、高 橋 寛
ブロックチェーンは社会に何をもたらすか
─ 新しいビジネスインフラとしての期待 ─
冨樫 寛 隆 、西 片 健 郎
トピックス
サプライチェーン・デザインのすすめ
─ ビッグデータを活用したシナリオ・シミュレーション ─
疋田 時 久
同時並行型プロジェクトの落とし穴
─ 事例に学ぶプロジェクト運営の勘所 ─
江原 信 一
データセンターネットワークの次なる姿
─「マルチ・クラウド・ファブリック」の実現へ ─
横島 孝 史
海外便り
グローバル・リモートワーク時代のチーム運営
─ 相互理解と連帯感を生み出すための取り組み ─
宮田 友 朗
Adobe Reader のメニューバーで「表示(V)→ページ表示(P)
」にある「見開きページ(U)
」と「見開きページモードで表紙をレイアウト(V)
」の 2 か所にチェックすると紙面
のイメージでご覧いただけます。また、両面プリンターをご使用の場合、印刷時に「ページの拡大/縮小(S)
」で「小冊子の印刷」を選択すると紙面に近い状態を再現できます。
2016
Vol.33 No.08
(通巻 392 号)
08
視点
注目したい API とブロックチェーン
04
北 川 園子
特集
FinTech の鍵を握る 2 つの
技術
金融分野の API エコノミー
……………………………………………………………
─ オープン API が生み出す革新的なサービス ─
06
遠 藤 圭 介 、高 橋 寛
金融分野におけるオープン API への注目が高まっている。標準化団体の設立や政策レベルでの議論も進んでいる。
本稿では、金融機関においてオープン API を提供するために求められる要素を概説しつつ、オープン API をどう
活用し、どのようにビジネスに生かしていくべきか考察する。
ブロックチェーンは社会に何をもたらすか
─ 新しいビジネスインフラとしての期待 ─
…………
10
冨 樫 寛 隆 、西 片 健 郎
FinTech の主要技術として世界的に注目され、実証実験も多数行われているブロックチェーンだが、実用化の事
例がまだ少ないことから、どのような変化を起こすものなのかは明らかでない部分が多い。本稿では、ブロック
チェーンの活用方法と普及に向けた課題、その解決に必要な取り組みについて考察したい。
C o n t e n t s
トピックス
サプライチェーン・デザインのすすめ
………………………………………
─ ビッグデータを活用したシナリオ・シミュレーション ─
14
疋田 時久
市場への対応能力を増強し競争優位を築くために、従来の「サプライチェーン・マネジメント(SCM)」から、サプライチェー
ンそのものをダイナミックに再設計する「サプライチェーン・デザイン」へと、取り組みのかじを切ることが必要である。
本稿ではその概要と、欧米の製造業において活用が始まっているサプライチェーン・デザイン・ツールの可能性を考察する。
同時並行型プロジェクトの落とし穴
……………………………………………
─ 事例に学ぶプロジェクト運営の勘所 ─
18
江原 信一
基幹業務システムの老朽化対応などに伴い、複数のシステム構築プロジェクトを同時期に立ち上げるもその運営に苦戦し
ているという話を聞くことが多い。本稿では、プロジェクト支援の経験から複数プロジェクトを同時並行で進める際のプ
ロジェクト運営の勘所について考察したい。
データセンターネットワークの次なる姿
………………………………
─「マルチ・クラウド・ファブリック」の実現へ ─
22
横島 孝史
仮想化の波はデータセンターネットワークにも押し寄せている。仮想化により物理的な制約から解放され、通信のソフト
ウェア制御が可能になれば、システム要件に迅速かつ柔軟に対応することはさらに容易になる。本稿では、ネットワーク
仮想化の動向を紹介し、仮想化に適したネットワークの在り方について考察する。
海外便り
グローバル・リモートワーク時代のチーム運営
─ 相互理解と連帯感を生み出すための取り組み ─
…………
24
宮田 友朗
グローバル化の進展により、言語や文化が異なる複数の国のメンバーの協業を必要とするプロジェクトが増えている。そ
のようなプロジェクトを成功させるためには、利便性の高い IT の活用に加えて、メンバーが互いに相手の個性や文化的背
景などを理解し、連帯感が生み出されるようにするチーム運営が求められる。
視点
注目したい API と
ブロックチェーン
野村総合研究所 経営役
証券ソリューション事業本部 統括部長
きたがわ
そ の こ
北川 園子
スマートフォンやタブレット端末などの普
のオンライン投資ファンド(個人投資家向け
及、Web 技術やデータ処理技術の高度化に
のファンド自動買い付けサービス)
「余額宝」
より、金融サービスのイノベーションが進ん
が、1 年もたたないうちに残高で中国最大の
でいる。今、それを担っているのが FinTech
ファンドとなった。
(
「金融」と「技術」の融合を意味する造語)と
日本では、モバイルを利用した PFM サー
呼ばれるサービスである。
ビスが利用者数を伸ばしている。また、資産
モバイル決済、Web 上での個人間送金、
管理型営業を強化することを目的に、富裕層
PFM(Personal Financial Management。個
やマス富裕層への顧客接点としてロボアドバ
人財務管理と訳され、複数の銀行・証券やク
イザーを活用する事例が見られる。
レジットカードなどの口座情報を一元的に確
04
認できるオンラインサービス)、ロボアドバ
FinTech は金融サービスにどのような変化
イザー(オンラインで簡単な質問に答えるだ
をもたらすだろうか。
けで、その人に合った資産運用の提案などを
簡潔に言えば、「提供者視点の金融サービ
受けられるサービス)など、FinTech にはさ
スから利用者視点の金融サービスへの転換」
まざまなサービスがある。米国では P2P レ
である。これまで、利用者は複数の金融機関
ンディング(お金を借りたい人と貸したい人
を使い分けるのが普通で、それによって送金
を Web サイト上で結び付ける融資サービス)
や決済に際して手数料を徴収され、手間も強
も行われ、融資希望者の与信審査を取引デー
いられてきた。資産が全部でいくらあるかを
タなどのビッグデータを用いて自動化し、審
オンラインで確認しようと思えば、各金融機
査期間を大幅に短縮している事例もある。
関の Web サイトに個別にアクセスする必要
米 国 で は 2015 年 に こ う し た FinTech ス
があった。
タートアップ企業への投資規模が 200 億ド
FinTech サービスはこのような利用者のス
ルを超えた(米国 CB Insights 社などのデー
トレスを解消する。資金移動は低コストでで
タに基づき NRI アメリカ推計)
。金融機関の
き、複数の金融機関に預けた資産の情報はま
ビジネスやサービスを変革するニーズがいか
とめて画面に表示されて確認が容易になる。
に強いかを表す数字である。
これまでも、大手電子商取引サイトや大手金
中国では、電子商取引大手のアリババ集団
融機関グループでは、グループ内での資金移
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
動に際して利用者に便宜を図ってきたが、そ
ン・ジャパン」では、NRI などが発起人となっ
れは自社グループへの囲い込みのためであ
て金融 API に関するワーキンググループを設
る。今後は、利用者視点のサービスの形とし
置し、API 仕様の検討や安全な公開の仕組み
て、グループや業態を超えた企業の提携が増
づくりに取り組んでいる。
えていくと考えられる。
API 公開に関する検討事項、セキュリティ
利用者が金融機関を選ぶ条件も変化するは
や標準化の取り組みについては今号の特集を
ずである。ネット社会では店舗の立地や規模
参照していただきたい。
はそれほど重要ではない。金融機関にとって
は、いかに利用者と “つながる” サービスを
FinTech におけるもう 1 つの重要な技術基
提供できるかが重要になる。
盤として注目されているのがブロックチェー
ンである。
では、利用者視点のサービスを提供するた
中央機関で全てのデータを管理するのでは
めに金融機関はどう変わるべきなのか。まず
なく、取引などの参加者がネットワーク上で
は自らのビジネスを再定義し、強みとなるコ
台帳を分散管理できることから、低コストで
ア機能をプラットフォーム化することによ
効率的なインフラを構築する技術として期待
り、戦略的に外部サービスと “つながる” 必
されている。ビジネス面でも、中央機関を必
要がある。この “つながり” を可能にするの
要とせずに所有権の移転や証明が可能となる
が API(Application Programming Interface。
ため、広い分野で新しいビジネスやサービス
ソフトウェアの機能を別のソフトウェアから
が生まれる可能性がある。NRI では、証券市
呼び出すための接続仕様)のビジネスプラッ
場へのブロックチェーン適用の有用性と課題
トフォームである。
を評価するため、日本取引所グループと共同
金融機関は、人が日常的に利用するアプリ
で 2016 年 4 月から実証実験を行っている。
や Web サイトを通じて、API を利用してその
今号の特集では、海外の事例や実用化の課
人を自社とつなげることができれば、それは
題について解説されているので、ぜひご覧い
大きな集客のツールとなる。そのため、金融
ただきたい。
機関はコア機能を分割して API を外部に提供
することで、サービス強化を図っていくよう
FinTech は、IT による効率化ではなく、金
になると思われる。
融ビジネスの変革が焦点である。金融機関
政府でも、決済サービスの高度化を目指し
にとっては、自らのビジネスを再定義し、
て 2015 年から金融サービスの API 公開が検
FinTech をどこにどう組み込むかがポイント
討されている。セキュリティなどの課題は
となる。また利用者にとっては、FinTech は
あるものの、近い将来には金融機関の API 公
金融サービスを飛躍的に身近で便利なものに
開が一般的になるだろう。野村総合研究所
すると考えている。それによって「貯蓄から
(NRI)も参加する「OpenID ファウンデーショ
投資へ」の流れも促進されることだろう。■
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
05
特 集
FinTech の鍵を握る 2 つの技術
金融分野の API エコノミー
─ オープンAPI が生み出す革新的なサービス ─
金融分野におけるオープンAPIへの注目が高まっている。標準化団体の設立や政策レベルでの議論も進んでいる。
本稿では、金融機関においてオープン API を提供するために求められる要素を概説しつつ、オープン API をど
う活用し、どのようにビジネスに生かしていくべきか考察する。
野村総合研究所 証券ソリューション事業本部
証券システムプロジェクト部
グループマネージャー
えんどう
06
けいすけ
野村総合研究所 証券ソリューション事業本部
証券システムプロジェクト部
上級システムエンジニア
たかはし
ひろし
遠藤 圭介
高 橋 寛
専門は Web システムのデザイン・設計・構
築
専門は金融分野のフロントシステムの企
画・開発
オープン API と API エコノミー
金融分野のオープン API の動向
API(Application Programming Interface)
金融分野でも、決済サービスの API 公開に
とは、あるソフトウェアが別のソフトウェア
向けた動きが活発化している。
の機能を呼び出して利用するための接続仕様
EU(欧州連合)では、銀行などの決済サー
である。
ビス関連事業者に関する資本要件や情報提供
従来、API は企業内やグループ企業内の異
義務などを定めた「決済サービス指令」が
なるシステムを連係させることを目的として
2007 年に策定されているが、これを改正す
利用するものが大半であった。しかし近年で
る新指令が 2015 年 11 月に EU 理事会で採択
は、インターネットの普及を背景に、Web
された。改正によって銀行は API 公開の義務
上のさまざまなサービスをつなげる仕組み
を負ったことになり、EU 加盟国は 2 年以内
として Web API が台頭してきた。この Web
に国内法を整備することを求められている。
API を外部に向けて公開したものを「オープ
日本では、2015 年末に金融庁の金融審議
ン API」と呼ぶ。
会が「決済業務等の高度化に関するワーキン
サービス事業者は、API を公開することに
グ・グループ報告~決済高度化に向けた戦略
よって他の事業者を呼び込み、サービスを拡
的取組み~」を公表し、「金融機関・IT 関係
大したり新しいサービスを生み出したりする
企業・金融行政当局等の参加を得て、セキュ
ことが可能になる。さらに、複数の事業者が
リティ等の観点から、オープン API のあり
競争することによって、サービスもより価
方を検討するための作業部会等」を設置し、
値の高いものになる。このように、オープ
2016 年度中をめどに報告を取りまとめると
ン API を利用してビジネスとビジネスをつな
している。このような政策の後押しを受け、
ぎ、新しい価値を生み出すことを「API エコ
オープン API の動きは金融業界でも加速度的
ノミー」と呼ぶ。
に広がっていくだろう。
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
証情報を第三者である
図 1 スクリーンスクレイピングの仕組みとリスク
サービス利用者
サービス提供者
資産管理サービス画面
XX さん
金融機関
サービス利用者に変わり
Webサイトにログイン
A 銀行
B 証券投信
50 万円
A 銀行
B 証券株式 200 万円
150 万円
複数金融機関の認証情報
(ユーザー ID・パスワード)
を
資産管理サービスに登録
XX 様
A 銀行 本店
200 万円
XX 様 aaa/bbb
スクレイピング
XX 様 A銀行 aaa/bbb
サイバー攻撃の標的
パスワードの漏えいリスク
ティ対策が十分でない
場合、情報漏えいにも
B 証券
オンライントレード画面
XX 様 B証券 ccc/ddd
することになる。サー
ビス提供者のセキュリ
ネットバンキング画面
サービス利用
サービス提供者が保有
XX 様
B 証券ネット支店
株式 150 万円
投信 50 万円
発展しかねない。
API を公開すること
XX 様 ccc/ddd
: ユーザー ID・パスワード
はリスクがあると捉え
られているが、API を
公開しない場合でも、
API を公開しない場合のリスク
自社の顧客をセキュリティ上の危険にさら
日本では、複数の銀行口座の残高をまとめ
FinTech サービスが活況になるにつれ、さら
て見ることのできる資産管理サービス(家計
に増加していくのである。金融機関にとって
簿アプリ)や決済サービスといった FinTech
も安全な API を公開する必要がある。
すリスクを負うことになる。このリスクは、
サービスが世間をにぎわせている。これらの
サービスでは、API を公開していない金融機
関の情報も利用されている。
これは、金融機関の Web ページの HTML
安全性を高めるために有効な
OAuth2.0 と OpenID Connect
情報を解析し、必要なデータを抽出する「ス
API を利用するためには一般的に認可を受
クリーンスクレイピング(以下、スクレイ
ける必要がある。認証と認可は混同されがち
ピング)
」という方法により実現されている
だが、認証は「本人であること」を意味し、
(図 1 参照)
。金融機関にとって、外部に API
認可は「使用する許可」を意味する。API
を公開することなく機能を提供できるスクレ
利用時にサービス提供者が認証情報を保持
イピングはオープン API と同様の役割を果た
せず、認可情報(以下、アクセストークン)
しているように見えるが、情報漏えいのリス
を安全に受け渡す仕様を定義しているのが
クを伴う。
「OAuth2.0」である(次ページ図 2 参照)。
スクレイピングを用いたサービスの場合、
この方法では、サービス提供者はアクセス
サービス利用者はサービス提供者に Web サ
トークンをサービス利用者に開示することな
イトの認証情報を提供する必要がある。サー
く受け取り、API を利用して目的のデータを
ビス提供者は、その認証情報を利用して本人
取得することが可能となる。アクセストーク
に代わって目的のデータにアクセスする。こ
ンが漏えいするリスクは残るが、認証情報で
れを金融機関から見ると、自社の顧客の認
はないため金融機関の Web サイトに直接ロ
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
07
特 集
FinTech の鍵を握る 2 つの技術
グインすることはできない。
図 2 OAuth2.0 と OIDC を用いた認証・認可のフロー(資産管理サービス)
金融機関が公開する API は、個
サービス利用者
人を特定した資産情報などのデー
は API を呼び出す際に個人を特定
する必要がある。この場合には
OpenID Connect(以下、OIDC)
を利用する。
OIDC は、OAuth2.0 の認可仕様
金融機関
金融機関サービスを登録する
許可取得依頼 認証結果提供依頼※
タ取得を目的としたものであるた
め、サービス提供者(API 利用者)
サービス提供者
「OAuth2.0」
アクセストークンを
サービス提供者に
提供するフロー
「OIDC」
本人確認要求
(金融機関ログイン画面表示)
本人確認情報入力
(金融機関ユーザー ID・パスワード)
ユーザー ID・パスワード照合
利用許可要求
(利用許可画面表示)
利用許可同意入力
OAuth2.0 を
認可コード返却 ※認可コードは有効期限が短い
拡張し、
ユーザー認証
結果の依頼・提供を
規定したフロー
アクセストークン取得要求
(認可コード付与)
※OIDC で追加され
る処理
金融機関サービス登録完了
に認証の仕様を組み合わせたもの
である。本人を特定することで、
トークン保存
アクセストークン返却
ID トークン返却※
API
金融機関サービスを利用する
API 呼び出し(アクセストークン付与)
アクセストークン照合
利用時
取得情報表示
API 応答
アクセストークンを誰に対して発
行したかを特定できるため、より安全な仕組
みとなる。現時点では、この OIDC の仕様に
表 1 オープン API 導入・運用時の検討事項
導入時
準拠することが、金融分野におけるオープン
API には有効な対応である。
API 利用規約、ポリシー管理
(サービス規約・ルール等)
API 仕様公開、テスト環境の提供
オープン API の普及に向けて
08
運用時
トークンの管理
認証、認可機能の構築
(不正アクセス防止や漏えい時
(OAuth2.0、OIDC への準拠)
の無効化対応等)
(開発者向けポータルサイト)
課金方式
API のバージョン管理
(新旧の並存)
API 利用証跡の把握、管理
継続的なセキュリティ対策
(新たな脅威への対応)
オープン API が普及するためには、サービ
証・認可についての具体的な検討はこれから
ス提供者(API 利用者)の利便性向上ととも
という状況である。そこで「OpenID ファウ
に、金融機関(API 提供者)の運用負荷を低
ンデーション・ジャパン」は「Financial API
く抑えることが重要である。
Working Group」
(以下、WG)を設置し、金
サービス提供者の利便性を向上させるた
融機関の口座情報に対する API 仕様を規定す
めには、API 仕様の標準化が必要である。金
るとともに、OAuth2.0 および OIDC の適用の
融機関が各社独自に仕様を決めてしまうと、
標準化を進めている。野村総合研究所(NRI)
API を利用する事業者はそれぞれの仕様に対
は WG の発起人の筆頭として活動している。
応しなくてはならなくなり、コストがかか
表 1 は、金融機関がオープン API を導入・
る。標準仕様を定義することで、複数の API
運用するために検討すべき事項を整理したも
も低コストで利用することが可能となる。
のである。導入時、運用時ともに検討事項が
API の標準仕様には米国の「FS-ISAC」(金
多くあり、API を公開する仕組みを独自に構
融機関の情報共有を目的とした組織)によ
築すると、金融機関の導入コストが膨らむ。
る「Durable Data API」 な ど が あ る が、 認
また、標準化の動きや法制度にも柔軟に対応
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
API 提供者
トランザクション
課金モデル
コミッションモデル
プロフィットシェア
モデル
では、FinTech サービ
API 利用者
サービス提供者
スが、金融機関の口座
【金融機関】
・投資情報 API
・資産情報 API
【FinTech サービス】
・自社サービスの向上
【金融機関】
・口座開設 API
【FinTech サービス】
・金融機関への集客 /
送客による収益源
対価を得ることができ
【金融機関】
・取引 API
・投資一任契約 API
【金融機関】
・自社サービスの向上
ルでは、グループ企業
【金融機関】
・銀証連携 API
(リアルタイム
資金移動)
【FinTech サービス】
・革新的なサービスの
創出
・類似サービスの登場
【FinTech サービス】
・新サービス API
【FinTech サービス】
・旧サービスの淘汰
開設 API を利用して金
融機関へ送客し、その
る。フリーミアムモデ
が相互の API を利用す
│ オ ー プ ン A P Iが 生 み 出 す 革 新 的 な サ ー ビ ス │
フリーミアムモデル
金融分野のAPIエコノミー
コミッションモデル
図 3 API エコノミーのビジネスモデル
ることで資産情報を一
サービスの
登場と淘汰を
繰り返す
度に照会できるように
したり、株取引アプリ
上にリアルタイムの入
し、安全な状態を維持する必要がある。API
金機能を実装したりすることも可能である。
公開を支援する製品も提供されており、これ
金融機関が安全な API を公開することに
を利用することも選択肢の 1 つである。
より、FinTech 推進の原動力となる新興企業
を自社の API エコノミーに呼び込むことがで
API エコノミーがもたらす
新たな競争
きる。金融機関同士が API を相互に利用す
ることで新たなサービスを生み出すことや、
FinTech サービスがユーザーインターフェー
金融機関のオープン API と FinTech サービ
スに優れたフロントサービスを担うことも考
スによって実現されるビジネスモデルは、大
えられる。こうしてさまざまな FinTech サー
きく 4 つに分けられる(図 3 参照)。
ビスが登場・淘汰を繰り返し、サービスその
①トランザクション課金モデル
ものが洗練されていく。
API の利用件数や対象とするサービス利用
オープン API がもたらす新たな競争は既存
者数に応じて、API 利用者に課金する。
サービスを衰退させる要因にもなり得るが、
②コミッションモデル
それ以上に革新的なサービスを生み出す起爆
①とは逆に、API 利用者がサービス提供を
剤となる。金融機関が自社だけでは生み出せ
実現した場合に報酬を支払う。
ない革新的なサービスを迅速に提供し、顧客
③プロフィットシェアモデル
満足度を高めるためには、従来と同じやり方
API の取引における利益を分配する。
では難しい。来るべき API エコノミー時代に
④フリーミアムモデル
向け、金融機関も自社ビジネスの API 公開に
双方のチャネルを拡大するため、基本的に
向けた取り組みを具体的に検討する時期にさ
無料で API を公開する。
しかかっていると言えるだろう。
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
■
09
特 集
FinTech の鍵を握る 2 つの技術
ブロックチェーンは社会に何をもたらすか
─ 新しいビジネスインフラとしての期待 ─
FinTech の主要技術として世界的に注目され、実証実験も多数行われているブロックチェーンだが、実用化の
事例がまだ少ないことから、どのような変化を起こすものなのかは明らかでない部分が多い。本稿では、ブロッ
クチェーンの活用方法と普及に向けた課題、その解決に必要な取り組みについて考察したい。
野村総合研究所 証券ソリューション事業本部
事業企画室 主任
と が し
ひろたか
野村総合研究所 証券ソリューション事業本部
事業企画室 副主任
にしかた
た け お
冨樫 寛隆
西片 健郎
専門は金融・証券ソリューションの企画
専門は金融・証券ソリューションの企画
注目を集めるブロックチェーン
性を開いた。この可能性は広範な産業にバ
ブロックチェーンは仮想通貨ビットコイン
らすと考えられ、多様な観点から研究、実験
を支える技術として登場したもので、分散台
が進められている。
リューチェーン(価値の連鎖)の変化をもた
帳とも呼ばれる。インターネットのような信
頼のおけないネットワーク上で、全てのコン
ピュータ(ノード)がそれぞれに台帳を保有
10
世界中で模索される活用方法
し、あるノードが価値の移転を自身の台帳へ
ビットコインが銀行を介さない送金を可能
記録すると、その記録が全てのノードで検証
にしたように、証券や不動産、貴金属などの
されて台帳へ反映される仕組みである。取引
価値を、信用のある中央機関なしに証明、交
はブロックという単位にまとめられ、ブロッ
換可能とするビジネスモデルが世界中で模索
クはチェーン状に順次追加されていく。改ざ
されている。活用分野は表1のとおり広範で、
ん、なりすまし、二重使用を防止する仕組み
取り組みの規模も以下に示すように大小さま
が組み込まれているため、ネットワークの参
ざまである。
加者は分散台帳を信頼することができる。
①企業内での取り組み
現在、世界中の国や企業がこの仕組みに注
技術理解を主な目的とした自社内での試行
目している。その最大の理由は、既存の台帳
的な取り組みが多い。
管理の方法を大きく変える可能性があるため
米国の大手銀行 BNY Mellon 社は、独自の
である。従来は、信用のある中央機関が全て
「BK コイン」を行内で発行する実験を実施し
の取引履歴を持つ台帳を集中管理することに
ている。「BK コイン」は従業員向け表彰制度
よって信頼性を保証してきた。しかしブロッ
で特典として使われるもので、制御が容易な
クチェーンは、中央機関の集中管理を必要と
行内という環境で実証実験を行い、今後のビ
せずに、信頼のおける台帳管理を行う可能
ジネスに向けて技術への理解を深めることを
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
表 1 ブロックチェーンの活用方法
送金・決済
デビット
証券・デリバティブ
銀行間の大口送金、海外送金
デビットカードとビットコインウォレットの双方向利用(ビットコインウォレットからデビットに必要額をロードなど)
証券の発行、清算・決済にブロックチェーンを利用
保険
P2P で運営される失業保険をスマートコントラクト(契約の自動化)を通じて提供
貸金
スマートコントラクトを用いてコミュニティー内にデポジットした資金を用いてファイナンスを実行
IoT
家のセンサーが問題を検知するとブロックチェーンにレポートを記録し事前に定めた修繕の注文・支払いを実行
ギフトカード・チケット
リワード
音楽
シェアリング
エネルギー
ゲーム内資産
マーケットプレイス
SNS
土地登記・婚姻・出生
投票
ID
学位
医療情報
サプライチェーン
宝飾品・美術品
ギフトカードの発行・送信・交換などをブロックチェーン上で実施
コンテンツ購入時にマイクロペイメント(小額決済)を用いてアーティストへ報酬を直接届ける
ブロックチェーンベースの P2P 音楽プラットフォーム
ソーラーパネルによる余剰電力を近隣住民同士で直接売買
ビットコインで全世界から電気代を受け取り、使用量をブロックチェーンに記録し代金を支払うスマートメーター
ゲームストーリーとゲーム経済にビットコインとブロックチェーンを組み込んだトレーディングカードゲーム
P2P マーケットプレイスでビットコインとモノやサービス、デジタルコンテンツの交換を安全に行える市場を目指す
独自コインのウォレットを組み込んだメッセンジャーアプリ
政府により提供されてきた土地・不動産登記、婚姻・出生届などの契約をブロックチェーンに記録
投票参加者による投票結果に基づき政治活動を実施
パスポートや免許証、車や家の鍵など各種サービスへのアクセスコントロールに利用するデジタル ID サービス
ブロックチェーン上で学位を発行し、その書類へのタイムスタンプおよび実在を証明
DNA 情報のバックアップをデータに変換しブロックチェーン上に記録
原材料や農作物のサプライチェーンを記録することで消費者に商品の信頼性・透明性を提供
ダイヤモンドの鑑定書や取引履歴の登録簿の情報を、ダイヤモンドに割り振った識別子とひも付けて記録
デジタルコンテンツ
デジタルアートやユーザーが独自に定義したデジタルアセットの発行・所有権移転・管理
医薬品・貴重品認定
医薬品や貴重品の商品確認・認定を行うことにより消費者が偽造品を受け取ることを防止
領収書
コンプライアンス
医療記録からオンラインショッピングに至るまで、記録確認に適用可能なブロックチェーンレシート
ブロックチェーン上のトランザクションの出元と宛先を高いレベルで正確に特定し、マネーロンダリング(資金洗浄)対策を提供
目的としている。
社がこの仕組みに参加することが必要となる
②企業間での取り組み
ため、同社は業界標準を志向している。
複数の企業に共通する課題の解決を目標に
③社会インフラとしての取り組み
するなどした取り組みでは、実証実験にとど
ブロックチェーンの意義とコストシェア効
まらず既に一部が実用段階にある。英国のス
果が最も大きい分野であり、野心的な調査・
タートアップ企業 Everledger 社は、ダイヤ
研究と実証実験が世界各地で行われている。
モンドのカラット数など 40 の特徴をブロッ
米国の LO3 社と ConsenSys 社は、近隣住
クチェーン上に記録し、その所在の証明・追
民同士が再生可能エネルギーを相互に売買可
跡を第三者なしに可能とするサービスを実用
能な「TransActive Grid」というプロジェク
化している。同社によれば、米国と欧州では
トをニューヨークのブルックリンで推進して
保険の不正請求による損失が年間 450 億ポ
いる。参加者の家屋にはスマートメーターが
ンドに上り、不正の 64% が検知されていな
備えられ、屋根に設置されたソーラーパネル
いという(www.everledger.io)
。このサービ
や庭に設置された風車によって発電された
スを使えば、保険会社はブロックチェーンを
エネルギーの発生および使用状況はブロッ
参照するだけで盗難物などの所有確認を行う
クチェーンに記録されて誰もが確認できる。
ことができ、不正請求を減らすことが容易と
余ったエネルギーは、ブロックチェーン上の
なる。真に不正請求を減らすためには、でき
独自資産として住民同士が直接売買できる。
るだけ多くのデータを管理し、多くの保険会
エストニアでは、Bitnation 社が政府と共
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
11
特 集
FinTech の鍵を握る 2 つの技術
同で、どこに居住しているかにかかわらず、
散させるシャーディングや、決済完了以外の
婚姻や出生、事業契約などの証明を、ブロッ
処理をブロックチェーンの外で処理する技術
クチェーンを通じて直接得られる公証サービ
など、さまざまな解決策が提案、検証されて
スを提供している。
いる。
米国証券保管振替機構の持ち株会社 DTCC
もう1つの代表的な課題に、プライバシー
(Depository Trust & Clearing Corporation)
の管理がある。ブロックチェーン上の情報は
社も、買い戻し条件付き取引(レポ取引)に
参加ノードへ全て公開されるため、競合他社
おける清算プロセスの改善を目的とした実証
から取引情報を秘匿したい場合などには問題
実験の開始を発表している。
となる。そのため、リング署名や準同型暗
これらの取り組みの背景には、より効率的
号、ゼロ知識証明や秘密分散といった暗号理
なインフラ実現への期待があると思われる。
論や分散コンピューティングを利用した解決
それが可能になれば、途上国のような潤沢な
案が提案されている。
コストのかけられたインフラのない分野にも
これらインフラの技術課題においては、必
一定のインフラを提供できる可能性があり、
要なスキルを持つ技術者の不足と基礎研究の
経済発展の観点からも意義があろう。先進国
不足が解決の障壁となっているのが現状であ
においても、標準インフラのない領域で社会
る。課題を適切に理解し、産業全体として、
的なサービスをスモールスタートさせるため
より多くの人にとって使いやすいインフラ仕
の手段として活用することも考えられる。
様を固めていく姿勢が求められよう。
②ソフトウェアの成熟
普及への主な課題
プリケーションといったソフトウェアが未
ブロックチェーンを普及させるためには、
成 熟 で あ る。1983 年 に 登 場 し た イ ン ター
まずはインフラレベルの根本的な技術的課題
ネットも 1990 年にようやく商用化され、さ
を解決し標準化を図る必要があろう。その上
ら に 広 く 普 及 す る ま で に は HTML(Web
で、ビジネス面、法規制面の課題を解決して
ペ ー ジ を 記 述 す る た め の 言 語。1993 年に
いく必要がある。
標準化)や Java(1995 年に当時の米国 Sun
(1)技術面
12
インフラだけでなく、ミドルウェア、ア
Microsystems 社が公開した Web アプリケー
①インフラの技術課題
ション開発のためのプログラミング言語)の
代表的な課題の1つにスケーラビリティー
登場が必要だった。ブロックチェーンにおい
の確保がある。ブロックチェーンは既存のシ
ても、HTML や Java のような、ビジネス活
ステムと異なる仕組みのため、システムの処
用を一気に促進させる “キラーソフトウェア”
理量が増加した際にその処理能力と処理時間
の登場が待たれる。
を確保するための対策も従来と異なる方法が
③技術者の確保
必要とされる。データを複数のサーバーに分
Java は世界に 900 万人の技術者がいるが、
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
め、ユーザーの利益と保護を両立させる新し
世界に 5 千人ほどしかいないという(William
い法規制を整備する必要がある。行政におい
Mougayar 著『The Business Blockchain』
ては、民間における課題の早期把握はもちろ
Wiley 社、2016 年 5 月刊)。この数を増やす
ん、課題を予期できない全く新しいビジネス
ためには、オープンで魅力的な開発環境と、
モデルに対して制度の実証実験を行う環境を
先進的・野心的な取り組みが必要だろう。
整備することも必要となろう。
ブロックチェーンは社会に何をもたらすか
ブロックチェーンの技術者は 2016 年半ばで
(2)ビジネス面
①技術理解とチェンジマネジメント
ビジネスに関わる者にとって、ブロック
新しいビジネスインフラとして
ブロックチェーンは、中央機関の存在を前
ともするとそれを使うこと自体が目的化しや
提に構成された既存システムを大きく変える
すい。また、既存の業務・プロセスの枠の中
可能性がある。システムとは、情報システム
で考え、イノベーションに至らないこともあ
だけでなく、制度や組織、オペレーションと
る。こうしたことを防ぐためには、経営者を
いった全般的な仕組みを指す。この変化はさ
はじめとするビジネスに関わる者が技術を理
まざまな分野で、大小さまざまな規模で起き
解することが何よりも重要である。その上
る可能性がある。
で、適切な活用方法を考え、新技術という変
ブロックチェーンがこうした変化を起こす
化に対して十分に対応できる体制や仕組みを
ためには、まずは足元の根本的な技術的課題
構築するといったチェンジマネジメントが求
を解決することが必要である。その上で、技
められる。
術者が技術改良を進めるだけでなく、ビジネ
②新しいビジネスルールの策定
スや法規制に関わる人間がまずしっかりと技
従来の決済の仕組みでは、一定の時間内に
術を理解し、互いに工夫を凝らしてユーザー
全てのシステムで一意に決済が完了する。こ
の利便性を高めるシステムを共に創造するこ
れに対してブロックチェーンは、時間経過と
とが必要である。時には、ユーザー間の調停
ともに反論される可能性が極めて低い状態に
のように、第三者が行った方が価値を高める
なることで決済が完了するという考え方であ
ものは中央機関の存在を限定的に認めるな
る。こうした従来とは異なる思想に対応し
ど、柔軟かつ最適な現実解を模索することも
て、SLA(サービスレベル合意)などの新し
重要となろう。
いビジネスルールの策定が、そのノウハウと
ブロックチェーンは破壊的イノベーション
ともに必要になる。
と呼ばれるが、見方を変えれば、次の時代の
(3)法規制面
│ 新しいビジネスインフラとしての期待 │
チェーンは魅力的な技術に映る。そのため、
システムを創造する機会を多くの人に提供す
従来は、信用ある中央機関に対する法規制
るものではないだろうか。従来の考え方とは
があればよかったが、ブロックチェーンの
一線を画す新しいビジネスインフラが日本か
世界では信用ある中央機関は存在しないた
ら次々と誕生することを期待したい。
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
■
13
トピックス
サプライチェーン・デザインのすすめ
─ ビッグデータを活用したシナリオ・シミュレーション ─
市場への対応能力を増強し競争優位を築くために、従来の「サプライチェー
ン・マネジメント(SCM)
」から、サプライチェーンそのものをダイナミッ
クに再設計する「サプライチェーン・デザイン」へと、取り組みのかじを
切ることが必要である。本稿ではその概要と、欧米の製造業において活用
が始まっているサプライチェーン・デザイン・ツールの可能性を考察する。
野村総合研究所 システムコンサルティング事業本部
産業 IT コンサルティング部 上級システムコンサルタント
ひ き た
ときひさ
疋田 時久
専門は製造業・物流業における SCM 改革コンサルティング
「人間力」では解決できなくなった
SCM の現状
条件を考慮して物流ネットワークを再設計す
る必要に迫られている。拠点数の拡大は、有
サプライチェーン上の課題は、10 年以上
能な現場担当者不足を引き起こしている。今
前から、
「在庫」に起因するものが多く、そ
までと慣習が異なる仲間の増大は、これまで
れは今日でも変わらない。例えば、期末在庫
のあうんの呼吸が通じない業務環境を暗示し
の圧縮、欠品・機会損失の削減の問題などが
ている。今後は、言葉も思想も異なる現場担
いまだに解消されていない。
当者の誰もが、同じ行動・判断ができるよう
これまでの日本企業は、この課題に対し
な基準が必要となるだろう。
て、有能な現場担当者の存在と彼らの密なコ
実際、既存のサプライチェーンの多くは先
ミュニケーションによる属人的な業務処理に
に述べた属人的な対応を前提とした仕組みと
より、不良在庫や欠品の削減を実現してき
なっており、既存の業務およびシステムが、
た。この背景には日本という国の地理的な要
市場・顧客企業のニーズに追随できておら
因も大きく影響している。島国という狭い空
ず、事業環境の変化のスピードに対応できな
間にサプライヤー、部品メーカー、セット
くなってきている。グローバル展開をしてい
メーカーが集積し、優秀な現場担当者間の密
る企業の海外拠点から、「日本の従来型サプ
なコミュニケーションと高い納期順守率にサ
ライチェーンでの管理が限界となりつつあ
プライチェーンは支えられていたのである。
る。どのような手を打つべきなのか」といっ
しかし、近年の急速なグローバル化の中で
た相談も受けている。
は、
「地理的距離の拡大」、「拠点数の拡大」、
多くの日本企業は、販売・物流・生産の拠
「これまでの慣習が通じない仲間の増大」と
点を海外に設置し、海外展開を進めて来ては
いう過去に例を見ない事象が起きている。
い る も の の、 あ ら た め て 自 社 の サ プ ラ イ
各拠点の地理的距離の拡大により、輸送の
14
ための時間、配送サイクルなどの多くの制約
チェーンの俯瞰(ふかん)・分析を行い、グ
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
ローバル化に即したサプライチェーンへの課
現実ではないだろうか。
題解決に向けて、本格的に取り組んでいる企
業はまだ少ないのではないだろうか。
「今、現在」だけを見る SCM の
限界
サプライチェーン・マネジメントから
サプライチェーン・デザインへ
市場への対応能力を増強し競争優位を築く
ためには、直近の直面している課題への対処
在庫に起因するサプライチェーンの課題
を行う「サプライチェーン・マネジメント」
は、市場動向、顧客のニーズに対し適切な商
から、中長期的な市場への対応までを視野に
品供給を行うために、どこで、何を、いつ、
加えた「サプライチェーン・デザイン」を実
どれだけ生産すればよいのか、どこに運べば
現していくことが必要である。
よいのか、を検討することだとされてきた。
「サプライチェーン・デザイン」とは、既
この課題を解決する手だてとして、近年
存情報を所与としてサプライチェーンをモデ
「経営の見える化」という取り組みがよく経
リングし、既存ビジネスの分析を図り、サプ
営者から発せられている。経営者が、“今日、
ライチェーン全体配置を再設計することであ
今現在、現場で何が起きているのか”を確実
る。さらには、将来的な市場への対応、顧客
に把握できるようにする(情報システムを組
ニーズへの対応に備え、中長期視点での事業
む)ことで、即時に意思決定を行うというも
展開を実現するために、投資・M&A・人材
のだ。確かに、調達、生産、販売が、グロー
育成・組織改革を伴う企業活動を設計してい
バル規模で広がっている中で、リアルタイム
くことである。
で正しい状況を把握し、どう対処すればよい
のかを検討することは、必要である。
このためには、中長期から短期までをシー
ムレスに連携する事業計画の設計が必要であ
しかし、
「見える化」だけでは短期対応の
る。さまざまな環境変化を想定し、それに対
取り組みであることは否めない。サプライ
する機敏な対応を実現していくために、常
チェーン・マネジメントは短期的な観点だけ
に、2~3 年の中期計画を有し、月次レベル
でなく、市場における顧客ニーズの多様化・
でその計画全体の見直しが可能な状態でなけ
不確実性に対応するために、中長期的な事業
ればならない。
目標・投資計画を検討しなくてはならない。
その計画の中で、長期的な投資を位置づ
現在の日本企業の対応は、長期的な視点で
け、直近の短期的施策の実施を行い、それぞ
の対応策は年に 1 回、もしくは 3~5 年ごと
れの成果を確認していくのである。当然、さ
に中長期計画を策定するという行動になって
まざまな事象がサプライチェーン上で起きる
いる傾向が強い。これでは刻々と変わってい
が、それに対する適切な対応指示を出すのは
く市場環境の中で自社の強みを生かし、成長
経営の役割である。
していく上での対応が後手に回っているのが
このように、具体的なサプライチェーン・
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
15
トピックス
デ ザ イ ン の フ ロ ー は、 ① 既 存 の サ プ ラ イ
し、管理・蓄積・処理できる高度・高速な
チェーン(既存の物流拠点、生産拠点、製
データベース管理システム(インメモリー
品、取引先/仕入れ先、配送方法など)の分
データベース)などの技術環境も整ってきて
析、制約条件の洗い出しを行い、②長期的な
いる。
視点から企業がどうありたいのかを描き、③
このような情報処理技術を背景とし、ビッ
企業の成長戦略に応じた投資シナリオに基づ
グデータである大量の社内外情報を活用した
く企業像のシミュレーションを行い、④見直
サプライチェーン・デザインの支援ツールが
しを行った将来のサプライチェーンを実現す
出現しており、欧米のグローバル製造業にお
るための長期から短期に連動した事業計画を
いて活用が始まっている。これらのツール
描く、となっている。
は、これまでのサプライチェーンの根本的な
しかし、こうしたサプライチェーン・デザ
課題解決に向けた取り組みを支援するものと
インを行うことは、冒頭に述べた人間力の
して可能性を秘めており、次のようなシミュ
「経験と勘」では不可能である。このため、
レーション機能を持つ。(図 1 参照)
企業のシステム武装が必須であり、IT の活
長期的施策のために
用により、シミュレーションを実施し、その
・再デザインによる潜在的価値の評価と将来
中から最適な策を選定するという方法が望ま
のシナリオを提示
・シナリオ・制約条件に基づく What-if 分析
れる。
(「もし~なら」と仮定を変えて結果を評価
サプライチェーン・デザイン・
ツールによるシミュレーション
IT の世界に目を向けると、サプライチェー
ン・デザインを支える技術要素はそろいつつ
・長期的視点からの投資施策など、意思決定
のための判断情報を提供
短期的施策のために
・現状の可視化により、直近のリスク・課題
(市場の変化、災害などの予想外の事態な
ある。
(1)ビッグデータを活用したサプライチェー
ン・デザイン・ツール
社内情報の収集手段としては、近年の情報
技術の躍進により、IoT(Internet of Things)
などで製造物や生産ラインに取り付けたセン
16
するアプローチ)を行う
ど)を検出
・それに対するコスト削減、サービスレベル
向上、リスク低減などの直近の対応策を
提示
(2)サプライチェーン・デザインの実例
サーから、企業内の活動のあらゆる情報を収
ここで野村総合研究所(NRI)が実際に担
集・可視化できる環境などが整いつつある。
当した、サプライチェーン・デザインの実例
社外に目を向ければ、SNS など顧客から発信
をご紹介しよう。某飲料食品メーカーより、
されたさまざまな情報も世の中にあふれてい
次のような依頼があった。
る。加えて大量の情報をメモリー上に展開
①直近の需要動向に即した生産ラインの稼
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
図 1 サプライチェーン・デザイン・ツールによるシミュレーションの概念
るとともに、中期計画で設定し
ている売り上げ拡大を支援する
生産・物流インフラを再設計し
長期視点からの
投資施策
シナリオに基づく
What-if 分析
たい。
②生産スピードが速く、段取り替
え時間(ラインの品種や工程内
現状把握
サプライチェーンの
モデリング
潜在的価値の評価と
将来仮説のシナリオ
を提示
<長期的施策>
サプライチェーンの
再デザイン
容が変わる際に生じる時間)が
<短期的施策>
短い新型生産ラインの投資、新
工場の投資(既存工場の廃止)
サプライチェーン・デザインのすすめ
働、配送作業の最適化を検討す
直近の対応策
を含めて、投資を判断する情報
リスク・課題の
検出
現状の可視化
実現性の高いシミュレーションを行うことが
この顧客ニーズに対し、NRI ではツールを
可能となっている。
活用して以下の情報提供を行った。
・現実の制約条件をできるだけ考慮した定量
シミュレーション・モデルを構築。
・工場・物流センター配置シナリオを複数設
サプライチェーンの継続的な
見直しの必要性
定し、トータルコストを比較。
「製造費+
サプライチェーン・デザインは、サプライ
物流費」の合計額が最小になる拠点配置シ
チェーンそのものをダイナミックに設計・調
ナリオを探索。
整するものであり、従来のサプライチェー
・生産増強への投資判断の支援。具体的には
ン・マネジメントとは大きく取り組み概念が
直近1年間と先5年間までの投資策の提示。
異なる。既存を前提としないサプライチェー
このように、サプライチェーン・デザイン
ンそのものの再設計こそ、企業競争力を高め
により、直近の問題対応以外にも、中期計画
や投資判断に関するシミュレーションが可能
となっている。
る源泉となり得る新たな取り組みである。
さらに、再設計されたサプライチェーン
は、事業環境の変化に応じて、常に見直しを
これまでのシミュレーションは、情報シス
図る必要がある。現在は、このようなサプラ
テムの制約から、需要量を一定とした単純な
イチェーンの再設計を継続的に行う情報シス
「静的モデル」で行われることが多かった。
│ ビッグデータを活用したシナリオ・シミュレーション │
が欲しい。
テム環境も整備されている。
しかし、情報技術の躍進に伴い、ビッグデー
ツールを利用したシナリオ・シミュレー
タを入手することで、より実態に近い生産現
ションをベースにサプライチェーンの再設計
場、物流現場を再現できるようになった。こ
を行い、短長期の連携した事業計画とネット
れにより実オペレーションの複雑性や高い業
ワーク再構築の策定を、企業は今こそ進めて
務水準をモデルに反映させ、分析することで
いくべきである。
■
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
17
トピックス
同時並行型プロジェクトの落とし穴
─ 事例に学ぶプロジェクト運営の勘所 ─
基幹業務システムの老朽化対応などに伴い、複数のシステム構築プロジェ
クトを同時期に立ち上げるもその運営に苦戦しているという話を聞くこと
が多い。本稿では、プロジェクト支援の経験から複数プロジェクトを同時
並行で進める際のプロジェクト運営の勘所について考察したい。
野村総合研究所 システムコンサルティング事業本部
IT 刷新プロジェクト部 上級システムコンサルタント
え は ら
しんいち
江原 信一
専門はユーザー側 PM 支援、PMO、IT 部門運営強化
同時並行型プロジェクトの背景
企業によっては同時並行型のプロジェクトに
初めて直面し、苦戦するケースも多いようで
近年、企業の情報システムの中核をなす基
ある。そこで本稿では、プロジェクトを同時
幹業務システムの老朽化対応やシステム基盤
並行で進める際の「プロジェクト運営の勘
の全面刷新などにより、IT 部門が複数のシ
所」について考察したい。
ステム構築プロジェクトを同時期に立ち上げ
るケースが増えている。
個々のシステム構築プロジェクトは、他の
プロジェクトとシステムやスケジュールにお
いて少なからず依存関係を持つことになるた
まず、同時並行型プロジェクトが苦戦する
め、各プロジェクト間で調整を行いながらプ
典型的な要因を挙げてみたい。大きく 2 つ、
ロジェクトを進める必要がある。
さらに、基幹業務システム刷新のような大
規模なプロジェクトの場合、プロジェクト間
18
なぜ苦戦するのか?
その要因とは
「並行プロジェクト間でのリソースの制約」
と「関連するプロジェクト間の調整の難し
さ」がある。
の依存関係も複雑になるため、関連するプロ
(1)プロジェクト間での共通リソースの制約
ジェクト全体を管理する必要性が生じる。こ
プロジェクトの計画工程において、プロ
の全体管理が十分機能しない場合、プロジェ
ジェクトマネジャー(以下、PM)は、ユー
クトは予期せぬ問題に直面することとなる。
ザーからの公開時期の要求、システムの老朽
機能追加や性能向上といったエンハンス案
化対応期限、ベンダーからの提案などを踏ま
件や、個別のシステム構築プロジェクトの運
えてプロジェクトのスケジュールを策定す
営を通年行っている企業は多いが、その中で
る。しかし、システム構築プロジェクトが同
もシステム基盤を全面刷新するレベルのプロ
時進行する場合、開発やテストなどの各タス
ジェクト経験者は限られている。そのため、
クの実施時期が重なる傾向にあるため、計画
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
段階から共通リソースの調整を行わないと、
量は、プロジェクト全体の 1 割にも満たない
プロジェクト実施段階においてリソース不足
規模であったが、プロジェクト多重度(同時
が発覚するという問題に直面する。
に並行して実行できる数)がシステム連係基
ここで言う共通リソースとは、人的リソー
盤に取られたキーマンの数とほぼ同値だった
スであれば基盤メンバー・情報子会社のメン
のである。そのため、各サブプロジェクトの
バーなどであり、物的リソースであれば、テ
計画見直しに際しては、これらのメンバーが
スト環境やプロジェクトメンバーの執務場所
ボトルネックであることから、プロジェクト
などが該当する。たとえ個々のプロジェクト
多重度の上限を設定することとした。しかし、
において必要なリソースの規模や期間はわず
サブプロジェクト間での優先順位の調整など
かであっても、そのリソースが枯渇した場
に限界があり調整が難航したため、A 社は急
合、プロジェクトは計画の見直しを余儀なく
きょプロジェクト全体のマネジメント支援を
され、大規模な新規システム構築案件ともな
横断的に行う PMO(プロジェクトマネジメ
ると月単位の変更が必要になる場合もある。
ントオフィス。以下、全体 PMO)を設置し、
ここで、人的リソース不足によりプロジェ
クト全体のスケジュールが大幅に遅延してし
まった事例を紹介したい。
この全体 PMO が計画の見直しを主導した。
全体 PMO は、プロジェクト多重度の制約
に加え、各サブプロジェクトの優先度や期限
A 社は、基幹業務システムの老朽化対応と
なども加味して計画の見直し案を策定した
して、基幹業務を刷新するためのサブプロジェ
が、ステークホルダー(利害関係者)が多岐
クトを9 つ定義し、さみだれ式に立ち上げた。
にわたることから、結局各サブプロジェクト
A 社では、刷新後のシステム間連係には、共
との合意には約 5 カ月もの時間を要した。
通のシステム連係基盤を利用することをルー
(2)プロジェクト間の依存関係による影響
ル化していたが、実はこのシステム連係基盤
プロジェクトの実施工程において、各 PM
は稼働して間もない時期で、メンバーの育成
は依存関係のあるプロジェクトの状況を把握
と増員の必要性という課題が裏側にあった。
し、必要に応じてスケジュール調整などを行
問題は、先行開始したサブプロジェクトが
いながらプロジェクトを運営する。
テストフェーズに入った直後に発生した。く
しかし、複数プロジェクトが複雑に依存関
だんのシステム連係基盤に性能問題が発生し
係を持つ場合、問題や変更発生時の影響確認
てしまったのである。この問題に対処するた
や対策の調整先が多岐にわたることから、通
め、各サブプロジェクトのキーマンが追加投
常のプロジェクトよりも遅延のリスクが高ま
入されることとなり、後続のサブプロジェク
る傾向にある。
トの要件定義タスクと開発タスクを中断せざ
るを得ない状況になってしまった。
サブプロジェクト全体の立て直しに入り分
かったことは、システム連係基盤部分の開発
また、プロジェクト間の依存関係自体を把
握できていない場合は、影響確認にさらなる
時間を要するだけでなく、構築システムの品
質低下リスクも懸念されることになる。
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
19
トピックス
ここで、プロジェクトの予兆管理が十分で
の実施時期も見直すことになったため、他部
なかったために、1 つのサブプロジェクトの
署との調整が発生する事態にまで発展してし
遅延がプロジェクト全体の計画の見直しに発
まった。
展した事例を紹介したい。
B 社 IT 部門は、合併後の非効率な業務運営
や IT コストの高止まりを解消するために、
システム統合プロジェクトとして、5 つのサ
ブプロジェクトを同時に立ち上げた。プロ
このように同時並行型プロジェクトの遂行
ジェクト管理体制は、各サブプロジェクトに
に考慮すべき点は多いが、企業のシステム構
それぞれ PMO を設置し、プロジェクト全体
築プロジェクトの PMO を支援した経験から
の PM 直 下 に 全 体 PMO を 設 置 し た。 全 体
同時並行型プロジェクトに必要な管理手法に
PMO は各サブプロジェクトからの状況報告
ついて言及したい。
を取りまとめ、PM への定期報告などを行っ
(1)全体整合の取れた計画の整備・維持とそ
のチェックプロセスの確立
ていた。
各サブプロジェクトの開発は予定通り進ん
プロジェクトの計画策定時に共通リソース
でいたが、問題はサブプロジェクト間の結合
の点検を含め、全体の整合チェックを行うこと
テスト開始の直前で発生した。4 つのサブプ
が円滑なプロジェクト運営には不可欠である。
ロジェクトは内部テストを終え、結合テスト
このため、個々のプロジェクト計画、特に
を実施する準備に入っていた。残り 1 つも若
スケジュール、スコープ(実施すべき内容範
干の遅延は発生していたものの、予定通りテ
囲の定義)、体制の承認取得時に、他のプロ
ストを完了させる見込みとの定期報告が上
ジェクトを含めたプロジェクト全体で整合が
がっていた。しかし、結合テスト開始の前週
取れているかを確認する「プロセス」を設け
になり、そのサブプロジェクトの PMO から
ることが重要である。整合確認における主な
テストに合流できないという報告が上がって
確認観点は以下のとおりである。
きたのである。その結果、急きょ、結合テス
①システム構成図とプロジェクトスコープを
トのテストシナリオの見直しが必要となり、
踏まえ、依存関係のあるプロジェクトやシ
その影響確認とテストの再準備に時間を取ら
ステムが特定され、スケジュールや WBS
れたため、結合テストの実施時期を後ろ倒し
(作業分解図)には、プロジェクト間の必
にすることになってしまった。
要なタスクが漏れなく抽出されているか。
結合テストは、内部テストが完了したシス
②プロジェクト間で依存関係を持つタスクの
テムから優先して実施することで、プロジェ
前後関係、実施時期、対応期限が、関係す
クト全体が中断する事態には至らなかった
るプロジェクトそれぞれのスケジュールに
が、この影響で UAT(ユーザー受け入れテス
おいて、整合が取れているか。
ト。発注元がシステムの検証を行うテスト)
20
同時並行型プロジェクトに必要な
管理手法
③スケジュールの裏づけとして、体制が確保
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
などにより、プロジェクトの計画見直しが
は、プロジェクト多重度が増すことによる
発生しないか。
リソース不足が懸念されるため、各プロ
上記の観点を踏まえ、具体的なチェックタ
ジェクト計画より必要リソース数や期間を
イミング、チェック内容、リスク顕在化時の
抽出し、リソース制約下での計画になって
対応方針などをあらかじめ整理すれば、プロ
いるかを確認すること。
ジェクト全体の予兆管理のベースとして活用
また、進行中にプロジェクト全体の整合性
できる。
これにより、変更予兆を察知した場合、個
を設けることも重要である。整合チェックの
別プロジェクト側への調査負荷をかけること
タイミングは、各プロジェクトのスケジュール
なく、影響範囲やリスク対策の事前検討を行
ベースライン確定時、各種チェックポイント
うことができる。また、リスクが顕在化した
判定時、影響範囲が複数プロジェクトにまた
場合は、速やかに対策を発動することができ
がる内容の変更管理案件発生時、が該当する。
るのである。
なお、整合チェックにおいて整合を維持で
きないことが判明した場合、関連するプロ
ジェクトと調整を行い、整合の取れた計画へ
の見直しを行う必要がある。
(2)プロジェクト全体視点での予兆管理
円滑なプロジェクト運営のために
同時並行型プロジェクトを円滑に進め、プ
ロジェクトの遅延リスクを軽減するために
複数プロジェクトが依存関係を持ち同時並
は、個々のシステム構築プロジェクトにおけ
行する場合、プロジェクトの変更予兆を早期
るプロジェクト運営に加え、関連するプロ
に察知し、変更発生時の影響範囲の調査や対
ジェクト全体の管理機能が必要であると述べ
策の調整を速やかに行うことが、プロジェク
てきた。そして、同時並行型プロジェクトの
トの遅延リスク軽減には不可欠である。
特性を踏まえ、特にプロジェクト全体視点で
このため、個別プロジェクトのチェックポ
イントとは別に、プロジェクト全体としての
の整合チェックと予兆管理が重要であること
を確認した。
チェックポイントを設定し、その時点での各
残念ながら、システム開発プロジェクトの
プロジェクトの状況を基に、計画変更リスク
運営体制や制約はプロジェクトごとに異なる
が顕在化しないかなどの予兆を点検する必要
ため、万能なチェックリストや管理様式は存
がある。予兆管理における主なチェック観点
在しない。同時並行型プロジェクトの運営に
は以下のとおりである。
際しては、全体 PM はプロジェクトに応じた
①タスク依存関係を持つプロジェクトにおい
管理対象や確認内容を明確化した上で、管
て、制約期限を越えるスケジュール延伸や
理方法を具体化していく必要がある。本稿
メンバー確保の重複は発生しないか。
で紹介した内容がその一助となれば幸いで
②突発的に発生した戦略案件や制度対応案件
│ 事例に学ぶプロジェクト運営の勘所 │
が確保されているかをチェックするプロセス
同時並行型プロジェクトの落とし穴
されているか。特に共通リソースについて
ある。
■
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
21
トピックス
データセンターネットワークの次なる姿
─「マルチ・クラウド・ファブリック」の実現へ ─
仮想化の波はデータセンターネットワークにも押し寄せている。仮想化に
より物理的な制約から解放され、通信のソフトウェア制御が可能になれば、
システム要件に迅速かつ柔軟に対応することはさらに容易になる。
本稿では、
ネットワーク仮想化の動向を紹介し、仮想化に適したネットワークの在り
方について考察する。
NRI システムテクノ
基盤システム第 1 事業部 主任
よこしま
こ う じ
横島 孝史
専門はネットワーク分野のシステム企画・開発
22
広がる仮想化の範囲
ネットワーク仮想化の取り組み
サーバー仮想化(物理的に 1 台のサーバー
こうして仮想化があまり進まないネット
上であたかも複数のサーバーが動作するよう
ワークは、効率化されたサーバー環境との隔
にすること)や、仮想化されたリソースを共
たりが決定的となり、コスト効果、柔軟性、
有するパブリッククラウドの普及に続いて、
即時性を求める上で大きな足かせとなって
ネットワーク上に散在したさまざまなデータ
しまった。この状況を変えようと、NRI シス
ベースのデータを仮想化するデータ仮想化も
テムテクノは顧客企業 A 社のデータセンター
進んできた。この仮想化はネットワークにも
ネットワークの仮想化に取り組んだ。
及んでいる。
まず、ベンダー依存をなくすために、米
従来のネットワーク機器は、機能がハー
国 VMware 社の SDN 製品「VMware NSX for
ドウェアと結び付いており、必要な機能が
vSphere」(以下、「NSX」)によって、サー
ハードウェアの制約によって実現できないこ
バー向け通信をハードウェアから独立させ
とが多かった。このようなハードウェア依
た。「NSX」は、仮想サーバーの通信を制御
存(ベンダー依存)をなくそうと 5 年ほど前
するソフトウェアである。
から提唱されているのが、ネットワークを仮
次に、ソフトウェア制御されたネットワー
想化して複数のネットワーク機器を 1 つのソ
クを最大限に生かすハードウェアとして、米
フトウェアで管理できるようにしようという
国Juniper Networks社のイーサーネットファ
SDN(Software Defined Network)という概
ブリック(仮想化環境に最適化されたネット
念である。しかし SDN はあまり普及してこ
ワークアーキテクチャー)製品を選択した。
なかった。特にデータセンターのネットワー
この製品は複数のネットワーク機器を仮想的
ク担当者は、変更の影響範囲が大きいネット
に 1 台の機器として稼働できるため、管理負
ワーク仮想化には慎重である。
荷を大幅に削減できる。
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
最後は、従来の設計思想からの脱却であ
ば、即時性や多彩なユーザーインターフェー
る。ソフトウェア制御の柔軟性を生かすべ
スといったパブリッククラウドの利点を享受
く、サーバーの用途によって細分化できる
できる。
ネットワーク設計を基本とした。
このように、ソフトウェア制御の利点をど
のように生かすのか、仮想ネットワークをど
導入効果の最大化には戦略が必要
のように使うのかという戦略が、導入効果を
最大化させるために必要となる。
取り組みの効果はすぐに得られた。機器の
集約により、保守費、ラック費、電気代など
を削減し、A 社では数年で投資を回収できる
クラウドのさらなる進化へ
見込みである。しかしこれだけにとどめず、
クラウドの利用形態として、プライベート
継続的に効果を上げるための次の戦略が考え
クラウドとパブリッククラウドを組み合わせ
られている。キーワードは 2 つ、自動化とク
たハイブリッドクラウドがある。実データは
ラウド連係である。
セキュリティのためにプライベートクラウド
従来の機器は、メーカーによって OS(基
上に保管し、即時性やユーザーの接続口を目
本ソフト)が異なっており、API(Application
的としてパブリッククラウドを利用する。単
Programming Interface。ソフトウェアの機
独で多機能を目指すのではなく、連係された
能を別のソフトウェアから呼び出すための接
クラウド上で、それぞれの得意な機能を利用
続仕様)を持たないものが多く、自動化から
しようというものだ。さらに、ソフトウェア
は遠かった。一方、「NSX」は仮想サーバー
制御された仮想ネットワークでクラウド同士
との連係を前提に API を標準装備しており、
を接続すれば、管理者はテンプレート化され
ネットワークとセキュリティの設定をテンプ
たネットワークを運用し、ユーザーは接続
レート(ひな形)化し、仮想サーバー上の任
先を意識せずにサービスを享受することが
意のアプリケーションに対して API を通じて
できる。こうした考え方を表す言葉の 1 つが
自動展開することができる。最大の効果は導
「マルチ・クラウド・ファブリック」である。
入速度の圧倒的な向上である。このように人
さまざまな形態のクラウドを 1 つの枠組み
的コストを含めた大きなコスト削減を望める
(ファブリック)に集約するということだ。
のはソフトウェア制御の大きな利点である。
仮想ネットワークはシームレスなクラウド
A 社では、データセンターネットワークを
群、データセンター群と非常にマッチする。
外部のパブリッククラウドと連係させ、自社
「マルチ・クラウド・ファブリック」の上で
データセンター上のプライベートクラウドを
実現したいことは何か、どのような機能が必
拡張することにしている。「NSX」の API が
要で、どのように仮想化をツールとして生か
標準サービスとして用意されているパブリッ
すのか、その方針と戦略が問われるようにな
ククラウドもあり、
「NSX」同士を接続すれ
るだろう。
■
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
23
海外便り
グローバル・リモートワーク時代のチーム運営
─ 相互理解と連帯感を生み出すための取り組み ─
グローバル化の進展により、言語や文化が異なる複数の国のメンバーの協
業を必要とするプロジェクトが増えている。そのようなプロジェクトを成
功させるためには、利便性の高い IT の活用に加えて、メンバーが互いに相
手の個性や文化的背景などを理解し、連帯感が生み出されるようにするチー
ム運営が求められる。
NRI 香港 グローバルシステムサービス部門
システムコンサルティング部 上級システムコンサルタント
み や た
ともあき
宮田 友朗
専門は ERP を活用した業務改善、ERP の導入・保守運用
あるチームの悩み
が実際に経験したことだ。
スケジュールは 2 週間も遅れている。今、
グローバルチームの課題
香港、フィリピン、インドネシア、タイ、イ
24
ンドなどアジア全域に散らばった 15 名ほど
NRI 香港では、アジアの日系企業向けに
のメンバーによる Web 会議が開かれ、文化
ERP(統合基幹業務システム)とその周辺ソ
的背景や考え方が異なるメンバーが代わる代
リューション(バーコードシステムやビジ
わるタスクの遅延理由を説明している。込み
ネスインテリジェンス・ツールなど)をクラ
入った議論も全て英語である。皆、口には出
ウドサービスとして提供している。導入とサ
さないが、いら立っているのが分かる。進行
ポートは現地の ERP コンサルタントが行う
役のプロジェクトマネジャーは、会議用マイ
が、顧客への提案内容や導入内容の検討など
クに気を付けながら深いため息をついた。
には各拠点のメンバーが参加する。ただし、
プロジェクトマネジャーが状況をさらに細
ほとんどのやり取りはメールか電話、Web
かく聞いていくと、深刻な事態であることが
会議で行い、関係者が顔を合わせるのはその
徐々に明らかになってくる。わずかな認識の
必要が生じた時ぐらいに限られる。
ずれから、全く見当違いの成果物が作成され
こういうチームは上に描写したような状況
ている。チームで作業しているという感覚が
に陥りやすい。システム構築プロジェクト
薄く、自分のタスクが他のメンバーに及ぼす
は、工業製品などと違って目に見えないもの
影響を想像できていない。あらためて完了予
をメンバーが協力してつくり上げるものだけ
定を聞くと、スピーカーからはいつもの「By
に、コミュニケーション品質がアウトプット
tomorrow(明日までに)」がむなしく聞こえ
品質を大きく左右する。ひと昔前はメンバー
てくる。
が顔を合わせて作業するのが当然だったが、
多少は誇張しているが、これは以前に筆者
今は上記のように国や言語、文化的背景が異
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
なる個人が別々の場所にいながら協力し合っ
機時間を減らすため、米国 Microsoft 社の法
て複雑な作業をするグローバル・リモート
人向けコミュニケーションプラットフォーム
ワーク時代になっている。
「Skype for Business」を導入した。これによ
このような状況では従来以上に “ボタンの
り、メンバー間で仕事だけでなくプライベー
掛け違い” が起こる。プロジェクトの共通言
トな会話も気軽にされるようになり、相手の
語は英語とすることが多いが、アジアではメ
家庭のことまで分かるようになった。また、
ンバーが英語を母語としないため、どうして
従来のリモート会議では互いに何をしている
も細かなニュアンスが伝わらない。リモート
のか見えなかったが、このツールでは出社・
会議ではなおさらである。スケジュール感覚
退社・会議中などの状況がリアルタイムに分
も違い、日本では日単位のところがフィリピ
かるため、相手のだいたいの繁忙度が把握で
ンでは週単位だったりする。日本だと十分に
き、思いやる雰囲気が出てきた。
事前準備をして失敗を避けようとするが、ア
②オフラインでの交流
ジア圏の多くは取りあえずやってみて失敗し
NRI 香港では、年に 1 回、全員を香港に集
たら直すという流儀のため、タスクの “レベ
めてチームミーティングを開催し、1 年の振
ル感” が合わない。責任感の内容も国や文化
り返りと次の年の予定を共有することにして
によって異なる。完遂まで頑張るのが普通の
いる。このミーティングの中で、数十人のメ
国もあれば、努力はするが就業時間内にでき
ンバー全員が自己紹介する時間をたっぷり取
なかったら仕方ないというベストエフォート
るようにした。プライベートなことも話して
感覚の国もあり、メンバー間の摩擦を生みや
もらい、どんな人柄かを皆に知ってもらう。
すい。もともと複雑なシステム構築プロジェ
ミーティングの後は食事会を開催し、存分に
クトに、さらにこのようなリスク因子が加わ
交流する。相手がどんな人で、何を意図して
るのである。
いるかを理解しやすくするためだ。
これを放置してしまうと、細かなずれが積
以上のような対策の結果、助け合おうとい
み重なり、リリース直前になって致命的な問
う意識が生まれ、円滑な協業ができるように
題が発覚するようなことが起こりかねない。
なった。今では冒頭で描写したようなシーン
リスクをリスクとしてきちんと認識し、積極
はなくなった。最も大切なのは、メンバーが
的に改善していく態度が求められる。
互いに相手の価値観、考え方、個性を知り、
連帯感を持てるような環境を構築することで
成功の鍵は相互理解と連帯感
ある。この環境に基づく協力体制がなけれ
われわれのチームでは、このリスクを重視
揮しない。
して以下の 2 つの対策を実施した。
今後もグローバルチームの円滑な運営に力
①コミュニケーションプラットフォームの導入
を入れ、グローバルに活躍している日系企業
コミュニケーション量を増やして無駄な待
のビジネスを強力に支援していきたい。
ば、便利なツールや厳格なルールも効果を発
2016.08 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
■
25
NRI Web Site
www.nri.com/jp
NRI 公式ホームページ
会社情報
NRI グループの CSR 活動 www.nri.com/jp/csr
IR 情報
www.nri.com/jp/ir
事業・ソリューション別のポータルサイト
コンサルティング
www.nri.com/jp/products/consulting
日本における先駆者として社会や産業、企業の発展に貢献してきた
コンサルティングサービスを紹介
未来創発センター
www.nri.com/jp/souhatsu
アジア・日本の新しい成長戦略に関わる NRI の取り組み、研究成果の
情報発信、政策提言などを紹介
金融 IT ソリューション
www.nri.com/jp/products/kinyu
金融・資本市場でのビジネスを戦略的にサポートする IT ソリュー
ションの実績、ビジョンを紹介
NRI Financial Solutions �s.nri.co.jp
金融・資本市場に関わる NRI の取り組みについての情報発信、
政策提言、IT ソリューションを紹介
産業 IT ソリューション
www.nri.com/jp/products/sangyo
流通業やサービス業、製造業などさまざまな産業分野のお客さまに
提供するソリューションを紹介
IT 基盤サービス
www.nri.com/jp/products/kiban
産業分野や社会インフラを支えるシステム、システムを安全・確実に
運用するためのソリューションを紹介
BizMart
www.bizmart.jp
企業間業務や生・配・販を中心とするさまざまな業種の業務効率化を
支援するソリューションを紹介
グループ企業・関連団体の Web サイト
NRI ネットコム
インターネットシステムの企画・開発・設計・運用などのソリュー
ションを提供
www.nri-net.com
NRI セキュアテクノロジーズ www.nri-secure.co.jp
情報セキュリティに関するコンサルティング、ソリューション導入、
教育、運用などのワンストップサービスを提供
NRI データ i テック
www.n-itech.com
IT 基盤の設計・構築・展開と稼働後のきめ細かな維持・管理サー
ビスを提供
NRI サイバーパテント
www.patent.ne.jp
「NRI サイバーパテントデスク」など、特許の取得・活用のための
ソリューションを提供
NRI 社会情報システム
www.nri-social.co.jp
全国のシルバー人材センターの事業を支援する総合情報処理シス
テム「エイジレス 80」を提供
NRI プロセスイノベーション www.nri-pi.com
中国でのオフショア業務などで培ったノウハウを活用した業務
支援サービスを提供
NRI システムテクノ
www.nri-st.co.jp
味の素グループに情報システムの企画・開発・運用サービスを提供
だいこう証券ビジネス
www.daiko-sb.co.jp
証券業務に関わるさまざまなミドル・バックサービスをワンストップで
提供
野村マネジメント・スクール
www.nsam.or.jp
日本の経済社会の健全な発展および国民生活の向上のために重要な
経営幹部の育成を支援する各種講座を開催
Worldwide
NRI グループ(グローバル)
NRI Financial Solutions(英語)
NRI アメリカ
brierley+partners
NRI 北京
NRI 上海
www.nri.com/global
�s.nri.co.jp/en
www.nria.com
www.brierley.com
beijing.nri.com.cn/jp
consulting.nri.com.cn
■ IT ソリューションフロンティアについて
26
NRI FT India
NRI APAC
NRI 香港
NRI 台湾
NRI ソウル
NRI インド
www.nri�ntech.com
www.nrisg.com
www.nrihk.com
www.nri.com.tw
www.nri-seoul.co.kr
india.nri.com
本誌の各論文およびバックナンバーは NRI 公式ホームページで閲覧できます。
本誌に関するご意見、ご要望などは、[email protected] 宛てにお送りください。
| 2016.08
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
編 集 長
編集委員
編集事務局
野 呂
五十嵐
梅 屋
河 西
木 闇
武 富
角 田
引 田
吉 川
和 田
直 子
卓
真一郎
敏 靖
憲 一
康 人
勝
健 一
明
充 弘
瀬 戸 優花子
内 山
川 口
北 香 山
田 實
登 坂
宮 原
和 栗
昇
剛 弘
俊 一
満
成 郎
和 生
由香理
一 雄
清 水 崇 史
2016 年 8 月号 Vol.33 No.08(通巻 392 号)
2016 年 7 月 20 日 発行
発行人
此本 臣吾
発行所
株式会社野村総合研究所 コーポレートコミュニケーション部
〒100-0005 東京都千代田区丸の内 1-6-5 丸の内北口ビル
ホームページ www.nri.com/jp
発 送
NRI ワークプレイス株式会社 ビジネスサービスグループ
〒 240-0005 横浜市保土ケ谷区神戸町 134
電話 045-336-7331(直通) Fax.045-336-1408
本誌に登場する会社名、商品名、製品名などは一般に関係各社の商標または登録商標です。
本誌では ®、
「TM」は割愛させていただいています。本誌記事の無断転載・複写を禁じます。
Copyright © Nomura Research Institute, Ltd. All rights reserved.
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
www.nri.com/jp