パンが主食

学んだことのアウトプット+ポエム

『Team Geek』を読んだ

目的意識

この本を読むに当たって、以下について新たな知見を得ることを目的とした。

  • 良いチーム作りの方法
  • 他人とうまくやるためのHack

1章 天才プログラマの神話

チーム内での合言葉

誰かに話しかけたいときは「ブレイクポイント、Mary」と言うのだ(Maryのところには話しかけたい相手の名前を入れる)。
(中略)
忙しかったら「ACK」と答えてくれるので、彼女の仕事が終わるまで他のことをして待つ。
(P.10)

とてもいい仕組みだと思う!ブレイクポイントの個所は優先度に応じて工夫の余地がありそう。

HRTを大切にする

謙虚(Humility)、尊敬(Respect)、信頼(Trust)。本書の内容が凝縮されていると思う。

2章 素晴らしいチーム文化を作る

内向的な人が秘めている力

本書で紹介されていた動画は以下。

スーザン・ケイン 「内向的な人が秘めている力」 | TED Talk

これを見てこの記事の内容を見直した。

wonda-tea-coffee.hatenablog.com

顔を合わせることは大切?

リモートワークをしていて遠方に済んでいても、チームメンバーと定期的に会いに行くべきだ、とあった。何となく同意しがちな感じがするが、その主張を支える根拠が欲しかった。

3章 船にはキャプテンが必要

内発的動機と外発的動機

  • 内発的動機・・・自発的に生まれるもの。
  • 外発的動機・・・外からの力で生まれるもの。

本書で紹介されていた動画は以下。

www.ted.com

この動画を見たのは2回目だが、やはり自分に必要ものは目的であると再確認。これについては仮ではあるものの設定しました。

wonda-tea-coffee.hatenablog.com

4章 有害な人に対処する

現状本書に取り上げられるような問題人物が身近にいないためかどれも響かず。

5章 組織的操作の技法

親切の経済

たとえ「返済」されなくても、誰かを手伝うと新しいことが学べるし、
そもそも誰かを助けるというのは気持ちがいい。
ちょっとした時間や労力以外に失うものなんてあるだろうか?
(P.137)

本当に心がけたい。今は自分のタスクで精一杯な場面が多いが、可能な限り誰かを手伝いたい。自分の質問に対して誰からも反応が無いのは辛い。自分がされて嫌なことを人にしてはいけない。

6章 ユーザーも人間

マーケティングユーザビリティ、顧客サービスについて取り挙げられていた。なんだか浮いた内容だと思ったが、これはユーザとうまくやるためのHackに入るのだと思う。

その他一言感想

  • 著者はLisper

総括

文量が少ないのは事実だったが、それを差し引いても自分の状況にそぐわない点が多く、全体的に響いた言葉が少なかった。とはいえHRTは大切にしたい。

言いづらさに押しつぶされないために

前置き

働いている人であれば職場の人に何かしら言いづらいことの1つや2つあると思う。言いづらいというのは精神的なハードルがあって言えないというケースを取り扱う。歯科矯正中で口内に矯正器具が入っている場合等は考慮しないものとする。

言いづらさの原因

思いつくがままに挙げてみるとする。

  • 相手の年齢が上である
    最もポピュラーな例ではないだろうか。職位が低くても相手の年齢が上であれば言いづらさが生まれがちな気がする。

  • 相手の社歴が長い
    これもありがちな気がする。もちろん会社の文化にもよるだろうが。

  • 相手の実務スキルが上である
    技術職であればこの傾向が強いのはないだろうか。

  • 相手の身体的要因に起因している
    上のどれに当てはまらずとも言いづらいことはあると思う。例えば、体臭が気になる、フケが散らばるなど。

どれもありがちだと思うし、共感してくれる人もいるのではないだろうか。
では何故これらが言いづらさに繋がるんだろう。それは恐らく言うことで自分あるいは相手が傷つくと思っているからではないだろうか。
勇気を振り絞って伝えたとしよう。もしかしたら相手の機嫌を損ねてまともな指導をしてくれなくなるかもしれない。その日を境にあからさまに態度が冷たくなるかもしれない。あるいは相手がショックを受けて辞めてしまうか、自分を声高に糾弾するかもしれない。

アイディア

