書評『A Philosophy of Software Design』:古典的かつ本質的な設計論

ここ数日で読んだ下記の本。非常に感銘受けたので書評を書く

A Philosophy of Software Design

著者はスタンフォードで教えているが、元実務家らしい。大学のコースの内容を本にしたものという。研究領域は比較的低レイヤっぽい。題名は訳すと「あるソフトウェア設計の哲学」

総評

ソフトウェア設計を複雑性（complexity） を減じるためのものだ、という基本的な考えのもと、非常に実践的なアイデアが学生のよくある間違いや好ましい例とともに記述されている。UNIXの設計を良いものと主張する場合が多い。間違いの例などは自分もやっていたな、と思うものもあり、かなり考えさせられる。数年教えてきた内容を使っているので、伝え方がうまい。

基本的なアイデアは古典的なものであり、目新しいというより原点回帰の設計論。当初はビジネスアプリケーションの設計には微妙かな、と思ったが、むしろ大事と思った。

アジャイルの罪

いくつかの議論は、いわゆるあちらのアジャイルのグルたち（アンクル・ボブやケント・ベック）と違うことを主張している。例えば、Unit Testには肯定的だが、TDDは設計を疎かにする恐れあり、として否定的だ。また、「クラスは小さくすべし」というアンクル・ボブの勧めに対して、「小さく分けすぎるな」という。

何も考えずにアジャイルで機能中心にガンガン作るってのをやると良い設計にならない/技術的負債がたまるって認識がそろそろ一般化してきていると思われる。その対策としてDDDなんかが注目されているのだと思うけど、この本に書かれているような基本的な哲学を抜かしてそこに向かうとなかなか厳しいことになると思われる。

こうした短期的な機能中心のプログラミングを著者は戦術的プログラミングと呼び、より長期の良い設計を探究しながら行うプログラミングを戦略的プログラミングと呼んでいる。TDDや機能中心のアジャイルは戦術的プログラミングを助長するという。

私見としてはプラクティスの提唱者たちは本書における基本的な考え方を身につけているから害はないのだろう。

抽象化というプログラミングと設計の核心

著者はインクリメンタルな開発には賛同するけど、それは機能（feature）単位ではなく、抽象単位であるべきだという。モデル単位と言い換えてもいいと思う。

「インクリメンタルに開発する」というのは一般的にはいいアイデアだ。だが、開発の増分というのは、機能ではなく、抽象であるべきだ。もちろん、機能によって抽象が必要とされるまで考えることを延期するのはいい。だが、ひとたび、抽象が必要とされれば、適切に設計するのに時間の投資を惜しんではならない。

TDDが設計を阻害するメカニズムとして次のように述べている。

テスト駆動開発は過度にインクリメンタルだ。...抽象化が必要になったならば、その抽象をバラバラに作り出すことをしてはならない。抽象は全体を一度に設計しなければならない。（もしくは、ある程度核となる機能のまとまりを提供できるだけの大きさは必要だろう）

ある程度一般的なモジュール（somewhat general-purpose fashon）

著者がいう抽象化のための実践的な指針が「ある程度の一般化」だ。SI稼業で何らかの成功体験がある人は、顧客の要件を鵜呑みにせず、後でどうにでもなるような仕組みを提供してうまくいった経験がある人は多いだろう。これはG.M.ワインバーグが著書でも触れていたテクニックで、長い歴史がある。

ただ、この一般化をやりすぎると結局何ができるのかが分からなくなったり、複雑性が設定ファイルやテーブルのデータ内容に移動しただけ、ということになりかねない。SIのプロジェクトでもよく見る。なんでも入るテーブルみたいなやつもそれだろう。一般化のしすぎ。

著者は個別の煩雑な要件を満たし、かつ、複雑性を減じるようなバランスの取れた一般化された目的のモジュールを設計することを推奨している。著者の例はテキストエディタの編集処理の際にUIモジュールから呼ばれるメソッドだ。

