雀巽の日記帳

雀巽が綴る日常の記録

Happy New Year 2022

あけましておめでとうございます!

今年もよろしくおねがいします!

昨年に引き続き、今年もロンドンの自宅での年越しでした。

早速、例年通りの簡単な振り返りをしたいと思います。

necojackarc.hatenablog.com

大きな出来事

勤続年数が初の3年越え

これを書いている現時点でもうすぐ丸4年ですが、3社目にして初めて、勤続年数が3年を突破しました。

necojackarc.hatenablog.com

波乱万丈な日々を今でも過ごしているので、この記録はまだ伸びそうです!

スタートアップの成功率を考えると、この先もまだまだ苦労は絶えないと思いますが、できることを頑張っていきたいと思います!

エンジニアリングマネージャーになった

キャリアの初め頃はマネージャーになる未来は想像していませんでしたが、ついにマネージャーになりました。

necojackarc.hatenablog.com

エンジニアリングマネージャーの職責については色々あり、かつ会社によって違うと思いますが、とりあえず大きな変化としては、正式にいわゆる部下と、ある程度の人事権を得たのが大きな違いでしょうか。人事権と言っても、もちろん単独で何かを決定するレベルではありませんが。

「エンジニアリング」マネージャーであるので、技術などのキャッチアップがおろそかにならないようにするのが今後の課題だと思います。

テニスクラブに加入した

秋ごろから色々なテニスイベントに参加するようになり、ついに冬にテニスクラブに加入しました。 コーチングはいまだに受けていませんが、ソーシャルセッションに頻繁に参加しています。

色々な人と試合をすると、練習では全く見えてこなかった課題や問題がたくさん出てきて、成長の糧になり良いです。

来年はクラブでのリーグ戦、そして誰でも申し込み可能なローカルリーグ戦に挑戦する予定です!

テーマ

2021年のテーマも引き続き、

  • 挑戦
  • 英語
  • 健康

でした!

挑戦

