2018-11-06

エンジニアのためのキャリアパスを読んだ

技術書読書感想

最近発売され、話題になっていたエンジニアのためのマネジメントキャリアパスを読みました。

エンジニアとしてまだまだ技術的に未熟なので、ソフトウェアよりの勉強ばかりしているのですが、自分の年齢を考えたときに、マネジメントについても知見が必要になってくると思い、購入しました。

この本は、題名の通り、エンジニアのマネジメントキャリアパスについて書かれています。

メンターから始まりテックリード、人の管理、チームの管理、管理者の管理、経営幹部、文化構築と、各職責ごとにどのように振舞うべきかを教えてくれます。

あくまでエンジニアのキャリアパスであって、他の業種のマネジメントとは異なりとにかくどの職責でも技術に関しては、おざなりにしてはいけないことを強調しています。

特に印象的だったのはブリリアントジャークについてです。

ブリリアントジャークとは、

自己中心的で周りから恐れと嫌悪の入り混じった気持ちを抱かせる。

技術力は高いがそれにしがみつき、技術力以外は認めない

仕事はできるのでやめさせるのは至難

こう言うエンジニアってたまにいる気がしますね。

これの解決策は、第一に雇わないこと、だそうです。

（しっかり対応策も書いてありますよ）

なかなかのボリュームなので、全部読むのはそれなりに時間もかかりましたが、とにかくマネジメントは最初から誰でもできることではなく、向上させる必要があることがわかりました。いきなりできる人なんでそりゃいませんよね。

とても実践的な内容が書かれているため、昇進することがあれば、また読むことになりそうです。

2018-10-31

ポモドーロテクニックを実践中

技術書勉強方

最近、試してみたい技術が多くなってきて収集がつかなくなってきました。

積読本も多く、消化しなくちゃと思いつつ、良さそうな本があれば買ってしまします。

今はRubyとRuby on Railsを中心に勉強していますが、フロントエンドも面白そうなのでTypeScriptとReactも少しずつ勉強しています。

Reactの次はVue.jsもやりたいし、またGoはこれからも需要が伸びるはずなのでそろそろやりたいと思いつつ、DockerやAWSLamda、Firebaseなども押さえておきたいと思う今日この頃。（CIツールやwebpackもまだまだ未着手）

時間がいくらあっても足りないです。

ウチは妻もフルタイムで働いているため、家事は折半しています。

私の一日は

・朝5時半起床

・6時に子供を起こし、家族分の朝食を用意する。

・自分の昼食の弁当を作る

・子供を着替えさせ、保育園に送り出す。

・出勤

・17時半定時なので、18時半ころ帰宅（残業はほぼないためだいたいこの時間）

・子供をお風呂に入れる

・晩御飯作る（妻と半々）

・食器洗う（妻と半々）

・洗濯（妻と半々）

・子供の寝かしつけ（パパとじゃないと寝てくれない）

ちょっと家事が多い気が、、、、

まあこれ全部終わって、だいたい21時くらいから自分の時間になります。

起床が早いので23時半には寝たいので、だいたい２時間くらいがパソコンに向かえる時間となります。

で２時間あっても、妻と会話することもあるし、SNSみたりして、結構集中できない場合もあり、思うように進まないことが多いです。

そこでポモドーロテクニックを試してみることにしました。

ポモドーロテクニックは以下のサイトを参考にしました。

www.lifehacker.jp

25分集中、休憩を繰り返すことで、短いダッシュを繰り返し生産性をあげるテクニックとのこと。

今週から始めてみたのですが、結構いいですね。

25分タイマーをセットし、その間は対象の勉強以外のことはしなよう意識するだけで集中力が上がるような気がします。

また今まで1〜2時間技術書読んでたりしてましたが、時間を区切ることで、25分で自分がだいたいどれくらい技術書を読めるのか、コードはどれくらい書けるのかわかるようになってきました。

