INTP型のブログ

苦味があるな？

頭の回転が速いを考える

note.com

 

知性を流動性知能と結晶性知能で二分して考えたときに、冒頭の記事は後者の知能によるレスポンスの速さを回答した言葉なんですよね

 

例えばですけど、小学生に上がりたて、事前学習ゼロ同士でも差が生まれるはず。

 

その事前学習ゼロ同士での差が流動性知能であって、一般的な頭の回転の速さはこっちを指すのではないかと思った話でした

 

ちな、基本的に出力みたいな部分で考えると結晶性知能 > 流動性知能であるとは考えていて、要は知識ゼロで頭の回転が速いみたいなヤツを用意しても、事前に答えを知ってるやつには勝てないという話です。

 

実際、年齢層が上になるほど幸福度とは結晶性知能の習熟度が相関すると言われていて、人生を豊かにするのは勉強だよねという話になる気がします。

 

よく巨人の肩の上みたいな話がありますが、流動性知能が外れ値で大きく人類を上回ったとしても、歴史の中で積み上がってきた形態的知識には勝てないという話なのかなと思います。

 

流動性知能の高い人間が輝くシーンは全員が結晶性知能の優位性を持たない瞬間だとも言えて、平時では考えられないトラブルとかの瞬間なんですよね。

 

事前に想定していないトラブルが発生したときになんかうまく切り抜けてしまうみたいなタイプこそ頭の回転が速いタイプだと思っていて、それは流動性知能が高いタイプなんだろうなと個人的には思ったりしました。

2024年4月の振り返り

前回: 2024年3月の振り返り - INTP型のブログ

 

出来事概要

  • 仕事忙しすぎワロタ
  • ちょっとだけbot開発進んだ
  • 仮想通貨ようやくプラ転した

 

仕事忙しすぎ

コンスタントに忙しいのできつい

 

プログラミングは好きな作業ではあるんだけど、やっぱスパゲッティコードを解読するのは苦痛なのでやりたくないなーとなってる。

 

アンチパターンを学ぶことで責務の分散というかオブジェクト指向だったり関数型プログラミングだったりの重要性に意識が向いたのはせめてもの救いな気がする

 

bot開発

多分ずっと言ってるような気がするけど延々と完成しない。to be continue..みたいな状態が数ヶ月単位で続いてる気がする。

 

ちまちまと必要なものができたりはしていて進んで入るんだけど、メインロジックが未だ未着手なのでなんとも言えない。

 

進捗具合でいうと体感30%ぐらいな気がする。休みくれ

 

ようやくプラ転した

年始にがっつり損失した分をようやく取り戻してプラスになった。

 

あと仮想通貨の仕組み上ドルに変えてるのでドル高で増えてるような気もする。

 

ただドル高、ガジェット周りの高騰にもつながっているような気がしており、税金かかるくせに体感の損益はプラマイゼロぐらいなのでは？と机上論だけど思ったりするのでなんとも言えない気持ちがある

 

てかいい加減160あたりを天井に落ち着くんだろうか、150のときもそう思ったような気がするし、全然わからん

 

本を読んだりしてた

最近は正直読んでないけど一時期読んでた。

 

読んでみて思ったのは読むと文章が書けるということ。読まないと全然かけない

 

不思議なもので書き続けていても読まなくなるととたんにかけなくなっていく感覚がある。

 

単純に読む場合に触れる文字数と、書く場合に触れる文字数で差が大きくあるからではと思ったりした。（書くときに資料用意するなど、ちゃんとやるなら別かもしれない）

 

少なくとも自分の場合は文章を書きたいならなんかしら本を読めば良さそうなことがわかった

 

マチアプやめた

ある日唐突に（しょうもな）と思って連絡してた人も何人か居たのだけどぷっつり終わらせた。

 

結局根本的に人間があまり好きじゃないので相手に興味が持てず、うまく関係が構築できなかったように思う

 

自分に問題があるし、このまま続けたところで精神的にも肉体的にも金銭的にも消耗するだけだなと思ってやめた。

 

ちなみに同時期に始めた友人は一ヶ月程度で恋人を作って最近ディズニーデートに行ってきたらしいので、やっぱ俺が悪いよなーと思ったりした。現状あんまり改める気ないけど

 

---

 

年始に目標として人間関係頑張ろうというのを掲げてたりしたのだけど、向いてなかったかもなぁと思ったりした。あと、単純に一足飛びで自分のキャパ以上の人間関係を作ろうとしたのも問題があったかもしれない

 

