はじめに 今回紹介する本 「技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック ITエンジニア本大賞という企画でこの本のことを知り、 技術書のインプットが足りてないなと思う時期だったため、改めて技術書の読み方を学んでみようと思い読んでみました。 本書の構成を簡単にお伝えすると以下の３部で構成されております。 第１部　選び方 第２部　読み方 第３部　情報発信＆共有 各部ごとに２人の著者それぞれが章を受けもってそれぞれ書かれている感じで、１冊の本なのですが、読書術を２人の視点から学べるお得な本となっております。 この本は次のような方におすすめできると思いました。 これから技術書を読み始める人 技術書を読んでいるがまだ数冊、読み方など考えたことがない 自己流でこれまで読んできているが他の人がどのように読んでいるのか知りたい この記事では「第２部　読み方」について特に印

1. 株価はサプライズによって動く 株式相場には常にプロの投資家がうごめいており、各銘柄の各種業績数値を常に予想して投資活動をしている。そんな状況下において、仮に「売上が前年比2倍」という決算が発表されても、株価が2倍になるわけではない。むしろ3倍が予想されていたのに、2倍だったら失望売りとなる。つまり事前予想と比較してこそ意味があり、staticな値や過去実績との比較を特徴量にすることはあまり意味がない。事前予想と決算の乖離、または前回予想と今回予想の乖離こそが意味のある特徴量であると言える。 2. 業績数値の単純な変化率では株価インパクトは測れない 営業利益の事前予想100億円に対し、決算が200億円の場合、 変化率 = （ 実績 - 予想 ) / 予想 の計算式を使うと、変化率は100%となる。 この変化率を特徴量にするのは一見もっともらしいが、株においてはこれは使いづらい。 営業利

ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad