好きな展開発表ドラゴン
🐉< 「主人公だけが気づいている」という事実が暗に視聴者に伝わるところ
『COSMOS』はいいぞぉということだ！
4/8 健やかに睡眠
やったことが少なすぎて、書くことが無い。
仕事
今日の仕事は、実装とチャットでの調整、あとはレビュー対応など
出社だと集中力は確かに増すのだが、代わりに周りの会話を聞き取ってしまい集中が散漫になることもしばしば。
雨が降っていたのもあって、今日のリモートワークは楽しく捗ることこの上ない。
集中したいけど中々進めることのできなかったタスクが一つ終わり、別部署で作業依頼を出さなければいけないことが分かった。一回休み。
昼は食べながら結局検証などを進めてしまったので、貴重な昼寝時間が取れず。
退勤後、流れるように布団へ飛び込んで、気づいたら朝の7時だった。よく寝たね。
ごはん
朝食：バナナ
昼食：レトルト麻婆豆腐
夕食：寝落ちした
4/9 もやもやもや
睡眠時間12時間
仕事
流石に12時間寝たら気分が爽快だ。いつもならリモートワーク開始時間ぎりぎりの起床なのに、今日は買い出しに出てシャワーを浴びてラジオ体操する余裕すらある。
いつもは目に沁みる眩しい太陽が、今日は心地良い。毎日こんな気分でいたい。あとそろそろタオルを積み上げただけの枕を卒業したい。
よく寝ると、面倒なタスクに対する向き合い方も違う。面倒くさいなぁ…と思う部分も、理性が「早くやるぞ」と急かしてくれるため、何とか乗り切れる。
よく寝ると、人にも寛容になる。小さな検証作業に申請が必要なことにも耐えられ…るわけない！ なんでこんなことまで大手企業のように全て申請しなければいけないんだよ～！ 適当加減によるスピードの早さが中小のいいところだろぉ！！*1
深呼吸とおやつでモヤモヤが取れるかと思ったが、そんなことは無理だった。
これが2025年までなら、私の実装を進めている間に依頼をしておくか～という速度感だったのだが、AIで検証コードの実装が早くなった今は、設定依頼による待ち時間がとてももどかしい。私がせっかちだから、余計にモヤモヤが増しているというのもある。
今年になってから何度考えたか分からないキャリア選択の話がまたも頭をよぎる。ちょっとぐらい真面目に再検討してもいいかもしれないなぁ。「GTMエンジニア」という面白そうな職種の話が出てきているみたいだし。
うちの会社には一つ良いなと思っているルールがある。それは「新卒1年目の出す日報は、全社員が見られるチャンネルに投稿すること」である。
個人差はあるが、日報はその日のスケジュール、学びと気づき、一言欄で構成され、読んだ社員たちがリアクションや返信を付けていく。
先日も、かなりネガティブな自虐一言を書いた子がいたのだが、
「卑下した内容を（思っていても）書く必要はありません。読む人も困惑するので、三方良しの考え方をもって情報を伝えるといいでしょう。」
というアドバイスが即日中に返されていた。なんて優しい先輩と、優しさで成り立っているシステムか。
「この子大丈夫かなぁ…」とそっと距離を遠ざけそうになった私はちょっと反省した。
しかし、ここは（適度に配慮した）日記だ。知らん！
モヤモヤした日だった。
雑務
よく寝て頭がすっきりしているので、退勤後も全く眠くならない。
更新期限が近づいてきたインターネットプロバイダの更新や、SKIMAで依頼した内容の返信、読みたかったキャリア系記事の内容をルーズリーフにまとめるなどしていた。
-
“先延ばし癖”の原因に新知見──「目標設定能力の欠如」のせいではない？ 英国チームが研究発表：Innovative Tech - ITmedia NEWS
- 先延ばしはよくしがちだが、そんなに成功確率を低く見積もっているつもりはないんだけどなぁ？
- そもそも、その前段階として「目標に向けた行動」を具体化したり、目標によって得られる姿を想像できていないから、動けないのかもしれない。
-
制約を読まないエンジニアへ - 弁護士ドットコム株式会社 Creators’ blog
- 凄く意訳をすると「Howだけに着目したらうまくいかないこともあるよ」という内容だった。プロジェクトの立ち上げ者が途中でいなくなって引力がなくなることを「責任の蒸発」と表すのは言い得て妙だなぁと。
- 実績は土台を作って意思決定で積み上がる - AI時代に崩れないキャリアの築き方 - そーだいなるらくがき帳
- 上で「制約」と言い表している段階について、よく理解出来る話。全く別の経路で知ったが、組み合わせてすごく腑に落ちた。
- 意思決定のサイクルがキャリアの行き先を決めるのであれば、大きな仕事をするサイクルを増やすか、高速でサイクルを増やせる仕事を選ぶことが今は肝要な気がするな。
ごはん
朝食：フルグラ
昼食：麻婆豆腐
夕食：ヨーグルト2つ
余談：最近のタスク管理ツールの話
先月に、ふとやる気が燃え上がって作り始めたタスク管理ツール。
コードを100% Made in Geminiで書いたらどうなるのだろうかという検証も兼ねて遊び始めたのだが、1か月も経つと面白いことになってきた。
私の変化
- 機能を消すことにためらいが無くなる。
- 毎日使うから、毎日欲しい機能が出てくる。
Geminiの変化
- 必要なコードを削除することが増えた。
- UIが壊れやすくなった。
私の変化
機能を消すことにためらいが無くなる
Webアプリを日頃運用していると、追加の開発案件が飛んでくることは日常茶飯事だが、機能を消す依頼が飛んでくることはほぼない。
それにはいろいろな理由があると思う。
・ステークホルダーが多く、調整が大変
・数%でも使っている人がいるから
・消すためにも影響調査が必要になり、何も生まない作業が増えるから
と言ったところだろうか。どれも頷けるし、せっかく作った機能を「効果が見込めないので消してください。」と3日後に言われたら、ストの一つでも起こしたくなると思う。
でも、それが個人ツール×AI開発ならまったく気にしない！
・ステークホルダー、私
・消すための影響調査、AIがなんとかする
・実装者はAIだし、利用者の私が不要なので、消すことが全く悲しくない
というわけで、日頃使わない引き算思考の鉈を、個人ツールでは思う存分振るうことができる。これで軽量化！ メンテ範囲が減るぞぉ、素晴らしい！
「ガントチャートの方が見やすいな？」と気づいた
これが今すぐ仕事に活きたわけでは無いのだが、「これって本当にいる？」という仮説の思考は組みやすくなった気がするし、個人ツールならとりあえず作って感触を実際に確かめてみるという検証をすればいいと分かった。
日頃、担当サイトで丁寧にレビューとCI/CDを回していると感じにくい感覚であるため、開発者にはぜひ味わってほしい。
毎日使うから、毎日欲しい機能が出てくる
「俺が考えた最強のプロジェクト管理ツールが欲しいなぁ」と願い、機能リストを挙げたことは何度かあったが、作ることまでには辿りついていなかった。他のツールを触った感じ、たぶんこういう機能が欲しいんだろうな～ 程度の考え。結局似たようなモノが出来ると思っているから、動く気も起きない。
それが、1か月毎日使い、「ここ不便だな、ちょっと直して」とGeminiに依頼をしていると、どんどんツールが進化していく。
最初はただのガントチャート管理ツールだったのだが、今は
- 今日のタスク一覧ダッシュボード。集中したい1つのタスクピン止め機能と、ポモドーロタイマーの停止・開始の管理ができる。
- Obsidian連携機能。
- 特定リンクをクリックしてObsidianからのタスク登録と、管理ツールでタスク完了した時にデイリーノートに自動書き込み。
- メモ欄にObsidianリンクを張ると、飛ぶボタンが現れる。
- マスコット機能
- クリックしたり、時間経過だったり、タスクを完了したりすると、性格付けしたマスコットが喋ってくれる。
- 拗らせたオタクしか喜ばないであろう機能だが、だからこそ欲しかった。
なんてものが追加されている。
ちなみに、上記全機能はキーボードのショートカットで操作可能だ*2。
かわいいこのキャラは、SKIMAのopt販売・キャラ販売（Adopt）で購入した一点モノだ。
始める前には想像もしていなかった機能であり、作って触り続けたからこそ私の譲れない「エゴ」が出てきたとも言える。
「当たるか考えるよりも、市場に出せ」と言われる要因の一つはこれだろう。自分の頭でこねくり回しているよりも、実際に作って触ってもらうと具体的なアイデア・欲・”エゴ”が出てくる。
個人用ツールなので、思ったときに機能追加して、確かめてみる。楽しい自作（？）ツールが出来て、とても満足している。
唯一今悩んでいるのは、全体的なデザイン。最初は、「一般受けするシンプルなもので」と依頼して作ってもらったのだが、今は面白みがないデザインだなと毎日感じている。デザインの引き出しが無く、方針設計も出来ない身なのがもどかしい。
AI時代に単独でシステム設計するなら、やっぱりデザイナーが覇者になるんじゃないかなという仮説も、確信が強まった。
Geminiの変化
そろそろ書くのがめんどくさくなってきたが、こっちの話も。
必要なコードを削除することが増えた。
UIが壊れやすくなった。
どちらも同じ話である。要するに、「AIエージェントが覚えていられる限界を迎えてきた」ということだろう。
計ったことは無いが、もうコードの数は1万行を超えているだろう。数時間単位で機能追加を繰り返しているため、1日の最後にはリファクタリングをさせているのだが、そこでうっかりコードを消していく。
単体テストで検知できる範囲ならまだいいが、UI側は実際に立ち上げないと分からない変化も多く、たまに使う機能がいつの間にか動かなくなっていることも。
対策としては、
- mainブランチ1本体制を止めて、機能開発ごとにブランチを切る。マージ時にCopilotでセカンドオピニオンレビューをする。
- E2Eテストを作って、フロントのUI崩れ検知をもっと早くできるようにする。
があるかなと考えている。
ただ、どちらもAI開発の速度を遅くさせることに変わりなく、未だに手を付けられずにいる。これが個人プロジェクトじゃなくなった時には入るのかなぁ。
フロントが壊れないための単体テスト…というか、関数・クラスの存在チェックテストをAI開発のために増やした話が流れてこないかと毎日ウォッチしているが、残念ながら見つからず。よそはどうやって検証しているのだろうか。
