Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

年末にちょうどいい「やり抜く人の9つの習慣」と「やる気が上がる8つのスイッチ」

TL;DR

  • 「やり抜く人の9つの習慣 コロンビア大学の成功の科学」を読んで、目標設定を冷静に振り返ると、継続性のある目標になりそう
  • 「やる気が上がる8つのスイッチ」を読むと、自分自身のやる気のタイプや他の人のやる気のタイプを冷静に分析することができそう
  • 「やり抜く人の9つの習慣 コロンビア大学の成功の科学」・「やる気が上がる8つのスイッチ」と2冊で、1時間足らずで読める

読むきっかけ

風呂で YouTube をダラダラと眺めていた際に、ふと目に入ったメンタリスト Daigo の 「12/31に読むと人生変わる本【1時間で読める】1」という動画をさくっと見た。

1時間かからずに読めそうという点で読んでみたのがこちらの二冊でした。

この2冊が紹介されているのは、目標達成のために継続する方法・やる気を出すきっかけを得る方法を、セットで得るため、と動画内では紹介されていました。

が、実際に自分が興味を持ったのは、次の2点においてでした。

  1. やる気から見た8つのタイプ
  2. 自身の目標設定の再評価

1. やる気から見た8つのタイプ

「ハイディ・グラント・ハルバーソン の やる気が上がる8つのスイッチ」で説明されている、やる気から見た8つのタイプでした。目の前にいる人がどういうモチベーションで日々取り組んでいて、何に喜びを感じるのか?という点について考えることが多いのですが、その考えるフレームとしてこのタイプは非常に良い枠組みになりそうです。

2. 自身の目標設定の再評価

また、「2020年を実践知識をより多く獲得し体系化する一年へ」にて行った、自身の2020年の目標設定が、これらの心理学的な観点において、有効たりうるかを再評価したいという思惑があります。

2020年抱負 実践知識をより多く獲得し体系化する一年へ - Software engineering from east direction

この2つの観点でこの書籍を振り返ります。

1冊目「やり抜く人の9つの習慣 コロンビア大学の成功の科学」

「ハイディ・グラント・ハルバーソン の やり抜く人の9つの習慣 コロンビア大学の成功の科学 [^2]」には、目標の設定の具体性などさまざま継続してやり続けるための方法が書いてありますが、一部「なるほど」と思った点だけ。

if-thenプランニング

目標達成のためにやるべき行動を明確にするための一つのアイデアです。日々追われていると、やるべきことが多すぎて、何から手を付けていいかわからない、そのようなときがあります。このような自体に対処するために、心理学で効果実証された方法が、if-thenプランニングと呼ばれる方法です。

つまり、(if)もし、Xだったら、(then)Yをするという形式で習慣づけたい行動を明文化するアイデアです。

例えば、「もし、午後6時になったら、会社のジムで汗を流す」といった風に。この方法が習慣化しやすい理由として、脳の構造上、「XならY」という文章を記憶しやすい特徴があると本書では説明しています。

私自身、この書籍をうけて、「2020年を実践知識をより多く獲得し体系化する一年へ」にて、「なにか焦りを感じるときがあれば、すっと深呼吸」という表現で、外部環境に左右されない精神性を保とうと考えたのですが、if-thenプランニングの形式で、「もし、心に焦り・もやもやを感じたら、1回深呼吸する」という風に変えました。

「これまで思考」と「これから思考」

これは、シカゴ大学の心理学者ミンジョン・クーとアエレット・フィッシュバックの研究によって整理された、目標に対する2つの視点です。

「これまで思考」とは、「どこまでやり遂げたのか」に視点を向ける思考スタイルで、「これから思考」とは、「あとどれだけやらなければいけないのか」に視点を向ける思考スタイルです。

実験の結果、「これまで思考」の強い人は、早い段階で達成感を持つために、早く気が緩んでしまうという結果が出ているそうです。

そのため、「これから思考」を重視して、目標までの距離を図ることが、モチベーション維持における重要な点と言えそうです。

2冊目「やる気が上がる8つのスイッチ」

「ハイディ・グラント・ハルバーソン の やる気が上がる8つのスイッチ」は、いかにして自分あるいは他人のモチベーションのスイッチを入れるかという点について説明しています。この書籍では、画一した一つの方法だけを示しているわけではないことが特徴です。つまり、体調不良をお医者さんが診断するときに多種多様なタイプに応じて必要な処方箋が違うのと同様に、「やる気」という点においてもそれぞれのタイプに応じて必要なアプローチが違うという点を強調しています。

証明マインドセットと成長マインドセット

まず、その人がどのようなマインドセットを持っているかについて、2つのマインドセットを紹介しています。

証明マインドセットを持つ人は、自分の能力の証明に焦点を当て、エネルギーを注いでいます。つまり、人に自分の能力を見せつけ認めさせようとしているタイプです。そのため、意識的/無意識的に他人と自分を比べます。そして、ミスをすることをいつも恐れ、自分にはできない/無理だということが人にも自分にもわかってしまいことを怖がります。

端的な表現を使うと、「すごい人と思われたい」人と言えます。一方で、成長マインドセットは、「すごい人になりたい」人です。

成長マインドセットを持つ人は、他人の目をあまり気にせず、他人が自分をたとえ認めてくれなくても、やると思ったことをやる人です。困難に直面したときも粘り強く頑張り続けるという特徴があり、有利に働きやすいのは「成長マインドセット」です。

私達が固定的にどちらにマインドセットを持つというわけではないようですが、私自身、「証明マインドセットが顔を出していたな?」と反省することが度々あるなと気づくことがあります。きっと、人間だから他の方もそういうときが思い当たるのではないかなぁとおもうのですが、注意が必要ですね。

獲得フォーカスと回避フォーカス

たとえ同じ目標に向かっていても、そのアプローチは人によって違います。それはどこに焦点を当てるかによって変わりそうですが、それが「獲得フォーカス」・「回避フォーカス」という整理です。

  1. 獲得フォーカス(Promotion Focus)
    • 高いレベルの仕事: 獲得であり達成
    • 動機づけ: 称賛を得る
  2. 回避フォーカス(Prevention Focus)
    • 高いレベルの仕事: 安定感であり信頼性
    • 動機づけ: 批判を避ける

これらはどちらが良いというよりかは特徴としてどちらよりかという風に人を見ると面白いかもしれません。

多くのことに手を出しがちなのが獲得フォーカスなのに対し、回避フォーカスはやり始めたことは最後までやろうとします。途中でやめたり、考えを変えたりするのが苦手なのです。獲得フォーカスの人が仕事を先延ばしにしがちなのに対して、回避フォーカスの人は最初から時間を多めに見積もり、期限までに仕事を完了できるようにします。

ハイディ・グラント・ハルバーソン. やる気が上がる8つのスイッチ (Japanese Edition) (Kindle Locations 222-225). Kindle Edition.

8つのタイプ

これまで上げた「マインドセット」・「フォーカス」に「自信の有無」を加えた3つの軸で、8つのタイプが現れるようです。

  1. 中二病
  2. うざいやつ
  3. 臆病者
  4. 退屈な人
  5. やる気の空回り
  6. まじめな見習い
  7. 新星
  8. 熟練の匠

書籍では、これらのタイプ別に治療法を提示していますが、「7. 新星」・「8. 熟練の匠」が目指すべき境地と解説しています。

たとえば、新星は、

というタイプで、個人が持っている能力を存分に発揮しているよいレベルだとしています。

また、熟練の匠は、

というタイプで、目立たなくてもしっかりとその場を支えてくれる人たちです。

この整理がいいなと思うことは、この整理によって、タイプが違う人に対してその能力の発揮を認識しやすくなる点です。正直なことを言うと、自分が「獲得フォーカス」が強い人間だと自己認識している分、「回避フォーカス」が強い方の思考やモチベーションを理解しづらい側面があります。しかし、この整理によって、「その人は回避フォーカスで成果を上げている熟練の匠タイプなんだ」と納得できれば、タイプが違っても理解できる。非常にいいアイデアだなと感じました。

