読者です 読者をやめる 読者になる 読者になる

massa142's blog

くり返す このポリリズム

2017年2月の振り返り

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

仕事

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

アウトプット

ブログ

イベント

読書

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

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

音楽

映画・ドラマ・アニメ

N/A

ラクロス

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

その他

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

目標と成果

  1. Golangもっと勉強する
  2. × まつもとゆきひろ 言語のしくみ を読む
    • Golang以外の本を読む余裕がなかった
  3. × 1月終わったけど2017年の抱負を書く
    • 気づけばもう3月
    • 今週こそ書くぞ…
  4. ◎ 鹿島Open楽しむ・騒ぐ
    • 最高に楽しめた
    • 祝優勝!また来年!
  5. ラクロスの時間を確保する
    • 確保できつつあるけど、まだまだ足りない
  6. △ 業務外の時間を確保する
    • 仕事が落ち着いた月末から確保できてきた
  7. × 映画・ドラマ観たい

3月に向けて

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

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

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

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

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

github.com

結果として、この本から

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

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

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

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

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

読書メモ

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

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

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

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

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

第5章 The Dark Arts Of Reflection

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

2017年1月の振り返り

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

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

仕事

アウトプット

ブログ

イベント

読書

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

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

音楽

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

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

映画・ドラマ・アニメ

N/A

ラクロス

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

その他

2月に向けて

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

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

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

*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)にたどり着くまで

2章 スペースとノイズ

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

3章 自由に学ぶ

4章 会話・儀式・道具

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

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

6章 観察のもつ力

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

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

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

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

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

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

  • 見積もりなしに仕事はしない
  • やること/やらないことを明確に
  • 複雑なプロジェクトのためのシンプルなシステム
    • 使うツールは少なく・シンプルであるべき
  • ショッキングピンク判断

10章 厳格、規律、品質

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

11章 持続可能性と柔軟性

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

12章 スケーラビリティ

  • ブルックスの法則

    遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ

  • ペアプロのメリットはわかるが...

13章 説明責任と結果

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

14章 アライメント

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

15章 問題

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

16章 まとめ

推薦者あとがき

  • 川鍋さんアツい
  • 文化が一番大事
    • 素早くたくさん失敗する
    • 見える化・情報の共有文化
    • 社員も顧客も文化を第一に選び・信じきる
  • たくさんの失敗を奨励するには、きちんとした評価制度が必要と感じた
    • 質の低い失敗を繰り返さないように

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

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

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

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

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

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

第6章 コーディング段階

  • アルゴリズムのスピード
  • テストしやすいコード
    • ユーザにテストさせない
  • 邪悪な魔法使い
    • ウィザードについて
    • 何やってるか自分でわからないものは使うな

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

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

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

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

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

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

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

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も人が増えてきて評価制度を整えないとという状況なので、こういった視点を取り入れるように提案していきたい。

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

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

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

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

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

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

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

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

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

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

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

不安定な品質

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

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

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

教育不足

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

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

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

slide-53.jpg

全体を通しての感想

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

おわりに

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

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

2016年の振り返り

あけましておめでとうございます。

年末はなにかと忙しくて2017年になっちゃいましたが、2016年を振り返っておこうと思います。 2017年の抱負はまた後で書きます。

massa142.hatenablog.com

エンジニア

Python

2016年はこれまで以上にPythonにハマっていきます。

SQUEEZEに転職してPythonで仕事するようになったし、Pythonにどっぷり浸かることができた。

やればやるほど奥が深くて面白い。自分が苦手なネットワーク周りの低いレイヤに関する知見を2017年は勉強していきたい。

Pythonの各項目別の達成度は以下の通り。

転職前まではPythonの勉強のために読み進めてたけど、春以降はやらなくなった。

転職して英語のドキュメントに抵抗はなくなったし、必要になったもの/興味が出たものを引き続き読んでいけばOKかな。

flake8プラグインを作ろうかなと思ったけど、去年はできなかった。業務で必要になったら作ろう。

  • PyCon JP 2016のスタッフを引き続き頑張る

