• 「Moonwalking Bearに気づかない」、「放射線技師の83％がゴリラを見逃した」などの例は、「白いシャツ」「がん細胞」のキーワードでバイアスをかけてしまい、人は無意識に情報を選択している。
• 特定の集団は特定のバイアスにかかっていることが多い（専門家バイアス）。
• 今の価値から新しい価値を見出す、つまり今までの価値から多様性を生かしながら積極的にバイアスがかかって見えないことを見に行くことでイノベーティブを見出していく。
• バイアスがかかっている中で生活している日常から、必要な時にバイアス外の考えができるようにすることを目指す。

• SDM：System Design and Management
• 慶應義塾大学大学院システムデザイン・マネジメント（SDM）研究科は、専門に特化するのではなく、マルチディシプリンを束ねるインターディシプリナリーな育成を行う大学院。
• 大学院2年生　8割、1年生　7割が社会人で占めマネジメントが多く、文系よりの構成となっている。ベースはシステムエンジニアリングとし、ひとつひとつの専門性を追求するのではなく束ねることにより新価値を見出す。コンポネントな知とアーキテクチャルな知をもつ「ナブラ型人材」を目指す。

• イノベーティブな思考は、システム思考をベースにしながらデザイン思考により創造的に思考することで生み出される。「システム×デザイン思考」。
• 専門家バイアスがかかると観点が広がらない。一方、非専門家の場合は重要でないコメントも多いがバイアス外の観点、意見が出やすい。
  多様性の活かし方、集合知の出し方・原理を理解してイノベーションの価値を狙うことが大切である。

• システム思考には、広義の「システム思考」と狭義の「システム思考」があり、本講義ではシステムエンジニアリングの一部である広義の「システム思考」のことをいう。
• システム思考とは、目的指向もって体系的に全体をとらえる（全体俯瞰）ことである。
  また一人で全体をとらえることは難しく、多様な人々の考えを統合してシステムアプローチの実践ができる。
• 多様な人々が集まると気になることや観点が人によってことなり、議論の発散、ねじれが生じる。
  これを回避するために、①同時に複数のことを言わない、②伝えたいことを端的に伝える、③言葉だけでディスカスしないことが大切である。
  
  ①同時に複数のことを言わない…視点・観点を決め、議論のポイントを絞ることが重要。
  ②伝えたいことを端的に伝える…ポイントを抽出することで焦点が絞られ考えざるを得なくなる。
  ③言葉だけでディスカスしない…日本語は具体的な表現をするには不得意であり、構造化と可視化されたものに対して議論することで具体的な議論がしやすくなる。
• 机を囲んで対面で議論するよりホワイトボード等を使うことで人間同士の対立構造が軽減でき、同じ側にたった議論がしやすくなる。
• 単に人を集めるのではなく、思考の発散と収束を“適切なタイミング”で適切に組み合わせ、思考の流れをデザインすることでイノベーティブな思考ができる。
• また多視点の議論、ブレストの過程であがった意見は、思考のトレーサビリティを活用することでSpiral Upができる。

• デザイン思考はもともとスタンフォード大学の学生たちに足りない所を追加するためのアプローチ。
• アメリカ合衆国カリフォルニアのデザインコンサルタント会社のIDEOでは、デザイン思考はマインドセットであると言われている。
• デザイン思考は①共感、②問題定義、③創造、④プロトタイプ、⑤テストの5つのModeで構成されている。
• Stepとして順番にやるのではなく、Modeとして“適切なタイミング”で実施することが大切。

①共感

• N社が大学に冷凍食品おけるインサイトを依頼した結果、「冷凍食品はめんどくさい」。
  1週間、N社冷凍食品生活を実施した結果、点線から開封する、電子レンジの設定が毎食になるとめんどくさいとの意見の他、高齢者もマニュアルの字が小さく読まずに失敗をすることで冷凍食品を食べなくなっていたことが分かった。つまり、消費者である人間中心の考えから外れていたことが分かった。
• 単に共感するだけでなく、“これまでとは異なる”問題を定義する必要がある。

②問題定義（リフレーム）

• 誰もが考えている課題にそのまま向かっても解決できない。→リフレーミング。
• リフレーミングとは、「普通じゃないけど面白い、しかも重要」という問題に捉えなおす、魅力的で実行する価値がある領域を見つけ出すなど、問いかけや観点を変えることで解決策が変わってくる。
  
  例1.　ホーブディング（自転車用のヘルメット）
  
  通常の問題：どのようにしたら人々は自転車にのるときにヘルメットをかぶってくれるか。
  リフレーム：髪の毛がぐちゃぐちゃにならないでヘルメットがかぶれるか、必要な時だけヘルメットがかぶれるか。
  
  例2.　地球で最も深いゴミ箱
  　通常の問題：どのようにしたら公園のごみをきれいにできるか。
  　リフレーム：どのようにしたら人々は喜んでごみをゴミ箱にいれてくれるか。
  


• 慶應SDMでは、1.今あるものから考えてみる、2.当たり前を疑ってみる、3.問題の完全な解決を目指さない、4.上位の目的で考えてみる、5.分析的アプローチで考えてみる、の５つのアプローチをしている。

③創造

• 単にブレストしてもなかなか発散できない場合は、違和感をブレストすることで違和感の特徴量を利用してアイデアを創出（強制連想法）することで枠外の発想を生み出すことができる。
• 人間は生まれながらにしてクリエイティブであるが、否定や批判されることでクリエイティブさが少なくなっている。
• 仕事でも、落とし所を見つけることでイノベーションできなくなっている。→　大丈夫、できるという信念を持たせることが大切である（クリエイティブマインドセット）。

④プロトタイプ、⑤テスト

• プロトタイプでは分からないからやってみることが大事。
  知らないこと、知らない領域に挑戦するためにまずはやってみること、そしてやってみて分かったことを見つけることがプロトタイプの役目で、トライ＆エラーの繰り返しである。
• ピポットではアイデアは創出できない。インサイト（面白さ、新しさ）を実現するアイデアは多様であり本来のピポットである。つまりインサイト中心のプローチ。
• インサイトとは今まで誰も知らなかった「洞察」「気づき」
• インサイト中心の進め方：分たちが知らないことを知るために、作りながら手を動かしながら考える。
• インサイトの例：見守りロボットをわざと段差にひっかけることで、ひっかかったロボットを老人が助けることで見守り機能を実現する。
• インサイトはどこを確認、確度をあげたいかを意識しないと意味がない。
• 二階建て経営において、既存事業では計画通り進めることがKPIであり、新規事業ではトライ＆エラー施行の数がKPI、どちらのKPIかを業務ごとに考えてマネジメント実施するが、知っているつもりで分かっていないことが最も面倒となる。

