ロジカル・シンキング & システム設計・プログラミングについて

37
ロジカル・シンキング システム設計・プログラミングについて 2017/01/23 齋藤 大 <[email protected]>

Upload: dai-saito

Post on 10-Apr-2017

173 views

Category:

Business


0 download

TRANSCRIPT

Page 1: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキング

システム設計・プログラミングについて

2017/01/23 齋藤 大 <[email protected]>

Page 2: ロジカル・シンキング & システム設計・プログラミングについて

§0. Introduction

ロジカル・シンキングの掟

- 結論ファースト -

このスライドも結論ファーストで書かねばなりません。

結論「ロジカル・シンキングは社会悪 もしくは ゴミです」

Page 3: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングとは?(1/2)

とりあえず wikipediaより抜粋

一貫していて筋が通っている考え方、あるいは説明の仕方のことである。

英語辞書に、logical thinkingという語彙を持つものは少なく、あっても十分な説明になっていないことが多い。

日本でロジカル・シンキングや論理思考の概念が広まった契機は、『ロジカル・シンキング』(照屋華子・岡田恵子, 東洋経済新報社, 2001年)以来、主にコンサルタント系の著者たちにより、ロジカル・シンキングのための様々なツールや手法が企業向けに提唱され、ビジネス書のブームとなったことにある。

以上のことから、logical thinkingは英語圏で広く通用する一般的な語彙ではなく、特定の経営コンサルティング会社あるいは業界用語とみなすことができる。

Page 4: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングとは?(2/2)

長くなるから、以降 wikipediaを要約

● 論理的思考に見せかけた、論理的思考と似たパターンの思考テンプレート。

● 顧客や敵対相手を説得するための手法であり、自分の思考のためではない。

● 「論理的思考」とは全く別物。

ロジカル・シンキングは固有名詞であり、一般名詞の形をしたテンプレの名前です。名前と実態が異なってますね。

[参考]関東鉄道:規模は大きそうだけど茨城県しか走ってません行け!!南国アイスホッケー部:アイスホッケーをやってたのは最初の数話で 後は全部下ネタギャグ漫画SoftBank:銀行じゃねーし!

Page 5: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングの基本パターン以下、ロジシンと省略。

ロジシンでは、結果(1)と原因(n)を1ブロックとして考え、それぞれ子ノードを連ねたツリーとして思考パターンを扱います。因果関係のブロックでは、原因を漏れなく列挙する必要があります。

で、全体が因果関係を表すツリーとなり、思考を表現する もっともらしいフローができあがります。

この基本パターンを軸に、様々なフレームワークと呼ばれる「データの見せ方」を使用して、無茶苦茶な言い分さえも優れた思考結果のように見せることができます。

これがロジシンです。

結果

原因 原因 原因

1ブロック

結論

原因原因原因原因

So what ↑ ↓So why

Page 6: ロジカル・シンキング & システム設計・プログラミングについて

フレームワークに関する注意

ロジシンで考えている フレームワーク は、多くが優れたデータ解析術・データの解りやすい表示フォーマットですが、これらはロジシンのために発案されたものではなく、ロジシンの発案者が勝手にサブセット化したものです。

優れた「フレームワーク」の例

SWOT分析

いろんなグラフ フィッシュボーンダイアグラム(どちらかいうと  QCサークルの縄張り範囲)

Page 7: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングで発生しうる結論の例

「想定の範囲外でした」

「1000年に一度の大地震」

「ありがとう文春!」

「明日は糸魚川の視察に行く事になりました。移動だけで1都5県です。

こんな日程をありがとう」

「機内サービスがなっていない。今すぐ飛行機から降りろ」

「ただひとつの火花でも飛ばすなら、我が千万軍民は積もり積もった憤怒を

総爆発させ、侵略者らの牙城と本拠地を無慈悲な稲妻で破壊する」

ごめんなさい。誇張です。

Page 8: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングの欠陥点

● 実際の論理学とは全く関係がない。もっと言うなら、論理的でなく、実際の思考に

沿っているわけでもない。

● もっともらしいネーミングで人々を騙している。実態は、コンサル屋に都合の良い風

習の構築にすぎない。