まとめ

以下の2冊を読み始めて、2冊で1時間足らずで読めたので、年末最後に一冊という方には、ちょうどいい分量なのではという感じでした。

  • ‪ハイディ・グラント・ハルバーソン の やり抜く人の9つの習慣 コロンビア大学の成功の科学
  • ‪ハイディ・グラント・ハルバーソン の やる気が上がる8つのスイッチ

また、この書籍から多くの参考文献のリンクが貼られているので、人間観察の材料としての心理学の入り口としてもちょうどいいと思います。

2020年抱負 実践知識をより多く獲得し体系化する一年へ

2020年における個人の目標・マイルストーンを整理する。「走り迷い戸惑った2019年を振り返る1」にて、2019年の振り返りの結果、2020年の目標を考えます。また、心構えとしての行動指針もいくつか決めてみようと思います(という自己満足です)。

khigashigashi.hatenablog.com

Theme

「実践知識をより多く獲得し体系化する」

2018年・2019年は、マイルストーンに「登壇におけるアウトプットの質と量」をおいていました。2020年は、いかに体系化された実践知識を獲得し成果として提示できるかという点をテーマとします。

そして、それを実現するための構成要素として、インプット→実践→体系化という流れをいかに回せるかを考えます。この3つのステージにおいてマイルストーンを設定していきます。

この中でいちばん重要なステージは、実践と捉えます。とくに、業務における実践・コードにおける実践を重要視し、その結果を体系化するという流れとします。

具体的な方向性・関心

具体的な方向性はいったん何も決めずにいきます。というよりかは、1年という単位の中で大きく興味・関心が深く広く移り変わる状況において、なかなか一つの分野を決めるのは自分には向いていないというのが正直なところです。

そのため、ここに記述するのは、2020年1月1日の現時点の関心についてです。直近は次のような関心を持って、テーマに準じて後述するマイルストーンをやっていきます。

ソフトウェアデザインにおけるデザインパターンの理解の深化

これは、デザインパターンを使えるようになるぞ〜ということよりかは、パターン・ランゲージとしてのGoFデザインパターンであったり、そこから時系列的にはあとに続くXP・アジャイルといった様々なプラクティスに対する理解を、線で捉えた上で、それを現在に生きる我々の成果物に投影可能な形で言葉に落とし込むということに興味があります。この分野において、まだソフトウェアの世界では未完成な部分があり、ここに微力ながらでも言葉やコードとして表現することで、言語化が進めばいいなと感じています。

殴り返せるだけのプログラミング力

PHP, Go, Pythonなどプログラミング言語フレームワークの個別技術についての習熟度は、現時点で自分の興味のベクトルの先にある感じはしていません。ただし、抽象的なことを扱えば扱うほど、個別技術において実現する力がない・あるいは示せない状態では、ある種「無」を感じてしまう自分がいます。名付け得ぬ質などといった思想から、それを導くための原理・原則を導き、実践知見としての様々なパターンがあるわけですが、実際に実現できるからこその思想・原則・パターンだと考えます。

また、「年末にちょうどいい「やり抜く人の9つの習慣」と「やる気が上がる8つのスイッチ」2」にて紹介した「やる気が上がる8つのスイッチ」という書籍にて、スキルや実力が伴ってこそ「新星」といった、充分に活躍できている状態となれることを、示しています。

khigashigashi.hatenablog.com

なお、「殴り返せるだけの」と荒っぽい表現となっているのは、そのくらいのファイティングポーズは引き続きとってくぞ!っという素の人格の治安の悪さをそのまま残しておくためです。

相互援助ができるチーム・プロジェクト体制をどう作るか

これは、現職にて感じている課題に対する関心です。「走り迷い戸惑った2019年を振り返る[^1]」にて事業への貢献のあり方を、「仕事としてのプロフェッショナリズムを求める最低基準を、自己からチームに拡大する」と定義したのですが、単体の自分の腕力で解決するのはすぐにスケールしないことは明白なので、自分自身含めて、相互に援助できるようなチーム体制を採用なども含めてどうできるかというところには関心があります。関連するキーワードでいうと、スクラムなりアジャイルチームなりそういった言葉なのでしょうか(まだまだ不勉強です)。このへんの個人に閉じない部分についても、何らかのアウトプットが出ていれば良いなと感じます。

Milestones

派手さのないシンプルなものを3つおきます。

  • [ ] (継続的なInput)12回以上1冊読んだ書評を書く
  • [ ] (継続的な実践)12回以上、業務にて、技術的に現状を変える小さな成果を出し、6回以上公開可能な形でアウトプットする
  • [ ] (体系化)同人/商業問わず、一冊の単著を書く

(継続的なInput)12回以上1冊読んだ書評を書く

インプットを考える際に、知識がないと見えないものがあることは明らかであるため、知識をインプットしていくのが最初のステージとして重要です。これは、パターン・ランゲージに関する第一人者である井庭崇氏の「認識のメガネ」という表現を参考に改めて感じたことです。

これまでは、カンファレンスの登壇といった、言語化マイルストーンに対して多くの書籍を読んでいました。ただし、これはある程度「認識のメガネ」をかけられている前提があるため、毎月認識のメガネをかけなおせるように12回以上という最低限のマイルストーンをおきます。

(継続的な実践)12回以上、業務にて、技術的に現状を変える小さな成果を出し、6回以上公開可能な形でアウトプットする

OSSとして公開する数といった形も考えましたが、2020年において重要と捉えるのは、事業において適用・実践した形で体系化することです。 そのため、業務において、技術的成果を出した上で、最低限2ヶ月に1回は、外部に公開可能なレベルに一般化した実践知見をアウトプットできればと思います。

(体系化)同人/商業問わず、一冊の単著を書く

インプット→実践→体系化の最後の段階で、しっかり体系化につながったからこそ、それを体系化するアウトプットが出せればというマイルストーンです。



行動指針

いくつか、自分の中で、こうしておこうという心構えを明文化しておく。

  • 自在不羈
  • 独自性の追求

自在不羈(じざいふき)

自分が思うこと・興味のあること・関心のあることのままに行動して、外的要因や数多くある他人のいろいろには惑わされずにやっていく、的なことを探したらこの熟語だった。

いろいろ「すごいな〜」と思うことはたくさんあるけれど、それはそれと一旦おいておいた上で、自分が「コレに興味ある」という内発的動機・心の中をひたすら見つめる。

これは、時代の移り変わりや外の変化に気がつけないという状況に陥るリスクも有る気がするが、「自分は自分、他人は他人」で、それについてはあえて見ない方向で、心の調整をする。なにか焦りを感じるときがあれば、すっと深呼吸。

また、セルフブランディングなどといった考えも考慮しないことにします。これは自尊心やプライドといったくだらないものが顔を出さないようにするために、意識してあえて「どうでもいいもの」と価値を下げます。あくまで自分の中での価値基準なので、他人がやってるセルフブランディングはこの価値基準には当てはまりません。その人にとっては現在必要と価値を見出しているものだろうというふうに捉えて素直に応援することを推奨します。

独自性の追求

これは、「プレゼンテーション・パターンという認識のメガネ | 書評「プレゼンテーション・パターン: 創造を誘発する表現のヒント」3」という記事で紹介した、プレゼンテーション・パターンの一つ、No31. 独自性の追求というパターンをお借りしています。

独自性とありますが、ここで言う独自性は、他人と違うことをするという意味ではありません。

心の独自性とは単に他と違うということではなく、その人でなければ到達できないような、普遍的な本質に迫るものです。

とあります。私は、「組み合わせによる希少性」などといったテーマをあげていましたが、この独自性は自分の中での上位概念に当たると捉えています。興味をきわめて実践して体系化することで、独自性を追求していければと思います。

khigashigashi.hatenablog.com

if-then Plannings

  • もし、心に焦り・もやもやを感じたら、1回深呼吸する
  • もし、不安と焦りを感じたら、ポエムを書いて明らかにする。if-thenプランニングに落とし込める場合、ここに追記する


Archivement

