だいぶ前に届いていたのですが、なかなか読み進められず。。時間がかかりました

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

今月の特集はID管理。
このあたりはちょっと苦手ですね。。。

BtoBというか、社内システム的なものを作る上ではLDAP連携はあれど外部の認証基盤を使うシーンは無いわけではないですが、結構限られる・・・うーん、相手によりますかね。

それこそOktaとか入れていれば使うことになるでしょうし。
それでも連携の手法というかやり方はそこまで大きくは変わらない印象です。
どうもあまり読み進められませんでした

連載で最近のお気にいりは「技術選定の舞台裏」今回はSUZURIのスマホアプリが取り上げられており、面白く読むことが出来ました。

いつもこの連載では自分の不勉強を感じられて辛いところですが、今回はKMPに関して。
少し前にKotlinのMultiplatformという存在を知ってはいたものの、しっかりと調べておらず今回の内容をきっかけにして調べてみようと思います。

また、Flutterでの難しさに関してもちょっと気になるところですね。
ちょうど今、Flutterに案件で挑戦しようとしているところなので、SUZURIの方々がうまく行かなかったというところが該当するのかどうか。
このあたりも勉強不足です。

というかですね、勉強なんて追いつかんのですよ。もう。
ふんがーってところです。眼の前の仕事にどれだけ積み重ねていけば良いのやら。

眼の前のことばかりだと外に目を向けることが億劫になってしまうので、やはりSoftware Designさんには頑張ってほしいところです。
ありがとうございます（何目線）

なんとなく手に取った本だったが、自分自身が組織運営に関しては悩んでいるというか、なんとかしないとなと思っている背景もあり色々と考えさせられる本だった。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Audibleで10時間近かったけれど、2周してしまった

オフィスワーク、リモートワーク、ハイブリッドワーク

GitLabはタイトルの通り、全従業員がリモートワークを実施しているオールリモートの組織とのこと。
本書としては、リモートワークの推進。それもハイブリッドの形態ではなくGitLabと同様に全従業員をリモートワークにすることを推奨としている

ただ、個人的には少し極端な気もする。
ハイブリッドの問題として挙げられているのは、オフィスワーカーとリモートワーカーそれぞれのメリット・デメリットによるお互いへの不満から来ているもの。
オフィスワーカーにとっては、通勤時間があることへの不満はありつつもオフィス設備の利用や情報取得の即時性。特に会社組織の上位レイヤーが出社している場合は、それらの人たちからの覚えの良さや情報伝達のスピードが利点として挙げられる。
リモートワーカーはなんといっても通勤が無いことによる時間の有効活用が一番の利点となる。一方で、オフィスワーカーだけが享受できる設備や情報取得に対する格差を感じてしまうところかもしれない。
先輩社員が出社している場合は、直接的な指導を受けやすいのは間違いなくオフィスであるだろう。

実際問題、新入社員やロースキルの若手メンバー育成を考えた場合、オフィスワークのほうが質問のしやすさや、問題を抱えていることへの察知のしやすさという点で良いように感じる。
どうしても、こういう有名企業の場合は、そもそもそこに入ってくる人のベースが高いという前提があるのではないかと勘ぐってしまう。
このあたりは、単純に管理の仕方の問題はあるかもしれないが、正直できる気がしないのが実情。
結果として、これを実現するためには先輩社員も出社をする必要があるなど、全体的にリモートから逆行してしまうという問題が生じる。

GitLabをオールリモートで効率的な組織足らしめている一つの要素として、情報を徹底的にドキュメント化していることを本書では紹介している。
このドキュメント化ができるのであれば、ハイブリッド状態でもある程度まで情報格差は解消できるのではないかとも思う。
オフィスワークするかリモートワークをするかの選択肢がエンジニア側に委ねられているのであれば、そこまで問題にならないのではないだろうか。もちろん、このドキュメント化の徹底ということの難しさは大いに感じることではあるのだけれど。

ドキュメント化

本書を読み、そしてGitLab Handbook の存在を知ってから、自社のドキュメント化をなんとか進めないといけないという認識を強く持つようになった。
あまりにも暗黙のルールが多すぎてしまい、ルールが定まっていない。
もしくは、明確になってなくその時その時で判断されてしまっている。これは臨機応変とは違うだろう、と。