● 目的が、アイディアを出すことではなく、説得すること である。

● 実際にやると、思考のスタート地点が「結論」になってしまいがち。 逆だろ!とい

うツッコミはダメ。

● 実際の論理的思考で、因果関係が2次元のツリーに収まるわけないだろ!アホか!

● ↑のように、主観を込めた論理展開をしても、それをチェックする余地がない。

● 真偽のチェックは、論理展開の矛盾点や抜け漏れのツッコミぐらいであり、逆に、そ

れらにミスがあれば結論はカス同然となる。もったいない。

Page 9: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングの優れた点

● 人を騙せる。

● なんとなく、優れた人 や 意識の高い人 に見える。

● ロジシン同士で見解をぶつけ合えば、お互いが曲げないため、長時間の議論になり、

なんとなく充実感を味わえる。

● 同僚や部下に「結論ファーストで!」と言えば、自分の考える手間を省ける。

結果として論理的な構成に見える成果物を生み出すのがロジシンです。なので、本当の論理思考を苦手とする人がどうしてもコンサル的な資料を用意しなければならないような場合には、有効な手段ではあります。ただし、名前に反して、本物の論理学とは大きくかけ離れたものなので、盲信することは危険です。

序章はこれで終わりますが、ここまで主観を前面に押し出して書いています。たとえロジカルに述べていても、客観的な視点を欠いていては説得力が無いことの例として扱ってやってください。

Page 10: ロジカル・シンキング & システム設計・プログラミングについて

§1. 思考

「ロジカル・シンキング」が “thinking” を扱っていないので、モデル化された「思考」を考えていきます。

Page 11: ロジカル・シンキング & システム設計・プログラミングについて

バイナリ的思考とテキスト的思考

題名にある正確ではない用語はともかく、思考は2種類に大分できます。

● 「無意識」に近い 言語化されていない思考。

● 日常で使っている言葉に近い形で言語化された思考。

言語化されていない思考は、歩く時の筋肉を動かす脳からの指令などはもちろん、記憶を遡るときなども「あれってなんだっけー?」みたいにいちいち言葉にはせず、脳の部位同士が理解できるモヤモヤした信号で思考が実行されます。日常の大半がこの思考です。一方、何かに迷って悩むとき や 落ち着いて何かを検討しなければならないとき など、(場合によっては独り言など)言語化した思考を仲介することでやっと解決できる場合もあります。

便宜上、前者をバイナリ的思考、後者をテキスト的思考 と呼ぶことにします。コンピュータと同じで、予め思考パターンがコンパイルされている か スクリプト言語のように随時解釈しているか の差がありそうです。

Page 12: ロジカル・シンキング & システム設計・プログラミングについて

直観と論理(1/2)

● 「無意識」に近い 言語化されていない思考。(バイナリ的)

● 日常で使っている言葉に近い形で言語化された思考。(テキスト的)

バイナリ的思考は、それまでの経験を通じてコンパイルされた思考パターンを辿ります。この思考は高速であり、扱うデータも意外と大規模なものです。これは、実際に1か月前の特徴的な出来事を思い出してみれば実感できます。「え~と?」と考えるよりも前に、直観的に思い出せることがあるはずです。

さて、今度は、10年前の出来事を思い出したい場合、どうするでしょうか? なんとなく、その付近の出来事を思い返し「あれは冬だった」「あれは8月ぐらい」「その間に起きたことは…」みたいな感じで思い返しませんか?この時、ある程度の言語化された思考を仲介しがちです。「~より前」「~より後」といった判断は、典型的な「論理」であり、何かしらのテキスト的言語を仲介することで論理的な判断を割り込ませやすくなります。

Page 13: ロジカル・シンキング & システム設計・プログラミングについて

直観と論理(2/2)

「直観」で過去の出来事を思い返したり、やはり「直観」で ある程度パターン化された解を思い浮かべる機能が人間には備わっています。さらに、言語を介した「論理」によって、一時的に思い返したデータを管理する機能も備わっています。直観と論理のどちらが重要か?ということではなく、どちらも重要です。なので、直観力や論理力だけを磨こうとしてもあまり意味をなしません。

過去の知識・経験

直近の知識・経験コンパイル