挑戦、特に常に新しいことに取り組む、新しいことを学ぶをテーマとしており、具体的には、

  • 興味が湧いたら即行動し、小さくとも新たな挑戦をし続ける(次の大きな挑戦への備えとなる)
  • 既知に囚われず未知に触れ続ける(未知のジャンルや技術も問題解決の選択肢として常に考慮する

としていました。

仕事ではエンジニアリングマネージャーとして日々未経験のことに飛び込むというのを続けれているかなと思います。会社はどんどん大きくなっているので、今後この挑戦は続くかと思います。

新しい技術については、なかなか自分からは触れられていませんが、新メンバーや人との交流を通してキャッチアップは最低限出来ているので、これも続けるか、もっと情報量を増やしていけたらいいなと思います。

プライベートではテニスクラブとリーグ戦への加入が自分にとっては大きな挑戦でした。

30歳前後で始めた新しいスポーツを本格的にやっていくのは、踏み出す勇気が必要でした!ちょっと踏み出せて来てる!

英語

英語の多読多聴をテーマにしており、具体的には、

  • 英語の映画やドラマを積極的に視聴する
  • 英語の本を積極的に読む(特に小説など、これまであまり英語で触れてきていないジャンルがベスト)

としていました。小説は……読めていませんが、英語の本を読む機会や、英語の動画コンテンツを楽しむ機会はかなり増えてきているかなと思います。

これはこの調子で続けていきたいと思います。

健康

健康、特にスポーツと食生活をテーマ都市、具体的には、

  • テニスと筋トレの継続
  • 1日7時間睡眠
  • 食事は満腹を避け常に腹八分目以下にする

としていました。睡眠以外は及第点だったかなと思います。睡眠については、そろそろ本格的に改善が必要です……。 おそらく意識改革から始める必要があると思いますが、まだ具体的なプランはないです……。

ただ、運動と食事により、身体のコンディションはかなり良いです!

あとは睡眠と飲酒量に気を付けたいですね……!

2022年のテーマ

2021年をほぼそのまま引き続き2022年のテーマ、サブテーマ、タスクとしたいと思います!

軽微な変更として、英語の多読でジャンルへの言及は無しにしました。 何を読んでもいいし、何を見ても良いので、とにかくインプット量を増やす、ということを掲げたいと思います。

  • 挑戦(常に新しいことに取り組む/を学ぶ)
    • 興味が湧いたら即行動し、小さくとも新たな挑戦をし続ける(次の大きな挑戦への備えとなる)
    • 既知に囚われず未知に触れ続ける(未知のジャンルや技術も問題解決の選択肢として常に考慮する)
  • 英語(多読多聴)
    • 英語の動画を積極的に視聴する
    • 英語の本を積極的に読む
  • 健康(スポーツと食生活)
    • テニスと筋トレの継続
    • 1日7時間睡眠
    • 食事は満腹を避け常に腹八分目以下にする

そして今年ももちろん、

将来の自分が過去の自分に向かって胸張れる存在になれるようにマイペースに生きていきたい

という自分の言葉と、

『小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道』

というイチロー選手言葉を今年も大切にしていきたいと思います!

2022年も最高に楽しんでいきましょー!

ぴーす!

「Design It! ―プログラマーのためのアーキテクティング入門」を読んだ

「Design It! ―プログラマーのためのアーキテクティング入門」を読みました。

正確には、英語版を読んだので、読んだのは "Design It!: From Programmer to Software Architect (The Pragmatic Programmers)" です。

こちらですが、端的に言って、良本でした!

アーキテクトが何者なのか、何をどんな風に考える必要があるのかについて、良くまとまっています。そしてソフトウェアアーキテクチャとは何か、という意外と答えにくい問いにも明確に答えています。

より端的に言うとソフトウェアの設計をする際の思考原則について触れている本で、デザインパターンのような本ではないです。

まず、ソフトウェアアーキテクトが何か、という点についてですが、本書では三要素に分割しています。これはこの本独自ではなく Software Architecture in Practice (SEI Series in Software Engineering) (English Edition) の引用になります。ソフトウェアアーキテクチャの設計と文書化の技術でも同様の定義を用いたので、そちらから以下に引用しました。

  • モジュール (module): ソフトウェアの静的構成要素としてのモジュールとそれらの間の静的関係からなる構造の表現
  • コンポーネントとコネクタ (component and connector): システム実行時の特徴を表現する動的構成要素としてのコンポーネントとそれらの間の関係からなる構造の表現
  • 配置 (allocation): ソフトウェアの静的構成要素や動的構成要素と、それらのハードウェアやネットワーク、開発環境への割り付けという関係からなる構造の表現

……ふむ、正直表現が固すぎてわからないですね。

モジュールはソフトウェアの設計時に出てくる構造で、どのように各コードを配置するか、具体例としては、クラス、パッケージ、レイヤー、データベースであれば、ストアドプロシージャやテーブルになります。

コンポーネントとコネクタは、実行時にのみ存在するもので、具体例としてはオブジェクトやコネクション、スレッドやプロセスなどが当てはまります。

そして最後の配置は、要はインフラです。具体例としては、サーバー、ロードバランサ―、そして Docker コンテナなども含まれます。

もっとザックリまとめてしまうと、モジュールはいわゆるソフトウェアの設計、配置はインフラの設計、そしてコンポーネントとコネクタはアルゴリズム、と捉えてもいいかもしれません。

これを全部含めて、「ソフトウェアアーキテクチャ」と定義しています。

そしてこれに責任を持つ、アーキテクトが何者かについて端的にまとめると、

  • ソフトウェアの全体がどうなってるかに責務を持つ
  • エンジニアリングの観点からの問題定義を行い、実装可能なチャンクに分割する
  • 設計に際しては品質要件(非機能要件とよく呼ばれるもの)のトレードオフを把握し意志決定を行う
  • ソフトウェア全体が適切に動いてることを保証する
  • 技術的負債の把握やコントロールを行う
  • チームメンバー全体のアーキテクトとしてのスキルを育てる(アーキテクトが多いチームが最良のチーム)

といった感じです。役職としてのアーキテクトが会社になかったとしても、この役割を担っている人は確実にいると思います。

その場合、エンジニアリングマネージャーだったり、テックリードだったりがになっているんではないかと思います。もし会社がまだ小さいのであれば、CTO が兼任しているケースも全然ありえます。

プロダクトマネージャはいわゆる機能要件、プロダクトがどのような価値をユーザーに届けるかに重点を置くのに対し、アーキテクトは品質要件(非機能要件)を軸に意思決定をすることになります。アーキテクチャの選定は品質要件(速度や拡張性、開発用意性、デプロイ用意性など)を大きく左右するためです。そして、どのようにソフトウェアが構築され、いつデリバリーされるかという点にも責任を持ちます。

ソフトウェアエンジニア、もしくはアーキテクトやマネージャーとして、常に意識しておくと良質な意思決定ができそうだなと思ったことについては、

  • 制約と要件を理解し、それに応じたアーキテクチャを考える
  • 良い解決策を見つけるためには問題の理解が必要だが、さらなる問題の理解のためには解決策の模索が必要で、このループを回す必要がある
  • 認知負荷を下げる為の設計を行う(メンテナンス性の向上に必須で、Team Topologies など開発組織構造などの文脈でも出てくる)
  • リスクドリブン設計(想定されるリスクを分析しアーキテクチャの比較検討と選択を行う)

あたりがありました。

あと、図に関する話が非常に良かったです。The C4 model で紹介されている考え方は、目を通しておく価値があります。 それについては、以下の動画に良くまとまっています。

大事なことは、

  • 図を描く際は抽象化(粒度)を先に考え、表現(記号)はその次
    • これは要は「誰を対象にするか」を最初に考えるということです。例えば地図を見る場合、世界地図が欲しい場合、街単位、ストリートビューなど、求めるものによって違うと思います。最初にこれを意識してから、必要な表現を考える、という話です。
  • 色や形などは、既に意味が通る図をさらにわかりやすくするために使う
    • つまり色や形をすべて取り除いても、意味が分かる図でないとだめ

の2つです。実際これを守って図を描いてみたんですが、格段にわかりやすくなりました。 アーキテクチャや設計などのレビューを行う外部の会社とのやり取りに使ったのですが、評判がものすごくよかったです。

特に効果的だと思ったのは、矢印には常に "(A) does something with (B)" などのように、矢印の元が主語になり、先が文章の最後に来るような説明を書く方法です。これで一発で矢印が意味しているところがわかるようになります。

そのほか、たくさんのワークショップが最終章で紹介されています。設計のフェーズにおいて、今何をするべきか変わると思いますが、それに応じて使えるワークショップがまとまっているので、軽く目を通してみるといいと思います。

この「今何をするべきか」は大事で、実際に本書では常に、

  • Understand
  • Explore
  • Evaluate
  • Make

の区分けがされていました。例えば、そもそも問題や制約を理解する必要があるのか、現状のアーキテクチャの理解を深めるのか、それとも解決策を探るのか、はたまたどのようなリスクが潜んでいるか考えるのか、最後の意思決定を行うのか、などです。

面白い点として、かなり大きなシステム開発も想定しているところがあります。どの程度事前のデザインに時間をかけるべきかの話があるのですが、一番大きいものは本当に大きく、おそらく SIer などに居ない限り目にしないような規模の話もあります。

つまり、ソフトウェア開発に携わる人であれば、だれでも楽しめる本なんじゃないかと思います!

良書でした!

My New Gear... PRS 35th Anniversary Custom 24

新しいギター買っちゃいました~!!

f:id:necojackarc:20210622212006j:plain

買ったのはポールリードスミス Custom 24 の35周年モデルです!

高校生のときから Custom 24 が欲しかったのですが、当時は当然手が出ず、大学生にも高過ぎアイバニーズに流れ、ついに15年の時を経て手に入れました!

ショップに行く前に気になってたのは Custom 24-08 でしたが、カムデンのギターショップで35周年記念 Custom 24 なる素敵な響きのモデルに出逢ってしまいました。

どうやら 24-08 とほぼ同じ構成に加え、10 TOP という上位10%の木材使用とのこと。つまり欲しいギターのアップグレード版!

1時間ほど複数のモデルを試奏しましたが、音も操作性も群を抜いて気に入りました。

詳しいレビューは世に出回ってる動画に任せるとして、最高に気持ちの良い音のクリアさに加え、ボリュームノブの反応の良さ、コイルタップ時の音圧の下げ幅の低さは特筆すべきものがあるなと思いました。

最大の難所はカラー選択でした。オンラインでも沢山見比べ悩み抜きましたが、最終的には、

「ギターは一期一会、出逢いを大切に」

の精神を貫き、最も店内で輝きを放っていたパープルにしました!

ふつくしい……!

人生初の全身麻酔手術をロンドンで体験してきた

ちょっと諸事情により、全身麻酔で日帰り手術を受けてきました。

手術は今まで局所麻酔を使ったのを一回だけだったので、全身麻酔は人生初でした。

necojackarc.hatenablog.com

手術理由はさておき(気が向いたら書きます)、今回は全身麻酔について書きます!

Twitter での繰り返しになりますが、本当に一瞬で落ちます!

まず、徒歩で手術室 (Theatre) に向かいます。手術室はおそらく二部屋構造で、一部屋目でベッドに寝ます。 その部屋に入ると「あ、これ洋ドラマで見たことある!」な感じで、まずここでテンションがあがりました。

手術室ではコンディションの最終確認、患者が手術内容などを理解しているか、患者本人かなどの入念な確認が取られ(手術の目的は何で、実際に何を行うのか、自分の口で麻酔科医に説明しました)、手の甲に点滴針が刺されます。左手に2度刺すもうまくいかず、結果的に右手の甲に刺すことになりました。まだ失敗した左手の甲が痛い……。

準備が整うと、酸素マスクを当てられます。吸って―吐いて―とやります。 で、三回目位の息を吐いてる途中で意識がぷっつり電源を切るように消えてます。 いつの間にか点滴がスタートしてたんだろうなと思いますが、全く気づきませんでした。

起きたら50分経過してました。なんだこれ凄すぎる……。

あまりにも凄すぎて、テンションがあがりまくり、麻酔から目覚めた直後に、その辺に居る麻酔科医(多分2人居た)に物凄いハイテンションで喋りまくってました。テンションが上がりすぎていて、何喋ってたのかも良く覚えてないです。とにかく医学の凄さを体感した感動に起きた瞬間からとらわれてました。

喋っていると気づく……喉ガラガラや。

身体を起こしてみる。なんだこれ気持ち悪。ぐわんぐわんする。

良し、寝よう。

二度寝しました。

で、二度寝から目覚めるとご飯食べるか聞かれたので、オレンジジュースとたまごサンドをもらいました。 このたまごサンド、たまご美味しいんですが、パンが全然喉を通らない……これ、水分が完全に失われてる……。

かなりの時間をかけてサンドイッチを食べきると、やはり水分不足か、喉がバリッバリになってました。 このあと、コーナーショップでアイソトニック飲料を飲むまで喉はバリバリのままでした。

水を飲みまくった結果、20分に一回くらいトイレに行きました。

そして、トイレが出にくい!噂には聞いてましたが、これは出ない! 気合で出しましたが、人によっては全然でないそうです。

退院時のチェック項目にも「トイレ出たか?」というを聞かれました。

で、そのあとは医者に手術の説明を受けて、書類手続きをして、看護師に送り出されて終了、という感じです。

この最後の送り出しですが、「確実に面倒を見れる相手に引き渡せたこと」を確認するフェーズなので、病院に迎えが来ている必要があります。妻に仕事を抜けて迎えに来てもらいました。

そんな感じで、その後丸一日なんかボンヤリしていたら、麻酔も抜けてきて、元気になってきました。

なぜか夜寝付けなかったので(多分病院で昼寝しすぎた)、筋トレして朝4時まで漫画読んでましたが、全身麻酔翌日の今日は、割と元気です。

今週末はテニスできそうだ!

32歳に、そして Engineering Manager になりました🎉🎂

本日4月27日で32歳になりました🎉🎂

また、2021年4月付けで、社会人9年目にして Engineering Manager を拝命しました!

キャリアの初期では、スペシャリストなのかマネージャーなのか悩むこともありましたが、ザックリいうと、リードソフトウェアエンジニアとしての役割を通して、マネジメントおよびリーダーシップにも十分興味ややりがいを持てたので、このキャリアパスを選択しました。あと、そもそもスペシャリストの道の厳しさは大学のスペシャルな同期たちをまじかで見てたので、そもそも及び腰だったというのも正直あります。笑

エンジニアリングマネージャーは技術にも責任を持つ*1ので、スペシャリストとマネージャーのスペクトラムがあるとすれば、割と中間寄りの立ち位置だと思います。

実際メインでリードしているのは、全社レベルの技術的意思決定を行うチームです。 そこの最終決定権を持っているので、実質アーキテクトも兼任しており、エンジニアリングの第一線から離れる予定はありません。

もちろんリードソフトウェアエンジニアになった段階で、コーディングの時間は減っていましたが、それでもテックリードとして書き続けてきたので、それは続けることになると思います。タイトルがアーキテクトではなかったとしても、アーキテクトの役割(ビジネス要件や制約、技術的制約や問題そのものの掘り下げ、選択肢のトレードオフの理解、などなど)は担い続ける予定なので、かなり面白いキャリアかなと感じています。

さて、そろそろ仕事以外の話も含めて現状を軽く振り返ってみたいと思います!

こちらが去年の記事です。

necojackarc.hatenablog.com

去年との大きな違いは、

  • エンジニアリングマネージャーになった!
  • 筋トレが習慣化して筋肉増えて脂肪が減った!
  • ロックダウンが緩和されてテニスができてる!

あたりでしょうか。直近のロックダウンが緩和されたのはつい最近のことですが、今はテニスができてます! このまま夏には元通りの生活に戻るといいなぁと感じてます。

そのほかの点については大きく変わらず、ロンドンは住み心地が良く、英語はまだまだ課題だらけです!

挑戦することがたくさんですね!頑張ります!

32歳も最高に楽しんでいきましょう!ぴーす!

*1:エンジニアリングマネージャーの役割などについてはこちらの記事がわかりやすくまとまっていると思います

「シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング―」を読んだ

シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング―」を読みました。

かなり胡散臭いタイトル(シリコンバレー、最強、新しい常識……)ですが、

  • 1on1 をなぜ行うか
  • 1on1 で何を行うか
  • 1on1 をどのように行うか

という、WHY/WHAT/HOW をすべて簡潔に網羅した良書でした。

1on1 って結局なんなのよ?という人は、とりあえず読んでみると得られるものがあると思います。

個人的には「緊急度は低いが重要度が高いものにフォーカスする」というのは、なるほどな、と感じました。 緊急度が低いと重要度が高いもの、例えばメンバーのキャリアやモチベーションなどは、緊急度の低さから、取り掛かりが遅れて、取返しが付かないケースになることはありそうですよね。

この本を読んでぜひ最強を育てて行きましょう。笑

「英単語の語源図鑑」を読んだ

「英単語の語源図鑑」を読みました。

英単語の語源図鑑

英単語の語源図鑑

語源系の本は少なくとも3冊目読んでいますが、こちらの本は網羅的かつビジュアルでの説明が常に付帯しており、読み進めやすかったです。

どのタイミングの語彙力で読んでみても、一定以上発見がある良い本だと思います。 ただ、あまりにも学習の最初期ですと、「なるほど!」と思うための語彙力が足りない可能性があるので、基本単語はあらかた覚えた段階で一度目を通してみると良いかなと思いました。

登場する単語のほとんどは知っている単語でしたが、知っている単語でも各々のパーツの語源は知らなかったりで、発見がなかなかにありました。今後新しい単語に出会った時の記憶に助けになるかなと感じました。

ちなみに、過去に読んで面白かったなと思った語源系の本は以下の二冊です。

necojackarc.hatenablog.com

necojackarc.hatenablog.com

語源系の本は、ボキャブラリ自体等よりは背後にあるキャパシティというか、関連情報の整理が進むので、気が向いたタイミングで気が向いた本を読むといいかなと感じます。全部を暗記しようとして読むよりは、学習の段階ごとに気に入った本を一度だけ通読してみる、でも良いと思います。

それにより今後新しい単語を辞書で引いたときや、知っている単語を見直したときに、語源への意識と、それからくる別単語へのつながりが感じられるようになると思います。

ぜひ目を通してみてください!