個別のユーザーの操作に対応したメソッドを一つ一つ提供するのではなく、より一般的なメソッドを提供し、それをUIが使う。

個人的にはこれらの工夫はドメインモデリングにつながると感じた。ソフトウェアのUIの下の層にドメインの本質が構築される。多分、いいUIはその下の層と操作も一致するか近しくなる。

ソフトウェア設計の本質への回帰

本書はUNIXのファイルアクセスやネットワークプロトコルのソフトウェアとしての設計などが多く出てくる。

近年のDDDなんかだとともそれば、基盤的要素は軽視されがちだけど、ソフトウェアを作る上ではそれらも大切な要素の一つ。むしろ、技術的な要素は上手く設計がされている場合が多いから問題にならない、といった方がいいかもしれない。TCPを意識することが我々があまりないってのは偉大な設計の勝利なんだよな。

この本は現代のプログラマが、ソフトウェア設計の歴史的な蓄積を身につけるのに非常に優れた本だと思う。そしてそれは新しいテクニックをみにつけ、活用するための土台になる。

こういうのが大学で教えられている、というのは非常に素晴らしいことだな、と思った。

独断と偏見にもとづく政治について学ぶための推薦図書

眠れないので、ふと昔を思い出して記事を書くことにする

自分の背景

• 政治学修士。研究者の道は挫折。今はIT業界。王道の政治過程論、政治哲学、比較政治学その他のものは基本ナンセンスだと思って、地域研究を専攻してた。

• 政治的志向は、中道右派 / 平等 < 自由と公平 / 適切に管理された市場経済の信奉者/ 立憲主義万歳 / 社会権等は擁護

全く知識がない人へ

高校の教科書がおすすめ。なんだかんだ言って、日本の教科書はレベルが高い。検定教科書はアップデートもされていくのでそこも良い。

最新政治・経済　新訂版　［教番：政経313］　文部科学省検定済教科書

高校倫理　新訂版　［教番：倫理312］　文部科学省検定済教科書

俺的おすすめ

かなり変わったおすすめだと思う。

ベースの本

日本国憲法論 (法学叢書 7)

とりあえず、これを読んでおけば生きた政治のかなりの部分が学べるんじゃないかと思う。佐藤先生は政治理論とかも参照しながら統治制度なんかも解説している。抽象的な人権論とか、政治哲学なんかより、実際に生きた人間に影響を及ぼした判例って事例から学べることは多い。まあ、６００ページ以上あるので、佐藤先生の他の本でもいいかも。でも網羅しているのはこれだから。

危機の二十年――理想と現実 (岩波文庫)

政治における力と理想や規範/法の問題についての切れ味鋭い論考。国際政治の古典だけど、リアリストとユートピアンのアイデアの対立はあらゆる政治現象で見られるものと思う。

アメリカにおけるデモクラシーについて (中公クラシックス)

政治学の天才。トクヴィルが19世紀のアメリカで現実に行われている民主主義を鋭く分析した名著。やばい。。。

歴史

抽象的な政治学談義は無視して、実際に我々人間がどんな政治を行ってきたのかを知ることはとてもためになると思う。近代以降の歴史を知れば今を理解する助けになるし、古代の様々な歴史は時を超えて普遍的な原理を見出すのにいい。 個人的には

• 近現代ヨーロッパ史（どのように国民国家が生まれ、民主主義が広がって行ったのか、どのような差異が地域であったのか）

• 近代以降の世界史（ヨーロッパに世界が支配され、その支配がどのように瓦解して行ったのか。ヨーロッパにどうやって対峙して行ったのか、戦後の経済発展と民主主義の広がりと失敗）

• 幕末以降の日本史(西洋の衝撃をどのように受け入れ、近代化を成し遂げ、破滅の戦争に突き進んで行ったのか。)

あたりのテーマが今生きると思う。昔なら、ソヴィエトというものを理解しなければならなかったけど、今は、多分、開発独裁みたいな文脈で理解すればいいんじゃないかと思う。本はたくさんいいのがあると思うけど、個人的にマニアックな本をいくつか。