• プロセスフレームワークを試行錯誤で調査していき、システム思考が抜けないようにすることが大事であり、5つのモード、アビリティ、マインドセットの組み合わせが大切である。
• イノベーティブ思考能力には、考えつける、見つける、説明できる　要素が必要であり、“見つけること”と“説明すること”は訓練できる。
• イノベーティブさを説明できることで、既存のアイデアの横展開をすることができる。
• 既存のいい事例はそのアイデアのポイント（良さの理由）を抽出した上で持っておくと横展開ができる。

• 必要とされる力は、そもそも何を作るのか（What to meke）を考えるだけでなく、どう作るのか（How to make）も考えられる力が要求される。
• システムと外界との関係性、システムを構成する要素とその構成要素間の関係性をアーキテクチャと定義する。
  さらに、時間要素（過去、現在、未来）の関係性も見なくてはならない。
• エンジニアリングの方法であるサイエンスは数式で構成されるため、インプットが同じだとアウトプットも同じになる。またアーキテクティングの方法であるArtは人への依存度が大きく結果が安定しないため、ルールや手順を決めるより人材育成が重要である。　参考著書：The Art of Systems Architecting
• 多様な考え方を統合する。
• 多様な業をつなげる人たちとディスカスする場合は、「構造化」と「可視化」つまりアーキテクチャが必要で多様な意見を得ることができる。
• ものごとの何をどう変えるかはもともと何がどうなっていたかを知る必要があり、アーキテクチャは多様な“業”をつなげるSociety5.0の土台となる思考法となる。
• プラットフォームを創出するには、デザイン思考的なアプローチだけではうまくいかない場合が多く、業を超えた繋がりを作ることで価値を提供することができる。
• 業と業をつなげるという意味で「System of System」として扱われる。
• 業は今まで縦割りで扱われており、横串がされてなかった。これまでの業とは違う切り方を示す＝業の再定義が必要であり、プラットフォームの検討に活用できる。
  例えば、災害プラットフォームでは、避難者の見積りや電力状況の復旧予測、緊急車両の手配などの判断に活用できる。

• デザイン思考は4つのマインドセットを持つために体系化されたもので、ベースの違いを加味したアプローチが必要。
• 日本では「多様性が機能する仕組み」、「システム的なアプローチの追加」することで、より「新価値創造」をガイドする方がよい。実際には、What to make / How to make　を行き来して考える。
• プラットフォームの創出では人間中心的なデザイン思考以外にアーキテクチャ思考が必要。

• アジャイルとデザイン思考は同じように感じます。違いはありますか？
  ⇒アジャイルとデザイン思考は似ていて共通項はあるが、全く同じ思考ではない。


• 品質とデザイン思考はリンクしますか？
  
  ⇒デザイン思考はユーザーにとって本当に価値があるかの観点が中心で、品質は全体的な観点でシステム思考が入ってくるため、直接的には関わってきません。

• 「グラフィックレコーディング(Graphic Recoding)」とは、リアルタイム(-ing)に絵(Graphic)で記録(Record)することである。
• 世界では当たり前の世界で2004年以前から使われている手法で、日本では2014年頃から流行し出している。

• 今までは左脳思考(数理、論理)が主流だった。
• イノベーションが求められ多様化する社会の中、最近では右脳思考（感覚、感性）が求められてきており、徐々に広まってきている。

• まとめると
  スケッチノートテイク：一人でコツコツ記録を残す。
  グラフィックレコーディング：一人で絵を使って記録する。
  グラフィックコミュニケーション：絵を使って1対1で会話する。
  グラフィックファシリテーション：絵を使って1対多で会議する。


• 【ワーク】　“せん”　をテーマにグラフィックレコーディングしてください。
  ＜結果＞
  単線、数字の1000、1000円札、コルク栓等々、人によって描くものが異なる。
  よって絵で示すことによって共通認識を持つことができる。


• 「絵が苦手」の本質は、「みんなと同じ」でないから恥ずかしいということ。
  つまり、「うまい」「下手」ではなく「違う」だけであり、いろいろな「違い」を吸収して知識を広げることが成長の伸びしろとなる。
• 外国人からしたら漢字だってアートと思うように、大事なのは発想力であり、引き出しを増やすことである。


• 【ワーク】　「品質」／「ソフトウェア」で連想する言葉を共有してください。
  ＜結果＞
  連想する言葉が他の人と異なることが多い。つまり人の頭の中は見えない、スキーマである。


• 「普通」「常識」は人によって大きく異なる、ということを念頭に入れて、人とコミュニケーションをとっていった方が良い。


• 悩み
  言いたいことが伝わらない、なぜか誤解される、伝わったような、ないような・・・という悩みの原因は、「イメージ言語間変換のずれ」であり、バイアスをかけてしまうからである。
• 概念
  左脳（言語）と右脳（絵）のバランスをとりながらコミュニケーションとるのが大切である。

• 顔を描くのは難しいという思いを払拭するための手法を紹介する。
• 人間の感情を表す顔は、眉、目、口の組み合わせだけで表すことができる。
• 【ワーク】　「喜」「怒」「哀」「驚」を絵で表現してください。
  ＜結果＞
  
  
　　 　　　　　　　　　　　　
• 【ワーク】ありえない顔を描いてみてください。
  ＜結果＞
  左右対称で描いている限り、あり得ない顔はなく、何かの表情になってしまう。


• 困り顔から笑顔などイメージの変化を表すことで意識共有がしやすくなり、ミーティングなどで使えてアイデアや発想が出やすくなる。
• 似顔絵はその人のワンポイントのキャラクタを作る。そして“名前”をつけてデフォルトにしてしまう。
• 眼鏡は眼鏡フレームの下半分だけで表現できる。
• 眉毛を上げ気味にする：賢そうな表情、下げ気味にする：優しそうな表示にできる。
• 目の下に三本線をつけることで可愛さを表現できる。

• グラフィックを活用することで、話し手、聞き手が気持ちよくコミュニケーションをとることができる。

