相変わらず読むのに気力がいるので時間がかかってしまうのですが、HBR7月号を読んだ

DIAMONDハーバード・ビジネス・レビュー20 2025年7月号 ［雑誌］特集「リーダーらしさはどこから生まれるのか」 ＤＩＡＭＯＮＤハーバード・ビジネス・レビュー

特集はリーダーらしさ。

リーダーとは？ではなくリーダー”らしさ”ってのがなかなか面白いテーマですね。

特集記事は4本あるのですが、アイデンティティマップを作成する。つまりは自分が何者なのかを知るという記事は色々と考えさせられた。

このアイデンティティマップみたいなもの。
結構リーダー研修とかでもよくやりますよね。
自分自身で作る場合もありますし、周りの人の協力を得て360度評価じゃないけれど、自分とはどんな人なのか？を認識する。周りからどういう評価を得ているかを理解する。

そういったことは自己形成において馬鹿にできない内容だと思います。

作ってみた

試しに、Claudeの助力を得ながらアイデンティティマップを作ってみました。

Claudeなので画像生成ではなくSVGで作られてしまい、ちょっと見づらいです。

問いかけをしてもらい、答えながら作るわけですが、自分自身で大事にしたいと思っていることが、最近、行動として実行できていないのではないか？と思ってしまった。

気持ちとしては、私は好奇心を持って動きたい。楽しいことがないかを探したいという人間で有りたいと思いながら、本当にそういうふうに動くことが出来ているのか？と。

もうちょっとコンフォートゾーンを出ていかないといけませんね

Audibleにあったので手にとって見た

ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 エンジニアになったら押さえておきたい基礎知識

私自身、大学時代は情報系の学科を出たわけではなかったので、社会人になってからプログラミングを始めた口。
最初は周りとの差に苦労をしました。

自分自身がどういう新人研修を受けたかな？というと、社会人研修は受けたものの、ITの新人研修は入った会社には存在しませんでした。
配属された部署は、新人は私一人で他に開発をする人は二人だけ。そういう規模の部署だったので、新人研修なんてものがないんですよね。

しばらくは書籍をひたすら読んで学ぶということをしていた記憶があります。
（その後、集合研修みたいな形の体制に徐々に変わっていきましたが）

現在の会社でも今年の新人さんたちは新人研修を現在行っていて、7月から現場配属。
配属後は各現場での学習と実務が待っているわけです。

新人研修でどれくらい、何をやるのか？はぶっちゃけ会社によってものすごい違うと思います。
そもそも、どのレベルの新人が入ってくるのかが一番大きな落差が生じる部分だと思いますし、新人研修でどこまでのレベルに到達することを目指すのか？も大きく違いそうです。

自社のプロダクトやパッケージを持っている企業であればその技術スタックを中心とした研修になると思いますし、SESなどを展開している場合はJavaなど比較的ヒット率の高い技術を教える形なんだろうと思います。

本書では、それら技術に特化した研修ではなく、もっと一般的な。
ソフトウェア開発って何をするものなの？ということに重点を置いた教育になっています。

いわば、基本情報技術者試験的な感じがしました。

結構前まではこの辺の知識ってそれほど必要性を感じていなかったんですよね。
でも最近、文系出身だとかいろいろな新卒が入ってくる中で、このあたりの知識がないと共通言語がなくて会話が成り立たないな、と感じるようになってきました。

そういう意味では悪くはないのですが、これで新人研修を終えられると現場は大混乱するだろうなぁと思うのも事実。

何を持って新人研修を終えたとするのか。どこまでのラインまで行くことを目指すのかという、新人研修の要件があまりにも企業の余裕だとかによって変わっている現実がなんともしがたい、歯がゆさを残します。

結局、自社なりの教育カリキュラムを作るしかないようにも。
なんとも非効率な効率性ですね

この業界に絶望した！

長かった・・・・

もはやそれ以外に言葉が思いつかないところはあるけれど、長かった。。。

三体2 黒暗森林 上 

三体2 黒暗森林 下

Audible合計で30時間近くの内容。

三体自体は、Ⅲとかあるようですが、一応の結末をここで迎えると言っていいのではないかと思っています（これ以降を読んでないのでそう言い切ってどうかはわかりませんが）

いろいろな思惑が絡みながら進む話は面白く、最終的な結末がどういう形を迎えるのかが非常に楽しみではあったのですが、個人的には少し消化不良な感じがしました。