少なくとも当面、休みの日はのんびりしつつbot開発に専念したいなと思った。

 

今の働き方を続けてもスケールしないので、プログラミングという優位性を使ってスケールすることを模索したい

 

手段が目的化していそうに見えそうだけど、KPIとしてoutput / inputという指針を立てたので、outputを改善するかinputを削減するかで考えたとき、プログラミングでinputを削減する方針のほうが性格的にも効率的にもあってると考えた

 

KPI改善としてもoutputを青天井に上げていくというのはそれなりにinput量も必要になってきて、KPI自体はそこまで大幅な改善を見せないと感じた。inputの最小化はinputを時間や労力、金銭などのリソースと考えたときに0に極限まで近づけるのはプログラミングを用いれば可能と考えた。

 

上記が達成できればKPIは大きく改善すると言えるので、KPIの設計自体が間違っているということでなければ、この方針で金銭や時間の最大化ができると思う

 

とりあえずbotのアイデア自体は完成にこぎつけさえすればプラスリターンが出ると思っているし、APR100%以上は（キャパは少額になるだろうけど）固い気がしているので、休日の予定も開けられるようになるし5月中完成を今度こそ目指したい

このコードどうやって直すか考えてた

 

それぞれが独立した条件だから単純にどう階層にifを並べればええやんと思ったけど、画像の書き方だと早期リターンで処理高速化が達成できてると考えると、それぞれのifの中にreturnを入れていく感じになるのかなと思った

 

寝れなさ過ぎてよくわからんことを考えてた、明日は出社、おわったぜ

 

 

これとかとりあえず直すならこういう形になるよって感じでわかるなとなった。

 

ただ今度はここまで書かれるとマジックナンバーがどうだとか、関数に切り出せばよくね？とかそういう気持ちが湧いてくるので困る。あともとがゲームのことを考えると早期リターンの仕様がなくなるのはよくないのでは？と思った

 

めっちゃツイートの引用みてたらcaseでよくない？とかelse if..とか書いてあってひょえーとなった。breakなしcaseとかより一層カオスを生むだろと思うし、else ifはそもそも前提のソースコードの要件をちゃんと満たせないでしょという。多分条件的に >= 1がほぼ格で発生するわけで、そこで抜け続けるだけやん

 

早期リターンの要件を満たそうとするときれいに書くのむずいんだよなこのコード。引用見てると底ガン無視でif並べればいいとしているやつが多いの腹立つな

 

---

 

ここまでかいて気づいたけど、new Vector3のところはあかんか。new10回呼ぶのはさすがに無駄すぎる

 

unlockの書き換えとnew vector3をしつつ、早期リターンもかなえるとなると、単純にunlockとvector3と早期リターン用のboolを返す関数を作るとかがシンプルかなぁ

 

 

この人はちゃんとわかってる人で気持ちいい。

 

プロフにFactorio好きと書いてあったのでやはりFactorio好きは優秀なエンジニアの素質あるんだよな。Factorio採用をしよう。Factorioプレイ時間が長い人優遇！履歴書にFactorioのプレイ時間を証明するスクショを添付してください的な

 

 

アジャイル + スクラム + カンバン

スクラムがすでにアジャイルを指しているというのはさておき、これ考える。連投してすまん。

 

冷静に考えたら

 

  1. WIP
  2. 進捗状態
  3. ポイント（報酬）

 

を一つのポイントで評価するのは悪手では？となった

 

WIPについては普通にチーム内の人数分をキャパにするのが一番丸い気がした。難易度観点にしたとき、例えばチーム3人いるのに、ポイント上限に達して2issueしか引き取れなかったとなったら、一人何すんねん。となるのではと思ったので

 

着手中タスク = 人数の状態を保っていればいい気がした。

 

進捗状態については、複雑さだけを観点にしたほうがいい気がした。優先度が高くて複雑さが低いものと、優先度が低くて複雑さが高いものを同等ぐらいのポイントに設定してしまうと進捗状態が嘘になる。

 

0~100までの進捗状態は時間をベースに評価するべきで、タスクの時間見積もりは開発者のスキルとタスクの複雑さの2観点でしかないはずなので。

 

ポイント（報酬）についてはそのまま進捗状況と相関させるでいい気がした。

 

