ノンアルコールビールいろいろ

最近、いろいろなノンアルコールビールを飲んでいて、自分の中での順位とか好みとかが分かってきたので、レビューというほどではないですが簡単にまとめてみようと思います。

なんとなく、個人的に好みの順番で紹介してみようと思います。

これは完全に（ドイツ）ビール！な味のヴェリタスブロイ

ノンアルコールビール ヴェリタスブロイ 缶 330ml×24本

これは本当にお勧めです。国産のノンアルしか飲んでない父親に今度もっていってあげよう。

アルコールが入ってないことを除けば、もはやただの美味しいビール以外の何物でもないです（個人の感想）

ぶっちゃけ、アルコール入りの普通の市販の国内ビール・発泡酒の大半を飲むならこっちのほうが美味しいまである（個人の感想）しかも本物ビールを買うより安い。

典型的な日本のビール（ピルスナー）ではないです。もっとホップが効いてて、エール・・・？とまではいかないですが、少し甘い感じです。

糖質量も比較的少なめで、ノンアルのなかでもさらにヘルシーでいうことなし！最高だ！

キリンラガーを飲んでいるかのようなラガービール感：Ninja ラガー

【ハラル認証】日本ビール 忍者ラガー ノンアルコールビール [ ノンアルコール 350ml×24本 ]

これは（も）本当にお勧めです。国産のノンアルしか飲んでない父親に今度もっていってあげよう（２回目）

見出しにも書いたのですが、私のつたない舌だと完全にキリンラガーの味です。キリンなみの苦み、重さがあって、でもノンアル。文句なしに美味しいラガー。

上のヴェリタスとは全然ちがうキャラクターの持ち主なので、これは完全に好みによると思います。自分はながらくラガーを飲んでいなかったのでヴェリタスのほうが好きですが、キリンラガーと思っておけば間違いないので、安心して飲める、というかたもいるかもしれません。

変わり種といえるかもしれないけど、飽きがこないエール系: キリン グリーンズフリー 

【ノンアルコールビール】キリン グリーンズフリー [3種ホップ香る 爽やかな味わい] 350ml×24本

次に好きなのがこれ。国内主要メーカの出しているノンアルだとこれが一番好みです。これも父親に（３回目）

味の雰囲気としては、ヴェリタスと同様にホップの香りが効いた、なんとなくエールよりの風味ですが、ヴェリタスみたいに（国産だと）飲んだことがない味！、ということはないです。ホワイトベルクが好きなひとだと「あ～」ってなるような感じです。

典型的な国産ピルスナーもまあいいのですが、どうしても一本調子になっちゃうんですよね・・・

そういうのはたまに飲むエビスとかプレモルで間に合ってます！なので、ノンアルは違うキャラクターのビールが好きです。

味が以前のパッケージよりも落ちた、という話もあるのですが、その以前を知らない身からすると問題なし。ヴェリタスに出会う前はエース級の扱いでした。今も時々普通に買ってます。美味しいです大好きです。上２つよりも明確に安いのも嬉しい！

独特の甘くてオレンジフレーバー、こういうビールも海外だとあるよね、なクラウスターラー

ドイツ産 ノンアルコールビール クラウスターラー 330ml×24本 ノンアル ビールテイスト ケース販売 ビアテイスト 長S

これもドイツのノンアルなんですが、かなり独特の味があります。明らかに甘みがあって、香りもオレンジ系のしっかりした芳香があります。

なので、苦いビールが苦手な女性とかだと喜ぶかも。

かなり独特のキャラクターなので、人を選ぶと思います。とくにビールといえばピルスナーという刷り込みが入っていると、こんなのビールじゃない！と思っちゃうかも。

たとえばドイツ度かベルギーとかで色々な味のビールを知っていると受け入れやすいかもしれません。

これも美味しいのでときどき買おうかと思うんですが、ちょっと高いことが多いんですよね・・・・

あと、甘さの分、糖質の量も結構多いです。これがちょっとネック。

国産ピルスナー系だと一番：キリン 零ICHI