あくまでも弊社で実践できそう、という基準で選定してみた。あくまでも会社にいながらにして何とかする方法を扱う。こんなんできねーよ!と思われた方がいたら大変申し訳無い。

  • 相談しやすい人に相談する
    何はともあれ吐き出すことが大切だと思う。私の短い人生経験のなかでも話すことで解決せずともスッキリすることが何度となくあった。同僚をランチに誘うも良し、SlackのDMで相談するも良し、家族、友人、何でも良い。大事なことは自分以外の人に認知してもらうことだと思う。対面で言える人間がいなければ、Yahoo知恵袋でも2chでも良い。それも憚られるならばアヒルのおもちゃに向かって話してみよう*1言語化することが大事なのだ。

  • 社内で匿名で悩みを投稿できる環境を設ける
    直接解決には結びつかないが、考える人は1人より2人がいいと思う。GoogleFormを使うのもいいだろう。これらを日次あるいは週次で取りまとめて議論をする時間を作る。ただ、相談内容が、見る人が見れば詳細(相談者など)が分かってしまい、かつ、取りまとめる側の人間が当事者だった場合が懸念される。

  • 気まずい時に押すボタン
    これを押して相手に察してもらい改善を求める。ふざけているわけではない。

イメージ図)

f:id:wonda_tea_coffee:20181209095946j:plain
気まずい時に押すボタン

  • ポストイットで伝える
    こういったものをおもむろに相手のデスクに貼る。繰り返し言うがふざけているわけではない。

f:id:wonda_tea_coffee:20181209101645j:plain
ローテンションな先輩へ


(追記)
何も元気を出さなくてもHRTを大切にすることはできるはずなので、このメッセージは間柄によっては適切ではないと思う。おそらくはローテンション+@があるから不快なのではないだろうか。例えば、

  • 話かけてもこちらを見ない
  • 声が聞き取りづらい
  • 不機嫌そうなトーン
  • しかめっ面

話かけて欲しくない場合はチーム内で合図などを決めると良いと思う。

参考

wonda-tea-coffee.hatenablog.com

いつもそんな態度である場合は、「声が小さくて聞き取りづらいです」「何か気に障ることをしましたか?」などのメッセージが良いだろうか。何にせよ何か嫌なことがあるならば口に出して欲しいものだ。


※直近の2つは会社やチーム単位で奨励 or 承認されていれば尚良し

  • 自分の精神構造を作り変える
    これは自分が傷つくから言えない場合に有効だと思う。そもそも相手に言動を受けて自分のフィルターを通り、それに反応することで不快感が生まれる。ならばそのフィルターを作り変えようというソリューションである。具体的には原始仏教のエッセンスを取り入れることを勧める。信仰せよと言っているわけではない。苦しみ生きた人間・釈迦からヒントを貰おうという態度であればいいと思う。詳細は何かしらの書籍を買い求めよう。

  • 異動を申し出る
    会社として解決に動いてくれず、以前として特定の人間に悩まされる場合、その人から遠ざかることを勧める。君子危うきに近寄らず。申し出る際はもっともらしい理由を捏造するか、それが厳しそうなら正直に伝えよう。

  • 退職する
    最終手段である。これも叶わなければ退職するよりないのではないだろうか。数々の工夫にも関わらずどうしようもなければ、最早そんな会社にしがみつく必要があるだろうか。強調するが退職しても死なないので安心してほしい。私のように汚らしい職歴になるかもしれないが死ぬよりはいいのではないだろうか。健康でさえあれば次の職場もきっと見つかる。

終わりに

私自身、目に見えぬ誰かのために何かをする、ということにモチベーションを感じづらい。自分の身近な人間が悩んでいるということに対しては何とかしたいと思う。というのも自分自身過去の職場でさんざん嫌な思いをしたため、少なからずそういった辛さは分かるつもりでいる。地球上のすべての人を救いたいとは思わないが、少なくとも自分の勘即範囲にいる人間には幸せでいてほしいと思う。

『ファシリテーション入門<第2版>』を読んだ

はじめに

私は現在社内の小さな読書会のファシリテーターを務めています。と思ったのですが、この本を読んで、私がやっていたことはファシリテーションではないということが分かりました。私はただの司会者だったようです。いやそもそも司会進行すらできていませんでした。そんな現状を社内1on1でマネージャに相談したところ、この本を勧められて読み始めた次第です。以下印象に残った個所と感想を書いていきます。