リモートワークをするためではなく、しっかりとしたルールを明確化する。記録を取るということはこの先のAI活用が当たり前となる会社組織の中で非常に重要な要素に感じる。
ツールの進化によってドキュメント化も随分と以前と比べればやりやすくなっている。
特に私はミーティング中に話に夢中になってしまってあまりメモを取ることが出来ない。自動文字起こしをしっかりと活用しつつ、そのテキストをどう活用していくのかを含めて検討し、明文化していくことで組織の中での浸透を図っていかなければいけない

うーん、現状があまりにも出来ていないのでやることが多すぎてめまいがしてくる

これまでは正直、そのあたりをバックオフィス部隊の仕事であろうと文句をいうだけの立場だったが、少なからずメンバーからの質問は定期的に発生する。
それを考えると、二度手間なところはあるが、整備したほうが全体としては良くなりそうな気もする。
一方で、それはあくまで暗黙のルールで、公式的に明文化されていないのであればそれを明文化する方に組織内へ働きかけるのが正攻法ではある。

正攻法ではあるのはわかるんだけれど、結果としてすごく面倒くさい方向になりそうな気もするので気が進まないというのも正直なところ。

まとめ

読んでいて、学びになることは非常に多かったのだけど、モヤモヤしていたりだめだなーって思うところが多く、「ではどうするか」に関しては足がすくむところはある

言ってしまうと、本書で書かれていることの殆どは、会社組織における人事制度を中心とした枠組み。
開発組織に属している中で、どこまで独自制度を整備できるかということには結構な制約がかかる。
そして全社的な立場に立ってしまえば良いのかもしれないけれど、それは別にやりたいことじゃないんだよなーって。

まずは自組織でできるところ。
特にドキュメント化に関しては進めていくとしてそれ以上の範囲をどうするかは戦略を考えないと行けない。

今回、本の主題であったリモートワークに関して記事を書いたが、それ以外にも初めて聞く単語や考えさせられること満載の書籍だった。
GitLab Handbookは公開されていることなので、膨大ではあるが少しずつ読み込んでいってエッセンスを有効活用していきたい。

いい本だった。

Audibelで「本質をつかむ」を読んだ

本質をつかむ

先日、会社の研修でマネージャーに求められるスキルとしていくつか挙げられた中に、この「本質を見極める」というようなものがあった。

本質

自分自身、色々な場面でものすごく表面的な反応をしてしまうことがよくあると思う。
色々な場面でそれを感じるわけだが、特に上司と話をしている中で、物事の捉え方が違うな、という場面に出会うこともある。
何かしら検索でヒットしたものを、そのまま鵜呑みにしてしまうというと考えてない感じがするが、でも実質的に考えが足りていないのだと思う。
反射になっているのだと思われる。

そんなこんなで色々とモヤモヤしている中で本書を見つけたので手にとって見たというわけだ。

前半は本質を見抜くことのメリットなどが書かれているが、基本的に本書を手に取る人であればそのメリットを列挙することにそれほど意味が無いのではないかと思う。

読み進めていくとわかるが、結局のところ、考える訓練を続ける必要がある。
ただ、そもそも考えた結果導き出した自分なりの答えが、本質なのかどうかの判断が難しい。
考えた結果の確からしさがわからないと、なぜなぜを続けて行っても終わりが見えなくなることもあるはず。
この、答えがあるようでないような問いはどうしたものかと攻めあぐねる

面白いと思ったのが、本質をつかむトレーニングとして、1週間のメニューを提案してきている点。

• 月曜日: 本質的な「意味」を見抜くトレーニング
• 火曜日: 本質的な「原因」を見抜くトレーニング
• 水曜日: 本質的な「目的」を見抜くトレーニング
• 木曜日: 本質的な「特性」を見抜くトレーニング
• 金曜日: 本質的な「価値」を見抜くトレーニング
• 土曜日: 本質的な「関係」を見抜くトレーニング
• 日曜日: 本質的な「大局」を見抜くトレーニング
  題材はニュース記事や仕事の中から選ぶことになる

やってみないとわからないところだが、変に深読みしているだけで本質にたどり着くことができるのだろうか。
まぁ、でもやってみないとわからないところはありそう。

技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック

読書術と銘打たれているが、読書の方法にとどまらず、本の選び方から始まり、読み方。そして情報発信や共有の方法までを含めた構成になっている。

選び方に関しては、書店や図書館での選び方は正直私にとってはあまり活用することはないかな？と思ったが、洋書を買う際のHumble Bundle, Better World Booksなどは初耳でした。
ちなみに、紹介されていたBookDepositoryはすでに閉鎖されているそうです。。。

