y.takky　てくめも

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

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

前書き

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

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

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の前日の定時後に連絡があってもあまり効果的ではない
    • せめて定時前には連絡しておきたい

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

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

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

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

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

エンジニアリングマネージャー と 目標設定　NTT Com Open TechLunch #7　聴講メモ

概要

https://twitter.com/hashtag/techlunch

  • ちなみに自分はNTTコミュニケーションズやNTT関連の企業とは全く関係ない企業に所属しているので、以下記事中の社は私の所属している社のことを指しているのでその点だけ注意

この勉強会に参加しようと思った理由

  • 社の目標設定の期間でいろいろと悩んでいた
    • ただでさえ目標設定に関してはネガティブなイメージを持っているのに目標設定に使うツールに関して人事と一悶着あったりなかったりしたのでさらにネガティブになっている状態であった。
    • そもそも、目標ってなんぞや？とか組織上マネージャが正しく評価できるわけないじゃんね。みたいなところを抱えていた
  • ちょうど以下のtwitterを見かけて時間も合うし参加してみようかなと思っていた (フォロワーのRTかtwitterのおすすめに流れてきたやつと思う)
  • 今回の発表者の吉羽 龍太郎さんの著書は何冊か読んでいて(SCRUM BOOT CAMP THE BOOKが一番好き)、この方の発表であれば納得感と何かしら得るものがあるのではないかなと思い参加した。

以下聴講メモ

目標設定の基本

  • よく言われること
  • 定量的に判断できるようにしましょう？
    • これはまぁまぁ怪しい
  • 大事なのは、定量的に判断できるということではないよね
  • そもそも目的と目標は別のもの
目的 : 最終的に達成したいこと
目標 : 目的を達成するための手段

上記は辞書的な定義からの引用(goo国語辞典)

  • つまり目的が上にあるよね？
  • なので、目的に立ち戻って考える必要がある

企業の目的

  • 企業とは何かを決めるのは顧客である（ピーダー・ドラッカー : マネジメント)
  • 企業の目的の定義は顧客の創造である
  • ただし、これをブレイクダウンするのは難しい
    • 顧客をキーワードにしてやるのはわかりやすいよね。

顧客との価値交換システムを中心に据える

  • 目標は価値交換システムにどう関係あるかを説明できるように必要がある
  • その目標を満たすことで、どう価値交換システムに影響あるか説明できる必要がある。
  • ただし、全部が価値交換システムに関係あるとは限らない
    • 個人のスキル獲得になるべき
  • 本質的には価値交換システムに関連のある目標であるのが自然ではないか

SMART

  • 目標設定のときに言われるやつ
Specific:具体的
Measurable : 計測可能
Achievable : 達成可能
Related : 関連性がある
Time-bounded: 期限がある
  • Relatedが重要

ビルドトラップ

  • 目標との関連性がないと陥る
  • アウトプットで成功を計測しようとして息詰まる状況。
  • 価値ではなく、機能の開発とリリースに集中してしまっている
  • 機能数、リリース回数、期日までのリリース、プロジェクトの完遂　
  • これは価値交換システムが機能していることを示さない。 Relatedではない

グッドハートの法則が発動

  • 管理のために用いられる測定はすべて信頼できない
  • リリースするって書いてしまったから適当にリリースする必要があるんですよねとか。のハック

多すぎる目標を避ける

  • あれもこれも達成したいは無理
  • 本当に重要なことを数個まで絞り込む
  • 自分の目標を全部口頭で説明できるようにする

目標の検査と適応

  • 半年間や1年前に立てた目標が有効なことは多くない
  • 目標が意味なくなる
  • 月1ぐらいで検査し適応する必要がある

    ツールがあって目標が変えられない

  • 上司との運用で合意する

まとめ

  • Relatedが大事だよ
  • 目標設定と報酬はわけろ。チートが発生する
  • 検査と適応が必要

パネルディスカッション