2016の会場チームは経験があまりないメンバーが多かったので、多少なりとも自分が引っ張ることができてよい経験だった。また寺田さんと一緒になる時間が増えたことで、仕事の進め方・周囲の巻き込み方などを勉強することができた。

PyCon JPのスタッフ活動からは、技術以外の大事な社会人スキルをたくさん学べている。

YAPC::Hokkaidoのあらたまさんのtweetはとてもしっくりきた。

ただPyCon Jp 2016に関しては、家庭の事情でカンファレンス2日目に参加できなかったことが心残りで不完全燃焼。

それでトークもキャンセルせざるを得なかったのは残念だった。2017はやりたいことやって完全燃焼できるようにしたい。

転職などでばたばたして休止していたもくもく会を10ヶ月ぶりに再開できた。

mokupy.connpass.com

けど結局2016年はこの1回だけになってしまったので、2017年はなんとか毎月開催を再会したい。

  • PyCon APAC 2016に参加する

初めて海外カンファレンスに参加した。

めちゃくちゃ楽しかったし、Python・カンファレンス運営の勉強になったので、2017年もPyCon APACにぜひ参加したい。

massa142.hatenablog.com

英語

SQUEEZEは公用語が英語なので、英語学習にはとても良い環境だった。

おかげで英語のドキュメント・リスニングに対する抵抗感はほとんどなくなった。

ただ話すほうは挫折した。

日本人比率も下がるしなんとか頑張りたいけど、英語に対するやる気と技術に対するやる気が両立しないのが難しい。どうするのが自分にとっていいのか模索中。

まあ英語な環境を楽しめているんで、焦らず気長に取り組んでいきたい。

アウトプット

ブログ

Qiiita

2015年と同じでAdvent Calendarの時期にアウトプットが集中したかな。これこそAdvent Calendar駆動開発。

量をこなせるようになったので、2017年はもっと質にこだわりたい。

また日報を11月から始めた。

wikihub.io

無理をせずに継続することを大事にしてるので2・3日おきの更新にはなってるけど、

  • 作業ログ
  • 感情の整理
  • アウトプットの練習

としてとても役立ってる。

飽きっぽい性格なんで3日坊主で終わるかと思ったけど、ゆるい感じのやり方が性に合ってたみたい。

この1年間の振り返りと日々の日報の中間的な存在として、2017年は毎月ごとに振り返りをブログでやっていきたい。

ラクロス

2016年のAdvance-Hanglooseは弱かった。

自分がAdvanceでプレーし始めてからチームは上昇しつづけてきたけど、去年ははじめて挫折を味わった。1勝もできずに、入れ替え戦にも破れて2部降格。

自分の反省としては、「幹部に頼ってしまい責任感がなかった」

もっとラクロスに真剣に向き合って取り組まなくては。

今年は久しぶりに幹部もやるので、Advanceが再び強いチームになるための礎を築きたい。

Perfume

2016年参戦記録

2016年はラクロス部とPyCon JPにもPerfumeの輪を広げることができてよかった。

日々の暮らし

  • 心と体を整える

体のメンテナンスがだいぶできた。

体の調子がいいと心の調子も良くなる。

  • 月2万ずつの貯蓄

貯蓄全くできてないけど、月2万の保険に入ったからよしとする。

  • 家計簿をつける

つけてない。けど現金で払うことがほとんどないから家計簿いらないかな。

お金に向き合うための別の方法を考える必要あり。

観に行った映画

今年振り返ってみて

良かったこと

  • SQUEEZEへの転職
  • 尊敬できるメンバーと出会えた
  • 業務外で手伝える会社に出会えた
  • Vue.js・Angular.jsのコミュニティに関わった
  • 技術本をたくさん読んだ
  • Steins;Gateを今更観た
  • ボルタリング始めた
  • 真田丸最高だった

悪かったこと

  • 発表をほとんどしなかった
  • 12月以外でのアウトプットが少ない
  • アウトプットにRockとエモさが足りない
  • 読書ログがない
  • 西武ライオンズが弱い
  • 相変わらず朝が弱い
  • 家族との時間が少ない