2024-01-12

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-01-08

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としても中途半端にしかできてない

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

2024-01-02

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%に取り組む割合を高めることを優先したいですね。それで３点目は生産性が上がるだろうし、生産性があがれば価値あるタスクを見極める目が改善されるから１番の精度もあがるし、２番の余裕も生まれるかな？

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

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

作者:グレッグ・マキューン
かんき出版

Amazon

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

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

2023-12-29

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

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

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

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

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

作者:牛尾剛
文藝春秋

Amazon

全体的な感想

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

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

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

生産性のはなし

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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