企業組織論としてのオープンイノベーション

© 2016 NTT DOCOMO, INC. All Rights Reserved.
栄藤稔
株式会社ＮＴＴドコモ
@mickbean
7/14/2016
本書に記載の会社名・製品名・ロゴは各社の商標または登録商標です
企業組織論としてのオープンイノベーション
1

© 2016 NTT DOCOMO, INC. All Rights Reserved. 2
アジャイル開発の変遷
第1世代＝開発（リリース）の⾼速化
第2世代＝DevOps
第3世代＝NoOpS？
ベストプラクティスな
開発環境の選定
クラウド
ソフトウェア開発ツール
Micro Services
マイクロ事業部
以下の実装が必須
組織・⽂化への
マッピング
チームに権限委譲．
今意識していること

コンウェイの法則（Marvin Conway, 1968）
• ⽣成物のデザインは組織構造を反映する．
• 組織の構造やコミュニケーションがそのままソフトウェアの
アーキテクチャとなる.
• ⼤⼈数のチームはコミュニケーションコストが指数関数的に
⾼くなるのでサービス開発に不適であり低品質となることが
多い.

© 2016 NTT DOCOMO, INC. All Rights Reserved. 4www.bonkersworld.net/organizational-charts/
有名テック企業の概念的組織図（2011年6⽉）

https://viethip.com/category/architecture/page/2/
You build, you run it.

外からの⾒え⽅実際の形
AWS
EC2 RDS S3
VPC EMR DynamoDB
… … …
Micro Services

© 2016 NTT DOCOMO, INC. All rights reserved.
⼈を増やせば開発スピードが上がるか？
oブルックスの法則
➢新たに投⼊された開発者が⽣産性の向上に寄与するまで時間がかかる
➢⼈員の投下はチーム内のコミュニケーションコストを増⼤させる
oリンゲルマン効果
➢⼈間は集団になればなるほど⼿抜きをする
oタックマンモデルも踏まえると，新たに投⼊された⼈員がチーム内で安定して機能するま
でには時間を要するため，明らかなプラス材料でもない限りはスピード向上に寄与しない
o特にビジョンや⽅向性が共有されていない⼈員はチーム全体のモチベーションを下げる効
果もあるため，⼈員増加は慎重に実施すべきことである（メンバーの⼊れ替えも同じ）
oスタートアップには30⼈，50⼈，100⼈の壁があると⾔われる
➢主にコミュニケーションコストの増⼤に起因する
8

http://www.roger-wilco.net/flight-object-ion/
”管理職のエネルギーの８０％は部門間調整”症候群を避けるには？
システムの各機能を疎結合にするために縦割り自己完結組織を作る。部門間のコミュニケーションを意図的に減らし個別最適化を図る

1 > 2 > 0 ?
重複は悪か？ No!, 意識的に重複を許す組織編成
同じようなプロジェクトが無いより２つあったほうが良い．では１にまとめたほうがさらに良いのか？ダーウィンならNoというだろうな．

私が経験した開発プロセスについて

要求
設計
実装
試験
運⽤・保守
13

14
事業部：過剰な要求仕様、
技術トレードオフの軽視。
技術部：事業部のリソースとしてお
客様満⾜は⼆の次。
バグゼロ化のための過剰な試験。
運⽤部：リスクゼロに向けた変
化への過剰な抵抗。
発注委託型サービス開発に巣⾷う病巣

アジャイル開発チーム
アジャイル
開発
Core engineer
Core engineer Development
promoter
Development
promoter
Product owner
15

要求
設計
実装試験
運⽤・保守
“UX向上”の追及
16

学ぶ
データ
素早い投資
判断
柔軟な資⾦
調達
アドバイザー
ユーザー
の声
構築する
製品
アイデア
計測する
17
「リーンスタートアップモデル」
少ない予算と⼈数で
素早い製品展開

Transition of Voice Agent Services
18
5/2011
Stealth Product
Data Center
歴史
June
AWS
NC-reg
Sept.
11/2012
AWS
Tokyo-reg.
Version 2
3/2012
Mar.∼
Version 1
Public
Cloud

基本アーキテクチャ２０１０
Logging
Voice 
Recognition
Task 
Recognition
Logging
Voice
text
text contents
Service
Providers’ DB
contents
text
Text to speech
19
Loose Coupling System