なので、30分くらい暇があれば、どれくらい作業を進められるか感覚的に掴めるようになるので、簡単な工数見積もりの精度が上がるような気がします。

まずはこのテクニックを使い、１日に２つの技術書を読んでいくようにしています。

25分、2セットで１つの技術書を読んで、次の2セットで別の技術書を読む。

これで集中して2冊を進めていっています。

しばらくはこのまま進めてみようと思います。

2018-10-26

リーン・スタートアップを読んだ

ビジネス読書感想

ソニックガーデンの倉貫さんのブログが好きでよく読んでいてリーンスタートアップというものに興味を持ったのでエリック・リース著のリーン・スタートアップを読みました。

新しいことを始める場合に、成功させるために何をするべきか、どのようにすれば失敗する確率を下げることができるか、また失敗しても被害を最少にできるかなど、サブタイトルの通り、ムダのない企業プロセスについて書かれた本です。

顧客の本当に望むものを作るため、小さくはじめて検証しフィードバックをもらいながら製造していく。

そうして出来上がったものが本当に顧客の欲しいものであり、顧客が求めてないものは全て無駄な機能であり、時間とお金の無駄であると。

事業を進めるために、仮説を検証し、事業が成功しているかどうか定期的に調査し、正しければそのまま続け、誤っていれば方向転換（ピボット）を行うことが必要。

また色々な起業家たちの成功した背景を探り、そこから何が成功の秘訣になったかも書いてあります。

また成功談の裏にはそれより遥かに多い数の失敗した起業家たちがいることにも言及しています。

起業家だけでなく、社内での新しいプロジェクトを立ち上げる場合にも有効な手段だとも書かれています。

最初にガチガチに仕様と工数を決めてしまうウォーターフォールの開発に従事している自分としては、このような顧客ファーストな開発手法に憧れますね。

2018-10-22

RubyでStruct.newを使って構造を包み隠す

Ruby プログラミング

今日読んでたオブジェクト指向設計実践ガイドでStruct.newについて学んだのでメモのつもりで記録しておきます。

以下のコードは時価総額を計算する簡単なものとします。

class MarketCapitalization
  attr_reader :data
  # 初期化
  def initialize(data)
    @data = data
  end

  # 時価総額計算
  def calc_market_capitalization
    data.collect do |cell|
      # 株価 * 株数
      cell[0].to_i * cell[1].to_i
    end
  end
end

# [0]に株価、[1]に株数とする
data = [[100,500],[200,1000],[300,320]]

mc = MarketCapitalization.new(data)
puts mc.calc_market_capitalization

このコードの場合、calc_market_capitalizationメソッドが、配列の構造を知っている前提になっているので、例えばdataの[0]に銘柄コードなどを差し込んだ場合、メソッド内の配列の要素数を変更する必要が出てきます。メソッドが一つだけなら修正も容易ですが、このdataを多岐に渡って使用している場合、あちらこちらを修正する必要があります。

そこで、Struct.newを使い、以下のように修正します。

class MarketCapitalization
  attr_reader :stocks
  # 初期化
  def initialize(data)
    @stocks = stock_assign(data)
  end

  # 時価総額計算
  def calc_market_capitalization
    stocks.collect do |stock|
      # 株価 * 株数
      stock.price.to_i * stock.num.to_i
    end
  end

  StockInfo = Struct.new(:price,:num)
  def stock_assign(data)
    data.collect do |cell|
      StockInfo.new(cell[0],cell[1])
    end
  end
end

# [0]に株価、[1]に株数とする
data = [[100,500],[200,1000],[300,320]]

mc = MarketCapitalization.new(data)
puts mc.calc_market_capitalization

Structクラスを使い、stock_assignメソッドの中でArray配列をStruct配列に変換しています。これによって、calc_market_capitalizationメソッドでは配列の要素数を気にすることはなくなりました。 dataの要素数が増えた場合、このstock_assignメソッドのみを修正すれば、他の処理に影響することはなくなります。