【ノンアルコールビール】キリン 零ICHI ノンアルコール・ビールテイスト飲料 350ml×24本

グリーンズフリーを知るまではこれ一択でした。まさに国産ピルスナービール！ド定番！の味わいを目指した感じで、ノンアルだけど頑張ってると思います。

少し薄くなりますけど、下手な発泡酒とかと比べればずっとビールの味で美味しくいただけます。

薄味辛口系: バドワイザー ゼロ、アサヒ ドライゼロ

バドワイザー ゼロ Budweiser 缶 [ ノンアルコールビール 350ml × 24本 ]

【カロリーゼロ・糖質ゼロ】アサヒ ドライゼロ [ ノンアルコール [ 350ml×24本 ] ]

バドといい、スーパードライといい、薄味辛口ビールはノンアルコールしても違和感が薄くて済むようですね。本物のアルコール入りバド、スーパードライにかなり似た味です。バドやドライが大好きな方は、おいしくノンアル生活ができると思いますのでお勧めできる。

自分はあんまりバドとか好きじゃないので・・・・・

他は？

色々飲んだんですけど、私としてはちょっともう上記のビールに比べると飲む意義をうしなってしまいました・・・

好みは人それぞれだと思うので、ご参考まで。。。

QGIS: vector processingがうごかない！？

Windows上にQGISをインストールしていたのですが、ある日突然

ベクターのタブが動かなくなりました。

矩形つくったりいろいろ使うので困っていて、これで３日くらい溶かしたのですが・・・・

https://gis.stackexchange.com/questions/202111/missing-processing-tools-in-vector-menu-of-qgis

これが解決策でした。

自分の場合、

C:\Users\(user name)\AppData\Roaming\QGIS\QGIS3\profiles\default 

ディレクトリ内の"processing"ディレクトリを削除して、

QGIS再起動、その後プラグインの管理から"processing"をenableすると直りました。

泡を吹くような事態だと思うので、お困りの方は試してみてください

2024年の目標

2022, 2023と少しずつ行動の変容をともなう習慣付けができるようになってきました。引き続き、今年も良い行動を促進する習慣付けを頑張っていきたいと思います。

今年の大きな目標は、「より生産性の高い働き方を身に着ける」になるかと思います。２０２３年特に後半（そして今も）は公私ともに忙しくて、毎日２～４時間睡眠が当たり前になってしまいました。

当然ですが、パフォーマンスおちていくので、公私ともにツライ日々です。

これを改善したい。そのために、いくつものベストプラクティスを本などで読んできたので、習慣として身に着けたいですね。

睡眠時間・休息時間の確保。損して得取ることを腹落ちする

  - 深夜の作業はできるだけ控える。頭をつかう作業は特に意味がない（だいたいミスする）ので、計算jobの投入以上のことはしない方が良い

  - 昼寝の時間を「確保する」。

    - これも忙しさにかまけてすっ飛ばしてしまっているのですが、エッセンシャル思考にもあるように「休息時間は数倍の仕事時間の生産性を担保する」はずなので、午後の生産性を上げるために、損して得とる（これができないから長時間労働しちゃうんだな）ことを腹落ちして実践する

KPT・行動の評価と改善の取り組み、これを進化させる

日々の行動の良し悪しは、いま変容したい習慣付けのための評価。それだけではなく、長期ゴールに対する進捗を見ないと生産性に関する評価ができない。それができるようになりたい。そのために・・・

- 長期（四半期、半年、１年、３年ぐらい）のO/KRを明記する<==最重要

  -  仮目標でも良くて、修正が時々はいる（１月、四半期、半年、１年・・・）で入ってもいいと思う。それでも、明文化されて、その達成度を測るメトリックを立てておくこと。ここがずっとあやふやなのが良くない

- KPIをO/KRに基づいて設計して、記録する

生産性を高める仕事の仕方を身に着ける

