うさみみが2016年に読んだオススメ書籍と振り返り

仕事

社内他チームをマネジメントしたり、Breaking Scrumしたりと挑戦しました。たのしかったです。 セミナーや新卒研修などにも携わり。ヴァル研究所様とお仕事できたのは素晴しい経験になりました。 また、 enPiT という文科省と各大学の連携でやっている「（僕から見ると）イケてるITエンジニアの卵つくろうぜプロジェクト」に関わらせていただきました。大学院生の教育に関われる日が来てよかった。これからも積極的にかかわりたいです。 株式会社オンザロードというか、僕へのお仕事の依頼はいつでもWelcomeなので kyon.mm あっとまーく gmail.com まで。

講演

1月に「15分単位でメトリクスとってるスクラムチームあるんだけど、質問ある？」っていう発表をしてから、ちょこちょこ発表をしました。

• 2016/1 Regional Scrum Gathering Tokyo 2016 Scrum,Test,Metrics #sgt2016
• 2016/3 九州ソフトウェアテスト勉強会 Startup.Retrospective
• 2016/4 NL名古屋 NAGOYA SCRUM LEARNING #nlnagoya // Speaker Deck
• 2016/5 アジャイルジャパン 2016 まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ AgileJapan2016
• 2016/9 Hacker Tackle 2016 アジャイル開発のテスト -自動化でしょうか。いいえ、戦略勝ちです。- // Speaker Deck
• 2016/10 Scrum現場ガイド MeetUp スクラム現場ガイド第1部で大切だと思うこと #nagoya_scrum // Speaker Deck
• 2016/11 JJUG CCC 2016 Fall Featherweight JavaやGroovyの漸進的型付けについて
• 2016/12 Nagoya.Testing in Tokyo アジャイルテスティング -バグ埋め込みを年間1件にまで減らした戦略- #NagoyaTesting // Speaker Deck

(意外と発表してた)

セミナー

3ヶ月に1度くらいのペースで、Git Boot Camp Premiumというセミナーを翔泳社で開催しています。ちなみにオンサイトでも開催できるのでいつでも依頼してください。(他のものでも) 2017年からはもっと他のセミナーも増やそうかと計画中です。

私生活

幸せでした。家族に感謝ですね。

その他いろんなこと

すみませんでしたああああああ＞＜

2017年にやりたいこと

1. きょんくんがいないチームにBreaking Scrumを導入したい。（きょんくん流 Breaking Scrumの導入事例になってみたいチーム募集しています）
2. F# かOCamlかGroovyで仕事したいので、仕事ください。
3. 形式手法導入したい。

読んだオススメなやつ

ここから下は基本的にどれも素敵な書籍なんですが、そこから更に好きなやつを選ぶなら、

• Joy, Inc
• SOFT SKILLS
• なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践
• グッド・マス ギークのための数・論理・計算機科学

ですね。まぁ、好みも問題かも。

IT系にいるならよんでほしいやつ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

組織とかチーム

ジョイ・インク 役職も部署もない全員主役のマネジメント

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

カンバン仕事術

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

チームワークの心理学: エビデンスに基づいた実践へのヒント

自衛隊メンタル教官が教える 心の疲れをとる技術 (朝日新書)

数学的な

圏論の歩き方

グッド・マス ギークのための数・論理・計算機科学

記号論理学: 一般化と記号化

アルゴリズムとかデータ構造とか

Purely Functional Data Structures

教育

幼児教育の経済学

「学力」の経済学

ネットワーク

擬人化でまなぼ! ネットワークのしくみ

さいごに

みなさまありがとうございました。ほんとうに。来年はもっとブログ書きます。

Gitを5年間教える側にまわって気付いたこと

Git Advent Calendar 2016 - Qiita の記事になります。 本記事では自分がGitを教えたことで気付いたことをまとめます。 ゆえに「Gitに入門したい人」に向けたものではありません。が、多少のエントリーポイントは示しますので参考になるかとは思います。 コミュニティ、有償セミナーで5年間Gitを中心としたバージョン管理システムを教えてきた経験の話です。 ただ、Git, GitHubなどのデベロッパーではないので、彼等の思想とは異なるかもしれませんが、そこは一人のGitの講師として見てもらえれば。