敗北を抱きしめて 上 増補版―第二次大戦後の日本人

アメリカ人による日本研究者の戦後史。視点が新鮮。

ゾルゲの見た日本【新装版】

ソヴィエトの対日スパイだったゾルゲの分析。戦前の日本の軍国主義化の根底にあった構造への鋭い洞察。

ヨーロッパ史については最近すごくいいシリーズが出てたね。

力の追求(上):ヨーロッパ史1815-1914 (シリーズ近現代ヨーロッパ200年史 全4巻)

フランス革命

フランス革命とナチスドイツ/ファシズムというのは、政治学における非常に重要なトピックだけどここでいくつか。

[新訳]フランス革命の省察 「保守主義の父」かく語りき

政治的洞察の天才エドモンド・バークの古典。フランス革命の徹底的な批判書。保守主義の父と言われるけど、彼はアメリカの独立には賛成した改革論者。 頑迷な保守主義者ではない。彼の論理は、フランス革命をある種の模範としたロシア革命やその他の革命がなぜ、殺戮と独裁に帰結していったかを恐ろしいほど的確に洞察している。 岩波の訳書では「バークに学ばずに政治を行うのは、海図のない航海のようなもの」という言葉が出てた気がする。

フランス革命についてはいろんな新しい歴史書があるけど、個人的にはトクヴィル先生の下記の本がお気に入り。歴史学的には多分、今では突っ込みどころ多いかも。

旧体制と大革命 (ちくま学芸文庫)

ハンナ・アレントの下記の本もどちらかというとフランス革命に批判的。

革命について (ちくま学芸文庫)

民主主義の可能性と限界

大衆心理についての警句

世論〈上〉 (岩波文庫)

民主主義のダメさ加減は、古代ギリシャやローマの歴史を学ぶといい。そして、個人的にはおすすめなのが下記。

政治学 (西洋古典叢書)

古典中の古典だけど、普通に政治学の本として読めると思っている。

法学

民主主義にはいろんな欠陥があるわけだけど、現代でうまくいっている要因のかなりの部分が立憲主義と法の支配、人権概念みたいなもののおかげと思っている。その根底には法についてのアイデアがある。下記の本も好き

法における常識 (岩波文庫)

理系っぽいやつ

組織の限界 (ちくま学芸文庫)

つきあい方の科学:バクテリアから国際関係まで (Minerva21世紀ライブラリー)

感情の役割。なぜ、これが絶版なんだ？？？

オデッセウスの鎖―適応プログラムとしての感情

Clojureをやってみた感想

この記事はClojure Advent Calendar 2019 - Qiitaの20日目の記事。 僕はClojure使いではなく、Javaメインのプログラマーですが、一昨年からclojure勉強し始めた。最近さぼってる。。。文系出身で、CSのバックグラウンドは皆無。比較的敷居が高いと思われる言語に、初心者から見た雑感を書いてみます。

興味を持ったきっかけ

• 一人でとあるアプリをLispで書いた人のことを聞いて。個人的感覚だと一人で書ききれる代物じゃなかったので、Lispってすげえんじゃないか、という気がしてた。
• 川島さんとか、アンクルボブとか、自分がすごい、と思う人がやってた。
• 関数型言語をやってみたかった。

勉強してみたこと

とりあえず、何冊か目を通した

Programming Clojure (The Pragmatic Programmers)

Living Clojure: An Introduction and Training Plan for Developers (English Edition)

The Joy of Clojure

フレームワークもいくつか触ってみた。

GitHub - duct-framework/duct: Server-side application framework for Clojure

Pedestal

開発ツールは色々試そうとしたけど、やはり、これになった。。。Emacsは何度か試したことあったけど、やはり挫折する。

cursive-ide.com

いまだと、Vs codeでもよさそう。

よかったこと

