potatotips #39 で fastlane android について話した

potatotips.connpass.com

最近業務で android も fastlane に乗せたので、 android 枠で話した。
fastlane android 良いと思う、継続的デリバるためのやつだからダメになったら捨てればいい、という軽い気持ちでいけるし。

発表では、たぶん自分はせわしなく話していて、他の人の発表見て「みんな落ち着いててすごいな〜」って思って見てた。
次話すときは資料の枚数もっと減らしてもっとゆっくり話すようにしてみようと思う。

「遅読家のための読書術」を読んだ

遅読家のための読書術

遅読家のための読書術

自分は本を読むのが遅く、さらに理解度が低いというつらい感じなので、そこらへんをなんとかしたいと思ってこの本を手にとってみた。

「本を読むのが遅い人は無駄に頑張って読みすぎなので、音楽を聴くようにもっと気軽に本を読んで、1行でも心に残る文章があったらそれで良いんだぞ」みたいな内容だった。あと見出しで判断して違うと思ったら読まなくて良いんだぞ、とか。

無駄に頑張って本を読みすぎというのは心当たりがあるのだが、見出しレベルで判断するというのはする気になれない…それが遅読の原因なのかもしれないが。

言っていることはわかるのだが、あなたはそう考える人なんですね、という感じで自分にはあまりためにならない本だった。

というかそもそもこの本は内容が薄く、1/3くらいでかける内容を冗長に書いている感じがして、遅読家向けの本なのに内容が薄く長いというのはどうなんだ。
遅読の人が読むんだからもっとページ数少なくするべきでは。わざと冗長に書くことで読み飛ばすことを実践させるという高度な内容になっているのかもしれない、などと思いながら読んでいた。

本を読んだ後に「もっとも素晴らしいと思った引用を1つだけ選ぶようにしよう」とあったので、1つだけ引用する。

「なにか」が頭の片隅に残っているのだとすれば、少なくともその部分が自分にとって必要だということ。
その本から得られる価値の全てはまさにそこにあり、1冊を読み通したことの意味は、その一節に出会えたことにある

