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

徹底的に数字で考える。

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

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へのインプットとして使うことでどういうアウトプットを出せるか？が観点としては面白いと考えている。

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

シャングリラフロンティアの22巻が発売されました！

シャングリラ・フロンティア（２２）　～クソゲーハンター、神ゲーに挑まんとす～ 

表紙はこの巻から登場となる京極です。

途中でゲーム大会を挟んだために結構長いあいだ続いたルルアイス編もここで終了。
次なるターゲットはジークウルムということでしょうか。

クターニッドがギミックボスと言う建付けだったので、今度はどういう建付けのボスになるでしょうかね。
楽しみです。

レベルキャップが外れていったり、今まで取り立たされて来なかったアクセサリー装備二関しての話題が出てくるなど、要素を追加しつつ新キャラの追加。

そして、ヴァッシュの兄貴登場。

どんな話の展開になっていくのか、23巻が楽しみです。

アラバとかもまたどこかで合流するんだろうな、と思うと楽しみですし、、、
というかクターニッドが周回だとすると、アラバも。。。。？
封将はいいとしてアラバは初回のみという扱いなんだろうか？
まぁ、NPCなのでまたルルアイスに行けば初対面のアラバと会えても不思議ではないですね。

次は8月ということなので楽しみに待ちましょう。

安斎勇樹著「問いかけの作法」を読んだ

問いかけの作法 チームの魅力と才能を引き出す技術

問いかけが必要な世界背景

本書によれば、組織はこれまでの経営層が「問題（why）」を定義し、現場が「解決策（how）」を磨き続ける縦割り構造であった「ファクトリー型」から、相互の対話を通じて「問題」と「解決策」を探索しながら、経営層は「理念（WHY）」を探究するという水平的な関係が重視された「ワークショップ型」へとパラダイムシフトしつつあるとのこと。

この、ファクトリーとワークショップという言葉は正直ピンとこない部分はあるけれど、トップダウンで物事を決めていく面と、対話を通じてボトムアップに進めていく比率は、以前とは変わってきているとは思う。

その流れにおいて、「答えを与える」のではなく「質問を投げかける」リーダーシップスタイルが有効性であると。
著者は、真の問題解決や組織の成長は、リーダーが答えを指示するのではなく、チームメンバーに適切な問いかけをすることで生まれると説いています。

なんのために問いかけるのか

なるほどな、と思ったところとして、問いかけに対しての2つのモードが示されている点です。

チームのポテンシャルを引き出すため、メンバーのこだわりポイントを深堀りしていき、固定観念にとらわれているようであれば揺さぶるための問いかけを行う。

常に「こだわり」を育てていき、「とらわれ」を疑うという点。

チームミーティングにしろ1on1にしろ、良い問いかけをしたいと考えながらも、”良い問いかけ”とはなにか？に関しての言語化がしっかりと出来ていなかったと感じた。

懸念点

そもそも、この問いかけをするにはじっくりとした対話が必要となり、時間がかかりそうな印象は受けた。
もちろん、人と人の関係なので一朝一夕にはいかないのはわかるので、根気強くやっていく必要がありそう。

こだわりにしろ囚われにしろ、当人自身が気づいていないことを話すことになると思うし、それに気づいた後にどう話を持っていくことができるのかは結構博打になりそう。
正直、それが出来たとして、チームのポテンシャル向上につなげることができるのだろうか？はまさに未知数に感じる。

相手のこだわりというものを尊重するのはわからなくもないけれど、それがそのまま仕事においていい価値観となるのかはわからないし、それ以上に優先させる事項も出てくるはず。それを多様性の一言で認めてしまうのは違うと思うわけですよ。

リーダーの腕の見せ所といえばそうなのだけど、果たして問いかけたあとに対しての対応がちゃんと取れるだろうか、それはそれで心配だ。

金色のガッシュ！！2の5巻と、ヘルモード11巻が発売されました

金色のガッシュ！！ 2 （5）

ヘルモード ～やり込み好きのゲーマーは廃設定の異世界で無双する～ はじまりの召喚士　11

ガッシュ２

ガッシュ2は単話版がちょこちょこと出ているものの、基本的に単行本を待つことにしています。
5巻は表紙にもなっている成長したモモンとウマゴンが復活するところまで。
モモンは前作の後半でかなりシリアスなキャラクターになり、そのまま渋い感じに仕上がっていますね。
そして、相変わらずバリーが強い。

ガッシュの新たな力も気になりますが、どうしても「懐かしのキャラクター勢揃い」感が強くて若干のマンネリ感がなくはないです。

物語として、前に進んでほしいところですね。

ヘルモード