1. 絵を描いているツールはなにか？
   ⇒“プロクリエイト”というツールを使用している。


2. 表情が読めない、笑っているような方の表現の仕方
   ⇒気持ちをグラフ状（上り気味、下がり気味）で示すことでコミュニケーションにも使える。


3. 偉い方、上司の方を絵に描いて関係が悪くならないか？
   ⇒ナナメ線など危ない線をかかなければ関係悪くなることはないと思う。
   　キラキラ度を増やすなどもサービス精神も忘れずに。


4. 絵が得意な人など、記録する人が一人に偏ってしまうのではないか、偏ってしまってよいのか。
   ⇒どう受け止めたか、どう理解したかを可視化することが目的であるため、3、4人など複数で描くほうが望ましいと考える。


5. ふざけているように思われないか
   ⇒チームメンバーなど小さいグループから徐々に活動範囲を広げていく方がよい。


6. 似たような集団時の描き分け方はないか？
   
   ⇒その人の特徴的な感情を特徴的なイラストにすると見分けがつく。あとは名前で分けてしまう。一生懸命、似顔絵を描く必要はない。


7. Windows系のハードウェアが必要か？
   ⇒ホワイトボードでも大丈夫。


8. 色使いなど工夫点はあるか？
   ⇒黒と黄色と青を使うとよい。赤は見えにくいので避けたほうがよい。

１．システム開発プロジェクトの課題

• 最近は失敗より残念（ユーザーに感謝されない、使われない）なシステムの増加している。
• 「感謝されるシステム」と「残念なシステム」の違いは何だろうか？
• 熟練者は経験的に「成功のツボ」を知っている。

２．プロジェクトの成功のツボとそのモデル化

• 上記経験者の成功のツボを「4つの力 17の視点」にモデル化した。
• ［4つの力］
  1）IT構想力
  2）IT構築力
  3）IT活用力
  4）IT基幹力
• ［17の視点］
  1）IT構想力
  
  ① プロジェクトコンテキスト
  ② アイデアの吟味
  2）IT構築力
  
  ③ チームの状況
  ④ プロセス
  ⑤ コンピテンスとナレッジ
  ⑥ 優先順位づけ
  ⑦ プロジェクトの目的とゴールの明確さ
  ⑧ マネジメントのサポート
  ⑨ 関係者の関与
  
  3）IT活用力
  
  ⑩ IT展開戦略
  ⑪ IT品質
  ⑫ IT展開手段
  ⑬ IT展開の役割と責任の明確さ
  ⑭ 保守と運用
  4）IT基幹力
  
  ⑮ 期待管理
  ⑯ ナレッジマネジメント
  ⑰ マネジメントコンピテンス

３．ImprovAbilityモデルの特徴

• 目的は使えるシステムを実現することである。
  このために、プロジェクトを自己診断して、解決に向けての対策立案をサポートする。
• キーワード
  （1）準備万端：分析と予測により準備万端にして成功の確立を高める。
  （2）リアルタイム改善：常に状況変化を察知し適切な対策を講じる。
• 簡易なモデルと明確な手法
  17の視点でチェック、重要な項目の絞り込み、解決データベースを参考に対策を立案する。

４．開発経緯

• 「成功のツボとは何か」を事例調査・分析。
  2003年～2006年のTalent@ITプロジェクトを集約し、54の基本パラメーターから20個のパラメーターへ。
  →プロジェクト診断では17個にした。
  ※ISO化：ISO/IEC TR 33014（2013年12月発行）

５．ImprovAbilityモデルのチェックポイント

• 4つの力、17の視点と51の診断項目を参考にセルフチェックを行う。

６．課題抽出と解決策設定までの手順

• 課題分析（51の診断項目での達成度判定表とプロジェクト特性要因評価））→評価（パラメーター重要度判定表）→課題絞り込み（達成度判定・重要度集約表）→解決策案（解決候補データベース）→解決案実行。
  ※（　　）内は本TOOLのワークシート名

７．ImprovAbilityモデルのツール

• ①チェックシート
  ②プロジェクトタイプ設定
  ③解決策データベース

• プロジェクトリーダーのセルフ診断・解決の流れは次のとおり。
  第1ステージ「分析・評価による課題特定」
  第2ステージ「課題解決」
  両ステージを通して実際に自己診断、解決策候補を導き出すまでの流れを体験できた。

• ポイント：
  ①準備万端
  ②リアルタイム改善
• ツボを押さえるためツボをモデル化したのがImprovAbilityである。
• 実践のためのツールなのでぜひ、広く活用・フィードバックいただきたい。

1. 自己診断で診断者はぶれないのでしょうか。
   
   →ガイドラインは4段階で示しているが、解釈の違いが出る可能性はある。先輩などが問いかけて確認する必要がある。
2. 診断の頻度・タイミングについて教えていただきたい。
   
   →開始時（準備万端）。大きなマイルストーン（要件完了で開発前、詳細設計前など）
   経験的には後ろに行けば行くほど、問題がわかっても解決が難しい。
   このため開発時にみて手を打つ、手を打たないものも可視化されているので気にしておける。
3. 第三者レビューでの活用することは可能でしょうか。
   
   →可能である。もともとのモデルはアセッサー用のモデルなので活用は可能である。
   日本ではデンマークのモデルを自己診断できるようにしている。
4. PJT特性はデンマークと同じものなのでしょうか。
   
   →PJT特性は同じ。変えてしまうと判断基準が不明になるので同じにしている。
5. 計画で出ないものは後からでよいのでしょうか。
   
   →実施に展開することを最初考えてないことがあるため、できるだけ計画を早く考える必要がある。
6. 期間の評価　12か月で3点とあるが、もっと長いのが多いのではないでしょうか。この点に関して、議論はあったのかご教示いただいたい。
   
   →日本だとすべてが重要になるので、デンマークと議論した。データ収集の観点もあり、条件を変えないという結論に至った。
7. PJTの成功率が低いとあったが、このツールを使った場合の成功率はどれくらいでしょうか。
   
   →2011年から活用しており、アセスメントで使った15PJTで、結果的に失敗はない。
   ただし、診断を頼むPJTは問題意識があるので条件は同一ではない。
8. エンタープライズ、組み込みの差はあるのでしょうか。
   
   →両方で使える。ただし、一部エンタープライズの言葉になっているので読み替えていただきたい。

講演者のご厚意により、本講義資料ならびにツールを公開しております。