達成状況について以下トラッキングしていく。

(継続的なInput)12回以上1冊読んだ書評を書く

現在: 0/12

Date | Title | URL --------- | --------- | ---------

(継続的な実践)12回以上、業務にて、技術的に現状を変える小さな成果を出し、6回以上公開可能な形でアウトプットする

現在: 0/12, 0/6

Date | Title | URL --------- | --------- | ---------

(体系化)同人/商業問わず、一冊の単著を書く

現在: 0/1

Date | Title | URL --------- | --------- | ---------

プレゼンテーション・パターンという認識のメガネ | 書評「プレゼンテーション・パターン: 創造を誘発する表現のヒント」

プレゼンテーション・パターン: 創造を誘発する表現のヒント1という、人間活動におけるパターン・ランゲージの一つである、プレゼンテーション・パターンについての書籍についての書評です。

「プレゼンテーション・パターン: 創造を誘発する表現のヒント」とは

この書籍は、慶應義塾大学総合政策学部教授である井庭 崇氏と井庭研究室の方々によってまとめられました。

www.keio-up.co.jp

井庭 崇氏は、「パターン・ランゲージ: 創造的な未来をつくるための言語2」というパターン・ランゲージに関する書籍の編者もされている、国内におけるパターン・ランゲージについての第一人者の方です。当該書籍については、別途書評記事を書きました。

khigashigashi.hatenablog.com

Web上ですぐにこのパターンについて知ることができます。書籍版では、さらにWeb版よりも詳細に内容について説明されているという違いがあります。

プレゼンテーション・パターン (Presentation Patterns)

この書籍は、個人的に2つの楽しみ方をさせてただきました。

  1. 認識のメガネとして過去を見る
    • 自分で整理したり参考にした「プレゼンスキル」をプレゼンテーション・パターンを通じて再評価する
  2. 「パターン・ランゲージ」として見る
    • 建築におけるパタン・ランゲージ、ソフトウェアにおけるデザイン・パターンといった他存在するパターン・ランゲージの一つとして捉えることで、「パターン・ランゲージ」という物自体を理解する

これらの2つの枠組みを通じて、プレゼンテーション・パターン: 創造を誘発する表現のヒント[^1]という書籍を紹介させていただこうかと思います。

プレゼンテーション・パターンとは

そもそも、本書籍にて解説されているプレゼンテーション・パターンとは、なんなのか?

これは、井庭 崇氏とその研究室の学生の方々が、自分たちの経験を見つめ直し、広義のプレゼンテーションにおける「大切なこと」を探り、体系化し、言語化し、「創造的なプレゼンテーション」の秘訣をまとめたものです。 

全部で34個のパターンが存在しており、ゆるやかにつながり全体を構成する構造になっています。次の画像にあるような可愛らしいキャラクターが扉絵に登場するために、非常に読みやすく親しみやすい内容になっています。

f:id:khigashigashi:20191230190506j:plain

Core Patternである、「創造的プレゼンテーション」が、パターンの核となる概念になります。

創造的プレゼンテーション

創造的プレゼンテーションとは、単なる「伝達」ではなく、聴き手が新しい発想や発見を生み出すことを誘発する「創造」の営みとしています。

プレゼンテーションを、「伝達」の場ではなく「創造」の場であると捉え直し、聞き手の想像をかき立て新しい認識・気づきを生み出す「創造的なプレゼンテーション」となるようにデザインする。

プレゼンテーション・パターン (Presentation Patterns)

ただ、伝えるだけではなく、聴き手が創造的になるという点が重要な点です。

このコアパターンに、ゆるやかにつながるように、残り33個のパターンが展開されます。



1. 認識のメガネとして過去を見る

認識のメガネ

タイトルに使わせていただいている「認識のメガネ」という言葉ですが、本書籍の Column プレゼンテーションを見るための「認識のメガネ」 にて触れらている言葉です。

プレゼンテーション・パターンは、プレゼンテーションについての「認識のメガネ」だと捉えることができます。このメガネをかけることで、これまで注目してこなかった部分が浮かび上がってきます。たとえば、ある人のプレゼンテーションを見るときに、プレゼンテーション・パターンのメガネを通して見ることで、その人がどのような工夫をしてつくっているのかを理解することができます。あるいは、自分のプレゼンテーションを振り返ることで、自分がどのようにプレゼンテーションをしてきのかや、今何ができていないかが見えてきます。

私は、「やったことがある人にしか見えない視点がある」とよく表現し、自分で実践してみてから評価しようとするのですが、同様に、「知らないと見えないことがある」というのも非常に重要な観点です。パターンというのは、使えるときに使うものくらいの認識だけな人がいるかも知れませんが、パターンを知ることで世界の見方が変わることに大きな意味があると感じます。

ここからは、自分自身がカンファレンス発表などを繰り返し行ってきた過去において、意識していたことが、「このプレゼンテーション・パターンにあてはまりそう」という視点で見ていきます。

同時に、他の方がブログ等で紹介している、プレゼンテーションの「具体的なTips」についても、「このプレゼンテーション・パターンと対応してそう」という風に一方的に感心する時間にもしてみたいと思います。

題材1: 筆者の発表の作り方

所属企業のブログにて、「Go Conference Tokyo 2019 Spring にて行った発表内容の作り方3」という、カンファレンスにおける発表の作り方という記事を書きました。

devblog.thebase.in

これを振り返ると、自分の書いた文章は、以下のパターンで再評価できると気が付きました。

No. 2 心に響くプレゼント

自身のブログ内に、「1. 「誰にどう役立ってほしいか」というありたい姿を整理する」という整理をすることを推奨する内容を書いていました。具体的には、「自分が共有する内容はこういう人に役立つはず」という聴講者の具体的なイメージをすることです。

これは、プレゼンテーション・パターンにおいては、2. 心に響くプレゼントと対応していそうです。

https://presentpatterns.sfc.keio.ac.jp/No2.html

このパターンにおける解決方法は、このプレゼンテーションが誰に向けてのものなのかを意識し、その人が喜ぶような魅せ方を考える。 というものです。

No. 4 ストーリーテリング

自身のブログ内では、「3. 期待に応えるための構成・ストーリーを作る」と言う話の中で、トークの課題・背景共有について書きました。これは、聴講者と語り手である自身との共通の土台を作る作業として、ほとんどのカンファレンスにおける発表にて行っています(いるつもりです)。

これは、プレゼンテーション・パターンにおいては、4. ストーリーテリングと対応してそうです。

メッセージが魅力的に伝わるストーリー(物語)をつくり、そのストーリーに従ってプレゼンテーションを作るようにしましょう、というものです。社会的な背景から入るストーリー、聴き手を中心としたストーリー、語り手の話から入るストーリーと3パターンが書籍内で説明されていました。聴き手の心を動かすことを問題意識としたパターンとなっています。

題材2: めもりーさんの発表の作り方

現在所属企業で同僚であるめもりーさんが、「エンジニアにおける登壇の心構えと資料作成のプラクティス4」というブログ記事にて、登壇と資料について書いています。

devblog.thebase.in

この記事内の解説も、プレゼンテーション・パターンに該当するようなものがあり、さすがだなぁと一方的に感心したので紹介してみます。

No1. メインメッセージ

記事内で、「相手に「何を伝えたいのか」を自分自身が完璧に理解する」という解説をしています。自分は、何を伝えたいのか?という点について自問自答を繰り返していくというものです。

これは、プレゼンテーション・パターンにおいては、1. メインメッセージというパターンに対応して考えられそうです。

https://presentpatterns.sfc.keio.ac.jp/No1.html

最も伝えるべきメッセージをひとつに絞り、そのメッセージに関係する内容だけを取り上げるようにする、というパターンです。

No25. キャスト魂

記事内で、「自分はピエロだと思いこむ」という解説をしています。

登壇当日私は自分自身のことを「ピエロ」だと思いこむようにしています。これは誰かにそう言われたからではなく、自分自身の緊張を解す意味でもそう思うようにしています。ピエロであるからには、オーディエンスの皆様に楽しんでもらって帰ってもらいたいという気持ちを持つようにします。 楽しんでもらうわけですから、誰か一人でも傷つけたり不快な思いにならないように最善の注意を払います。

