「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) の引用になります。ソフトウェアアーキテクチャの設計と文書化の技術でも同様の定義を用いたので、そちらから以下に引用しました。
……ふむ、正直表現が固すぎてわからないですね。
モジュールはソフトウェアの設計時に出てくる構造で、どのように各コードを配置するか、具体例としては、クラス、パッケージ、レイヤー、データベースであれば、ストアドプロシージャやテーブルになります。
コンポーネントとコネクタは、実行時にのみ存在するもので、具体例としてはオブジェクトやコネクション、スレッドやプロセスなどが当てはまります。
そして最後の配置は、要はインフラです。具体例としては、サーバー、ロードバランサ―、そして 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
新しいギター買っちゃいました～！！
買ったのはポールリードスミス Custom 24 の35周年モデルです！
高校生のときから Custom 24 が欲しかったのですが、当時は当然手が出ず、大学生にも高過ぎアイバニーズに流れ、ついに15年の時を経て手に入れました！
ショップに行く前に気になってたのは Custom 24-08 でしたが、カムデンのギターショップで35周年記念 Custom 24 なる素敵な響きのモデルに出逢ってしまいました。
どうやら 24-08 とほぼ同じ構成に加え、10 TOP という上位10%の木材使用とのこと。つまり欲しいギターのアップグレード版！
1時間ほど複数のモデルを試奏しましたが、音も操作性も群を抜いて気に入りました。
詳しいレビューは世に出回ってる動画に任せるとして、最高に気持ちの良い音のクリアさに加え、ボリュームノブの反応の良さ、コイルタップ時の音圧の下げ幅の低さは特筆すべきものがあるなと思いました。
最大の難所はカラー選択でした。オンラインでも沢山見比べ悩み抜きましたが、最終的には、
「ギターは一期一会、出逢いを大切に」
の精神を貫き、最も店内で輝きを放っていたパープルにしました！
ふつくしい……！
新しいギター買っちゃった😍
— 雀巽（じゃくそん） (@necojackarc) June 22, 2021
高校生のときから欲しかったポールリードスミス Custom24 の35周年モデルお買い上げ！！ pic.twitter.com/uXyGqo4gKb
新しいヘッダーはこれかな！？ソファに並べてるやつと悩む！！ pic.twitter.com/jdzFS0QOjO
— 雀巽（じゃくそん） (@necojackarc) June 22, 2021
スイープのミストーンが「ぶっ！」と思い切り入ってる、同じテイクの続きの一部。 https://t.co/Id1PEsDI0e
— 雀巽（じゃくそん） (@necojackarc) June 22, 2021
人生初の全身麻酔手術をロンドンで体験してきた
ちょっと諸事情により、全身麻酔で日帰り手術を受けてきました。
人生初の全身麻酔から目覚めた！マジで一瞬で落ちてた……！これは魔法だ……！！ (@ Ealing Hospital in Southall, Greater London) https://t.co/NXvjjw2WB9
— 雀巽（じゃくそん） (@necojackarc) June 14, 2021
病室からの景色がなかなか良い。電車走ってるのぼんやり眺めてる。 pic.twitter.com/yERI8YpT3R
— 雀巽（じゃくそん） (@necojackarc) June 14, 2021
手術は今まで局所麻酔を使ったのを一回だけだったので、全身麻酔は人生初でした。
手術理由はさておき（気が向いたら書きます）、今回は全身麻酔について書きます！
Twitter での繰り返しになりますが、本当に一瞬で落ちます！
まず、徒歩で手術室 (Theatre) に向かいます。手術室はおそらく二部屋構造で、一部屋目でベッドに寝ます。 その部屋に入ると「あ、これ洋ドラマで見たことある！」な感じで、まずここでテンションがあがりました。
手術室ではコンディションの最終確認、患者が手術内容などを理解しているか、患者本人かなどの入念な確認が取られ（手術の目的は何で、実際に何を行うのか、自分の口で麻酔科医に説明しました）、手の甲に点滴針が刺されます。左手に2度刺すもうまくいかず、結果的に右手の甲に刺すことになりました。まだ失敗した左手の甲が痛い……。
準備が整うと、酸素マスクを当てられます。吸って―吐いて―とやります。 で、三回目位の息を吐いてる途中で意識がぷっつり電源を切るように消えてます。 いつの間にか点滴がスタートしてたんだろうなと思いますが、全く気づきませんでした。
起きたら50分経過してました。なんだこれ凄すぎる……。
あまりにも凄すぎて、テンションがあがりまくり、麻酔から目覚めた直後に、その辺に居る麻酔科医（多分2人居た）に物凄いハイテンションで喋りまくってました。テンションが上がりすぎていて、何喋ってたのかも良く覚えてないです。とにかく医学の凄さを体感した感動に起きた瞬間からとらわれてました。
喋っていると気づく……喉ガラガラや。
身体を起こしてみる。なんだこれ気持ち悪。ぐわんぐわんする。
良し、寝よう。
二度寝しました。
で、二度寝から目覚めるとご飯食べるか聞かれたので、オレンジジュースとたまごサンドをもらいました。 このたまごサンド、たまご美味しいんですが、パンが全然喉を通らない……これ、水分が完全に失われてる……。
かなりの時間をかけてサンドイッチを食べきると、やはり水分不足か、喉がバリッバリになってました。 このあと、コーナーショップでアイソトニック飲料を飲むまで喉はバリバリのままでした。
水を飲みまくった結果、20分に一回くらいトイレに行きました。
そして、トイレが出にくい！噂には聞いてましたが、これは出ない！ 気合で出しましたが、人によっては全然でないそうです。
退院時のチェック項目にも「トイレ出たか？」というを聞かれました。
で、そのあとは医者に手術の説明を受けて、書類手続きをして、看護師に送り出されて終了、という感じです。
この最後の送り出しですが、「確実に面倒を見れる相手に引き渡せたこと」を確認するフェーズなので、病院に迎えが来ている必要があります。妻に仕事を抜けて迎えに来てもらいました。
そんな感じで、その後丸一日なんかボンヤリしていたら、麻酔も抜けてきて、元気になってきました。
なぜか夜寝付けなかったので（多分病院で昼寝しすぎた）、筋トレして朝4時まで漫画読んでましたが、全身麻酔翌日の今日は、割と元気です。
今週末はテニスできそうだ！
32歳に、そして Engineering Manager になりました🎉🎂
本日4月27日で32歳になりました🎉🎂
また、2021年4月付けで、社会人9年目にして Engineering Manager を拝命しました！
昇進しました🎉🍻😍🥳
— 雀巽（じゃくそん） (@necojackarc) April 19, 2021
Engineering Manager を拝命しました！
マネージャーを、ましてや英語圏で母国語以外で担う日が来るとは思いもしなかったので素直に嬉しいです🥰
新しいチャレンジが目の前にゴロゴロ転がってるので、学びながら楽しみながら頑張ります💪
常にコンフォートゾーンの外へ……！
キャリアの初期では、スペシャリストなのかマネージャーなのか悩むこともありましたが、ザックリいうと、リードソフトウェアエンジニアとしての役割を通して、マネジメントおよびリーダーシップにも十分興味ややりがいを持てたので、このキャリアパスを選択しました。あと、そもそもスペシャリストの道の厳しさは大学のスペシャルな同期たちをまじかで見てたので、そもそも及び腰だったというのも正直あります。笑
エンジニアリングマネージャーは技術にも責任を持つ*1ので、スペシャリストとマネージャーのスペクトラムがあるとすれば、割と中間寄りの立ち位置だと思います。
実際メインでリードしているのは、全社レベルの技術的意思決定を行うチームです。 そこの最終決定権を持っているので、実質アーキテクトも兼任しており、エンジニアリングの第一線から離れる予定はありません。
もちろんリードソフトウェアエンジニアになった段階で、コーディングの時間は減っていましたが、それでもテックリードとして書き続けてきたので、それは続けることになると思います。タイトルがアーキテクトではなかったとしても、アーキテクトの役割（ビジネス要件や制約、技術的制約や問題そのものの掘り下げ、選択肢のトレードオフの理解、などなど）は担い続ける予定なので、かなり面白いキャリアかなと感じています。
さて、そろそろ仕事以外の話も含めて現状を軽く振り返ってみたいと思います！
こちらが去年の記事です。
去年との大きな違いは、
- エンジニアリングマネージャーになった！
- 筋トレが習慣化して筋肉増えて脂肪が減った！
- ロックダウンが緩和されてテニスができてる！
あたりでしょうか。直近のロックダウンが緩和されたのはつい最近のことですが、今はテニスができてます！ このまま夏には元通りの生活に戻るといいなぁと感じてます。
そのほかの点については大きく変わらず、ロンドンは住み心地が良く、英語はまだまだ課題だらけです！
挑戦することがたくさんですね！頑張ります！
32歳も最高に楽しんでいきましょう！ぴーす！
「シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング―」を読んだ
「シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング―」を読みました。
かなり胡散臭いタイトル（シリコンバレー、最強、新しい常識……）ですが、
- 1on1 をなぜ行うか
- 1on1 で何を行うか
- 1on1 をどのように行うか
という、WHY/WHAT/HOW をすべて簡潔に網羅した良書でした。
1on1 って結局なんなのよ？という人は、とりあえず読んでみると得られるものがあると思います。
個人的には「緊急度は低いが重要度が高いものにフォーカスする」というのは、なるほどな、と感じました。 緊急度が低いと重要度が高いもの、例えばメンバーのキャリアやモチベーションなどは、緊急度の低さから、取り掛かりが遅れて、取返しが付かないケースになることはありそうですよね。
この本を読んでぜひ最強を育てて行きましょう。笑
「英単語の語源図鑑」を読んだ
「英単語の語源図鑑」を読みました。
語源系の本は少なくとも3冊目読んでいますが、こちらの本は網羅的かつビジュアルでの説明が常に付帯しており、読み進めやすかったです。
どのタイミングの語彙力で読んでみても、一定以上発見がある良い本だと思います。 ただ、あまりにも学習の最初期ですと、「なるほど！」と思うための語彙力が足りない可能性があるので、基本単語はあらかた覚えた段階で一度目を通してみると良いかなと思いました。
登場する単語のほとんどは知っている単語でしたが、知っている単語でも各々のパーツの語源は知らなかったりで、発見がなかなかにありました。今後新しい単語に出会った時の記憶に助けになるかなと感じました。
ちなみに、過去に読んで面白かったなと思った語源系の本は以下の二冊です。
語源系の本は、ボキャブラリ自体等よりは背後にあるキャパシティというか、関連情報の整理が進むので、気が向いたタイミングで気が向いた本を読むといいかなと感じます。全部を暗記しようとして読むよりは、学習の段階ごとに気に入った本を一度だけ通読してみる、でも良いと思います。
それにより今後新しい単語を辞書で引いたときや、知っている単語を見直したときに、語源への意識と、それからくる別単語へのつながりが感じられるようになると思います。
ぜひ目を通してみてください！
「なっとく！アルゴリズム」を読んだ
「なっとく！アルゴリズム」を読みました。
- 作者:アディティア・Y・バーガバ
- 発売日: 2017/01/31
- メディア: Kindle版
特に大事だと思われる、基本となるアルゴリズムを丁寧にわかりやすく説明してあります。
簡単な内容一覧は以下の通りです。
正直、大半は学生時代に習った（ことになっている）はずですが、ダイクストラ法以降は貪欲法を除いて、名前しか覚えてないレベルでした……。 データ構造とアルゴリズムは学生時代最も苦しかった授業の一つなので、まぁ仕方ないと言えば仕方ないと思います。
学生時代と言えば、コンピューターサイエンス系の授業はたいてい苦しみ、ソフトウェアエンジニア系は楽しめた、という記憶が薄っすらあります。 最も苦しんだ科目は英語でしたが……閑話休題。
これらのアルゴリズムを全てを即座に使いこなせる必要はないと思いますが、どういう問題のときにどういったアルゴリズムを使うと良いかというザックリとしたインデックスを頭に張っておくのは、非常に重要だと思います。特に基本となるデータ構造については、知っておいて全く損はないです。
本当にわかりやすく書かれているので、「アルゴリズムが理解できる！」という自信に、そして、最初の一歩になる本だと思います。 特に未経験からソフトウェアエンジニアしてる人は是非読んでみると良いと思います*1。
以下、読んだことをあとで思い出せるように、簡単なまとめです。
1章から6章までは、基礎の基礎という感じでした。自分でも覚えているようなことが大半でした。 また、8章の貪欲法も「各ステップで局所最適解を選ぶ」というものなので、こちらも覚えていました。
ただ、6章のトポロジカルソートについては、名前と雰囲気だけ知っている状態だったので、しっかりと把握できてよかったです。 雑に言ってしまうと DAG を並べ替えて "any of the sorted items appears after its dependencies (the ones which the item in question is dependent on)" な状態にすることです。
ダイクストラ法も名前しか知らなかったです。そしてもう詳細な内容は忘れました……。 ただ、どういうときに適応できるかを思い出せるように抜き出しておきます。
9章の動的計画法については、ぼんやりと知っている……というレベルでした。 端的に言うと、部分問題先にを解くことで難しい問題を解く手法です。
個人的に少しややこしいなと思ったのが、動的計画法と分割統治の違いでした。 どちらも同じように問題の分割をするからです。
違いとしては、
- 分割統治は、部分問題の解の組み合わせが最終解になる（例：クイックソート）
- 動的計画法は、部分問題の解を再利用して、最終的に最終解を導き出す（例えば部分問題の解を二次元配列にメモ化 memoization しておき、それを計算に再利用していく）
という違いがあります。要は動的計画法は、次の部分問題を解くためにその前の部分問題を解いておく、というように、解の再利用が必要になります。
例えばナップサック問題であれば、まずはサイズ最小、物品一つから始めます。 そして物品が一つの場合の最適解を全てのサイズで解き、次に物品を二つの場合を解きます。 この際、物品が一つの際の最適解を利用します。そしてこれを繰り返します。
大事なことの一つに、部分問題が他の部分問題に依存していてはならない、というものがあります。 部分問題の解が再利用ができなくなってしまうからです（つまり解いたと思ってた部分問題は解けていなかったということ）。
動的計画法は、制約を前提として何かを最適化する際に役立ち、問題を互いに依存関係のない部分問題に分割できるときに使えるアルゴリズムとなります。
10章は k 近傍法でした。まさか回帰の話がアルゴリズムの本に入ってるとは思わなかったです。 こういう機械学習よりのアルゴリズムは、あまりアルゴリズム本で見ない印象でした。あまりアルゴリズム本を読んでないので間違った印象な可能性も高いですが。
特徴量、分類、回帰と、基本的なことに触れていて良かったです。 機械学習への入り口として非常にわかりやすいと感じました。
最後にひとつ、大事だと思った文を抜き出しておきます。
複雑なテクノロジーてあってと、そのベースとなっているのは k 近傍法のような単純なアイデアであることを理解しておくことが重要
読みやすく良い本でした！