• プロジェクトリーダーのためのプロジェクト健全化技法
  ～ 熟練者のツボをモデル化した技法 – ImprovAbilityモデル - ～
• ImprovAbilityの活用 ～ 使えるImprovAbility ～
• 達成度判定表（図書館）
• まとめ

• ImprovAbility（ツール）

※本ツールはチュートリアルの演習用のツールであり、本来Excelで自動的に設定できる箇所も手動で入力する形式となっておりますこと、予めご了承ください。

サイバー攻撃の歴史

• セキュリティにとっての第一のターニングポイント：2000年 科学技術庁などのホームページの改ざん事件。
• セキュリティにとっての第二のターニングポイント：2010年 Stuxnetの出現（遠心分離機への攻撃）
• 第一と第二では攻撃目標が異なり、第二からは標的型に移ってきており、攻撃技術も高くなっている。

今後、増加が予想される攻撃

1. 被害の大型化
   仮想通貨580億円相当の不正流出する事件
2. 被害形態の多様化：機密性の喪失から完全性や可用性の喪失へ
   脅威の分類
   （１）機密性（Confidentiality）の喪失: 表法を不当にみられる
   （２）完全性（Integrity）の喪失：情報を不当に破壊、改ざんされる
   （３）可用性（Availability）の喪失：不当な利用によりデータやコンピュータパワーが使えなくなる
3. 攻撃対象の多様化： PCなどからIoTなどへ
   IoTの特徴とセキュリティへの影響: IoTには、
   （１）脅威の影響範囲・影響度合いが大きい
   （２）IoT 機器のライフサイクルが長い
   （３）IoT 機器に対する監視が行き届きにくい
   （４）IoT 機器側とネットワーク側の環境や特性の相互理解が不十分
   （５）IoT 機器の機能・性能が限られている
   （６）開発者が想定していなかった接続が行われる可能性がある、
   という性質があり、セキュリティ対策がより重要になっている。また、IoTではセキュリティがセーフティに及ぼす影響を考えていく必要性が出てきている。
   
   例) 「制御装置: 電力会社へのサイバー攻撃で140万世帯が停電」、「自動車: Blackhatでの自動車の遠隔操作法の発表」、「電子掲示板: 交通標識が『ゴジラ来襲』と警告」
   また、製造工程からバックドアが設置されるなどのサプライチェーンにおける脅威もある。
4. 愉快犯から経済犯・組織犯へ：犯罪組織の高度化
   昔は個人（愉快犯）が多かったが、今一番多いのは金銭入手である。サイバー犯罪者組織では役割の分化も行われている。

• 社会のITシステムへの依存: ITシステムへの依存は増大しており、情報セキュリティの問題が重要
• ISMSとPDCA: リスクマネジメントの仕組みとしてISMS（Information Security Management System）がある。ISMSとは、組織のマネジメントとして、自らのリスクアセスメントにより必要なセキュリティレベルを決め、プランを持ち、資源を配分して、システムを運用することである。（https://isms.jp/isms/）
• リスクとは「将来の帰結に対する現在における予測」という見方が下敷きになっており、常に不確実性とをもなう。工学分野ではリスク＝損害の大きさ×損害の発生確率で定義されるが、情報分野ではリスク＝資産価値×脅威×脆弱性で定義される。
• リスク社会: 自然災害などをコントロールするためのシステムが新たなリスクとして問題になってきている。
• 誤ったリスク認識の例: 2001年の9・11後、飛行機が危険との認識で、自動車の利用者が増えたが、それによって、自動車事故の死亡者数が増加。飛行機による事故の約6倍であった。
• 日本人のリスク感の特徴: ①リスクに極めて敏感でゼロリスクを求める傾向、②安全よりも安心を重視する傾向、③リスクに対しあきらめてしまう傾向
• リスク社会学者などが指摘するようにリスクを制御するのは限りなく難しい。しかし、そこにリスクがある以上、当事者は万全の注意を払ってリスクに対応し続けるしかない。そのためITリスクに応じてどう対応すべきかを明確化していく必要がある。
• リスク評価法の分類
  
  1. リスク分析のアプローチの方向
     ①ボトムアップ型（情報資産の洗い出し）：チェックリスト法など
     ②トップダウン型（情報システム上の脆弱性の洗い出し）：アタックツリー法など
  2. リスク分析における量的扱い
     ①定量的アプローチ：例) 指紋認証に関するアタックツリー分析法
     ②準定量的アプローチ：例）JPDECのリスク算出式、25マスによる準定量的分析方法
     ③定性的アプローチ：例）チェックリスト利用法、質問票利用法、シナリオ分析法
  3. リスク評価の目的と範囲
     ①リスクの大きな情報資産やシステムの明確化
     ②上記＋必要なリスク対策の明確化：こちらが望ましい

• 基本的認識とアプローチ
  
  1. ゼロリスクはないので定量的リスク評価が不可欠である。
  2. ITシステムのリスクは多様であるので、ＩＴシステムが扱う情報の安全だけでなく、ＩＴシステムそのものの安全や、ＩＴシステムが行うサービスの安全も同時に扱う必要がある。
  3. リスク対策が別のリスクを引き起こすことがあるので「リスク対リスク」「多重リスク」への考慮が不可欠である．
  4. 多くの関与者がおり、パラメータの設定などに不確実性を伴うのでリスクコミュニケーションの導入が不可欠である
• リスクコミュニケーションが必要になった背景
  
  （１）人はリスクの存在そのものを認識できないのではないか。
  人はリスクに直面し判断せざるを得ない場合は少なくないが人知を超える判断はいずれにしろできない。
  （２）リスクの存在を認識できたとしてもフランク・ナイトが指摘するようにその事象の発生確率は測定できない場合が多い
  （３）事象の発生確率やその損害の大きさを推定できたとしてもそれらの値そのものに不確実性が残る。
  ナシーム・タレブが指摘するようにすべての確率は主観確率。よって、各人の主観を明確にしそれらのあいだの合意形成を図るしかない
