ビットの海

ゆるふわソフトウェアエンジニアしゃぜのブログ

2020年振り返り

（結局簡単に書いとく）

これまで

2019年を振り返る - ビットの海

2020年の振り返り

  • コロナのせいもあるし、関係ないのもあるが、全般的にだめだめであった。
  • 仕事は雑に言うとデータ基盤周りと、検索基盤周りのことをしていた。
  • プライベートでいうと子供が+1
  • 振り返りと目標を書く気にならないほどにだめだめ

2020年毎月の振り返り

会社のブログ書いた

qiita書いた

ただのメモだが

子育てソフトウェアエンジニアの継続的な学び方のエッセンス

この記事は 子育てエンジニア Advent Calendar 2020 の 7日目です。

はじめに

  • コロナ渦での働き方、みたいな話は世に溢れていると思うのでしません。
  • 子育てエンジニアも、自分のモチベーションを大切にして、学びを続けるための自分の工夫について書いてみます。

昨年からのアップデート

shase428.hatenablog.jp

^ は2019年の記事です

  • 家族構成のアップデート
    • 子どもが+1したので、3歳（♂）と0歳（♀）の2児の父となりました 🎉
    • 夫婦、子ども2人の4人家族です。
    • 私(36歳)、新卒でIT業界に入ったのでなんやかんやで14年も仕事してる、転職は2回ぐらいしています。いまはEdtech企業でデータエンジニアをしています。
  • 働き方のアップデート
    • 例によって、ほぼフルリモート生活になりました。
    • 都内オフィスに行く頻度は月1回あるかないか、というレベルです。
    • 自宅の片隅に作業スペースをつくってひっそりと仕事をしています。

子育てソフトウェアエンジニアあるある

子どもがいると、人生の主役の交代、そこまで言わなくても生活の中心が子どもになりがちだと思います。

必然、自分の学びというのは後回しになりがちです。

とはいえ、日進月歩のIT業界

この10年で、仕事の仕方（使っている技術、文化）は大きく変わってきましたし、この先の10年も大きく変わっていくことでしょう。

自分が新卒だった時代にトレンディだった技術は枯れたり、使われなくなったりしていて（もちろん変わらないものも多くありますが）、「ふつうに仕事をする」これだけでも常に知識のアップデートが必要だなと感じことが多いです。

（ここでいう「ふつう」は 「世の中的なスタンダードな技術や知識」を指します）

また、インターネットの高速道路を通った優秀な若者は、30代/40代よりも現在の環境にうまく適応できることが多いように思います。

そういったとき、10年選手は「経験がある」「昔学んだ」だけでは、おそらく日々の仕事すら難しいでしょう。やはりエンジニアとしての継続的な学びが必要だと感じます。

学びの方法論

方法論は世にいくらでもあると思うので、個人的にやっていることについて簡単に書きます。

まず、学びたいと思っているテーマを書き出してみます。その中で、仕事で短期的に必要なこと、仕事で短期的には必要ではないことに分けてみます。

仕事で短期的に必要なこと、は、あまり工夫をしなくてもインプットが捗ると思います。これは、仕事というアウトプットの機会、仕事というモチベーションの後押しがあるからです。

（逆説的ですが、学びたいと思っている分野があるのであれば、それを仕事にしてしまうのが手っ取り早いです。もちろん、それが難しいケースも多いですが）

問題は、仕事で短期的に必要ではないが、長期的に自分の好奇心やキャリアのために学びたいと思っていること、これが意識的に工夫をしないと学びが進まない領域だと思います。

失敗したこと

ここ数年を振り返って失敗したと思っているが、学ぶことの取捨選択のやり方、です。

子育てエンジニアは時間が無いので、どうしても学ぶことの取捨選択を強いられます。去年の記事にもそのようなことを書いたのですが、この取捨選択のやり方で失敗したと感じることがありました。

自分の好奇心よりも、世の中のトレンドとしてやるべき、とか、一般的に考えてやるべき、みたいな外部環境的なモチベーションのものを「やることリスト」の上の方にもってきてしまいました。

この結果起こったことは、単純な学びの停滞でした（笑）

時間が無いのはどうしようもないのですが、そもそものモチベーションを殺してしまっては何にもならないのですね。

どうしても外部環境的なモチベーションを、内部的なモチベーションにつなげたいときには、テーマ同士を融合できないか、頭を悩ませることもあります。

苦手なことの学び

学びが進まない分野があるかと思います。

そういった分野は（自分にとっては数学なんですが、笑）切り口を変えてみる努力をしています。