• 関数型っぽい考え方が分かった気がする。あと、抽象として扱うことを突き詰めること。
• Repl駆動を知れた。
• Rich Hickeyという天才の存在をしったこと。彼のスピーチが（多分）分かりやすくなった。
• 本やドキュメントも全体的に鋭い洞察にあふれているのでプログラマーとしてのレベルアップにつながると感じる。
• 触ってて気持ちいい。

現時点でつらいこと

• 設計の考え方があまりパターン化されていない気がする。というより、Javaのようなレイヤみたいな考えがなくても抽象度高く書けるのでそこらへんはどう書いていけばいいのか戸惑う。Javaっぽくやるのは違うと思っているので。
• 特にJavaとの接続部分で似たような機能があって、ちょっと戸惑う。DataTypeとRecordとか。先にどっち使うか決めなきゃいけない？
• 社内のツールをClojureで書いたが、やっぱメンテ辛いらしい。S式は見た目が違うので、勉強する気を失わせる可能性がある。

今後

やっぱ、不思議な魅力があるので今後も頑張って、勉強したい。多分、身に着けると、相当品質、生産性ともに高く開発できるポテンシャルがあると思う。 使わなきゃ身につかないのでツール作るとか、色々考え中。

1on１に頼らないこと

1on1 Advent Calendar 2019 - Adventarの14日目です。ちと体調崩してアップ遅くなりました。

1on1の源流

部下との1on1ミーティングの重要性、必要性を強調したアンドリュー・グローブはコンピュータシステムの発達によって、1オン1ミーティングの頻度はずっと減るだろうと言っている。

一対一 の こうした ミーティング は 果たして 必要 なの だろ う か。 絶対 に 必要 なの だ。 それでは 10 人 の 部下 が いる 場合 でも、 ５ 人 の 部下 の 場合 と 同じ だけの 頻度 で、 こうした 会合 を 持つ 必要 が ある の だろ う か。 その 必要 は ない。なんでも かん でも ミーティング を 持つ 必要 が ある の だろ う か。 そんな 必要 は ない。 という のは、 今日 の 従業員 は 10 年前 に 同じ 立場 に い た 従業員 よりは、 コンピュータ・ネットワーク を通じて、 自分 たち の 企業 の 中 で 一体 何 が 起き て いる かを たいてい の 場合 ずっと よく 承知 し て いる からで ある。

アンドリュー・S・グローブ. HIGH OUTPUT MANAGEMENT (Kindle の位置No.447-452). 日経BP. Kindle 版.

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

1on1ミーティングは時間がかかる。ミーティングを有意義なものにしようとして準備なんかをしようとするとなおさらだ。アンドリュー・グローブが本を書いた時代よりはるかにシステムが発展しているはずの現代で1on1がマネジメント手法として注目されているのは、ちょっと注意が必要だと思っている。

1on1の外のマネジメント

ツール

多くの情報は例えばツールなどでタスク管理していれば状況は把握できるし、マネジメントからのメッセージも当然多人数向けのミーティングやwikiなんかの情報共有手段でアップデートされるはず。それらが有用な情報なら多くの人はそれを採取しようとする。もし、それらが受け取られていない場合は別の問題かもしれない。

MBWA(Management By Walking Around) ウロウロすることによるマネジメント

当然、対面でのコミュニケーションは大事だ。ただ、それがフォーマルなミーティングに限定する必要もない。日々ウロウロしながら声をかけながらチームや組織の状態を把握しておく、個人の仕事の状況やどのように困っているかを把握する、雑談する、困っているときに相談されやすい状況を創ることはリアルタイムで問題を把握したり対処したりすることに役立つ。

例えば、ミスが目立ったり、成果物をつくるのが遅いメンバーがいたりしたとき、ちょっと断ってどのように行動しているのかを観察する、などをするのもいいと思う。スキルが足りないメンバーはほとんどの場合、何が足りないのか理解できないので、1on1なんかの場で、自分で課題を説明させるってのは大抵正確ではないし、そこから効果的な解決策なんて生まれないのだ。加えていうと、フィードバックが最も学習効果をあげるのは、その行動を行ったとき、すかさず行うフィードバックだ。（ここらへんは、Scrum使っているときは難しいかも。）