システムアーキテクチャ２０１２
20
Availability Zone #1
SmartPhone
Management
Server
Log Server for VR
Voice Recognizer(VR) Task Recognizer(TR) Log management system
Same as
AZ #1
TR Servers
ELB
(across multiple
zones)
Tokenizer Access Log Servers
VPC
VR Servers
LB
ELB
(across multiple
zones)
ELB
(across multiple zones)

ソフトウェア開発⼿法の進化にあわせて
を契機として企業⽂化と組織を変えよう．

プログラムできるデータセンターの⼤規模利⽤が進展
• システム構築＝コンポーネントの組み合わせ
22
シンプルな
Webサーバ
しゃべってコンシェル（Cloud-native）
データ分析基盤（On premise-hybrid）

２０１０年
私の⾃慢のシステムでした．

Client
Redshift
Data Source ET Temporary
Storage
Direct
Connect
State
Management
Forwarder
Loader
Sandbox
VPC
Peering
S3
Q3 2014

⼤企業Hacks! by ⼤津⾕，NTTコミュニケーションズ
内製で作る．
• ソフトウェアの重要性が増している．
• ソフトウェアの開発が容易になった．
• ソフトウェアの開発⼒が企業の競争⼒を左右する．
• ソフトウェアがかつてのハードウェアの領域もカ
バーするようになった．
25
http://www.slideshare.net/rotsuya/hacks-56126883
⼤企業をうまく利⽤して⾃由に，楽しく，かっこよく新しいサービスを作る⼯夫．

社内にスタートアップ環境作る．
＝等価＝
スタートアップとの協創環境を作る．
＝等価＝
⾃分たちで事業創造シナリオを考え、
安く早く作ることに拘る．

イワヤ
電動動物玩具
製造・販売
ノウハウ
docomo
商品企画/
NW提供※1/
料⾦提供※2
バイテック
グローバル
エレクトロニクス
開発マネジ
メント
ムーアドール
ボイスメッセージ
技術/IoTプラット
ホーム
メールを使っていない⾼齢者でも操作可能なシンプルＵＩ
離れて暮らす家族のコミュニケーションを活性化
2016年7⽉
サービス開始！
（7⽉販売分は予約完売、
9⽉に再販売予定！）
右⼿ボタン
メッセージ
再⽣
左⼿ボタン
メッセージ
送信
事例１『コミュニケーションパートナー』
各社の役割
調査会社を⼀切使わず、商品企画・開発担当者⾃らが⾜を使
い、ユーザの⽣の声をヒアリング（※）。ユーザのより深い要望を
掘り起し、商品開発へダイレクトに反映！
※ユーザインタビュー300名以上、ホームユース調査30世帯以上、
アンバサダー（無償で協⼒をいただいている⼀般の⽅々）との定例MTG6回を実施。
27

全社が⼀丸となったプロジェクト運営
⇒「発注・受託」の関係だと、「何のためにやっているか」が末端まで伝わらない。
4社が⼀つのチームとして全プロセスを共に歩むことで、メンバー全員が共通のビジョンを持ち、
さらに1社の稼働が切迫した際に他の会社がバックアップできるようになった。
<従来>
<今回>
docomo B社 C社 D社 E社
イワヤ・ドコモ・バイテック・MOOREdoll
調査
Ａ社
5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月
調査
①
調査
②
調査
③
調査
④
調査
⑤
調査
⑥
イワヤ・バイテック・MOOREdollとの協業
プロトタイプ開
発
新商品発表会
準備
企画開発試験⽣産運営
2015年 2016年

事例２：コインパーキングをスマートに
駐⾞場予約・
キャッシュレス精算
満空監視・
⼊出庫検知
＝

開発は外で，スモールチームで
課題検出
(温度上昇・電波⼲渉)
ハードウェア部品
構成変更
システム
チューニング
・3社(ドコモ,xtone,ユカイ⼯学)
10名程度で横断チームを編成
-クラウド
-アプリケーション(UI/UX)
-IoTシステム(センサ・GW)
・実際のコインパーキングを使い、
実データを基点に、システム開発
・10⽉より、実ユーザも参加し、
ユーザビリティの評価・改善を経て
17年度商⽤化(予定)

