ビットの海

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

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

2020年7月-9月の振り返り

7月

  • 育休
  • 余計なことは考えず家事と育児に専念
  • 卵焼きがうまくなる
  • 料理全般は別にうまくならない

8月

  • 社会復帰(相変わらず在宅勤務)
  • 技術的なことって楽しいですね(こなみかん)
  • Elasticsearchチョットダケがんばる

9月

  • 公私ともに、上期色々振り返り、下期やっていくことを考えた
  • 人工知能やっていきな気持ち
  • とりあえずはやっぱり数学かなぁ

読みかけ本

読んだ本

「最強のデータ分析組織 なぜ大阪ガスは成功したのか」を読んだメモ

全般的な感想

  • 非IT企業におけるデータ組織の成功事例としては多分稀有。
  • 筆者が研究所出身で、その思考にも納得感がある。
  • 予算のオーナーシップ制度は、筆者は肯定的だが、自分は功罪あると思っている。が、きっとこの事例の大阪ガスであればうまくワークしているのかもしれない。
  • 分析者(アナリスト)が「育つ」「自立する」ってやっぱりエンジニアと似たように大変だなーとは思う。
  • 後半にオージス総研から出向者が来ていていろいろやってもらっている、と書いていて、やっぱり少人数チームで繰り返しオペレーションみたいなの回すの無理だよねーと思ったりした。
  • 個人的にはやっぱり伝統的日本企業めんどくさい...という気持ち。

印象的だった部分

第1章 ビジネスアナリシスセンターの実像

私たちのチームは当時、"個人商店"の集まりのような状態でした(中略)これでは個人の存在意義は認められても、チームとしての存在意義は薄いままです。経営の視点に立ては、そんなチームの戦力を増強しようとは思わないでしょう。
(中略)
そこで私はメンバー間でチームのミッションやアクションについて共通認識を持つため、それらを書面にまとめました。単にまとめるだけでは読み捨てられてしまうので、メンバーの意見も聞き入れながら論文にまとめ、メンバー全員の連名で学会誌に投稿しました。
(中略)
タイトルは「企業においてデータからの情報形成力を強化するのに必要なミッションと推進体のあり方」です。
「万が一、大阪ガスが倒産しても、年収OO万円の仕事に就けるだけの人材に全メンバーを育てます」。他社から求められるほどの人材に育てることを自らの責任としたのです。

第3章 事業部門から信頼と予算を勝ち取る

  • 責任には結果責任と説明責任があり、両者はトレードオフ
  • 高度な分析手法を用いて予測精度を上げると意思決定の結果は良くなる一方で、意思決定の根拠を説明するのは難しくなる
  • 単純な分析手法を用いた予測をすれば、意思決定の根拠を説明することは簡単だが、予測精度は低いので意思決定の結果は芳しくない
  • 人は両方を鑑みて納得できれば予測結果を受け入れる。
    • メンテナンス担当者は的中率60%の結果責任を負えないが、80%であれば、説明責任を果たしにくくても結果責任を負える。
  • 担当者が覚悟できる水準とは絶対的なものではなく、現状と比べた相対的なもの。

第4章 分析組織は経営に必ず貢献できる

  • 相対的に見て貢献度が大きくなるのは「未開拓のエリア」と「大金が動くエリア」
  • 全方位外交で、特定事業に依存することを避ける(データ組織のポートフォリオ経営)

第5章 メンバーの幸福を勝ち取る

  • 成長を促してくれる仕事の必要条件とは「責任」と「成果」が明確であること
  • 仕事のアサインを「解く」だけでなく、「見つける->解く->使わせる」の一気通貫にする
  • 事業部門でできることは断る

第6章 十八年かけて築いた三つの無形資産

  • ミッション、カルチャー、レピュテーション
  • 社内向けレピュテーションは一朝一夕で築けないので他社に対する競争力の源泉となる
  • 縁の下の力持ちスタンス、メディアに露出するときも現場となるべく一緒に、手柄の独り占めにみえるようなことをしない

MacでJDK切り替えるメモ

いつも忘れるので

install versions

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    11.0.2, x86_64:     "AdoptOpenJDK 11"       /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
    1.8.0_202, x86_64:  "AdoptOpenJDK 8"        /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home

ちなみに、 /usr/libexec/java_home の実体は /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java_home にある。

change

11.0.2から1.8.0_202にするとして

export JAVA_HOME=`/usr/libexec/java_home -v 1.8.0_202`

$ java -version
openjdk version "1.8.0_202"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)

^ は現在のセッションのみのなので、必要であれば、 ~/.zshrcなどに書いて V sourceする

export JAVA_HOME=`/usr/libexec/java_home -v 1.8.0_202`
export PATH=$JAVA_HOME/bin:$PATH