こうした積極的なコミュニケーションは当然、1on1ミーティングで部下から話をきく必要がある情報量を下げる。普段言えないことや潜在的な課題、マネージャーと部下との認識齟齬、訓練などに時間を割くことができる。

MBWA(Management By Walking Around) については自分はこの本で知った。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

心理的サポートと内省支援

1on1ミーティングは悩みを聞いたり、内省を促したり、といった機会を提供することもできる。また、お互いの本音をさらして打ち解ける、みたいな効用もあるのかもしれない。一方で、こうしたフォーマルな形式に依存させるのはやはりあまり得策ではなく、普段からオープンなコミュニケーションができる環境をつくる、ということが大切と思う。

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

内省にしても、プロフェッショナルの仕事は日々省察しながら実践を繰り返すものだ。日々振り返りながらやっていくもの。

省察的実践とは何か―プロフェッショナルの行為と思考

マネジメントツールの一つとしての1on1

アンドリュー・グローブの本の中には、優れた知識をもつ部下からマネージャーである著者が学ぶ時間としている例がある。彼によれば、1on1の目的は「相互に教えたり、情報交換する」ことだ。教えるというのは、上司からの教育も、部下からの他者視点からのアドバイス、高スキルを持つ部下からの上司の教育も含むのである。これは1on1の目的が成果を上げるためのマネジメントの一つだと位置づけられている、ということだと思う。

1on1の頻度もタスクの習熟度によって変える。多くの会社で1on1を一律の頻度で実施するということになってはいないだろうか。（習熟度は、例えば二年目までは月一回のような抽象的、形式的なものでない。）

形骸化を避ける

1on1はあくまでマネジメントのツールの一つであり、効果的ではあるが、それはあくまで全体のマネジメントシステムの中で機能するものだ。一方で、何をやっているのか定義が困難な「マネジメント」という仕事の中で、1on1は「やっていること」が分かりやすく、「仕事をした気」になりやすいものであると思う。1on1をやる、という発想ではなく、マネジメントに1on1を活用する、という捉え方の方が形骸化を避けられると思われる。

創造的なチームと礼儀正しくすることについて

この記事は Engineering Manager vol.2 Advent Calendar 2019 の3日目の記事です。ちょっとまとまってないですが、何かの足しになれば。

礼儀正しくすること

個人間の社会的儀礼は、一般的に文脈を異にする人同士のコミュニケーションでは重要なものだ。儀礼を尊重することでお互いが相手にとって危険ではないことを伝えることができる。

相手のスキルの低さや成果物の品質の低さを指摘することは無礼なことと感じる人が多い。これはマウンティングと一緒で、「お前は弱く、無能で、自分の言うことを聞かなければならない」というメッセージを受け取ってしまっているからだろう。人は多分、本能的に自分を支配しようとする人、支配できる人には脅威を感じる。

マウンティングメッセージは送り手が意図的に込めることもあるし、防衛のため、無意識に込めることもある。 また、メッセージの送り手がマウンティングを意図していなくても、受けて側が勝手にそう受け取ることもある。だから、礼儀正しく、相手を批判しないことは安全なコミュニケーションになる。

また、礼儀正しさは、他人の想定外の行動や期待と大きく外れた行動や反応をしない、ってことでもある。自分は研修の仕事をしているけど、例えば、講師が丁寧に説明しているのに、話を聞かずに別のことをしていたり、演習中に泣き出してしまったりするのは「礼儀正しくない」。

礼儀正しくすることのリスク

礼儀正しさは、社会的期待に合致した行動をとること、もしくは、そうできる能力を示すことで「安全に、不安なく」コミュニケーションをとる方法であるといえると思う。ただ、それは多くの場合、本当に起きている生の出来事を多少歪ませることで達成していることが多い。初めて取り引きする取引先にも「お世話になっております」と必ずつけるメールのマナーなんかは、その典型。