これは、プレゼンテーション・パターンにおいて、25. キャスト魂に近いものがあるなと感じました。

https://presentpatterns.sfc.keio.ac.jp/No25.html

このパターンでは、プレゼンテーションの内容を伝えることに集中してしまい、自分が見られているということを忘れてしまうという状況において、次のようなことが発生する問題に伴うパターンです。

  • プレゼンテーションを通して伝わることは内容だけではない。
  • 人は緊張すると、周りの人や状態が見えにくくなってしまう。

パターン・ランゲージの有用さ

これまで、過去のブログ記事にて書いたこと・書いてあったことを通じて、一部パターンを紹介しました。それぞれ各人が思っている「こうしたらよくなる」というアイデアが実際に、創造的プレゼンテーションを作ることにおいても同様に当てはまる普遍的なアイデアと言えそうだということが見えました。

が、ここで強調したいことはそうではなく、このようなアイデアが緩やかな前後関係を伴った上で、体系的に、かつ統一的な書式で整理されている、ということが素晴らしいアイデアだなと感じました。

さらに、パターン・ランゲージ自体が目指す部分として、Column パターン・ランゲージという方法 にて、次のように説明しています。

パターン・ランゲージが目指しているのは、「これをこの手順でやるべし」という一つの大きな枠にはめ込むことではなく、いまの自分のやり方をベースとしながら少しずつ拡張・成長していくことを手助けすることです。

おそらく、各人において、「このパターンはできてる」と思える部分があると思います。そこから広がる形でパターンを眺めると、漸進的に自身のプレゼンテーションを成長させていく指針となりうるのではないでしょうか。



2. 「パターン・ランゲージ」として見る

さて、一転して、パターン・ランゲージ自体を眺めるという切り口において、プレゼンテーション・パターンをみてみます。

そもそも、パターン・ランゲージとは、建築家のクリストファー・アレグザンダーが提唱した知識記述の方法です。建物や街の形態に繰り返し現れる法則性を「パターン」と呼び、それを「ランゲージ」(言語)として記述・共有することを提案したものです。それによって、目指したものは 街や建物のデザインについての共通言語をつくり、誰もがデザインのプロセスに参加できるようにすることでした。

パターン・ランゲージでは、デザインにおける問題発見・解決の経験則を「パターン」としてまとめています。この、問題発見・解決がセットとなっているのは、デザイン行為が問題発見・問題解決の2つの要素があるからとされています。

それがゆえに、パターンの統一的な書式が、「状況(Context)」・「問題(Problem)」・「解決(Solution)」となっています。

パターン・ランゲージ3.0

これは、「パターン・ランゲージ: 創造的な未来をつくるための言語[^2]」という書籍にて説明されていますが、パターン・ランゲージは3つの世代があると、著者である 井庭 崇氏は説明しています。

建築家アレグザンダー氏が提案された段階である「パターン・ランゲージ1.0」、その後ソフトウェアの分野で応用・展開された段階を「パターン・ランゲージ2.0」、その後人間行為のパターン・ランゲージという新しい応用の段階を「パターン・ランゲージ3.0」と呼んでいます。

その中で、プレゼンテーション・パターンは、パターン・ランゲージ3.0の一つと言えます。この世代に対応して、「デザインの対象」・「デザインの特徴」・「ランゲージの使い方」という3つの角度で比較できるようです。

デザインの対象

パターン・ランゲージ3.0では、デザインの対象が人間行為に向いています。つまり、物理的なものを対象とした建築の1.0、非物理的なものを対象としたソフトウェアや組織の2.0に対して、学びや教育などを対象としています。

デザインの特徴

建築の1.0においては、建物や街のデザイン段階と、そこに住民が住む段階が不可避的に切断されてしまいますが、ソフトウェアの2.0では、物理的なものと比較して作り直すことが容易なため、断続的に繰り返される構造となります。そして、3.0の人間校のデザインにおいては、「継続的に」デザインが行われる可能性があり、1日ごとでもデザインし直して実践することができる特徴を指摘しています。

ランゲージの使い方

建築における1.0の段階では、デザイナー(建築家)とその結果を享受するユーザー(住民)の橋渡しをするために考案されたとされています。

ソフトウェアに展開された2.0では、熟練したデザイナー(エンジニア)とそうでないデザイナー(エンジニア)の差を埋めるために用いられるようになったとのことです。これが、ソフトウェアの世界におけるデザイン・パターンについての使われ方の端的な整理として表現されています。

そして、人間行為に着目した3.0では、人々が暗黙的に持っている「経験」に光を当て、それを捉え直し、語り合うことを支援するために用いらます。

実際に、自身が体験したランゲージの使い方としても、プレゼンテーション・パターンを通じて、自身の経験を捉え直して、こうしてブログに書き連ねるという実践につながっています。

記述量の違い

これも、「パターン・ランゲージ: 創造的な未来をつくるための言語[^2]」という書籍の 第4章 パターン・ランゲージとネイチャー・オブ・オーダー にて説明されていますが、アレグザンダー氏がまとめた「パターン・ランゲージ」やソフトウェアにおけるデザイン・パターンは、記述的で、詳細に書くことが重要視されています。

実際に、英語版のアレグザンダーのパターンは700ワード、GoFデザインパターンは2000ワードくらいあるようです。それに対して、プレゼンテーション・パターンなどの井庭 崇氏が整理したのは、200ワード程です。

この意図は、具体例は対話の場面で口頭で聞くことが大切だという点があるようです。そのため、文字で書かれたドキュメントだけでは完結しないように作っているとのことです。語りや対話を引き起こす「スキマをつくって」いるようです。

まとめ

プレゼンテーション・パターンは、普段プレゼンテーションするような機会がある人であれば、自分を振り返るいい機会になるのでおすすめです。このパターンの背景理論にぐっと深堀りしたい方は、再三紹介している「パターン・ランゲージ: 創造的な未来をつくるための言語[^2]」という書籍と合わせて読むことをおすすめします。

パターン・ランゲージを分野を超えた流れから捉える | 書評「パターン・ランゲージ: 創造的な未来をつくるための言語」

「パターン・ランゲージ: 創造的な未来をつくるための言語1」という書籍が面白かったので、振り返りがてら書評を書いていく。

TL;DR

  • 「パターン・ランゲージ: 創造的な未来をつくるための言語[^1]」という書籍は、建築・ソフトウェア・政治など様々な分野から、パターン・ランゲージについての考えを聞くことができる
  • パターン・ランゲージを3つの世代という時間軸で整理している点が(個人的に)新鮮だった
  • ソフトウェアにおけるデザイン・パターンの課題感と、よりクリエイティブでより根源的な「デザイン・プリンシプル」(設計原理)を学ぶ重要性

この書籍に至るまで

https://www.amazon.co.jp/dp/4766419871

(この書籍名に引っかかった方であれば、これから紹介する書籍もすでに読んだことがある方かもしれません。) 以前、江渡 浩一郎氏の「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)2」という書籍を読み、建築家のクリストファー・アレグザンダー氏の考えがソフトウェア業界にどのように適用されていったかという歴史の線に興味を持ちました。

khigashigashi.hatenablog.com

その後、長坂 一郎さんの「クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う3」を読み、アレグザンダー氏の考えの変遷を線で捉えることができました。

https://www.amazon.co.jp/dp/4395320465

そこから、ソフトウェア設計における「デザイン・パターン」というものを、出自から見直すことで、さらに有効に使えるのではないか、という仮説を持って、いくつか関連の発表を通じて、自分の中の頭の整理をつけてきました。

なんとなく頭の中にもやもやと浮かんでいる、パターン・ランゲージの構造とデザインパターンの構造の差異について、その分野のエキスパートの方々はどう捉えているのだろうかと思い、この書籍を手に取りました。

非常に内容が詰まっているのですが、個人的に琴線に触れた部分を一部ピックアップして、関連書籍とどう紐付いてそうかについても紹介してみたいと思います。