特にHumble Bundleは、1.0USDでのまとめ買いもできるみたいで、その時々でラインナップの差はあるのですが試してみるのには面白そう。
洋書の場合は読むのが大変そうという問題はあるのですが、このあたりはLLMを駆使するなりしてなんとかしていきたいところですね。
Humble BundleはPDFでの提供をしてくれそうなのでまだなんとかなるのですが、問題はKindleでの洋書です。
Kindleで購入して読み進められていない本も実は手元にあったりするので。。。
そういう意味で考えると、Amazonで洋書を買うのはやめておいたほうが良いかな、という気がしてきてしまいます。
Kindleで読みたければPDFを取り込めば良かったと思うので。

読み方に関しても、わかっていながら実践できていないことが多いです。
特に、物理本であればパラパラとめくるということはよくあるのですが、電子書籍になるとパラパラと進めるのが正直難しいんですよね。
ただ、技術書などで例題をコーディングするような系統だとどうしても時間がかかり、結果として最後まで走り切ることが出来ないケースがよくあります。
そういうときに、定期的に先を見ることで、進めるためのモチベーションを復活させるということはいいな、と改めて感じました。
このあたりは実践していきたいところ。

本を読んだあと。
基本的に私はBlogに書くことにしているけれど、書いているだけだな、と改めて思った。
あまり活かしきれていない。

仕事におけるコミュニケーションは、すべからく行動に結びつく必要があるということをどこかで読んだ気がする。
本に関してもそうであって、この本を読んだ後で、では自分の行動として何に活かしていくのか。どう変えていくのか（場合によっては何も変わらないこともあるとは思うけれど）
つまりは何かしらの学びがあってほしいところ。
その整理ができていないのだと思った。

まずは、Blogに書く前にObsidianに記載してその内容を整理可能にする。
そしてこの本を受けてどうしていくのかを考えて見るということをやってみようと思った。
洋書に関しての挑戦もしていくとともに、技術書を継続して続けるためにも定期的に先を見てモチベーションを上げる。先を見てモチベーションが上がらないようであれば、それは逆にあまり現時点の自分にとってはタイミングとしてあっていない本なのかもしれない。
その時はおいておこう。

また、新しいプログラミング言語などを学ぶ際には図書館で複数冊借りて違いを見るというのも面白い方法だと思った。これは直近でDartを勉強しようとしているので試してみたいところ。
ただ、千葉市の図書館でFlutterを検索したら3年前のSoftware Designしか出てこなかった。。。

技術書はなかなか厳しいな。現実は。。
これは、都内の図書館のほうが良いのかもしれない

創刊50周年記念号であるランナーズ1月号が届きました

ランナーズ 2026年1月号 

私自身はランナーズを定期購読し始めて数カ月というひよっ子ですし、そもそも走り始めて3～4年というレベルなので、50周年と言われても何にも懐かしさの欠片もないわけですが、これまでの歴史を感じる一冊です

面白いのが、それぞれの時代に色々なトレーニング方法が紹介されているのですよね。
LSDが初めて紹介された号や、ファルトレクなどなど。
知っているトレーニング方法からちょっとしたTips的なものまで紹介されていて面白かったです。

個人的に取り入れてみたいな、と思ったのは2012年11月号「信号待ちはジャンプの時間！」
これは面白い。

走っていると少なからず赤信号や車を待つようなシーンに遭遇します。
トラックを走っているわけではない以上しょうがないですね。

これまでは迂回したり信号無視したりウロウロしたりとしていましたが、ジャンプによってバネを鍛えるという発想はなかったです。
これであれば、無理に信号無視する必要もないし、かえってリラックスしてトレーニングすることができそうですね

また、同じようにバネを鍛える方法として縄跳びも紹介されており（2019年10月号）、そういえば縄跳びは地味に長くやるの大変なんだよなぁと思い返します。

多くの著名人が50周年に寄せてコメントを入れているのでまだ見切れてはいませんが、のんびり眺めていきたいと思います

「一分で話せ」でおなじみの伊藤羊一さん著「壁打ちは最強の思考術である」をAudibleで読んだ

壁打ちは最強の思考術である

伊藤羊一さんといえば、Voicyで話をよく聞いており、壁打ちに関してのよく話が出ていたことを思い出しました。
（最近はVoicy自体を諸々の理由で聞かなくなってしまったのですが）

何年もVoicyで伊藤さんの話を聞いてきているので、なんというか書かれている内容がどれもいつも話されている内容であることに、本当に日常的に壁打ちが溶け込んでいるのだと気が付きます。

