未分類

システムオブシステムズ研究会（第13回）報告
報告者　落水浩一郎

第13回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記
１． 日時：2021年4月29日および4月30日　18:30～20:40
第12回と同様に、参加者を変え、同じ内容を29日と30日の両日に報告・議論した
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：
(1) 4月29日
日下部茂（長崎県立大）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、
富松篤典(電盛社)、落水浩一郎（UIT，世話人）
(2) 4月30日
小笠原秀人（千葉工大）、艸薙匠（東芝）、日下部茂（長崎県立大）、栗田太郎（ソニー）、
新谷勝利(新谷ITコンサルティング)、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、
奈良隆正（コンサル21世紀）、方(ファン) 学芬 (SRA先端技術研究所) 、
堀雅和（新潟工科大）、矢嶋健一（JTB）、落水浩一郎（UIT，世話人）
４． 議事（4月29日）：
(1) 18:30～19:30　講演
落水浩一郎(UIT)「デジタルトランスフォーメーション -その目標と手段-」
MITスローン情報システム研究センター発行の著作「デザインド・フォー・デジタル」の内容を、
以下の点にわたって解説した。
① デジタル技術は新たなカスタマーバリュープロポジションを形成する機会を提供し、新しいカスタマー・バリュープロポジションはデジタルサービス（デジタルオッファリング）の開発を促進する。
② より高度なカスタマーバリュープロポジションを実現するために、イノベーティブなデジタルサービスを開発することをデジタル対応化という
③ 継続的なデジタル対応化のために人材、組織、プロセスを全体的・組織的に構成することをデジタル企業デザインとよぶ
④ デジタル企業デザインを目標として、デジタル企業デザインされていない企業を変革していく過程をデジタルトランスフォーメーションという
⑤ デジタルトランスフォーメーションのため、本書が推薦する手段は5つのビルディングブロックの段階的実現である。

(2) 19:30～20:30　議論
① 2年前に行われたレガシーがよくないというDXの説明はまちがっていたのでは
そう思います
② デジタル対応、デジタルトランスフォーメーション、デジタル企業デザインという用語間の意味の違いをもう少しはっきりと認識したほうがよい。私もデジタルトランスフォーメーションとデジタル企業デザインは同じような意味合いにとれるので混乱している。デジタルデザインの方がより具体的に定義されている。デジタルデザインという言葉はDXの目標をより具体的に定義している。
③ 主要な概念間の関係で、デジタルトランスフォーメーションから出る矢印は、カスタマー・バリュープロポジションとデジタルサービスにも向かうべきだ。その通りです
④ DXはすべての業種の企業を対象にしているのだろうか。事例研究の結果を抽象して得られたモデルであり、事例研究の対象となった企業はすべてデジタルを活用している。そこで、デジタルを使った企業を対象としているのではないか。なるほど
⑤ 自動車の自動運転機能がデジタルサービスでないというのは大変気になる。ユーザが変わっていないからではないか。経営学にダイナミックケーパビリティとオーディナルケーパビリティという概念があるがその違いが明確でないという説もあり、同じようなことではないのか
⑥ 「デジタル技術の活用による新しいバリュープロポジションの創出」というところが話の肝か。はい、そうです
５． 議事（4月30日）：
(1)18:30～20:30　講演 4月29日に同じ
(2) 20:30～21:40議論
① この著書に書かれているようなことを、イノベーションのジレンマを乗り越えて、既存（大）企業が実施できると、著者達は本気で考えているのだろうか。非難しているのではなく、事実を知りたい
② 私の会社はDXに取り組んでいる、5つのビルディングブロックのうち、アカウンタビリティフレームワークを実施するのは日本の企業では難しいと思っている
③ 中小企業にはDXの話はひびかないとおもわれる
④ ビルディングブロックは日本では５＋１になると思う。＋１は「組織カルチャー、人の意識」である。とくに従業員に、終身雇用のせいで、これまでどおりでよいという人が多い
⑤ 日本ではイノベーション（新しい芽）はスカンクワークスでうまれてきた。最近は余裕がなくなって統制がきつくなり次の事業の芽となる新しいアイデアを育てにくくなっている
⑥ 短期間（例えば3か月）での成果がもとめられる時代だ。
⑦ 別の言葉で言えば、「遊ばしてくれない」。遊ぶことを会社が許さない
⑧ 日本人はトップダウンの管理にむいていない。ボットムアップだ
⑨ 日本人は改善はやれるがイノベーションはできない
⑩ 日本でＤＸをやるには、両利き（右利きと左利き）の組織構造をもつ必要があるという話があり、経営者の間で爆発的な人気がある。そのどちらかでＤＸをやることは可能か。無理だろう
⑪ 人間はなかなか変われないので、企業で業務内容を変更するためには、中の人間を入れ替えるしかない。ノキアが生き残っている理由は、従業員の99％の人間を入れ替えたからだ。
⑫ 古い企業は巨象の死ぬ道をたどるのでは、新しい事業は新しい会社がやる。
⑬ 楽天の真似は大企業にはできない
(1) 今後の予定　DXの日本の事例について調査してはどうか