パタン・ランゲージをさらに大きな流れで捉えられる書籍

書籍を読み始めてから、一気に止まらず読み進めて、2日で一気に読み終えました。この書籍は、建築家アルグザンダーの考えたパタン・ランゲージだけを扱っているわけではないことに大きな特徴があります。

パターン・ランゲージは、1970年代に建築家クリストファー・アレグザンダー氏によって、住民参加型の町づくりを支援するために提唱された方法です。町や建物に繰り返し現れる特徴を「パターン」と捉え、それを「ランゲージ」として記述・共有することを提案しています。

これについて、編者である井庭 崇氏は、パターン・ランゲージに3つの世代があると説明しています。

建築家アレグザンダー氏が提案された段階である「パターン・ランゲージ1.0」、その後ソフトウェアの分野で応用・展開された段階を「パターン・ランゲージ2.0」、その後人間行為のパターン・ランゲージという新しい応用の段階を「パターン・ランゲージ3.0」と呼んでいます。

この書籍は、これらの大きな流れをとりまく話を、編者の説明と各分野のエキスパートの方々同士でのトークセッションという形で進められます。そのため、建築・ソフトウェアにおけるパタン・ランゲージという話は他書籍でも楽しめますが、井庭さんがまとめてらっしゃる「プレゼンテーション・パターン4」や「コラボレーション・パターン5」といった人間行為におけるパターンについても語られています。

この書籍の進み方

この書籍は、下記の目次で進められます。

  • 序章 創造的な未来をつくるための言語 ーパターン・ランゲージ入門ー(井庭 崇)
  • 第1章 建築におけるパターン・ランゲージの誕生(中埜 博・井庭 崇)
  • 第2章 建築からソフトウェアへ ーパターン・ランゲージの展開ー(江渡 浩一郎・中西 泰人・井庭 崇)
  • 第3章 制作言語=政策デザインのパターン・ランゲージを作る(竹中 平蔵・井庭 崇)
  • 第4章 パターン・ランゲージとネイチャー・オブ・オーダー(中埜 博・羽生田 栄一・井庭 崇)

目次から分かる通り、建築・ソフトウェア・政策デザインと、様々な分野におけるパターン・ランゲージが考察されています。

パターン・ランゲージの世代ごとの使われ方の着目

パターン・ランゲージは3世代があるという点については、冒頭で紹介しました。この世代の整理において、どのような使われ方をされているかについても、「序章 創造的な未来をつくるための言語 ーパターン・ランゲージ入門ー」にて、簡潔に整理してくださっています。

建築における1.0の段階では、デザイナー(建築家)とその結果を享受するユーザー(住民)の橋渡しをするために考案されたとされています。

ソフトウェアに展開された2.0では、熟練したデザイナー(エンジニア)とそうでないデザイナー(エンジニア)の差を埋めるために用いられるようになったとのことです。これが、ソフトウェアの世界におけるデザイン・パターンについての使われ方の端的な整理として表現されています。

そして、人間行為に着目した3.0では、人々が暗黙的に持っている「経験」に光を当て、それを捉え直し、語り合うことを支援するために用いらます。

筆者自身が普段使うのは、パターン・ランゲージ2.0の代表的なもののひとつ、デザイン・パターンですが、この整理は納得感がある良い説明だと感じました。実際に、Gang of Fourの「オブジェクト指向における再利用のためのデザインパターン6」の第1章 概論においても次のように記述されています。

経験豊富なオブジェクト指向設計者は実に良い設計をする。一方、初心者は利用可能な豊富な機能に惑わされ、結局のところ、彼らが以前から用いているオブジェクト指向ではないテクニックにすがる傾向がある。初心者が「良いオブジェクト指向設計とは何か」を学ぶには多分な時間がかかるのである。つまり、経験方法な設計者は、初心者が知らない何かを知っているのである。それは何なのだろうか。

熟練したデザイナー(エンジニア)とそうでないデザイナー(エンジニア)の差を埋めるためという課題感が前段にあったことは汲み取れると感じます。

さらに、本書籍では、パターン・ランゲージ2.0に次のような解説を加えています。

熟練者の技を学ぶためには、パターンを読んで学ぶとうことが中心的な使い方となったのである。そこにはユーザーは登場せず、デザイナーとユーザーのコラボレーションも視野から外れてしまった。

実際、建築におけるデザイン・パターンでは、ユーザーとの共通語彙となっているが、ソフトウェアにおけるパターンは、ユーザーとのコラボレーションで使われるものではない

この差異についても、デザイン・パターンの輪郭をくっきりさせる上で非常に重要な点と言えそうです。

パタン・ランゲージの書式における重要度

「第4章 パターン・ランゲージとネイチャー・オブ・オーダー」において、クリストファー・アレグザンダー氏のもとで学び、日本でもアレグザンダー氏と一緒に活動された建築家である中埜氏が次のように語っていました。

みなさんは、パターンの書式の三本柱である「問題」「解決」「コンテクスト」を知っていると思いますが、そのなかの「コンテクスト」がいちばん大切なのです。「状況」や「問題条件」「環境」などと訳されるのですが、どれもぴったりこない。基本的には「コンテクスト」とは、パターンとパターンがどのように自立しつつ、相互に関係しているのか、そしてそのためには、パターン自身がどのようにジャンプをして、さらによい解決につなぐことができるのか、というリンクのことです。

パターン・ランゲージには、すべてのパターンにおいて、統一されている書式があります。クリストファー・アレグザンダー氏自身の書籍の翻訳本である「パタン・ランゲージ―環境設計の手引7」の「本書の使い方」とにて、パタンの使い易さ・わかり易さのために、同一の書式にまとめている点について言及しており、最初にその書式を説明することから始めています。この書籍内の翻訳では、コンテクストを前後関係と訳していますが、パタンに前後関係があることに重要な目的があると説明しています。

このような書式を用いたのは、2つの重要な目的のためである。第1に、パタン相互に関連性をもたせ、253パタンの集合を1つの全体、つまり1つの言語(ランゲージ)として把握し、無数の組合わせを可能にするためである。第2に、パタンの根底にある本質を見失わずに、読者自身が、各パタンの問題と解答を判定し、修正できるようにするためである。

そういえば、Gang of Fourの「オブジェクト指向における再利用のためのデザインパターン[^6]」の「6.3 パターンのコミュニティ」において、パターン・ランゲージ1.0と違っている点について説明していますが、その中の一つに次のような説明をしています。

  1. Alexanderのパターンは扱う問題を強調しているが、我々のデザインパターンは解決法についてより詳細に記述している。

パターン・ランゲージ2.0においては、解決法を強調したという結果となっている点も、世代間の違いとして捉えられるかもしれません。

ソフトウェアにおけるパターン・ランゲージの課題

「第4章 パターン・ランゲージとネイチャー・オブ・オーダー」において、情報システムの観点からパターン・ランゲージを探求・活動されている羽生田 栄一氏は、次のように語っています。

他方で、そのソフトウェアは何を目指すのか、どのようなユーザーがどのような環境で使うのかを想像しないまま、エンジニアの技術的な基準のみでデザイン・パターンが適用されてしまいます。それでは、まさにいま中埜さんが言われたように、悪いパターン、「いきいき」していないソフトウェアになってしまいます。そうならないようにはどうすればよいのかを、ITの世界でも考え始めています。

悪いパターン、「いきいき」していないソフトウェア になってしまうという状況にならないための一つの指針として、デザイン・パターンを構成する、よりクリエイティブでより根源的な「デザイン・プリンシプル」(設計原理)をエンジニアがしっかりと学び、身体化することを上げています。つまり、ソフトウェアの設計・開発ではここだけは押さえないと美しくならない、という身体感覚を持つことが必要だと示しています。

まとめ

パターン・ランゲージを、過去・現在・未来と大きな時間軸で、いろいろな分野を渡りながら感じられる点がとても面白かったです。この書籍は章ごとに、パターン・ランゲージにそこまで詳しくない聴講者向けに概要が最初から説明されるので、他の関連書籍を読んでいなくてもパターン・ランゲージの世界を楽しめるものになっていると思います。