例えば、入門書を読んでもわからないとしたら、別の入門書を読んで見る、雑誌の特集（読みやすい）を読んで見る、などです。また、分野によっては、Youtubeで良質なコンテンツもあったりするので、概要を掴むのに重宝しています。

学びでうまくいったこと

コロナでの在宅勤務により、狭いながら自宅での作業スペースを用意することになりました。

これによって、以前よりも学びのペースが確実に上がったと感じます。

これはコロナによる嬉しい誤算でした。自宅で作業できるスペースは本当に大切です。

他人と比べない

子育て中はなかなか自分の学びの時間を取るのが難しいと思います（自分も上の子が0歳のときは、正直何もできていませんでした）。

ペースがつかめてくると、どうにかこうにか、深夜や早朝など時間を確保できるようになる、という感じだと思います。

人と比べると辛くなるだけなので、昨日の自分、去年の自分との差分で、変化を見ていったほうがモチベーションを殺すこと無く継続できると思います。

まとめ

  • 子育てエンジニアにとっても継続的な学びは大切だと思います。
  • 学ぶテーマは自分の好奇心を大事にしたほうが継続的な学びにつながりやすいです。
  • 他人と比べず、過去の自分と比較するようにして、自分のモチベーションを殺さないように工夫してがんばっていきましょう。

学び方で参考になった本

各方法論は各書籍を読んでいただいたほうが良いと思います。

2020年11月の振り返り

振り返り

ひとこと

  • 10月死んだメンタルとフィジカルが徐々に戻ってきた
  • 技術書読もう活動は、パラパラ読んでる他の技術書もあるんだけど、なんか読み切ったのはエンジニアの自己啓発系が多くなってしまった。これでちょっと元気++になった部分もあるんだけど、こういう自己啓発ばかり読んでいると胃もたれ感もあるので、しばらくはもういいや。

読みかけ

読んだ本

2020年10月の振り返り

振り返り

10月

  • 仕事とプライベートでつらいことが立て続けに発生してしまってとてもつらい。
  • 自分でコントロールできる部分をがんばって、あとは流れに任せるしかないんだけど。
  • メンタルとフィジカルでいろいろあって、日々の勉強みたいなのが止まってしまった。とりあえず両方治そう。

読みかけ本

読んだ本

「稼働率」と「人材価値」に関する話

（とりとめのない散文です）

IT業界というところにいると、「稼働率」というキーワードが時々出てくる。

受託の会社にいるときは、SEを遊ばせておかないように案件アサインをする、という文脈だったり（それが組織のKPIになっていた）。

小さな事業会社（中小企業、ベンチャーなど）にいるときは、黙っていても（ただでさえ少ない）人件費として資本が流出するのに恐怖し、少しでもKGI/KPIに貢献することをやらせ「続け」ようという背景があったり。

資本に余裕のある比較的大きな会社や、経営者が「稼働率」というキーワードに思うところがあるような場合だと、このキーワードはあまり出て来なかったな、と今では思いかえされる。

（今の職場ではほぼ聞かない単語だ）

さて、これは小さな会社に居たときの話で、自分は開発リードのような仕事をしていた。その会社の経営者は、メンバーの稼働率（手持ち無沙汰で遊びが無いこと）にとても関心を払っていた。

どうしていたかと言うと、メンバーに遊びが生まれないように、案件のバックログを積み重ねていた。メンバーは日々忙しく仕事をしていた。

ところが、リリースされた案件のクオリティや、リードタイム、KPIに対する効果は、現場視点から見るとあまり芳しいものではなく。

これをうまく説明できなくて、個人的にはモヤモヤしていたのだけれど、以下の記事に出会い、部内のフリートークの場で紹介してみた。

brevis.exblog.jp

「工程があって、個々の稼働率を高めても、全体のスループットは出ないことがある。品質もあまりよくならないらしい。」そんな話をしたような記憶がある。

自分の説明も拙かったというのもあり、結局、周囲にあまり理解されたような気はしなかった。経営者は分かったような、分からなかったような顔をしていたのを覚えている。

（理論をうまく説明できるという話と、プラクティスとして実践できるというのには大きな隔たりがあって、IT業界でよく遭遇することなんだけどそれは別の機会に書きたい）

ときは少し流れて、2017年くらいから、日本のIT業界でフロー効率とリソース効率の話題が出始めた。

t-and-p.hatenablog.com

This is Leanで紹介されている概念で、トヨタ生産方式とかリーンに詳しい人なら自明だったのかも知れないけど、自分のような普通のIT業界の住人にとってはちょっとした「発見」だった。