- Prj/Roleごとに、いまの状況で、20%のwork hourで80%の価値をうむ単一タスクを一つだけ決めて、その実現に集中する <== 最重要

   - 大事なタスクが複数あって、それをリストして忘れないことは結構ですが、実際にこなせるのは、せいぜい1~3 MVP/日, ８～１０MVP/週というのが今年の計測結果だった。

- 書いてから、考えてから、行動の枠をつくって集中して実行する。いずれも、すぐ作業したくなるのを我慢できるように。我慢して、生産性が結果あがった、という成功体験を積み重ねるしかない・・・

  - デバッグ時には、原因の仮説を立てて、今のログがそれに沿っているかを見てから、仮説の成否を判定する修正を行う癖をつける

  - 論文・研究は、まず論文を書いてからその穴埋めをする

プレゼンテーション・報告資料の作成時に「枠」スライドをつくって埋めていく、というのはすっかり身についたので、本丸である論文・研究も（今年こそ）同じやりかたを身に着ける。

基礎的な生産性力を高めるための日々の時間投資＝勉強

- LeetCodeのような、プログラミング修行を行う

  -  ソフトウェアやってるので、エンジニアリング的にも、研究の実験検証の上でも、プログラミング基礎能力の向上はそのまま生産性に直結する。なので、多分これは割のいい投資のはず・・・

- 論文よみ。今のPrjに関する論文か、LLLM, やっぱりhallucinationに関する論文を趣味として。

  -  読み方も工夫する。家ならGPTのツールで概要翻訳させてからすっと読むともっと早く理解できる。

ちょっと盛りだくさん過ぎるかもしれないですが、どれも習慣化させることができれば大きな成長の礎になってくれるはず。

その結果として、IC、一人称のエンジニアとしての貢献に加えて、

マネージャ機能で不足している

- まだまだ予定、look aheadの見積もりが甘い

- 時々抜け漏れがある

- チーム/prjを進行させるための雑務を色々とってこなすために、マネージャしぐさもcontributorとしても中途半端にしかできてない

も改善できるのではないかと。

2023年の振り返り

2022年の振り返り

では

• 反省：もっと目標を明確に立てて、明記する

といって、それを受けた

2023年のゴール（仕事編） - Bag of ML Words (hatenablog.com)

では

• 論文を読んで、アウトプット（公開）する営みをします
• プロジェクトマネージャーの機能とマインドを実践してlearnしていきます

と書いていたのですが、それぞれの達成度を見てみると

• 反省：もっと目標を明確に立てて、明記する: 50点
• 論文を読んで、アウトプット（公開）する営みをします: 10点
• プロジェクトマネージャーの機能とマインドを実践してlearnしていきます: 60点

ってところですかね。

目標を明記して、それに対して勾配をとって修正していくという営みは、

紆余曲折がありながら短期目標に対しては機能して習慣づきました。

これは「

Amazon.co.jp: エッセンシャル思考 最少の時間で成果を最大にする eBook : グレッグ・マキューン, 高橋璃子: 本

」（これもいい本でした）で出てきた Minimum Valuable Progress (MVP)*1に従って、プロジェクトの進捗的に今週で達成したい成果をMVP最小単位に切り出して、それをひとつずつ実現する、という形で行動計画を立てています。