ゆでガエル

本書の冒頭にこのような文章がありました。

自分も問題の一部であると認め、なにかの行動を起こさないといけません。
少しずつ温度が上がる湯から出られずに死んでしまう、「ゆでガエル」になってしまいます。
(P.4)

このゆでガエルという言葉、達人プログラマにも出てきました。

wonda-tea-coffee.hatenablog.com

何かポピュラーな表現なのかと調べてみると、どうやらビジネスの世界において警句として使われていそうな雰囲気を感じました。また、実際にカエルは湯の温度を上げていくとちゃんと逃げていくとか・・・。*1

第1章 協働を促進するファシリテーションの技術

本書で一番印象に残った文章

あまり引用しすぎると自分の言葉が無くなりそうだと懸念していますが、この文章はそのまま紹介したいです。

群れをつくり生活する人間は、常に人と人との相互作用のなかで生きています。
今この状況のなかで考え振る舞っているのが自分である、なにが本当の自分なのか、本人もよく分かりません。
個が相互作用をつくると同時に、相互作用が個をつくるからです。
(P.22)

きっと自分がその時置かれている環境次第で、響く言葉は変わってくるように思います。転職してまだ間もない今だからこそ響くものがあったのかもしれません。これを踏まえると本当の自分というものは無いのではないでしょうか。このコミュニティにいる自分といった具合に考えるのがいいかもしれません。

ファシリテーターは司会者ではない

これまでファシリテーターという言葉について、何か司会進行的なものなんだろうなーと思っていましたが、全く違いました。と同時に今の私が読むべき本ではないと思いました。とはいえ結果的に大きな学びがあったので読んで良かったです。

第2章 発展するファシリテーションの応用分野

デザイン思考

異分野の本を手にとったつもりが思わぬ形でまたこの言葉を見ることになりました。確かにデザイン思考のなかでもファシリテーションの技術は生きそうです。

wonda-tea-coffee.hatenablog.com

第3章 場のデザインスキルー場をつくり、つなげる

場をデザインする五つの要素

  • 目的(何のために議論するのか)
  • 目標(何を決めるのか、終了条件)
  • 手順(議題)
  • 行動規範(グラウンドルール)
  • 役割分担(5~6人が最適)

関連する原理・法則

めっちゃ多いな。

小グループに分ける

人数が多い場合こういった方法も有効なようです。そう突飛な発想ではないと思うのですが、集まった全員で話をするという発想しかなかったため個人的には目からウロコでした。

心理的安全性

ファシリテーターが重視すべき概念。とても好きな概念です。この言葉でググるGoogleについて出てくるところを見ると、先駆者がGoogleなのでしょうか?『Team Geek』に載っていそう。

第4章 対人関係のスキルー受け止め、引き出す

「自分が貢献できないときは退出する」というルール

このルールを実践している企業があるそうです。笑いました。最近自分の貢献度が限りなく低い会議に出たせいかとても印象に残りました。ただどうなんでしょう。必ずしも貢献するために会議に出席するわけでもないと思いますし・・・。

誰が言ったかではなく何を言ったか

確か釈迦もこういうことを言ったように記憶しています(要出典)。ただ、こと技術の話においては、自分の知識が浅い場合なおさら誰が言ったかで見方を変えてしまいます。

コンテクスト

自分はこう言ったつもりだったのに、相手はこう解釈していた。ありがちですよね。私は前職である事柄について「規模感を調査してくれ」と言われ、まず規模感という言葉から調べました。よく分かりませんでした。

聞くのではなく、聴く

こういう言葉の違い、ややこしくはありますが結構好きです。

  • 聞く・・・自然に耳に入ってくる。受動的。
  • 聴く・・・注意深く身を入れて耳を傾ける。能動的。

仕事においては多くの場合聴くことが大切ということが分かりますね。
また、聴くに当たっては体を向けることも大切だと思います。(相手と会話する同意が成り立った上で)自分が話してる時に、相手がPCに向かっていたら良い気分にはなりません。故に自分がされて嫌なことを人にしないよう気をつけなければなりません。

リアクションで相手を承認する