成果をoutput / inputとして評価する場合、質は開発者のスキル次第だったりプロジェクトの最初の設計次第になる。inputに入る時間を削ることでoutput / input = KPIとしたときにKPIを改善することができるので、じゃあ進捗を進めた分だけ評価が正しいよねという。

 

ただそれだと優先度が高いissueをやるインセンティブがないんだよなぁ。。。

 

タスクの複雑さ + 優先度とした場合、前述したとおり

 

  • タスクの複雑さ低, 優先度高
  • タスクの複雑さ高,優先度低

 

が価値的に釣り合ってしまう。

 

優先度が進捗状況と関係性が深いか？というのを考えたとき主観的には低いと思うから、そこを進捗状況の評価に使いたくない。

 

となるとやっぱり進捗状況はタスクの複雑さだけで評価して、報酬ポイントに関してはさらにそこに優先度をかける形で算出する。みたいにすればいいのかなーと思った。

 

つまりこうなる

 

  1. WIP: チームの人数 = タスク数になるよう制限
  2. 進捗状況: タスクの複雑さをもとにストーリーポイントを見積り、それをもとに算出
  3. 報酬: ストーリーポイント  * 優先度

 

---

 

まあ問題はgithub projectsの機能で個人にポイント割り当てする仕組みはないからissueに報酬フィールド用意して開発者とレビュアーにポイント割り当て。それを別途集計する必要があるという点すかね

 

github actionsとissueのカスタムフィールドを使えば多分できる。PRマージした人間を開発者、承認した人間をレビュアーとして、承認とマージをトリガーになんかしらのDBにポイントと開発者を突っ込んでいけば後で集計自体はできる。と思った

ソフトウェア開発によるissueのポイント化観点

ギルド式開発の続き

 

要はissueの難易度見積もりなんだけど考えるとむずすぎワロタ。

 

そもそもウォーターフォール開発ではなくアジャイル開発がいいよねという話の根元には「やってみなくちゃわからない」が少なからずあるという話で、issueの見積もりはあくまで見積もりになっちゃうよなぁという

 

まあでもissueをいい感じにポイント化できたらいい感じにゲーミフィングができて面白そうなので観点洗い出しをざっくりやりたい

 

※ちなみに調べた感じgithub projectsを使ってstory pointでポイント付けするのがいい感じ。そうすることで残ストーリーポイントから進捗状況を可視化できたり、良いことが増えそう

 

タスクの複雑さ

複雑さをどう評価するかだけど、

の2観点かなと思った。複雑なアルゴリズムは例えばDEXアビトラでいかにして最速検知 + 最速txを達成するかみたいなやつ

 

知っている人の少ない技術は例えばだけどAPI作ったことない集団だったら、Hello Worldを返すAPIを作るだけでもそこそこ大変だよねという話。

 

不確実性

  • 外部APIや外部システムが関わってくる

あたり、内部仕様が不透明なほどよくわからないエラーに引っかかったりするので。

またテストコード実装も面倒になってくる。外部APIかかわってくるところのテストのためにmockを作りたいけど、ドキュメントがあてにならねぇ！みたいになると面倒だよねという

 

他issueへの依存度

Aissueがあったとして、そのissueを解決しないと他issueが進まない。というケースはポイント高めたほうがいいと思った。

 

AissueをクリアするためにはB,C,Dissueの解決が必要。というケースでAissueをあげるかについてはB,C,D側が一つ目の考えでポイント上昇しているので別にいいかなと思った。

 

ポイントを報酬として考えたら、優先度を上げるときもポイントを増やす形で対応できるわけで、そしたら前者パターンがいいのか。

 

issueに観点ごとのポイントを書いておけば、「難易度低いけど優先的に解決してほしいタスクでお得やん！」となって引き取ってもらえるかも

 

優先度

 

依存度の話と大体同じ気がする。

 

---

 

考えてて思ったけど、ポイントと進捗度が紐つく形になるとポイントの美味しいタスクが優先的に処理される -> ポイントがおいしくないタスクが後々処理されるになって、進捗がスプリント後半になるほど鈍化するのでは？

 

まあでも後で高速化するよりはそのほうがいいのかもしれない。ポイントがそのスプリントに対して占める重要度やウェイトを示すようにしておけば、まあ別に問題ないような気もするし。

 

いやー考えてたらテンション上がってきた。

 

ちょうどよく開発中のbot、構造気に食わなくて作り直してたので、オレオレ開発やろうかな。github projectsで。一人でやることにはなるけど、とりあえずやってみてどんな感覚になるのか試してみる

 