ただ、長期目標、OKRに対する進捗を刻んで評価するのがKPT[としてはベターなんですが、それができていない。

これはコーチとEMから指摘されているのですが、OKRというレベルになると「完璧主義」な欠点がまた頭をもたげてくる・・・

そういう長期のゴールが、まずは自分のためにだけでもしっかり立てられないとマネージャー志望としてはまずいだろ、という気持ちが生まれてしまうんですね。仮でもいいので立てればよかったのですが

論文読んで公開は普通に出来ませんでした。考えれば１年のほとんど、特に４月以降はずっとお世話しているプロジェクトで忙殺されていた気がする。

プロジェクトマネージャーとしての機能とマインドの実践は、それなりにやっていけたと思います。１年前に比べればずっとチームを見渡す視野は広がったし、２、３か月ごとに訪れるチェックポイントについて、少なくとも報告資料の枠をつくって、何を埋めればいいかは提示共有を率先してできるようになりました。

３か月や半年ごとに、「そろそろまずいだろう・・・」という感じが出るころに、チーム全体でゴールの再確認とタスクの再整理を行ってチームメンバの割り振りを話し合って、という会も、半分ぐらいは提唱できるようになりました。

ただ、不満点としては、

- まだまだ予定、look aheadの見積もりが甘い

- 時々抜け漏れがある

- チーム/prjを進行させるための雑務を色々とってこなすために、マネージャしぐさもcontributorとしても中途半端にしかできてない

あたりですね・・・・。

不満点が強いので、全然だめだなという気持ちが強い毎日ですが、公私て振り返ると１年前よりは成長はしていそうですね。良かった*2

今年はもっとそれぞれの仕事、タスクにフォーカスして、価値ある20%に取り組む割合を高めることを優先したいですね。それで３点目は生産性が上がるだろうし、生産性があがれば価値あるタスクを見極める目が改善されるから１番の精度もあがるし、２番の余裕も生まれるかな？

とりあえず年度内は「収穫」のための研究開発作業がもう目白押しなので、これもキーイシューだけをえらんでやっつけていかないといけないです。

エッセンシャル思考 最少の時間で成果を最大にする

*1:もちろんMinimum Viable Productのもじり

*2:問題は、周りの成長のほうが早くて相対的に埋没してそう

書評：「世界一流エンジニアの思考法」 主にソフトウェアエンジニア向けだが良書！

お久しぶりです。年末、今年一番じゃないか？という良書にであったのでご紹介です。

世界一流エンジニアの思考法 牛尾 剛 (著)

著者のかたはMSエヴァンジェリストとして成功しながら、MSのazure開発チーム（多分）にソフトウェアエンジニアとして参加します。周囲の同僚がおしなべてハイパフォーマーという不思議な環境の中で、どうやったら生き残れるようにパフォーマンスを上げられるかを試行錯誤した、その上澄みの経験を分析して共有してくれています。

世界一流エンジニアの思考法

全体的な感想

著者のかたの苦しい経験に基づく上澄みの話なので、基本的にソフトウェアエンジニアリング業務についてのお話になります。

周囲のエンジニア仲間が全員ハイパフォーマー（エースに頼り切るチームでない）という状況で、なぜ再現性のある形で圧倒的な生産性をあげられるのか、マインドセットの持ち方、チームメンバー内のコミュニケーション、生活習慣などについての経験と要点を説明してくれます。

日本と違って、ソフトウェアエンジニアから自然とマネージャーへあがるキャリアラダーはないので、マネージャーは完全に別職種です。また、ソフトウェア開発業務の以外の職種にはそのまま汎化できない部分もありますし、自分一人では変えられない職場環境あるいは文化に立脚する部分（どうしようもないね）もありますが、個人としては実感をもってうなずける内容が多かったです。

生産性のはなし

個人的に一番のtake home messageはここでした。個人的結論は「基礎・基本・王道を徹底して突き詰めることが高い生産性につながる」と捉えました。いくつかエピソードを書いておくと

2-8の法則、つまり一番価値のある２０％の稼働業務が、８０％の価値を持つという話があるが、ドリームチームの同僚たちはひたすらこの２０％の業務だけをやっている。

- ここに優先順位の付け方の違いがあると考えている。優先順位の高いタスクからやっつけましょう、というのは日本でも当然のように言われますが、そこでは上から順番にすべてのタスクに優先順位をつけて、できるだけたくさん上位のタスクをやっつけようとします

- 著者の同僚たちはそうではなく、一番重要なタスクだけにフォーカスします（重要20%)。それが終わったら、残りの優先タスクを埋めるのではなく、別タスク・再評価後の一番重要なタスク（２０％）を見定めて、そちらに移ります。完成させようとしない。

- 結果として、４０％の稼働で１６０％の価値を生み出せる。理論的には。

自分の場合、優先順位をつけて上からやっていく、というのは実践しているところではありますが、いつもタスクがあふれてやりきれないことが日常化してしまっていました。