何を持っての解決とするかは確かに微妙なところであり、結果として三体世界からの侵攻を食い止めることが出来たとしても、別な問題を引き起こしてしまう。
まぁ、作中でもあるように、もうどうしようもない状態なんだろうな、とも。

三体世界にしても、それで引き下がるのか～という思いは出てしまいます。

それでも三体の一作目よりこの二作目のほうが面白いと感じ、続きが気になっていたのは事実。面白い作品だったと思います。

ここまで長時間一つの作品に拘束されたのも久しぶりなので、ちょっと軽めのものをつまみ読みしていきたいですね。しばらくは。

うまくいかないときやストレスが溜まった時は、ついつい漫画を衝動買いしてしまいます

その着せ替え人形は恋をする 14巻 

「その着せ替え人形は恋をする」も14巻が出ていたのですね。
コミックを購入するのは初めてですが、アプリ等で読んでいます。

雑誌ではすでに完結したようで、次の15巻が最終巻。7月が待ち遠しいです。

アプリはこういう時、最後までは無料で読むことが出来ないので、我慢出来ずに13巻、14巻と購入してしまいました。

私は基本的に酒もタバコもやらないですし、日々のストレス発散は何だろう？と考えると、走ることと漫画を読むことになっていそうです。
いい年こいて漫画まだ読んでいるのかと言われると、まぁ、なんというかいいじゃないですか。楽しみなんですからとしか言えません。

15巻。

この話がどんな完結を迎えるのか、今から楽しみです

長い！

三体2 黒暗森林 上

2020年7月にハードカバーを購入していたものの、読むことを諦めていた三体ⅡをAudibleの力を借りて読みました。

Audibleで14時間。。。
長過ぎる

そして、三体Ⅰを読んでから5年は経っていることから、どこまで覚えているか不安でしたが、なんとか話はつながって読むことが出来ました。

上巻では面壁計画が始まって、それぞれの計画が徐々にわかってくるところ。
今は下巻を聞いているけれど、これがどんな結末を迎えるのか。

楽しみではあるんだけど、長い。。。

それでもなんとか進めることが出来るのはAudibleのすごいところなんだけど、翌々考えてみるとそこまでして聞かないといけないものなのか？という至極当たり前の疑問にぶち当たりそうで怖い

とはいえ、Audibleで聞きたいものも徐々になくなりつつあり、ランニング中に聞くものをゲットするという意味においては、ちょうどいいといえばちょうどいいんですよね。

というわけで、下巻も頑張ってます！

深沢真太郎著「徹底的に数字で考える」を読んだ

徹底的に数字で考える。

私自身、ある程度論理的に考えることが出来ているようで出来ていないのが実情な気がしています。
特に仕事における評価で数値化に関しては悩むところが多いです。

ITエンジニアにおける、スキルレベルの数値化。
難しいですよね。
一概に言うことが出来ないと言ってしまえばたしかにそう。

例えば、同じ言語で同じ開発対象での同一作業という意味では、比較はまだできます。
これが異なる開発対象だったりすると、そもそもの難易度が関係してきます。

更に、設計や製造、テストや要件定義など工程も複数ある中で何ができることをどういう評価として最終的に数値化するのか。

難しいとか、比較にならないと言っても最後には給料という数値になってしまうわけで万人に納得の行く形というのは難しいです。

定義する

本書では、まず定義するということを第一に置いている。

ITエンジニアのスキルと言うものを分解して定義すると

• 技術的なスキル
  • プログラミング能力
  • 設計力
  • 問題解決能力など
• 業務遂行スキル
  • タスク完了率・品質
  • プロジェクト管理能力
  • ドキュメンテーション能力
• コミュニケーションスキル
  • チームワーク
  • 指導力
  • 調整能力
  • 交渉力

なんて分解できるかもしれない。
更にそれぞれをどうやって数値化していくか。。。

また、これらが年を経てどう変わるのか？によって成長力が変わってくるだろうし、新技術へのキャッチアップ能力みたいなものも必要となると思う。

ある業務において優秀とされていた人が、数年経って出来ることが変わっておらず、仕事が変わることによる影響から評価を下げざるを得ないくなることもよくある話。

そうなると、数値化したスキルレベルは、年々減少するような補正を掛ける必要がある現場も出てくるかもしれない。

比較的技術が安定しているようなパッケージ開発をしているのであれば、技術力より業務遂行能力のほうが高いかもしれないし、場合によっては何よりもコミュニケーション能力を重視する場面もあるかもしれない。