チーム単位じゃないからポイントがあんまり意味ないような気がするけど、進捗状況を確認できるのは単純にモチベーション理論的に素晴らしいものだし、ロードマップ作製 -> スプリント分割自体はやってみれるし。

 

土日の楽しみができたぜ

ギルド式開発

妄想してた。

 

アジャイル開発の手法としてスクラム、カンバンというのがある。

 

スクラムはスプリント（アジャイル開発の一単位）ごとにPDCA回していくやり方みたいなのを体系化したやつという認識。（mtgによる毎日の簡単な状態確認もある）

 

1スプリントは2~4週間程度で、いったん全体のプロジェクト完遂までをロードマップとして定義。それを複数のスプリントに分割して、1スプリントずつ進めていくイメージ

 

ウォータフォールと違って、スプリンドのフィードバックのタイミングで手戻りが必要なら後ろのスプリント期間を調整したりして、手戻り用のスプリントを差し込むとかもできる（期限ぎりぎりのタイミングになるほど難しくなりそうではある）

 

カンバンはこのアジャイル開発の作業の可視化と効率化を目指したものという認識で、大体こんな感じでタスクを分類

 

  1. ToDo: とりあえず現在上がっているタスク全て
  2. Doing: 着手できる状態になったタスク（今のスプリントで着手する想定のタスクとか？）
  3. In Progress: 着手中
  4. Review: 着手されたタスクがレビュー中
  5. Testing: タスクがレビューを通り、リリースされ想定通り動くか確認中
  6. Done: タスクが完了

 

これをカンバンボードと呼ばれるもので視覚的に管理するイメージ

 

※看板はアジャイルの1スプリントに限定されず、全体の作業状態の確認でしかないっぽい。状態設定自体は大体今あげたやつぐらいだとは思う。Doingにするタイミングは優先度とか作業の進捗状態から触れるようになったタイミングでとかなのかな？そういう意味ではスプリント単位もあながち間違いではないのではと個人的には思うけど、厳密な定義的にはアジャイルにカンバン手法は限られるわけではないっぽいので違うかもしれない

 

ユニークだなと思ったのがWIPとプルシステムみたいなやつ。

 

WIPは各チームのタスク容量みたいなやつで、Doingに置かれるタスクは最大でも3つ。みたいにタスク数を制限するみたいなやつ。ただこれ決めたら「じゃあタスク進めなければいいのでは？」と思ったりしそうなんだけど、その辺はうまく監視すんのかな

 

プルシステムはWIPを前提としたもので、要は抱えているタスク数が3から2になったら3になるようにタスクが引き込まれる。みたいな仕組みを指してるっぽい。

 

あとはin progressのものが完了したら担当者は状態をreviewにして、レビューできる人は状態がreviewのものをキャパに応じて引き取る。といったもの

 

---

 

凄い完成されたシステムだと思ったのでここからさらに妄想。

 

ゲーミフィング、要はよりゲームっぽくして報酬機能を刺激する仕組みにしたいというところで考えたのがギルド式開発。

 

前提として

 

  1. アジャイル開発
  2. スクラム
  3. カンバン

 

の仕組みを採用する。ロードマップをざっくり作って、それを2~4週間のスプリントに分割。そのスプリントの進め方はスクラムのフレームワーク通り

 

タスクの進捗管理もカンバンを使う。ToDoにはタスクが発生した時点で難易度、優先度あたりを決めてissueを作成。みたいに大体カンバンと同じ仕組みでスプリントを進めていく。

 

Doingに落とすのはスプリント単位で実行予定のissue。で、それを各チームもしくは開発者が引き取る（プルする）。極端なブラック化を避けるためにWIPを設定しておく

 

ほぼアジャイル + スクラム + カンバン通りなのだけど、ここにさらにポイント管理を付け加えたいというのがギルド式開発の考え。

 

ファンタジーものでよくあるギルドのようにissue単位に報酬が存在していて、その報酬をもとに開発者はissueを引き取ることができる。ポイントは金銭や評価、ランキングなどの報酬機能を刺激する何かに結び付ける。みたいなイメージ

 

まあこれの問題は営業とかでよくある問題と同じで、評価制にすることでチーム内やチーム間、個人間の軋轢を生むし、ノウハウの共有が避けられる可能性があるという点。

 

書いといてなんだけど、ギルド式開発で運用したいポイントはそのままカンバンのWIPのポイントとして使えるようにできるし、そこを頑張るほうが健全なのでは？となったりした

 