• リスクコミュニケーションの分類と目的
  ・リスクコミュニケーションのフェーズ分類
  
  （フェーズ１）そのリスクに関連する情報を提供するフェーズ
  （フェーズ２）対象となる事象や対象システムが受け入れられうるものかどうかの検討のためのフェーズ
  （フェーズ３）そのままでは受け入れられないとすれば、どのような対策をとるべきかを決めるフェーズ
  
  ・リスクコミュニケーションの目的
  
  目的① 個人的選択：例）禁煙の実施、インフルエンザワクチンの接種
  目的② 組織内合意形成：例）工場の環境対策、オフィスの省エネ対策
  目的③ 社会的合意形成：例）原発再稼働の可否、BSE対策のための全頭検査
• 多重リスクコミュニケータMRCの対象は目的②の組織内合意形成である。
• MRCの背景
  
  背景１．多くのリスク（セキュリティリスク、プライバシーリスクなど）が存在⇒リスク間の対立を回避する手段が必要
  背景２．ひとつの対策だけでは目的の達成が困難⇒対策の最適な組み合わせを求めるシステムが必要
  
  背景３．多くの関与者（経営者・顧客・従業員など）が存在⇒多くの関与者間の合意が得られるコミュニケーション手段が必要
• MRCにおける対応
  ①多くのリスクやコストを制約条件とする組み合わせ最適化問題として定式化
  ②関与者の合意が得られるまでパラメータの値や制約条件値を変えつつ最適化エンジンを用い求解
• 関与者間のリスクコミュニケーションの一例
  
  1. 制約条件に関するもの
     （１）もっとコストをかけてもいいのではないか　（従業員代表の意見）
     （２）情報の漏洩確率は、半分ぐらいにできないか　（顧客代表や経営者の意見）
     （３）プライバシー負担度をもっと小さくしてほしい　（従業員代表の意見）
     （４）利便性負担度をもっと小さくしてほしい　（従業員代表の意見）
  2. 対策案に関するもの：この対策案は使いにくくて困る。外した場合の対策案最適組あわせを求めてほしい　（従業員の意見）
  3. 対策効果などに関するもの：この対策はそんなに効果はないと思う
• 納得のプロセス
  ①説明を聞くことによる納得（確かにそういうような対策案はあるな、確かにそういうような制約条件はあるな）
  ②条件を変えて再計算を行った結果による納得（パラメータの値を変えても最適の対策案はあまり変わらない）
  ③相手に対する信頼による納得（彼の言うことだから間違いないだろう）

1. リスクコミュニケーション法の拡張
   
   （１）合意形成対象者が1000人を超すような問題への適用
   
   ・合意形成対象者が1000名を超すような社会的合意形成問題には従来のMRCは適用できない。
   

   ・オピニオンリーダ向けの従来MRC支援システムであるMRC-Studioと一般関与者の意見を導入するためのMRC-PlazaからなるSocial-MRCを開発

   ・Social-MRCを青少年への情報フィルタリング問題に試適用。一般関与者20名のうち75%がSocial-MRCはこの問題に関する対策案の合意を形成するのに有効と回答。一般関与者の85%が最終回は合理的なものであると回答
   
   （２）経営者とのリスクコミュニケーションも考慮した多重リスクコミュニケータ


2. リスク評価法の拡張
   
   （１）標的型攻撃等多段にわたる攻撃のリスク評価のためのリスク解析法（EDC法）の開発
   
   ・従来はアタックツリーを用いてリスク分析を行っていたが、EDC法を開発。
   

   ・イベントツリー分析とは、標的型攻撃メールなどの初期事象から時系列順に攻撃事象の成功・失敗を追うことでそれぞれのシーケンスの発生確率を求める分析手法。またそれぞれの発生確率にその影響度をかけることで定量的にリスクを求めることができる。

   ・発生確率を求めるために、ディフェンスツリー分析を用いる。
   

   ・東京電機大学の次期セキュリティ対策に対してEDC法を実適用し、リスクとコストが最少となる対策案を最適解として適用。
   
   （２）被害発生防止対策と復元対策の両方を考慮した対策案最適組合せ法
   
   ・イベントツリー分析法を採用することにより、確率と影響の大きさの両方の扱いを可能化
   ・PERT手法を用いることにより影響の大きさの推定を可能に
   
   
   （３）動的リスクを考慮した多重リスクコミュニケータ
   
   （４）発生確率の不確実性を考慮した多重リスクコミュニケータ
   
   ・発生確率をあいまいであると考えて、最適な組み合わせを求める。

• Society5.0:サイバー空間（仮想空間）とフィジカル空間（現実空間）を高度に融合させたシステムにより、経済発展と社会的課題の解決を両立する、人間中心の社会。IoTが中心となって入ってくる。
• IoTの特徴とセキュリティへの影響: IoTには、
  （１）脅威の影響範囲・影響度合いが大きい
  （２）IoT 機器のライフサイクルが長い
  （３）IoT 機器に対する監視が行き届きにくい
  （４）IoT 機器側とネットワーク側の環境や特性の相互理解が不十分
  （５）IoT 機器の機能・性能が限られている
  （６）開発者が想定していなかった接続が行われる可能性がある
  という性質があり、セキュリティ対策がより重要になっている。また、IoTではセキュリティがセーフティに及ぼす影響を考えていく必要性が出てきている。
• IoTシステムでは対象によってセキュリティ対策が大幅に異なる。
• IoTシステムのリスク評価法の開発
  ・方式１：制御型ＩｏＴシステムに対するセキュリティとセーフティを考慮したリスク評価法
  　例) インスリン注射システム
  
  ・フィードバックがあるので従来のアタックツリーのようなものだけではアンセーフな事象の適切な抽出が困難 → STPA手法によりハザードを導き出す
  ・従来のSTPAにはサイバー攻撃が入っていない → STPA手法にサイバー攻撃を追加
  
  ・STPAでは対策案までは対象としていない → 多重リスクコミュニケータを改良し、対策案の最適な組み合わせを求められるようにする
  ・方式２：センサー型ＩｏＴシステムに対するＭＳＳを考慮したリスク評価法
  　例）敷布型マルチバイタルIoTモニタ
  ・システム導入によるメリットとデメリットを考慮する

まとめと今後の方向

1. リスク評価方法の推移と最近の動向を紹介
2. 特に、定量的リスク評価に基づき、対策案の最適組み合わせを求める多重リスクコミュニケータとその改良版について詳しく紹介
3. 最近はIoTシステムのリスク評価方法や、サプライチェーンを考慮したリスク評価方法が大切になってきている
4. 今後はAIシステムのリスク評価も重要に

質疑応答