そういう重み付けによってのスコア算出をすることで、何かしらの数値化が出来るのかも知れない。

実際のところ

どれだけモデルを作ったところで、よくわからん”人に気に入られる”謎スキルによって全てをかっさらっていく人も出てくるのではあるんだけど、このあたりはやってみての仮説検証をしてみたいところではある。

ただ、これ、PDCA回すのすごい長いサイクルになって仮説検証を早く回すの難しそうだな～ってのが正直なところ。
一発で当たりのモデルを組み上げるなんて無理だろうから、やっぱり積み上げていくしかないんだろうな。

ただ、数値化出来るということをこうやって考えたことで、いろいろなモデルを考えることが出来るようになるというのは数字の強いところではあると、改めて思った。

意味を本当につけることが出来るかはわからないけれど、試していきたいところです。
いい本でした。

少し前になってしまうけれど、「一日の休息を最高の成果に変える睡眠戦略」を読んだ

一日の休息を最高の成果に変える睡眠戦略 世界のビジネスエリートが取り入れる「7つの眠り方」

自分自身の睡眠に関する現状

睡眠に関して言うと、そりゃしっかり寝たほうがいいだろうし、よく7~8時間くらい眠りましょうねって話になる気がする。

私自身の睡眠時間は比較的少ない方で、以前は5時間強といった感じだった。
最近は結構睡眠時間を気にするようにしており、6.5時間くらいは取れていると思う。
起きる時間は変わってないが、0時前にできるだけ布団に入るようにしている点が変わったことだと思う。

睡眠戦略

本書で書かれている「7つの眠り方」というのは、”眠るための方法”ではなく、ライフステージや当人の置かれている状況に応じて、睡眠時間をコントロール。
そうすることで、その時時に応じたベストなパフォーマンスを引き出そうという視点であって、必ずしも安眠を進めているわけではないところが面白かった。

具体的に示されているのは下記の７つ。

• 短眠戦略：深い眠りで超回復し、突っ走る
• 快眠戦略：バランスよく眠ることで創造性を発揮させる
• 長眠戦略：レム睡眠を多く取ることで、成長速度を上げる
• 二分割睡眠：深夜に一度起きて、集中。そしてもう一度寝る。短眠を2ステージやるような感じ？
• 多分割睡眠：更に細切れに睡眠を取る
• フレックス睡眠：生活リズムや仕事のスケジュールに合わせて調整していく
• チーム睡眠戦略：一人ではなくチームで睡眠改善に取り組んでいく

自分自身、睡眠時間は少ないほうだという認識は持っているものの、短眠という状態になっているかどうか？と言われると単純に睡眠不足なだけの可能性が高い。

日中。もちろん食後とかもそうだけれど、ふと気を緩めると眠くなってしまったり落ちてしまったりするのが果たして睡眠不足から来ているのか自分自身の怠惰なのか、色々特定できない点は多いけれど、睡眠の質の改善はなんとかしないと行けない問題に感じている。

一方で、睡眠評価をアプリで見てみると、75点は超えているので決して質が悪いわけではないように見える

そうなると、やはり日中に落ちてしまうのは怠惰だからか。。。

HRVステータス

最近特に気にしているのは、Garminで計測されるHRVステータス。
体調を崩したり、足首が炎症で苦しんでいた4月はこの数値がひどいものだった

最近は、睡眠に気をつけているせいか数値はだいぶ改善されている。

そして、この数値が良い状態だと、トレーニングレディネスが顕著に良くなっている気がする。

過負荷のトレーニングによる怪我は怖く、3月末や4月頭はそのあたりの数値を無視して動いていたところもあり、数値的に大丈夫か？は一つの基準として意識していきたいところなので気をつけるようにし始めている。

これからの戦略

ライフステージによって、これらの睡眠量や内容を変化させるという考え方は面白い。

一方、物理的にそういう時間取れるんだっけ？という点やそもそも目が覚めてしまうという問題もあったりするのでなんとも言いづらいところはあります。

ただ、変に自分はショートスリーパー！みたいな考え方は捨てて、今はどういう時期なのでどういう寝方をしようという意識を持つという考え方は非常に面白いと思うので取り入れていければな、と考えました。

今月号も読み始めました

ソフトウェアデザイン 2025年6月号

今月号の特集はアクセシビリティに関するものとターミナル環境に関して。

