y.takky　てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

インセンティブが人を動かす 今日から使える行動経済学入門　を読んだ

社員総会の話が心に刺さらない理由

混合シグナルとしてのMVV・OKR・プロダクト価値

『インセンティブが人を動かす』を読んだ。

インセンティブが人を動かす　今日から使える行動経済学入門

インセンティブが人を動かす　今日から使える行動経済学入門

Amazon

感想をCHATGPTに投げてある程度まとめたものを記す。

この本を読もうと思った理由は、会社のインセンティブ設計に以前から違和感があったからだ。

会社では、ミッション・ビジョン・バリュー、全社目標、OKR、評価制度などを通じて「何を大事にするのか」が語られる。

ただ、現場で働いていると、会社が語る理念と、実際に求められる行動がズレているように感じることがある。

その違和感を説明する言葉として、本書に出てきた「混合シグナル」がかなり近いと思った。

社員総会の話はなぜ刺さらないのか

社員総会では、会社の方針や目標が語られる。

社員総会とは？2つの事例と目的や内容・必要な準備を徹底紹介

そこで話される内容は、たいてい正しくどれも否定しにくい。

しかし、それを聞いても心に刺さらないことがある。
場合によっては、むしろ反発したくなることすらある。 まあ自分はいつも反発しているような気もするが。

それはなぜか。

社員総会で語られる理念と、実際に評価される行動が一致していないように見えるからだ。

たとえば、会社は「長期的な価値を大事にする」と言う。
しかし現場では、今期のOKR達成が強く求められる。

会社は「チームで成果を出そう」と言う。
しかし評価では、個人として何を出したかが重視される。

このズレがあると、きれいな言葉は理念ではなく建前に見える。

会社は常にシグナルを出している

会社は、社員に対して常にシグナルを出している。

ここでいうシグナルとは、「この会社では何が重要なのか」を伝えるものだ。

たとえば、次のようなものがある。

  • MVV
  • 全社目標
  • 評価制度
  • 表彰制度
  • 昇進基準

ただし、人はきれいな言葉だけを見て動くわけではない。

実際には、

  • 何が評価されるのか
  • 何が報われるのか
  • 何が許されるのか

を見て動く。

つまり、本当のシグナルはスローガンではなく、評価や報酬や意思決定に表れる。

混合シグナルとは何か

混合シグナルとは、表向きに言っていることと、実際に評価される行動がズレている状態のことだ。

もっと簡単に言えば、

「こうしてほしい」と言っていることと、
「そうすると得をする」ことが一致していない状態

である。

この状態になると、人はだいたい後者に従う。

MVVや社員総会のメッセージは抽象的だ。
一方で、OKRや評価制度は具体的で、自分の評価や給料や昇進に直結する。

だから、会社が「長期的な価値を作ろう」と言っていても、四半期OKRの達成率が強く見られるなら、現場は短期目標を優先しやすくなる。

これは現場の人が冷めているからではない。
組織が出しているシグナルが混線しているだけだ。

OKRは目標を具体化するが、ズレも生む

OKR自体が悪いわけではない。

全社の方針を、事業部やチームの行動に落とす道具としては有効だと思う。

ただし、目標を具体化する過程で、上位の理念と下位の目標がズレることがある。

たとえば、全社では「顧客体験を高める」と言う。
しかし現場では「問い合わせ件数を減らす」が目標になる。

このとき、現場にはこういうシグナルが届く。

顧客に丁寧に向き合うより、問い合わせを減らした方が評価される

OKRの問題は、目標を具体化することではない。
具体化された目標が、上位の価値観と違う行動を誘導してしまうことにある。

長期価値と短期目標はぶつかりやすい

プロダクト開発では、長期的に価値のある仕事が多い。 たとえば、

  • 技術的負債の返済
  • 設計の見直し
  • テストの整備
  • ドキュメント化
  • 運用改善

これらは長期的には重要だ。 しかし、短期OKRや四半期評価には乗りにくい。 一方で、新機能のリリースや短期KPIの改善は評価されやすい。 その結果、長期的には価値があるが評価されにくい仕事は、現場の善意に依存しやすくなる。 これは危険だと思う。 本当に長期価値を大事にするなら、それは目標や評価に反映されるべきだ。 そうでなければ、長期価値は「大事だけど、余裕があればやるもの」になってしまう。