記憶断片

論理

直観

行動直観

記憶断片記憶断片記憶断片

直観

論理

記憶行程 行動行程

Page 14: ロジカル・シンキング & システム設計・プログラミングについて

§2. 記憶作業 と 意思決定

思考過程のうち、記憶の過程 と 行動の過程 について、詳細を考えていきます。

Page 15: ロジカル・シンキング & システム設計・プログラミングについて

記憶パターン(1/2)

知識・経験のコンパイルや直観的工程は、いずれも言語化されていない「バイナリ的思考」で行われます。これは、いわば人間に備わった「機能」です。ところが、同程度の速度で、やはり人間の機能として忘却力が働きます。なので、実質的に、知識・経験をストックできる総量には上限が存在することになります。そのため、本能的に記憶するデータ量を抑えながら、直観での検索のしやすいフォーマットにコンパイルすることが、ある程度無意識に行われます。

過去の知識・経験

直近の知識・経験コンパイル

忘却

記憶

Page 16: ロジカル・シンキング & システム設計・プログラミングについて

記憶パターン(2/2)

記憶するとき、脳の機能でフルオートにコンパイルされますが、このままオート機能に任せて記憶すると、早い段階で忘却機能によって破棄されてしまいます。なので、意図的に忘却を防ぎたい場合は、この記憶行程で少し工夫をする必要があります。記憶方法としてよく挙げられるのが「反復して意図的な体験回数を増やす」「過去との類似性を探しながら理解を深める」であり、意図的なこれらの工程を経由することで雑多な他の記憶と差別化した状態でストックされます。

過去の知識・経験

直近の知識・経験 コンパイル忘却

記憶(ラベル無し)

記憶断片 直観

記憶重要

記憶〇と類似

論理(ループ)

論理(抽象化)

Page 17: ロジカル・シンキング & システム設計・プログラミングについて

記憶時の具体指向思考

大量に記憶すべきデータの中で、どうしても忘却機能をブロックしたい場合、「これは重要」とラベリングしたデータとしてストックします。その場合の記憶方法の多くは「反復処理」です。● 歴史年代を覚えるために暗記用のペンでマーキングした箇所を何度も読み返す● すっぽかすとマズいお客さんの打ち合わせ日程を付箋に書いてモニターに貼るなど、具体的なデータを記憶から反復して出し入れすることでラベリングします。

過去の知識・経験

直近の知識・経験 コンパイル

記憶断片 直観記憶重要

論理(ループ)

記憶重要

記憶重要記憶重要

Page 18: ロジカル・シンキング & システム設計・プログラミングについて

記憶時の抽象指向思考(1/2)

意図的に忘却を防止する必要はないものの、長期にわたって応用が利く形で記憶しておきたい場合、抽象化する作業を経由して記憶にとどめます。人の記憶の多くはこのパターンであり、典型的には「類似性」や「対比」を頼りに抽象化します。● (この初めて見る芸能人は、男で髪が長くて色白でオカマ言葉で…)● (強火でバター使って3分炒めたら黒焦げになった。前はオリーブオイルだっけか…)この抽象化が進行し、記憶の出し入れが最適化された状態が「理解」です。

過去の知識・経験

直近の知識・経験 コンパイル

記憶断片 直観

記憶〇なパターン

記憶特徴:〇

論理(抽象化etc)

● 〇に似てる● ●とはここが違う

Page 19: ロジカル・シンキング & システム設計・プログラミングについて

記憶時の抽象指向思考(2/2)

抽象化した場合、記憶した事柄は● 抽象化が済んだ骨格部分(雛型)● 骨格から元の記憶を再現するための原始的データ(primitive型データ)をセットにしてストックされます。多くの場合、このセットは他のセットと親子関係を持ち、互いが関連付けられてストックされます。

旅行に行った記憶場所:北海道網走同行者:なし時期:2月

宿に泊まった記憶場所:網走駅前

設備:普通日付:初日

食べた記憶場所:網走港食べたもの:カニ美味さ:格別

……

食べた記憶場所:〇〇

食べたもの:〇〇美味さ:〇〇

原始的データ場所=網走港食べたもの=カニ美味さ=格別