命名の混乱とユーザー層

Gitのコマンドは名前から理解しにくいことで有名です。 git rebase --intractive などは典型です。 例えば、branch という単語が示す内容はあまりにも違っています。 VCS毎に branch の意味が違うことも難しくしていますが、加えてGitの場合には branch (枝)というメタファーと実態の乖離が大きく、理解するまで時間がかかったという人もいるようです。 (ちなみにMercurialでは同等機能は bookmark となっており、Mercurialはbranch(枝)とbookmark(しおり)の両方で管理することができます)

そして、ユーザー層?スキーム?が様々であるため、GUIツールではあまり対応がとれないような言葉になっていることもあります。 GUIツールで困ったときに違う単語で調べる必要があり、加えてGitのコアユーザーはコマンドラインで使うため、GUIツールのトラブルシューティング情報は少なめになっています。 もちろんこれらを乗り越える人もいますが、自分の経験ではあまりいませんでした。 乗り越えないままに使うことはできるけど。。。という感じでしょうか。 ので、トラブルが起きたときにはGitで解決をせずに別の方法(ファイルのバックアップをどこかからもってきたり、新しくリポジトリをcloneしなおしてから、コピペしたりすること)で解決している人もたくさんいます。 別にそれ自体は悪くないですが、Gitの学習という意味では大きな壁になっています。

そういった意味で、自分が大切にしているのは Git公式の Pro Git というページです。 Git - Book

このページを読んで理解できるのであれば、それなりにプログラミングや、VCSに精通しているとおもいます。 ですが、なんとなくで使える程度の人や、パパっとワークフローがわかればいい人にはちんぷんかんぷんなページだと思います。 ここにある概念を大切にしながらGitを使う開発プロセスのトレードオフを伝えることが大切だと思っています。

Gitの概念を日本語でうまく表現している書籍は次の2冊だと思います。出版時期は少々古いのですが、あまり古びた内容でもありません。

入門Git

実用Git

バージョン管理、統合の戦略が広まっていない

Gitを教えていていつもぶつかるのは、そもそもSCM(Software Configuration Management)の戦略が知識としてもあまり広まっていないということです。 GitはSCMを支える重要な要素ですし、様々な戦略を取れるようにGit自身は多数の機能を提供しています。 この何年かで、「ローカルでGitを使うときの作法」「Pull Requestによるレビュープロセスの確立」「Infrastructure as a Code」といった知見は広まってきましたが、バージョン管理を活用したチームやプロダクトのプロセス品質を上げるという方向についての議論はあまりされていません。 というよりは、ずっと課題だと思う(ソフトウェア構成管理という単語がずっと使われている事情からそう思う)わけですが、流れとしては「SCMの戦略」よりも「SCMを中心として少しでもよくなってきている開発の改善力を中心にもっと範囲を広げよう」という感じだと見ています。 大切だと思いますし、そうすることで無駄が減る(部分最適をする前に全体を見ることが出来ることによって余計なことをしないで済む)こともあります。 ですが、Gitを活用したSCMの戦略が貧困なままでは、ビジネスのボトルネックになるばかりです。

一例としては、 Jenkins + GitによるIntegrated Workflow + Gateway CheckInを実践することができます。

JenkinsとGitで実装するGatewayCheckIn Pattern #AsianAA from kyon mm

www.slideshare.net

また、SCMという広い意味では次も参考になります。

qiita.com

「何を編集しやすく、何を実行しやすく、何を統合しやすく、何をレビューしやすく、何を組合せやすく、何をスケールアウトしやすく」それぞれのトレードオフや理想を達成するためにGitを利用することは多くの場面で大切です。

ただ、そういったSCMの戦略がわかっていない、関心がない人もたくさんいますし、必要ではない人もいます。 (もちろんわかっている人もたくさんいますが、割合の話ですね)

まとめ