1. EDC法の東京電機大学への適用にかんして、セキュリティをどれだけのコストをかけるか:コスト試算について、どのように一般化していくらと分配したのか？
   →実際の分析は一回では終わらず、複数回行う。一回目はざっくりおこない、2回目以降はベンダーも決まってくるので、コストや効果が細かくわかってくる。

• ソフトウェアプロセス改善と品質とはどのように「関係させるか？」がポイントである。ドラッカーは「生産性の本質を測る真の基準は、量ではなく、質である」と述べている。
• 一昔前、ソフトウェア品質保証活動はデバックや単体テスト以降のソフトウェア開発工程の後半に行われていた。
  • ソフトウェアの品質が良い ⇒ バグがない、動作中にバグが出ない。
  • 作ったソフトウェアから、どうやってバグを除去するか？
• 今は開発中の工程内でできるだけ品質を作り込むため、ソフトウェア品質活動はすべての開発工程で行われるようになっており、プロセスの改善も進められている。
  • ソフトウェアの品質が良い ⇒ 顧客・ユーザーが実際に利用しているときに満足させられる。
  • どうやって品質を作り込みながら、ソフトウェアを作っていくか？
• ソフトウェアプロセス改善（SPI：Software Process Improvement）は品質を作り込むためにある。
• しかし、開発グループと品質グループとの間には「距離」「川が流れている」などがあるといわれている。品質保証担当からは、ソフトウェアやプログラムの設計・技術の観点から、品質上の問題点や対策方法、検証方法の詳細が分かりにくい → どの程度まで十分に品質を作りこめているかを十分に把握できない
  • 開発部門と品質部門とで品質作りこみ活動のコラボレーションができないか？ → SPI活動
    • プロセスグループ（SEPG：Software Engineering Process Group：SEPG）を結成、組織化することになった。
  • 開発部門で品質向上のためにSEPGでSQAG (Software Quality Assurance Group) を結成し、SEPGとSQAGで開発部門と品質部門をブリッジしている。
• SPI活動の役割と組織化：SPI活動の推進体制モデル（コラボレーションのための役割分担）
  • プロセス SEPG：プロセスを作成・改善する
  • 開発グループ：プロセスを実行して、開発・保守・運用サービスを行う
  • 品質 SQAG：プロセスの実行が適切かを確認する
• SEPG、SQAGは役割：誰もがSEPGとしてSPIできる。 SQAGとしてSQAができる。 → 皆が参加できる。

• 症状：プロセスが形だけになってしまう。
• 原因:「自分たちのプロセス」だと思うことができないから。
  • 「全てを決まったとおりに、やりさえすればよい」ではうまくいかない。自分たちがプロセスの作成に参加しないまま、どこかで決められて、与えられたプロセスだけでは、「自分たちのプロセス」にならないからである。
• 治療1：「自分たちのプロセス（作戦）」になるよう見直す。
  • 機能に割り当てられた品質要求に対応させて、機能別の設計・評価プロセスを設計する。
    • 既知・既存の機能は、通常のプロセスで開発・改造（開発全体をまとめる）
    • 途中で評価して改良するのが、品質向上に得策な機能は、先行して開発
    • 何度も繰り返し作成・評価するのが、品質向上に得策な機能は、反復開発
• 治療2：ソフトウェア品質要求仕様のレビューからプロセスを作る・見直す。
• 品質要求レビューに参加する。
• 品質要求分析を支援する。
• 品質課題・リスクを共有する。
• プロセス（作戦）見直しを相談する。
• 組織の標準プロセスの適用で注意したい点
• プロセスの遵守実行方法は、意図・目的・成果を重視して、複数可にする。
• 選択肢を提供し、取捨選択できるようにする。
• 変えられるルールを提供、皆でちゃんと見直す。
• プロセスは「作戦」：プロセスはC（コスト）とD（期間）制約の下で最大限にQ（品質）を作りこむための「作戦」である。

• 症状：データを集めているが、うまく使えていない、データを取らされている感、がある。
• 原因：「開発・品質のデータは、最初に開発チームメンバ自身が自分たちで使うもの」だと思うことができないから。
  • 平均値としきい値の比較は要注意：平均値よりバラツキに注目
  • すぐにデータを判断材料として使えるようにする。
• 散布図、度数分布図などグラフにして過去／他と比較する。
• 平均値だけでなく、ばらつき、にも着目する。
• どこから問題点の調査を優先するか、選択する。
• データを使って攻めない！人を評価しない！
• 治療1：データは開発チームが自分たちでも使える、が大切である。
• 治療2：データを「自分」も見て、取捨選択の判断材料にすることで、「自分たちのデータ（判断の根拠）」にする。
• データは「判断材料」：データは最大限にQ（品質）を作りこむための「判断材料」である。

• 症状：どんな効果があるの？？？
• 原因1：日常の仕事では、意識的に効果を感じようとする機会がないと、気が付かないから。
• 原因2：そもそも「何を今より良くしたいか？」に、組織も開発プロジェクトチームもメンバーも？？？だから。
• 治療1：開発チームメンバが自分でよくしたいことへの効果を、身近に考える機会、場を作る！
  • 効果を身近に実感する機会を作る：KPTで「ふりかえり」：プロジェクトメンバがミーティングして各自から提案する。
    • 先ず良かったので続けたいこと(Keep)
    • 次に経験した課題、問題点(Problem)
    • 課題解決のためにやってみたいこと(Try)
• 治療2：自分たちが開発・保守しているソフトウェアが、システムや、さらに上位／未来のシステムの品質（価値）にどう貢献できる（支えられる）か？の改善ストーリーを持つことで効果を意識！
  • ソフトウェアが、そのシステム、さらに上位のシステムの品質（価値）にどう貢献できる（支えられる）か？：あなたのソフトウェアが搭載されたシステムは、誰かのシステムのサブシステム
  • 自分たちはシステムにつながる、どんなソフトウェア品質課題を改善したいか？：今より良くしたいことを見える化
  • 未来へ準備するために改善！：バックキャスティング：未来の時点で、どんな姿になっていたいかを想い描くことで、今から、その準備を始めると考えると、変えていこう（改善しよう）とする機会や好機を活かし易い
  • 自分たちの改善ストーリーを持つ
    • 上位／未来のシステムへ貢献できる（支えられる）ような、ソフトウェアの品質（価値）のゴールは何か？
    • そのために、開発中に用いるプロセスが、どのような品質（価値）を成果としてアウトプットするとよいか？
  • 改善ストーリーをもつ：身近な効果を感じられるよう日常の目線から、また、何をどう支えたいのかを、全体を鳥瞰する高い目線から見よう。