プロダクト価値と会社のMVVがぶつかる場合

プロダクトとしての価値と、会社のMVVがぶつかることもある。 たとえば、売上は上がるがユーザー体験は悪化する施策がある。
短期CVRは上がるが、長期的な信頼を損なう施策もある。

こういう場面では、MVVだけでは判断できない。 必要なのは、衝突を明文化することだ。 たとえば、こう問う。

この施策は短期KPIには効く。
しかし、長期的な信頼を下げる可能性がある。
今回はどちらを優先するのか。

こうすれば、感情論ではなく意思決定の問題として扱える。

MVVは具体的な判断基準にする必要がある

MVVは、そのままだと抽象的すぎる。

たとえば「ユーザーに誠実である」というMVVがあるなら、プロダクトの現場では次のように翻訳する必要がある。

  • ユーザーに誤解を与えるUIにしない
  • 料金や制約条件を分かりにくく隠さない
  • 解約や退会を不当に難しくしない
  • 短期CVRのために長期信頼を損なわない

ここまで落ちていないMVVは、現場にとってはスローガンに近い。

MVVを浸透させるとは、社員総会で何度も語ることではない。

具体的な判断の場面で、何を優先し、何をやらないのかを決められる状態にすることだ。

どうすればいいのか

混合シグナルがあるとき、現場ができることは、ただ不満を持つことではない。

大事なのは、優先順位の衝突として言語化することだ。

たとえば、

短期OKRと長期的な品質改善がぶつかる場合、どちらを優先するのか。

短期KPIには効くが、長期的な信頼を下げる施策を進めるのか。

チーム成果を重視するなら、レビューやドキュメント整備は評価対象になるのか。

このように、トレードオフとして提示する。

「これはMVVに反している」と言うだけだと、感情論に見えやすい。

混合シグナルは感情の問題ではない。
優先順位と意思決定の問題である。

善意で背負いすぎない

もう一つ大事なのは、評価されにくいが価値のある仕事を、個人の善意で背負いすぎないことだ。

技術的負債の返済、レビュー、ドキュメント整備、運用改善、品質改善。

これらは長期的には重要だ。

しかし、それが評価されない構造のままなら、やればやるほど自分だけが消耗する。

本当に重要なら、目標や評価に入れるべきだ。
評価されないなら、どこまでやるべきかを確認した方がいい。

善意で支える構造は、いつか壊れる。

まとめ

社員総会の話が心に刺さらないのは、理念が抽象的だからだけではない。

その理念が、OKR、KPI、評価制度、プロダクト判断、実際の意思決定とつながっていないように見えるからだ。

人を動かすのは、綺麗な言葉ではない。

何が評価されるのか。
何が報われるのか。
何が許されるのか。

そこに、本当のシグナルがある。

MVVを浸透させたいなら、言葉を増やすのではなく、評価・目標・意思決定と揃える必要がある。

ハッカーと画家 コンピュータ時代の創造者たち を読んだ

前書き

ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

Amazon

www.ohmsha.co.jp

前々から気になっていたが読む機会や時間が取れなかったのでやっと読めた。

エッセイを書籍化ってある通り、気になったところを引用・紹介していく。 基本的に書いてある内容に対しての紹介で引用・紹介は

引用 をつけて区別する

注意すべきところ

原文が2004年頃、訳が2004年の12月で出版が2005年1月なことに留意して読む必要がある。
そのためVue.jsやReactといった今主流のフロントエンドで使われる言語に関しては触れらていない。
同じようにGoやTypeScript,Rustといった新しい言語に関しては触れられていない。
また、生成AIなどに関しても出てこないので、新しいことを学ぼうと考えている人には不向きである。
あくまで2004年頃にどうだったのかというのところから考えを巡らせる必要がある。

