システムデザインマネジメントの集中講座に行ってきました

2019年11月2日から11月4日まで慶應義塾大学日吉キャンパスで開催された
慶應SDM メソドロジーラボ主催「『SDMの基礎』公開集中講座」
に参加してきました。
集中講座というだけあって講義の量が膨大で、まだまだ咀嚼できていないので、
備忘録も兼ねて、メモしをそのまま写す(考察なし、後ほど考察してまとめる必要)ことにしました。人に見せるように書いてはいないですが、自分の頭の中のモヤモヤをそのまま公開することにします。

業務というのはシステム*デザイン思考システムエンジニアリング、ロジカルシンキング・システムシンキングの上に乗っているイメージ

慶応義塾大学SDMは専門家を束ねる専門家を要請するところ
自分に専門性がない人が専門家を束ねられるか?
多様性をどうやって統合するか
というところが課題である。

たての深掘りではなく横で串刺しする人材が必要である
inter discipline (インターディスプリ)
多くの分野の専門知識や経験が必要な研究課題にあたるときに、様々な領域の学者や技術者が協力しあって横串を通すこと。

ナブラ型人材 http://lab.sdm.keio.ac.jp/maeno/papers/toyotaboshoku2011.pdf

https://www.fujitsu.com/jp/group/fri/column/opinion/2018/2018-9-2.html

ロジカンルシンキング&システム思考

基盤的スタイルは知識として学んだ後に繰り返すことによって身につけるもので、わかることよりもやってみることの方が大事である(例:ロジカルシンキング、システム思考)
知識を学んだりすることは当然として、それをアウトプットすることを考え続けることが大切である。
多視点からみることが必要
教員が言うことを盲信しない

間違いや矛盾を見つけることは簡単だが、良いところを見つけるのは難しい
そこでポジティブを原則にして、相手の良いところを見つけてリアクションする。

「群盲、像を撫でる」という言葉がある
これは部分だけを見て全体を理解することはできない、自分と違うことを言う人が間違っているとは限らない、全体が見えていると思う時ほど思考停止していないか気をつける必要があるということを戒めた言葉である。

だらだら時間をかけても仕方がないので時間、進捗、管理は常に意識する必要がある

ロジカルシンキングは自分とは違うということを前提にスムーズにコミュニケーションすることや、自分の考えをなるべく短時間に誤解ないように伝える技術である。抽象度のコントロール、基本、応用が必要になり、これは参考文献を読んで自分でトレーニングすることができる。
4picks1wordというスマホゲームが抽象度を上げるトレーニングになるので試してみるとよい。

ロジカルシンキングは具体的には多視点からみる、第一印象にとらわれすぎないことが大切(認識の固着)、抽象的な話と具体的な話をセットにする、意図的な抽象度の上げ下げを普通の会話に生かす、うまくいった例の抽象度をあげて概念化する、最初にMECEで全体像を見せてから具体的な例を説明していくことが必要になる。

参考文献:ロジカルシンキング練習帳 照屋花子

アイデアを出すことよりもまとめることの方が難しい

分類をする時、具体例を並べられると理解しづらいので、まずMECEで分類してみる

自分にとっての当たり前は相手にとっての当たり前ではないことを意識しておく必要がある

so whatやwhy soを考えるときには目的を忘れないようにしないと意味がない

相手あってのロジカルシンキングだと言うことを意識しておく必要がある。例えばラブレターを考えるとわかりやすい。
相手も決まっていないのに自分のいいところを並べ立てたようなよくわからないラブレターを書くようなバカはいない。

ロジックを考えながら相手のことを考える必要がある。よく使う論理(エビデンスを本当か確認する)。

コミュニケーションには自分が話しての場合と、自分が聞き手の場合があり相手に期待する反応を決めておく必要がある。それはゴールを定めないと資料は作れないからである。

わかりやすいコミュニケーションをとることを考える必要がある。

パラグラフライティングやロジカルライティングでコミュニケーションのスキルが変わる。

プレゼンは1ページ1ページにメッセージがあるべきで、相手に期待する反応を決めておく必要がある。

会話の技術

相手の真意を見つけ出す必要がある。

相手のリクエストをそのまま実行するのは、相手の最大の満足ではないかもしれない、「なぜ」と質問してそれを何のためにするのかを理解する必要がある。

Teach is learning
教えることをせずに学ぶことはできないという言葉があるのでこの言葉の意味を考えてみると良いかもしれない。