• Gitの概念、コマンドを覚えるのは苦労しやすいポイントであり、反復練習か、Gitを使わないという選択肢を見つける必要がありそう。そして、それに耐えられない人がGitをなかなか使い始められなかったり、Git使っています() みたいな状態になってしまっている。
• Gitを使うことで、どのような理想的な開発プロセスにしたいのか。というSCMの戦略に関心がない人や、そもそも知識が共有されていない現状があることを踏まえて、Gitの使い方を教える必要がある。

自分の教えかたを2,3年毎に大きく変化させることでいくつか気付きがありましたが、大きいこの2つについて紹介しました。 では、これらをどうするのか? という話ですが、前者は Gitカルタ という形でコマンドをさわらずにGitの操作をイメージで掴めるようなゲームとして教えています。

codezine.jp

後者については、事例をはさみながら教えていますが、いまのところGit Boot Camp Premiumというセミナーでは最初のほうだけを教えるに留まっています。 ので、更に拡充して2017年はコミュニティ、有償セミナーを開催しようと思います。おそらく別枠で開催する感じがいいかなぁと。

おまけ

弊社、基盤チームではGitからの脱却を目指して新しいVCSの設計を始めています。いつ完成するのかはわかりません。いろいろ不満なのでね。。。

組織（チーム）を成長させるための参考書籍

概要

マネジメントやプロセスの方法論自体をどのように適用、変化させるのか。 というのは、方法論自体を知る必要があるのはもちろんのこと、どんな組織にしたくて、どうすれば成立できるのかということを考える必要があります。 それらを引っ張るものが、理想や価値観であり、それらを明確につくる能力も大切です。

というのをあるTweetの具体例から入って話しているうちに、参考書籍を紹介しておこうという流れになりました。 ので、ある程度抽象的なやり方っていうんですかね。組織に変化をもたらす方法っていう感じですかね。

Twitterの流れ

togetter.com

参考書籍

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書)

エクストリームプログラミング

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

IMPACT MAPPING インパクトのあるソフトウェアを作る

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

蛇足 : 方法の反対は目的ではない

最近勉強していて当たり前？のことを知ったのですが、方法の反対を意味する語は目的ではないという。 目的のために方法があるだけであって、反対という意味ではないというか。 ロランバルトという思想家？の著書をいくつか読んでいるのですが、彼の考え方は非常に刺激的ですので、興味がある方は読んでみてはどうでしょうか。 （ちなみにこのような解釈における方法の反対は教養になります。方法は目的を価値とするけど、教養は縛られるものがないという意味）

というのをこういった方法論とか組織論とか価値とかビジョンを勉強して、自分で考えているときにそういったことを考えていないとまさしく無縄自縛っていう感じになってしまってよくないなぁと。 っていうのを考えるためには哲学とか言語の勉強が役に立っています！

Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt

3行まとめ

• Hacker Tackleっていう激熱なITデベロッパー向けのイベントで「アジャイルテスト」について講演しました。
• みなさんがつらいのはわかるけど、解決したいなら本気で取り組む必要があるので、参考になれば幸いです。
• あと、アジャイルにテストしている人達といろいろ議論したいです。

Hacker Tackleとはなにか

hackertackle.github.io

HackerTackleは、プログラマのための総合技術イベントです。 「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。 イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。 ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか？

なんかMMA感がありますが、まさしく登壇者の多様性と豪華さはすごかったです。 主催者と登壇者のみなさまほんとうにありがとうございました。 僕はホクホクして帰りました。

名前の由来はハッカータックル、ハカタクル、博多来る というかんじです。 今年で2回目ということでして、昨年に引き続き参加させてもらいました。

どんな講演をしたのか

speakerdeck.com

50分間の講演だったので、30分はスライドの内容をかいつまんではなし、20分は会場と意見交換をしました。

スライドでは次の3つのアンチパターンを紹介しました。

1. 過剰自動化
2. モック酔い
3. TDD不要論

で、時間の都合上2番目のモック酔いは軽くだけふれて、1と3を中心的に話しました。 これら3つはまぁ私のまわりではよくあったので、その状況における原因とか自分なりの対策をまとめました。

ちなみに1の話ではかの「自動化ハイ」についても口頭で言及しました。 @関西のテスト自動化コミュニティ