1章どうしてオタクはもてないか/13章オタク野郎の復讐

  • いきなりお？ってなるタイトル
  • ここでのオタクはどちらかというとnerd的なもので、いわゆる日本でオタクって言われて思い浮かべるものとは若干違う

    • どちらかというとそれは freakに近いよね　という話がされている

  • オタクがもてないのは社会一般的なところとは別のところにステータスを振ってるから（ここのステータスはゲームとかのステータス)だなと。
  • ここ20年で ある種オタクの社会的な地位(?)が上がってきていてこの辺ってもはや当てはまらないのかなとも。

5章 もうひとつへの未来への道

  • アジャイルやスクラムといった言葉は出てこないけど、考え方はそれと同じだな。
  • デスクトップソフトウェアからWebベースへのアプリケーションへの転換というのはあの時代ではあまり考えなかったんだけど今では一般化されているな。
  • リリースに関しても小さく早く作ってリリースってのはアジャイルやスクラムで重要視しているところだよな。顧客の声を聴くってところも含めて
  • ユーザーを観察するっていうのも今では当たり前に行われているしこの時代でその考えに至れたのはすごいな

6章　富の作り方

  • よくパイを大きくすることはできないというけど、何かしら他の人に役に立つことで富は作り出される。
  • 金はあくまで抽象化しているだけであって富ではない。
  • ある種Vtuberも富を創り出しているし、(個人的にスパチャ文化はよくわからないが)スパチャを投げたりするのはある種富の交換なんだろうな
    • むしろスパチャに反応するというのが、ある種の富を作り出していることになるのかな
  • 測定と梃子が大事。小さいことで測定ができ新しい技術を発明してお金を儲けることが梃子になる

9章 ものつくりのセンス

  • 良いデザインというものが必要

  • 単純であること

    • 短い数学の証明が美しい

  • 永遠であること

    • 良いものは未来でも受け入れられる

  • 正しい問題を解決すること

    • ソフトウェアでは解くことが簡単な問題へと置き換えることが多い
    • 多分これは検索とか考えるといいのかな。アナログでやると目で見る必要があるけど、ソフトウェアにすると簡単な問題になる。

  • 想像力を喚起すること

    • これはあんまりよくわからんな。ユーザーが自分の思うとおりに組み合わせるようにした方がいいってあるけど。

  • しばしばちょっと滑稽(ユーモアがある)

    • これはamazonのエラーで犬が出てくるとかそういうやつかな

  • 良いデザインをするのは難しい

    • はい。

  • が簡単に見える

  • 良いデザインは対称性を使う

  • 良いデザインは自然に似る

  • 良いデザインは再デザイン

    • スケッチを書くように壊して作り直す

  • 模倣する

  • しばしば奇妙

11章 百年の言語/ 14章　夢の言語

  • この本がかかれてから百年のうち20%が過ぎたけどどうなってるだろうか。 ->プロセスを気軽に作ってそれがたまたま並列にはしるとかそういうものだろう -　厳密にいうと違うけどGoのgoroutineとかはそうよね。まああれは並行だけど。
  • 簡潔さってのが重要
    • 個人的に GO のエラーハンドリングは if err := hoge(); err != nil { } で書けるからエラーハンドリングで細かいこと考えなくていいからいいなって思うけどそのへんがあまり好きじゃない人もいるよね
  • go書き捨てのプログラムは書きやすいと思う。どこでも動くし
  • 逆にprotobufとかって書き捨てには向いていないと思うんだけどあの辺はどうなんだろうな。
  • ライブラリはそこそこあるし、効率もまあ悪くないんじゃない？
  • 時間に関してはようやく立ったって感じがする。
  • 生成AIになってこの辺の考え方って変わったんだろうか。

15章　デザインとリサーチ

  • 開発ってある種の芸術と同じというか、悪いものを改良していくっていうところと共通している
  • 完璧なものを作るんじゃなくってプロトタイプを雑にやっぱ作り始めた方がいいんじゃないか

16章　素晴らしきハッカー

  • この時代からオフィス空間の機能について言われてるんだな
  • 技術を売る会社にとって、ハッカーの考えることは会社の製品そのものだと言える。ハッカーを、ざわついて気が散る環境で働かせるのは、ペンキ工場を煤だらけにしておくようなものだ
  • 難しいものを考えた時にやっぱ静かなところで働くしかないし、それか邪魔が入らない時間にやるしかない