目線や相槌、大切です。
本書の趣旨とは異なりますが、リモートワークをしている際は意識してSlackでメンバーからの呼びかけがあった際はスタンプを押して「見たよ!」「OK!」などの意思表示を積極的にするように心がけています。余談ですがリモートワークに関しては別途1つ記事を書きたいような気がしてきました。

人はアクションでモチベートされる

「行動はすぐ後の状況の変化によって決まる」とする行動分析の考え方。大変興味深いです。自分よりスキルが低いメンバーと接していく際は、行動分析についてよく学びたいです。

第5章 構造化のスキルーかみ合わせ、整理する

感想がないあたり、読む動機が少し本流からずれていたんですね。
ただ、意思決定の支援としてのフレームワークの存在が分かったのは大きいです。必要に迫られた時に再度本章を読み返すとします。

第6章 合意形成のスキルーまとめて、分かち合う

決め方を決める

私自身、最近何かにつけて自由に行える意思決定が苦手で辛かったのですが、決め方を決めると良い具合に決まっていくことが分かりました。直近の例だと、社内で書くことになったアドベントカレンダーの記事のネタが決まらず苦しんでいたのですが、以下の手順で解決できました。

1. 自分が少しでも知っていることについてとりあえず3つ絞り出す  
  (以下、出した順に案0, 案1, 案2とする)    
2. 今日の日付(年月日)を整数とみた時の各桁の和を3で割った余り(以下nとする)を計算する  
3. 案nに決定する

これを大項目、中項目と細分化していくと自ずとやるべきことが定まっていきました。とても気に入っているので(特に工程2)、しばらく運用してみようと思います。

第7章 ファシリテーションの実践に向けて

感想がないあたり(略)

その他一言感想

  • ファシリテーターとしてというかヒューマンスキルの面で勉強になった
  • 意思決定の支援という観点では、1人考える時においても生かせる点が多いように感じた
  • プログラミング以外にもたくさんのフレームワークがあることが知れた
  • 不慣れな分野ではフレームワークがないか探してみる
  • 巻末のブックガイドが豊富なため、この本で興味を持った諸分野に入門しやすい
  • ファシリテーションをすることになったら再度読み返そう

NEXT

ありたい姿(仮)

自分が何を学ぶべきか迷うのは、ありたいという姿を定義できていないためと思われる。
今回それを解決すべく一旦ありたい姿を定めることにした。こう書くとそこに向ける思いが感じられない気がするが、個人的には楽しんでできる気がしている。

今やっているタスクを最速かつ最高のクオリティで仕上げる

一旦こうすることにした。理由は以下の通り。

  • 明確である
  • 集中した時間は楽しい
  • 学ぶべき内容が定まりやすい

具体的には現在やっているタスクが「HTMLメールの作成」であれば、HTMLメール作成をいかにより速くより良くできるかについて退勤後、休日の時間を最大限に使う。技術に関するタスクであれば、掘り下げることに終わりはないはず。

  • この設計、実装でいいのか→設計やリファクタリングの本を読む
  • 何故この方法が成り立つのか→Web、メーラー、HTMLに関する本を読む

などなど・・・。

課題

これだと自分が担当のタスクにしか意識が向かない気がしている。これは運用しつつも、他メンバーのコードレビュー、デザインへの関わりについても考えていきたい。目標設定も見直さねば・・・。

『達人プログラマー』を読んだ

読みました。
印象深かったところなどを書き残します。

技術書以外の書籍を読む

とてもタイムリーに感じました。このところ、技術面以外でも課題が浮き彫りになっているので、何冊か技術書以外の書籍に手を出しました。

そのうちの1冊↓

wonda-tea-coffee.hatenablog.com

技術一辺倒だと人間との接し方を疎かにしてしまうと思いますし、逆もまた然りだと思います。 何事も中庸が大事ということで、技術面も高めつつ人との関わりについても学んでいきたいです。

設計やアーキテクチャの本を読みましょう

やっぱりな〜ということが書いてありました。メトロノームの下の部分ですよね。読みます。関連が深い記事↓

www.huffingtonpost.jp

この記事が好きすぎて10000回くらい読んでます。

DDDとのつながり