走り迷い戸惑った2019年を振り返る

2019年を振り返る自己満足を今年もやります。

前回までのあらすじ!

2018年はだいたいまとめるとこんな感じの1年だったようです。

khigashigashi.hatenablog.com

  1. 2017年10月にBASE株式会社に転職してきてからだいたい1年ちょっと経過
  2. PHPカンファレンスのメインホールで登壇できるようになりたい」という目標に少し近づいた
  3. ユニットテスト周りで様々アウトプットしてきたが、次の深みとして「アプリケーション設計」分野に対して洞察を深めていきたい

そして、それを踏まえた2019年の目標はこちらでした。

khigashigashi.hatenablog.com

  1. PHP系カンファレンスでのロングセッション登壇
    • Clear! PHPerKaigi2019にてロングセッション
  2. Go系カンファレンスでのセッション登壇
    • Clear! Go Conference Tokyo 2019 Spring / Fukuoka
  3. 合計発表時間300分
    • Clear! 25回 367分
  4. OSSを3個以上公開する
    • Clear! 3つ(満足行ってはないが行動結果としてはclear)

なので、すべての目標をクリアした形になりました。

2019年を振り返ると

早回しで色々できた

自分が「もう少しかかるかな」と思っていたやってみたいことも実現したのがよかったです。具体的には、

  • 国際カンファレンスでの登壇(GopherCon / CakeFest)
  • 技術書典執筆(golang.tokyo)
  • 商業誌寄稿(みんなのPHP
  • PyConJP登壇(初めて参加したカンファレンスなのですこし思い入れがあった)

また、会社における状況も変わっていき、色々の経緯があり、「Tech Lead」というバッチがつくようになりました。

自分が想像していた25歳(早生まれなので来年3月に26歳)よりは、いろいろなことができた一年だったなと思います。

繋がりが増えた

PHP・Go・Python・Docker・CI・監視系あたりのコミュニティでいろいろスピーカーをさせていただいたこともあり、その界隈の方々と交流を深めることができたのは、素直に良かったと思います。スピーカーしているからすごいというわけでは全く無いとおもいますが、結果的にソフトウェアデベロッパーとしても経験が豊富で優れた一般知見を持っている方々が多いのも事実です。そのような方々と個別に話せたり、飲みの席に呼んでいただいたりするようになったのは、視座を上げる上で非常にありがたい機会だったのとと感じます。

登壇という行為は自分にとって「目的」にはなりえない

BASEに入る前の私は、駆け出しプロジェクトマネージャー/リーダーなどをしており、24時間365日追われていたので、技術コミュニティで活動することがあまりできていませんでした。(「時間は作ればいいじゃん」という意見をアウトプット系を推奨する際に聞こえるときがありますが、生きる時間全てかけても仕事が終わらない状況でそれは酷でしょと思う時があり、一般化した言葉としては強すぎるなとヒヤヒヤするときがあります。余談でした)(社内勉強会ではよく技術の話をしていたのでエンジニア職だと勘違いしていた同僚もいました)。 だからこそ、転職を決めて事業会社に行こうとした際に採用した目標がこちらででした。

PHPカンファレンスのメインホールで登壇できるようになりたい」

これは、大学生の時に参加したPyConJP 2015に参加した際に、そこで登壇しているスピーカーの方々に憧れを持ったからです。

devblog.thebase.in

個人的にPyCon JPは私がぴよぴよエンジニアをしていた際に、人生で初めて参加したカンファレンス(PyCon JP 2015)でした。当時登壇されている方々に、「いつかあそこで登壇するくらいになれたら良いなぁ」とあこがれて、それが現在、技術カンファレンスで登壇するようになった最初の原体験なるものだったりします。

これは、登壇できるくらいであれば、ある程度「一角の技術者になれた」というマイルストーンになるかなという、発想でもあります。

そこから時を経て、2018年・2019年と3年間でだいたい50回以上、外部で話してみました。「一角の技術者になれた」と全く思えません。

むしろ、話せば話すほど更に奥深い場所が見えてきます。これはいいことでもあります。無知の知です。知らないことを知るきっかけになるという意味で、アウトプットは素晴らしい。

さらに、私の中で深刻に感じ始めたのは「果たして自分は本当にコードにおける実践で優れた成果を出せる人間なのか」という不安です。さらに素直に心の内を表現するのであれば、 「話すこと・伝えることだけうまくなって、肝心な根幹となる技術力本当にコレで伸びてるの?」 という不安です。

実際に、人に伝えるために言語化して自分の理解を一般化することは重要です。この作業の過程の中で多くの文献や実体験を振り返る作業をしていきます。これをしてきたからこそ、今の自分がある、というのは高校生のときから行ってきた振り返りの習慣として大事にしたいです。

しかし、その振り返りの成果として、カンファレンスの登壇や書籍の寄稿ができたとて、「高度な専門力を有する技術者」になる道においては、主たるマイルストーンにはなりえないのでないかというのが今の仮説です。引き続き、自分の理解を体系化していく手段として、登壇という行為を有意義に使っていきたい(※ もちろん聴講者・イベント運営の方々ありきです)のですが、それを目標にするフェーズはもう終わったという時期になりました。

志向性の変化

自分は、現職に入社する前の生存戦略として、「ソフトウェア技術への理解とマネージメント」を掛け算することで希少価値を高める 戦略をとっていました。そんな私が、2年強前、転職してフルタイムのプログラマーとなるのは、戦略の大きなピボットです。

そこからは、とにかく好きなソフトウェアの世界を突き詰めたいという想いでやってきました。

Songmuさんのエントリーの言葉をお借りすると、「 好きなことしかしない覚悟 」をそこで決めました。

engineer-lab.findy-code.io

Personal Computer上自分が書いたコードで無限に世界が広がる、そんなワクワク感を感じたかつての自分の原点に戻って、それだけをやっていこう、その上で自分が生きていけるために、試し・考え・反省して、学びのサイクルを早めていこう、というのが、ここまでの2年強の関心です。

結果的に、「好きなことだけやろう」とやってきた結果、プログラミング自体が好きなわけではない 事に気がついてきました。PHPCakePHPなど触れている言語やフレームワークがすごく好きでそれに専門性を持ちたいと全く思えません。Go・PHPPythonとサーバーサイドの守備範囲を広げてきましたが、全部適材適所で使用して、書き心地とかは一旦おいておいて、その言語文化圏における思想を反映すればよいではないか、と考えます。つまり、プログラミングにこだわりを持てません。

ソフトウェア設計自体に関心が強くなりました。そうなると、サーバーサイドだけ専門性があっても不十分です。インフラ・フロントエンド等周りを取り巻くソフトウェア要素を組み合わせてこそのソフトウェア設計であるなかで、更に特定技術への専門性という志向性は薄まっていきます。 ゆえに、中間地点のコンテナが絡んだ設計や、AWSクラウドサービスをその設計においてどのように活用するかが、更に守備範囲として広がっていきました。

結果的に、組み合わせにおける希少性の考え方にゆり戻る ような方向を、また向く結果になっています。

器用貧乏への不安

組み合わせにおける希少性の考え方にゆり戻ると、揺り戻すように現れる、 「自分はただの器用貧乏になっていないか」 という不安です。構想は実現能力ありきです。個別技術の実現能力や知見の深さがここで重要になるでしょう。コレについて色々考えましたが、現時点では、 個別技術の能力が高いからこそソフトウェア設計への説得力が増すという風に考えました。

また、希少性という考え方は、結果的に「オンリーワン」を志向する考え方に近くなりますが、野球選手のイチローが、【人生100年 イチロー人生すごろく】という企画にて次のような言葉を言っています。

www.youtube.com

2番を目指して2番はダメでしょ。それは1番を目指した上で2番というのはそれはいいですけど、2番でいいというスタンスは、僕は嫌いですね。僕はオンリーワンという言葉は嫌いではないですけれど、結果オンリーワンになるという考え方

この言葉に僕はハッとした部分もあって、あくまで個別技術に対しても一流であることを目指すことは重要だと考えました。

そのため、個別技術の専門性を強みとしないけれど、「一流に見られる」くらいの個別技術の力は引き続き磨いていこうというのが現時点の方向性としました。(言い方をあらっぽくすると、殴り返せる技術力を磨こうと言う言葉を標語にしています。)

事業にどう貢献するか

自分が関わる事業にどのように貢献するか、これについても自身のフェーズが変わり、その捉え方に変化が必要と感じてきました。

結論としては、 他の人のために、好きなこと以外もやろう というふうに向く方向が変わりました。

「エンジニアのイベントへの登壇をどう評価に結びつけるか」というえふしんさんの記事にて、事業における貢献のあり方について考えを展開していますが、その考えに当てはめると、自分の貢献は直接的・間接的の両方があります。

note.com

実際、イベントに参加する際に必ず登壇するのは、それが回り回って自社への貢献になる、と思っているからです。これは、かつてのBASEの現場エンジニアで登壇しそうな人が周りに少なかったがゆえのある種の責任感でもありました。

その間接的貢献の仕方も、登壇するような方が増え、希少性という価値が薄まった今、「では自分はどう貢献する?」と考え直しました。

これは、「Tech Lead」というバッチがついたことも相まって、そもそもTech Leadとは何なんだ・・・というう迷いと入り混じり、数ヶ月迷い続けることとなりました。

自分の道の中で、「Tech Lead」というバッチを目指していたわけでも無い中で、このバッチとどう向き合うのかについては、非常に悩ましい問題です。内発的動機をひたすら見つめていた自分に突如、外発的な要求が発生したように感じたためです

色々思い悩んだ結果、 自分の進みたい方向性に対して考慮外とする ことにしました。ただし、仕事としてのプロフェッショナリズムを求める最低基準を、自己からチームに拡大する変更をしました。そうすると、「周りの同僚を先回りしてどう助けるか」・「働きやすいようにするためにはどうしたらいいか」・「悩みを減らして走れるようにするにはどうしたらいいか」を、さらに考えるようになりました(これは、事業でアーキテクチャを考えた経験がある方であれば、同様の関心事を持つのではないかと思います)。

総括

「明日死んでも悔いがない人生を送ろう」と思い刹那的に生きようとしてる自分ですが、今年も刹那的に生きることができたと思います。 来年はまたさらに仕事以外においても自分の関心範囲が増えるのだろうと思うので、来年振り返って、また言ってることが違う!ってなっていれば、走りきったと思えるのでしょう。

P.S. 今年もみなさまありがとうございました。

書評: パターン、Wiki、XP ~時を超えた創造の原則 がすごく面白かった

ソフトウェア設計とは何なんだというような話を社内でモヤモヤ話していました。

その話の流れで、@fuubitさんからアーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡というブログエントリを紹介していただいて、めちゃめちゃおもろいこれ!非常に興味深く読ませていただきました。

arclamp.hatenablog.com

すごく興味深かったので、ブログ冒頭で紹介されていた江渡 浩一郎さんのパターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)も「これおもしろい!」と当日の夜にさくさく読ませていただきました。(風呂で電子版を1時間弱読んで体内の水分がおしまいになりました)