主人公の性格といえば性格なのですが、相変わらず淡々と攻略が進んでいきます。

物語としては、それなりに苦難の連続なはずなのですが、あまりにも主人公が冷静に淡々と攻略してしまうので、読む方としても淡々と読んでしまう感じですね。

この、「主人公が特定ゲームのNo.1プレイヤーで、そのゲーム世界に転生して無双」パターンは数多い中で、転生先がゲームなのかよくわからんゲームっぽい世界を攻略していく。

転生ではないですが、どちらかというとシャングリラフロンティアに近い感じなんでしょうね。

いずれにしても、上位魔神と人間との実力差は大きくある中で、この先その差をどう埋めていくのか。
なんとなく神器を手に入れて神になるとかそういう方向なのかしら？とか思わなくもないですが、楽しみに攻略を待ちましょう

来週にはシャングリラフロンティアの新巻も発売されることですし、楽しみで楽しみでしょうがないです。
ストレス貯まるとついつい漫画を新しく買ってしまったりして、全くスキルアップが進まない。。。

これは、精神安定として必要なんだ！と誰にでもなく言い聞かせている毎日です。

先日公開された、fukabori.fmのエピソード128を聞きました

128. 冒険する組織のつくりかた w/ YukiAnzai

今回のゲストは、株式会社MINIGURIの安斎勇樹さん。
書籍「冒険する組織のつくりかた」を中心としたエピソードとなっていました。

冒険する組織のつくりかた──「軍事的世界観」を抜け出す5つの思考法

正直存じ上げない方でしたが、エピソードを聞く限り面白そうだったので、早速ポチりました。
過去の著作である、「問いかけの作法」だとか「問いのデザイン」も非常に気になるタイトルであります。

本書も非常にボリュームがあるようなので少し時間がかかってしまうかもしれませんが、読んで、活かせるところを実践していければと思っています。

「問い」

難しいと常に考えています。
部下との面談においても、以下に本音を引き出す問いを投げかけることができるか。
また、当人の目標やキャリアなどを導くための適切な問いとは。

考えていくしかないとは思いつつも、これら書籍の中からヒントを見つけ出して答えにつなげていけるようになりたいものです

ソフトウェアデザイン 2025年4月号が随分前に届いてはいたんだけど、ようやくある程度目を通すことができた

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

今号の特集は「ドメイン知識とどう付き合うのか？」と「公式リファレンス・man・RFCの歩き方」。

ドメイン知識

ドメイン知識という呼び方はあまり慣れておらず、普段は業務知識と読んでいて、本書でもほぼ同義として考えられている。
ドメイン知識のほうがより業界全体を指し、業務知識が個別企業の業務内容に対する知識を指すような使われ方と書かれているので、これはしっくり来る。

最終的に、開発者として何が問われるか？と聞かれたときに、もちろん言語に対しての理解や技術、アーキテクチャ等に関する知識も大事なのだが、ソフトウェアが何を解決するのか？は結局のところ業務だったりするわけで、私は業務知識だと思っている。

本書では、いくつかの立場別にドメインに対してどう向き合っていくのか？を書いているけれど、これに関しては正直ちょっと残念に感じてしまった。

自社プロダクトや、自社の業務に関する立場という話であれば、それは知らないといけない話であり、よほどの特化した立場もしくは駆け出し出ない限りはちゃんと向き合えよ、という対象だと思う。

一方で、SESや受託など、その時々で対象とするドメインが変わる場合にはそのドメインに対してどこまで理解をする必要があるのか？割り切りも必要になってくる。
そういう立場で、どう効率的にドメインの知識を吸収していくかなど、一つの考えを見れればな、と思ってしまった

でも、ドメインの知識が重要ということには変わりなくいい題材と思う

リファレンス、1次情報へのアクセス

これは、重要性は理解しつつ、読むの大変だよねって話につきてしまうんですよね。

検索エンジンでヒットするQiitaやZennなどの記事、そしてAIなどの返答。その他有象無象のブログたち。

1次情報がしっかりとしているかもしれないが、読むのに時間がかかってしまう面もあるが他の情報は古いかもしれない。

このあたりは、どういう優先順位で見ていくのか次第なんだろうけれど、やはり知りたい内容次第なんでしょうね。

仕様に関して知りたければ1次情報でしょうし、ユースケースであればネット記事でしょうし。。。

でもまぁ、RFCはもうちょっと読めるようにしておかないといけないかな、と思いました。
記事を読むと、とてもじゃないけれど読みやすい構造になってないのが気になりますが。。

いくつか、ざっと読んだけれどしっかりと読み込めてない記事もあるので、のんびりと目を通していきます