システムオブシステムズ研究会（第12回）報告
報告者　落水浩一郎

第12回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記
１． 日時：2020年12月15日および12月17日　18:30～20:40
はじめての試みとして、（参加者を変え、）同じ内容を15日と17日の両日に報告・議論した
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：
(1) 12月15日
日下部茂（長崎県立大）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、
富松篤典(電盛社)、奈良隆正（コンサル21世紀）、矢嶋健一（JTB）、
落水浩一郎（UIT，世話人）
(2) 12月17日
栗田太郎（ソニー）、艸薙匠（東芝）、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、方(ファン) 学芬 (SRA先端技術研究所) 、堀雅和（インテック）、落水浩一郎（UIT，世話人）
４． 議事（12月15日）：
(1) 18:30～19:30　講演
落水浩一郎(UIT)「デジタルトランスフォーメーション(DX)とマイクロサービス(MS)」
① マイクロサービスは、独自のライフサイクルをもつ、協調する細粒度サービスの利用を促進する分散システムである。
② 細粒度サービスは、境界づけられたコンテキスト（同じ意味で言葉を使う範囲）により定義される。
③ それぞれの細粒度サービスはビジネスドメインを中心にしてモデル化（ヘキサゴナル/オニオン/クリーン　アーキテクチャ）されるので、伝統的な階層アーキテクチャの問題を回避できる。
④ 細粒度サービスの開発と運用は、細粒度サービス毎に少人数のチーム（Two Pizza Team）が担当し、CI/CD(継続的統合と継続的デリバリー)をおこなう。
⑤ マイクロサービス群の協調は、軽量のメッセージキューを介した事象駆動型非同期通信によって達成される。アプリケーションをコンテナ化して実行する実行環境やその周辺ツール群であるDockerを利用することでクラウド上での実装が容易になる
⑥ 顧客重視、プロセスの自動化などを特徴とするデジタルトランスフォーメーションの実現においては、モバイル(as a タッチポイント)、IoT、ビッグデータ、AI、クラウドなどの要素技術を組み合わせることが重要である。
⑦ マイクロサービスは、デジタルトランスフォーメーション(DX)の実現手段の一つとして有望であり、とくに、サービスの連携と進化容易性を保証するものと思われる。
(2) 19:30～20:30　議論
① 最後のスライド、まとめの⑤（プロトコルなど）は誰またはどのチームが考えるのか（栗田）。Dockerなどのコンテナをつかうことが多い。今後の検討課題とする（落水）
② マイクロサービスは、個別自由にやるという思想なので、全体に風呂敷をかぶせる必要があるセキュリティとの相性が悪い（矢島）
③ DevopsとMSは関係があるのか（日下部）。ある（答え）
④ マイクロサービスでは、開発者＝ビジネスマンである必要がある（栗田、矢島）
⑤ AMAZONほど人材がそろってない会社で、MSを実施している例が知りたい（栗田）
⑥ Docker, Kubernetess等のMSの具体的インプリメンターションを勉強したくなった。一番のとっかかりは、bounded contextではないかと。これをもっと追求してみたい。Boundedがどのように認識され、実装の対象として切り出され、それらの非同期性を如何に制御するか？DockerとかKuberunenetisはこれらを容易にするものと考えるが、それらとMSの具体的な接点は？（新谷）
⑦ DXは経営者がリードするトップダウン型である必要があるといわれるが、日本ではトップはリードしないことが見られ、米国ではトランプのように独裁型が見られる。このような環境でbounded contextをどう管理、推進してゆくか、非常な関心がある（新谷）。
⑧ 16日に受けとった矢島さんからのコメント
DXを実現する技術要素の一つがMSで、そのMSは「個別自由にやるという思想」という印象を受けましたが、その印象は「DXは経営者がリードするトップダウン型である必要があるといわれる」というご指摘に、相反しているような気がしていました。DXにも二種類あると思います。
例示されていたUberやAirBnB、Gilt（会員制セールのサービスです）は、ソフトウェアにビジネスそのものをやらせており、それらの会社での仕事とは、売ったり買ったりではなく、ソフトウェア開発です。そこでは、少人数でどんどんソフト開発していかないと、競争に負けるので、MS化が進んでいます。これらのDXは、ソフトウェアに商売そのものをやらせ、ソフトウェア開発が仕事になっている、トランスフォーメーションです。このDXでは、MSは必要不可欠な要素技術で、親和性が高いと思います。モバイル、IoT、クラウドなども同様です。
巷で言われている(＝
に定義されているような）DXには、人やモノが担っていたことをソフトウェアにやらせることも含まれているような気がします。ここには、ソフトウェア開発は必ずしもいりません。これがもう一種類のDXです。このDXを推し進めるには、トップダウン型でなければなりません。というのは、人やモノが、それぞれのやり方でやっていたものを、一つのソフトウェアにするからです。
残念な事実は、どちらのDXにも、日本企業は苦労しているということです。前者は、ソフトウェアにビジネスをさせるという、新たなベンチャー的発想が生まれにくいこと、企業にソフトウェア開発を自らするという文化（能力）がない（端山さんがおっしゃっているように）ため、後者は、カルロス・ゴーンのようにトップダウンで進めていけていない（瀬尾さんがおっしゃっているように）ため、だと思います。
ソフトウェアにビジネスをさせるという発想や、企業が自らソフトウェア開発ができるようになるには、我が社のような100年企業では困難で、新しい企業が生まれて育っていかないと、ダメなような気がします。米国でも、そうではないでしょうか。そうなるためには、大学はとても重要な役割だと思います。学生人気は、メカ・エレキ＜＜＜＜＜ソフト、のようですし。
UberやAirBnB、GiltのようなDXには、MSは必要な技術で、MSの集合体も、SoSだと思います。
SoSの研究を深めていくために、MSは興味深いテーマであり、UberやAirBnB、Giltのような企業で取り組んでいるDXにも、MSやSoSを進めていくための課題解決策が隠れていると思います。
(3) 20:30～20:35　次回会合について
① 次回とは限らないが、MSとSoSは相性がよいので、今後も検討を続けたほうがよい（矢島）

５． 議事（12月17日）：
(1)18:30～19:30　講演 12月15日に同じ
(2) 19:30～20:45議論
① 1)マイクロサービスは、現代版のライブラリの設計・実装の技法なのか。クラウド上で、リソース制約がなくなったことを前提に、-ドメインモデリングに基づく設計、-保守性と拡張性の重視、-オーバーヘッドを気にしないプロセス間通信（コンテナ）など、高速なネットワークとCPU、大容量のメモリを利用して、設計、実装、配備の知的労力を軽減する取り組みに見える。2)マイクロと言いつつ、そこそこ大きい機能単位のようだ。3)社会全体として利用者数/システム数が増大したことにより、過去には流通しえなかった単位での再利用が可能になったのではないか。（端山）
② 1)ソフトウェアマイクロサービスは、あるソフトウェアプラットフォーム上で、簡便に、ビジネスモデルに従って開発し、利益を得たり、だめだったら破棄したりすることに意義がある。2)関係する技術は、OSSなり、プラットフォーム提供会社なりが、提供してくれる。それをうまく使いこなせれば良い。難しい技術の話は、任せれば良い。3)既存のシステムを、マイクロサービス化する意味は全くない。ぐちゃぐちゃを整理して、マイクロサービス化する意義はない。ぐちゃぐちゃならば、今あるものを全捨てして、EAを参考に、ちゃんとシステムを作る。しかしその時APIを解放して、そのシステム上で、マイクロサービスが走るように作れ！10年ぐらいでまたマイクロサービスだらけになったら、全てを捨てて、またEAで、ちゃんとシステムを作れ！（艸薙）
③ 小さいサービスを組み上げてアプリを作る。それぞれのサービスはDeploy可能というところにMSの一つの特徴がある（方）。マイクロサービスについて、最初知ったのは、クラウド、コンテナ環境と関わりの中からです。その中で言われているマイクロサービスは、小さな独立した複数のサービスを組み合わせて一つのシステムを開発する手法はマイクロサービスアーキテクチャとなる。複雑なシステムを小さく分けるといままでの考え方と変りがないですが、分け方として、一つのビジネスの機能をサービスとして、そのサービスは他のサービスの機能に影響を与えることなく開発、デプロイ、実行、スケールする。各サービスは他のサービスとコードまたは実装を共有する必要が一切しないこと。実際のシステムでそんなようなサービスに分解できるか？　かなり難しいと思います。各サービスは正確に定義されたAPIを通じてやりとりできても。システム全体としてうまく統合できるかがよくわかりません。（方）
６． 今後の予定
(1) MSの話を続ける場合は話題を絞って検討したほうがよい（栗田）
(2) つぎの話題をしては、・モノリスからマイクロサービスへの移行法など、いろいろと調べるべきことがあるが、MSの適用領域、有効性、実施上の問題点などを把握するため、MSの事例について調査してみたい（落水）。