システムシンキング
多視点からみる
現状分析と問題解決のアプローチの一つとして因果でループを書く
目的:複雑なものを分析すること
3冊くらい本を読んだら少しずつわかってくるかも
多様な人々の考えを統合する。
システムズシンキングの肝は多視点から構造化して可視化することである。

Iceberg(氷山)モデル
問題は見えている部分が少ないので、見えているところの対策をとるのは表面的でしかない

システムズアプローチ

因果ループ図:原因と結果という観点で世の中をモデリングする

因果関係とは

  • 出来事の共変(相関関係)
  • 時間的順序関係
  • もっともらしい他の要因を排除

によって決定される。

因果ループのルーツ
2種類の因果リンク
正(ポジティブ)の因果リンク        s(same)
負(ネガティブ)の因果リンク        o(oposite)
2種類の因果ループ
自己強化型ループ                (正のフィードバック)
バランス型ループ                (負のフィードバック)
(システムに安定をもたらす)
偶数個の負のループは正の関係になる

quick fixes
long-term solution

世の中quick fixesだらけ
Systems Archetypes とは
ということを考えてみる必要がある。
うまくいかないときに足りないと考えがちだが、引くことも考える
一見してうまくいっているときに裏で何が起きているか考えないとFixes that failが起こる
手を動かしながら書くのが先で、議論は後。書き直しながらやっていくイメージでやるのが良い。
現実世界の問題について因果関係を見つけるのは容易ではない
Evolutional model (成長していくモデル)でやっていくのが良いかもしれない。
図を書くことが目的でなく、図を書くという手段によって議論を活発化することが重要

とにかく何か一つやってみる。理解してからやるのではなく、やってから理解すると発想を転換する必要がある。

システム*デザイン思考
人は無意識に情報を抽出している。
認知バイアス、専門家バイアスなど人はバイアスの中でしか考えられない。
新しい事業を考える時も自分のバイアスで考えていることが多い。
そこで遠いバイアスの人と組み相互作用をさせることが有用である。

open innovation
バイアスがかかっていないところを意識的に観にいくと良い。

改善のマネジメント、イノベーションのマネジメントでは
マネジメントスタイルが違うので意識しておく必要がある。

理解していると思いながら自分のバイアスの中で考えてしまうことが多い。
人が間違っていると思うときは自分の中にバイアスを持っていることに気づいていないことが多いので注意する必要がある。

自分の専門分野のことであっても専門家以外の意見を聞くことも重要である。
構造化、可視化で自分が伝えたいことをわかりやすくする効果と、議論がしやすくなる効果がある。
思考のトレーサビリティが上がり、可視化すると頭の中にも入りやすくなる

自分たちの専門分野の上にデザイン思考をかぶせるイメージ。
戦略やシステム思考のベースの上にデザイン思考を乗せる。
参考文献:boot camp boot leg

同じ商品でも置かれる場所が変わると意味が変わる
意味のイノベーション(ベンガルディ)

落とし所を作ると良いものにならない
締め切りに向かって全力で走り続けないとイノベーションが起こらない
2週間に1サイクル回す
最後の最後まで走り続けないる方が良いケースが多い→チキンレース
デザイン→課題解決
アート→自己表現
アート思考
ワークショップデザイナー:人の思考の流れをデザインする

イノベーション対話ツール→ダウンロードできる

http://www.mext.go.jp/component/a_menu/science/detail/__icsFiles/afieldfile/2014/06/02/1347910_1.pdf

システム思考 ✖ デザイン思考→イノベーティブ思考 (ハイブリッド)
現在の思考のOSは分析的思考が多い。
だからどうするか?

イノベーションを起こせるアイデアの必須条件  (濱口秀司氏)
1見たことも聞いたこともない
2実現可能であること
3物議をかもす(賛否両論である)こと                        コントロバーシー

イノベーションとイノベーティブの違い
イノベーションhttps://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%8E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
機会を新しいアイデアへ変換し、さらにそれらが広く実用に供せられるようにする過程(玉田俊平太)
創新普及←技術革新ではない

イノベーティブ→面白いが普及の部分が弱い、普及する保証がない
イノベーティブ思考は発散と収束が必要
システム思考とデザイン思考を発散と収束に利用

ワークショップ→参加者の多様性を利用、上下関係のないフラットさが重要

