2-1 抽象的コンカレントプログラミング
- 並列(Parallel)
  - 複数の処理を同時に行う
- 並行(Concurrent)
  - 少なくとも見かけ上は複数の処理を同時に行う
- プロセス
  - 「実行中のプログラム」のことを表す
  - それぞれのメモリー空間が独立
  - メモリー空間全体を複製することから、forkによるプロセス発生のコストは高い
    - Cow(Copy on Write)などで効率化しているけど
  - プロセス間通信も難しい
- スレッド
  - 一つのプログラムの中でメモリー空間を共有しつつ、複数の制御の流れを実現
  - 整合性を維持する排他的制御(Mutex)が面倒
  - 結局システムコール呼び出しはコストになる
    - 特権命令が実行できるカーネル空間への切り替え
    - 膨大なCPU命令数
    - スタック領域としてのメモリー割り当て
- アクターモデル
  - 非同期のメッセージをやり取りできるアクターという独自の制御の流れを持った存在
- Erlang
  - Ericssonが開発したの知らなかった
  - Erlangのプロセスがアクターに相当
    - OSのプロセスと紛らわしい
- Go
  - goroutine
  - メッセージ送信の対象はchan(チャネル)オブジェクト
    - Erlangではプロセス自身がメッセージの送信先
- Clojure
  - STM(Software Transactional Memory)
  - DBのトランザクション処理をプログラミングに導入
2-2 新言語「Streem」とは
- 「Stream」から名前変わってたの知らなかった
- 21世紀のシェルスクリプト
  - 軽量なコンカレント実行
    - 一つのプロセスの中でCPU数に応じたスレッドを生成して、それらが交代で実行を引き受ける
  - コンカレント実行における競合状態の削除
    - すべてのデータをイミュータブルに
  - 計算モデル
    - シェルの実行モデルを参考に、抽象度が高い計算モデルを導入
    - そのぶん表現の自由度は下がる
2-3 文法チェッカーをまず作る
- 供給者・消費者パターン
- ラウンドロビンパターン
- 放送パターン
- 集約パターン
- 要求・応答パターン
2-4 イベントループ
- イベント処理を行うライブラリ
  - libevent
  - libev
  - libuv
- I/Oイベントの検出
  - ブロックを回避するために、ファイルディスクリプターにデータが届いていることを確認する必要
  - select
  - epoll(Linux)
  - kqueue(BSD系OS)
- 文法衝突みたいなうまくいかなかった話が面白い
2-5 マルチスレッドとオブジェクト
- マルチコアの実装が難しいのがわかる
- 優先度付きキューのアルゴリズム面白い
- ガーベージコレクション
  - libgc
glibのメモリ管理でlibgc(boehm gc)を使う方法

libgcは、GC_INIT()を最初によび、以下メモリ確保でGC_MALLOCなどをmallocの代わりに使うことで、freeしなくてもガーベージコレクタが機能するプログラミングを行えるライブラリです。
2-6 キャッシュとシンボル
- マルチコアではL1キャッシュは各コアが独立にもっていて、L2とL3は複数コアで共有することが多い
- ‘There are only two hard things in Computer Science: cache invalidation and naming things.’ - Phil Karlton
- 『"Don’t guess, measure!（推測するな、計測せよ！）”』
- Rubyのシンボル
https://docs.ruby-lang.org/ja/2.3.0/class/Symbol.html

