2018年1月25日(木)に匠道場*1に参加してきました。

今回は、師範の萩本順三さんが、第1部ではデザイン思考とシステム思考の融合、匠Methodの成り立ち、第2部は、価値起点思考を二元論で説明するというテーマでお話されました。

f:id:haru860:20180128214216p:plain

第1部は、デザイン思考とシステム思考の融合と、匠Methodの成り立ちがテーマでした。

デザイン思考とシステム思考の融合

デザイン思考とシステム思考

デザイン思考：直感的、感性的な発想を重視する思考法
- ここでの「デザイン思考」はデザインのプロセスのことではない。
- (参考)WikiPediaの定義: デザイン思考（でざいんしこう、英: Design thinking）とは、デザイナーがデザインを行う過程で用いる特有の認知的活動を指す言葉である
システム思考：論理的な構造を重視する思考法
- システム＝人間を含めたシステム。コンピュータシステムだけではない
- (参考) WikiPediaのシステム思考

意志・表現、活動

デザイン思考＝表現（右脳的なもの）
システム思考＝活動（活動に行き着くまでの論理展開：左脳的なもの）
表現と活動を行き来し、洗練させる

描く力と作る力の両立（匠Think）

片方が得意な人は片方が苦手なことが多い
両方を活かしながら、思考していくことが重要

個人的メモ

(個人的な問い)両方ができると、何がよいのか？

(個人的な回答)

以下の２つの思考を行き来することで思考が洗練される。

(感性→ロジック)直感で考えてロジックで証明する→パナソニック創業者の松下幸之助氏の考え方(直感で考え、ロジックでサポートする。そして決断する)
(ロジック→感性)ロジックで考えたことを実現したとして、人として嬉しいのか？自分たちが取り組むべきことなのか？情熱を持って取り組み続けることができるのか？を思考することができる
感性を活かすことでチームや自分の個性を活かした思考が生まれてくる(感性は人ごとに異なるので)→自然に差別化される（ロジックだけで考えるとどうしても他の人や競合と似てきてしまう)
感性だけだと実現性に乏しくなる。アイデアは良くても説得力がないので、最後の最後(稟議など)で人を動かしにくい(最初は「いいね」と言ってくれる)

匠Methodの成り立ちと誕生〜オブジェクト指向から匠Methodへ

27歳でIT業界へ

27歳でIT業界に入った
スティーブ・ジョブズが開発したNEXTSTEPを購入。その考え方に影響を受けた（最先端のオブジェクト指向）
素人の視点があったからこそ、ソフトウェア工学に疑問を持てた
- オブジェクト指向を客観的に見ることができた、本当に役に立つのか

自分の考え方を手法としてカタチにしたい

目指していたこと

複雑なものをシンプルな構造で説明する。それこそがソフトウェアエンジニアの仕事の本質である
- 複雑性をシンプルで共通的な本質として解明することができる
- 究極の本質を見抜く
人の新たな思考法を生み出す

オブジェクト指向の探求

モノに指令を出す（Smalltalk)
構造主義
- 認知の世界
- 言葉（シニフィアン：記号表現、言葉、音声） - 概念（シニフェ：記号内容、概念、イメージ）
  - 言葉が概念を指している
  - 言葉は同じだが、概念が関係者間でずれている場合がある
  - 概念は言葉で構成されている。分解していくと認知がずれていくことが分かる
  - 概念を言葉で分解していくことで詳細化、具体化に役立つ
ものごとを徹底的に探求したい→最初の頃は、目の前の仕事に必要のない余計なことまで考える、全体を理解しないと納得しない、できない社員だった
要求や価値は曖昧である。それをカタチにできると思った

常に考えていたこと

曖昧性を排除すること
- 言葉の指す概念を明確にすること。曖昧性をなくして皆で同じものを見る
本質面での抽象理解を促進すること
- 本質的な言葉を共有し詳細を排除する。ヒトは本質さえ理解すれば、詳細を知らなくても強い結束力を持てる
- オブジェクト指向設計は納得理解できた。オブジェクト指向分析は怪しいと思った
- ソフトウェア開発は見えないものだらけ（恐怖感だらけ）
  
  具体化、詳細化、構造化が見える化ではなく、抽象化・本質を捉えることが見える化である
人の心を工学として取り扱う
- 海外から入ってきたオブジェクト指向方法論は、構造化手法の焼き直しだと感じた
- 自分で方法論をつくろうとした→オブジェクト指向方法論Drop→苦しんだ(5年後にやっとかたちになった)
- システム思考に限界を感じた
  - 論理的に書けば書くほど使えないものになる→論理的美の虚像
  - プロフェッショナルの仕事で使えるものをつくりたかった
  - 感性的な発想を組み込んだ。人が感じるものや感じたことをカタチにする
正しい勘違いは大切にする
- 守破離の守を終えた後、自分のレベルではできないことを「できる」と思う勘違い
- 「できる」と正々堂々という→自分を伸ばすことにつながる
- やらないとチャンスはない→やれば経験値があがる

豆蔵設立、要求開発の方法論へ

豆蔵でビジネス戦略の見える化に取り組んだ

仮説的な戦略からIT手段へと考える→論理的美の虚像の排除につながる
- 2000年代前半当時のモデリングの流行は、動的モデル、静的モデルを分類することだった（モデリングの対象は全て手段）
- 要求開発では、以下のビューで表現した
  - ビジネス戦略
  - 業務プロセス
  - サービス(ビジネス/システムユースケース)
  - 情報(データ)
- 手段が広がらないようにアプローチした

一定の効果があったが、以下のような問題点があった。

戦略が絵に描いた餅になる（戦略の効果を考えていないため）
戦略とは何かを考えた。
- Howの勝ち組がWhatになっているだけ
- 戦略を疑わないといけない
- 「戦略と実現の線上にしか価値は存在しない」（匠Think)

個人的メモ

Howの勝ち組がWhatになる流れ
- どこかの企業で成功した事例が、戦略のベストプラクティスとして研究される
- 他の企業で、価値を考えずに戦略のベストプラクティスを真似する
- 価値や目指す方向(ビジョン)を考えずに導入したり、自分たちの文化に合わないことをしているので、価値を生み出せず失敗する

特許庁プロジェクト

総務省の技術顧問、内閣官房のGPMO補佐官時代→ Publickeyの記事
日本の大規模システムの実態を見ることになった
日本のユーザー企業はIT活用ができないと感じた
業務設計、フローチャートの大量生産
- 役人はプロジェクトだと思っていない。無責任に言い放つ
ユーザーの要求を待ち続けるIT業界(SIer)の業務慣習
手法から作ることは文化
- 文化を形成したい→匠Method
守りのスキルばかり蓄積され、日々の仕事に忙殺される

匠Methodの誕生

価値をデザインし、価値記述の要素から戦略を創り出す

価値-戦略-手段(手段にはお宝が埋まっている)
価値への着目
- 戦略を定義する前に、価値をデザインすることから始めた
- 価値を書くことは手段の証明になる
- 価値を演出する、デザインする
- 価値を描いたあとに考えた戦略は、絵に描いた餅が少なくなる(価値で検証された戦略)
- 価値とは何かを考え、匠Methodの新たなモデルとして採用した
一人の脳から出てくる感性を信じ続ける
世の中の考え方を学び、咀嚼する
→ 自分なりの考え方を組み合わせて生み出す
感性は持って生まれたセンスではなく訓練で磨けるもの

心が震える経験を積む→感性を磨いていく