また、アンチパターンだけはなしても「こいつうさんくさい」とおもわれるかなぁとおもったので、 一部ではありますが、自分達のチームがどのようにテストにとりくんでいるかも紹介しました。

いまは少しずつですが、手動テストもテスティングフレームワークで書くような下地をつくりはじめているところ。ってかんじですかね。

会場との意見交換では、いろんな質問がでておもしろかったです。 きょんくんの現場ではこういったことは困っていないのか？といったものから、参加者さまの現場で困っていることについての方針相談などなど。

まとめ

アジャイルって「素早く順応する」ってことが大切だとおもうので、みなさんも自身含めてどんどん変化していくとよいのでは！！！とおもっています。

改めてになりますが、Hacker Tackleの運営のみなさまによって素晴しい会になったとおもいます。本当にありがとうございました。 また、来年も参加させてもらえると非常にうれしいです。

Specification by Example: How Successful Teams Deliver the Right Software

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

「アジャイルコーチの道具箱 - #見える化実例集 -」を読みました。 by mari

kyon_mmさんの友人のmariです。今回はkyon_mmさんのブログを借りて、「アジャイルコーチの道具箱 -見える化実例集-」の書評を書かせていただきました。

本書はすごく楽しんで読めた一冊でした。著者、翻訳者のみなさまありがとうございます！

leanpub.com

付箋愛

まず感じたのは、「溢れんばかりの付箋愛！」です。 私も会社でガンガン使っています。 すぐかけて、貼りたいところに貼れて、 誰かに渡すことも簡単で、すぐ共有できる！

付箋がもたらす情報共有力、見える化力ってすごいですよね。 私も好きです、付箋。

肝心の本書の内容について。

基本的に説明が書いていないので、好き嫌いは分かれる本なのかもしれないなぁと思います。 どういう理由でそれをやるのか、を誰かに教えてほしい人には読みづらく感じそうです。 説明がないと物足りない！って人は、別の本を読んだ方がいいと思います。 私はどちらかというと感覚でものをとらえるタイプなので、 非常に好きなタイプの本でした。

Exampleが基本1頁に1つの構成になっていて非常に読みやすいです。 読むというより、観るって感じが近いかもしれません。 長い文章が一切なく、半分以上が図となっており、感覚的に脳に入ってきます。 本書で取り扱うExampleの中にも、図や表を利用するExampleが多く出てきますが、 それらの効果を本書をもって証明しているように思います。 すぐにできそうなシンプルなExampleばかりで、すぐにでもTryできそうです。

見えるようになるとそもそも何が嬉しいのか。

1. 気づかなかったことに気づくようになり、今まで考えなかったことを考えるようになる。
2. コミュニケーションが増える。
3. 知らなかったことを知ることができる。
4. 成長できる。
5. 楽しいと思える機会が増える(ここは人によりそうですね。)

楽しんでチームと仕事をする、という部分に特化しすぎているように思える部分もありますが、 「楽しむ→やる気がでる→効率よく仕事ができる」 とつながっていくので、仕事をするうえで楽しむって必要なことなんじゃないかな、と自分は思います。 「仕事に楽しさは求めていない」という人もいますが、 私は楽しむことで、自分の人生が金銭的にもメンタル的にも豊かになると信じています。 本書には、楽しんで仕事をする、チームうまくやる、ための工夫がたくさん詰まっています。

下記に、特に自分の心に響いた部分をいくつか引用し、レビューの締めとします。

シンプルに。

更新されなくなると信用されなくなり、どんどん使われなくなっていく。

どんな情報もツールも同じだし、よくあることだと思います。 メンテナンスされない膨大な利用ガイドや、設計書を含め、 身に覚えがある人も多いのではないでしょうか。 始めは凝ったつくりにするものの、結果として自己満足になっていて、 他の人からすると、情報や装飾が多すぎて使いつらいとか、読みづらいとか、 そういう使えないものになり、更新されなくなっていく。 作った人は、せっかく作ったのに、とイライラし、結果としてチームの雰囲気が悪くなる。