Page 20: ロジカル・シンキング & システム設計・プログラミングについて

行動までの工程

歴代の様々な実験から「行動」は次のような時系列で行われていると考えられています。

1. 脳が指令信号を発する2. 自らの意思で行動を決定する3. 実際に行動する

日常の多くの単純な行動の場合、2の論理は 「すべてそのまま実行」となり、脳の指令→行動 が直接的に実行されます。

単純行動の範囲を超え「意思決定」が必要になる場合、1の脳指令信号 は 2では「直観的に復元されたデータ」として認識され、必要に応じて論理的な考察を経て 3の行動に移ります。

Page 21: ロジカル・シンキング & システム設計・プログラミングについて

意思決定

意思決定時に、直観から得たデータがそのまま行動に結びつけられる形式になっている場合、論理処理はほぼ省略され、行動に直結します。日常的な単純行動 や 意図的に抽象化された記憶データは、この時に必要だった論理処理を予め済ませているため、行動に直結しやすい形式になっているわけです。一方、具体志向でストックされた記憶を扱う場合は、意思決定に必要な記憶断片をすべて復元し、なにかしらの論理を経て意思決定の結論を出すことになります。

過去の知識・経験行動

直観

記憶断片記憶断片記憶断片

直観

論理

意思決定

抽象指向

具体指向

Page 22: ロジカル・シンキング & システム設計・プログラミングについて

思考パターンのまとめ-具体指向と抽象指向

総合すると、思考には具体指向と抽象指向があり、記憶内容の特性 や 最終的な行動時の目的 に応じてこれらを使い分けることになります。 その目的自体が個人個人それぞれで異なるため、この使い分け自体、傾向にバラつきが発生します。一般的に着目されるのは「意思決定」の工程であるため、具体指向の方が論理的な行動を伴うと考えられがちであり、注意すべき点であるといえます。

過去の知識・経験

行動

直観

記憶断片直観

論理

抽象指向

具体指向

直近の知識経験

コンパイル

記憶断片

記憶断片記憶断片

論理(抽象化)

コンパイル

論理(ループ)

直観

Page 23: ロジカル・シンキング & システム設計・プログラミングについて

§3. ビジネスでの具体指向の危険性

扱うデータの量と質の影響で、ビジネス社会では日常の思考と系列が異なります。そのため、人間の無意識な思考系列を排除しがちですが、これには問題点が潜んでいます。

Page 24: ロジカル・シンキング & システム設計・プログラミングについて

漠然・抽象・具体

(深く触れませんが、日本人は「抽象」を苦手とし「具体」を好む傾向が強いようです)(日本の)ビジネス社会では、「具体」を好む傾向があります。ただし、これは「抽象」の特徴を理解しているわけではなく、「抽象」=「漠然」として考えているほどであり、手に負えないなかなか危険な状況です。

抽象散在する多くの事象から論理的な共通点を抽出した骨格

具体(正確には ≠具象)テーマに沿ってカテゴライズされた生データ または 抽象から復元された事象

漠然テーマやカテゴリーが不明であり、(数値, 真偽値など)原始的なデータも伴わない状態

Page 25: ロジカル・シンキング & システム設計・プログラミングについて

漠然とした具体 の危険性

ビジネスの世界では、兎にも角にも具体性を好みます。● 抽象的なデータよりも具体的なデータの方が馴染みやすい● 提示されたときに頭を使わないで済む● なんとなく説得力がある具体指向の思考傾向が強い人物にとっては そのデータをそのまま受け入れられるため問題ありませんが、抽象指向の思考傾向が強い人物にとっては受け入れがたいものです。

「サル と ブタ」具体を列挙しているつもりかも知れませんが、いきなり言われても生物の分類, 絵文字の種類, カタカナ2文字の言葉, 人種差別問題, 絵本のテーマどれに該当するのか理解できません。

「売り上げ目標 1億円」多いのか少ないのか, 削減箇所は社員の給料なのか設備投資なのかたとえ数字を含んでいても漠然とした具体であり、理解しづらい情報です。

Page 26: ロジカル・シンキング & システム設計・プログラミングについて

具体指向と抽象指向 どちらが優れているか