⼤企業＝計画重視
スタートアップ＝計画＆実⾏組織
クラウドネイティブでデザイン思考
1. BizDevOpsの内製化．
2. アセット化を意識．
3. 多能⼯（フルスタックエンジニア）によ
るチーム⽣成．
さらに意識していること

ソフトウェア開発⼿法と組織構造
33

アジャイルとクラウド
oアジャイルの特徴
➢変化への対応の⾼速化：1⽇10回デプロイ，等継続的デリバリー
oクラウドの特性
➢後から変えられる，ソフトウェアで完結する変更すぐ作れる，リソースは完全に測
定可能，すぐ試せる継続的な改善，デリバリー
o（当たり前だが）両者は相性が良い
➢むしろアジャイルを実現しようと思えばクラウドを利⽤せざるを得ない
oアジャイル（≒リーン）な開発をしようと思うなら，ツールや環境もそれに合わせる
必要がある
➢逆にアジャイルに適したツールは通常の開発にとってはオーバーヘッド
➢エクセルで課題管理票のやり取りをするなら，アジャイルやリーンを採⽤しない⽅
が相性は良い
34

CodeOperate
Analyze
DEVOPS
Agile
Growth Hack
Lean Startup
A/BTest
バックログ管理
自動テスト
デプロイ
ソースコード管理
インテグレーション
※ビルド、テスト、デプロイを
連携させ実行する
ビックデータ分析・BIをふくめたツール群
アクセス分析
Amazon Mobile
Junit
tableau
PLAN
BUILD
RELEASEMEASURE

リーン開発（リーンソフトウェア開発）
o トヨタ⽣産⽅式（TPS）に端を発する考え⽅（リーン思考）をソフトウェ
アに応⽤した開発⼿法
➢ アジャイル開発の実現⼿段の1つとして位置付けられることが多い
o 7つの原則
➢ ムダをなくす，品質を作り込む，知識を作り出す，決定を遅らせる，速く提供する，⼈を尊重する，全体を最適化する
o 22の思考ツール
➢ ムダを認識する，バリューストリーム・マップ，フィードバック，イテレーション，同期，集合ベース開発，オプショ
ン思考，最終責任時点，意思決定，プルシステム，待ち⾏列理論，遅れのコスト，⾃発的決定，モチベーション，リー
ダーシップ，専⾨知識，認知統⼀性，コンセプト統⼀性，リファクタリング，テスティング，計測，契約
o 品質＝収益＋低コストの実現（ユーザ満⾜＝最終ゴール）
o 「ムダ」に注⽬されることが多いが，開発としてのポイントは継続性
（Continuous Integration/Deployment/Delivery）
➢ ムダを無くすのはMVP作成が主眼だが，本質は継続によるカイゼン

リーンスタートアップ
o 構築・計測・学習のアジャイル的なフィードバックサイクルをベースに
MVP作成，顧客価値の検証，改善の⼯程を繰り返すスタイルのスタート
アップ
➢ 0から1を作る際の試⾏錯誤⽅法なのでピボットあり
o アジャイル開発⼿法をスタートアップに適⽤したものだが，1を産み出
すために，「開発」よりも「検証」に重きを置く
➢ アジャイルはプロダクトリリースサイクルを早めるが，リーンスタートアップではリリースはコストなので最悪開
発しなくても良い
➢ MVPの価値検証の進め⽅
✓ アジャイル：最⼩限の動くものを作って提供しカイゼンを繰り返す
✓ リーン：動くものを作る前に顧客と対話して作るものを絞り込む
➢ 動くものがないと検証できない時点でリーンではない
✓ 構築・計測・学習でなく，構築の前の仮説・検証・学習を繰り返す取り組み
✓ 最初に⽴てた仮説はほぼ確実に間違っているので，何度もサイクルを回して顧客にとって価値ある仮説を創出することが重要
• 価値を認識できるまでコストをかけない，開発しない
➢ リーンキャンバスのようなツールを活⽤（MVP/MMF/UVP…）
✓ 実践：http://k2works.github.io/blog/2014/04/18/runnig-lenan-startup/
37