向かい合って議論しないで壁とかに何か書きながら議論することが重要で、何か書くことで一つクッションを置いて、人格を否定されているわけではないと客観的に見るようにする。
プロセスフレームワーク→どこからやってもよい

ブレインストーミング(連想)
少数のメンバーが会話を独占するグループでは負の相関がある。ゼロではなくて、負の相関であることに注意する。

親和と類似は違う
親和で分ける。何かが似ていればよく、論理的には分けていくわけではない。

強制連想法
発想するときシーンはなるべく限定的にすると、面白いアイデアが出やすく、イメージがずれにくくなる。
思いついたらすぐに書いて発言することが必要で、30%くらいの出来で良い一人で考えずに集合知を使うイメージを持つ。
マスを全部埋めるつもりでやっていくとスタックしてしまうのでできるところからやる

CVAを書いてWCAを書く理由は捨てステイクホルダーをある程度固めないとWCAは描きにくい。
ツールを使いこなすと強制連想まで1時間
WCまで2〜3時間くらいでできる
半日くらいあればプロトタイプを作る前のアイデア出しはできる

Innovative Thinking as a Habit

システムズエンジニアリング

システムでは自分の分野だけバイアスに気づくことが多く、自分がバイアスの中にいることに気づけないことが多い。そのため「自分が知っていることと考えないこと」が大切で、どうやって他人の意見を聞くかが重要になってくる。

知っていることでも100%知っていることはないので、知っていないことをいかに見つけるかが必要になってくる。

システムズエンジニアリング
「yes or はい」の精神を持つ。私たちは必ず成し遂げる。できないということはない

システムはナチュラルシステム、エンジニアリングシステムと色々なものを含む
システムはサブシステムの集合体でサブシステムもシステムの一つである。

俯瞰的に捉えるとは多数の視点をまとめるために可視化することであり、
空間的俯瞰、意味的俯瞰、時間的俯瞰の3つの軸がある。

システムズエンジニア:目的を実現させる人

要求の捉え方が重要でそれを取り違えると、そのことがわかるのは最後の方になる
要求:システムを外から見て考える
上位の設計結果は下位の要求になる
要求にも種類があり、評価できないものを要求として出していけない。

コンテクスト分析
システムはコントローラブルであることが重要

個別要求定義分析
要求と設計は明確に分ける必要がある、設計してから要求ではない。どの要求からどの機能が抽出されたかがわかるようにトレーサボリティが必要になる。
個別要求定義手法は3つある。ステート/モード手法、範囲外動作分析構文解析である。

アーキテクティング
アーキテクチャとは退く的を最大化するような機能と特性の配置。
単一ではなく複数の要素を組み合わせることで価値が生まれる。
参考資料:ものづくり白書(経済産業省)

同じ機能を違う物理で実現する
機能と物理の分離は“第一原理思考”の根拠 (イーロンマスクがうまい)

アーキテクチャを作り出す
インターフェース(関係性を明確にする)には、機能設計、物理設計がある。

システムズエンジニアリング最新動向
最近のシステムはほとんどSystems of  Systemsになってきた(今までのシステムでは定義できなくなってきた)

Systems of  Systems→どこに責任があるかわからない
スマートグリッドの人たちが問題に気づいた

産業の再定義、産業構造自体の設計が必要な時代になってきた。
Society5.0:人間中心のためにデータをつなげて使う
Enterprise Systems Engineering
システムを世の中にデプロイするとモディファイする→違う課題が生まれる

VUCAワールド時代
設計をきちんとしてコンテクストをきちんと出しても、製品が出来上がった時にはコンテクストが変わってしまっている可能性がある。

オープンシステムは世の中の影響を受けやすい。D-CASEで世の中の変化をキャッチする。

変化をしやすいところは変化を受け入れやすくする必要があり、機能は変わらないが手段はかわることがあることを理解する。つまり動的に変化していくことを考慮したデザインを考える必要がある。

センチュリーシリーズスタイルプロセスは早く開発して早く使用してサイクルを早く回す必要がある。ミッションアシュアランスを守るためにはあえて品質を上げないという選択肢もあり得る。

部分最適よりも全体最適を目指すべきである。

ボトムアップでもものはできるが、立証が難しい(安全性など)ということは考慮しておく必要がある。

というメモを残してあるが、まだまだ腹落ちするところまで行っていないので、
これから考察したり、まとめたりしながら腹落ちするまで深く考えていく必要があると思います。
考察が済んだところから少しずつブログにアップしていく予定にしています。

Leave Comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です