定期的にエディタとターミナルの話題が出てくるのは、それだけ思いの強い人がいるということなのだろう。
ちなみに私はそこまで強い思い入れはないというのが正直なところ。
なので、ターミナル系の特集は読み飛ばしてしまうことが多いです。

さて、アクセシビリティです。

以前、パッケージ製品開発に携わっていたときに考えたことがあったのですが、意義は理解できつつも、取り組むことの難しいテーマに感じています。

それらが出来ていることが商業的な価値を生むケースも持ちろなるし、差別化要因となる可能性もわかるのですが、ある程度限られたリソースの中でどこまでを考慮し、更にそれに対しての効果計測までやるとなると、一過性になってしまいます。
結果として、取り組んでいるとも言えないような中途半端な状態になってしまい、廃れていくのが見えます。

解決策は法律で縛る以外に何があるのだろうか。。。
うーんって感じですね。

こういう系統こそ、AIにやってもらうのがいいのかもしれません。
ただ、それであれば代替テキストなんて用意せずに、そもそもOS側で提供される音声アシスタントなりでページの要約をしてもらう方向で動くと、各アプリやWebページ側でアクセシビリティを確保するというアプローチから変わってしまいそうな気もします。

いろいろな前提条件ありきの人たち全てを救うアクセシビリティはやはり難しく、その中で開発者として何を提供していくのか。
ちょっと哲学的な話になりかねないですね

荒木 俊哉 著「こうやって頭のなかを言語化する。」を読んだ

こうやって頭のなかを言語化する。

言語化ってなかなか難しいなと常々思っている。

言語化という言葉が適切なのかはわからないけれど、結局のところ言語化出来ていない＝モヤモヤしているみたいな感じなのかもしれない。
色々と思うところはあるのだが、その気持ちに対して結論を導いていない。
そんな状態ナノではないだろうか。

本書では、「言語化ノート術」という手法に取り組むことを提唱している。

この言語化ノート術。
要するに、何かしら考えるテーマを立て、その理由と結論を作っていくということなのだが、大事なところはそれを日々積み上げていくというところなのだと思う。

日々積み上げていくことで、自分の中での物事の見方というか、眼鏡というか。考えが把握できるようになる。
あくまでその時点での考えではあるのだろうけれど、結論まで持っていくというのが大事なところ。
そうすることで、自分の中での物事に対して着地点を作っていき、そういう思考法に頭を慣らしていく。

一方で結論にたどり着けるのだろうか？という問題もあるわけで、言語化出来たところで物事が解決するかどうかは別問題なんですよね。
問題解決のメソッドではないので。

このあたりは、あくまで”自分の頭のなかの言語化”までである認識は持ってないと行けないですね

まずは、ちょっとしばらく試してみようと思います。
毎日はきっと難しいだろうけれど。。

Software Design の5月号が発売されたので読んでいます

ソフトウェアデザイン 2025年5月号

今月号の特集はオブザーバビリティとクラス設計に関して。

オブザーバビリティに関しては、基本的にOpenTelemetryの話が中心となっていて、何年か前にも特集があったような気がする。

今年の1月にもCNCFでOvservability2.0に関しての記事もあがっていたし、より重要性のます分野でもあると思う。

What is observability 2.0?
https://www.cncf.io/blog/2025/01/27/what-is-observability-2-0/

一方で、ここまでのObservability環境を構築したことは正直まだない。
自社サービスでも運営していれば話は別なんだろうが、運用の絡まない受託だったり、そのレベルで受けたりするシステムだと、せいぜいモニタリングのレベル感。

以前、前職でプロダクト開発を行っていた際に似たようなことを検討したことはあり、あれを続けていたら間違いなくこの分野に対しての知見は溜まっていただろうなとは思うのだけど、それはそれと考えるしかない。

ただ、大げさかもしれないが手軽に組むことができるのであれば仕込んでおくに越したことはないのは間違いない話なので、開発者としては実装としてどうあるべきかをしっかりとしておかないとな、と改めて思うわけです。

DevOps的な感じですかね。

一方で、AI時代の幕が上がってしまっている現代においては、Observabilityは何もシステムに向けられるだけでなく、日常の業務そのものにも向けられるべきであり、そこから収集された様々なデータを、個別のモニタリングではなくObservabilityへと昇華する必要性はつねづね感じるところ。

もはや対象はシステムではなく人。
そしてその知見をAIへのインプットとして使うことでどういうアウトプットを出せるか？が観点としては面白いと考えている。

うん、何か出来ないかな。