アジャイル + スクラム + カンバンまでは導入しているところはしているだろうし、ここに評価軸を置くなんてことは誰もが思いつくことだろうけど、調べた限り明確にやってる人の話は目にしなかったのでリスクがあまりにも大きいと思う人が大半なんだろうなと思った。俺もそう思う

 

まあでもゲーミフィングが有効であるのは確かだし、最下位が見えないようなランキングはいいんじゃないかなと思ったりした。ランキングの悪い点は自身の劣等感を感じる人間が出るというところなので

 

桜井さんがスマブラ作るときにランキングを世界戦闘力という形にしたのもその対策のためという話だったし。ポイント制 + 上位のみランキング化。というのがギルド式開発の落としどころかもしれん

 

---

 

余談だけどアジャイル + スクラム + カンバンの方式見ててめっちゃ美しいなと思った。ソフトウェア開発は特にハードウェア開発と違って手戻りは比較的しやすいわけだけし、アジャイルと相性いいよなとか。

 

スクラムのPDCA的やり方は無難に強そうだよなとか

 

特にカンバンの視覚化やWIP・プルシステムによるキャパオーバーを避けたりする仕組みはマジでいいなと思った。カンバンボードとかだれが使うねんってちょっと思ってたんだけど、認識変わったわ。プッシュ的な思想でとらえてたから使いづらそーと思ったけど、プル的な思想でカンバンを見るとめっちゃいいね確かに

 

WIPの点数化をいかにうまくやるかはゲームでいうレベルデザインのところになってくると思うので、ここがキモなんだろうなという気もする。

 

めっちゃ俺の考えた最強のプロジェクト進行やりてーと思った次第でした。おわり

PC周りの最適な環境について考えてた

どうにも色々作業をしていると不便さというかストレスを感じるシーンが多いように思っており、その原因について考えてた。

 

結論から言えばおそらくこれは配線で給電やサブディスプレイとのHDML接続など、優先マウスなどにストレスを感じているように感じた。

 

（考えてみると、大量のA4用紙の紙束なんかを見ると無性に全部丸めて捨てたくなったりするし、ごちゃごちゃした環境にストレスを感じる性格なのかもしれない。）

 

そこでサブディスプレイは安価なandroidタブレットを購入し、spacedeskというアプリで無線接続することにした。マウスもワイヤレスマウスを導入した。

 

無線に変更するとラグ関係の問題が出てくるが、入力する際のUIはノートPC側。参考資料などはサブディスプレイ側にすればそこまで問題が出ないと考えた。

 

懸念点としてはウェブアプリ開発時にサブモニタ側でそれを確認するケースだが、まあ問題ないだろということで目をつむることにした（まだ考えている最中でこれ書いてるので試してない）

 

これでゼロ配線で作業できるような環境を作れたが、問題になるのは充電。

 

日常的に作業をしていて長時間に及ぶ作業の場合ノートPCの充電が切れることが多いように感じた。

 

そうなると結局永続的に給電するために電源と接続する必要が出てくるため配線問題がクリアできなくなる。

 

そこで二つの解決策を考えた。

 

  1. 2in1の小さな電源を用意し、そこからそれぞれに給電する
  2. モバイルバッテリーを二つ用意し、そこからそれぞれに給電する

 

個人的には2かなと思った。

 

結局配線のストレスは、電源とデバイスの距離に比例して大きくなると考えたので、その距離を短くするためには電源を持ち運び可能なものにするしかないという考え。

 

2in1のモバイルバッテリーを一つ用意して、そこからそれぞれに給電するというのも考えたが、それをすると結局二つのデバイスはモバイルバッテリーを通じて接続されているような状態になり、ストレスのもとになるような気がした。

 

であればデバイスごとにモバイルバッテリーを用意しそこから給電。デバイスを使って無いときにモバイルバッテリー二つを充電する。という形を作れればストレス軽減ができるのではという考え。

 

うまくいくかわからないけど、実際何を使うかは調べる予定。

 

---

 

ちょっと調べた。

今使ってるpcのusbc給電には最低でも40w必要らしい。

 

anker nano power bankとかよさげだなと思ったのだけど、これだと出力足りない。

 

出力を満たしつつってなると結構大変かも。あと意味不明だけどusbc給電すると処理が遅くなって、タイピング速度に表示が追いつかなくなる。充電問題だけはうまく解決できなさそうだなぁ。。という次第でした