こちらの書籍が非常に面白かったのでどのような内容が書かれていたか紹介したいと思います。

パターン、Wiki、XP ~時を超えた創造の原則

この書籍は大きく、3部立てになっています。

  1. 第1部 建築
  2. 第2部 ソフトウェア開発
  3. 第3部 Wiki

いきなりソフトウェア開発の話ではなく、建築の話から始まります。ソフトウェア開発のプロセスや設計は大きく建築の世界の概念が参考にされていると聞いたことがある方は多いかもしれません。この書籍では、建築家 クリストファー・アレグザンダー が追求してきた建築設計の理論・概念整理が、ソフトウェア開発で普段聞く概念にどのような影響をもたらしているかという話が展開されます。

パターン、Wiki、XP ~時を超えた創造の原則 という書籍タイトルで想像つくかもしれませんが、デザインパターンやXP(エクストリームプログラミング)といった概念が書籍で取り上げられます。

また、XPが誕生までの過程のなかで、オブジェクト指向についても取り上げられます。

個人的に面白かった点

クリストファー・アレグザンダーの考え方の移り変わり

クリストファー・アレグザンダー氏は、"パタン・ランゲージ"という概念を考えだした方ですが、理論を構築して実践・失敗、そこから学び実践、とされています。本書では、彼の思考の移り変わりを 6 章にわたり非常にわかり易く解説してくださっています。 その中で提唱される原則や設計についての考え方は、普段その影響を受けたソフトウェア開発の舞台にいる我々にとっては「はっもしやこれはあの概念につながっていくのでは!?」と謎解きをしていくような感覚を味あわせてくれました。

クリストファー・アレグザンダーの追求

クリストファー・アレグザンダー氏の追求したものが書籍内では、次のように書かれていました。

彼が建築において追及したいと思っていたのは、「何がものを美しくするのか」という原理でした。 江渡 浩一郎. パターン、Wiki、XP 時を超えた創造の原則 (WEB+DB PRESS plus) (Japanese Edition) (Kindle Locations 401-402). Kindle Edition

ソフトウェア設計について深く考え自分なりの理解・考えを突き詰めてらっしゃる方々を見ていると、(いい意味で)理想や美や調和のようなものへの探求みたいなことを感じていて、そういう姿勢に私はその方の"ソフトウェアエンジニアとしての深さ"を感じて尊敬しています。アレグザンダー氏の追求したものを読んで、「なるほどなぁ」と言葉にならない納得感を覚えました。

老練な親方と新前大工の仕事の進め方

アレグザンダー氏の書籍「パタン・ランゲージ―環境設計の手引」では、老練な親方と新前大工の仕事の進め方という例が出てくるのですが、これはソフトウェア開発においても同様に言えるなと思いました。

決定的な違いは仕事の手順である。老練な大工は、後で修正できないようなことはけっしてやらない。だからこそ、自信たっぷりと着実に仕事を進めていくのである。(中略)新前と親方との違いは、小さな過ちを吸収しながら建てていく方法を、新前がまだ修得していないだけのことである。親方のほうは、自分の作業を続けていれば、必ず後で過ちを修正できることを知っている。この単純かつ本質的な知恵があるからこそ、親方大工の仕事ぶりが、すばらしく、滑らかで、くつろいで、無頓着といってよいほどの単純作業に見えるのである。 江渡 浩一郎. パターン、Wiki、XP 時を超えた創造の原則 (WEB+DB PRESS plus) (Japanese Edition) (Kindle Locations 747-753). Kindle Edition

"老練な大工は、後で修正できないようなことはけっしてやらない"という一文に、そうだよなぁという気持ちになりました。

OOPSLA1996 での基調講演

OOPSLA(Object-Oriented Programming, Systems, Languages & Applications) 19961というオブジェクト指向プログラミングのシステム、言語、アプリケーションをシュダにしたカンファレンスで建築家のアレグザンダー氏が基調講演をされています

その中で次のような話がされたようです。

「生きた世界」(LivingWorld)はどのようにして生成され得るかという問題について扱いました。非常に興味深いことに、この問題は建築家や都市計画家ではなく、聴衆であるコンピュータ科学の領域に属する人々こそが答えを見つけることができるはずだ 江渡 浩一郎. パターン、Wiki、XP 時を超えた創造の原則 (WEB+DB PRESS plus) (Japanese Edition) (Kindle Locations 1990-1993). Kindle Edition

長い歴史のなかで、ひとつの答えを見つけるパスをコンピュータ科学の領域に呼びかけるという、学問はつながる瞬間があるのだなとぞわっとした感覚をもちました。

(主題の内容にはあまり触れなかった)

などと、主題を避けてピックアップしたところでも、各所で琴線に触れる内容で、とても面白かったです。

すごく人に伝えたかったので

