Masteries

技術的なことや仕事に関することを書いていきます.

「学びを結果に変えるアウトプット大全」読んだ

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

どこかのブログで紹介されていて, タイトルだけ見て「面白そうかも...?」と思って買った本でした. ここ最近, インプットについて良いリズムで取り組めるようになったので, 改めてアウトプットにも目を向けてみよう, と思ったのでした.

著者は精神科医で, 実際に本の執筆だったり, メルマガやYouTubeなどで本書に書かれているようなアウトプットを実践されている方です. 著者が精神科医ということもあってか, 「エンジニアの知的生産術」と同じように, 脳科学などの研究結果に基づいて, より良いアウトプットの方法が説明されています. "アウトプット"と言うと, エンジニアであればブログを書いたり勉強会で発表したり, そういうのを連想しがちですが, 「他人とのコミュニケーション」も"アウトプット"の一環ということで, 他人に対して説明をしたり, 説得したり, あるいは褒めたり叱ったり謝ったり... といった内容にも触れられているのが印象的でした.

個人的には, 先に名前を挙げた「エンジニアの知的生産術」だったり, あるいは最近読んでいた「小さな習慣」や「ハーバード流交渉術」でも紹介されていた内容もいくつかあったので, それらの復習(思い出し)のように読むことが出来てよかったです.

また, これまで経験則で「こうやると良さそう...」と思っていたことについて, 科学的な裏付けなどが与えられたという感覚を得ることができました. 例として, 「何となく仕事に集中出来ない時はとりあえず"刺し身たんぽぽ"のような単純作業でエンジンをかける」という事をよくやっているのですが, これは研究でも効果があると調べられていて, 「作業興奮」と呼ばれているということ, 「作業興奮」に至るまでの時間は5分程度, ということを知る事ができました. これに基づけば, エンジンがかからない時のために, 日頃から(分割して)5分〜10分程度でできそうなタスクをストックしておくと, いざという時に役立つかもしれませんね.

また, 「判断の基準」の話も面白かったです. この本の著者は悩んだ時, 「ワクワクするかどうか」と「最初に思いついた方を選ぶ」という軸で判断をしているそうです. 後者については「ファーストチェス理論」というものがあり, チェスのプレイヤーに盤面を見せ, 5秒後と30分後にそれぞれ次の手をどうするか問うと, 86%が一致した(つまり, 5秒で直感で決めた答えと30分かけて熟考した答えは86%で一致した)という研究成果も紹介されています. 個人的には, とにかく後悔しないように, 「判断して, やると決めたらやりきる」よう心がけていますが, その手前として「判断する基準」を自分の中で作って定めておくのも大事そう, と気づくことができました.

Twitterやブログにテキストを書き出すのはもちろんのこと, 仕事でコードを書いたり, ミーティングや雑談で他人と会話したりするのも立派なアウトプットです. そこに課題を感じていたり, あるいはもっとクオリティを高めてみたい, と思っている人は, この本をサックリ読んでみると得るものがある... かもしれません.

次は id:shimobayashi さんにオススメしてもらった「失敗の本質」を読む予定です.

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

  • 作者: 戸部良一,寺本義也,鎌田伸一,杉之尾孝生,村井友秀,野中郁次郎
  • 出版社/メーカー: 中央公論社
  • 発売日: 1991/08/01
  • メディア: 文庫
  • 購入: 55人 クリック: 1,360回
  • この商品を含むブログ (304件) を見る

「Gotanda.EM #2」で1on1について話しました

「Gotanda.EM #2」で1on1について話しました.

papix.hatenablog.com

今期からシニアエンジニアになって, これまで1on1をしてもらうだけの側から, 1on1をしてもらいつつ, 自分もメンティーを持って1on1をする, という立場になりました. これまでの1on1体験を踏まえて, 新米メンターがどういうポイントを意識して1on1に望んでいるか, というところまとめてみました.

1on1, 難しいですが, 個人的には楽しい(得るものが多い)と思ってて, とはいえ現状で満足せずに, メンターもメンティーもより多くのものを得られるように改良していきたいと思っているので, 良い知見などあれば是非教えてもらえると嬉しいです.

はてなにおける1on1制度については(資料でも触れましたが)この辺りのエントリが参考になりそうです:

developer.hatenastaff.com

blog.shibayu36.org

「仕事の問題地図」読んだ

仕事の問題地図 ~「で、どこから変える?」進捗しない、ムリ・ムダだらけの働き方

仕事の問題地図 ~「で、どこから変える?」進捗しない、ムリ・ムダだらけの働き方

会社のSlackで id:onk さんが推薦されていて, 面白そうと思ったのでさくっと読んでいました. チームで仕事をするにあたって現れる様々な問題点, 例えば「計画がない」, 「進捗がわからない」, 「モチベーション不足」, 「意見が出てこない」... それらに対して, どのようにアプローチしていくかについてのアイデアがまとめられた本です.

個人的には, 最初の「計画不在」の章が良かったと思っています. 昨今いろいろな計画を建てる機会が増えてきていて, どのように計画を作るか... というところで試行錯誤していたので, 良いアイデアを幾つか見つけることができました.

  • 構造化してみる
  • 計画表を書いて相談してみる
  • 未知か既知かを皆で判断する
  • 情報共有の旗振り役を置く