まとめ

  • 20年前に書かれている本だけど、今でも通じるところがある。
  • 例えば
  • 小さく作って、ユーザーの声を聴いて改良して、サブスクリプションでお金をもらっていく　というのはまさに今の時代のことを言っていると思う
  • オフィス空間に関してもこの時代から悩まれていて、一時期リモートワークとかになったんだけどこの後どうなんでしょうね。世間的に。
  • ただ、出社回帰を推し進めている会社はあまりオフィス空間の機能について考えていない気がする。
  • むしろフリーアドレスとか、偶発的なコミュニケーションみたいなところってここで言われているハッカーの天敵だと思うんですけどね。

エンジニアリングマネージャーとは何なのかの私見

エンジニアリングマネージャー(以下EM)に対して思うことがあるので私見を述べる。

なお、ここでのエンジニアはいわゆるWebやSaaS業界で働いているITエンジニアをさし マネージャーはそのエンジニアをマネジメントする役割の人を指す

※よくエンジニアはITエンジニア以外もいるぞみたいなことがあるが、 あくまで本記事中のコンテキストであることをご認識いただきたい。

また、筆者はマネージャーの立場ではない

EMの4領域

よく言われるEMの4領域がある。 - qiita.com

上記4領域に関して、会社によるところもあるが、

  • テクノロジーマネジメントに関してはいわゆるテックリードやアーキテクトなどが務めることが多いだろう。
  • プロダクトマネジメントはPdMがいる組織ではPdMが担うだろう。
  • プロジェクトマネジメントの中でスクラム開発を行っているのであれば、スクラムマスターがプロジェクトマネジメントに関しては担うだろう
    • ※いやスクラムマスターはマネージャーではないとか、あるだろうが一旦話を簡単にするためにプロジェクト周りに関して担うこととする
    • 見積もりなどは実際に設計をしたテックリードなどが行うことが多いだろう。

こうなるとEMが残された領域はピープルマネジメントとなる。

EMのもう一つの役割

gihyo.jp

によると、

「エンジニアリング組織の成果に責任を持つもの」 と定義している。 その中でマネージャーは 説明責任を求められることが多くなるとある。 なぜこうなったかを説明する義務がある。

そもそも、なぜ説明責任が必要なのかというところを考えてみる。

当たり前だが、会社は業績や利益を上げる必要がある。 その中で会社として戦略や方針・決定事項がありそれが各エンジニア組織に目標として与えられ、その目標に対してどうだったかという説明責任が必要となる。 すなわち、EMは会社としての戦略や方針を各エンジニアに説明する責任がある。 特に会社としての戦略や方針は抽象的であることが多く、それを具体的なものに落とし込んで説明する必要がある。 いわゆる　なぜそれをやるのか　という部分を説得力を持って伝える必要がある（と筆者は考える）

ピープルマネジメント

エンジニアのためのマネジメント入門にコミュニケーションを支える技術として メンタリング、ティーチング、コーチング、フィードバックの4つが紹介されている。 いわゆるメンバーに対しての説明責任を果たすためにはこの技術が必要となってくるだろう。

信頼貯金