こうした礼儀正しさは、切迫した、創造的な思考や行動を阻害する可能性がある。現実と乖離したコミュニケーションが増えると、複雑な場では人々は現実をコントロールする力を失う。上位マネージャは儀礼的なコミュニケーションからは全く現実が把握できなくなり、何が起こっているか分からなくなる。

マイケル・チェーホフという演技教師のメソッドを学んだとき、ファシリテーターだった方はワークショップの場で愛想笑いや、儀礼的なハグのようなものを徹底して排除していた。参加者たちは非常に集中して、今場に起きていることや自分自身に起きていることに自覚的になり、学び易い環境になったと思う。

チーム内コミュニケーションの心理面の不安などに対処するために、礼儀正しさを強調すると欺瞞が増える可能性があるのだ。もちろん、例えばサッカー選手が年上の選手のことを「~君」と呼ぶように、特殊な礼儀を導入することでそれに対処する方法もあるだろう。

起きている現実に対処すること

レビューなどを含むチーム間のコミュニケーションで問題が起きているのであれば、それを礼儀正しさを強調することで対処して現実を隠すのではなく、現実に起きている事象に試行錯誤しながら取り組んでいった方が益が多いと感じる。

例えば、レビューなどの場でチームで期待された水準に達していない成果物であることが判明したときに、レビューイが「傷ついた」場合、いくつもの対処しなければならない事象がある。レビュー以前にスキル不足やリソース不足が判明しなかったのはなぜか、判明しても対処できなかったのはなぜか、そのほか、レビューの結果を個人的に受け止める必要はない、ということやプロとして仕事の評価を受けることは当然である、という認識の不足。チームとしての結果にフォーカスできていない環境などなど。

高スキル者が強い言葉で相手を批判する場合なども、何が起きているか、どうしてそのような行動パターンをとるのか、を理解すれば大抵の場合対処は可能だし、対処方法が分からなかったとしても、現実の問題を高スキル者と共有すれば改善してもらえるものだ。単に言葉の選び方を知らなかったり、問題を認知できていなかったりするだけの場合も多い。

例えば先に挙げた、講義を聞かない受講者の場合、かなりの確率で話についていけず、理解できていないことが原因だ。自分としては、話を聞かなくてもいいから、相当初期の内容を復習するように指示することが多い。（わが身を反省しつつ。。。）ここで、分からなくても聞け、というのは学校の教師がよくやることだが、学習に何のメリットもない。

礼儀正しさを強調して、表面上の心理的安全性を達成しても、「見えないルール」や「欺瞞的なコミュニケーション」が増えればチームの能力に悪影響を与えるリスクがある。

儀礼はコミュニケーションを密にできない人々や複雑性に対処する必要のない場合には有効だ。店頭での商品の売買などは儀礼を適切に使えるシーンだ。ソフトウェア開発はその真逆の状況だと思う。

ちなみに、原因を理解しようとして分からない場合は、分からない、ということを認めてパッチワークをすればいい。原因は大抵複合的だから、対処法はやってみないと分からないことも多い。問題の定義をすることの方が何倍も重要だ。

ヴィゴツキーにおける科学概念と生活概念の発達の違いとその意義

先日、この本を読んだ

「発達の最近接領域」の理論―教授・学習過程における子どもの発達

第6章の「生活的概念と科学的概念の発達」についてメモ。

ヴィゴツキーによれば、学校で教えられるような科学的概念の発達と生活概念の発達は、相互に関連しつつも別の経路をたどるという。

その中で、彼は、「であるから」のような言葉を歴史学習の問いかけでは正しく答えられるのに、現実の生活の例だと正答率が落ちるような例をあげている。

彼によれば、無自覚に習得した生活概念が強いところでは、自覚的な科学概念が弱く現れる傾向にある、という。

研修をやっていると、こういうのは至る所で見る。机上の空論と呼ばれるやつだ。学習の文脈の中では言葉上で理解しているのだけど、現実に当てはめることができない。新しく学んだことを利用するのではなく、古い慣習的なものの見方をつい、適用してします。