• 症状：モチベーションが上がらない（下がってしまう）。
• 原因：組織内の「単に一人の作業者」として、指示され、扱われ、評価され、何かあると責められがち、と感じるから。
• 治療1：互いにリスペクトしている、されていると、感じられることが大切である！
  • 肯定眼でリスペクト（尊重）
    1. 避けたいネガティブな否定的な思考と態度
       1. そんなやり方ではダメダメだ（頭からダメ出し）。
       2. ○○さんが原因じゃないの？（人を責める）
       3. モデルの通りにしないと何も対策が進みません。
       4. 絶対に○○にならなくては、いけない。
• 治療2：自らの気づき、自発的な提案を促すよう、ファシリテーション（例えばツールや手法の施行・自動化を援助）
  • プロセス改善のファシリテータとして振る舞う：心理的安全な組織文化へ
    1. 相談、傾聴、気づきを促す。
    2. 雰囲気、場、機会を作る。
    3. なぜそのプロセスなのか、を伝え、共に考える。
• 治療3：プロセスを改善していくことで、自分の能力を開発し、発揮するチャンスが増えることを伝える。
• あなたはファシリテータ：ソフトウェアプロセス(SPI)改善活動は、ファシリテーション、SEPG&SQAGはファシリテータ

• これからのプロセス改善と品質は？：これからもプロセスで人と技術を結び付ける。
• 誰もがプロセス改善！
  • ソフトウェアのプロセスもソフトウェア（オスターワイル教授）
  • ソフトウェアを作るとき、そのプロセスも設計して実行し、見直して改良！
  • さらに、皆さんが開発しているソフトウェア、システム、サービスも顧客やユーザーの仕事や生活のプロセスの改善・変更・革新を提案し実現しようとするもの！

質疑応答

Q1．プロセス改善の効果の確認はどのようにしていくのがよいか？モニタリングの工夫は？

A1．身近に何が改善効果かを考えることが必要。軽くすることで何がよくなるのか、レビューは軽くしたいが、どうしても見つけたいものは何か、を考えて改善をする。プロセス改善だけの話ではないが、変えたことでの効果を1対1でピタリと当てはまることはない。効果は何年もかかることもある。あまりデータ、データしない方がよい。きっかけは意思である。

●デジタル化を起点として、組み込みソフトウェアの規模が増大。

●マネジメントとしては、プロセスやプロマネを強化する方向へ

• 「エンジニアリングなきマネジメント強化」は悪循環を招くことも

●近年、ネットワークに接続する製品の開発が増加 → IoTでは製品を取り巻く周辺の状況変化が発生している。

●ソフトウェアの資産価値が在庫化している？

• 在庫: ソースコードは複雑で説明困難。信頼できるドキュメントは存在しない。保守コストが膨れていく
• 属人資産: ソースコードはシンプル。設計ドキュメントがそろっていない。個人主導の開発
• 半組織資産: ソースコードは複雑。設計ドキュメントはそろっている。マネジメント主導の開発
• 組織資産: ソースコードがシンプル。設計ドキュメントは整備されている。予測可能な開発
• 戦略資産: ソースコードと設計ドキュメントが統合。戦略的な資産活用ができる

●ソースコードの変更と改善のジレンマ

• 機能追加・削除: 局所的な機能追加で当初の設計意図が埋没してしまう。
• 障害対策: 局所的な修正の積み重ねでスパゲッティ化に陥る
• 性能最適化: 設計構造を崩すことも。
• 再利用資産化: 機種ごとのコンパイルスイッチはアドホックに追加
  →「ソフトウェア疲労」が発生している → 抑制には設計改善による「可視化&洗練化」が必要

ソフトウェア疲労【静的】

1. 一筆書き: 一つの巻子やファイルが長い。作った人にしかわからない
2. クローン: 同じコード断片が点在。修正漏れが発生する。grep検索が最も便利な開発ツール
3. 神様データ: 全てを支配しているデータが存在する。修正の波及範囲が大きい。
4. 中央集権: 一つのファイルにたくさんの関数がある。いつも同じファイルを修正している
5. スパゲッティ: いろいろな関数を呼び出している。副作用が発生する。
6. 老舗温泉旅館: 階層を超えた呼び出し／命名規則がない。引継ぎができない
7. 一枚岩: #includeしているファイルが多い。分割コンパイルができない

⇒想定原因

• 1, 2: そもそも設計していない
• 3~5: 設計技法を使いこなしていない
• 6, 7: 全体を見ていない。アーキテクト不在

●構造設計の基本

• 一筆書きは設計ではない。フローチャート／コーリングシーケンスはモジュール化はできているが、レベル化ができておらず、これも設計ではない
• 構造設計には箱（Whatの名称）、線（利用関係）、配置（水平垂直分割）が必要である。

●設計品質の原則: 凝集度

• 機能的、逐次的、通信的はOK。手順的、一時的、論理的、偶発的はNGである。

ソフトウェア疲労【動的】

1. 末広がり: 処理の起点からフラグ判断を積み重ねて動く。変更は、流れを追いかけないとできない。
2. 裏取引: 後からアドホックに追加されたフラグ変数が多い。改修時に思わぬ副作用が出てしまう
3. 状態迷路: 状態数やイベント数が20を超えている。状態やイベントを追加削除することが大変
4. 途中で待つ: ボタン操作が効かない。イベントの順番が変わると動かなくなる。
5. データ競合: セマフォでデッドロック。スレッドセーフの連続でパフォーマンス遅延
6. タスク過多: タスクの数が意味もなく多い。サイクリック実行型ではループの増殖
7. 凸凹API: IFプロトコルが煩雑。IFの順序が分かると動かなくなる

⇒想定原因

• 1, 2: そもそも設計していない
• 3~5: 設計技法を使いこなしていない
• 6, 7: 全体を見ていない。アーキテクト不在

●制御仕様をそのままプログラミングすると「末広がり」になってしまう。コードレベルで改善しても、他の例にあてはめられない。構造化すれば設計図で説明できるようになる

●プログラミングスタイルの違い: アセンブラ的Cからモジュール的Cへと変わってきており、動解析ファーストではなく、静解析ファーストへと移ってきている