http://d.hatena.ne.jp/wayaguchi/touch/20130217/1361047033 より
原則と思考集（経営者視点）
反復型開発のフレームワーク
（管理者視点）
ベストプラクティスの集合体
（開発者視点）

DevOps
• DevelopmentとOperationを組み合わせた造語
• 体制や組織論，考え⽅の概念（Dev，Opsに加えてQAも含まれる）
• 最近ではBusiness部⾨を加えてBizDevOpsという造語もある
• ⽬的，ゴールは顧客の望むものを速く届けること
• 元々はFlickerのエンジニアの以下のスライドに端を発する
• http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-ﬂickr
• 開発と運⽤（とQA）は尊敬・信頼しあい，相⼿を⾮難するのではなく，透明性を確保し，影響を与え
ながらプロダクトを頻繁にリリースする
• 上流から下流ではなく，フィードバックとイテレーション
39

NoOps (Mike Gualtieri, Forrester Research)
• http://blogs.forrester.com/mike_gualtieri/11-02-07-
i_dont_want_devops_i_want_noops
• IaaSとPaaSを活⽤してOpsなしで実現すること
• 2016年3⽉のGCP NextでGoogleのEric Schmitも以下を発⾔
• NoOps will become mainstream
• Serverless architectures will be the next wave of computing
• Public Cloudの発展によりOpsが必要な領域は減ってきているのは事実
• AWS Lambda/Google Cloud Functions/Azure Functions，各種PaaS
• こういったものを活⽤してDevOpsの概念を実現するのがNoOps
• インシデント対応等を含めると運⽤がなくなるわけではない
40

State of the Art in Microservices by Adrian Cockcroft

https://giantswarm.io/microservices/
Monorith Microservices

http://qiita.com/spesnova/items/d7c95cc13ca1caf389fb
http://www.slideshare.net/adriancockcroft/goto-berlin

http://olive-drab.com/od_milorgs_us_army.php
Squad

http://www.educate.co.jp/2008-10-05-11-32-59/126-2010-12-14-10-01-01.html
タックマンモデルとリーダーのタスク
o 形成期
➢ リーダーはチームの⽬標を達成するための課題を明らかにする
o 混乱期
➢ リーダーは課題を解決するためのアプローチを⾒つけるためにメンバー間の相互理解を促す
o 統⼀期
➢ リーダーはメンバーの価値観を踏まえてルールや役割を決め，チームとしての⽬標達成意欲を喚起する
o 機能期
➢ リーダーはメンバーのコミュニケーションをサポートする

アジャイルな開発組織におけるリーダー
o 開発が上⼿くいかない原因はほぼ全てリーダーに起因
➢ 開発＝新規ビジネス開発，リーダー＝上司と置き換えても良い
➢ スーパーハッカーを集めてもリーダーが無能なら失敗する
o 例：良いアイデア・プランが出てこない
➢ 出てきているのに⾒ない・聞かない・気づかない
➢ 出ているものは⾃分の求めているものではないと決めつけている
のどちらかであることが多い
o リーダーの役割
➢ 全てのビジネスは⼩さくムダとも思える種から始まり，それをチーム全員で擦ったり揉んだりしながら粘り強く作りあげていくこと
で結実する
➢ 個々のメンバーが⾃由に発想できない，⾃由に発⾔できない，協働意識が持てていない，チームの⼀体感が持てない，問題意識を共
有できない，というのはリーダーがチームのムード作りに失敗していることが原因
➢ リーダーの役割はメンバーが⾃律的に動けるようにサポートすることであり決定や指⽰命令をすることではない（奉仕型リーダー
シップ）
✓ チーム内で解決できない問題の解決はリーダーの仕事（他チーム調整等）
48

組織パターン
o ⽣産性が⾼い組織にはパターンがある
➢チーム編成のパターン（アジャイル開発）
✓ロール
✓ロール間の関係
✓チーム間の関係
➢パターン⾔語＝⽅法と関係性の記述
o プロセスは問題を解決しない
➢逆にプロセス志向とウォーターフォールは
相性が良い（規律，ステップ論，⼀貫性）
➢アジャイルはプロダクト志向と相性が良い
o 組織パターンの効果
➢コミュニケーション（アーキテクチャ）の⽂化的⼟台
➢ゴールや⽬的，価値観についての共通認識
o パターンリストと概要
➢http://d.hatena.ne.jp/asakichy/20140121/1390255981