つまり、生活概念が邪魔しているのだ。ヴィゴツキーは、第二外国語を学ぶ時にもこれと同様なことが起こっているという。

さらに、科学的概念を生活の文脈の中で適用できるようになるには、その概念の内在的な成長、そして、教師などによる支援が必要になってくる。

ここまでの議論で自分が受けた示唆は以下の点だ。

一つは、学んだことが現実に適用できず、言葉だけのものであったとしても、それは科学概念の萌芽なのであって、無意味ではない。それどころか、実践的に学んだことを適用するために不可欠である、ということ。

２つ目は、生活概念が邪魔をする、ということを教師も理解しつつ、辛抱強く新しく学んだ科学概念がその生徒の内面で発達してくることを待ちつつ支援する、ということが重要だということ。

創造指向と問題解決指向の違いについて

ロバート・フリッツがよく言っていることだが、

創造（Creation）と問題解決（Problem Solving）は全く違う。

なぜ、それが強調されなければならないのか、というと両者は表面的には似ているから。

ロバート・フリッツが定式化したシンプルな創造プロセスは下記のようなものだ

www.soljapan.org

望む結果があり、現在存在している現実がある。その差異がエネルギーを生み出す。

一方で、G.M.ワインバーグの定式化した問題の定義は下記のようなものだ。

望まれている状態と現在の認識の差異

参照

ライト、ついてますか―問題発見の人間学

コンサルティングやシステム開発のビジネス要件定義などで行うGap分析もこれだ。

果たして両者に違いはあるのだろうか。文章だけ読んでいただけでは、その違いは明確ではない、自分もよく分からなかったし、その違いは重要ではないと思っていた。。

だが、最近これを区別することはかなり実践的なインパクトがある、と考え直すようになった。

指向（orientation）の違い

今のところの自分の理解では、創造（Creation）と問題解決（Problem Solving）の違いは、その出発点と方向。英語のOrientationの違いにあると考えている。

問題解決（Problem Solving）は現状の不満、不足、マイナスから始まる。現状の評価から出発する。現状から離れることが目的。成果はそれほど重要ではない。多くの場合、抽象的な「完璧モデル」や漠然としたイメージから「望んだ状態」を定義する。

創造（Creation）は出発点において現状を評価しない。ニュートラルにみる。創り出したい状態から現状を見てその違いを識別するだけ。その差異の認識がエネルギーを生み出し、創り出すことを後押しする。

問題解決（Problem Solving）は現状から離れることに主眼があるため、対策が効果を持ち出すとどうしても望んだ成果へ向かうエネルギーが失われていく。そのため、ある程度の対策をすると問題が解消され、次に問題が再発生するまで放置されることになる。問題発生→解決→放置→発生→解決のサイクルを繰り返す。

創造（Creation）はその成果が実現されるまでエネルギーが失われることはない。また、その成果が得られてから失われることはない。新しい創造の土台になる。

創造指向（Creative Orientation）の肝は、最初に現状を抽象的な評価基準を持ち込んで、評価することをやめることだ。ビジョンを定義し、そこからの差異としてのみ現実を評価する。

ワインバーグの問題定義は、おそらく、問題解決指向（Problem Solving Orientation）から創造指向（Creative Orientation）への変換、どこへ行きたいのか、という問いを根本的に問い直すきっかけを確かに与えてくれるだろう。ただ、ビジョンもなく、現状の分析から始めるだけでは、「望まれた状態」はでっち上げられたものになる。

創造指向（Creative Orientation）において、現実はただそこにあるだけなのだ。画家がキャンパスを前にしたら、それに絵を描いていくだけ。キャンパスの材質が悪い、とか、小さいとか、キャンパスを修理し出しても絵は完成しない。

そして、創造は常に、選択でもある。やってもいいし、やらなくてもいいことなのだ。

不満のない状態から目指すものを見つける、というのはある種のスキルだ。そこに理由は不要。カレーが好きとか、野球がしたい、とかそういう純粋な動機。多くの大人はこれを失っている。