以下雑なまとめ。


  • 本はそんなに真剣に読むな、音楽聴くみたいに雑に流せ
    • フローリーディング
  • 1冊に1フレーズでも心に残るものに出会えればいい
  • 100%を得ようとするな価値を感じられる1%と出会え
  • 引用することでその本のどこに心を動かされたか可視化される
  • もっとも素晴らしいと思った引用を1つ選ぶ
  • 12冊ごとに振り返りをし、その中からベストの1冊を選ぶ
  • 小見出しをみて読むべきパートか判断する
  • 自分語りは読み飛ばせ、まとめだけ読めばいい
    • この本かなり自分語りあったな?
  • 本を気軽に読み始められないのは、その本から何を得たいかがはっきりしていないからでは?
  • マーカー引くのは良くない
  • 電子書籍より紙の方が良い(筆者の意見

「プログラムはなぜ動くのか」を読んだ

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムを書き始めて5年ほど経つが、今までずっと「何かアプリケーションを作る」という目的のためだけにソフトウェアを作ってきて、それゆえに低レイヤで何が起きているのか全然知らなかった。
プログラムを書くのにコンパイラが何をしているのかわからんのもよくないので、そこらへんを知りたくて読み始めた。

CPU から2進数、メモリ、コンパイラ、OS、アセンブラと今まで避けてきたことが色々書いてあった。

特にコンパイラアセンブラの章がよかった。
コンパイラは色々ゴニョゴニョっとライブラリ入れたりスタティックライブラリ使ったりとかしてやっと exe ファイルができるらしい。
アセンブリ言語も mov とかでチョチョっと書ける、逆アセンブルというのはマシン語アセンブリ言語に逆変換することだったのか、それすら知らなかった。

2進数とかってどうなんだろうか、どの程度まで理解していた方が良いのだろうか。あの 1001010101 みたいな数字が苦手で、 2進数を10進数に計算するのもろくにできない。
でもそれで困ったことがないと感じてて、それは私のレベルが低いから困ったことがないだけで他の人は2進数の理解によりメリットを感じているのだろうか。

本の内容としてはためになったけど、この本を読む前とあとで自分の書くコードは変わらないのかな、とも思う。
コンパイラを理解しているとデバッグがしやすいとか書いてあったけど、果たして iOS の Swift などでそれが役に立つことがあるのだろうか…。
自分の理解度が低いのか、時代に即していないのか、果たして。

とはいえ、ためになるいい本でした、終わり。

以下 wikihub 日報 のまとめ。


読み始めた。いつだかに買ったけど積んでたやつ。 ソフトウェアは書けるけどなぜ動くかわかっていないのでためになる気がする。 1章読んだけど全然わからんかった、パソコンは難しい。

  • レジスタ
    • 命令やデータを格納する領域でメモリみたいなもんらしい
  • 制御装置
    • メモリ上の命令やデータをレジスタに読み出し、命令の実行結果に応じてコンピュータを制御するらしい
  • 演算装置
    • メモリからレジスタに読み出されたデータを演算するらしい
  • クロック
    • CPU が動作するタイミングとなるクロック信号を発生させるもんらしい
    • クロックは大きければ大きいほど CPU は早い
  • みなさんが書いたコードがマシン語となり CPU の内部でレジスタを使った処理結果になるらしい
  • コール命令やリターン命令で関数を実行したりするらしい
  • この本を読むと今まで何気なく書いていたプログラムがこれからは生きたものに見えてくるようになるとのこと

備忘録として書いてたらめっちゃ長くなった。

2章 データを2進数でイメージしよう

2進数めっちゃ苦手だ。というか知らなくてもプログラム書けないですか?

  • ビット
    • 2進数の1桁に相当する
  • バイト
    • 8桁の2進数
  • 基数
    • 数の数え方、10進数は10を基数、2進数は2が基数
  • シフト演算
    • 2進数で表された数値の桁を左右にシフトする
    • シフト演算や論理演算の仕組みをイメージできることは 必ず 身につけておかなければならないこと
      • まじ?
  • 符号ビット
    • 0の場合はプラスで1はマイナス
  • 補数
    • プラスの値でマイナスの値を表す
    • 「反転して +`1」で補数を求める
  • 論理右シフト
    • シフト後の上位桁に0を入れる
  • 算術右シフト
    • シフト前の符号ビットの値を入れる?
  • 符号拡張
    • 例えば8桁の2進数を、値を変えずに16桁や32桁の2進数に変換すること
  • 算術演算
  • 論理演算
    • NOT,AND,OR,XOR など
  • 真理値表
    • 2進数の0がfalseで1がtrue

3章 コンピュータが少数点数の計算を間違える理由

計算とかだいたい Math.floor とかしちゃうから気にならないくないですか?

  • 0.1 を 100 回加えても10にならない
  • 10進数の小数点の中には、2進数に変換できないものがある
  • 正確に表せない数は近似値になってしまう
  • 倍精度浮動小数点型
    • 64 bit の double
  • 短精度浮動小数点型
    • 32 bit の float
  • 浮動小数点では、少数点数を「符号」「仮数」「基数」「指数」の4つに分ける
  • 符号部
    • 1bit を使って数値の符号を表す、0は負で1は正
  • 仮数
    • 様々な形式で表せる浮動小数点型を糖質的な表現にする
  • 指数部
    • イクセス表現を使う。
    • 中央の値をゼロと見做すことでマイナスの値を表す工夫、トランプでいうと7を中心とし6以下はマイナスみたいな

4章 四角いメモリーを丸く使う

メモリに関しての内容。
C言語も書いたことないしポインタとか概念としてしか理解してない。

  • 制御信号
    • WR(write), RD(read) のように IC に動作を行わせる信号
  • メモリの物理的な仕組み
    • モリーIC の内部に8ビットデータを格納できる入れ物がたくさんあり、その場所をアドレスで指定してデータの読み書きを行うだけ
  • データ型
    • どのような種類のデータを格納するか示すもので、メモリからすると占有するサイズを意味するもの
  • 変数を使うことで物理アドレスを指定しなくてもプログラムでメモリの読み書きが可能
  • ポインタ
    • データの値そのものでなく、データが格納されているメモリーのアドレスを持つ変数
    • 参照型って理解でいいのかな?
  • 配列
    • 同じデータ型の複数のデータがメモリ内に連続して並んだもの
  • スタック/キュー
    • どちらもアドレスやインデックスを指定せずに配列の要素を読み書きできるもの
  • スタック
    • LIFO = Last In First Out
  • キュー
    • FIFO = First In First Out
  • リスト
    • データの値だけでなく、次の要素のインデックスも付加できる
    • リストでない配列を使うと、途中の要素を消した時に後ろの要素を全て移動しないといけない

ためになる!

5章 メモリーとディスクの親密な関係

メモリとディスク(HDDとかフロッピーとか)について。

  • ストアド・プログラム方式
    • プログラムが記憶装置に格納されていて順次読み出されて実行される仕組み
    • この方式の前はコンピュータの配線を変えてプログラムを変更してていたらしい
  • ディスクキャッシュ
    • 一度ディスクから読み出されたデータを保存しておくメモリ内領域
  • 仮想記憶
    • ディスクの一部を仮想敵にメモリとして使うもの
    • 物理メモリと仮想メモリスワップしながらプログラムを実行する
  • ページング方式
    • 実行されるプログラムを構造に関係なく一定の「ページ」の大きさに分割する
    • ページイン、ページアウトとかいう
  • ページングファイル
    • 仮想記憶を実現するためにデゥスク状に仮想メモリとなるファイルをおく
  • スタティックリンク
    • アプリケーションの実行ファイルの中に関数を埋め込むこと
    • これをやると同じコードが複数アプリケーションに存在することになり微妙っぽい
  • スタックのクリーンアップ処理
    • 関数の引数を受け渡すために使われるメモリ状のスタック領域から不要となったデータを削除すること
    • 関数の前に _stdcall をおく
  • ディスク
  • セクター方式
    • 固定長の領域に区切る
    • ディスクの表面を同心円状に区切った領域をトラックと呼び、それを固定長サイズに区切った領域をセクターと呼ぶ
    • 複数のファイルを1つのクラスタに格納はできない、両方削除されちゃう
  • バリアブル方式
    • 可変長の領域に区切る

6章 自分でデータを圧縮してみよう

zip とかの仕組みが書いてあって面白い。

  • ランレングス法
    • ファイルの内容をデータ*繰り返し回数で表すことで圧縮する方法
    • 同じデータが続いている場合が多い画像ファイルなどでは有効打が文書ファイルではあまり…
  • ハフマン法
    • よく使われるデータを判別して、それを小さいbit数で表す
    • ハフマン木とか使う
  • BMP
    • bitmap は圧縮していないやつ
  • 可逆圧縮
    • 元に戻せる、zipとか
  • 非可逆圧縮
    • 元に戻せない、jpeg とか

7章 プログラムはどんな環境で動くのか

戦うプログラマーでいろんな環境で動くように作るみたいな話をしていたやつだった。

  • ネイティブコード
  • ソースコード
    • テキストファイルで書かれたやつ
  • アプリケーションの機能の中に、ハードウェアを直で触るところがあると汎用プログラムにならない
  • API
    • Application Programming Inteface
  • Ports
  • Java
  • JVM
  • BIOS
    • ROM に記憶され、キーボードとかの基本制御プログラムやブートストラップ・ローダーをもつ
  • ブーとストラップ・ローダー
    • 起動ドライブの先頭領域に記憶された小さなプログラム
    • OS はブーとストラップ・ローダーによって起動する

8章 ソース・ファイルから実行可能ファイルができるまで

コンパイラとかのはなし。
知らないことばっかりだ。

  • ダンプ
    • ファイルの内容を1バイトずつ2桁の16進数で表示すること
  • ロスコンパイラ
    • 動作環境で使われる CPU とは異なる CPU 用のマシン語を生成
  • オブジェクトファイル
    • コンパイルした後に生成される .obj 形式のファイル
    • まだ exe ファイルではない
    • printf() など実行する場合は必要な処理内容が格納された状態に結合しないといけない
  • リンク
    • 複数のオブジェクトファイルを結合して1つのexeファイルを作る処理
    • リンクを行うプログラムのことをリンカーという
  • スタートアップ
    • 全てのプログラムの先頭に結合する共通的な処理が書かれたオブジェクトファイル
  • ライブラリファイル
    • 複数オブジェクトファイルをまとめて1つのファオルに格納したもの
  • 外部シンボル
    • 他のオブジェクトファイルの中にある変数や関数
    • printf() とか
  • 標準関数
    • ライブラリファイルの形式でコンパイラと一緒に提供される
  • DLL
    • Dynamic Link Library、プログラムの実行時に結合されるもの
  • インポートライブラリ
    • 外部にあるライブラリファイル
  • スタティックリンクライブラリ
    • exe ファイルに直接結合するライブラリファイル
  • 再配置情報
    • 実行時にメモリを仮想敵に与えてうまく動くようにするやつ
  • スタック
    • 関数の内部で一時的に使用される変数などのメモリ領域
    • 自動でメモリを確保し自動で解放
  • ヒープ
    • プログラムの実行時に任意のデータやオブジェクトを格納するためのメモリ領域
    • 自分でメモリを解放する

コンパイラはこんな感じの処理になるっぽい。

ソースファイル
-> .obj + タートアップ + スタティックリンクライブラリ + インポートライブラリ
-> スタティックリンク + ダイナミックリンクライブラリ
-> exe


読み終わった。

9章 OS とアプリケーションの関係

  • モニター・プログラム
    • プログラムをロード・実行する機能だけを備えるやつ
  • OS 上で動くアプリはハードウェアを OS を介し間接的にアクセスする
  • システムコール
    • OS の関数とかを呼び出す行為
  • 時分割
    • 短い時間間各区で複数のプログラムを切り替えながら実行する
  • マルチスレッド
    • 関数の単位で時分割を行う
  • ミドルウェア
    • ネットワークやデータベース機能のような、OSには不可欠でないがOSに近い存在のこと
  • システム・ソフトウェア
  • フラグ&プレイ
    • 新しいデバイスをすぐに使えるようにする仕組み
  • バイス・ドライバ
    • 新しいデバイスを接続した時にそれを制御するプログラム

10章 アセンブリ言語からプログラムの本当の姿を知る

この本で一番ためになる章だったと思う。
コードがコンパイルされ、それがどうコンピュータに読まれるかみたいなのを順を追って解説してくれる。

11章 ハードウェアを制御する方法

  • システムコールを使いアプリケーションからハードウェアを制御する
  • IN命令
    • 指定したポート番号のポートからデータを入手する
  • OUT命令
    • CPU のレジスタに格納されているデータを指定しポート番号のポートに出力
  • I/Oコントローラ
    • コンピュータ本体と周辺装置をいい感じに繋ぐやつ?
  • ポート
    • 入出力されるデータを一時的に格納しておくための一種のメモリ
    • えっポートってメモリなの、マジで
    • ポートって行っても https:443 みたいなポートとか USB ポートとか色々あるし何がどれなんだ
  • ポート番号
    • I/Oアドレスとも呼ぶ。ポートを区別するやつ。
  • IRQ
    • Interrupt Request, 割り込み要求
  • 割り込み処理
    • 現在実行中のプログラムを一旦止めて他のを実行する
    • 割り込み番号が振られる
    • 割り込みコントローラが間にいる
  • ポーリング
    • 複数の周辺装置の状態を順番に調べること。パソコンには不向き
  • DMA
    • CPU を仲介せずに周辺装置が直接コンピュータのメインメモリとデータ転送をおこなう
    • DMAチャネル
  • I/Oポート番号、IRQ、DMAチャネルは周辺装置を識別するための3点セット
  • VRAM
    • ディスプレイに表示される情報を記憶するメモリ

12章 コンピュータに「考え」させるためには

プログラムに人間の傾向とかを学ばせるみたいな話。
ディープラーニングみたいに深い話ではなく、人間がグーを出した後はパーを出しやすいとかを覚えるとかの話。

  • 擬似乱数
    • 数式によって得られる乱数、本当の乱数とは言えない

「リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす」を読んだ

個人でアプリを開発するときによく思うのが「とりあえずまずリリースしてみる」というのが大事だと思っていた。
MVP とかいったりするし、そこらへんちゃんと理解したいという思いで読み始めた。

実際に読んで見ると「とりあえずまずリリースしてみる」というのは正しくなくて、「検証可能な仮説が正しいのか検証するための最速の一手を打つ」みたいなのが大事。
最速の一手というのはスケールしない方法という意味で、例えば洗濯をするサービスを作ろうと思ったとき「本当にそのサービスは必要なのか?」を検証するために、街中の人に1000円で洗濯するけどどう?って話して実際に CEO が洗濯する、というのを通して開発する意味があるのか検証しよう、という感じである。

昨今のサービスは、企画があってすぐに開発に移るけどそれはよくなくて、本当にその企画が正しいのか?というのを理解してからやったほうが良さそう。 そういう意味での Minimum Viable Product を作っていこう、というのが印象に残った。

検証するときにはちゃんとそこから学習して、次は良い結果になるように企画を変えるのはもちろん次の検証はもっと早く実施できるようにしよう、とかもよかった。

以下 Twitter に投げた感想。


「Deep Work 大事なことに集中する」を読んだ

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

rebuild.fm で本書の話しが出てて、最近集中できないことが多いので読んでみるか〜というノリで読み始めた。

言っていることはわかるのだが、ちょっと独善的すぎないか?と思ってしまう。
メールを返すのは1日1回だけで良い、あいつはメールを返すのが遅い人間と思わせたら勝ち みたいなの書いてあって、それはチームワークみたいな話じゃなくて独りよがりすぎないかなあとか思った。

オンラインの誘惑に勝てとか SNS は本当にお前の人生に必要か?という話はめっちゃ身にしみる。
沁みるのだが Twitter やめられねえ… って感じで己の意志の弱さに負けてしまう。

というかそんな Deep Work に命かけるとか人生何のためにいきてるんや!って思ってしまう。しかし Twitter やっている間に Deep Work している人がいると思うと自分はその人に勝てないとも思う。

とりあえず本を読んでから意識的に Twitter はしないようにしている。
就業時間を終えたら会社の Slack も見ていない、今のところ支障はないし無意識に iPhone で Slack 見るみたいなことはなくなって精神的にも良い。

毎朝やること書き出してタイムスケジュール決めて、その通りのスケジュールには行かないけど自分がどの仕事に集中するのか意識すべし、っていうのは良さそう(やれてないけど…)。

Deep Work 実践できたらめっちゃ強いけど自分はそこまで強い意志が持てずつらい、というのが正直な感想です。

以下 wikihub 日報 のまとめ。


読み始めた。まだ40%くらい。
これからは貧富の差が拡大していくから、富の側の人間になろうぜ!!!って導入でウケた。

毎日3~4時間は深い集中で仕事するべしってあって、めっちゃ同意できる。
SNS がどうとかって話が rebuildfm で言われてたけど、それより最近だと Slack が一番厄介だと思う。
仕事だと Slack でカジュアルにメンションくるけどあれ完全にシャローワークなんだよな。

ディープワーク/シャローワークらへんで言いたいことたくさんあるからブログ書こう。

とりあえず明日からポモドーロやってみよう。


50% くらいまで読んだ。
外界と断絶して集中するのがいいけどそうも言ってられないからフロー状態に入れる環境作ろうなみたいな話してる。
オープンオフィスは最悪とのこと。


60% くらいまで読んだ。

  • 就業時間が終わったら翌朝まで仕事のことは完全に頭から追い出す
    • これは最近やってる、就業時間終えたら Slack は見ていない
  • 初心者は1日1時間程度しか Deep Work できない、慣れてくると最大4時間いける、だから夕方になると疲れ果てて仕事は手につかないので定時で帰れ
    • 1日1時間も Deep Work できていない…。
  • オンラインの誘惑に打ち勝ちオフラインにしろ
    • おっしゃる通りだ

読み終わった。

言っていることはわかるし Deep Work の 必要性も感じているが、著者が人生 Deep Work って感じてついていけなさを感じる。
意識が高すぎる。

あと自分が Deep Work するために他者を拒絶する感じがあって、
例えばメールは5分以内に返すのが美徳とされるこの世界においてメールは1日1回しかチェックしません、
というのは働きにくい人間やな〜ってなりそう。
本書的にはそういう人間と思わせれば勝ちってあるけど、うーむ。

  • 60%~
    • Twitter などの SNS はあなたが本当にやりたいことに対しプラスになるのか?
      • なりません…
    • SNS やめろ
      • はい…
    • シャローワークさせらせそうになったらはっきり断れ
      • うーむ、断りたいけど全体最適化みたいなの考えると断れなくね?
    • よくわからんメールとかきたら無視しろ、無視した結果問題が起きたらそれはそれで良い
      • おれにメールを無視する度胸はない…
    • ディープワーク最高だろ?お前もやれよ
      • うむ、最高である、努力してみる。

「オブジェクト指向でなぜつくるのか」を読んだ

今まで Ruby, Java などオブジェクト指向言語に触れてきたけどオブジェクト指向っていうのが結局よくわかっていない。
クラスとかカプセル化とか継承とかの概念はわかるし使えもするけど、自分の知識は薄っぺらいというか真髄を理解していない気がしているので、オブジェクト指向を完全理解したいというモチベーションを持って読んだ。

しかし、この本ではオブジェクト指向は「クラスは処理を隠して、継承とポリモーフィズムは処理をまとめるだけだよ」みたいに書かれてて、それは本を読む前から理解してるし俺が知りたいのはそれじゃないんや〜って感じだった。
後半は要件定義とか関数型言語の話になって、何の本を読んでいるんだ?という気持ちになってしまった。

しかし、オブジェクト指向が生まれる前の話が書いてあって、昔は全てグローバル変数でサブルーチンがあるだけだったらしい。
なので、それと比較するとクラスで隠蔽できて、継承とかで処理を共通化できるのは素晴らしいことだったんだろうなと思う。
そこらへんの歴史的背景が知れたのはよかった。

自分が知りたいのは多分この本ではなくて、 オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の方なのかなと思った。

以下 wikihub 日報 のまとめ。


読み始めた。20% くらいまできた。
恥ずかしながらオブジェクト指向をちゃんと理解しておらず、概念はわかるがちゃんと使えていないという状態なのでためになりそう。

  • 「動物クラスから犬のサブクラス作って吠えるってメソッド実装する」って説明じゃ全くオブジェクト指向伝わらない
  • そんなわかりにくい例じゃなくてちゃんと説明するぜ
  • オブジェクト指向と現実世界は同じとか言われるけど全然違うから理解できなくて当然だぞ
  • オブジェクト指向は従来の開発を置き換える新しいものという説明があったりするが、それは間違い
  • オブジェクト指向は、それ以前のプログラミング技術を基礎としてその欠点を補うもの

オブジェクト指向をちゃんと理解できていないの、めっちゃコンプレックスなので完全理解したい…。


なんか読まないほうがいい気がしてきた


書評があまり良くないけど読み進めてる。45%くらいまできた。

  • クラスは関連性の強いサブルーチン(関数)とグローバル変数を1つにまとめて粒度の大きいソフトウェア部品を作る
    • 本当にその理解でいいのか…?
  • ポリモーフィズムと継承は、共通サブルーチンではうまく対処できない重複したコードを一本化する仕組み
    • 本当にその理解でいいのか…?

「書評が良くない」という情報を一度得てしまうと、内容に対し懐疑的になってしまうの良くない。
↑ の理解でいいならそもそもオブジェクト指向を理解していたということになるのだが、本質はそこじゃないと思うんだよなあ。
とりあえずもうちょい読み進めよう。


60% くらいまできた。
知ってる内容ばっかで、おれが知りたいのはそういう話じゃないんや〜ってなってる。


80% くらいまできた。
要件定義とかウオーターフォールとかアジャイルの話とかになってて、おれが求めてた書籍じゃなかった…。
とりあえずもうちょいなので読み切ろう。


なんか最後の方は関数型言語めっちゃいいぞ!って話になってハァ〜って感じだった。
オブジェクト指向の表面だけ舐める感じで微妙な本でした。

「チームが機能するとはどういうことか」を読んだ

単純な業務だったら上司が圧倒的パワーバランスで部下を管理してサボらないように効率化を測れば良いが、複雑な業務であったりイノベーティブな業務にはチーミングが必要。
チーミングのためにはリーダーシップが不可欠であり、心理的安全を高め意見を出しやすくすること、価値観の違いなどの境界を超えること、失敗を咎めずむしろ良いこととするなどし、学習しながら実行する組織を作ろうみたいな内容だった。

前職は完全に心理的安全がなく、失敗はそこまで咎められなかったが許容されている感じでもなかった。
現職はそもそもリーダーがおらんし、自分はチームで働いている訳でもないので寂しい気持ちがある。

本を読んだ後毎回思うのが、「ためになるいい本だった、おわり」という小学生並みの感想しか出てこず、他の人の感想文みてるとすげ〜って思う。
まともな人間になりたい。

以下、 wikihub 日報 でちまちま書いてたまとめと感想。


  • ブラック企業みたいに上から恐怖で支配するのはもうオワコン
  • チーミングとは、新たなアイデアを生み答えを探し問題を解決するために人々を団結させる働き方
  • 学習するための組織作り
  • 学習しながら実行する

20%まで来た。やはり内容が難しい、というかすっと頭に入ってこないので読むのに時間がかかっている。

  • 昔はリーダーが管理して部下が労働するような仕組みでうまく回ってたが今は違う
  • リーダーが部下を信頼し、リーダーは方向性などを示し失敗に寛容であるべき
  • そうすると部下が自分たちで考え、良い組織になっていく
  • はっきり意見を言うこと、協働すること、試みること、省察することが大事

26%まで来た。相変わらず内容が濃く文章が長く理解しにくい… 俺の脳内メモリが足りないだけともいう。

  • チーミングを妨げる大きな障害は不安であり、明確な共通の目標がないことも努力を妨げる要因
  • 官僚的な煩雑な手続きや矛盾するインセンティブなども妨げとなる
  • はっきり意見を言うより黙っている方が楽、しかし個人は楽だが組織としては良くないこと
  • 従業員を尊敬しているということをリーダーが従業員に伝えると、従業員はやる気100倍になって良い
  • 意見の対立は新たな理解や尊敬、信頼を築く圧倒的チャンス👊
  • 失敗から学ぶことは難しいが絶対に欠かせない
  • チームはみんなが互いに尊敬、尊重しあい、それには価値観を詳しく知ろうとする姿勢を育てる必要がある
  • 学習するための組織作りには4つのリーダーシップが必要
    • 学習するための骨組みを作る
    • 心理的に安全な場を作る
    • 失敗から学ぶ
    • 職業的、文化的な教会をつなぐ

35%くらいまできた。ゆっくりだけど毎日少しずつ読んでる。

  • リーダーは仕事を押し付けるのではなく、みんなを信頼する。
  • そのことをちゃんと伝え、目標を明確にし、反論や議論などを歓迎する。
  • 周りの人は部下ではなくチームのメンバーであり、全員がパートナーである。
  • そんなこんなでメンバーに圧倒的当事者意識が芽生え、プロジェクトが成功する。

周りの人を信頼し、信頼していることを伝え、目標を明確にし、労働でなく意義のある仕事なんだと認識してもらえるように頑張れという感じっぽい。
競合他社に負けないとかの目標で働くのはメンバーが学習や思考をしないのでよくないとのことだった。
友達の友達の会社は完全にアンチパターンにはまっているな〜と思いながら読んでいた :innocent:


48%まできた。
心理的安全について述べられてて、友達の友達の会社はあまり心理的安全を感じないので、まあそういうことなのかなと思って読んでた。

  • 心理的安全とは、関連ある考えや感情について人々が気兼ねなく発言できる雰囲気を指す。
  • 一人だけ心理的安全ということはなく、一人が心理的安全であれば他のひとも心理的安全である可能性が高い。
  • 逆に、一人でも心理的安全でない場合はみんな心理的安全でないばあいがおおい
    • だから、自分が心理的安全を感じなければ他のひとも感じていないということなのである
  • 心理的安全を得るためにはやはりチームを信頼し、率直にはなし、意見を歓迎し、失敗に寛容になることだ
    • 失敗したからといって処罰はしない、失敗は歓迎することでチャレンジが生まれる
  • 心理的安全が高い方が失敗の数が多い、それは失敗を話し合う文化があることで明るみに出やすくなるからだ

60% まで来た。ひたすら失敗を肯定しろという話がされている。

  • 失敗に寛容になれ、むしろ失敗はいいことである
  • 失敗を叱るな、褒めろ
  • 小さな失敗でも見過ごさずなぜその失敗が起きたかちゃんと振り返れ
  • エンジニアが「これはやばい」といっても経営層がヤバさをちゃんと認識せず数ヶ月後にヤバいことが判明するのは勿体無い
    • 友達の友達の会社かな?って感じで読んでた。

70% まで来た。
リーダーシップについて語られている、とりわけ境界という他者との違いを受け入れチームとして働く為には〜という話がされている。

  • いまどきの社会は価値観が全く同じ人が揃うことはまずなく、みんな考え方が違う。
    • それを境界と定義する。
  • その境界を繋ぐことが大事。
  • 成功しているチームは境界を超えて協働する、しかし境界は軽視されがちなので境界を受け入れよ。
  • より上位の目標を上げることでチームをうまく動かすリーダーシップが必要になる
    • 「例えばドリルで穴を開ける」という目標ではなく「落石に埋もれた人を助ける」など

80%まで来た。
学習しろみたいな話がひたすらされてた。あまり覚えていない。

  • 実行するな学習せよ
    • 実行というのはマニュアル通りにやり、改善することや決められたことをいかに素早くやるかみたいなやつ
    • 学習は試してナンボ
  • 学習しながら実行せよ
  • 学習しながら実行し続けるにはリーダーシップが不可欠
  • 何をするにしても心理的安全や失敗はむしろ良いことなどが絶対に必要とのこと

読了。

  • リーダの極めて重要な仕事は、短期的には高くつくが長期的には費用対効果の高いことにお金を出してもらうこと
  • 人々をリードするのは良い答えを提供することではなく、良い質問を多くすること
  • 進歩には分野や国家を超えたチーミングが必要になる。
    • その新たな試みは間違いなく失敗を経験するので是非学ぼう

まとめ

  • チームが機能するにはリーダーシップが不可欠。
  • サボらないように監視するやり方は複雑な業務に向いていない、メンバーを信じメンバーに考えてもらうことが大事
  • チーミングのためには心理的安全、境界を超えること、メンバーを仲間として尊敬しあうこと、目標を掲げることなどが大事
  • 学習しながら実行する
    • そのためには失敗すること、失敗を怖がらないこと、失敗を咎めないこと、
  • 仕事といっても「ルーチンワーク」「複雑な業務」「イノベーティブな業務」がある
    • ルーチンワークとかは失敗とかより改善とかスピードだけど、その中にも挑戦や失敗がないと後で詰む

macOS Sierra にしたので Karabiner が使えなくなってやったこと

やったこと

参考にしたもの

Karabiner 使えない対策: Hammerspoon で macOS の修飾キーつきホットキーのキーリマップを実現する - Qiita

hammerspoon Config file

local function pressFn(mods, key)
    if key == nil then
        key = mods
        mods = {}
    end

    return function() hs.eventtap.keyStroke(mods, key, 1000) end
end

local function remap(mods, key, pressFn)
    hs.hotkey.bind(mods, key, pressFn, nil, pressFn)   
end

remap({'alt'}, 'h', pressFn('left'))
remap({'alt'}, 'j', pressFn('down'))
remap({'alt'}, 'k', pressFn('up'))
remap({'alt'}, 'l', pressFn('right'))

RxSwift で NotificationCenter を使う

Notification を送る側

let name = Notification.Name("notification")
NotificationCenter.default.post(name: name, object: nil, userInfo: ["key": "value"])

Notifiactin を受ける側

disposeBag があるので購読やめるとかしないでよい。

NotificationCenter.default.rx.notification(name, object: nil)
    .subscribe(onNext: { notification in
        log?.debug(notification)
    })
    .addDisposableTo(disposeBag)

結果

f:id:star__hoshi:20170326175758p:plain

補足

引数の object ってなんだ?

NSNotificationの通知を受け取れるパターンと受け取れないパターンについて - Qiita

iOS Test Night #3 でカバレッジの計測について話してきた

カバレッジについて話したが、カバレッジが高けりゃいいわけじゃなくて、計算ロジックとかは絶対に書いた方がいいけどそうではないところは書くメリット小さいかなと思っている。

とはいえテストがないと影響範囲読めないし、「俺たちが書くコードは完璧だから絶対にバグが起きないぜ😎」という自信がある人以外はテスト書いた方がいいんじゃないかと思っている。

今日の勉強会では「そもそも静的解析で間違いを発見するべし」みたいな話が出ていて、素晴らしいと思った。
そもそもバグを生み出さない仕組みがあればテストいらんよねという話である。

iOS Test Night の雰囲気

司会の人とかだいぶ緩い空気出してて、 LT 以降は酒飲みながら、懇親会はシースーが出てくる感じでゆる〜くて良かった。
また次回も参加したい 😊

実はめっちゃ練習した

自分にとってはほとんど初 LT みたいなものだったので、だいぶ緊張した。
本番で頭真っ白になったらどうしようとかめっちゃ不安で、5分のライトニングトークなのに多分20回くらい練習した。

大して面白い発表はではなかったけど、まあ失敗はしなかったので良かったと思う。
他の勉強会にも出て行きたい。