今にして思えば、あのときの経営者はリソース効率の話をしていて、自分はフロー効率の話をしたかったんだな、という。

ただ、あの時代に戻っても、This is Learnの理屈であまり経営者に納得してもらえる気はしていなくて、根本には人材価値みたいなのが、資産として会計上見える化されていないのが問題だと思っている。

どういうことかというと、リソース効率性を追求した時に、リーンでは良いこととされる「遊び」が発生し、現場の人間は学習の機会などに当てられるわけだけど、多分経営者から見ると、この「遊び」に価値を感じにくいのだと思う。

そしてその根本には、定量化しにくい（会計上表現しにくい）「人材価値」という問題があると思っている。

brevis.exblog.jp

^ ここで語られている通り、本当は会計上「人件費を繰延資産として資産計上する」「人件費の一部は労働の対価ではなく、職務能力のビルドアップ投資と考えてもよい」と考えて貰えれば良いんだけど、世の中はきっとそうはならないので...。

ぼくらは現場で、見えにくい人材価値みたいなものを、手を変え品を変え発信し続けることが必要なんだろうなー、と思ったという話。

Mac に Terraform を Install して、GCP の IAM を操作するまでのメモ

前提

  • Terraform用の適当なディレクトリを作成してそこで作業しているものとする
  • GCP Projectはまっさらな状態。Project名はfoobar

Terraform Install

$ brew install hashicorp/tap/terraform
$ terraform --version
Terraform v0.13.3

最新版にしたいとき

$ brew upgrade hashicorp/tap/terraform
$ terraform --version
Terraform v0.13.4

とはいえ、tfenv使うほうがいいのかなーと思ったりもする

追記 : tfenv のメモ

$ brew install tfenv 
$ tfenv install 0.8.0 # or latest
$ tfenv use 0.8.0
$ echo 0.7.3 > .terraform-version # 引数なし tfenv install でそのバージョンがインストールされる

Create Service Account & Key

Terraform用のService Accountを作成して、JSONキーをダウンロードしておく

gcloud cli setup

# configの作成
$ gcloud config configurations create foobar-terraform

# projectのset
$ gcloud config set project foobar

# accountのset
$ gcloud config set account terraform@foobar.iam.gserviceaccount.com

# 設定の確認
$ gcloud config configurations list

# アカウントのactivate
$ gcloud auth activate-service-account terraform@foobar.iam.gserviceaccount.com  --key-file /path/to/foobar.json

tfstate用のGCS Bucket作成

gsutil mb -c regional -l asia-northeast1 gs://foobar-terraform-bucket

バージョニングの有効化

gsutil versioning set on gs://foobar-terraform-bucket

ライフサイクルの設定

$ cat foobar_terraform_bucket_lifecycle.json
{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type": "Delete"
        },
        "condition": {
          "numNewerVersions": 3
        }
      }
    ]
  }
}

$ gsutil lifecycle set "foobar_terraform_bucket_lifecycle.json" gs://foobar-terraform-bucket

export GOOGLE_CLOUD_KEYFILE_JSON

JSONキーファイルパスを以下の環境変数に渡す

export GOOGLE_CLOUD_KEYFILE_JSON=/path/to/foobar.json
export GOOGLE_APPLICATION_CREDENTIALS=$GOOGLE_CLOUD_KEYFILE_JSON

Write main.tf

provider "google" {
  project = "foobar"
  region  = "asia-northeast1"
  zone    = "asia-northeast1-a"
}

terraform {
  backend "gcs" {
    bucket  = "foobar-terraform-bucket"
  }
}

init

$ terraform init
$ terraform plan
$ terraform apply

tfstateがgcsに上がってる

$ gsutil ls gs://foobar-terraform-bucket/
gs://foobar-terraform-bucket/default.tfstate

Create Service Account

$ cat serviceaccount.tf
resource "google_service_account" "bq_test_user" {
  account_id   = "bq-test-user"
  display_name = "bq-test-user"
}

resource "google_project_iam_member" "bq_test_user" {
  count = length(var.bq_test_roles)
  role   = element(var.bq_test_roles, count.index)
  member = "serviceAccount:${google_service_account.bq_test_user.email}"
}

variable "bq_test_roles" {
  default = [
    "roles/bigquery.user",
    "roles/bigquery.jobUser"
  ]
}
$ terraform fmt
$ terraform plan
$ terraform apply

tips

  • module の upgrade
    • terraform init -upgrade