システムオブシステムズ研究会（第1１回）報告
報告者　落水浩一郎

第10回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記

１．日時：2020年11月18日　18:30～20:40
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：日下部茂（長崎県立大）、艸薙匠（東芝）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、瀬尾明志（日本ユニシス）、富松篤典(電盛社)、奈良隆正（コンサル21世紀）、方(ファン) 学芬 (SRA先端技術研究所) 、Huyen Phan Thi Thanh（日立）、堀雅和（インテック）、矢嶋健一（JTB）、落水浩一郎（UIT，世話人）
４． 議事：
(1) 18:15～18:30　接続準備・挨拶他
(2) 18:30～19:30　講演 落水浩一郎(UIT)「VSM(Viable System Model)に基づいたプロジェクト管理システムのSoSへの適用」
複雑系のシステムに対するプロジェクト管理システムの設計、適用例を紹介した。
従来のプロジェクト管理は、まず計画をたて、その進捗を監視し、計画とはずれるところがあれば調整する。プロジェクトが失敗した場合は、その原因を追究し、次回以降の計画に反映させるというものであった。
複雑系システム開発の場合は、確率的、動的、創発的特性のため、不十分かつ部分的な計画しかたてられないので、上記のプロジェクト管理技法ではうまくいかず、環境のスキャニング、内部監視に基づいて、動的安定性の維持を目標としたプロジェクト管理が必要であるとする。
上記の立場から、VSM(Viable System Model)に基づいて設計されたプロジェクト管理システムをSoSに適用した例を紹介し、複雑系のシステムを開発する際、どのようなプロジェクト管理手法をどのように適用すればよいかという問題に関して理解を深めた。得られた結果は、用語の統一、利害関係者のものの見方/考え方の違いの調整など、ごく常識的（平凡）な知見であった。

(3) 19:30～20:30　議論
① 今回紹介した論文で対象としている複雑系のシステムは、われわれの世界（情報システム）に現実に存在するのか？
 ソフトウェアシステムの場合、結果的に複雑になるにせよ、最初から複雑になるわけではない。作るときはシンプルを心がけている（富松さん他、多くの参加者の意見）。
② 環境のスキャニング・内部監視に基づいて動的安定性の維持を保つというプロジェクト管理法は危険ではないか？
 状況がかわるのを管理するということの必要性はある。例えば携帯の開発では、アジャイル開発を行い、ユーザとともにシステムを進化させていくことを心がけている（栗田さん他、多くの参加者の意見）。
③ 複雑系システム、動的安定性の維持を目標としたプロジェクト管理、その理論的背景としてのVSMモデルをどう評価するか
 作り話であるような気がする（多くの参加者の意見）。
 アジャイルスクラムの理論的背景をVSMをもとに作れないか

(4) 20:30～20:35　次回会合について

５． 今後の予定
第12回：SoSとマイクロサービス（落水予定）