また積み残しタスクは翌日に基本的に持ち越しするのですが、そこが思考停止していたことにも気づかされました。

2-8の法則はもうあらゆる本で述べられていて、自分も知識としては知っていますが、本当のハイパフォーマーがそれをどう行動に適用しているかの実例はショックが大きかったです。

もっとフォーカスして、「いちばん」だけに集中するようにしていかないといけないですね（でもタスクリストを減らすのは怖さがある、自然です）

手を動かす前に考える。考えるとは、仮説を立てること。仮説検証のために手を動かす。精度の良い仮説を高速に生成するための基礎の勉強がキモ

- バグ取りのエピソード。著者はログメッセージをみて、「あそこが悪いかな」「ここかな」と思いつくところから検証していきますが、検証の作業それぞれにも時間がかかる。一方エースの同僚は、ログを見てから原因の仮説をたてて、「この仮説が正しいならここはこう動いてこうなっているはずで・・・」という考察を続けます。いくつか仮説を検討後、チェックのためのクエリをひとつだけ投げて、見事に原因をみつけます

- また、同僚たちは著者なら見飛ばしてしまうような長いログも丹念によむし、コードも隅から隅まですっかり理解しています。そのため、立てる仮説の精度が高く、また高速で仮説の構築と検証ができます。これはさらに生産性をたかめるポイントになっています。

- これらのenablerは、誰でも通り一遍はしっているような基礎を徹底的に習得するコストを払って「理解」すること、です。だれもがハイパフォーマーということは、彼らすべての脳みその理解力が常人離れしている、ということではないことがポイントです。

 手を動かす前に考えよう、というのは、これもやはりあらゆることで言われます。が、バグをみつけると「あれかな」「これかな」となって時間ばっかりかかっているのが実情ですね・・・。

あれかな、これかなは仮説のタネになるはずで、あれかなこれかなの修正ソースを書く前に、「あれが間違ってるとすると、コードの他の部分ではこうなっているはずで・・・」という次のステップを考える癖をつけることが大事かな、と思いました。それがlogから検証できるのであれば良い、と。そして、その仮説を複数束ねて、一番キモとなりそうな部分から検証する。

また、ここの仮説の部分の精度を高めるための基礎の勉強も大事ですね。ただ、拾得すべき「基礎」をどう定義するか。プログラミングの１００本ノック、みたいなのは分かりやすいですが、たとえば研究職ではどうか（プログラミングが時間かかるのはその通りなので、１００本ノックも有効ではある）、マネージャー職ではどうか、となると、日々鍛えるべき基礎とは・・・？となってしまいます。

その他

スクラムベースのアジャイル開発環境ではそれぞれがオーナーシップをもって働く、fail fastで素早く修正していく、失敗したことを責めずに歓迎してそこから最大限学ぶカルチャーなどは、今の職場環境をさらに突き詰めた型を実践していて、いいなあと思います。

コードのまえにドキュメンテーション、というのも、研究の前にまず論文下書き、というイシュードリブン手法として知ってはいますが、やっぱり実践できてないですね。。。（だから研究者として３流に終わっている）

いきなり全部はできないし、今までトライしてできなかったことをまた同じやり方をしても出来ないままなので、まずは2-8の法則の部分だけでも取り込みたいと思います。

pyenv localで設定されたpythonを、どうしてもpoetryが使ってくれない時～

pyenv env infoを見ると、systemもvirtualenvもsystemの設定になってて、.python-versionで指定された奴を読んでくれないときですね・・・

pyenv env use pytnon3.10 

とかすると、systemもvirtualenvも書き換えられます。それもそれで違うんだけど・・・

Chrome key shorcut disabler

VS Codeをブラウザ経由で使うようになって、便利なんですが、chromeのキーボードショートカットとぶつかってしょうがない。

とくに、emacs keymapでkill ring regionの Ctrl-Wをコピペのためにつかうんですが、これがchromeのclose tabとぶつかる。

そこで下記が役立ちましたのでメモ

chrome.google.com