@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

202606 振り返り

8年弱働いた会社を退職した。

リクルートで働いていたからこその経験はあったし、ここでの時間で作れた人脈など大変ありがたいものを沢山いただいた。ただ、自部署には悪影響を残してしまったという気持ちだけが残ってしまっている。残っている方々は優秀な人ばかりなので解決してくださるだろう。
本当にお世話になりました。

そんなこんなで、6月は飲み会がいつもよりは多かった。それでも毎日になるほどではなかった。 体重を落とすことと仕事になれることを目標として頑張ろう。

べんきょうかい

参加したものはなかった。
Tech な人が集まる飲み会には参加したが勉強はしていないな。

ほん

押井守本と小説をいくつか読むことができた。
技術書は読めてないけど積読は順調に増えている。どこかで時間を取るのが良いのかもしれない。

えいが

1本も観ることはなかった。
観たいものはあるので行ってみる。

ぶろぐ

退職したので退職エントリーを書いた。これで2本目かー

hihihiroro.hatenablog.com

株式会社リクルートを退職しました。

退職時いただきもの

はじめに

2019年1月に入社した株式会社リクルートを2026年6月30日をもって退職しました。
7年5ヶ月間お世話になりました。
(以後、簡便のためにリクルートと表記する。

退職理由

1つは退職金制度。僕が入社した当時はまだリクルートには大きな退職金制度があった。入社した会社には制度が残っていたため、使うことができる年齢になったのでせっかくなので利用することにした*1
2つ目は横断での働き方に少し疲れてしまったこと。僕が働いていた部署は40サービスくらいのデータを分析しやすくし、提供をするというのがメインの仕事だった。関わる人もサービスも大きい仕事のだが、何かのサービスに特化しての開発をすることはしづらかったりという事がありました。そのためやりがいを感じることが少なくなってしまったのが原因。

データエンジニアとして勉強もしてきて、もう少し知識をお仕事に活かせるのではと思ったときにサービスに対してのコミットがしやすい場所だと楽しそうだなと思ったところにお誘いをいくつかいただいたので転職をすることにしました*2

リクルートというところ

とにかくみんな優秀。チームメンバーもだし、関わることになる皆さんリクルートで働かれている方は優秀だと思うことが多々ありました。自分は頑張って平凡になろうと思っているくらいなのでみなさんとの会話が毎回毎回刺激的で勉強になることばかりでした。また人材についてを考えている会社ということもあり成長するための制度など面白いものも体験できてとても刺激でした。

また、仕事の仕方としては週休3日を目指すようになりメリハリをつけた仕事のやり方が推奨されていました。完全リモートも許可されているし出社することも止められないし自由に働けたなと思います。大きい会社なこともあり仕事のツールなども自由度高く使うことができるように整備されていたため不自由を感じることは何もなかったです。

次のお仕事

お声がけいただいた一社でデータエンジニアとして引き続き働いてみます*3
整備もあまりされてないのでやることも多いし責任も増えそうとのことなので楽しんでみようと思います。

謝辞

同僚や上司、関わってくださった方皆様が刺激を与えてくれるすごい人ばっかりでとても恵まれていた環境だったと思います。
特に、グループで一緒に働いてくださった皆様には感謝しかありません。少しでも自分が何かをお返しできていればとは思っています。
今後も関わることは多々あるかと思いますので、その際にでも少しずつお返しできるよう頑張っていきたいと思います。

今後も情報交換、ご飯や飲みに行くだけなど色々関われると嬉しいので引き続き宜しくお願い致します。

ありがとうございました!!!

欲しいものリスト

皆様からのお気持ちお待ちしております。

www.amazon.jp

*1:本当に入金されるかは来月にならないとわからない

*2:リクルートでは部署異動も頻繁にあるが僕にはそのお声がけもなかったので…

*3:次の職場は新宿駅です

202605 振り返り

のんびりしていた時間が多かった。
家にいたり外に出かけてもぼーっとしたりしている時間を多く取った。

もう少しだけのんびりすることができれば活動する気が起きそうだから来月くらいまではダラダラしているかもな。

べんきょうかい

久しぶりにいくつか勉強会に参加してみた。
オンラインもオフラインも面白い話が多くて楽しい。いつかは自分も喋ってみたいとは思っている。

ほん

誕生日祝いでいただいた本をいくつか読んだのと毎度通り積読になっていた技術書をいくつか読んだ。
移動の際に本を読んでいたのだが最近はスマホを見ていることが多いので読書時間が減ってしまった。

えいが

少しずつだが映画を観に行くことが増えてきた。
まだ見たいものがいくつかあるので来月も見に行こうと。

  • 劇場版 魔法科高校の劣等生 四葉継承編
  • SAKAMOTO DAYS

ぶろぐ

GWだったので読み終えた本についていつも通りダラダラと。
例年に比べると読み終えた冊数が少ないけど無理しない範囲で。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「ソフトウェア設計の結合バランス」を読んだ

こちらも読もうと思って積まれていたのでせっかくの時間のある時期なので読んでみた。

目次は以下。

第Ⅰ部 [結合]
  第1章 結合とシステム設計
  第2章 結合と複雑性:クネビン   第3章 結合と複雑性:相互作用
  第4章 結合とモジュール性
第Ⅱ部 [次元]
  第5章 構造化設計におけるモジュール結合
  第6章 コナーセンス
  第7章 統合強度
  第8章 距離   第9章 変動性
第Ⅱ部 [バランス]
  第10章 結合の均衡化
  第11章 結合の再均衡化
  第12章 ソフトウェア設計のフラクタル幾何学的性質
  第13章 均衡結合の実践
  第14章 結論
付録A 結合のバラード
付録B 結合の用語集
付録C 演習問題の解答
付録D ドメイン駆動設計の用語の訳について

疎結合とよく言うけどなにを持って結合しているしていないを考えることなかったなと言うのが本書を読んでのまずの感想。
まずは結合や複雑さ、モジュールの説明・定義から始まり、モジュール結合やコナーセンスなど結合の度合いを測るためにこれまでソフトウェア工学で用いられてきた概念がわかりやすく整理されている。その後、汎用的に使えて暗黙的な結合なども考慮した尺度となる統合強度、モジュール間の距離、モジュールの変動性についての説明がされている。

本書では統合強度、距離、変動性の3軸のバランスが取れる点を探ってシステムを作成することが良いと説明されている。結合は疎であることが良いと言われていると思いこんでいたが、本書では無結合ではそもそもシステムとして成り立たないものとして説明されている。それもそうだなと思いなおすことができた。結合は必ず必要なもので、むしろ結合自体がシステム設計の本質であると捉えようとしていました。結合が悪いわけではなく丁度良い結合度合いにすることが大切なのだろう。

その他にも本書では意思決定フレームワークのクネビンについて説明されている。クネビンは対象がどんな状態なのかを一次元的な尺度で把握できるようにするもの。具体的には以下の順序で複雑度の状態が説明されている。問題を考えるときには役に立つフレームワークだと思っているので自分で試してみることをやっていきたい。

  1. 明確系: 何をすれば良いか分かってる状態
  2. 煩雑系: 他の詳しい人に聞けば解決する状態
  3. 複雑系: 実験結果で推論できる状態
  4. 混沌系: 実験結果でも推論できない状態
  5. 無秩序系: どの状態か分かってない状態

また、ソフトウェア設計のフラクタル幾何学的性質の章が面白かった。

最近いろいろ考えることをしているのだけどフラクタルやトレードオフでの選択ってどこにでもでてくるものだなと思いはじめている。この辺りをまとめて発表している人とかは昔から考えていたのだろうなと思いつつも、遅れながらでももっと知識を入れていきたいなと思った。

まとめ

  • 均衡結合モデルについてはもう少し学びたい
  • 最小化ではなく最適化を目指せるようにシステムの見直しをしたい
  • システム内、システム外両方の結合について考え直したい

「Aligned」を読んだ

目次は以下。

コンテキストを理解する
  第1章 組織
  第2章 人
関係を築く
  第3章 ラポール
  第4章 信頼
アラインメントを実現し維持する
  第5章 ロードマップ
  第6章 変化
逆境を克服する
  第7章 挑戦
  第8章 エピローグ

ちょうど本書を読む前に読んでた本で開発グループ以外とのやり取りを強化していかないとなと思ってブログに書いていた直後なのでグサグサとささってくる内容だった。
開発にずっと所属しているとプロダクト開発ってシステムをどうこうする話がメインになってしまっているのだがそもそも作るものってどうやって決めるのかがなく、なんとなくで優先順位を決めて作ってしまっていたなと思っていた。そのためユーザーに近い方や偉い人と話をすることにしたのだが、そうすると出てきた要望の順番を決めることができなくなってきた。それらを解決するための方法が色々と書かれているので実践してみたいなと思った。

意思決定文化の4つのタイプと個人の意思決定スタイルがとても学びになった。別にタイプ分けをしたいわけでもないしそんなに単純に分かれないだろうとは思っているが4分類の理解をすることで相談の仕方や話の仕方を考える事はできるだろうなと思った。自分は参加型にしたいと思っているけど指示型になっていることが多いなと。
民主って良いと思いつつもいつも選ばれない方を推していると辛い感じになるので決定者はいる方が良いよなーと思っている。
ちなみに意思決定文化の4つのタイプは「指示型」、「民主型」、「参加型」、「コンセンサス型」。個人の意思決定スタイルは「主導型」、「影響型」、「安定型」、「慎重型」。

コミュニケーションを取るときには共感を元にしようというのもわかる。思ってはいるのだが、自分の言いたいことだけを喋ってしまうのだよな。このあたりは特訓が必要なのかなと思っているので話し合いの練習相手を募集したいところ。

ラポールで出てくる仕事以外の時間に話をするとか、バーチャルでの雑談タイムやオンラインのチームビルディングなどは元々やっていた。そもそも仕事以外のところの仲良しさってコミュニケーションとりやすくなるよなと思っているので自分がやっていたことが間違ってなさそうで良かった。
そして、信頼性の築き方では必要なものが言語化されていて確かに自分もこれらのことってされないと信頼してないかもと思った。自分も信頼されるためにこの辺りは間違いなくやるぞというのと、プロとしての意見が言えるだけの知識や経験は抑えておきたいなと思った。

まとめ

  • 組織や社内政治についての勉強になる
  • 今は強さでノーと言ってしまっているのでうまく伝えれるようになりたい
  • ステークホルダーリストを作ってみよ

202604 振り返り

外に出る時間を増やしたので読書の時間が減ったけどなんか移動をするのは楽しかったな。
ただ、スマホの位置ゲームなので移動中もずっとスマホを見ているので姿勢も悪いし目にも悪いのだろうな。

久しぶりに自分の振り返りをしてみた。
なにしていたかは大体覚えてないしできるようになったこともよくわかってない。もう少し深堀りしてみよ。

誕生日お祝いしてくださった方もプレゼントくださった方もありがとうございます。
なにか少しでもお返しできるように頑張ります!

べんきょうかい

今月は何も参加していない。
スマホゲームで遊ぶことを優先してしまった月になった。
そんな時があっても良いだろう。

ほん

今月は読書数は減っている気がする。
ドラクエウォークを真面目にやっていたので休日移動時間にあてていたので思ったよりも読書に割り当てる時間少なかったのかな。
出社の際に電車の時間増えても読書が捗るわけではなさそうだ。

えいが

観ようと思っていたものと映画館に行ってみかけて観た2つ。
コナンを見るたびにサッカーするかと思っていたのだけど今回はそこまで思うことなかったな。

  • 名探偵コナン ハイウェイの堕天使
  • 劇場版「暗殺教室」みんなの時間

ぶろぐ

連休に入ったので例年通り。

hihihiroro.hatenablog.com

「ソフトウェアアーキテクチャ・ハードパーツ」を読んだ

読まなきゃ読まなきゃと思っていたけどようやく読んだので。

目次は以下。

1章 「ベストプラクティス」がないとどうなる?
第Ⅰ部 分解する
  2章 ソフトウェアアーキテクチャにおける結合の見分け方
  3章 アーキテクチャのモジュール化
  4章 アーキテクチャの分解
  5章 コンポーネントベース分解パターン
  6章 業務データの分解
  7章 サービスの粒度
第Ⅱ部 つなぎ合わせる
  8章 再利用パターン
  9章 データの所有権と分散トランザクション
  10章 分散データアクセス
  11章 分散ワークフローの管理
  12章 トランザクショナルサーガ
  13章 コントラクト
  14章 分析データの管理
  15章 独自のトレードオフ分析を構築する
付録A 概念や用語の参照
付録B アーキテクチャデシジョンレコードの参照
付録C トレードオフの参照

ちゃんと見てなかったけど分析データ基盤についての話もすこしだけあったんだ。

アーキテクチャの正解を探している事が多いけど本書では絶対の正解はなくトレードオフを判断して、常に自分たちで決定していくものということが説明されている。そしてこのトレードオフの判断をするための説明がされている。
最悪でないものを選べるようになりたいところである。

各章では架空のプロジェクトを題材としたストーリーから始まる。関連した問題の解決をメンバーが目指しアーキテクチャのトレードオフを判断し、話し合って決まったことをADR(Architecture Decision Records)にまとめるまでが書かれている。決定をするために何を考えているのかや、決定事項をどのようにまとめておけば良いのかがわかりやすくなっているので理解をしやすいと思った。

分割の仕方としてはできるかどうかで決めるのではなく、ビジネス上の要因で分割することが重要であることが説明されている。まあ、その分割の境界を決めるのが大変なんだろうと思うんだけれどもな。ただ、ここではビジネスを推進することをことが大事とのこと。ということは開発だけで決めれることは少ないのだろうなと思ったので、できるだけサービスのことを日々考えている、ユーザーに近い企画や営業の方々と話をすることは大事になるのだろうな。

分割するとシステム間の連携が複雑になる。例えば、通信(同期/非同期)、データアクセス/データ連携、データの整合性(アトミック/結果整合性)、サービス間のオーケストレーション、エラー発生時の回復性など色々と説明されている。そしてこれらそれぞれの中にもメリット・デメリットがあり、トレードオフを判断してどれを使うかを決めていくことになる。
これらが対処できるかどうかを見極めて分割するかどうかも考える必要が出てくるようだ。システム面では自分たちでこの辺りを責任持って決めれるようになっていきたい。

第Ⅱ部では第Ⅰ部で分割したアプリケーションやデータの繋げ方についての話がメインだった。
共通処理の実装箇所、データの所有権、分散トランザクションなどマイクロサービスを作るときに迷うことがこちらもストーリーと説明でわかりやすく書かれているなと思った。分析データとしてはデータメッシュはちゃんと実装されている基盤を見たことがないので、やったことがある人がいたらお話を聞いてみたい。

最後に紹介されていたパターンを記載だけしておく。
これらが説明できるほどには理解しておきたいので時間取りながら再度読も。

パターン 結合度 複雑さ 応答性/可用性 スケール/弾力性
エピックサーガ とても高い 低い 低い とても低い
伝言ゲームサーガ 高い 低い 低い 低い
おとぎ話サーガ 高い とても低い 中程度 高い
タイムトラベルサーガ 中程度 低い 中程度 高い
ファンタジーサーガ 高い 高い 低い 低い
ホラーストーリーサーガ 中程度 とても高い 低い 中程度
パラレルサーガ 低い 低い 高い 高い
アンソロジーサーガ とても低い 高い 高い とても高い

まとめ

  • ビジネス推進を第一に考えるのが大事というのは忘れない
  • 本書に書かれているのはこのシステムに対する選択なので自分たちのシステムのときには再度トレードオフを考える
  • 完全に理解したところなので身になるように引き続き勉強する