●多面化と詳細化
アーキテクト: 多面的に図面化し設計意図を伝達する
設計担当者: 設計を詳細化しプログラミングを行う

●アーキテクチャ設計とコンポーネント設計

• アーキテクチャ設計は、構造と意図を明確にして人に伝える
  • 重要な部分から明確にしていく
  • 未記述部分（TBD）があってもよい
• コンポーネント設計は、ソースコードに直結する設計
  • 設計書を最新に保つコツは、設計とコードを同期させること

●そもそも「設計」とは？

1. 実装する前に: 要求分析: 要求を正しく理解し、設計することで、手戻りをなくす
2. 全体像を明らかにして: 静的構造: 全体を構造的に俯瞰することで、適用範囲を明確にする
3. 問題点を検討し: 動的構造: 構造要素と要素間の問題を、あらかじめ検討する。わからないことを明確にする。
4. 複数の関係者の認識を合わせる: 文書化: 設計意図を伝達し、開発の方向性を合わせる

●設計図とは

• 静的構造図と動的構造図の両方が必要
• 全体を俯瞰できる粒度で静的構造を表現する

●「設計力」= 分離 + 構造化 + 図解。設計力があれば、いろいろな設計図を読み書きすることができる。そして、次第にいろいろな手法を使いこなすことができるようになる

●組込みシステムの5つのビュー: 静的構造を中心に、動的構造と実装構造を設計

• 目論見: 製品の特徴や売り
• 設計方針: 目論見を実現するための設計方針
• 静的構造: 責務や機能の単位
• 動的構造: 並行動作するタスク要素、タスクや割込みという実行要素単位
• 実装構造: ファイルの構成単位、設計規約

●動的ビューと静的ビュー

• システムを複数の視点（ビュー）でとらえる。複数視点の図面を統合化することで方式設計する

●各ビュー間の関係

• 目論見を実現するための設計方針
• 目論見、設計方針を具現化する静的構造
• 静的構造を下敷きにして、動的構造／実装構造を記述

●アーキテクトの役割

• 正しく判断し、プロジェクトを成功に導く
• 技術支店のリーダーシップを発揮する人

●アーキテクトの基本スキル

• 複数のビューポイントで対象を図表化する
• 複数の図表を統合して一冊の空きてくちゃドキュメントにする
• 様々なステークホルダを巻き込んで、リーダシップを発揮する
  
  • プロマネは売上増大、アーキテクトは利益率向上に貢献する

●システムズ・アーキテクト

• システムズ・アーキテクトに求められること: アーキテクトが経営とテクノロジをつなぐ
  1. 異ドメインの接続: ヘテロジニアスな全体像をつかむ
  2. ビジネスへの補助線: コンセプトやバリューを考える
  3. 本質を見抜くスキル: 抽象化できる人材の育成

●IoTシステム開発を成功に導く要素

• ビジネス価値のプロト開発(PoC)から、素早くゴールに到達（アジャイル）し、運用までを考慮(DevOps)することで、ビジネスを成功に導く
  • これを支えるのが、システムズ・アーキテクト
    • 必用となるスキル: 仮説検証スキル、統合スキル、解析スキル、抽象化スキル、モジュール化スキル

●ソフトウェア疲労の再発防止

• 開発プロセスに設計エンジニアリングを組み込む

●三階建て設計改善

• ソースコードを直接修正するのではなく、設計図上で原因を特定し、アーキテクチャの方針に従って、設計図を修正し、ソースコードを回収する。

●アーキテクチャ設計原則

1. モジュール化: モジュール（変数/関数/ファイル/フォルダ）の識別性。Whatの名称であり、内部にデータを隠蔽している。
2. 高凝集: モジュールが単一目的を持っている。まとまりのあるデータ群を持っている。
3. 疎結合: グローバル結合していない。一覧できるスコープを超えない。
4. レベル化: BOSSを作り、指示<->報告の上下関係を作る。上位がクライアント、下位がサーバの利用関係。
5. 水平分割: 上位が論理、絵画物理。データの受け渡しは、求心/遠心で。
6. 垂直分割: 基本系列と横断的関心及び異ドメインを分離する。横断的関心としては初期化やエラー処理。異ドメインはUIなど
7. 静動分離: 周期起動部（動的）と機能実現部（静的）に分ける。制御スレッドは走りきる。フィードバック処理の最小化
8. 状態連動: 複数の状態が連動して動く。ひとつの状態遷移は状態数を7個以内にする
9. 固定変動（資産化）: 共通部分のライブラリ化やフレームワーク化。変動部分の特定とアーキテクチャ上へのマッピング

●エンジニアリングで全体を俯瞰: エンジニアリングすることで現状打破。図面化と設計の原則原理

●在庫から脱却し、戦略資産へ: 資産価値を向上させる

●ソフトウェア疲労【静的】／【動的】を改善する

●アーキテクトが「丸投げ」をつなぐ

• まずは「コードに近い設計」、最終的に「アーキテクチャで繋ぐ」

●ソフトウェアの資産化アプローチ

• 既存資産を起点として戦略的な開発の実現へ
  • ボトムアップ: 既存コードを部品化して、洗練化・資産化していく
  • トップダウン: 設計意図を明確にして、ソースコードへ反映していく

●悩むエンジニアから、考えるエンジニアへ: コード中心から設計中心へ

＜質疑応答＞

Q1: アーキテクチャの大切さはわかるが、マネジメント層にどう伝えるとよいか？例えば、ソフトウェア疲労を防ぐためにリファクタリングをするための工数をどう得るのがよいか
A1: 在庫という言葉を使うことでマネジメント層に伝えると理解できる人が多い。構造を図で見せるのもよい。中間マネジメントが阻止することも多いので注意が必要。

Q: 組み込みで今後、海外のOEMを相手にする場合、アセスメントでビジネスチャンスを逃すことが多い。ドイツのドキュメントの差は？
A: ドイツではリファレンスモデルが当たり前。トップダウン流のリファレンスモデルをまじめに作るしかない。ドイツはかなり厳密に作っている。

Q: リファクタリングはいつ挟むのがよいのか？
A: リファクタリング目的のリファクタリングはしない。修正、移植の目的のために前段階でリファクタリングするのがよい。

1. 修正のタイミングでリファクタリングする。リファクタリングをしてから、修正する。
2. 移植のタイミングでリファクタリングする。