「具体指向と抽象指向のどちらが優れているか」というテーマが出た場合、多くの人は「自分はどちらなのか?」という思考が先行します。それで構いませんが、実際のところ、どちらが優れているというものではありません。業種とその担当分野によります。ロジカル・シンキングを提唱し具体指向を好んでしまっているコンサル業界では、本来の内容からすると意思決定速度を重視した抽象指向の方が適切です。

過去の知識・経験

行動記憶断片直観

論理

具体指向

直近の知識経験

記憶断片

記憶断片記憶断片コンパイル

論理(ループ)

直観

ロジカル・シンキングの守備範囲

Page 27: ロジカル・シンキング & システム設計・プログラミングについて

ロジカル・シンキングの大きな問題点

ビジネスや学術分野で扱うデータの量は大きいため、「暗記」の延長として具体指向に偏ってしまいがちです。ロジカル・シンキングの大きな問題は、この具体指向思考での意思決定論理に限定した方法論である点(加えて、名称に惹かれて支持者が「信者」と化している点)です。「抽象化」の論理にも言及し、さらに「思考」と「論述方法」は分けるべきでした。

過去の知識・経験

行動

直観

記憶断片直観

論理

抽象指向

具体指向

直近の知識経験

コンパイル

記憶断片

記憶断片記憶断片コンパイル

論理(ループ)

直観論理(抽象化)

Page 28: ロジカル・シンキング & システム設計・プログラミングについて

§4. システム設計

システム制作は、具体を論理で抑え込む傾向にありますが、

ダメです。

Page 29: ロジカル・シンキング & システム設計・プログラミングについて

直観を重視したシステム設計

(webサイトを含む)システム化の失敗の典型的な例として挙げられるのが「直観的操作を無視したシステム設計」です。直観的操作は、UX/UIに限らず データ構造(情報設計)も直観的でなければなりません。直観的な設計は、人の直観的な思考パターンと一致していることが望ましく、必然的に「抽象指向」に沿うことが求められます。

過去の知識・経験

行動

直観

抽象指向思考

直近の知識経験 記憶断片

直観論理(抽象化)

システム成果

直観的

エンドユーザーの操作管理者操作

直観的

抽象化されたデータ構造

設計・制作者

Page 30: ロジカル・シンキング & システム設計・プログラミングについて

よくあるシステム設計の失敗

1つ1つのユーザー操作に対して「最適解」をロジカルに考察し、それを論理上「有機的」にシステムとして繋ぎ合わせる

といった方法で設計を行いがちですが、ほぼ必ず失敗します。

ベストな画面1

ベストな画面2

ベストな画面3

ベストな画面4

設計・制作者

「最高のシステム  ができあがった」

ユーザー

「画面ごとに仕様がバラバラで、すごく使いづらい!」

ユーザーは、無意識にシステム操作方法を頭の中で抽象化しながら使用します。同じシステムであるにもかかわらず その抽象化した経験則が画面ごとに異なる場合、「この画面ではこの操作をする」といった「論理」を強いることになり、「使いづらい」という第一印象が先行することになります。

Page 31: ロジカル・シンキング & システム設計・プログラミングについて

抽象的設計とその具体化

設計に慣れていない場合、とりあえずいったん全画面を設計してみます。

画面1 画面2 画面3 画面4

システムのポリシーを確定し、それを拡張して雛型を作成します。

ポリシー 雛型

雛型を元に各画面の設計を生成し、画面固有の項目について部分的に改変します。 画面1 画面2 画面3 画面4

設計後や運営時は、雛型からかけ離れた仕様改編を行わないことを原則とします。たとえ依頼者からの注文であっても、元の設計を大きく変えることはエンドユーザーに戸惑いを与えるだけです。

Page 32: ロジカル・シンキング & システム設計・プログラミングについて

§5. プログラミング

プログラミング言語自体が抽象をベースとしているため、開発の土壌も抽象の概念が定着していますが、その骨格になる抽象やポリシーを見失うと糞システムができあがります。

Page 33: ロジカル・シンキング & システム設計・プログラミングについて

プログラミング言語の特徴