実際のところ、壁打ちに限らず発話することで思考が整理されるというのは何度も経験していることで、それは部下との1on1でもよく生じる現象です。
ただ、これを壁打ちとして日常の中に取り入れるというのは、職場環境にもよるとは思いますが、どうすれば良いのかがパッと出てこない。

多分、余裕がなさすぎるのだろう

本書の中でも、コーヒー片手にウロウロしていると壁打ちの依頼が来る。。。なんてエピソードが紹介されているけれど、それは壁打ちが組織レベルで根付いている職場であるし、そもそも日常的に壁打ちをするようなネタがある・・・？

と、ここまで考えてふと思うのは、我々IT技術者に取ってみれば、壁打ち＝ソースコードレビューなのではないかと。
いやいや違うだろうと。

レビュー ＝> 対象に対してのレビューアーからの評価や改善点の指摘
壁打ち ＝> 壁打ちをしたい人の思考の整理・深堀り・気づきの創出

と考えるとやはりレビューを壁打ちとするのにはちょっと無理がありそう。
レビューを出すもっと前の段階なんだろう。

であるならば、タスクを与えた後でその実装方針やなんかの検討結果を話してもらうような”壁打ち場”を意図的に作ってしまうのが良いのかもしれない。
ペアプロやモブプログラミングに近いのかもしれない

そんな気がしてきた。
いずれにしても、時間を取って行う行為ではあるので全てに適用するというのは難しいところだけれど、やってみる価値はありそうだ。

そしてここまで書いていてちょっと思うのは、私にとってこうやってブログを書くという行為も一人でやっているけれど壁打ちみたいなものだよな、と。
誰かに読んでもらって反応が返ってくるわけではないので、打ちっぱなしな感じはあるけれど。
まぁ、それはそれだろう。

HBRの12月号をようやく一通り。
今月号は「P. F. ドラッカー 『真摯さ』とは何か -経営と人生の指針-」特集でした

DIAMONDハーバード・ビジネス・レビュー 2025年12月号 ［雑誌］特集「P. F. ドラッカー 『真摯さ』とは何か -経営と人生の指針-」 ＤＩＡＭＯＮＤハーバード・ビジネス・レビュー

ドラッカーの言葉として、「真摯さ」という言葉はそれなりに認識しているつもりでしたが、元々の言葉である”integrity”という単語の意味。ニュアンスという認識は全く持っていませんでした。
そういう意味では日本語訳に頼るというのはある意味難しいものですね。
Google先生でインテグリティを検索すると下記のようになります

インテグリティとは「誠実さ」「真摯さ」「高潔さ」を意味し、高い倫理観や道徳観に基づいて、自分の信念や原則に忠実に、一貫して行動する様を指します。単なる正直さにとどまらず、不利な状況でも自分の信念を貫くことが本質です。特にビジネスにおいては、経営者や管理職に不可欠な資質とされ、企業全体の信頼性を高める要素と考えられています。 

インテグリティの主な意味

• 誠実さ・真摯さ: 正直であるだけでなく、自分の言動に責任を持ち、言葉と行動を一致させること。
• 高潔さ: 自分の信念や原則を、妥協することなく一貫して守り抜くこと。
• 完全性・健全性: 語源のラテン語「integer」が持つ「完全な」「健全な」という意味合いも含まれます。
• 責任: 失敗や困難な状況に直面しても、現実から逃避せず、自分で責任を負おうとする姿勢。 

ビジネスにおけるインテグリティ

• 経営者・管理職の資質: 信頼を築く上で不可欠な資質と見なされ、特に管理職や経営者に求められる重要な要素です。
• インテグリティ・マネジメント: 法令遵守だけでなく、より広範な社会的責任や企業倫理を実践する経営手法を指します。
• 企業文化への影響: インテグリティの高い人材を採用・育成することで、組織全体の誠実性を高めることができます。 

では、ここで言う「自分の信念や原則に忠実に、一貫して行動する様」で挙げられている”自分の信念や原則”がなにか？と考えてしまうと途端に自信がなくなってしまうものです。。。

ただ、物事を判断するうえで何を重視するのか？何を基準にして良し悪しを決めていくのかということに関してはある程度作ることができるのではないだろうか。
もちろん、IT技術に関して言うと判断基準が変わらなかったとしても、その時その時での最新技術の変化によって判断結果が変わることは多くありそう。

逆に言うと、そういった変化によって生じた前提条件の変化も、基準を明確にすることで一貫性を持った形で受け入れられるのではないかとも思う。
ようは一度判断した内容に対しての一貫性ではないという話なんだろう。