「構造化してみる」では, 仕事(タスク)を複数の段階に分けて構造化するアイデアが紹介されていました. 第1段階では命題(テーマ)を書き, 第2段階には目的を, 第3段階に目的達成のためのアクションを, 第4段階以降はそのアクションを成し遂げるために必要な細かな作業項目を, それぞれ"モレなくダブりなく"書き出していく... という形で構造化していく方法です. そこそこの規模のプロジェクトを開始するときは「インセプションデッキ」などのテンプレートが使えますが, 小規模〜中規模なタスクの計画であれば, この構造化を使った計画作りをうまく使えそうな気がします.

やはりチームで仕事をやっていくにあたって, 「銀の弾丸」と言えるものはなくて, 本書でも仕事をするにあたっての問題を文章化して図示して(地図にして)理解しやすいようにして, それに対する地道な解決案を示していく... という感じになっていて, 分析すること/それを元に手を打っていくことが重要そう, という気持ちになりました. とはいえ, そういう時に分析の助けとして, あるいは分析結果から次に打つアクションを考える種として, 本書があると「そういえば, 似たような内容が...」という感じにヒントとして使えそうです. また, 「はじめに」に書かれているように, チームでこの「問題地図」を眺めて, いま自分たちのチームにはどの辺に問題点がありそうか? と発見する目的で使うのも良さそうです.

そういう意味で言えば, 社会人になって2〜3年目くらい, 徐々に業務に慣れてきたタイミングでこの本を読めると, 視点が個人からチームに広がって良い影響があるのではないかと思います. 個人的には, ここ数年で視野が広がった感覚があるので, 「視野が広がった!」というよりは, 「視野が広がって見えてきた問題点に対して, こういう向き合い方ができるかな...?」と考えながら読むことができました. サックリ読めますし, 良い本だと思いました.

「Gotanda.pm #19」でJSONの話をしました

「Gotanda.pm #19」でJSONの話をしました. 普段何気なく使っているJSONですが, JSON, JSON::PP, JSON::XS, Cpanel::JSON::XS, JSON::MaybeXSとかたくさんのモジュールがあったりするので, それらの紹介や各種Tipsの紹介などをしました.

boolean_values でJSONのture/falseをPerlでどのように表現するかを変更出来る...という話をしたのですが, id:karupanerura さんからその実用例を教えてもらったり(受け取ったJSONを更にMessagePackに変更するとき, MessagePackのture/falseに対応したものをセットしておくと便利)とか, あとは id:kfly8 さんがCpanel::JSON::XSの特徴を話してくれたりとか, いろいろ学びがありました. あとは今更dualvalueのことを知ったりとか...

金曜日ということもあって(?)疲れがたまっていたのか, 懇親会はちょっとぐったりしていたのですが, 総じてPerlの話題が盛りだくさんで楽しい勉強会でした. また次回も参加したいと思います!!!

「失敗から学ぶRDBの正しい歩き方」読んでた

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

id:Soudai さんこと曽根壮大さんの「失敗から学ぶRDBの正しい歩き方」, ちまちまと読んでいました. 結論から言えばめちゃくちゃ良い本という感想で, これまでMySQLなどデータベースのアンチパターンについて本で学ぶ時には, 「SQLアンチパターン」が最良の選択肢といった感じでしたが, 「失敗から学ぶRDBの正しい歩き方」は, それと並ぶ立ち位置にある本だと思います.

SQLアンチパターン

SQLアンチパターン

「SQLアンチパターン」, 非常に良い本なのですが, どちらかというと初心者向けではなく, ある程度データベースを使ったプロダクト開発の経験を積んだ上で読んで, 「こういうアンチパターンがあるのか...」とか, 「これってあの時踏み抜いたやつだ...」みたいな感じで, 知識を整理する時に役立つ... という感想を持っています. それに対して「失敗から学ぶRDBの正しい歩き方」は, さまざまなアンチパターンに対して, どういう経緯で陥っていくのか...? という部分が物語っぽく紹介されていたりするので, 新卒入社のエンジニアとか, これからデータベースを学んでいくぞ! という人も, アンチパターンのイメージがしやすくなっているように思います. データベースのアンチパターンと向き合う最初の一歩として最適ですし, 「SQLアンチパターン」を読んで, まだとっつきにくいな... という感想を持った方は必読でしょう.

一方で, 「SQLアンチパターン」を既に読了した方からすれば, 「失敗から学ぶRDBの正しい歩き方」は若干の物足りなさはあるかもしれません. とはいえ, だからといって購入する価値が一切ないのか? といえばそうでもなくて, とはいえ新人教育などの場面で教本として「失敗から学ぶRDBの正しい歩き方」を渡し, アンチパターンを踏んだ時に「これは"失敗から学ぶRDBの正しい歩き方"にある, ○○というアンチパターンで...」と紹介する, みたいな使い方ができると非常に有用なので, そういう機会がありそうな方は一通り目を通しておく価値はあると思います(自分の場合は, 「こういうのあったなー」とか, 「あるある〜」みたいな気持ちで読み進めていました).

以下個人的な感想ですが, 著者の id:Soudai さんはかつて同僚で, とてもお世話になっていた(本当に頼りになる兄貴みたいな人で, 最近もちょっといろいろ相談させてもらう機会があったりしました)のですが, 違うチームで働いていた事もあり, 技術的な話題をみっしり伝授してもらう... という機会を作れないまま転職されてしまったのが, 個人的な心残りでした. 今回, この本を通して, id:Soudai さんからデータベースに関する知見を伝授してもらう事が出来て, 若干念が晴れたような気持ちを持っています. 会社は違いますが, これからも本や勉強会を通して, いろいろな知見を伝授頂きたいですね. 次の本も楽しみにしています!!!