ただ我々であれば手始めに、アプリケーションからインフラ部分を切り出すという手をよく使います。
(P.42)
ユーザーと開発者が同じものを表す際に異なった名前を使ったり、
さらに悪いのは異なったものを表す際に同じ名前を使うような場合、
プロジェクトの成功が非常に難しいものとなるのです。
(P.236)

リポジトリユビキタス言語 ー DDDに通じるものを感じます。

また、アスペクト指向プログラミング(以下AOP)という用語が登場しました。本書いわく、

AOPでは、一ヶ所で定義した動作がソースコード獣の適切な場所に配置されます。
(P.45)

ナンノコッチャよく分かりません。Spring Frameworkにも取り入れられているそうなので、今後触れる機会がありそうです。そういえば『実践ドメイン駆動設計』や『オブジェクト指向でなぜ作るのか』にも出てきました。どうもオブジェクト指向の弱みを克服した概念らしいのですが、広い普及には至っていないようです。

プロトタイプと曳光弾

プロトタイプは何となく知っていましたが、曳光弾は初めて知りました。本書の言葉を用いてそれぞれの特徴をまとめます。

プロトタイプ

  • システムの最終形態に対する理解を検証するためのもの
  • 役目を終えたら破棄する
  • 曳光弾を発射する前に開始する偵察、諜報活動

曳光弾

  • アプリケーション全体がどのように連携するのかを知りたい場合に適用するもの
  • 破棄せずに残す

曳光弾はアプリケーションの骨組みって感じでしょうか。

仕事に誇りを持つということ

本書にも登場しましたし、弊社の企業理念にも明記してあります。これって言葉自体は馴染みのあるものなのですが、いざ考えてみるとよく分からなかったです。そういうわけで弊社の親切な方にインタビューできることになったので明日聞いてきます。to be continued...

あとでやる

魅力的な演習問題が多く載っていました。しかし、これを始めると多くのことが後手に回ってしまいますので、ここに書き残しておきます。必ずや・・・。

  • 72~73
  • 115
  • 120
  • 142(20)
  • 185
  • 206
  • 212
  • 222

その他一言感想たち

  • Emacs推しで笑う
  • C, C++で書かれた部分よく分からなかった
  • リファクタリングの本も読みたいな〜
  • シェル書けるようになりたい!
  • 仕事に迷ったら付録Cを読み返したい

総括

正直まだ読むのが早かったかな、とも感じています。もちろん学びが多かったのは事実ですが、経験不足のためイマイチぴんとこない個所も多々ありました。開発経験を積んでからまた読み返すとまた違う学びがあるように思います。そういうわけでこの半期が終わってからまた読んでみます。

NEXT

ファシリテーション入門』

『デザイン思考が世界を変える』を読んだ

会社の人が「名著です!」と仰っていたので読んでみました。
ざっと1周しただけなので我ながら浅い感想・・・。

デザイン思考について

素早くプロトタイプを作って検証して〜というプロセスが似てるのかな?と感じました。

  • 業界を問わないスキル

人間を相手にする仕事のすべてにおいて有用なスキルなんだなーと感じました。
身につけたいものですね。ただ私の場合人への共感という部分が壊滅しているような気がするので難ありです。共感、提案ができる人でありたい!

(追記@2018/12/8)
デザイン思考はスキルではなく手段のようでした。

  • 人間中心設計という言葉

本書で何度も出てきたこの言葉。
実践に当たってはまず人間に興味を持たないといけないですよね。
そして興味を持った上で理解、共感が必要なんだと解釈しました。

ただこれって相当難しいことですよね。
そもそも人の気持ちは分かりません。何なら私の場合自分の気持ちもよく分かりません。
まずは特殊な場合、自分中心設計から始めようかと思います。 それが何なのか分かりませんが。

思わぬ効果

  • 関心が生まれたことで共通の話題が生まれた

私の身近にデザイナーがいるんですが、共通の話題ができました。
この本の感想を話す中でアパレルにおけるデザイン思考の話、業界を取り巻く社会問題などいろいろな話が聞けました。 これ単体でながーい文章になりそうなのでまたの機会に・・・。

興味惹かれた言葉

これらはこれ単体で掘り下げてみたい感じある。

残る疑問

  • 垣根を超える

