More Related Content
Similar to LiBRA_210201/Sum2
More from Masanori Saito
LiBRA_210201/Sum2
- 1.
- 2.
- 3. サイバーフィジカルシステムとIoT データ収集 モニタリング データ解析 原因解明・発見/洞察 計画の最適化 データ活用 業務処理・情報提供 機器制御 ヒト・モノ クラウド・コンピューティング 日常生活・社会活動 環境変化・産業活動 現実世界／Physical World サイバー世界／CyberWorld Cyber Physical System／現実世界とサイバー世界が緊密に結合されたシステム アナログな現実世界のものごとやできごとを デジタル・データで捉えデジタル・ツイン （現実世界のデジタル・コピー）を作る 狭義のIoT デジタルとフィジカルが一体となって 高速に改善活動を繰り返す状態を実現 ビジネスの最適化を維持する 広義のIoT
- 4.
- 5. IoTが生みだす2つのループとテクノロジーの関係 5 現実世界のデジタル・コピー デジタル・ツイン 規則や関係 の見える化 未来予測・最適解 インサイト・示唆 機器制御・指示命令・アドバイス 最適化ループ 効率・省エネ・生産性・時短・コスト削減など イノベーション 変革ループ UX(体験価値)向上、新たな連携、利便性向上、驚き・感動など センサー センサー・チップ センサーネットワーク センサー・フュージョン など クラウド データの収集・蓄積 計算処理能力の提供 アプリケーション など AI（機械学習） データの分析 最適解の導出 規則性や関係性の見える化 など 5G（第５世代移動通信システム） 高速・大容量 他端末接続 低遅延 など アジャイル開発・DevOps 現場のフィードバックをうけて高速に改善 ニーズの変化に俊敏な対応 バグフリー・高品質なソフトウエア開発 など AIチップ 自律制御 自律連携 リアルタイム処理 など
- 6. 社会基盤のシフト 「モノ」の価値のシフト IoTがもたらす２つのパラダイムシフト 1. 現実世界のデジタル・データ化 2.ビッグデータを使ったシミュレーション 3. 現実世界へのフィードバック 1. 「ハード＋ソフト」がネットワーク接続 2. モノとクラウド・サービスが一体化 3. システム全体で価値を生成 ハードウェア ソフトウェア ハードウェア モノの価値は、 ハードウェアからソフトウェアへ そしてサービスへとシフト アナリティクス 人工知能＋シミュレーション アプリケーション クラウド・サービス ビッグデータ 現実世界のデジタルコピー 現実世界のデジタルデータ化 IoT デジタル・ツインの実現 「モノ」のサービス化 インターネット クラウド・サービス
- 7. デジタルツイン 7 電脳世界 （Cyber World） 現実世界 （Physical World） Cyber-PhysicalSystem スマートフォン 自動車 ウェアラブル 家電 スマートメーター 263 Kw ○×電力 様々なアクティビティ スマートフォン 自動車 ウェアラブル 家電 スマートメーター 263 Kw ○×電力 様々なアクティビティ データ 最適解 シミュレーション デジタル・ツインを使って最適解を導出
- 8. 工場でのデジタル・ツイン デジタル・プラント フィジカル・プラント 最適解による制御・指示 パフォーマンス・データ デジタル・ツインを使った シミュレーション センサーを使った リアルタイムなデータ取得 条件を変え実験を繰り返し 最適解を見つけ出す 変更や変化に即応して 最適状態・動きを実現 圧 力 ひずみ 振 動 重量 電 流 ・・・ リアルタイムにフィジカル・プラントの最適化を実現する リアルタイムにデジタル・ツインを生成する
- 9. 従来の工場とデジタル・ツインを使った工場の違い 9 決められた工程に従って進められるライン生産方式が主流。 混流生産もあるが、多くの製造機械によるラインを組まないと いけないので、製品の仕様を多様化することは簡単ではない。 製造実行システムは、本来は生産ラインに柔軟性をもたらすは ずだが、生産ラインを構成するハードウェアの制約によって活 用できる機能が限定的。 生産ラインで働く人々も個々の現場で全体像が把握できず、定 められた役割を果たすための作業を行う。 結果としてリアルタイムで顧客ごとの個別の要望に応えること は難しく、要望があったとしても、生産現場で動的に実現するこ とは困難。 製品個々の仕様ごとに工程の組み替えがダイナミックに行わ れる（ダイナミックセル・システム）。 顧客、機械、設備、部材、製品、作業者の情報が全て収集連 携され、製品毎に個別最適化された工程を自動的に作る。 生産工程は、コンピューター上で構築・検証され、それに合わ せた実際の工程が実行される（Cyber-Physical System）。 結果としてリアルタイムで顧客ごとの個別の要望に応えること ができ、要望があれば、生産現場で動的に実現する。 http://blog.livedoor.jp/ail01u9j10taw/archives/4075532.html
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16. ソフトウェア化するモノ 16 物理的・物質的なモノでしか実現できない部分 プログラムで制御または実現できる機能・性能 レンズ シャッター ボディなど タイヤ エンジン 車体など 機体・翼 ジェット・エンジン 燃料タンクなど シャッタースピード 発色・感度 フォーカスなど ブレーキ・タイミング エンジン制御 機器のオンオフなど 姿勢や方向の制御 エンジンの制御 機内環境の制御など ソ フ ト ウ ェ ア ハ ー ド ウ ェ ア 製造コストの低減 故障要因の低減 保守容易性の実現 できるだけ シンプルに 開発コストの低減 高機能化のしやすさ 保守容易性の実現 できるだけ 多機能に IoT化 通信機能を組み込み インターネットにつ なげることでモノを サービス化する モジュラー化 機能を標準化・部品 化することで、生産 コストの低減と保守 性を向上させる
- 17.
- 18. 「モノ」のサービス化 自動車メーカー 航空機メーカー 工作機械メーカー アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア 運行データ 走行データ作業データ 制御 制御 制御 遠隔からの保守点検・修理、自律化機能による自己点検や修復、ソフトウェア更新による機能・性能・操作性の改善 インターネット
- 19. 使 用 の現場 センサーコンピュータ ソフトウエア モノ・製品 モノのサービス化の本質 ものづくり の現場 開 発 製 造 保守 サポート ソフトウェア 改修・更新 インターネット 直 結 ・ 連 係
- 20. 製造業におけるデジタル化 調整や連携：打合せ 調整や連携：打合せ 調整や連携：打合せ Input ：人間→紙の書類 Output：紙の書類→人間 Input ：人間→コンピュータ Output：コンピュータ→人間 Input：機械→コンピュータ Output：コンピュータ→機械 デジタル化前 人間が主体で行う仕事を 機械が支援する 機械が支援して人間が仕事をする 調整や連携：機械同士 Input ：機械→機械 Output：機械→機械 管理 ：コンピュータ 目標設定：人間 デジタル化後 自律制御 監視・指示 データ＋機械学習 機械にできることは 徹底して機械に任せ 人間しかできないことを 人間が行う 機械と人間が一緒に仕事をする 自律制御 H2H Human to Human M2H Machine to Human M2M Machine to Machine
- 21. モノのサービス化の構造 21 価値を生産 価値を消費 交換価値 購買 グッズ ドミナント ロジック 企業と顧客／パートナーが共創によって、価値を創り出す関係が築かれる 価値を共創 価値を共創 交換価値 文脈価値 使用価値 サービス ドミナント ロジック 顧客による使用情報の継続的入手 ソフトウェアの更新、新たなサー ビスの提供による価値の拡大 January 2016DAIAMONDハーバード・ビジネス・レビュー別冊を参考に作成 ビジネス価値の明確化×エコシステムの構築×圧倒的ビジネス・スピード
- 22.
- 23. サプライ・チェーンとデマンド・チェーン 正確な需要予測 消費に見合った 円滑な商品の流れ を実現する 消費現場の 正確でタイムリー なデータ 消費現場の データに基づく 最適な商品の流れ を実現する POSや販売データだけでは なく、主義主張、趣味嗜好、 人生観や悩み、ライフログ、 生活圏などを含めて消費者 を深く知るためのデータ サプライ・チェーン Supply Chain デマンド・チェーン Demand Chain 日本メーカは、製造現場の改善活動やTQC（Total QualityControl）活動を中心に、SCM（サプライチェー ン・マネジメント）に力を入れ、ムダのない効 率的なものづくりで競争優位を確保してきた。 しかし、グローバル競争に突入したいま、日本 メーカのこれまでの競争戦略が通用しなくなっ ている。とくに価格競争で強みを発揮する中国 やインドがグローバル市場へ進出したことで、 日本メーカの競争力はますます低下している。 ものづくりの付加価値の源泉は、「いかに作る か」という製造生産プロセス（SCM）から、「何 を作るか」という企画開発プロセス（DCM）へと 大きくシフトしている。日本メーカはこれまで 「下り車線」のSCMには強かったが、「上り車 線」のDCMに弱かった。日本メーカの営業利益率 が低いのはそのためである。デジタル時代のも のづくりでは、利益率の低いサプライチェーン よりも利益率の高いディマンドチェーンに強い 企業が生き残るといわれる。 デジタル時代のものづくりでは、利 益率の低いサプライチェーンよりも 利益率の高いディマンドチェーンに 強い企業が生き残る可能性が高い。
- 24. 「モノのサービス化」ビジネス コア・ビジネス 既存ビジネス 蓄積されたノウハウ 確実な顧客ベース 付加価値ビジネス 収益構造の多様化 既存ノウハウの活用 顧客ベースの囲い込み 新規ビジネス 顧客価値の拡大 ノウハウの創出 顧客ベースの拡大 製造・販売 製造・販売 製造・販売 走行距離に応じた 従量課金サービス Pay by Mile 出力×時間に応じた 従量課金サービス Pay by Power 工事施工 自動化サービス Smart Constriction 建設機械 遠隔確認サービス KOMTRAX 安全・省エネ運転 コンサルティング 予防保守・交換 燃料費節約 コンサルティング 予防保守・交換
- 25. モノのサービス化 25 TOYOTA MaaS /e-Palette Concept KOMATSU SMART construction 土木工事における作業の自動化と高度化を実現す ることに加え、前後工程も効率化して、工期の短 縮に貢献できるパッケージ化したサービス 移動、物流、物販など多目的に活用できるモビリ ティサービス（MaaS）と、これを実現する専用 次世代電気自動車（EV） モノを売り収益を得るビジネス。サービスはモノ売りビジネスを支援する手段 サービスを提供し収益を得るビジネス。モノはサービスを実現なする手段
- 26. MaaS（Mobility as aService） 26 電車 タクシー バス レンタカー 自家用車 配車サービス カーシェア 自転車シェア 電車 タクシー バス レンタカー 自家用車 配車サービス カーシェア 自転車シェア MaaS 経路検索 支払 予約 配車手配 現 在 MaaS あなたのポケットに全ての交通を 個人で所有・個別に手配 手段の提供：マイカーの所有や個別の手配･予約ではできない最適化された「移動体験」提供 価値の実現：マイカー利用を減らし環境負荷の低減や移動の利便性・効率化を実現
- 27. MaaS（Mobility as aService） 27 電車 タクシー バス レンタカー 自家用車 配車サービス カーシェア 自転車シェア MaaS 経路検索 支払 予約 配車手配 MaaS 交通についての悪しき悪循環 地方へ行くほどマイカーへの依存度が高くなる。 自動車は移動手段としては便利だが、保有コストが高いわ りには、稼働率は低い。 大気汚染や渋滞による社会的ロス、交通事故の死亡者数は 世界全体では年間100万人を超えている。 公共の交通機関の運営が、マイカー保有により危機に瀕し ている。乗り合いバスの利用者は近年大きく減少しており、 赤字で路線廃止に陥るケースが続いている。 公共交通路線の廃止により、移動手段がますますマイカー に偏り、公共交通機関の運営をさらに苦しめている。 MaaSによって悪循環を解消 公共交通が整備されると人々の流れが変わり、ガソリンや駐 車場代に向けられていた支出が、公共交通に回るようになる。 それによって地域全体が活性化する。 渋滞や交通事故の発生が減少すれば、社会全体のロスも低下、 行動履歴をビッグデータとして把握できれば、道路や都市計 画に活用できる。 高齢者や障害者などのハンディキャップを抱えた方々の移動 が容易になる。 運転ができるかできないかで住む場所が限定されるという不 自由さがなくなる。 マイカーに偏る今の社会が解消され、個人の暮らしは改善し、 街の中心部も活性化して地域が抱える問題の多くが緩和する。 公共交通も含めた交通手段の多様化により、 様々な社会的課題を解決できる可能性がある。
- 28. MaaSのレベル定義 28 スウェーデン・チャルマース大学の定義 社会全体目標の統合 Integration of socialsocial スマートシティーのような上位の政策目標に統合された移動 手段を実現するサービスを提供 提供するサービスの統合 Integration of the service offer 予約や決済に加えて、サービス独自の料金体系を持ち、異な る移動手段をシームレスにつなぐサービスを提供 予約と支払いの統合 Integration of booking and payment 異なる移動手段をまとめて検索でき、予約や手配も行うこと ができる統合サービスを提供 情報の統合 Integration of information 異なる交通手段の情報を統合して提供 統合ない No integration 事業者個別に移動手段や附帯するサービスを提供 レベル 4 レベル 3 レベル 2 レベル 1 レベル 0 個別の交通事業者が提供する移動手段やカー シェア、自転車シェアなどのサービス Google Map、NAVI TIME、乗り換え案内 Citymapper、シアトルのTripGo、などによ るルートや所要時間、料金の検索など ダイムラーのMoovel、ロサンジェルスのGo LAなど フィンランドのWhim、スイスのGreen Classなど 該当するサービスがない MaaSに相当するサービス
- 29.
- 30. ビジネスス・モデルの変革 VISION-S Prototype WOVENCity e-palette エンターテイメント・デバイス エンターテイメント空間として サービスを提供するためのデバイス サービス・プラットフォームとして コネクテッドな時代の 社会・生活空間として コネクテッドな時代のビジネスの可能性・新たな生き残り戦略の模索
- 31. コ ト づ く り 顧客価値 価値実装 体験 更新 心地良い・使い易い もっと使いたい ずっと使い続けたい 継続的な改善 最適を維持 顧客の期待を先回り UX ソフトウエア 「モノのサービス化」の構造 機能 仕様 モ ノ づ く り ハードウェア UI サービス・ビジネスとは、コトの価値を提供し続けるビジネスのこと
- 32.
- 33. ビジネス価値のシフト モノづくり：サプライヤー／部品メーカーへの依存拡大 先進運転支援システム/ADAS Advanced driver-assistance systems 自動運転システム/ADS AutonomousDriving System 自動運転システム/ADS Autonomous Driving System 移動サービス／MaaS 等 移動サービス／MaaS 等 車両／ハードウェア 車両／ハードウェア 車両／ハードウェア コトづくり：自動車メーカーの事業の重心がシフト データ Data 差別化の対象 差別化の対象 差別化の対象 ソフトウェア ソフトウェア
- 34. 自動車／移動ビジネスの3つの戦略 SONY Vision S Concept UX（体験） 機能（移動） モノ （所有） サービス （使用） 従来までの 自動車メーカー サブスク MaaS Mobilityas a Service ? 自動車メーカーのUX実現支援 自動運転ソフトウェア ビジネス・モデル の転換 ビジネス・モデル の拡張 ライドシェア
- 35. 属性データと行動データ 性別・年代・結婚・職業・・・ 女性・20代・独身・事務職・手芸が好き・・・ 属性に応じて最適化された 機能・性能・品質の提供 属性データ 属性（静的）データ ✖️商品（モノ） 商品力向上＝調査✖️技術開発✖️製造技術 個 人 場所・時間・体験・感情・・・ 競技場・夏の夕方・サッカー観戦・勝利の喜び・・・ 状況に応じて最適化された 感動・楽しさ・共感の提供 行動データ 行動（動的）データ ✖️ UX（体験） 共感 デジタル接点・取得頻度の 増加によって解像度が上昇 UX向上＝多接点✖️高頻度✖️高速改善 状況 主義主張・人生観・価値観・悩み・生活圏・・・
- 36. データとモノ／コト・ビジネスの関係 属性データ 商 品販売代金 属性に最適化された 商品の作り込み 魅力的な商品を作る 属性理解→商品設計→商品開発 行動データ UX サブスク 従量課金 状況に最適化された UXのアップデート 魅力的な体験を作る 状況理解→UX設計→UX開発 体験を継続したいという想いへの対価 商品を手に入れることへの対価 行動データ 商 品 販売代金 うまくいかないビジネス 行動データを取得する意味がない 商品の機能や性能を アップデートできなければ意味がない アップデートのコストをまかなえない
- 37.
- 38. 体験データを手に入れるためのプラットフォーム モノ 魅力的な機能・性 能・品質を実装し たカタチある商品 コト 適切なタイミング に便利で必要十分 なサービス 生活 楽しい、心地良い、 使い続けたいなどを 感じさせる物語・ ジャーニー 惣菜パン 生命保険 自動車 など コンビニ ライフランナー 販売店・営業 など 決済・ポイント コミュニケーション 移動サービス など モノとコトをつないだ 体験データを掌握 プラットフォーマー
- 39. 体験とスーパーアプリ スーパーアプリ：メッセージングやソーシャルメディア、決済、送金、タクシー配車、飛行機やホテ ルの予約、Eコマースなど、スマホで一般的に行われるサービスがすべて詰まっている。何かをする度にい くつもアプリを立ち上げる煩わしい手間が不要となり、ユーザーにとっての利便性は極めて高い。 SNS 配車 決済 送金 その他 アプリ ビデオ 通話 SNS 配車 決済 送金 その他 サービス ビデオ 通話 スマートフォン・モバイル端末スマートフォン・モバイル端末 Apple iPhone,Google android端末 スーパーアプリ Apple iPhone,Google android端末 Apple App Store,Google Play Store Apple App Store,Google Play Store Facebook Uber PayPay Zoom 各ベンダー WeChat,Alipay,Go-Jek,Grab,Paytmなど Line & PayPay,Uber,Facebookなどが同様のポジションを狙う スーパーアプリによるユーザー体験の一元的把握により、ユーザー毎のきめ細かな個別最適化され たUXが提供できるようになり、圧倒的な競争力の確保につながる。
- 40.
- 41. プラットフォーム・ビジネスを成功させる3つの要件 ビジネス価値の明確化： テクノロジーではなく、Purpose 魅力的なVisionによる求心力 エコシステムの構築： 調整力より、リーダーシップ 囲い込みからオープン・イノベーション 圧倒的ビジネス・スピード： 外注ではなく内製 アジャイル開発×DevOps×クラウド Purpose Vision Speed プラットフォーム・ビジネス ビジネス・モデル × ビジネス・プロセス × 事業戦略
- 42.
- 43. ハブ型社会からメッシュ型社会へ 43 メッシュ型社会 ハブ型社会 情報の非対称性・権力の偏在 情報伝達に伴うタイムラグの拡大 仲介による情報伝達コストの増加 情報の双方向性・権力の分散 情報伝達に伴うタイムラグが発生せず 仲介を無くすことで情報伝達コストが低減 シェアリング・エコノミー ホスティング・エコノミー 安い社会コストとフラット化 高い社会コストと階級化
- 44.
- 45. インダストリー4.0がやろうとしていること 45 標準化 複雑なシステムの管理 通信インフラの高度化 安全と情報セキュリティ 労働組織とワークライフバランス 人材育成、専門能力の開発 規制の枠組 エネルギー効率 通信規格の国際標準化 サプライチェーンや顧客との間でリアルタイムにデータを共有・分析 設備稼働率平準化、多品種変量生産、 異常の早期発見、需要予測などが可能に ドイツの２つの狙い 国内製造業の輸出競争力強化 ドイツ生産技術で世界の工場を席巻 インダストリー4.0仕様の生産システムがコスト競争上優位となり、我が国企業の海外生産 における競争力劣位が発生するおそれあり。 インダストリー4.0仕様の標準化が進むと、我が国のＦＡ関連機器が海外市場において参入 できなくなるおそれあり。
- 46. コレ１枚で分かるインダストリー4.0 46 インダストリー4.0 Industry 4.0 自ら考える工場 製造コストの極小化 個別仕様オーダーでも 量産品と同じコストで対応 カスタマイズ対応 お客様毎に異なる 個別仕様のオーダーに対応 短納期対応 個別仕様オーダーでも 短納期で対応 IoT Internet ofThings 工場内外の設備、機器、 部材からの情報を収集 IoP Internet of People 工場や関係事業所で働 く人々の情報を収集 IoS Internet of Service ECサイト、店舗、 サポート拠点な どからのサービ ス情報を収集 Cyber-Physical Systems 他工場 他工場 他工場 他工場 Internet 人工知能 ロボット
- 47. 産業革命の区分 47 電力 蒸気機関 人力・自然力 大量生産 注文生産 多品種化 マス・カスタマイゼーション パーソナル・ファブリケーション 機械生産 手作り コンピューターによる自動化 標準化・規格化 個別仕様 個別仕様 コンピューターによる自律制御 工場・機器・人間の自律連携 産業革命以前 第１次産業革命 第２次産業革命 第４次産業革命 第３次産業革命 水力 馬力 蒸気機関 鉄道 化学産業 科学的管理 コンピューター インターネット IoT/ビッグデータ 人工知能/クラウド 第１次産業革命 第２次産業革命 第３次産業革命 米国での理解 ドイツでの理解 産業革命以前 18世紀中〜 20世紀初〜 2010年代〜 1970年代〜 デジタル・ファブリケーション時代 農業社会から工業社会への転換 労働力の田園地帯から都市部への移動 資本家や企業の台頭と労働者との役割分離 内燃機関
- 48. インダストリー4.0（第4次産業革命）とIoT 48 第１次産業革命 Industry 1.0 第２次産業革命 Industry 2.0 第３次産業革命 Industry3.0 第４次産業革命 Industry 4.0 機械化 効率化 自動化 最適化 水力・蒸気機関 手仕事から機械を利用 電力・科学的管理 統計的手法と電気による制御 コンピュータ 労働力を機械に置き換え デジタル 生産性を維持し個別最適 製造業 製造業 製造業 製造業 ＋ 非製造業 18世紀後半 20世紀前半 1970年代以降 2015年代以降 科学的管理 ERP 情報の一元管理と連係 前工程 生産 後工程 デジタル 社内外を含めたデジタル連係 自 動 化 自 動 化 自 動 化 自 動 化 自 動 化 第２.5次産業革命 Industry 2.5
- 49. ドイツでインダストリー4.0の取り組みが始まった背景 49 経緯： 少子高齢化による労働人口減少や原発の停止等に起因する国内立地環境の悪化 ドイツ国内でGDPの約25%・輸出額の約60%を占める製造業の存在感が低下 ＥＵ全域でアジアへの製造業流出の懸念 2011年11月、独政府は“High-Tech Strategy 2020 Action Plan” のプロジェク トの1つとして、 独製造業の競争力強化のための構想であるIndustry4.0を提示 連邦教育研究省（BMBF）、連邦経済エネルギー省（BMWi）が所管 実施主体： ドイツ機械工業連盟（VDMA）、ドイツ情報技術・通信・ニューメディア産業連 合会（BITKOM）、ドイツ電気電子工業連盟（ZVEI）を事務局とする、産学連携 プラットフォーム
- 50. 第4次産業革命（インダストリー4.0）とIoT 50 Recommendations for implementingthe strategic initiative INDUSTRIE 4.0 【第１次：機械化】 【第２次：電力活用】 【第３次：自動化】 【第４次：自律連携】 Cyber-Physical System 蒸気機関 大量生産 移動手段の革新 電力 科学的管理 化学産業の発展 コンピュータ 自動制御 大量生産と品質安定 IoT/M2M 自律制御 つながる工場
- 51. インダストリー4.0を支える繋がり 51 Recommendations for implementingthe strategic initiative INDUSTRIE 4.0
- 52. 従来の工場とインダストリー4.0がめざす工場の違い 52 決められた工程に従って進められるライン生産方式が主流。 混流生産もあるが、多くの製造機械によるラインを組まないと いけないので、製品の仕様を多様化することは簡単ではない。 製造実行システムは、本来は生産ラインに柔軟性をもたらすは ずだが、生産ラインを構成するハードウェアの制約によって活 用できる機能が限定的。 生産ラインで働く人々も個々の現場で全体像が把握できず、定 められた役割を果たすための作業を行う。 結果としてリアルタイムで顧客ごとの個別の要望に応えること は難しく、要望があったとしても、生産現場で動的に実現するこ とは困難。 製品個々の仕様ごとに工程の組み替えがダイナミックに行わ れる（ダイナミックセル・システム）。 顧客、機械、設備、部材、製品、作業者の情報が全て収集連 携され、製品毎に個別最適化された工程を自動的に作る。 生産工程は、コンピューター上で構築・検証され、それに合わ せた実際の工程が実行される（Cyber-Physical System）。 結果としてリアルタイムで顧客ごとの個別の要望に応えること ができ、要望があれば、生産現場で動的に実現する。 http://blog.livedoor.jp/ail01u9j10taw/archives/4075532.html
- 53.
- 54. 54 製造業とそれに関連する産業 製造業に限らず広範な産業 Industrial Internet とIndustry4.0 Industrial Internet Industry 4.0
- 55.
- 56. Industrial Internet とIndustry4.0おける標準化の取り 組み 56 IIRA IIC Reference Architecture RAMI4.0 Reference Architecture Model Industrie 4.0 デジュール寄り 国際標準化組織による標準 デファクト寄り 市場の要請などによる事実上の標準 マッピングの比較・分析リーダー by 日本
- 57. インダストリー・インターネットのモデルベース開発 57 自動車の高機能化（電子制御、安全運転支援システム、快適性、ネットワーク化）、パワートレイン 方式の多様化等により、設計開発業務は複雑化。一方で、製品の開発サイクルは短縮化。 こうした状況に対応するため、モデルベース開発（モデル化、シミュレーションを活用し開発を進め る手法）がエンジン開発を中心に進展。 開発環境の変化に対応できない中小サプライヤーが、欧州メガサプライヤー等に淘汰される可能性も 存在。 航空機分野は、安全性要求の高さ等から自動車に比べモデルベース開発が先行。重工各社は、モデル ベース開発を踏まえたエンジン部品開発を、エンジンメーカー（GE、P&W、R&R)に提案し付加価値 を獲得。
- 58. 日本産業システムが抱える課題 58 製造プロセスのデータ収集・活用によるカイゼン活動（暗黙知の形式知化、不可視知の可視知化）に は多くの日本企業が取り組んでいるが、カイゼン以上の付加価値提供にまでは至っていない。 他方ＧＥは、データ解析ツールの外販により、様々な分野で他社製の機器も含めたデータプラット フォーマーとなる動き。 今後、付加価値獲得競争が激化する中でビジネスモデルの構築が課題。 ITを活用した生産自動化により、工場内の生産性向上の分野では世界をリード。必要に応じて、混流 生産（一つのラインで複数の製品を生産）も実施。 → 大量生産を念頭に置いたもので、機械どうしを繋ぎ自律的に生産ラインを変えて 変種変量生産を実現する動きには至っていない。 我が国にも、製造物や生産ラインに取り付けたセンサーからデータを取得し、製品の保守や生産ライ ン効率化に活用する先進的な動きがある。 → 自社で閉じたシステムで、ＧＥのように競合他社へのシステム提供を通じ付加価値 を獲得しようとする動きにまで至っていない。 製造業のデジタル化による「つながり（Connectivity)」（工場内の機械や製品などのモ ノのデジ タルなつながり）が、消費者の多様な需要に対応した変種変量生産ラインの構 築に不可欠。 → デジタルものづくりのプラットフォームとなるツールやそれを工場内に導入するSＩer不足 データの蓄積・解析による付加価値づけが、競争力の源泉へ。 → データ蓄積のためのプラットフォーム作りを率先して行うことが必要。 → データの解析を通じた予測モデル等の付加価値づけにむけた人材が不足。 国際標準化、サイバーセキュリティへの対応。 → IEC（国際電気標準会議）で始まっている国際標準化活動に積極的に参画することが必要。
- 59.
- 60. 1G 2G 3G4G 5G 音声 テキスト データ 動画 あらゆるモノがつながることを前提とした 社会課題の解決 通信・コミュニケーションの性能向上 移動体通信システムの歴史 1979〜 1993〜 2001〜 2012〜 2020〜 9.6Kbps 28.8〜384Kbps 2.4〜14.4Mbps 0.1〜1Gbps 10Gbps〜
- 61. 5Gのビジネスの適用領域 データ量超増大 × 即時性向上 1通信あたりのデータの嵩が増える リッチ化する：高精細や高音質になり臨場感、没入感 が増す 多角化する：同時に取り扱える情報の選択肢が増える 1通信あたりのデータの種類が増える 制御用の情報（センサーやカメラからの情報）が増え る：自動○○が実現する 参考可能な情報（ログ情報）が増える：パーソナライ ズのパターンが増える、レコメンドの精度が向上する、 対象への理解が深まる タイムラグがほぼ無くなる 距離の制約が消える：各地に散らばる人たち同士で同 時に何かやる、今やった/起きたことをすぐに取り込 んですぐ活かす 社会（利便性）向上系 医療分野 超高信頼低遅延通信の実現で移動中や遠隔地の高度診療が可能になり、 医療格差が解消される 農林水産分野 超大量端末同時接続の実現で作物や家畜などの状況を把握するセン サーと散水・薬剤散布や給餌を実施するロボットやドローンの制御が 可能になり、減少する従事人口を補える 土木建築分野 超大量端末同時接続と超高信頼低遅延通信の実現によって遠隔制御が 可能になり、危険度が高い高所・鉱山・災害地などの現場での安全な 作業が確保でき、またドローンの活用による高精度測量などの精度が 向上する 生活分野 自動運転と遠隔制御によって、細分化された公共交通が実現する センサー情報を駆使して状況を把握する店舗運営が可能になる 遠隔授業や家庭教師の実現によって、学習格差が解消される 大量センサーと自動判定AIによって、防災・防犯・減災力が向上 VRオフィスとテレワークが実現する コンテンツ向上系 スポーツの場合⇒体験が深くなる 自動制御が可能になってカメラ台数を一気に増やせることで、多地 点・ドローンなどによる多角度撮影ができるようになる 取得データの種類が増え分析できる情報が増えることで、選手のバイ タルデータ・顧客のバイタルデータ・環境データが取得できるように なる AIが発達することでデータの有効活用レベルが上がり、多角的な分析 結果を提示できるようになる エンタメの場合⇒現実を超える仮想実現へ 即時性が向上することで出演者の居場所を問わない制作環境を実現さ せることや、同時多人数対応の参加型体験の提供ができるようになる スポーツ＆エンタメに共通 1通信あたりの送信データの嵩が増え、高画質・高音質・8K360°リ アルタイムな高臨場感映像が提供できるようになり、また視聴者に合 わせた多種多様な映像・情報を提供できるようになる 生活者データ・ドリブン・マーケテイィング通信より https://seikatsusha-ddm.com/article/10129/
- 62. コレ１枚でわかる第５世代通信 1G 2G 3G 4G 高速・大容量データ通信 10G〜20Gbpsのピークレート どこでも100Mbps程度 大量端末の接続 現在の100倍の端末数 省電力性能 超低遅延・超高信頼性 1m秒以下 確実な通信の信頼性担保 5G 音声 テキスト データ 動画 IoT 多様なサービスへの適用を可能にする 異なる要件のすべてを1つのネットワークで実現する。 各要件をに応じてネットワークを仮想的に分離して提供する（ネットワーク・スライシング）。 1979年〜 1993年〜 2001年〜 2012年〜 2020年代〜
- 63. 5Gの3つの特徴 先送り 高速・大容量 大量端末接続 超低遅延・高信頼性 100万台/k㎡ 1ミリ秒 20Gビット/秒 1Gビット/秒 10万台/k㎡10ミリ秒 20 倍 5G 4G URLLC： Ultra-Reliable and Low Latency Communications mMTC： massive Machine Type Communications eMBB： enhanced Mobile Broadband リアリティの再現 光ファイバーの代替／補完 高精細／高分解能な デジタル・ツインの構築 時空間の同期 リアルタイム連携
- 64. 5Gの３つの特性 URLLC：Ultra-Reliable andLow Latency Communications／超低遅延・超高信頼性 eMBB：enhanced Mobile Broadband／高速大容量通信 mMTC：massive Machine Type Communications／大量端末接続
- 65. 第５世代通信の適用例 高速・大容量データ通信 10G〜20Gbpsのピークレート どこでも100Mbps程度 大量端末の接続 現在の100倍の端末数 省電力性能 超低遅延・超高信頼性 1m秒以下 確実な通信の信頼性担保 5G 多様なサービスへの適用を可能にする 異なる要件のすべてを1つのネットワークで実現する。 各要件をに応じてネットワークを仮想的に分離して提供する（ネットワーク・スライシング）。 2020年代〜 ２時間の映画を ３秒でダウンロード ロボット等の 精緻な遠隔操作を リアルタイムで実現 自宅内の約100個のモノ がネットに接続 (現行技術では数個) 現在の移動通信システムより 100倍速いブロードバンドサー ビスを提供 利用者がタイムラグを意識 することなく、リアルタイ ムに遠隔地のロボット等を 操作・制御 スマホ、PCをはじめ、身の 回りのあらゆる機器がネッ トに接続
- 66. 5Gの普及段階 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 4G（LTE） 4Gコアネットワーク LTE 基地局 4Gコアネットワーク LTE 基地局 NR 基地局 マクロセル スモールセル 既存周波数帯 新しい周波数帯 NSA NSA: Non-Standalone 5Gコアネットワーク LTE NR 基地局 既存周波数帯新しい周波数帯 SA SA: Standalone マクロセル スモールセル NR ユーザー情報 制御情報 ユーザー情報 ユーザー情報 制御情報 SA LTE: Long Term Evolution NR: New Radio 5G初期 5G普及期 2010〜 2020〜 2022〜
- 67.
- 68.
- 69.
- 70. 第５世代通信におけるネットワーク・スライス 高速・大容量データ通信 大量端末の接続 超低遅延・超高信頼性 5G ネットワーク・スライシング SIM SIM SIM 閉域網 閉域網 閉域網 SIM SIM SIM(subscriberidentity moduleもしくはsubscriber identification module/SIMカード)とは、電話番号を特定するための固有のID番号が記録された、 携帯やスマートフォンが通信するために必要なICカードのこと。
- 71.
- 72.
- 73.
- 74.
- 75. AIとAGIの関係 汎用型人工知能 AGI : ArtificialGeneral Intelligence 特定の領域に特化した 知的処理 汎用的で自律的に拡張する 知的処理 特化型人工知能 AI : Artificial Intelligence 何を知るべきを見つける どうすればいいかを探す
- 76. 知能・身体・環境とAI 76 生物／生存と繁殖 自己概念 信念、欲求、感情、理性、自己意識 感覚器 運動器官 骨格、関節、筋肉、靭帯、腱 環境／ガイア仮説 身体 影響 受容 相互作用・適応 エネルギー循環 誕 生 死 滅 進化遺伝・淘汰・絶滅 IoT ロボティクス 地球と生物が、相互に 関係し合い環境を作る 認識 判断 運動構成 AI/人工知能 繁 殖 長く生き延び 子孫を残す 内分泌系
- 77.
- 78.
- 79. 79 ある ない ある ない あるない ある （少ない学習データ） ある （膨大な学習データ） 高い 低い (ひとつの知的処理に特化) 高い 低い 低い 高い 人間は身体に備わる様々な感覚器からの情報も含め総合して知覚・認識 しているが、機械には身体がないのでそれができない。 自分が現在何をやっているか、今はどんな状況なのかなどが自分でわか る心の働きである意識により、人間は様々な知的処理を同時に実行し、 それを統合・制御しているが、機械にはできない。 人間は、自分の考えや選択を決心し、実行する能力、あるいは、物事を 成し遂げようとする意志を持っているが、機械にはない。 人間は少ない学習データからでも効率よく学習できる能力をそなえてい るが、機械は膨大な学習データとそれを処理できる膨大な計算能力（消 費エネルギー）を必要とする。 人間はひとつの脳で様々な種類の知的処理が可能だが、機械は特定の知 的処理に特化している。 人間は、神経の機能単位が消失しても、それを自律的に補填・回復させ ることができるが、機械にはそれができない。 人間の場合、１千億個のニューロンによる超並列処理がおこなわれてい るが、その数を増やすことはできない。しかし、機械のプロセッサーは 増やすことはできる。 人間の知性と機械の知性 意識 身体性 意志 学習能力 汎用性 可塑性 スケーラ ビリティ 高い 低い 人間の脳の消費エネルギーは思考時で21ワット/時程度のエネルギーを 消費するが、機械の場合はその数千倍から数万倍を必要とする。例えば、 GoogleのAlphaGoの消費電力は25万ワット/時とされている。 エネルギー 効率 ある ある 共に記憶能力はあるが、人間の場合は、身体的な感覚を含む記憶が可能 であり、記憶内容やメカニズムは必ずしも同じではない。 記憶能力 機 能 的 特 徴 器 質 的 特 徴 人間の知性 機械の知性 補足説明
- 80.
- 81.
- 82.
- 83.
- 84. 第3次AIブームの背景とこれから 84 1960 1970 19801990 2000 2010 2020 2030 第1次AIブーム 推論・探査など ゲームや迷路などに 用途は限られ実用性は 無かった 第2次AIブーム ルールベースなど エキスバーとシステムと して実用化されたが汎用 性が無かった 第3次AIブーム 機械学習（統計確率論や深層学習など） 汎用性、実用性が高まり、様々な分野の適用 が期待されている 大型コンピューター メインフレーム パーソナル・コンピューター スマート フォン IoT ビッグデータ時代の到来 ARPAnet 米国・インターネット 商用利用開始 日本・インターネット 商用利用開始（IIJ） World Wide Web が開発され公開 画像が扱えるWWWブラウザー Mozaicが開発され公開 Windows95発売 IEが付属し、ブラウザーでの インターネット利用者が拡大 ISLVRCにて ディープラーニング圧勝 1969 1990 1993 1995 2012 Googleによる 猫認識 2011 Jeopardyにて IBM Watson勝利 電脳将棋 竜王戦 開始 1997 チェス・チャンピオンに勝利 IBM Deep Blue 2007 iPhone 発売 1981 IBM PC 5150 発売 汎用人工知能 Artificial General Intelligence 登場の可能性 ムーアの法則／コンピュータ性能の加速度的向上 1965〜 ムーアの法則の限界／新たな選択肢の登場 GPGPU、ニューロモーフィング・チップ 量子コンピュータ等 IBM S/360 メインフレーム 1964 ニューラル ネットワーク 考案 Intel 404 マイクロプロセッサ 1971 データ流通量 1957 1956 ダートマス 会議 1982 第５世代 コンピュータ プロジェクト
- 85.
- 86. 人工知能と機械学習の関係 86 人工知能 Artificial Intelligence/AI 機械学習Machine Learning ニューラル・ネットワーク Neural Network 深層学習 Deep Learning 人間の”知能”を機械で 人工的に再現したもの 強いAI:コンピュー タに人間と同様の知 能を持たせた仕組み 弱いAI:コンピュー タに人間と同様の知 的な振る舞い・処理 をさせる仕組み データからグループ分 けのためのルール（モ デル）を作る仕組み 脳の仕組みを参考に作 られた機械学習の手法 従来よりも精度の高いモ デルを作ることができる ニューラル・ネットワー クの手法 遺伝アルゴリズム、エキスパートシステム、音声認識、画像認識、感性処理、機械学習、 ゲーム、自然言語処理、情報検索、推論、探索知識表現、データマイニング、ニューラル ネット、ヒューマンインターフェース、プランニング、マルチエージェント、ロボット データ プログラム モデル
- 87.
- 88. 機械学習がやっていること モデル レントゲン写真から 「癌」の病巣を 識別するルール 入力 出力 癌 データ分析で ルールを作る 機械学習 癌の病巣が写っている 大量のレントゲン写真 ある患者のレントゲン写真「癌」の病巣を表示 レントゲン写真から 「癌」の病巣を見つける「モデル」
- 89. 機械学習がやっていること モデル 推論モデル／学習モデル 入力 出力 Y＝f(X) X Y f関数 学習：大量のXとYの関係を調べ、統計的に最も確からしい関数 f を見つける計算 推論：関数 f に入力Xを与え、出力Yを導く計算 学習データ 大量のデータを処理するため の計算資源が必要 学習ほどの計算資源は不要
- 90. ルールベースと機械学習 Sheep Dog を見分ける仕様 やルール = ifXX Then XXX else XXX Mop を見分ける仕様 やルール = if XX Then XXX else XXX Sheep Dog を見分ける仕様 やルール 0101011101010 1110101001011 1110010101010 Mop を見分ける仕様 やルール 0111100101010 1101010001010 1110100100101 人間が記述 データから生成 GoogleのAI学習教材より
- 91. 機械学習の仕組み 91 IoT Web Mobile データ モデル 推論 機械学習 Machine Learning 識別 予測判断 ゾウ or カバ？ 正常 or 異常？ 晴れ or 雨？ データ(学習データ)を分析して 特徴が共通するグループに分ける ための基準／ルール(モデル)を作る モデルを使ってグループ分けする 音声認識 顔認証 自動運転 創薬支援 天気予報 画像診断 人材採用 故障予測 機械翻訳 競技アドバイス 惑星探査 ヒビ割れ点検 製品品質検査 機械学習アプリケーション 推論モデル／学習モデルという 学習データという
- 92. 学習と推論 92 大量の学習データ 機械学習 学習済 推論モデル アプリケーション 対象 データ 推論 エンジン CT画像データ 通話音声データ LIDERデータ など 推論 判別 画像：癌病巣の発見 音声：話者の特定 センサ：障害物回避 など GPUや専用LSIを使用 消費電力より並列処理性能を優先 FPGAやDSPなどを使用 高速処理と低消費電力を優先 GPU: 大規模並列処理可能なプロセッサ FPGA:プログラミング可能なLSI DSP:信号処理に特化したLSI LIDAR:レーザーの反射光から周辺環境の3次元的な構造を読み取る装置 学習 Learning 推論 Inference
- 93.
- 94.
- 95. 自動化ツール Google Cloud AutoML MicrosoftAzure ML AWS SageMaker など AIと人間の役割分担 データを準備 意志決定 学習方式の選択 パラメーターの調整 可視化・分類・予測 問いを生みだす 解決したいこと・知りたいことを決める 膨大なデータの中から、人間 の経験に基づく先入観なしに 規則、相関、区分を見つける 新たな問いを生みだす 判断・制御 モデル 公式・ルール・関数など
- 96.
- 97.
- 98. 機械翻訳の現状とそのプロセス 音声認識 Speech Recognition 機械翻訳 machine translation 音声合成 Speech synthesis 2016：人間並み 2018〜19：人間超え 2018〜19：人間との区別困難 プロの逐次翻訳に匹敵（状況による） 60 50 40 30 20 10 一般の人が翻訳した場合よりも高品質であることが多い 非常に高品質で適切かつ流暢な翻訳 高品質な翻訳 理解できる適度な品質の翻訳 主旨は明白だが文法上の重大なエラーがある 主旨を理解するのが困難 ほとんど役に立たない BLEUスコア 198519901995 2000 2005 2010 2015 2020 統計的機械翻訳 SMT(Statically Machine Translation) ニューラル機械翻訳 NMT(Nural Machine Translation) BLEU: BiLingual Evaluation Understudy
- 99.
- 100.
- 101.
- 102. デジタル化 実践のステージ 102 Stage Ⅲ 自律 Autonomy StageⅡ 自動 Automation Stage Ⅰ 操作 Operation Stage 0 監視 Monitor 事実 把握 実行 適用 判断 ルール 設定 修正 最適化 目的 設定
- 103. 人間とAIの役割分担 人間にしかできないこと AIに任せた方がいいこと 疑問や興味を持つ 課題を持ち解決したいと思う 目的やテーマを設定する 結果をイメージできる 行動に意味を与える 最適な結果を高速に見つける 大規模データを高速に計算する 試行錯誤を高速に繰り返す 膨大な選択肢を絞り込む 膨大な組合せを検証する 意欲や興味、想像、意味付け 高速・大量な論理演算、検索と比較 マシンは答えに特化し、人間はよりよい質問を長期的に 生みだすことに力を傾けるべきだ。 “これからインターネットに起こる『不可避な12の出来事』” ケビン・ケリー・2016
- 104.
- 105.
- 106.
- 108.
- 109. 機械学習の活用プロセス 109 モデル運用 機械学習 モデル作成 学習データ 収集・加工 学習データ 定義 問題定義 問題発見 ゴール設定・KPI定義 業務方針決定 ノウハウの形式知化 目的変数の決定 説明変数決定 データソース決定 データ収集 加工プログラム開発 アルゴリズム選択 コーディング パラメータチューニング 環境構築 コーディング デプロイ&テスト 経営や業務 業務 IT 計算科学 統計学 計算科学 IT 業務 プロセス タスク スキルや知識
- 110.
- 111.
- 112.
- 113. システムの開発と運用とは システム 開発 Development アプリケーション を実行可能にする こと アプリケーショ ンを企画設計し プログラムを作 ること。 最適な技術を目 利きし、その適 用方法を決める こと アプリケーショ ンを動かすため の仕組み（プ ラットフォーム とインフラ）を 整えること システム 運用 Operation アプリケーション やプラットフォー ムとインフラを安 定して動かし続け ること 稼働状況やトラブ ルの監視 万が一のための バックアップや復 旧（リカバリー）、 安定稼働のための 改善など ユーザーからの問 い合わせやトラブ ル対応に対処する こと インフラストラクチャー サーバー、ストレージ、データセンターなどのハードウェアや設備 プラットフォーム データ管理、セキュリティ管理、通信、ハードウェア制御、決済などの共通機能 アプリケーション 会計管理、販売管理、オンライン・サービスなどの 業務成果を生みだすソフトウェア／プログラム 開発や実行のための環境の整備 プログラミング・テスト 概要設計・詳細設計 企 画
- 114. システム化の対象範囲は「レベルA」以上 レベルD 存在しない レベルC 初期段階 レベルB 反復可能だが直感的 レベルA 標準プロセスが定義されている レベルAA 管理が行き届き測定可能 レベルAAA 最適化されている Source: Capability MaturityModel Integration, CMMI システム化 の対象範囲 システム化 の対象範囲外
- 115.
- 116.
- 117. システム構築事例 ：大手オンライン・サービス事業者 財務会計・人事 Netsuite 管理会計 Tableau 勤怠・給与 e-Pay 経費精算 Concur 連結会計 Diva 人事ダッシュボー ド QlicView 考課・目標管理 Cydas KPI管理 内製 作画・共有 Cacoo 情報共有 Quita 進捗管理 Tollelo 開発ソース管理 GitHub 開発案件管理 Jira 開発情報Wiki Confluence ファイル共有 Box シングル サインオン Okta メール G Suite チャット Slack 無人受付 Smartat ワークフロー kintone 名刺管理 sansan マーケティング Marketo 基幹業務 システム開発 コミュニケーション その他 クラウド SaaS オンプレミス パッケージ オンプレミス 内製 クラウド・サービス利用することで、構築や運用の負担を減らし、「最新」の価値を享受
- 118.
- 119.
- 120.
- 121. ビジネス・スピードの加速を支える開発と運用 アジャイル開発 Agile Development ビジネスの成果に貢献するコードだけを 変更に柔軟・迅速に対応して バグフリーで提供する DevOps Development & Operation 運用の安定を維持しながら 本番環境への迅速な移行と 継続的デリバリー クラウド Cloud Computing 最新・高速・俊敏な開発実行環境の調達 経費化による不確実性への担保 運用やセキュリティから解放と人材の再配置 デジタル・トランス･フォーメーション
- 122.
- 123.
- 124.
- 125.
- 126. ウォーターフォールとアジャイルの違い 用意されたプロセスやツール 全てを網羅したドキュメント お互いの妥協点を探る契約交渉 一度決めた仕様や計画に従うこと システムを納品すること 計画通りに完成させること 「計画通り」が正義という信念 自律的な判断と行動 実際に使う動くソフトウェア 顧客との対話と協調 変更や変化への柔軟な対応 ITサービスを提供すること ビジネスを成功させること 「計画通り」は無理という現実
- 127. ウォーターフォールとアジャイルの違い ユーザーと開発者はプロジェクトを通して、日々一緒 に働く ユーザの満足を優先し価値あるソフトウェアを早く継 続的に提供する 要求の変更はたとえ開発の後期であっても歓迎する 動くソフトウェアをできるだけ短い間隔（ 2〜3週間 あるいは2〜3ヶ月）でリリースする 動くソフトウェアこそ進捗の最も重要な尺度 技術的卓越性と優れた設計に対する普段の注意が機敏 さを高める シンプル（無駄なく作れる量）に作ることが基本 最良のアーキテクチャ・要求・設計は自己組織的な チームから生み出される チームが最も効率を高めることができるかを定期的に 振り返り、それに基づいて自分たちのやり方を最適に 調整する アジャイルな思想 ユーザと開発者はいつもは別の場所にいてプロジェク トを通して定例ミーティングを行う ユーザーの満足や価値のあるなしではなく、とにかく ソフトウェアを提供する 要求の変更を開発の後期に出すの勘弁して欲しい パワポ、エクセル、ワードの仕様書を丁寧に清書して （ 2〜3週間あるいは2〜3ヶ月）納品する 動くソフトウェアこそ進捗の最も重要な尺度 技術的卓越性と優れた設計に対する普段の注意が機敏 さを高める 仕様書通り（間違っていようが）に作ることが基本 最良のアーキテクチャ・要求・設計は自己組織的な チームから生み出される チームがもっと稼働率を高めるように監視し、それに 基づいて自分たちへの批判や不満を回避するために、 念のため納期を厳しめに設定する ウォーターフォールな思想 https://speakerdeck.com/kawaguti/flipped-agile-manifest Yasunobu Kawaguchi氏 資料を参考に作成
- 128.
- 129.
- 130.
- 131.
- 132. アジャイル開発 ウォーターフォール開発 最初に要件をあらかじめ 全て決めてから開発 要件 設計 コーディング 単体テスト 結合テスト ウォーターフォール開発とアジャイル開発（３） リリース ビジネス上の重要度で要件 の優先順位を決め、これに 従って必要機能を順次開発 反復（イテレーション）1 反復 2 反復 3 反復4 リリース リリース リリース リリース Continues Integration 品質の作り込み
- 133. ウォーターフォール開発とアジャイル開発（５） ◎ 〇 △ Ｘ 反復 １ ビジネス価値◎ 反復 ２ ビジネス価値 〇 反復 ３ ビジネス価値 △ 反復 ４ ビジネス価値 Ｘ 「MVP（Minimum Viable Product：仮説を検証することができる最低限のプ ロダクト）」かつ、ビジネス価値の高い機能・プロセスを優先して開発する。
- 134. ウォーターフォール開発とアジャイル開発（６） プラン ドリブン型 バリュー ドリブン型 リソース アジャイル 納期 リソース 納期 実現仕様 ウオーターフォール 要求仕様 要件 設計 コーディング 単体テスト 結合テスト リ ス ク 時間 反復1 リ ス ク 時間 反復2反復3 反復4 前提条件 原理的に 不良が起きない 納期が守られる コストと納期を 守ること 機能と品質を実 現すること ゴールは何か？
- 135. アジャイル開発の目的・理念・手法 135 高品質で無駄がなく、変更要求に対応できるきるソフトウエアを作成する為 適切な一連の手順に従う 高い協調と自律的なプロジェクト関係者によって実施される イタラティブ(反復/周期)、インクリメンタル（順次増加部分を積み上げていく)方式 ダイナミックシステムズ開発技法(Dynamic Systems Development Method) Dane Faulknerほか アダプティブソフトウェア開発(Adaptive Software Development) Jim Highsmith クリスタルメソッド(Crystal Methods) Alistair Cockburn) スクラム(Scrum) Ken Schwaber、Jeff Sutherland エクストリームプログラミング(XP/eXtreme Programing) Kent Beck、Eric Gammaほか リーンソフトウェア開発(Lean Software Development) Tom and Mary Poppendieck フィーチャ駆動開発(Feature-Driven Development) Peter Code、Jeff DeLuca アジャイル統一プロセス(Agile Unified Process) Scott Ambler 反復(周期)的(Iterative) --- 定期的なリリース 漸進的(Incremental) --- 徐々に機能を増加 適応主義(Adaptive) --- 変化に対応(即応) 自律的(Self-Organized) --- 学習する組織 多能工(Cell Production) --- 一人多役(SE、プログラマー、テスター) 目的と理念 手 法 共通する要素
- 136. 自律型の組織で変化への柔軟性を担保する 136 さまざまな専門性を持った人がチームを組み、最初 から最後まで一緒に働く。 人とチームを重視し、彼らが自律的に働ける環境を 与えることでブレークスルーが起こりやすくなり、 同時に製品化までの時間が短くなる。 リーダーは、自律するチームの障害を取り除くこと が仕事であり管理しない。 日本で行われている 新製品開発のプロセスを 米国のやり方と比較した論文 1986,Harvard Business Review Scrum（スクラム） 1990年代、Jeff Sutherlandらが ソフトウェア開発のに適用 アジャイル開発 不安定 高い自由裁量と困難なゴールを持つ 自己組織化 情報ゼロから相互交流し自律的に仕組みを作る 全員多能工 分業を共有しメンバーがプロジェクトの責任を自覚する イノベーションを 生みだす方法論
- 137. スクラム：特徴・3本の柱・基本的考え方 137 システム開発のフレームワーク（1995）／ Ken Schwaber& Jeff Sutherland 特徴 軽量 理解しやすい（シンプル） 会得するのは比較的難しい 三本の柱 Transparency （透明性） Inspection （視察、検査） Adaptation （適応、順応、改作） 基本的考え方 タイム・ボックス（Time Box） 時間を区切って、その時間内に目的を果たす仕事を行う仕事の仕方 機能横断的な固定化されたチーム チーム内で役割分担を決めず、全員が必要な仕事をこなす多能工（T型人間のチームででき るだけチームメ ンバーを固定化した方がよい 持続可能なペース 徹夜や残業を排除して安定した持続可能な一定のペースで開発し、定期的にリリースを行う
- 138. スクラム：スクラム・プロセス 138 イテレーション（反復） 4 1〜4週間 イテレーション（反復） 3 1〜4週間 イテレーション（反復）2 1〜4週間 イテレーション（反復） 1 1〜4週間 納品 納品 納品 納品 プロダクト・オーナー プロダクト・バックログ 1. -------------------- 2. -------------------- 3. -------------------- 4. -------------------- 5. -------------------- 6. -------------------- スプリント･プラン イテレーション毎の 内容区分 2時間程度の単位 スクラム･マスター タスク･リスト スプリント・バックログ 1. -------------------- 2. -------------------- 3. -------------------- 4. -------------------- 5. -------------------- 開発チーム バーンダウン チャート デイリー スクラム 開発・テスト インテグレーション To Do On Going Done Keep Problem Try スタンドアップミーティング & スプリント･レビュー・振り返り
- 139. スクラム：プロダクト・オーナー 139 ミッションと責任 プロダクトの完成図と方向性を示す プロダクトに必要な機能の詳細を決める リリースの内容と日程を決める 市場価値に基づくプロダクト･パックログの優先順位を決める スプリント毎に優先順位を変更できる権限を持つ プロダクトの収益性(ROI)の責任を持つ プロダクト･オーナーが行う事 プロダクトのビジョンを作成し、関係者に示し、共有する 対象プロダクトのビジネス要求(ビジネス環境)の説明 エピック、ユーザーストーリーの確定とペルソナの作成 ユーザーストーリー毎の受け入れ基準の承認 プロダクト・バックログの優先順位付けとプロジェクト期間中の維持管理 開発チームへのユーザーストーリーの説明 開発チームのDoD(完了の定義)作成の支援 リリース計画の承認 稼働環境の定義 EOL(プロダクトの終焉)条件の設定
- 140. スクラム：スクラム・マスター 140 チームの機能や効率化を支援する チームが最大パフォーマンスを発揮できる環境を作る ＝妨害からチームを守る チームがスクラム・プロセス通りに作業を実施できる様に支援する チームに気付きを与える チームの自律を支援する チームの能力をユーザーに売り込む プロジェクト関係者間の信頼感を醸成する お客様(ユーザー)第一の思想 ジャスト・イン・タイムの徹底 カイゼン活動の促進 チームのモチベーションの向上 スクラム･マスター
- 141. スクラム：開発チーム 141 自己組織的なチームである 自律性 メンバーが自ら日々の仕事を管理する 自己超越 常に目標を達成するように自らを追い込み、常に自身のプラクティスを改善する 相互交換作用 機能横断的かつ定めた役割がない 目標にコミットする義務がある チームはスプリント計画ミーティングでコミットした目標を達成する責 任 を持つ 目標達成につながるならば方法を限定しない チームは全ての決断を下す権限、必要なことを何でも行う権限、あらゆる障 害の除去を依頼する権限を持つ 争議はチーム内で解決する 作業規約を作る
- 142. エクストリーム･プログラミング（XP） 142 テスト駆動開発（Test-Driven Development：TDD）＝テストファース ト・プログラミング 実装する機能をテストするプログラムを書く コードを書いてテストする デザインを見直す 信号が青になる（テスト・コードが成功する）まで繰り返す リファクタリング 完成したコードの見直し（実装された機能を変えずに、コードをシンプルに、 見やすくする） 任意の作業（全員が行う&時間が空いたら行う） ペアプログラミング ドライバー（コードを書く人） ナビゲーター（コードをチェックする人、ナビゲーションをする人） この役割を1日の中でペア間で、途中で交代する ペアの組み合わせを毎日替える 10分間ビルド 自動的にシステム全体をビルドして、全てのテストを10分以内に実行させる Kent Beck（1999年）によって提唱された開発手法
- 143. アジャイル開発で品質が向上する理由 143 ムダ取りの原則を徹底する。 作業にムラがあるから、ムリをするようになる。 ムリな作業をした結果、ムダが生じる。 ムラを防止するのは、一定の作業リズム（タクトタイム＝タイムボックス） タスクの粒度を小さくする。 作業手順（工程設計）を考えなければタスクは小さくできない。 タスクが小さくなれば、ミスを容易に発見できる。手戻りも小さい。 タスクを小さくするとムダが見えてくる。 正味（本来の価値を作り込む）作業、付帯（事前、事後の）作業、ムダな作業 タスクを小さくすることで、整流化が容易になる。（ボトルネックの解消：一個流し生産） 全員での作業で透明性が高まる。 一人で抱え込む仕事がなくなる。 事前に他人の目が届く（チェック） トヨタ生産方式（ＴＰＳ）の自働化の思想をプロセスに組み込める。 不良作業をしない。不良品を流さない。不良品を受け取らない。（自工程完結） 不良が起こったらラインストップをして、関係者全員が異常に気づく。（見える化） 作業者（開発者）に直接フィードバックする仕組みが構築できる。 『擦り合わせ』をしながら作業が進む。
- 144. アジャイル開発で品質が向上する理由 144 タスクの粒度を小さくすることはＴＰＳにおける小ロット化と同様 「流れ」を作り、負荷を平準化し、柔軟性を高める タスクの粒度は小さいほど良い １日以内、理想は１時間 責任を持って見積ができる バグを作り込まない（簡単にテスト可能） 他のペアと同期がとれる ダイナミックなプロジェクト運営が可能となる（チーム編成の増減、分散開発など） タスクが小さくできないのは、作業対象の内容把握に問題が存在するのではないか？ タスクを小さく分割するという事は、作業指示書を作成する事。 Statements of Source code Test Cases Test Coverage 1 1 100.00% 10 2 100.00% 100 5 95.00% 1,000 15 75.00% 10,000 250 50.00% 100,000 4,000 35.00% 1,000,000 50,000 25.00% 10,000,000 350,000 15.00% Application size, Test Cases, and Test Coverage. Logical source code statements By Caper Jones
- 145. DoD (Definition ofDone) 完了の定義 145 各作業の完了基準 閾値（標準値）を決める。 作業経過、結果を計測する。 自工程完結の基本的な姿勢（現場での意思決定） 仁＝他人の努力を無駄にしない思いやり 検 査 検 査 検 査 発生防止 流出防止 プロセス プロセス プロセス 検 査 納入 検査 検査 検査 DoD
- 146. ウォーターフォールとアジャイル 要件 設計 実装テスト ウォーターフォール アジャイル デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 147. ソフトウェアV&V（ベームのVチャート） 要件 設計 実装テスト ウォーターフォール コンセプト 探索 コンセプト確認 要求 要求ベースライン 要求確認 設計確認 確認テスト 製品設計 製品設計検証 詳細設計 プログラム設計検証 コード 単体テスト 統合テストと システムテスト 受け入れテスト バリデーション(確認) ベリフィケーション(検証) 導入 運転試験と評価 利用と サポート デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 148. アジャイル 設計 に対する 検証（ベリフィケーション）ではなく、 要求（要件）に対する 確認（バリデーション）を繰り返す 要求 確認 要求 確認 要求 確認 要求 確認 要求 確認 デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 149. アジャイル開発（スクラム開発）の体制（理想） Product Owner Developer End Users Agile Team 要求（要件） に対する確認（バリデーション）を直接実施 デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 150. アジャイル開発（スクラム開発）の体制（実際） Product Owner Developer End Users Agile Team 要求（要件） に対する確認（バリデーション）を直接しにくい／頻繁にはできない Business Unit 要求（要件） に対する 確認（バリデーション）を間接的に行うこととなりがち デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 151. アジャイル開発（スクラム開発）の体制（さらに複雑となったある事例） Product Owner Developer End Users Agile Team Project Manager 要求（要件） に対する確認（バリデーション）を正しく行うことができない状況 Sales Project Leader Project Owner Project Member Customer その結果、短期間のイテレーション（反復）を繰り返していても、後になって仕様変更、仕様追加が発生 ❓ デンソー・デジタルイノベーション室長・成迫剛志 作成資料
- 152.
- 153.
- 154. ビジネス 開発 運用 アジャイル開発DevOps アプリケーション開発環境 マイクロ･サービス、ルールエンジン、AI、APIなど ITインフラストラクチャー IaaSなどのクラウド アプリケーション実行環境 コンテナ・オーケストレーション・ツール サーバーレス・FaaS Infrastructure as Code 運用の自動化 SRE Site Reliability Engineer アイデアの創発 デザイン思考 リーンスタートアップ トライ･アンド･エラー のサイクルを高速で回す ビジネス･スピードを加速する方法 ビジネスの成果に貢献するコードのみ 現場のニーズにジャストインタイム バグフリーと変更への迅速･柔軟な対応 開発されたコードを直ちに本番移行 安定稼働の維持 変更やスケールへの迅速･柔軟な対応
- 155. 開発と運用の協調・連携を実現するDevOps 155 情報システムに求められること システムによってビジネスの成功に貢献すること ビジネスの成功のための貢献を確実、迅速にユーザーに届けること ユーザーの求める貢献の変化に迅速・柔軟に対応すること 開発チーム（Development） システムに新しい機能を追加すること 運用チーム（Operation） システムを安定稼働させること 迅速にアプリケーションを開発・更新し すぐにユーザーに使ってもらいたい 確実に本番システムに安定させ 安心してユーザーに使ってもらいたい 対立 アジャイル開発 SDI/IaaS（インフラのソフトウエア化） ツール と 組織文化 の融合 開発チーム（Development）と運用チーム（Operations）が、お互いに協調し合い 「情報システムに求められること」を実現する取り組み いますぐ変更を 反映したい！ 安定運用したい！
- 156. 「ビジネス×IT」環境の変化 ＋ ビジネス・スピードの加速 ITニーズの変化：「効率化×生産性×低コスト」から「差別化×競争優位」へのシフト IT環境の変化：モバイル、IoT、ビッグデータなどの新しいテクノロジーへの対応 IT利用の変化 ：ITリテラシーの拡大やデジタル・ビジネス、ビジネスとITとの一体化 DevOpsとは何か？ 156 業務部門 開発部門 運用部門 依頼 業務部門 開発部門 運用部門 情 報 システム 情 報 システム 連係・協力 対応に長いリードタイム 組織の間を隔てる意思疎通の壁 煩雑な業務プロセス 手間のかかる構築や確認などの作業 ビジネス・ニーズに迅速・柔軟な対応 役割や関係などの組織文化の変革 ビジネス・プロセスの変革 自動化ツールの整備・活用 DevOps
- 157. DevOpsとは何か？ 157 業務部門 開発部門 運用部門 情 報 システム 連係・協力 継続的デリバリー ContinuousDelivery 継続的インテグレーション Continuous Integration バージョン管理 自動構築 動的テスト 非機能テスト サーバー構築 オートスケール 自動運用 コミュニケーション ツール ビジネス・ニーズ 開 発 要 望 フ ィ ー ド バ ッ ク ツールによる自動化
- 158. DevOpsとは何か？ 158 お互いを尊重する（Respect）： 一緒に働く相手のことを心から思いやる、相手を一人の人間として扱い、能力や功績を評価する お互いを信頼する（Trust）： 自分以外の人は優秀で、正しいことをすると信じる。信じて仕事を任せる 失敗に対して健全な態度を取る（Healthy attitude aboutfailure）： 新しいことに挑戦すれば自ずと失敗は起こってしまうものであり、相手のミスだと責めない 相手を非難しない（Avoiding Blame）： 相手に非があると断じて言葉で責めるのではなく、次に同じ問題が起こらないように建設的な批判を行う 自動化されたインフラストラクチャ（Automated infrastructure）： インフラの構築を自動化する。よく使われているツールにはAnsibleやChef、Dockerなどがある バージョン管理システムの共有（Shared version control）： GitやMercurialなどの同じバージョン管理システムをDevとOpsで共有する ワンステップによるビルドとデプロイ（One step build and deploy）： 手順書などを使い、手動でビルドやデプロイをするのではなく、ビルドやデプロイを自動化する。よく使われているツールや サービスにはJenkinsやCapistranoなどがある フィーチャーフラグ（Feature flags）： 詳細は後述のコラムで説明。コード中の機能の有効／無効を設定ファイルで管理する メトリクスの共有（Shared metrics） ： 取得したメトリクスの結果をダッシュボードでお互いに共有する。よく使われているサービスにはNew RelicやApplication Insightsなどがある IRCとインスタントメッセンジャーのBot（IRC and IM robots）： SlackやHipChatなどのチャットツールに自動的にビルドやデプロイのログ、アラート内容を投稿する仕組みを 作ることで情報をお互いに共有する ツ ー ル 組 織 文 化 改善
- 159. サーバー仮想化とコンテナ OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア サーバー仮想化 ハードウェア コンテナ管理ソフトウエア OS ミドルウェア アプリ ミドルウェア アプリ ミドルウェア アプリ コンテナ コンテナ コンテナ コンテナ ライブラリ 環境変数 ライブラリ 環境変数 カーネルカーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 隔離されたアプリケーション実行環境を提供（クラッシュの分離、独自のシステム管理とユーザー・グループ） 実行イメージのスナップショットをパッケージとしてファイルにして保存できる アプリケーションに加えて仮想マシン・OS の実行イメージを持つ必要がある アプリケーションとOSの一部 の実行イメージを持つ必要がある デプロイするサイズ 大きい 起動・停止時間 遅い デプロイするサイズ 小さい 起動・停止時間 早い 異なるOS 可 異なるOS 不可 メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い 構成の自由度が高い 異なるOS・マシン構成を必要とする場合など 軽量で可搬性が高い 実行環境への依存が少なく異なる実行環境で稼働させる場合など サンド・ボックス化 Sand Box アプリケーション アプリケーション アプリケーション
- 160. 仮想マシンとコンテナの稼働効率 ハードウェア 仮想マシン ミドルウェア OS 仮想マシン OS 仮想マシン OS ミドルウェア ミドルウェア ハードウェア OS コンテナ管理機能 カーネル ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ カーネル カーネルカーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 コンテナ 仮想マシン アプリケーション アプリケーション アプリケーション ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ
- 161. 仮想マシンとコンテナの稼働効率 1/2 161 仮想マシン ハードウェア 仮想マシン ミドルウェア OS 仮想マシン OS 仮想マシン OS ミドルウェア ミドルウェア カーネルカーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 アプリケーション アプリケーション アプリケーション OSの維持コストが高いので １つのOSに複数のアプリケーションを同居させる あるいは基盤更改などで移行する時も分離できず 再構築することもおおい ライブラリが共通で依存関係があり アップグレードもパッチ適用もできず塩漬けになりがち 仮想マシンごとに OSを稼働させとハードウェア・エミュレーションがあり ハードウェアとOS起動+運用が必要となり オーバーヘッドが大きい・起動は分単
- 162.
- 163.
- 164.
- 165. DevOpsとコンテナ管理ソフトウエア オペレーティング システム サーバー （ハードウェア） コンテナ管理 動 作 保 証 オペレーティング システム サーバー （ハードウェア） コンテナ管理 動 作 保 証 オペレーティング システム サーバー （ハードウェア） コンテナ管理 アプリケーション 開発・実行環境 ミドルウェア コンテナ 動 作 保 証 Build,Ship and Run AnyApp,Anywhere アプリケーション開発者は、OSやインフラを意識することなくアプリ ケーションを開発し、どこでも実行できるようになる 開発しテストが完了したアプリは、すぐに本番環境で実行させることができる 本番環境 テスト環境 開発環境
- 166.
- 167.
- 168. DockerとKubernetes の関係 168 コンテナの作成 コンテナの実行 コンテナ内でファイルシステ ムとして使われるイメージの 作成および管理 など 関連するコンテナのグルーピング コンテナに割り振られるIPアドレスの管理 コンテナ間ネットワークルーティング管理 複数のコンテナを利用した負荷分散 コンテナに割り当てるストレージの管理 コンテナの監視 など ネットワークのルーティングや複数コンテナの 連携、複数台のサーバーを対象にコンテナを横 断的に管理する機能などは提供されていない。 クラスタ環境でDockerを利用する場合は別途何らかの管理手法を用意する必要がある。 Dockerと連携して利用できるデプロイ/オーケストレーションツールのひとつ By Google Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops. Linuxコンテナのクラスタを単一のシステムとして管理して 開発を加速し、運用を簡素化します。 意味：ギリシャ語で「人生の道標」 読み方：クーベルネイテス（koo-ber-nay'-tace）
- 169. Twelve Factorsとの関係 169 Ⅰ. コードベース バージョン管理されている1つのコードベースと複数のデプロイ Ⅱ.依存関係 依存関係を明示的に宣言し分離する Ⅲ. 設定 設定を環境変数に格納する Ⅳ. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う Ⅴ. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する Ⅵ. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する Ⅶ. ポートバインディング ポートバインディングを通してサービスを公開する Ⅷ. 並行性 プロセスモデルによってスケールアウトする Ⅸ. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する Ⅹ. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ Ⅺ. ログ ログをイベントストリームとして扱う Ⅻ. 管理プロセス 管理タスクを1回限りのプロセスとして実行する アジリティーの高いWebサービスを構築するための方法論 コンテナ Kubernetes https://12factor.net/ja/
- 170. Kubernetes Master 全体のコンテナの稼働 状況などを把握し、運用 管理者が指定したよう に、コンテナ配置、削除 などを指示 Kubernetes の全体構造 170 コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア Kubernetes Node Kubernetes Node Kubernetes Node Kubernetes Pod Kubernetes Pod Kubernetes Pod Kubernetes Pod コンテナ管理システム コンテナ管理システム が稼働しているマシン ／サーバーの単位 コンテナの まとまりの単位 Kubernetes Cluster Nodeの集まりの単位 物理マシン／仮想マシン yaml形式記載された設定 ファイル kubectlコマンドを使って、 設定をKubernetes Masterに反映 Kubernetes Masterは反 映された内容を元に、 NodeやPodを操作 マニフェスト 意味：ギリシャ語で「人生の道標」 読み方：クーベルネイテス 略称：K8s
- 171. マイクロサービス（Micro Service） 171 ユーザー・インターフェイス 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 共有データ 顧客管理 注文管理在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 個別データ ユーザー・インターフェイス 個別データ 個別データ 個別データ モノリス型アーキテクチャ マイクロサービス型アーキテクチャ マイクロ サービス 巨大な１枚岩のような 複数の独立した機能（マイクロサービス）を 組み合わせることでひとつの処理を実現する 大きな単一の機能によって ひとつの処理を実現する 単一の機能 独立した機能 内 部 は 複 数 の 機 能 で 構 成
- 172. マイクロサービス（Micro Service） 172 ユーザー・インターフェイス 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 共有データ 顧客管理 注文管理在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 個別データ ユーザー・インターフェイス 個別データ 個別データ 個別データ モノリス型アーキテクチャ マイクロサービス型アーキテクチャ マイクロ サービス 巨大な１枚岩のような 単一の機能 独立した機能 内 部 は 複 数 の 機 能 で 構 成 マイクロサービス単位でマシンが必要 各機能の単位でマシンが必要 ＊「マシン」とは物理マシンだけではなく仮想マシンやコンテナも含む。
- 173. マイクロサービス・アーキテクチャの6つのメリット 修正 修正 リリースの同期は必須 個別にリリース可能 Java JavaJava Java Java Java Java Ruby php C++ Java Script C# 言語は統一 機能にふさわしい言語を選択 影響？ 影響？ 影響？ 影響？ 変更 影響？ 一部機能変更・全体テスト 一部機能変更・対象機能のみテスト 変更 全体で拡張 個別に拡張 正常 正常 正常 正常 障害 正常 正常 正常 正常 正常 障害 正常 一部障害で全体停止 一部障害でも正常箇所は稼働 流用 流用 特定の機能流用は困難 特定機能の流用は容易 １．機能の独立性 ２．言語の独立性 ３．保守の容易性 ４．拡張の柔軟性 ５．障害時の可用性 ６．再利用の容易性 「これなら分かる！ マイクロサービス（入門編）〜モノリスと比較した特徴、利点と課題（CodeZin）」を参考に作成
- 174. マイクロサービス・アーキテクチャの3つの課題 174 機能間で通信は発生しない 機能間で通信が行われる 全体をひとつのチームで行うので 人の入替えやノウハウ共有が容易 各機能個別に組織が分かれるの 人の入替えやノウハウ共有が困難 過剰分割の影響は内部に留まる 一貫したユーザー体験を提供 過剰分割はパフォーマンスを劣化 機能別に異なるユーザー体験のリスク １．機能間の通信によりパフォーマンスが出にくい ２．人の入れ替えやノウハウの共有が難しく”人”や”知見” の活用効率が低くなる ３．プログラム構造次第でパフォーマンスやユーサー体験に悪影響 通信により組み合わせるという仕組みから、パフォーマンス を出しにくい。 性能向上のため各機能間は非同期通信とし、機能をまたがっ たトランザクション保証はしないため、正常終了した後に後 続処理がエラーとなることも想定した設計が必要。 個人ユーザー向けの決済処理のような再試行が難しい業務の 場合は、実装が難しい。 マイクロサービスを適用したアプリケーションを作るには、 個々の機能と同じように独立し完結した組織でなければなら ないが、それができる保証はない。 チームごとに独自文化が形成されチーム間でスキルの共用が 難しい。 文化の違いから人的ローテーションも難しくなる。 マイクロサービスの利点を生かすには、機能の境界を適切に 設定することが必須となるが、分ける範囲を誤れば機能間の 通信が大量に発生する。 分けるべきであった機能を一つにしてしまえば保守性や再利 用性などのメリットが満たせない。 独自性がすぎるとユーザー体験がちぐはぐになってしまう。 「これなら分かる！ マイクロサービス（入門編）〜モノリスと比較した特徴、利点と課題（CodeZin）」を参考に作成
- 175. オーケストレーションとコレオグラフィ 175 オーケストレーション（Orchestration） コレオグラフィ（Choreography） オーケストレーション・プログラム リ ク エ ス ト リ プ ラ イ サービス （アプリケーション機能） サービス （アプリケーション機能） 全体の処理の流れを制御する指揮者にあたるプログラム が存在し、指揮者からのリクエストによってサービスを 実行し、実行結果をレスポンスとして指揮者に返して処 理を継続させるプログラム実行方式。 全体の処理の流れやサービスの呼び出しを制御する指揮 者は存在せず、個々のサービスに予め与えられた動作条 件や次にどのサービスを起動させるかといった振り付け に従って自律的に動作させるプログラム実行方式。 指揮者の指示に従う演奏方式 演劇や踊りなどの振り付け リクエスト・リプライ方式で実行されるのが一般的 利用する全てのサービスは、指揮者であるプログラムが 処理の順序や得られた結果に続く処理を制御。 各サービスは、そのサービスを制御する指揮者が行って いる同一の処理のためだけに利用され、他の指揮者が制 御する別の処理を引き受けて実行することはない。 サブルーチン・コールやメソッド・インボケーション （呼び出し）と同様の考え方。 イベント・ドリブン方式に向いている イベントの発生によって特定の業務処理サービスが駆動 される方式。 イベントの例 新規に注文が入った 倉庫に商品が入庫した 新規顧客が登録された など 発生したイベントを他のサービスに通知することで､必 要な処理を継続的に実行させる。
- 176. Version 1.3 Version 2.0Version 1.5 Version 1.4 エンジニアの役割分担 176 ITインフラ ITインフラ ITインフラ ITインフラ 開発エンジニア 開発エンジニア SRE テスト・エンジニア マイクロ･サービス×コンテナによる独立したプロセス クラウド･ベースでの 組織横断的な仕組み作り
- 177. 「クラウド･ネイティブ」とは 177 開発者は他社と差別化できるビジネスロジックに集中したいのに 付加価値を生み出さない作業で負担を強いられる ミドルウェアの設定 インフラの構築 セキュリティ・パッチの適用 キャパシティ・プランニング モニタリング システムの冗長化 アプリケーションの認証・認可 APIスロットリング など この負担から開発者を解放 DevOps マイクロ・サービス アーキテクチャ コンテナ サーバーレス／FaaS(Function as a Service) アプリケーションを継続的・高速にアップデートし ビジネス・ニーズに即座に対応
- 178. クラウド・サービスの区分 自社所有 IaaS 仮想マシン CaaS PaaSFaaS ユーザー企業が管理 ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS SaaS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ IaaS ベアメタル クラウドサービス事業者が管理 連携機能 CaaS PaaS FaaS SaaS
- 179.
- 180. 運用技術者からSREへ 180 ITの実務上の利用方法について問い合わせを受けて対応する 窓口業務 定められたオペレーションを繰り返し実施する定常業務 ITに関するトラブルに対応する障害対応業務 インフラ（ネットワークやOS・ハードなどの基盤部分）に関 する管理業務（構成管理やキャパシティ管理など） 積極的にソフトウェアで 置き換えていく クラウド・サービス 自動化/自律化ツール ビジネスもアプリも要件がどんどん変わっ ていくので、継続的に改善して手作業をソ フトウェアに置き換えていく必要がある 変更への即応性や信頼性の高いシステム基盤を設計 運用管理の自動化/自律化の仕組みを設計・構築 開発者が利用しやすい標準化されたポリシーやルールの整備 運用技術者 Operator / Operation Engineer SRE Site Reliability Engineer 組織横断的なインフラ整備 作業者から ソフトウェアエンジニア への変身！ http://japan.zdnet.com/article/35090649/ http://torumakabe.github.io/post/bookreview_site_reliability_engineering/ 参考になる記事： DevOpsのための取り組み
- 181.
- 182.
- 183. ローコードとプロコードの違い プログラミングの専門スキルが必要 開発スピードはスキルに依存 変更への対応は開発のしかた次第 プロコード開発 業務に精通していれば開発ができる 開発スピードが速い 変更に迅速に対応できる ローコード開発 https://www.automatigo.co.jp/solution/platform/outsystems 株式会社オートマティゴ ホームページより
- 184. ローコード開発ツール 184 インフラ・プラットフォーム構築 手組によるアプリケーション開発 クラウド 手組によるアプリケーション開発 クラウド ローコード 開発ツール ビジネスニーズの変化に即応 新規アプリケーションの開発期間の短縮 日々改善に対応できる保守・改修の実現 業務プロセス可視化による属人性の排除 経営視点を持ち、ビジネスゴールを設定できる能力 業務を分析・整理して、業務プロセスを描ける能力 現場のニーズを引き出せるファシリテーション能力
- 185. ローコード開発ツール 185 要件定義 概要設計 詳細設計単体テスト 結合テス ト プログラミング 結合テスト 従来型 開 発 要件定義 運用・保守 （高速化・効率化） 結 合 テスト ローコード 開 発 ローコード開発 人手による作業 ツールによる 自動化 プログラム生成型 統合環境型 プラットフォーム型 画面や業務ロジック、データ構造などセグメント 毎に機能が独立 アプリケーション層よりも上位に特化、システム を統一的に構築、抽象化モデルを使いGUIで開発 システム開発だけではなく、ライフサイクル全体 を統一的に管理・支援 NTTデータ・TERASOLUNA NEC・SytemDirector Enterprise FUJITSU・Software Interdevelop Designer など GeneXus キヤノンITS・Web Performer 住友電工情報システム・楽々Framework3 ジャスミンソフト・Wagby SCSK・FastAPP など OutSystems ServiceNow Mendix AppPlatform サイボウズ・kintone Microsoft PowerApp/Datahlex Salesforce・Lightning Platform AWS・Honeycode Google・AppSheet など 運用・保守
- 186. 自動生成 ローコード開発ツールの 基本的な構造 186 要件定義 概要設計詳細設計 単体テスト 結合テス ト プログラミング 結合テスト 設 計 リポジトリ 画 面 業 務 ロジック データ 構 造 アプリケーション データベース 運用・保守 アプリケーション 実行基盤 運用管理 ツール 運 用 レポート プラットフォーム型 ローコード開発ツール 人手による 作業 ツールによる自動化 GUI 画面・業務ロジック ・データ構造を管理 クラウド・サービス オンプレミス
- 187.
- 188.
- 189. デジタル・トランスフォーメーションとは何か 189 不確実性の常態化 予測不可能なビジネス環境 と 競争原理の流動化 圧倒的なビジネス･スピードの獲得 高速に見える化高速に判断 高速に行動 企業の存在意義／Purposeを貫くこと 自分たちは何者なのか？いかなる価値を社会や顧客に提供するのか？ デジタル・トランスフォーメーション デジタル技術を前提に 考え方や働き方、ビジネス・モデルやビジネス・プロセスを変えてゆくこと CX : Customer Experience お客様の事業の成果に貢献し お客様の社員の幸せを支える EX : Employee Experience 従業員のやり甲斐を与え 自己の成長の喜びを感じさせる いまの社会や ビジネスの状況は？ この状況に 対処するには？ そのために 実現すべきことは？ 目指すべき あるべき姿は？
- 190. 必ず失敗する新規事業 新規事業を行うことを目的にしている新規事業 お客様の幸せのためではなく、 × AIやIoTを使って、何か新しい事業を始めることが目的になっている。 × ３年後には、10億円くらいになる事業を作ることが目的になっている。 ×他社がやっていない、目新しい新しいビジネスをすることが目的になっている。 新規事業を成功させることではなく、 × 新規事業計画を作ることが目的になっている。 × 経営者を納得させることが目的になっている。 × 新しいことをやっていることを世間に知らしめることが目的になっている。 新規事業は目的ではなく手段 目的は事業課題の解決
- 191.
- 192. 「手段」と「目的」をはき違えてはいけない イノベーションの創出 新規事業の開発 ビジネス･モデルの転換 AIを活用する IoTビジネスを実現する クラウドで稼ぐ など 手段 であって目的ではない 何が問題なのか 何を解決すべきなのか 何を目指すべきなのか あるべき姿 10年後の自分たちの事業 お客様が実現すべき事業 解決したい社会課題 など できること・できそうなこと 目的 は自分たちで作り出す 未来をどうするかは 自分で決める！
- 193.
- 194.
- 195.
- 196.
- 197. DXによる新規事業創出組織に求められる資質 197 1. 企業会計の基本を理解しており、事業計画立案やレビューに際して貸借対照表および損益計算書を元に検討ができること。 2. 既存の製品・サービスとの比較検討に際して、ユーザー視点に立ち、中立的かつ客観的に考えることができること。 3.ユーザーが満足しよろこんでお金を支払う気になるレベルの製品・サービスの機能や品質を実現できる技術および体制を持つこと。 4. ゼロからイチを創るセンスを持ち、かつ事業が軌道に乗せるまでやり切るパッションと責任感をもつこと。 5. 既存のしがらみを一旦忘れ、物事をシンプルに考え、整理できること。その上で既存のしがらみを打破できること。 6. 正解がないことに挑むことを理解し、正解が誰もわからない前提で仮説検証サイクルを回すマインドがあること。自分の中に軸を 持って自分の頭で考えを整理することができること。 7. 過度な投資を志向するのではなく、リーンスタートアップを実践できること。 8. 市場規模の予測をリーズナブルにできること。また、予測した市場規模に対する獲得目標シェアを実現可能性を保守的過ぎずアグ レッシブ過ぎずに考えらえること。 9. 売上だけでなく、むしろ利益を主眼に事業計画を検討し、事業が軌道に乗るまでのキャッシュフローを見積もることができ、また 損益分岐点を超えた後の営業利益率を高めるプランを描けること。 10.自社だけで製品・サービスを開発・提供できない場合には、必要十分かつ最適な最低限のパートナーを選び、交渉し、双方が十分 な利益を得られる事業構造を構築できること。むやみやたらにステークホルダーを増やさないこと。 11.開発だけでなく、維持保守および運用に関して、低コストで必要十分な体制を構築できること。 12.グローバル展開を視野に入れるが、まずは特定の市場において利益を得られる事業立ち上げを考え、実践できること。 13.現状の否定に終始することなく、自ら未来を切り開くことを志向し、その意気込みや構想、計画について、ステークホルダーから 共感および同意、賛同を得るための論理的説明ができること。 14.うまくいかないことを他責にしないこと。阻害要因がある場合、それを自ら取り除くことができること。 15.変化に柔軟に対応できること。間違いや失敗を早い段階で自ら認め、必要なピボットができること。 16.様々な視点を持つ多様なアドバイザーを持ち、様々な意見に対して真摯に耳を傾けられること。反論されても折れない心を持つこ と。 17.焦らず余裕を持つこと。努力や自己犠牲をアピールせざるを得ない状況に追い込まれることのないように振る舞えること。 18.うまくいかない状況となった場合に、傷が浅いうちに止める決断ができること。あらかじめ決めた撤退要件に従うことができるこ と。 19.プラットフォーマー、エコシステム、データを持つ者が勝ち、マイクロサービスが売れる、等の流行り言葉、バズワードに惑わさ れることなく、事業計画を立案できること。 20.そして、人に好かれる愛嬌を持つこと。困った時に助けてくれる応援団を持つこと。孤軍奮闘とならないこと。あのひとのプロ ジェクトに参加したい、あの人のためなら一肌脱ぎたいと思われる人間的な魅力を持つこと。 21.上記20項目を意識しながらも、それでも「人々のためになることを自分が信念を持って創る。」という強い想いを通すために必要 な場合には、キチンと「NO！」と言えること。 デンソー・MaaS開発室長・成迫 剛志
- 198.
- 199.
- 200.
- 201. 「両利きの経営」とDX戦略（１） 201 新しいビジネスモデルや商品・サー ビスを生みだすために、いろいろな 組合せを試し、知の範囲を拡げる。 いま業績のあがっている事業領域の収益の確保と増大に注力し、 知の範囲を深化させる。 知の深化 知の探索 サクセス・トラップまたはコンピテンシー・トラップ 「知の探索」には手間やコストがかかるわりに、収益に結びつくかど うかが不確実。そのため、収益の確保が見通しやすい「知の深化」に 偏りがちになってしまう。 経営レベルで 知の探索 と知の深化 のバランスを調整する 1. 探索チームには、ビジネスに必要な機能（たとえば 開発・生産・営業）をすべて持たせて「独立性」を 保たせること 2. トップレベル（たとえば担当役員レベル）では、そ の新規部署が既存の部署から孤立せずに、両者が互 いに知見や資源を活用し合えるよう「統合と交流」 を促すこと新規事業部署にはなるべく「知の探索」 を好きなようにやらせて、他方で「知の深化」との バランスを取り、既存事業分野との融合を図る 1. 自社の定義する「ビジネスの範囲」を狭め ず、多様な可能性を探求できる広い企業ア イデンティティーを持つこと 2. 「知の探索」部門と「知の深化」部門の予 算対立のバランスは経営者自身が取ること 3. 「知の探索」部門と「知の深化」部門の間 で異なるルール・評価基準を取ること 「両利きの経営（東洋経済新報）」を参考に作成
- 202. 「両利きの経営」とDX戦略（２） 202 知の深化 知の探索 サクセス・トラップ コンピテンシー・トラップ 経営レベルで「知の探索」と「知の深化」のバランスを調整する 支援 Before DX After DX 1.「探索事業」が新規の競合に対して競争優位 に立てるような、既存事業の資産や組織能力 を突き止める。 2. 「深化事業」から生じる惰性が新しい取り組 みの勢いを削がないように、経営陣が支援し 監督する。 3. 「探索事業」を正式に切り離して、成熟事業 からの邪魔や「支援」なしに、成功に向けて 必要な人材、構造、文化、資本を調整できる ようにする。 成功しているほど知の深化に偏って結局は、イノ ベーションが起こらなくなる。 成功すればするほど深化に傾斜 「両利きの経営（東洋経済新報）」を参考に作成
- 203.
- 204.
- 205.
- 206. ふたつのイノベーション（１） 206 顧客は誰か？ 現状に満足していない顧客 存在していない顧客 機能・性能の向上 新たな需要の創出 持続的イノベーション破壊的イノベーション ハイエンド戦略（足し算戦略） 高付加価値・高利益 ローエンド戦略（引き算戦略） 価値限定・低利益 新機能、高機能、多機能、省エネ、 高コストパフォーマンス、新デザイン 簡単、便利、低価格、新鮮、 画期的、面白い、これだったら使える 事業の拡大
- 207.
- 208.
- 209. 資金シフトの進める（１） 導入 成長 成熟衰退 資金 資金 採算ライン 新規事業が成功する条件は、 成功するまで失敗を 繰り返すことができる 資金力があること。
- 210.
- 211. DXの実現に立ちはだかる課題 情報システムの部分最適化や複雑化 各事業の個別最適化優先した結果、システムが複雑となり、企業全体での情報 管理・データ管理ができず、全体最適が困難になっている。 業務に合わせ１からシステムを開発することが多用され、カスタマイズするこ とが好まれ、その結果、個々のシステムの独自化／特殊化（ガラパゴス化）が 進み、新しい技術を取り込むことが困難になっている。 先送りを許容する意識の定着 現状は問題なく稼働しているので誰も困っていないとの認識があり、時代遅れ （レガシー）になってしまっていることに自覚がない。 レガシーが問題であるとの自覚があっても、根本的な解決には長時間と膨大な 費用が要するうえ、失敗のリスクもあるため、刷新に着手しない。 経営者のコミットメントが不十分 改善して使い続けた方が安全であるという意識が強く、デジタル技術を前提に したビジョンが不明瞭で、コミットが稀薄である。 DXやビジネスのデジタル化に取り組む組織を作るも、デジタル技術やそのビジ ネスへの影響についての理解が不十分で、かれらに明確な指示をだせない。 『DXレポート 〜ITシステム「2025年の崖」克服とDXの本格的な展開〜 経済産業省・2018年9月』の指摘を参考に作成
- 212. 変革のリーダーたるよき抵抗勢力となる 212 ビジネスやテクノロジーのトレンドについて好奇心を絶やさず、情報 収集や勉強を怠らない。 分析的に物事を捉え、自分の理屈を語れる。 人の意見に耳を傾け、それについて自分の意見を示すことができる。 社内外に人的なネットワークを持ち、特にコミュニティや勉強会など で、社外との広い緩い繋がりを持っている。 自分の職掌範囲を自覚し、その達成に誠実に向きあっている。 評論家やアウトロー、あるいは単なる批 判者ではなく、自分の与えられた職務の 中で批判的な精神を持ち、改善策を探し、 これを実践する人。
- 213. ローコンテクスト文化 ハイコンテクスト文化 空気を読む文化 前提となる文脈（言語や価値観、考え方な ど）が非常に近い状態のこと。コミュニケー ションの際に互いに相手の意図を察し合うこ とで、「以心伝心」でなんとなく通じてしま う環境や状況のこと。 前提となる文脈や共通の価値観が少ない常態 のこと。コミュニケーションの際に、言語で 表現された内容が高い価値を有する傾向にあ り、思考力や表現力、論理的な説明能力や ディベート力といった能力が重視される。 言葉で伝え合う文化 アメリカの文化人類学者・エドワード.T.ホールが唱えた「ハイコンテクスト文化とローコンテクスト文化」 日 本 人 中 国 人 ア ラ ブ 人 ギ リ シ ャ 人 ス ペ イ ン 人 イ タ リ ア 人 イ ギ リ ス 人 フ ラ ン ス 人 ア メ リ カ 人 ス カ ン ジ ナ ビ ア 人 ド イ ツ 人 ド イ ツ 系 ス イ ス 人 聞き手の能力を期待する 直接的表現より単純表現や凝った描写を好む 立場や状況、人間関係などに配慮する姿勢を示す 曖昧な表現を好む 多く話さない 論理的飛躍が許される 質疑応答の直接性を重要視しない 話し手の能力を重要と考える 直接的・明示的で解りやすい表現を好む 言語に対し高い価値と積極的な姿勢を示す 単純でシンプルな理論を好む 寡黙であることを評価しない 論理的飛躍を好まない 質疑応答では直接的に答える コンテクスト文化から考えるリモートワーク 五感を総動員 言語を駆使
- 214.
- 215. Krebs Cycle ofCreativity Age of Entanglement（もつれ時代） 時代の先端を行こうとする個人、もしくは組織にとっては、肩書など一言で説明できない状 況になっている。脱専門的な態度が”スタンダード”になろうとしている。 実用性（Utility）を最 大化することで我々の 行動変容を生み出す 我々の行動変容を批評 することで新たな認識 を世界に生み出す 我々の世界を説明・予 測することで、 “Engineering”で活用 可能な知識を生み出す 課題解決に科学的知識 を活用することで実用 性を生み出す もつれ時代における創造性
- 216.
- 217.
- 218.
- 219.
- 220. つながり力：計画された偶発性理論 成功した人のキャリア形成のきっかけは80%が「偶然」 移動は、自宅と職場／客先との間だけ つき合う相手は、同僚かお客様、家族だけ いつも聞き手、質問や議論を避ける など 偶然を 呼び込めない 残念なケース 社内外を問わず、コミュニティや勉強会に参加する 社内外を問わず、自分のやっていることを人に話す 社内外を問わず、自ら発表する機会を持つ など 偶然を 呼び込むための 効果的な行動 自分とは異なる能力やスキルを持つ人の助けを得て問題を解決できる 多様な価値観やロールモデルを知り、きっかけや勇気を得られる アウトプットの何倍もの情報が、効率よく手に入る など
- 221.
- 222.
- 223. 新刊書籍の御案内 2020年1月26日･発刊 新用語・技術を大幅追加しリニューアル！ デジタル・トランスフォーメーションと共創 デザイン思考とリーンスタートアップ IoT とモノのサービス化 機械学習とディープラーニング ゼロトラスト・ネットワーク クラウド・バイ・デフォルト原則 アジャイル開発と DevOps ブロックチェーン 量子コンピュータ など 【図解】コレ一枚でわかる最新ITトレン・改装新訂3版 言葉は知っているけれど、 それが何なのか、何ができるようになるのか、 なぜそんなに注目されているのか、 あなたは、ご存知ですか？ ITの常識をあなたのビジネスの武器にする。 そのためのお手伝いをさせて頂きます。 https://amzn.to/2Qj1AhE
- 224.