目標設定と報酬が結びついている状況で、アウトカムを意識しつつ、本人の頑張りを正しく評価できるような目標設定をどうするか？

  • 売上でエンジニアが評価されるのはどうなんだってのはある。
  • 古いシステムの維持の場合、アウトカムは高く見せづらく、アウトプットで評価しがち
  • スクラムだと個人の貢献度がわからないよね

内容

  • 目標設定の成果を見たときに達成率で本当に頑張ったよね？って言えるんだっけ。
  • 会話の土台や目線合わせのために目標があるのであって、評価って目標以外にも諸々あるはずだよね。
  • 1on1などをすることで、キャリアデベロップメントや方向を見るべき
  • 本質的にはマネージャーも現場でみて、振る舞いなどを見るべきではないか
  • そもそもマネージャー一人で評価ができるのか？
  • 他の人のインプットがないと評価できないよね。誰が何をやってるかしらんし
  • やっぱり360度評価みたいなのは必要なのではないか。
  • 目標設定のみで評価を避けるべき
  • アウトカム（業績)　と行動の部分も評価してる（NTT)
  • 評価とかでびっくりさせてはいけない。

成長をサポートする効果的な目標設定・振り返りのやり方

  • 少しストレッチして、目線をあげるような目標設定をさせたい
  • 今季チャレンジしたい事はなにか？
  • これ(=チャレンジしたいことや能力)を伸ばしたければこういう目標設定をすればよいよ。 　　
  • これ(=チャレンジしたいことや能力)がわからない、これがイケてるか、イケてないかは検査と適応でアップデートしようよ。というのが必要
  • 目標自体が更新すべきで、書き方よりは運用
  • ツリー構造っぽくしてブレイクダウンしていく必要がある
  • メンバーによって道のりの粗さは分けて良い。
  • シニアだったら勝手に考えてくれるだろう
  • 日々の運用に組み込むのが重要
  • どこどこの何々システムを導入すれば良いというわけではない。

Q&A

チームで価値を生む場合個人目標はどうする?

  • 個人目標いらなくない？
  • スキル獲得はやったほうがいいけど、それ以外はいらないかもね。

顧客への価値と技術者の評価はどのように紐づくか

  • アジャイルだと全員が同一評価かも。
  • チーム内のエンジニアの個別評価は？
  • 目標設定する上で顧客にどうやって利用されるのか、という部分を意識してもらう。というのはある。
  • 定量だけでなく、定性も入れてもらう。
  • 期待値を伝える
  • なんのために目標設定をしたいんだっけ？ってところがある。
  • 評価のために目標設定をするのであればそれはオプションの一つではないか。
  • 目標設定がなぜ必要なのかを考えるべき
  • 一つの評価では無理

業務とアウトカムとの関連が薄いチームについてどうすべきか

  • 設備保全や社内情シス、終息プロダクト
  • 存在している事自体がアウトカムでそこを握れば良い
  • 目標設定だけで評価決まるだけではないよね？
  • 運用系は難しいよね。

まとめと感想

  • 目標や目標設定の定義づけとすり合わせは必要だなと思った。
  • 制度を変えるのは難しいから、上司との1on1などで合意をとって、頻繁に検査と適応をしていく必要があるよねというのは概ね同意できる。
    • ただそれって、いわゆる運用で回避ってやつだよな...とも思ってしまう
    • 上司（マネージャー）のマネジメント力に引っ張られてしまう可能性が高い。マネージャーガチャが外れると目標設定自体が無意味なものになってしまう危険性があるなと思った。
    • 本質的には評価制度設計者（基本的には人事部だと思うけど）が、 気づいて運用をできるような組織風土づくりをしていくのが大事なんだろうけど、人事はエンジニアリングのことをわからないことが多いと思う（社だけかもしらないけど）のでそれも難しいのかなとも
      • エンジニアリング向けといわゆるセールス向けと評価制度が別になってしまうとそれはそれで対立を生むきっかけになってしまうしな..と
  • やはり、目標設定だけで、人事評価につながる。という部分が根本的にいけないのではないかなと感じた。
  • エンジニア的には根本的なところが直らないともやもやするのでこのもやもやは晴れないなみたいな気がした。