権限委譲
o 権限移譲と権限委譲
➢ 権限移譲：権限を渡すと同時に責任も渡す
➢ 権限委譲：権限を渡すが責任は⾃分に残る
➢ 責任転嫁：⾃分の責任を他⼈に押し付ける
o 経営者（管理者）はリーダーに権限を委譲する？
➢ 多様性の中で衆知を集める必要があるため権限はチームに委譲する
✓ アジャイル開発においてはリーダーが権限を持つべきではない
✓ ピラミッド型組織は同質のものを受け⼊れ，異質なものを受け⼊れない
➢ チームメンバが⾃分のこととして意識できることが重要
✓ リーダー任せにしない，指⽰待ちにならない
50
Situational Leadership http://
www.pmaj.or.jp/online/1209/pmp_bukai.html

補⾜：組織としての原則，考えるべきこと
o 最初は⾃分達の組織にどういった開発⼿法，プロセスが合うかを検討した
り，合うように変更したりしない
➢ 既に提⾔されている開発⼿法，プロセスは実践を経ているのでまずは「あるがまま」実践してみる
➢ 改善した⽅が良い部分があれば次のサイクルで改善する
o 開発⼿法・プロセスは料理のレシピ
➢ 料理をしたことがない⼈が作ったレシピは誰の役にも⽴たない
➢ アレンジャーにならない，最初はレシピ通りに作ってみる
➢ 作ってみた後でなければ味付けが⾃分に合うかはわからない
➢ 「家庭の味」ができるまでには時間がかかる
o ⼿法・プロセスを作るのは「やったことがある⼈」
➢ There is no compression algorithm for experience（経験だけはショートカットできない），Werner Vogels，
Amazon CTO
o 守破離
➢ 最初は師匠の教えや型を忠実に「守」ることから始まる
➢ ⾃分なりに型を「破」っていくことで次の段階に移る
➢ 最終的には「離」れて⾃らの型を創りだす
51

イノベーターの思考パターン
探索！探索！
Uncertainity を探す旅。確実でないも
のを探す。
頭の良い⼈は、確実なものを探す。
指令でイノベーションが出来た話は聞
いたことがない。

http://prismlegal.com/diversity-and-law-firm-decision-making/
team success
amount of diversity
creative abrasion
quick failureslow failure

誰がそのメッセージを発したのかが
⼤事じゃない．
メッセージそのものが⼤事なんだ.
シリコンバレーの信念

スタートアップの⽂化をどうやって導⼊するか
•とことん職位格差を意識させない”タメ⼝⽂化”の規範を作る．
さん付け，全員参加・全員発⾔の会議，座席配置．プロは外に居る．
•本体とは独⽴した組織を作る．
•成功例を作って，それをストーリーにし，内外に喧伝する．
•とことん外のプロと付き合う．プロの⼒を利⽤する．⾃分もその⼀⼈になる．
CVC（企業ベンチャーキャピタル）でも弱い．バッターボックスに⽴ったこ
とのないサラリーマンにすぎない．
•バッターボックスに⽴つ．
•⾝の程を知る．勝負できないならコーディネーターに徹する．

UXデザイナー
プログラマー
テスターCEO席
Airbnbにて
ダイバーシティーの例：オフィスレイアウト
企業内のコミュニケーションバリアの破壊を考え抜く．

Stanford Start-X

IoTとか⼈⼯知能とか
機械学習
ビッグデータ
ビジネス設計
システムエンジニアリング
クラウド＆データベース技術
ICT⼈材育成・スタートアップ
労働流動性(ICT領域）
企業⽂化・組織改⾰

59
イノベーション
最良の
ソフトウェア
開発環境
組織・⽂化
Enthusiasm
&
Empathy

Mick Etoh
Restless Enthusiasm

企業組織論としてのオープンイノベーション

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to 企業組織論としてのオープンイノベーション

Similar to 企業組織論としてのオープンイノベーション (20)

More from Osaka University

More from Osaka University (20)

Recently uploaded

Recently uploaded (12)

企業組織論としてのオープンイノベーション