モノノフ日記

普通の日記です

達人に学ぶDB設計徹底指南書を読みました

仕事でDBの設計をするタスクが回ってきそうなので積読して置いたこちらを読みました。

大体やっていたことがきちんと言語化されていて「あー、そうそう」という感じでパラパラっとすぐ読めました。 すごく普通のことが書いてあるのだけれど、本の中でも正規化のところで触れられているように常識を定式化することが大事だよなぁと思いながら読んでました。 7〜9章が応用編という立ち位置になっていて、実際に設計するときにはこのあたりが勘所になる気がします。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

Amazon Web Services実践入門を読みました

なんとなくで使ってたので1冊AWSの本を読んでみようかなと思って手に取りました。 (実際には電子書籍で買ったので手には持っていませんが)

僕はオンプレミス環境でインフラっぽい仕事もいろいろやった経験があるので、 「へー、AWSだとこうやるんだ」という知識の置き換えをしながらサラサラっと読めました。

AWSの機能のそれぞれの役割を掴むには良い本だと思います。 あとAWSCLIのサンプルコードが書いてあるのもCLIを使う入り口としては良いのかなと思いました。 AWSには詳細なマニュアルは用意されていますがいかんせん物量がすごいので。。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

最近読んだ本

自分の読書メモとして書いておきます。

オンラインのチュートリアルやライブラリのコードを読んでてGo言語に興味が出たので2冊読みました。 プログラミング言語Goの方は言語の基本的な文法から特色であるinterfaceやgoroutineについて網羅されていて言語についての理解はこれ1冊読めばOKと言えそうな内容の本です。 個人的には各章に用意されている練習問題がなかなかやり応えがあって面白かったです。

みんなのGo言語はライブラリの紹介やライブラリ・CLI等の作り方について言及されていて、どのようシーンでGo言語を使うかという空気感がわかって良かったです。あとパラパラマンガが秀逸。

オブジェクト指向設計ガイドはRubyOOPについて語られた本でサンプルコードよりは説明となる文章が多く、読み物として読むのにはいいです。ただ説明がかなり丁寧で冗長な感もあるのでそこは好み分かれるかなぁという感想でした。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

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

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

Dockerを読みました

Docker

Docker

オライリーから発売されたDockerを読み終わりました。「コンテナとは」から始まってDockerの基本的な使い方や周辺ツールまで幅広く解説された入門書には最適な1冊だと思います。 自分もDockerのマニュアルを読んで手元で少し動かしてみた、くらいのレベルだったので大変参考になりました。

気になる点は誤字が少し多いことと原著が書かれたのが1.7の頃なので少し現状と違っている箇所があることです。 特にツール周りやSwarmのあたりが少し記述が古いような感を受けました。 本に書かれているサンプルコードは基本すべて動きますし、githubにコードも公開されているので手元で動かす分には全く困りません。

欲を言えば、AWSGCPで運用してみる実例とかまで踏み込んでもらえたら個人的にはうれしかったんですけどね。。

一人CTO Nightに参加してきました

~マネジメントに悩める全てのエンジニアにささげる~ 伊藤直也の1人CTO Night |転職ならDODA(デューダ) に参加してきたのでメモです。

話を聞いてて思ったのはいろんな本やサイトでマネジメントに関する知識をインプットして、それを現場で昇華していった感がすごかった。やはり自分にインプットするところから始めないとダメだなぁと再認識させられた発表でした。

TL;DR

開発組織マネジメントのコツ

  • 一休の話だけじゃなく技術顧問の経験を踏まえた話
  • 10000人とかの会社じゃなくて50-300人くらいの規模の想定
  • 今日はVP視点の話
    • VP of Engineering
    • CTOはこういう仕事をする人をつくろう
  • 組織マネジメントとヒューマンマネジメントの話にスコープを絞る
  • 問題を発見してメンバーに解いてもらう
    • 正しい問題を発見することに集中
    • 問題が発見できればマネージメントとしては成功

組織構造

  • 内製組織
    • エンジニア・セールス・プロダクトの横串
      • まぁ人が増えるともめる
    • 縦割りにしても問題は起こる
    • ハイブリッドな構造
  • ラーニングする構造にしないと意味がない
  • 日経
  • Kaizen
    • PMとエンジニアが1on1で仕事している
    • 実質チームとして機能してない
    • これもラーニング結果がチームに蓄積されない
    • チームとしてメンバーを助けられない
  • コントロールできる対象をマネジメント
    • 個々人の意識は無理
    • 組織構造はできる
  • 優先度を高いことを進めたいとき
    • 構造で変化

組織課題の発見とアプローチ

  • 心理的安全性と責任
    • チームが置かれてる状況でアプローチが変わる
    • ぬるま湯(仲良しグループ)
      • プロダクトマネージメントが必要
    • 売り上げあげてるチーム
      • チームビルディング

ヒューマンマネジメント

信頼を勝ち取る

  • トップマネジメントから信頼を勝ち取ると物事がスムーズに進むようになる
  • 時間はもちろんかかる

アンチパターン

  • 「文化を変えよう」は悪手
  • 変化にあたって現状否定
    • 敵を作る
    • 未来志向で説く
  • サーヴァント型リーダーシップ
    • Fate zeroを観ましょう

即効性のあるHow To

  • 1on1
  • 壁打ち相手
  • フレーミングをきちんと
  • 技術プロセスの課題解消

伊藤直也氏のマネジメントお悩み相談室 withソラコム 玉川憲氏

  • 事前アンケートを見ながらディスカッション
  • エンジニアの守備範囲を広げたい話
    • マインドを変えるのは無理
    • 1on1でお互いの守備範囲をすりあわせ
    • 日本の会社だと担当領域以外やると怒られる空気もある
  • 社内全体の思考を切り替える必要はないのでは
    • 一休もセールスの人はIT会社だと思ってない
    • エンジニアが解決すれば良い
  • マネージャーが調整業ばっかりに追われる問題
    • 1回調整地獄に落ちるのは仕方ないような...
    • 現場に一部負担してもらうやり方
    • 調整は仕事ではない
  • 1on1で技術力が上の人と困る
    • 「最近うまくやれてますか?」「あの揉めてたやつどうなった?」みたいな人の話が中心
  • 採用の話
    • コンテンツの魅力でひけるのは数社しかない
    • 知名度ない会社はエージェント頼みにした方がいいような
    • 外資はJob Descriptionをめちゃ細かく書く、日本は雑に書くところが多い
    • 一休の話
      • エージェントに流してる募集要項がひどかった
    • 採用する側の教育も重要
  • 古いやり方に固執して成長しないエンジニア
    • 新しいことやりたい人は少数
    • 業務知識は詳しい人もいる
    • 会社は多様である方が強い
    • ポートフォリオの問題
    • リーダーがこつこつやってると、文化ができていく
    • 今あるカードでどうにかする方がよい

ソフトウェア開発者採用ガイドを読みました

ソフトウェア開発者採用ガイド
Joel Spolsky
翔泳社
売り上げランキング: 296,816

Joel on Softwareで有名なジョエル・スポルスキーのエンジニア採用についての本です。 下記に挙げたような感じのことが書いてあります。(たぶん本買わなくてもオンラインで日本語訳さがせばあるかもです)

  • 待ってても良い人は来ないから取りに行きましょう
  • 履歴書の仕分け方法
  • エンジニア労働環境はベストなものにしましょう
  • 優れた開発者のふるい分け方法
  • チームマネジメント

本が刊行された2008年当時だと「日本だとないわー」みたいな話だったように思いますが、近年だと書いてある内容がそれほど日本の現状と現実離れしてるような気はしませんでした。