Rubyの内部実装では、メソッド名や変数名、定数名、クラス名などの`名前'を整数で管理しています。これは名前を直接文字列として処理するよりも速度面で有利だからです。そしてその整数をRubyのコード上で表現したものがシンボルです。シンボルは、ソース上では文字列のように見え、内部では整数として扱われる、両者を仲立ちするような存在です。名前を管理するという役割上、シンボルと文字列は一対一に対応します。また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。
- Pythonは文字列をインターン化することで性能解決
  - Pythonは文字列がイミュータブルなため
- シンボルごみ問題
  - GCする必要あり
  - 「弱い参照」(参照はしているがガーベージコレクション保護の対象にならない参照)
2-7 AST(抽象構文木)に変換
- 構文木のままトラバースして実行するのは性能が良くない
  - メモリー空間を飛び飛びにアクセスするためキャッシュ効率が悪い
  - VMのバイトコードに変換して連続的に解釈するのが望ましい
2-8 ローカル変数と例外処理
- ローカル変数の実装
  - 関数のコンパイル時にローカル変数ごとに個別のインデックスを割り当て
  - この配列がスタック
- クロージャー
  - 関数オブジェクト(無名関数)に外側のスコープの変数が「閉じ込められている」
- CやGoは明示的エラーチェック
  - コンカレントプログラミングと相性が悪い
- 例外安全性が大事になる
- SwiftのOptionalおしゃれ
  - Java8でも便利だった思い出

第3章オブジェクト指向機能を設計する

3-2 Streemのオブジェクト指向
- Namespaces are one honking great idea
- Python・JavaScriptはLisp-1
- RubyやSmalltalkはLisp-2
- StreemはLisp-1.5
  - 関数名を直接指定したときには関数への参照
  - 「.」を使ったメソッドチェーン形式では引数のないメソッド呼び出し
3-3 Streem文法再訪
- Lisp-2
  - メソッドキャッシュによる高速化
  - ネームスペースに分散した関数を総称的に扱うのが得意でない
3-4 パターンマッチ
- 末尾再帰化でスタックの無駄遣いを解決

第4章 Streemオブジェクトを実装する

4-1 ソケットプログラミング
- そもそもソケットとは
  - ネットワーク接続の通路となるための「OSオブジェクト」
  - ファイルディスクリプタで識別
  - 同じファイルディスクリプタで読み込み・書き込み可能
4-3 オブジェクト表現とNaN Boxing
- CPython: オブジェクトへの参照は構造体へのポインタ
  - 単純ポインタ法
  - 構造体へのアクセス最速
  - オブジェクトへの割り当てが大量になる
- CRuby・Emacs Lisp: ビットに型情報を詰め込み、整数の値など一部の値を参照に直接埋め込む
  - Tagged Pointer法
  - メモリ効率Up
- mruby・Lua: オブジェクトへの参照は構造体
  - シンプル & 移植性の高さ
  - メモリ効率Down
- V7: NaNの浮動小数点でオブジェクト表現
4-4 ガーベージコレクション
- トレース法
  - 「生きている」オブジェクトを確実に検出
  - 処理時間が長い
  - マークアンドスイープ法 / コピー法
- 世代別GC
  - 「若い」オブジェクトを重点的にスキャン(マイナーGC)
  - 旧世代領域から新世代領域への参照はリメンバーセットで管理（write barrier）
  - 全ての領域をスキャンするフルGC(メジャーGC)
  - 実行時間を短くできるが、最大停止時間は変わらない
- インクリメンタルGC
  - 処理を細切れにして少しずつ実行
  - 世代別GCと同様んひライトバリアを使用
  - 実行時間は長くなるが、最大停止時間は抑えられる
- リファレンスカウント法
  - オブジェクトの解放を局所的に判断できる
  - 停止時間も短くなる
  - 循環参照を持つオブジェクトを解放できない
  - 並列処理と相性が悪い
- 例えば GC を止める・Ruby ウェブアプリケーションの高速化
- Dismissing Python Garbage Collection at Instagram

第5章ストリームプログラミングを強化する

5-1 パイプラインプログラミング
- 通常のデータ構造はイミューブルでも、状態を持ちたい
  - Haskellは「モナド」
  - Erlangは状態を2種類の方法で管理
  - Streemは組み込みデータベースで解決
  - ロックによる排他制御とトランザクション

2017-03-08

2017年2月の振り返り

もう3月になって1週間過ぎちゃったけど、2月の振り返り。

仕事

GoによるAPIプロキシサーバー
それを利用するためのPython Package
依存パッケージのwheel化
サムネイル生成のAWS Lambda

アウトプット

ブログ

イベント

第14回 Pythonもくもく会 - connpass

読書

先月の読書メーターまとめ

読んだ本の数：1冊
読んだページ数：144ページ

みんなのGo言語【現場で使える実践テクニック】

音楽

映画・ドラマ・アニメ

N/A

ラクロス

鹿島OPENめっちゃ楽しめた
バサロカップでのパフォーマンスも良かった
2月後半は忙しくてあまりできてない
チーム全体としてもっと練習盛り上げていかないと

その他

PyCon mini Kumamoto 2017のTalk採用された
アライド株を売った
- 500円で買ってた株が4000円になっててすごい(小並感)

目標と成果

◯ Golangもっと勉強する
- 良かったGolangの記事/発表（2016年）やみんなのGo言語【現場で使える実践テクニック】を中心によく勉強できた
× まつもとゆきひろ言語のしくみを読む
- Golang以外の本を読む余裕がなかった
× 1月終わったけど2017年の抱負を書く
- 気づけばもう3月
- 今週こそ書くぞ…
◎ 鹿島Open楽しむ・騒ぐ
- 最高に楽しめた
- 祝優勝！また来年！
△ ラクロスの時間を確保する
- 確保できつつあるけど、まだまだ足りない
△ 業務外の時間を確保する
- 仕事が落ち着いた月末から確保できてきた
× 映画・ドラマ観たい

3月に向けて

JSの勉強をする
- 今月からフロントエンドの改修にとりかかる
- 4月のOkachi.jsの発表準備もする
- 以下を読み進める
まつもとゆきひろ言語のしくみを読む
そろそろ2017年の抱負を書く
執筆作業を進める
ラクロスの時間を確保する
業務外での仕事を完成させる
PyCon mini Kumamotoの準備をする

2017-02-28

「みんなのGo言語」を読んだ

みんなのGo言語【現場で使える実践テクニック】

作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太,稲葉貴洋
出版社/メーカー: 技術評論社
発売日: 2016/09/09
メディア: 大型本
この商品を含むブログ (3件) を見る

業務でGoを書くことになったのがきっかけで、「みんなのGo言語」を読んだ。

Goの経験は、1年ちょっと前に A Tour of Go やって、CLIツールとか書いたことある程度だった。

github.com

結果として、この本から

Goらしいプラクティス
仕事で使えるテクニック

を知ることができたおかげで仕事が捗った。

タイトルにもある通り、「現場で使える実践的なテクニック」という趣旨が各章で意識されていた。薄い本だけどカバー範囲が広く内容が詰まっていて、とても読み応えがある。

特に「第1章 Goによるチーム開発のはじめ方とコードを書く上での心得」と「第6章 Goのテストに関するツールセット」の内容が、めちゃくちゃ勉強になったのでオススメ。

プログラミング言語GoとかA Tour of Goの次に読むべき本として最適だと思う。

読書メモ

第1章 Goによるチーム開発のはじめ方とコードを書く上での心得

songmuさんの章
Goでチーム開発していくにあたって、めちゃくちゃ参考になった。特にこの3箇所
- ディレクトリ構成
- 依存管理
- タスクランナーとしてMakefileを使う
依存管理はGoから公式なのが出たけど様子見
- https://github.com/golang/dep

第2章マルチプラットフォームで動作する社内ツールのつくり方

mattnさんの章
Goの特徴
- スタティックビルド(プログラムの実行に必要なライブラリがあらかじめリンクされていること)
- シングルバイナリ
Windows対応の話がメイン
「2.6 シングルバイナリにこだわる」はWindowsだけじゃなくてweb開発で汎用的に役立つ内容だった
- 静的ファイルをバイナリに組み込むやり方について
  - go-bindata
  - go-assets
- go generateをうまく使ってて参考になる

第3章実用的なアプリケーションを作るために

fujiwaraさんの章
3.3 効率的なI/O処理
- I/O処理のバッファリングに関して理解してなかったから勉強になった
- 合わせて読んだ
3.9 goroutineの停止
- 処理の中断やタイムアウトをやりたい時はcontextパッケージ
- contextはGo1.7から標準パッケージ
- 合わせて読んだ

第4章コマンドラインツールを作る

deeeetさんの章
慣習的にcmdディレクトリを作ってたけど、理由が書かれててスッキリした
gotebuでは、urfave/cliを使ってる
Exitをむやみに使わない
- deferが呼ばれないため
合わせて読んだ
- コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014

第5章 The Dark Arts Of Reflection

lestrratさんの章
reflectはMethodByNameを使ってるけど、他にも色々できて勉強になった
合わせて読んだ
- RubyistのためのGolangメタプログラミング - k0kubun's blog

第6章 Goのテストに関するツールセット

suzukenさんの章
Goにおけるテストのあり方は「明示」と「シンプル」
Build Constraintsを利用したテストの切り替え
インターフェースを使ったモック
coverageは複数パッケージのテストに対応してないから、ちょっと工夫が必要
- https://github.com/codecov/example-go#caveat-multiple-files
合わせて読んだ

2017-02-06

2017年1月の振り返り

もう2月に入ってしばらく経ってるけど、1月の振り返りブログを書いておく。

頭の整理のために、月単位での振り返りをはじめてみる。

仕事

Django1.10.5 Upgrade
Golangプロジェクトの土台作り
スクラム啓蒙

アウトプット

ブログ

イベント

読書

先月の読書メーターまとめ

読んだ本の数：2冊
読んだページ数：672ページ

音楽

1/28にYYY Vol.2とYSTK×KPP CLUB EDITIONがあったから、今月はその関連の曲をよく聞いてた。

そしてついにTeddyLoidにハマった。

映画・ドラマ・アニメ

N/A

ラクロス

体力づくりのために皇居ラン再開
思ったよりブランクを感じずにシーズンインできた
1月はあまり練習いけなくて申し訳なかった

その他

雪山合宿めっちゃ楽しかった
- ラクロスの日程が合えば夏も行きたい
転職ドラフトに登録したことで外部からの評価をある程度知れた
PyCon mini Kumamoto 2017のプロポーザル書いた
Rustの勉強をちょっとはじめた
- Rebuild: 173: There Are No Gems, Only Stones (N)でNさんの「世の流れはRustじゃなくてSwift」という話は新鮮だった

2月に向けて

Golangもっと勉強する
- やればやるほど面白くなってきた
- 良かったGolangの記事/発表（2016年）を抑える
- Golang本読み進める
まつもとゆきひろ言語のしくみ
- 読むの後回しになってるけど、2月中に読みたい
1月終わったけど2017年の抱負を書く
鹿島Open楽しむ・騒ぐ
ラクロスの時間を確保する
業務外の時間を確保する
映画・ドラマ観たい
- 海街diary
- 東京タラレバ娘
- トリック
- SPEC
- 高い城の男

2017-01-25

「ジョイ・インク」を読んだ

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

作者: リチャード・シェリダン,原田騎郎,安井力,吉羽龍太郎,永瀬美穂,川口恭伸
出版社/メーカー: 翔泳社
発売日: 2016/12/20
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

*1先日のRegional SCRUM GATHERING Tokyo 2017で宣伝されていた「Joy, Inc.」日本語版を読んだ。

この本の趣旨と翻訳に至った経緯は以下のように記されている。
Ref: 【17-B-7】『ジョイ・インク』Joy, Inc. 〜共感のソフトウェアづくりについてみんなで考えるワークショップ | Developers Summit 2017

“Joy, Inc.: How We Built a Workplace People Love”(2015年刊行）は、アメリカ、ミネソタ州にあるソフトウェア受託開発企業メンロー・イノベーションズ社の15年にわたるモノづくり、人づくり、顧客との関係づくりの詳細をまとめた本です。そこには2000年代初頭にアジャイル開発(特にXP)とデザイン思考に出会った人々が、苦労を重ねながら優れた組織とプロセスを作り上げる過程と、行なっている優れたプラクティスについて語られています。そして、2016年12月に、原著に共感したアジャイルコーチが集まって、日本語翻訳版『ジョイ・インク』を刊行しました。

XPやアジャイル開発のことを知っている人であれば、すんなり読むことができると思う。その考えを経営・会社作りにも適用してるというもの。川鍋さんのアツいあとがきに書いてある「アジャイル経営」という言葉がとてもしっくりくる。

失敗したことやうまくいかなかったことも多く書かれていて、とても共感が持てる。またメンローという会社はシリコンバレーにあるエッジの効いたハイテクカンパニーというわけでもない。決して手の届かないどこか遠い話ではなく、自分ごとのように身近に感じることができた。

エンジニアだけでなく経営メンバーなど色んなひとに読んでもらいたい
一緒に喜びに満ちた会社を作っていきたい

そう思える一冊でした。会社の本棚に置いておこうと思う。

合わせて読みたい

読書メモ

イントロダクション

喜びと幸せは同じではない
- 幸せとはある時点における状態の話
- 幸せな状態が連続していなくても、喜びに満ちていられる
- 根本的で本能に根ざした追求心は喜びに向かう

1章僕が喜び(Joy)にたどり着くまで

XP・アジャイル開発おすすめ
- ペアプロ・モブプロは個人的に心理的ハードルでかい

2章スペースとノイズ

壁を取り払え
- キュービクルは最悪だよね
  - コミュニケーションうまない
  - 個人主義すぎる
フィクションから得た「身軽」というひらめき
- 遊びごころが戦場の緊張感を和らげる
  - 犬とか赤ちゃんとかよいよね
C?Oはどこにいる
- 権威づけいらない
オフィス警察はいらない
- 自分たちの場所はオーナーシップを持って自分たちの望む場所に変えていく
喜びは騒がしい
- 賛成だけど集中するためにヘッドホンしたいよね

3章自由に学ぶ

1台のPC共有してのペアプロは現実的に厳しい
- エディタ問題
- 画面を共有したペアプロがいい
  - Screenhero

4章会話・儀式・道具

アジャイル開発の具体的な事例紹介

5章インタビュー、採用、立ち上げ

「正しい人をバスに乗せ、正しくない人をバスから降ろす」
採用はカルチャーに直結するから、とことんこだわりたい
- 長期間のトライアルは実際に仕事を一緒にできるから有効
  - コスト大きい & 情がうまれてしまって採用判断が難しそう

6章観察のもつ力

ハイテク人類学をソフトウェアに適用
グループインタビューは人格が破綻した人に乗っ取られてしまう
そもそもユーザーは自分が本当に欲しいものを知らない
プライナリペルソナ（1人だけ）を設定する
- 誰にとっても役立つようなサービスは誰からも使ってもらえない
- 百徳ナイフにするな

7章恐れと戦う、変化を抱擁する

すばやくたくさん失敗しよう
サンクコストによる思考停止
- こんなに投資してきたんだから
- うまくいかないことをやろうとした奴らと思われたくない
- 実験が失敗だとわかっても、コースを変更したがらない。これまでの投資が無駄だったと認めたくない
心理的安全性
SQUEEZEもオフィスに赤ちゃんいるけど、とてもよい試みだと感じる

8章ボスではなくリーダーを育てる

みんな完璧ではないことを認めなくてはいけない
何か問題があった場合に、すぐ晒け出される仕組みが大事
- 悪いことを隠そうとしない
『ビジョナリーカンパニー』からの引用多い
- 読みたさ

9章カオスを終わらせる、曖昧さをなくす

見積もりなしに仕事はしない
やること/やらないことを明確に
複雑なプロジェクトのためのシンプルなシステム
- 使うツールは少なく・シンプルであるべき
ショッキングピンク判断
- 古いプロダクトの保守運用に関するストーリーカードを見える化した話
- リファクタリングなどを見える化してみるのいいかも

10章厳格、規律、品質

厳格さと規律が品質を保つ
厳格さと規律はルーティンをもたらす
- 一流はルーティンを大切にして、身体だけでなく魂を傾ける
- 二流は表面的には従うが、信じてはいない

11章持続可能性と柔軟性

卓球台・ゲーム機・マッサージチェア
- こういったの置いてるのは遊び心ある会社ですよっていうパフォーマンスでしかないよね
- 確かにほとんど使ってないイメージ
低い離職率は健全な文化の証ではない
- ex) 東ベルリン
- 高給で引き止めてることが多い
出戻り推奨
「許可を求める」という文化はいけてない

12章スケーラビリティ

ブルックスの法則
遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ
ペアプロのメリットはわかるが...

13章説明責任と結果

かかった時間とベロシティの測定が見積もりの正確さにつながる
自由さの報酬としての説明責任

14章アライメント

文化を隠すな
自分たちのストーリーを話せるようにする

15章問題

メンローにも他のところと同じ問題を抱えている
- 問題の数は他と変わらないが、問題のサイズはだいぶ小さい
- 問題が見つかれば隠さないで、小さいうちに解決
会社の問題を気軽に議論にあげられる場と仕組みを作りたい

16章まとめ

どんな組織にもビジョンが必要だ
Whyを見つけよう
- 『WHYから始めよ』の観てみよう
- サイモンシネック: 優れたリーダーはどうやって行動を促すか | TED Talk | TED.com

「新装版達人プログラマー」を読んだ

新装版達人プログラマー職人から名匠への道

作者: Andrew Hunt,David Thomas,村上雅章
出版社/メーカー: オーム社
発売日: 2016/10/20
メディア: 単行本（ソフトカバー）
この商品を含むブログ (5件) を見る

数多くの技術者がオススメしている名著「達人プログラマー」を読んだ。

ちなみに絶版となっているほうは読んでいない。

Rebuild.fmでomoさんが話していたように、確かに時代背景をきちんと考慮しないと読者のためにならないような情報も多かった。特に技術に関する箇所はそうだったが、取り組む姿勢・技術の根底にある考え方に関しては今でもとても役に立つ内容となっている。

各トピックに関しては広く浅く、エッセンスだけの紹介にとどまるので、「達人プログラマー」となるためには自分でそれぞれ深掘りしていく必要がある。

今となっては当たり前となっていて意識しないようなことも書いてあるが、17年前にこの本を読んだ「達人プログラマー」たちの努力によって技術・環境が進化して今があるかと思うと感慨深い。

総じて、「古典として素晴らしい」というものだった。

合わせて読みたい

読書メモ

第1章達人の哲学

割れ窓理論
毎年少なくとも一つの言語を学習する

第2章達人のアプローチ

直交性
- 「直交性」という言葉の意味がよくわかってなかったからスッキリした
- ヘリコプターの操縦の例がわかりやすい
- 恥ずかしがりなコード
専用の言語
- Rebuildで話してたようにDSLの話は歴史を感じた

第3章基本的なツール

デバッグの節がよかった
- パニックに陥らない心構え
- バグを直すだけでなく、バグを早期発見できなかった原因を考えて改善する
他の節は古典としては楽しめた

第4章妄想の達人

契約による設計(DbC)
- 誰の責任かを明確に
早めのクラッシュ
- 問題発生時点で早めにクラッシュするほうが問題の早期発見や診断を簡単に行える
表明プログラミング
- もし起こり得ないというのであれば、表明を用いてそれを保証
  - 副作用があってはだめ
  - 本来のエラー処理に表明を使ってはだめ
いつ例外を使用するか
- 例外とは予期せぬ事態に備えるためのものであり、プログラムの通常の流れの一部には組み込むべきではない
- 例外は例外的な問題のみに使用する

t_wadaさんの話を聞いてたから、この章は理解しやすかった。

【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised

第5章柳に雪折れ無し

デメテルの法則
- 別名最小知識の法則

基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。

// デメテルの法則に違反している
console.log(aStudent.class.grade)

// デメテルの法則に違反していない
console.log(aStudent.getGrade())

Ref: 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita

メタプログラミング
- 去年のPyCon JPのメタプログラミングPythonをやっと見た
- 内容がまとまっててよかった
- メタプログラミングRuby 第2版よさげ

第6章コーディング段階

アルゴリズムのスピード
- 入門データ構造とアルゴリズムこれを去年読んでたから理解しやすかった
テストしやすいコード
- ユーザにテストさせない
邪悪な魔法使い
- ウィザードについて
- 何やってるか自分でわからないものは使うな

第7章プロジェクトを始める前に

要求の落とし穴
- 用語集を管理する
  - glossaryは管理し続けるのが難しいから人気ないけど、ユビキタス言語の整理にもなるし必要最低限のものは作りたい

要求とは拾い集めるものではなく、掘り起こすものである

最終的な目標は、要求どおりのものを作るということではなく、ビジネス上の問題を解決するということ

第8章プロジェクトを始める前に

誇りと愛着
- コードへの署名を推奨しているけど、属人性を強めるから好きではない
- おそらくバージョン管理がないような時代背景のせい

達人プログラマーは責任逃れを潔しとしません。代わりにチャレンジを受け入れること、技術を発揮することに喜びを感じます。

2017-01-16

Regional Scrum Gathering Tokyo 2017 に参加してきた #RSGT2017

はじめに

2017/1/12~2017/1/13 に開催された Regional SCRUM GATHERING Tokyo 2017 に参加してきたので、その参加メモです。

Regional SCRUM GATHERING Tokyo 2017

http://2017.scrumgatheringtokyo.org/

Regional SCRUM GATHERING Tokyoは、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。講演やワークショップ、そして参加者同士の交流を通じて、世界最前線の情報から日本の現場での工夫まで多くの知見を得られます。

参加動機

SQUEEZEの今のチームでもスクラムを最近始めたので、

スクラムに関して改めて勉強したい
実践的な知見が得たい

という動機から参加しました。

個人的には2015にCertified ScrumMasterを取得して以来のスクラムイベントでした。

印象深かったトーク

※ それぞれのトークに@fullvirtueさんのまとめツイートを紹介させて頂きます。

エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史

slide: https://speakerdeck.com/player/26ea9ccdcd9344c59a80a16d01c5cee2

評価制度を継続的に改善・見直しできている仕組みが素晴らしいかった。
評価軸から組織文化を作っていく過程は参考にしたい
- 人というのは評価されることを頑張る
- 評価するポイントを具体的に明確にすることで、社員をそっちの方向に促す
  - 文化として根付いて欲しいこと - 事業理解 etc.
  - いま重要視したいこと - テスト etc.

この取り組みはとても勉強になりました。SQUEEZEも人が増えてきて評価制度を整えないとという状況なので、こういった視点を取り入れるように提案していきたい。

ただ評価会という制度については、個人的に以下のような違和感が残りました。

評価者・被評価者のコストが大きい
事業のためではなくて、評価のために頑張っている感じを受ける
途中から評価会をうまく回すための改善になってて、本質的な解決になっているのだろうか？
いくら気をつけても、プレゼン能力の影響力が大きくなりそう
階級制度はフラットな組織でなくなるので嫌い
- 新卒採用を広く行うところでは仕方ないのは理解できるが

こういった違和感は残りましたが、このような意見も想定内のはずだと思います評価制度というセンシティブな分野を信念を持って長年取り組んできて、その試行錯誤を発表するという試みはとても尊いなと感じました。

※ そもそもスクラムにはほぼ関係ないトークだったけど、どういった文脈なのだろうか？

Regional SCRUM GATHERING Tokyo 2017 古賀さんによる『エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史』の講演メモ。 #RSGT2017 pic.twitter.com/acgEfga46k
— fullvirtue (@fullvirtue) 2017年1月12日

Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴〜アジャイルコーチが遭遇するよくある問題とその解決方法

slide: http://www.ryuzee.com/contents/blog/7104

アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。

@ryuzeeさんによるわかりやすいスクラム診断。

自分のチームをセルフチェックしてみたら、以下のような診断結果になりました。

いつも完成しないスプリント

症状: PBIの一部または全部がいつも終わらない
原因: 実績に基づかない楽観的な見積もり

不安定な品質

症状: バグ報告が多い / 完了していないものや作りかけのものを成果として扱っている
原因: 完了の定義(DoD)がない・守れない

機能しないデイリースクラム

症状: 時間通りに始まらない
原因: 時間軽視の文化（自分の遅刻癖）

教育不足

症状: 既出の症状全般
原因: トレーニングや準備不足

次の振り返りでこれを改善できるよう話し合いたい。現状を把握できるようになるスクラムはやっぱりいいですね。

スライド53ページにある以下のモデルだと、自分たちはまだ「混乱期」だと認識できました。

Regional SCRUM GATHERING Tokyo 2017 吉羽龍太郎(Ryuzee)さんによる『スクラムの落とし穴〜アジャイルコーチが遭遇するよくある問題と解決方法』の講演メモ。 #RSGT2017 pic.twitter.com/X6A3fDpVqY
— fullvirtue (@fullvirtue) 2017年1月13日

全体を通しての感想

規模は大きすぎず小さすぎずちょうど良かった
会場みんながフレンドリーな雰囲気で楽しかった
仕事もあって2日間フルでいられなかった
- 来年はPartyにも参加してちゃんとGATHERINGしたい
マネージメントな人が多くてPyConなどの技術カンファレンスとはまた違った感じ
- 年齢層はちょっと高め
- 女性比率は高い
- エンジニア比率は低い
カンファレンス運営の収支報告を行なっていて良かった
来年は木・金・土の３日間に増えるかも
- 同じ会場の仮予約を済ませたらしい
翻訳メンバー陣が推薦していた『ジョイ・インク役職も部署もない全員主役のマネジメント』を読み始めた
- 途中までの感想としては
  - XP, アジャイルのエッセンスが詰まってる
  - 「Joy」と「Happy」の違いの指摘が鋭くて面白い
  - 実践に基づいたアウトプットなので親しみやすい
  - 川鍋さんのあとがきが熱い
- 読み終わったらまた別途ブログ書く

おわりに

スタッフ・スピーカー・スポンサーの皆さま、お疲れ様でした＆ありがとうございました。

すごく楽しくて為にもなったので、ぜひ来年も参加しようと思います！

合わせて聞きたい

合わせて読みたい

読書メモ

第1章 さあ、どんな言語を作ろう

第2章 新言語「Streem」の設計と実装

第3章 オブジェクト指向機能を設計する

第4章 Streemオブジェクトを実装する

第5章 ストリームプログラミングを強化する

仕事

アウトプット

ブログ

イベント

読書

音楽

映画・ドラマ・アニメ

その他

目標と成果

3月に向けて

読書メモ

第1章 Goによるチーム開発のはじめ方とコードを書く上での心得

第2章 マルチプラットフォームで動作する社内ツールのつくり方

第3章 実用的なアプリケーションを作るために

第4章 コマンドラインツールを作る

第5章 The Dark Arts Of Reflection

第6章 Goのテストに関するツールセット

仕事

アウトプット

ブログ

イベント

読書

音楽

映画・ドラマ・アニメ

その他

2月に向けて

合わせて読みたい

読書メモ

イントロダクション

1章 僕が喜び(Joy)にたどり着くまで

2章 スペースとノイズ

3章 自由に学ぶ

4章 会話・儀式・道具

5章 インタビュー、採用、立ち上げ

6章 観察のもつ力

7章 恐れと戦う、変化を抱擁する

8章 ボスではなくリーダーを育てる

9章 カオスを終わらせる、曖昧さをなくす

10章 厳格、規律、品質

11章 持続可能性と柔軟性

12章 スケーラビリティ

13章 説明責任と結果

14章 アライメント

15章 問題

16章 まとめ

推薦者あとがき

合わせて読みたい

読書メモ

第1章 達人の哲学

第2章 達人のアプローチ

第3章 基本的なツール

第4章 妄想の達人

第5章 柳に雪折れ無し

第6章 コーディング段階

第7章 プロジェクトを始める前に

第8章 プロジェクトを始める前に

はじめに

Regional SCRUM GATHERING Tokyo 2017

参加動機

印象深かったトーク

いつも完成しないスプリント

不安定な品質

機能しないデイリースクラム

教育不足

全体を通しての感想

おわりに

第1章さあ、どんな言語を作ろう

第2章新言語「Streem」の設計と実装

第3章オブジェクト指向機能を設計する

第5章ストリームプログラミングを強化する

第2章マルチプラットフォームで動作する社内ツールのつくり方

第3章実用的なアプリケーションを作るために

第4章コマンドラインツールを作る

1章僕が喜び(Joy)にたどり着くまで

2章スペースとノイズ

3章自由に学ぶ

4章会話・儀式・道具

5章インタビュー、採用、立ち上げ

6章観察のもつ力

7章恐れと戦う、変化を抱擁する

8章ボスではなくリーダーを育てる

9章カオスを終わらせる、曖昧さをなくす

10章厳格、規律、品質

11章持続可能性と柔軟性

12章スケーラビリティ

13章説明責任と結果

14章アライメント

15章問題

16章まとめ

第1章達人の哲学

第2章達人のアプローチ

第3章基本的なツール

第4章妄想の達人

第5章柳に雪折れ無し

第6章コーディング段階

第7章プロジェクトを始める前に

第8章プロジェクトを始める前に