直観的で分かりやすいプログラミング言語は、「抽象」と「具体」を組み合わせて扱えるように工夫されています。人の思考パターンと形式が一致するため「直観的」であり「ミスしづらい」(ミスを見つけやすい)わけです。

XML(データ構造)

要素の意味付けAttribute, TextNode データ付与

HTMLXML的には具体デザイン的には抽象

CSS : デザイン設定

画面

Abstract Class

implementポリシーを継承

Class

親クラスを継承「実装」

protected Class

実行

構造データの具体化

デザインの具体化

設計ポリシーの具体化

実行内容の具体化

(Java VM)

Page 34: ロジカル・シンキング & システム設計・プログラミングについて

ツール と フレームワーク

「汎用化」と「抽象化」はほぼ等価な意味合いで使用され、いずれも「同じ処理を1つにまとめ、展開可能な状態にすること」を指します。構成としては同じですが、抽象化は、テーマやポリシーを含む点で異なります。

ツールとフレームワークは、これと同じ違いであり、規模が大きいものを指します。

システムのポリシーやテーマを含んだ抽象クラス群を具体化(実装)することで、そのポリシーを引き継いだシステムが出来上がるものを「フレームワーク」と呼びます。

関数

具体的な処理として展開

手続き処理

汎用化

抽象クラス

テーマに沿って展開

クラス

ツール

具体的な処理として展開

処理

汎用化

フレームワーク

テーマに沿って展開

システム

jQueryなど AngularJS など

フレームワークを使用した実装者は、ポリシーを気にせずに(客観的に)具体化する作業を行います。ただし、そのシステム設計者は、フレームワークのポリシーがシステムに合致していることを確認しなければなりません。ツールのつもりで使用すると死を招きます。

Page 35: ロジカル・シンキング & システム設計・プログラミングについて

アジャイル開発のリスク

詳細設計を不要としながらも、開発者同士でシステムのポリシーを共有し合い、その骨格に対して肉付けしながら進める開発手法がアジャイルです。

ポリシー

抽象

抽象

抽象

抽象

直観的なシステム

ポリシー

抽象

抽象

抽象

抽象

糞システム

詳細設計が不要で気軽に開発に入れるのは利点であり、各イテレーション毎に抽象部分の使用が多少ブレても構いません。

が、ポリシーは一貫したものとして定めなければならないものの、詳細設計が存在しないため このポリシー自体がブレてしまうことが多々あります。

設計に慣れた開発者同士がポリシーを共有しあわないと糞システムができあがるので、注意が必要です。

Page 36: ロジカル・シンキング & システム設計・プログラミングについて

§6. まとめ

● ロジカル・シンキング は、具体指向の意思決定手法であり、その範囲は局所的。● 直観を排除しようとすること自体がNG。論理と直観を連携させる手段を考察すべし。● 具体指向と抽象指向とで思考系列が異なり、それらの特性を理解すべし。● ビジネス社会では、具体データをもっともらしく弄って満足する傾向がある。● 直観の利点を活かすため、抽象化の仕組みを把握するのが吉。

● システムは、ユーザーの直観的な操作を最優先すべし。● 直観性を優先したシステムは、自ずと抽象化された設計となる。● ベストな具体の集合体を目指すのではなく、抽象から展開した具体を扱うべし。

● プログラム言語は、人の思考過程と一致するように設計されている。● 品質維持と工数削減を目的に 安易にフレームワークを選択すると死を招く。● 設計の省略を目的に 安易にアジャイル開発を行うと死を招く。

Page 37: ロジカル・シンキング & システム設計・プログラミングについて

§補.

抽象指向者の扱いについて● 「納得するまで不満そうにする」「いうことをきかせるにはコツが必要」「具体的なこ

とを提示してもうまく理解しない」「たとえ話を交えるとかなり理解する」「説明が長い」「結論が分かりづらい」このような特性があるので、意識高い系の職場では扱いづらく思われがち。

● 性格の問題ではなく、扱う側の問題。● 開花が遅めで、高確率で突然すごい人になるので、良い意味で要注意。

抽象指向思考のコツ● よく分からないときは何かに例えてみる。(例:「ドラゴンボールに例えると誰?」)

齋藤について● ロジカル・シンキングは嫌いだけど使います。主に、頭にきたとき。