まぁ、判断基準がブレブレになってしまわはないようにだけはしないといけません。

ドラッカー。
一時期、かなり感銘を受けて著作や関連作を色々と手を出したことがあります。
今思うと、ちゃんと身になっているのだろうか？は非常に怪しいところではあるのでこれを機会に読み直してみたいと思います。

ドラッカー名著集1　経営者の条件

少し前に購入した、AIエージェント開発の本を亀スピードですが進めています。
Kindleで購入したのですが。。。

https://amzn.to/44cXD3H

まさかの固定レイアウト本でした。

AIなどを取り扱うのであればデータの重要性が第一に考えてほしいものですが、まさかの固定レイアウト。つまりは画像本です

スマホで見ると文字が小さくて読みづらいし、拡大すればスクロールを必要とするのでこれも読みづらい。
更にKindleでマーカーを引くこともできない。

なぜ固定レイアウトにしたのでしょう。。
レイアウトにこだわりを見せたかったのかもしれませんが、作中のコードもコピペできなかったりして、正直Kindleで買ったことを後悔したくらいです。
紙で購入したほうが良かった。

よくよくAmazonのページを見ると、「※この電子書籍は、「固定レイアウト型」で配信されております。説明文の最後の「固定レイアウト型に関する注意事項」を必ずお読みください。」と書かれているので、それに気が付かなかった自分が行けなかっただけなのかもしれませんが。。

残念だ

Audibleにて「ルポ 人が減る社会で起こること」を読んだ

ルポ 人が減る社会で起こること──秋田「少子高齢課題県」はいま

少子高齢化は日本全体の課題ではあるけれど、その進行具合はやっぱり地方に行けば行くほどひどくなり、本書は秋田でのその状況を伝えているルポとなっている

私自身、大学時代は山形に４年住んでいたし、妻は宮城出身ということもあって東北に関して全然馴染みがないわけではない。
ただ、秋田に関しては温泉に何度か行った程度であまり知らなかった。

どうしても移動のルートは太平洋側を中心になりがちで、秋田って絶妙に生きづらい場所なんですよね。
青森ならそのまままっすぐ北上すれば良いのだけど、秋田の場合は盛岡で方向を変える必要が出てしまいますし。そういう行きづらさもあるんだろう。

本書では、人口減少や高齢化。
はたまた、昨今急に多くなったようにも感じるクマ被害や食文化など幅広い内容で秋田や東北周辺を紹介していて面白かった。

特に食文化に関して面白いと思った。
山形や宮城でも感じていたのだけれど、基本的に味が濃い。というかしょっぱい。

宮城でも、紫蘇巻とか食べたことがあるけれど、なんでこんな食べ物が成り立つんだろう？と思ったくらいにしょっぱかった。
本書によると秋田は更にしょっぱいらしい。。。

雪深い地方では、冬に食材を持たせるために塩蔵するというところからこの食文化が端を発しているということなので歴史的経緯としては理解できる。
現代においては、塩分過多は好まれるものでもないので、この伝統というか食文化を伝えるべきなのかという話は、結構悩ましい問題にも感じた。

こういう歴史的な経緯があり、それが現代においては解決されている問題に関して以前の状態を伝統として保持したものか。。。結局は変わっていくしか無いのではないかな、と思う。

うーんと思ってさとふるで秋田県を見ていたら、稲庭うどんの写真がホラーものだった

もうちょっと、なんとかなっただろう・・・

Audibleで「24 TWENTY FOUR 今日1日に集中する力」を読んだ

24 TWENTY FOUR 今日1日に集中する力

眼の前のことに集中することの大事さというものに対して、様々な論文などを集めて本に仕立てたような一冊。
ひたすら引用が続くので、基本的には聞いたことがあるような内容が多いような印象を受けた。

スタンフォード監獄実験の話などが出て、いかに人間が環境や役割によって影響を受けてしまうのかみたいな話が出てくるのだが、スタンフォード監獄実験自体はすでに否定されていたのでは、とふと思った

スタンフォード監獄実験 – Wikipedia

そう考えると、論文なんてものはその肯定・否定の両方が存在しているので、この論文を集めて作ったものに対して、うーんと思わざるを得ない気持ちが出てしまう。

まぁ、結局のところどんな情報であれ自分が動き出すきっかけとなるのであれば何でも良いのだとは思う。
ただ、今日一日に集中＝先を考えないということではないはずなので、言葉ヅラで変に考えてしまわないようにはしていかないといけないだろう。