Vapor Trail

明るく楽しく元気よく

最近読んだ本

 

 

KPIを設定するも方向性がずれてたりハックされたりしながら、軌道修正して適切な数値に調整する部分は参考になった。

ファイターズのボールパーク移転問題で秋元市長がいつも叩かれているが、運営会社と球場のドームの所有者が別れていること、ステークホルダーが多いことと、何をするにも市民の声を聞かないといけないから、身動き取れなくなるよなと感じた。

 

 

 

最近観たドラマ

たまたまYouTubeで名場面の切り抜きを観て、気になったのでFODに入会して観た。

テレビドラマって1シーズンしかできないせいで、原作のいろんな部分端折って微妙なことも多いが、2シーズンで21話まであって見ごたえがあって面白かった。

2023年振り返り

1月 新規機能の開発を始めた
2月 変わらず
3月 今の会社に入って1年が経過。意外と早かった。
4月 妻のおじさんが死去。
5月 変わらず
6月 ツリー構造のデータの並び替えのフロント実装がむずかった。
7月 業務委託の方の面接もやるようになった
8月 ビアガーデンに行った
9月 正社員の面接もやるようになった。
10月 変わらず
11月 変わらず
12月 副業を始めた。お世話になったマネージャの人が退職する。

総括

仕事に関して

 今月リリースされた新機能の開発していた1年だった。23年第4四半期をリリース目標にして最初は間に合うのか?と考えていたが、寄せ集めの即席のチームではなく1年前からあるチームだったことと似ている機能の開発をしていたチームだったので、安定して開発できた感がある。あとは仕様を詰めるディレクターの人が歴の長く細かい仕様について詳しい人だったのでそれも大きかったと思う。進め方としては大枠の仕様とFigmaモックアップができたら実装して細かい部分は作りながら詰めていくみたいなスタイルで開発をした。
 11月くらいからアルファ版として実際にユーザーにトライアルしてもらってみたいなことをして期待値とズレがないか確認できたのも良かったが、ディレクターの人の負担は大きかった。ディレクター=プロダクトオーナーなのだが、仕様書作成、スコープ調整、マネージャー・営業・カスタマーサポートなどのステークホルダーとの調整もしてとディレクターの職務広いなと思った。丸1年かけて開発していて、最小限の機能だけにしてさっさとリリースすればよいのではとも考えていたが、人によってあって当たり前の機能が違って組織が大きくなるとこういう問題も起こるのかと知った。MVP、MVPとよく言われるが、この記事で元GitLabの人も同じようなことを言っている。
 自分はツリー構造のデータを保存する機能の部分を開発したのだが閉包テーブルに挑戦できたことは良かった。サーバサイドだけではなくフロントエンドも実装したが、ドラッグアンドドロップで項目の並び替えや階層を移動する処理の実装はかなり苦戦した(こういうやつ)。ただの縦移動だけではなく階層という横移動もできるとなると考えることが増えてメモ化をして再レンダリングしないようにしたり、VirtualListを使用して重くならないようにしたりも大変だった。

 前の会社の同僚だった人が会社を立ち上げて人手が足りなくて困っているということなので12月から副業を始めた。副業はする気がなかったが、前の会社の同僚だった人が社長で特に納期などもない上にコードレビューもないし自分で自由にライブラリを入れることができるのでノンストレスで自分のペースでできるので楽しい。

 前の会社で同僚だった人が入社した。12月に一緒に飲みに行って自分が辞めたあとの話を色々聞いたが、前の会社で尊敬してためちゃくちゃ仕事ができるCTOの人が体調を崩してやめたという話を聞いてショックだったのと、やっぱりハードワークは良くないな健康が一番大事だなと改めて思うようになった。

私生活について

 4月に妻のおじさん(妻の父の兄)が癌で亡くなった。久しぶりに葬式に参加したのだが、葬式の最中に「自分が死んでもこんなに人たくさん来ないよなぁ」とか「こんなに供花来ないよなぁ」とか、葬式ってその人の人生が現れるなぁとか考えていた。おじさんは定年まで建設会社で働いていた人で、互助会?みたいなものがあるらしくその会社からも参列者が来たりちゃんと供花が届いていてJTCも悪くないのかなとか思った。

 2023年は資格を取らなかったが、データベーススペシャリストネットワークスペシャリスト(申し込みしてないのでもう間に合わない)、PMBOKあたり取りたい。

最近読んだ本

仕事で業務委託の方の面談や正社員の一次面接をするようになったが、どうすれば良い人をとることができるのか知りたかった為読んだ。

 

『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』

「バリューを体現をできる人を取りましょう」といった感じ。じゃあバリューを体現できる人かどうかどうやって判断するのか。今の職場や過去の職場でバリューに沿った行動を主体的にしていたのかどうか質問して見極めるしかなさそう。

  • コミュニケーションのとり方が参考になった。特にコミュニケーションガイドライン

jp-handbook-gitlab.tech4u.dev

「正論で相手を追い詰めるのではなく、相手が理解できるように接しましょう。…厳しいメッセージを伝えなければならないときにも真摯に受け止めてもらえるようになります。」

  • 新入社員のパフォーマンスは社会的交換関係(ギブアンドテイク)と社会的受容(チームに受け入れられているという感覚)と関係があること、インフォーマルなコミュニケーションも大事であること。
  • SBI(Situation-Behavior-Impact:状況-行動-影響)モデルで相手に誤解を与えずに言語化して伝えることができるようにする。

invenio.jp

・チームのパフォーマンス = チームのメンバーの生産性の合計 - プロセスロス + プロセスゲイン

www.dodadsj.com

 

  • コラボレーション≠コンセンサス
    自分の責任を軽くするためにコンセンサスを取ったり、自分一人でできることを無駄に遠回しすることはコラボレーションではありません。
  • 成果 = コミットした責任を果たすこと
    成果が良かったかどうかを決めるのはステークホルダーであって、良い影響を与えられたかを客観的に計測することが重要
  • イテレーション = 何かを追加・削除すること
    ユーザーやチームに対して何も変化がないものはイテレーションとは呼ばない。また大規模な計画もしない。イテレーションの最初のリリースは小さすぎて気恥ずかしいくらい些細なものであれば正しい。

    jp-handbook-gitlab.tech4u.dev

『採用基準』『生産性』

結論としては、リーダーシップがある人を採れという感じ。

chikirin.hatenablog.com

  • 決める
    十分な情報が揃ってない段階で決断をすることはリスクを伴うため、決断を先延ばしにする人がいるが、未来のことなので十分な情報が揃うことはなく、常に不十分な情報しか存在しない中で決断を求められる。
    マネージャの仕事とはトレードオフが存在する状況において判断を下すこと。下した決断は人によって正解、不正解が分かれることを理解し、なぜその選択をしたのか他の人に説明できるようにしておくこと。
  • できるようになる前にやる
    できるようになるまで見て学ぶのではなく、とりあえずやってみてできない部分だけを誰かに助けてもらう。リーダーシップがある人は仕様とか決まってない状況でも自分から聞きに行ったり提案したりしてプロジェクトを前に進める力がありますね。任せられてやっていくうちにできるようになるみたいな。