さて、抽象的な会社の戦略を具体に落とし込むときには実際のプロダクトを知る必要が出てくる。 例えば、サイトを高速化することを戦略として置いたときに、すでにその戦略が手を尽くした後であった場合は無意味になる。 つまりEMといえどプロダクトの性質やプロダクトのアーキテクチャ、コード、そして一連のリリースまでという現場を理解している必要があると考える。 (ここの理解度は濃淡で関数レベルで知ってる必要はないとは思うがある程度どんな構造でどんな処理になっているかを知っている必要があるだろう）

さて、ここに2人EMがいる。 片方はコードを読んだことがなく、1行もコミットしたこともなく、1度もインシデント対応やハンドリングをしたことがない人と、 片方はある程度コードを読み込んでおり、何かしら機能開発をしている　とする。

信頼に足るのはもちろん後者であろう。

前者で信頼される人の場合は、例えば該当プロダクトの知識は無くても、その領域のドメインに精通していたり、プロダクト開発自体に精通している人 もしくは理解に努めようとしている人であろう。

現場を知らないEMの言葉に、誰が耳を傾けるだろうか。 具体的な経験に基づかないEMの言葉は、ただの薄っぺらい机上の空論であり、メンバーのモチベーションを削ぐ要因となる。 上からの一方的な指示を下すだけのEMは、チームの成長を妨げるだけの不要な中間層以下である。

まとめ

  • EMとはピープルマネジメントを中心にマネジメントを行い会社の戦略の説明責任をもつ
  • それを伝えるコミュニケーションを行うためには信頼が必要である。
  • 戦略を語るにしてもやはり信頼が必要であり信頼が失われるとメンバーは納得して動かないだろう
  • 信頼を得るには、技術や能力が必要だったり一度現場の感覚がつかめていないと信頼されないだろう。そういうEMは今後どうなっていくのか。

protobufに関するメモ

  • Google製のバイナリフォーマット+スキーマ定義
  • JSONみたいに人間が読めない
  • 圧縮されたバイナリだから早い
  • スキーマだから型が決まってる
  • 送る前から両者で合意している、強い後方互換性

protofile

syntax = "proto3";

package todo.v1; option go_package = "github.com/you/todoapp/gen/todo/v1;todo";

message Item { int64 id = 1; string text = 2; }

service TodoService { rpc Create(Item) returns (Item); }

フィールドの脇にあるのはタグ番号。番号は二度と使いまわさない

JSONとの違い？

  • サイズが小さい
  • 方が決まってる
  • gRPCみたいな双方ストリーミングに強い

どうやって使う？

  • gRPC
  • 最近はconnect-go で gRPC,gRPC-Web/Jsonを1つで捌ける
    • ブラウザもcurもいける

注意ポイント

  • タグ番号は変更しない
  • optionalは乱用しない

    oneof/map

  • oneof 同時に一個だけ入るユニオン型

    • 例えばAPIでどっちかだけ更新したいときとか
    • ワイヤーフォーマット
      • 単なるタグ番号+値だから実際には普通フィールドの並列
      • 何も送らなければ何も送らない
      • タグ番号が衝突しなければ既存oneofに新フィールドを追加しても互換性がある
    • 多言語対応メッセージ、バージョン違いの共存、コマンドパターン的に使う

  • map

    • キーに使えるのは4種だけ
    • message stockEntry { string key = 1; int32 value = 2; } repeated stockEntry stock = 1;
    • に自動展開される
    • シリアライズ順番は未定義
    • nullが定義できないのでgoogle.protobuf.NullValueにする

  • optional を使うと値が設定されたかどうかを判定できる

  • unkwon fields は受信側が知らないフィールドを一時保存してそのまま再送できる

バリデーション

  • protoc-gen-calidateが便利。アノテーションを書くと、生成されたコードで msg.Validateが呼べる
  • .proto にバリデーションルールを書く → 生成コードに Validate() メソッドを自動付与、っていうプラグインだ。
import "validate/validate.proto";  // ← これを忘れずに

message Signup {
  string email    = 1 [(validate.rules).string.email = true];
  string password = 2 [(validate.rules).string = {
                        min_len: 8,
                        max_len: 64
                      }];
  int32  age      = 3 [(validate.rules).int32 = {gte: 13, lte: 150}];
}

これを生成すると自動でメソッドが生成される

protovalidateもあり

Keyball61を作成した

この文章もKeyball61 で書いています。

きっかけ

  • 自作キーボード自体は、SoyuzだったりQuick17だったり作成経験はあるものの、いわゆるマクロパッドが中心だった
  • 過去に書いたが、 KeyFuda02とかも作っていた　

ytacky.hatenablog.com

  • 業務上出社する機会が増えそうだったので、ポータブル可能なものが欲しかった
    • ※会社として出社せよという命令があったのではなく、業務上出社して行う必要なものが増えたという意味
  • 分割キーボードにも興味があった
  • 昨年トラックボールを使い始めてトラックボールへの違和感が無くなった
  • 一方でキー数が少ないと使いこなせないと思ったので61にした

購入したもの

手元にあったもの

組み立て中のトラブル

ダイオードの極性が見えない

  • スマホで拡大しながらやればできるだろうと思ってたけど面倒に
  • インスペクションルーペを買うことで解決。もう少し拡大率が高いものを買えばよかったかなとも
  • ルーペで逐一極性を確かめながらはんだ付けをしたので後述する1か所以外は問題なくはんだ付け完了

はんだ切れ

  • 手元にあったはんだの量の見積もりが甘くもう少しで完成するけど今日を逃すとやるタイミングがないという状態に
  • 寒い中閉店30分前のホームセンターに駆け込み何とかはんだを購入して作業を続けられた
  • 年末風邪ひいた原因の一つかなーとも

基板を一か所焦がしてダイオードが不通に

  • いいわけすると、ジムから帰ってきた後はんだしていた部分で基板を焦がしてしまい、動作確認中ダイオードが不通に
  • githubでdiscussionsで相談させていただき、なんとか解決した。

OLEDがつかない

  • トラックボール側(右手側)のOLEDだけがつかず、まあ動くからいいんだけどどうせなら完璧にしたいなと思い原因を調査
  • 動作していた左手側のOLEDと交換したところ、ついたのでOLED自体の故障ではないと判断
  • とりあえずピンソケット周りのはんだ不良かな？と思ってはんだをはずしたところピンソケットを壊してしまう。
  • 泣く泣く有給をとり遊舎工房へピンソケットを買いに行き再はんだした。
  • それでも動かなかったので、よく見たところPromicrioのはんだ不良があったので再はんだしたら動いた
    • OLEDで利用するピンの部分のみはんだ不良があったのでキーボード自体は動作していたのが原因切り分けがなかなかできないところであった。

keyball61どう？

  • 分割キーボード自体はいい
  • まだ慣れてない部分があるのでタイピングはおぼつかない部分がある
  • あとLayerのどこになにがあるかもまだ覚えきれてない
  • タイピングしながら手を動かさずにトラックボール使えるのはよい
  • Layer3をSlack特化にして、チャネル移動をしやすくするのははかどった

2023年を買った技術書で振り返る

すべては読んでないし積んでるけど、2023年に買った技術書をまとめておく。

1月

SQLではじめるデータ分析 ―クエリで行う前処理、時系列解析、コホート分析、テキスト分析、異常検知

SQLではじめるデータ分析 ―クエリで行う前処理、時系列解析、コホート分析、テキスト分析、異常検知

Amazon

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

Amazon

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

Amazon

  • 1月はデータ分析系に興味を持っていたらしくそのあたりの本を購入。
  • いまはその辺の仕事はやってないので手つかずでやるときに読むようになるはず。

2月

3月

  • Go言語プログラミングエッセンス
  • エンジニアのためのマネジメント入門
  • 一生モノのビジネス教養　データサイエンス大全

  • エンジニアのためのドキュメントライティング

  • AI周りをビジネスサイドの人に説明できるようにまずはデータサイエンス周りの書籍を購入

  • Goは日常的に使っているのでよっぽど初学者向けじゃなければ買うようにしている
  • ドキュメントライティングはドキュメントを書くことが結構あるのと、この時期に出てた本なので

4月

  • システム設計の面接試験
  • ZEN 禅的マネジメント
  • 従業員エンゲージメントを仕組み化するスキルマネジメント
  • SOFT SKILLS ソフトウェア開発者の人生マニュアル第2版

  • 解像度を上げる 曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動方

  • システム設計の面接試験は、入社試験などを見るようになってどんなやつがいいんだろうか？という観点から購入

  • この時期は目標設定があったりするので、目標設定に関する本だったり、エンジニアとしてどう生きるか？という本を中心に買っていた

5月

  • スタッフエンジニア
  • 図解 目標管理入門 マネジメントの原理原則を使いこなしたい人のための「理論と実践」100のツボ 「理論と実践」100のツボシリーズ
  • 世界標準のデータ戦略完全ガイド データセンスを磨く事例から、データの種類と仕組み、戦略策定のステップまで

  • Good Code,BadCode 持続可能な開発のためのソフトウェアエンジニア的思考

  • 引き続き目標周りの書籍と、エンジニアとしてどう生きるか？という本を中心に

6月

  • これまでの仕事 これからの仕事　～たった1人から現実を変えていくアジャイルという方法
  • 人が増えても速くならない〜変化を抱擁せよ~
  • 因果推論の科学　「なぜ？」の問いにどう答えるか

  • ソフトウェア設計のトレードオフと誤り

  • 市谷 聡啓さんの本は大体読んで参考にしてるので購入

  • 多分この時期はどういうものを作るか？というものを決めるのに不安があった時期なのであろう。

7月

8月

  • スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する
  • Go言語 100Tips ありがちなミスを把握し、実装を最適化する

  • WEB+DB PRESS Vol.136

  • WEB+DB PRESSが休刊になるのでさすがに休刊前の書籍は紙で持っておきたいなという気持ちで購入

  • Go言語100TipsはGoなのでってところ

9月

  • GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ
  • ネガティヴ・ケイパビリティで生きる ―答えを急がず立ち止まる力

  • マスタリングTCP/IP

  • もう少し低レイヤーのことを学びなおそうかなと マスタリングTCP/IPを購入

10月

  • プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド
  • クラウドアプリケーション 10の設計原則　「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則
  • 図解いいキャリアの育て方

  • 雑に作る ―電子工作で好きなものを作る近道集

  • この時期に自作キーボードにはまってたので、電子工作の書籍を購入

  • 10月は目標設定などでキャリアについて考えねばならないので、キャリア関係の書籍も購入

11月

  • データで話す組織〜プロジェクトを成功に導く「課題発見、人材、データ、施策実行」4つの力
  • マンガでよくわかる1on1大全
  • コンセプトの教科書
  • NO RULES 世界一自由な会社　NETFLIX

  • 任せるコツ

  • 部下ではないけど、いわゆるジュニア層のエンジニアに任せるためにどうすればいいか？という点から購入

  • この辺の書籍は積んでる...

12月

  • プロジェクトマネジメントの本物の実力がつく本 組織力・コミュニケーション能力・リーダーシップ・キャリア構築力を全部鍛える
  • Stable Diffusion AI画像生成ガイドブック
  • 独習Notion [チュートリアル & リファレンス]
  • プログラミング知識ゼロでもわかる プロンプトエンジニアリング入門
  • 年末に触ろうかな？と生成系AIの書籍を購入
  • Notionもなんとなく使ってる状態なので一旦整理されているもので見直したいなというところで購入

まとめ

  • 買った書籍でもその時期に何をしていたか。何を求めていたのかというのがわかるなと思った。
  • 来年もやる予定

仕事できる人の共通項とは？

社会人生活も長くなってきてきたけど、この人仕事ができるなってところの共通項がなんとなく自分の中で見えてきたのでまとめてみた。

人のことを気遣って仕事ができている

  • 自分1人で出来る仕事はそんなに多くなくて、チームとして仕事をしているという意識がある。
  • そのうえで、自分がブロッカーにならないように動く。ということが意識的にできると仕事できる人だなと感じる。

適切に優先度をつけられる

  • 上で書いたブロッカーの件とも共通するけど、複数の仕事があって自分がブロッカーになってしまうときに適切に優先度をつけられる人は仕事ができるなと感じる
    • この人はこのブロックが解決しないと仕事が進まないな。みたいなものは優先してできる
    • この人詰まってるし、最速で返しても積まれるだけと判断したものは若干優先度を下げて対応する
    • まあこれ仕事とそこまで関係ないから優先度低でいいかみたいなやつはあいているタイミングでやる
    • 飲み会の準備とか

仕事が早い

  • MTGをスキップするという意思決定をしたならば、すぐに連絡ができる。
  • かつ、その連絡のタイミングが適切
    • 該当MTGの前日の定時後に連絡があってもあまり効果的ではない
    • せめて定時前には連絡しておきたい

自分がどの仕事をすべきか適切に管理できている

  • チーム内で自分の果たすべき役割がどのようなものかを理解し、その役割を遂行できている。
  • その役割を遂行した上でほかの役割を手助けできている。　という人はスーパーできる人

連絡に対して適切にリアクションできる

  • 何かしら問い合わせが来たら、最低限その問い合わせは認識してますよというリアクションを取れる
  • こういう人は何かと信頼されやすい。

自分もどこまでできているかはわからないけど、この辺を踏まえて仕事をしていきたいところ。