とても良さそうな響きではあったのですが、これはどういう状態なのかIDEOの人々の様子をもっと詳しく知りたかった。 また、越境と同じ意味合いで良いんでしょうか。 これについては別の類の本を読む必要がありそうですね。 なんとなく『エンジニアリング組織論への招待』という本が気になっています。次なる読み物枠にします。

総括

  • IDEOのような会社があるという事実に驚いた
  • UXをデザインする、ということの理解が少し深まった気がする
  • 名著だったかどうか自問してみると、そうは感じていない  → そう判断するにも相応の能力が必要ということ・・・
  • とはいえ、思わぬ効果もあった上、デザイン思考に入門できた感があるのでとても良かったと思う

NEXT

  • 『達人プログラマ
  • ティム・ブラウン氏のTEDの動画をいくつか見つけたので後で見てみよ
  • デザイン思考のワークショップみたいなのあれば行ってみようかな・・・

『Re:ゼロから学ぶReactNative入門』を読んだ

新たな知見、感想をまとめます。

1章

エモい

2章

  • ECMAScriptJavaScriptの中核使用を抜き出して標準化したもの

  • ReactNativeは大規模アプリに向かないらしい。何をもって大規模なんだろう・・・。弊社プロダクトは小規模?

  • ExpoはReactNativeの開発支援ツール。ネイティブのビルド処理をよしなにしてくれる。プロトタイプ向け。

3章

  • react-native run-iosでこけた。XCodeの設定が足りていなかったよう。これを見て解決。

stackoverflow.com

  • command + Dのメニューからホットリロードをオンにできる!!!!!!良い!!!!!!!!  VSCodeで自動保存してるとタイプするたびに反映されるので楽しすぎる。

  • そういえば弊社ではiosシミュレータを立ち上げるまでに、コマンドを3回ほど叩いた記憶が・・・。1度で済まないんだろうか。  そもそもそれぞれ何をしているのかよく分からない。

4章

  • アプリ実行時はルートのApp.jsが動く

  • 変数、定数の宣言は3つあれど、constを使うべし。varだけはダメだ

  • Platform.selectでOSごとに処理を分けられる。

  • コンポーネントのreturnでnullが評価されると何も表示されない。

  • render内に複雑な分岐を設けるのはやめよ。

  • propsは親から子へコンポーネント間で渡される書き換え不可能なデータ。  試しにHoge.jsで代入してみたら変わっていなかった。つまり試みてもエラーにはならないけど、書き換わりはしない。

  • stateはコンポーネント内の状態を管理するデータ。

  • stateはconstructorで初期化し、setStateを使って変更する。 子クラスでのpropsの操作同様、変更を試みてもエラーにはならないけど、書き換わりはしない。

  • constructorでは先頭でsuper(props)を呼ぶのがお約束。 忘れると、this.stateが評価された際にundefined is not an object。 this.stateもないと子クラス呼び出し個所にてReference: this hasn't been initialised super() hasn't been called

  • ButtonのimportとgetTextが文中にないので初学者戸惑う・・・

  • コンポーネントから親コンポーネントへの情報の受け渡しはコールバックを使う。 あれ、、?bindしなくてもエラーにならないぞ・・・ 文中でもgithubのコードでもbindしてる様子はない。

  • async/await、この例だけでは何が何やら・・・

  • background-colorみたいな形式ってケバブケースって言うの・・・

5章

特になし。

6章

  • 同じハマり方をするもnpm startからのreact-native run-iosで復活

stackoverflow.com

  • Stack Navigatorのところでエラー。バージョンによる違いの模様。こちらを見て解決。

qiita.com

  • list型のstateを更新する際は、オブジェクトのコピーを渡す
こうしたり
this.setState({ todoList: todoList.map(item => item) });

こうやったり
this.setState({ todoList: Object.assign([], todoList) });
  • keyは文字列としてAddTodoScreen.jsに渡しているが数値でも問題なし、何ならkeyは全ての個所において数値で扱えた。

モヤモヤ

  • async、awaitの使い方、まだまだわからぬ

  • 時折HotReloadingをONにしていても反映されなかった気がする

総括

やはり書くのが一番というわけで何度か写経した後、何も見ないで作るという工程を3〜4回ほど繰り返した。 不思議なもので何度か何も見ないで書けると完全に理解した気になれた。

github.com

NEXT

  • 『達人プログラマ

  • 『デザイン指向は世界を変える』