私は身に覚えがありすぎて、「本当それ！」と叫びそうになりました。 言うのは簡単ですが、実行するのは難しい。 「シンプルに」考える、「シンプルな」ものをつくる、 このあたりの考え方は、人生をより楽しく生きるためにも必要な要素だと思います。

自信のニコニコマーク！

これならひとりひとりの感覚が可視化できるし、 毎日、進捗や達成可能か？と考えることができます。 そして達成できるためにできることはないだろうか、と考えるきっかけとなると思います。 なんとなくバーンダウンを見て、「はい、見た！終わり。」ってなっているチームや、 そもそもバーンダウンなんて見てません！ってチームに取り入れると意識が変わりそうですね。

情けない話、自分のチームではそういうことがありました。 こういう工夫をしていたら、もっとよいチームになれたような気がします。

評価しよう。改善、調整をしよう。必要ないなら、使うのをやめよう。

やめ際がわからなくて、ずるずると必要のないことをやってしまったり、 引き際がわからなくて、余計なことを言ってしまったり… たくさん思い当たるふしがあります。 ずっとやってるからといって、必要かどうかを考えずにやり続けている レガシー的な何かとか。 常に物事は変わっていくのだから、常に評価して 必要がないのであればやめるというのはよく考えたら当然のことですね。 全然できていないけど、それは頭を使っていないってことなんだなぁと思いました。

テスト(コード)レビューの方針 書きなぐり版

牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。

元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs

僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日

牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」

僕のコメント「書いていません！」

僕のコメント「書きました！」

パターンに関する質問と、パターンとはアートなのかデザインなのか考えてみた

最近、 TwitterとかFacebook で @ryuzee さんとか @katzchang さんが「スクラムにおけるImpediments Listはどう扱うのか」みたいなやりとりがありました。 そのやりとりの途中で @jcoplien さんが日本で開催した組織パターンに関する講演の話がでてきました。それは @m_seki さんのブログにレポートがあって先ほど読みました。http://d.hatena.ne.jp/m_seki/20131110#1384094601

で、これらを読んで思ったことを書きながら、TODOってなっていることを @ryuzee さん、 @katzchang さん、 @m_seki さん、 @kawaguti さん、 @jcoplien さん、 @haradakiro さん @digitalsoul0124 さんあたりに質問してみたいなぁと思っています。

ちなみに話題にあがっていた Impediments Listは僕は扱いやすいように管理しておけばListでもバックログでもKPTでもなんでもOKで、いつ解決しないとやばい問題であるかが最初に考えることですかね。出てきた問題によって置き場が変わります。

パターン

パターンが何であるかのより具体的な説明として @jcoplien さんが説明した様子を @m_seki さんは次のように書いてくれていて、「パターンは複数の問題に対して使える」という理解は僕もなんとなくしています。

研修のテキストに「1つのパターンが、いちどに解決する問題は一つだけ」という誤訳があり「一度に一つずつ適用する」が正しかったのですが、これを起点に「一つのパターンが複数の問題を解決するよ、それは…」といった具合にコプリエンが暴走してくれました。

彼の話を全部受け止められた自信はないのですが、がんばって説明します。

まずたくさんのいろいろな向きのフォースが存在する空間があるモデルを考えます。

# ホワイトボード全体にいろんな向きの矢印（フォース）を描いてくれました。だれかホワイトボードの写真残ってない？

つぎにいくつかの矢印を「対象の問題」として選び囲み「それらを解決する、調和させるのがパターンだ！一度に複数の問題が解決されるんだよ！」っぽいことを話してました。

うぉー。なにを問題と思うかも自分たちに任されてる！パターンはきれいに並んでるわけじゃなく重なり合ってる！この説明はいいなあ … あ、あれ？

今思うと変だな。あのときは腑に落ちたんだけど…。これってパターンじゃなくてコンテキストとフォース、解決策ですよね。それのカタログがパターンなんだろうか…。

問題すら自分たちで選べるっていうのは自分たちのチームの雰囲気と合ってていいなあと思いました。でもカタログの方はあんまりぐっとこないんですよね…