第142回 PHP勉強会@東京で周辺の話もまとめた上でお話します。

ソフトウェア設計を少し学んでいる方々にとっては、「あの人がここに影響受けて、更にそれがあの人に繋がり、この概念にうぉぉぉ」という感動があります。まだ読んでないよ〜という方はぜひ読んでみてください!

外部イベント登壇しがち属性が考える登壇の使い方

TL;DR

  • 外部イベントを楽しむ・学びのきっかけにするための登壇の使い方
  • イベント運営の方々いつもほんとうにありがとうありがとう...

はじめに

社の飲み会などでカンファレンスに行ったり登壇したりすることの意味みたいなことがうっすら話題になり、各エンジニアの力量・フェーズによって"使い方"が変わるよなぁと思ったので考えをまとめてみます。

カンファレンスなどの外部イベントへ関わり始めたのは大学生のころからでした。大多数が職業エンジニアという属性の場に一人でいっていて、職業エンジニアになり数年経過した今でもいろいろなイベントに顔を出させていただいています。

そういった経過の中で、感じた登壇するとこういうことが良かったなとおもうことを書いてみようと思います。

目次

  • 外部イベントでの"交流を楽しくする"使い方
  • 外部イベント登壇をマイルストーンに置く"学びのペースメーカー"としての使い方
  • 思考の練度を上げる"きっかけ"としての使い方
  • 伝え方の練度を上げる"きっかけ"としての使い方

外部イベントでの"交流を楽しくする"使い方

カンファレンスなど初めて行く場で、その場で懇親会が始まったりすると、根本的に人見知りな私は話しかけるのに躊躇してしまいます。学生の頃は、「大学生なんです!」っていうと優しいおじさんたちが輪にいれてくれるといったことはあるのですが、職業エンジニアになるのと会話のフックが難しかったりしてさらに困難を極めます。

しかし、何かしらで登壇しておくと自分のセッションの聴講者の方々が大変ありがたいことに話しかけてくださったりします。
例えば、今年の6月29日に開催されたPHPカンファレンス福岡2019では、ユニットテストの現場の問題を原則に立ち返って考えるという内容の話をしたのですが、その後のAsk the Speakerや懇親会で、同じような課題感を持ってらっしゃる方々が集まってきていただいて、人見知りな私でも交流を楽しむことができました。

また、そういった交流の中で新しい気付きや課題を見つけることもあります。 例えば、Go Un ConferenceというイベントでGo API Validation error handlingという「みなさんどうしてますか?」という問いかけがほしい旨の内容を話すと、twitter上でそれに関する意見を貰えることができたりしました。

これは、聴講者として参加していただけでは得られなかった交流の仕方だなと思い感動を覚えました。

学びのペースメーカーとしての使い方

これについては、2018年のPHPカンファレンス2018でも次のようなLTをさせていただいていました。

俗に言う"発表駆動開発"というものでしょうか(本当に俗にいうかはわからないけどよく聞くので)。実際にこの効果はあって、普段業務では使ってないけど今後使っていきたい領域をカバーしたいというときに有用だと思います。
例えば、昨年のPHP勉強会でTerraformでAWSのインフラ構成構築を自動化する(入門)という発表をしました。この時の状況として、アプリケーションエンジニアなのでメインでTerraformを触るわけではないが、理解する必要があるし、少しずつクラウドやインフラ領域に対して自分の専門領域を広げていきたいと思っていました。そのために、雰囲気で見ている .tf ファイルを理解すべく発表をマイルストーンにおいてががっと勉強したという経緯があります。
このように、外部イベントで「その話ができるレベルにはなりたい」というマイルストーンをおいて、そこまで自分の能力を強制的に引き上げるというプロセスを私はよくやっていました。それの継続の末にいろいろな範囲をカバーできるようになってきた自分がいたりするので、負荷が高いやり方ですが眼の前の業務範囲に縛られないという状況を作りたい方にはおすすめな使い方だと思います。

逆に言うと、「その範囲は仕事の中で手が届くし、今やってないなら自分で仕事にしてしまえ!」くらいの能力・立場・心の力を持っているとこの使い方はあまり刺さらないメリットなのかもしれないと最近は思っています。

思考の練度を上げる"きっかけ"としての使い方

ソフトウェアエンジニアの"技術力"という言葉がどう定義でどう分類できるかというのは難しいですが、一つの要素として、実現するソフトウェアシステムに込められた 思考の深さ があるのではと思っています。
一つのクラスを作るなり機能を作るなりしても、その人が普段どれだけソフトウェア開発についての思考を巡らせていて、設計ノウハウ・知力をそこに込められているかは、結果的にメンテナンス性やパフォーマンス性といった別の指標で現れてくるのではと考えています。そういった意味で、さらに深いレベルで思考する、思考の練度を上げていくことは個人の能力に直結していくと思っています。

例えば、僕はユニットテストという一つのテーマでPHP系カンファレンスで何度か話しているのですが、それは毎回の発表時点ではまだ思考の練度が足りず話せなかったことをやろうとしています。カンファレンスを通して自分のソフトウェア開発に対する思考の練度を高めようとしています。

そういった形で自身のソフトウェア開発の造詣を深めるために登壇というきっかけを作るという事ができると思っています。

伝え方の練度を上げる"きっかけ"としての使い方

同僚のエンジニアのコードに対してレビューするといった機会や、同僚に対して何かしら働きかけを行いたいと思った際に、様々な伝え方があると思います。「俺のコードを読んでついてこい」というような職人タイプの引っ張り方もあれば、一から言葉とコード例で伝えていくという引っ張り方もあります。
職業エンジニアとしてそのソフトウェア・あるいはサービスに貢献する方法として、一個人としてのスキルの提供を通して貢献していくてもありますが、より再現性・レバレッジを利かせるのであれば自分以外も含めてチーム全体でどう成果物を出せるかというのは、大なり小なり重要な貢献の仕方です。 後者を考えると、「どう伝えるか」という点においていろいろな難しさがありますよね。普段から考えていないと「なんとなくこうしてる」といった見えない慣習的なことがあります。あるいは、自分のスタイルを人に伝達しようとした際に、そのメリット・デメリットを把握できているか、その人の状態で無理のないやり方に落とし込めるかという点が求められます。

そのような伝え方の練度をあげるために、一つ登壇して"アウトプットを残す"ということが有効かなと考えています。
たとえば、PHPカンファレンス仙台2019 にて、テストが辛いを解決するテスト駆動開発のアプローチという発表をしました。
これは、「このコードにテストを書くのがつらいんだがどうすればいいだろう」というコードの悩みを何度か現場で聞き、それに対して説明していたことをちゃんと筋道立てた形で資料にしたいとおもったことがきっかけでプロポーザルを出したものです。
このように、実際に現場で「あの人にどう伝えればいいだろう」というテーマをもとに発表内容を構成していくと、自分自身が実は意識していなかったことが言語化され、伝える際の参考資料も登壇を通して手に入れることができます。
多かれ少なかれ、誰かに対して働きかけを行ったり、自身の知っていること・身につけていることを伝搬する機会はあると思うので、そのようなことを考えることが多い方にはこういう使い方がおすすめなのではと思っています。

最後に

使い方という形で登壇に対して自分が思っている「使い方」を書いてみました。こういう雑な記事がかけるのも、普段カンファレンスやイベントを有志で運営していただいている方々のおかげです。この場を借りて皆様に深く感謝の意を申し上げます。
この記事では、「エンジニアとしての市場価値」などの観点は入れていません。実際、個人のコミュニティにおける注目度が上がることによって、所属している企業に興味を持ってもらうフックになるという意味での価値は一つあると思います。個人的には その価値に溺れてしまうと名実の実が著しく乖離してしまう状況になってしまう危惧があり、今回はあえて省略させていただきました。
アウトプットの一つとして登壇というものをどう使えそうかということをつらつらと書きましたが、登壇だけが全てではまったくなく、業務やOSSのコントリビュート・ブログ等様々なものを、それぞれ個人が使い分けていけばいいと思います。
一つの考え方として参考になれば幸いです