Software Designの7月号が届いたので読んだ。だいたい

Software Design (ソフトウェアデザイン) 2025年7月号

今月号の特集はRustとデータ分析のためのSQL講座。

Rust

注目はしているものの、Rust…案件で名前が上がったことはないんですよね。
このあたりは、受託ではなかなか出てこないような気がします。

OSSのツールなどがRustに置き換えられているというような話も以前に聞いてはいましたが、直近ではRustの複雑さについていけずにGoLangもそれなりに増えて、パフォーマンス上もいいという話も聞くし。
このあたりの言語選択は難しいところです。

私自身はC++をそれなりの期間やっていたので、なんとなく基本はできそうですが、やはり実際にコードを書いて考えないと駄目ですね。
とりあえず、サラッと概念だけは抑えておきつつ、機会を伺いたいかと

データ分析のためのSQL講座

アプリケーション開発主体でSQLを考えているのと、使っている関数や考え方が違うところに結構違和感を感じました。

これが、データ分析向けのSQLだとこうするべきって話なのかどうかがちょっと気になります。

特に、概念設計の順序というか、アプリケーションでSQLを書く場合は、駆動表となるテーブルを軸に、付属情報としてのマスタテーブルを結合していくイメージでした。
本特集では、そうではなくマスタからスタートしているように見えています。

おそらく、1つのSQLで完結させるのではなく、データウェアハウスなどで事前に結合済みのテーブルを作成するためにそうしているのであるとは思うのですが、このあたりの考え方は実際にDWHを構築するシーンでは気をつけないと行けないかな、と思いました。

ふむぅ。

その他連載

今号で、「RAGアプリケーション評価・改善の極意」と「実践データベースリファクタリング」の連載が終了。

実践データベースリファクタリングは結構面白い読み物ではあったのでちょっと残念です。
データベースのリファクタリングと聞くと、なかなか現実的な話には思えないのですが、労力を割いてもどこかでやらないと行けないのであればやるしかなく。。。

構築時の設計でカバーできればそれに越したことはないんですけどねー。
わからんものはわからんし、そこまで初期に工数をかけられないとか色々考えると、世の中の世知辛さと自分の思いの至らなさにただただ悲しくなるばかりです。

今日も頑張っていきましょう

Audibleにて見つけて拝聴

若者に辞められると困るので、強く言えません―マネジャーの心の負担を減らす１１のルール

4月に入社した新入社員もそろそろ会社によっては研修が終わり現場配属も始まる時期ではないかと思います。
私の所属している会社でも、7月から新入社員が配属されることになっており、その受入準備を進めているところです。

毎年のこととはいえ、接し方に関しては日々見直しが必要ですね。

本書では「11のルール」という形で下記のようなテーマ仕立てになっています

第１章　「優しさ」と「厳しさ」のバランスは？
第２章　「強制」と「主体性」のバランスは？
第３章　「スピード」と「完成度」のバランスは？
第４章　「教育」と「経験」のバランスは？
第５章　「頑張る」と「力を抜く」のバランスは？
第６章　「励ます」と「スルーする」のバランスは？
第７章　「個人の成長」と「組織の利益」のバランスは？
第８章　「強みを伸ばす」と「弱みの克服」のバランスは？
第９章　「チームワーク」と「競争意識」のバランスは？
第１０章　「お金」と「やりがい」のバランスは？
第１１章　「今までのやり方」と「新しいやり方」のバランスは？

最初読んでいて、結構強いこと言ってるなーというのが正直なところ。
読み進めていると、確かにそうだよねって思うところもあれば、一概にそうではないんじゃないかな？と思うところもやはり散見される。

結局のところ、よく言われることですがコミュニケーションは相手ありきの話であり、教育に関しても同じことが言えます。
一般的に言えることが、当該対象に対しては言えないことも多々あります。

上司としても、必ずしも一人に対して指導を行うわけではないので難しいところではあるけれど、なんでそうなのか？の理由はちゃんと伝えられるようにはなりたいと思います。

何が正解だなんてわかるものではないのですが、正解なんてないよねって思わずに探し続けるということを忘れないように接していきたいと改めて考えた次第です。

相変わらず読むのに気力がいるので時間がかかってしまうのですが、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ページ側でアクセシビリティを確保するというアプローチから変わってしまいそうな気もします。

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