@m_seki さんの気持ちと一緒かどうかはわからないけれど、パターンのカタログがわくわくしないみたいなのは僕も組織パターンというか、PLoPのなにかを読んでいても同じ気持ちになります。（ちなみに僕はパターン言語好きです） 僕がよく説明するのは「パターンとパターン言語の関係は、業界と業界用語の会話のような関係で、業界用語リストを見てもわくわくしないけど、どの用語を組み合わせるのか、新しい用語を発見するときはちょっと楽しい」みたいな感じです。パターンとイディオムは区別すべきなのですけど、ここでは関係を表現する比喩として使いました。 TODO この認識であっているか聞いてみる

文中にある1度に1つのパターンを適用しなさいは組織パターンというパターン言語（6.2 漸進的成長を主眼にして話した内容）だったからだと思う。どっちにしても1つのパターンが複数の問題の解決に役立つというか、どの問題に使うかは自由で、それは自分がどんな文章組み立てるかは自由なのと似ていると思う。 カタログとしてのパターンやパターン言語は僕の中では、辞書とか文例集とかが近いです。でも、組織パターンやいくつかのパターンに関する名著からも伺えるようにそれはなんらかのストーリーであるべきだし、うまく書かれているものは読んでいて感情移入できるくらいに読めるものもありました。例えば、僕は Fearless Change というパターンの書籍ではいくつかのパターンは読んでいて興奮しました。

でも、どんなに瑞々しい文章でも、自分たちが体験してことばにならないものを触り続けている瞬間の感覚とはかけ離れてしまうなぁと思います。恋愛小説を読んでいる時と自分の恋愛の違いみたいに感じます。恋愛しなくなったり、まともな恋愛をできていないと、恋愛小説を読んで羨ましくなることはあると思います。パターンと毎日楽しく触れ合っている人には、カタログになったパターンはきっとつまらなくうつってしまうときがあるし、そうではないときもある。くらいの印象です。

日本語でも「つまらない」と表現することはいろんな事象に当てはめられるし、「旅行で休む」という行為においてもいろんな問題（仕事で忙しい、家事が大変、日本のキッチリさが鬱陶しい）を解決することもできます。 でも、その1フレーズだけでその人の状況が表現できないので、パターンというのは言語の1部であり、全体性が重要であり、パターンを見出すというのはある種の言い回しと状況を具体的にするという行為なのかなぁと思いました。 TODO もう少し具体的にしたいけどよくわからないので、聞いてみる

パターンはデザインかアートか

最近「芸術とは何か」みたいなのを勉強しているので、パターンはデザインなのかアートなのか考えてみました。（芸術という言葉が面倒（歴史的経緯が面倒）なので、とりあえずアートという言葉で言います。

パターンをみつけたり組み合わせたり、明確にしていくという過程は「デザイン」なのか「アート」なのか。 現代的？に捉えると、アートであるならば問い、未来、可能性の性質が強くなりますし、デザインならば答え、過去の性質が強くなると思います。（僕はデザインとアートの違いをそう捉えている） そうではなく、本来的な意味を考えると、アートは問いと答えを連続させていく行為であり、その蓄積物のスナップショットが文化であるがゆえに、文化とは迷いの象徴であるというようにも捉えることができます。

パターン、パターン言語に触れているその瞬間は「問いと答えを連続させていく行為」としてのアートに近い存在、もしくは「アートとデザインの両方を持っている」と思います。 また、先にあげた業界用語のように比喩に上げたものでさえも同じように言えると思います。日本人が時折バラエティなどで「あぁ、この漢字、熟語の成り立ちはこうだったのか」と感心するのはまさにそういった例なのではないかと思うのです。

デザインの性質が近いパターンとはおそらく本来的な意味のパターンを表現していないのだと僕は思います。 問いや意思や可能性を広く深くしようとするという思いが感じられるから、複数の問題を解決するために使えるパターンになるのではないでしょうか。 TODO 全体的におかしいところがないか聞いてみる

次回

「UXを重視したいという風潮が、建築、都市計画、ITの業界で起きているのは、アートとデザインが再び統合されようとしているのではないか。もしくは似非アーティスト、似非デザイナーをあぶりだす時代の到来か」みたいな話を書きたいと思っています。（予定は未定

組織パターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系