パルカワ2

最近はFlutterをやっています

面白く働く

人生において、働く時間というのはかなりの時間を占めていて、どうせ時間使うなら面白く働いた方がお得だと思う。 特に自分の場合、気ままに生きてたら趣味が仕事になり偶然にも面白いと感じることをやってお金をもらえているボーナスタイムという感じなので面白くないならあんまやる意味ないと思ってる。 仕事なので、やりたくないことや面白くないことは一切やらないわけではないが、なるべくやらないでいいように頑張る。(それもまた面白だね)

面白く感じることはその時々で変わっていく。Perlを書くことが一番面白い時もあったし、チームのことを考えることが一番面白い時もあった。その時々で一番に面白いと感じるテーマに沿って活動してるときに面白く働いていると思う。

このテーマは目標とは違っていて、具体的になにかを成し遂げたいみたいなものがない。テーマから具体的な目標が生まれることはあるが、何かを成し遂げられなかったとしてもそのテーマと向き合っていたこと自体に価値がある。（少なくとも自分の人生においては）

テーマの設定は、直近で具体的に何が面白いと思ったかを複数あげて、それぞれ面白さを感じる部分はどこか探して共通項を探していく。

他にも人にこういうことをやってるんですよね〜自分はこう感じてて〜と話すことで言語化されてテーマとして持てる時がある。 1 on 1で最近何をやっているのか話すのは、進捗確認のためではなく、何を面白いと思ってるかとか逆に何を面白いと思えないかを話してテーマを言語化していくためだと自分は思っている。

個人が持つテーマが会社が求めることと合うのが一番いいと思うが、合わないこともある。そうなるとテーマに沿った活動が出来るように会社を説得する、自分のテーマを変える、テーマに沿った活動が出来る会社にいくがあり、自分は最近エンジニアリングマネージャーをやめたタイミングでテーマを変えたりした。

テーマを変えることは悪いことではなく、むしろ気軽に変えていいと思う。このテーマしかやりません！と決めてしまうともっと面白いことに気づきにくくなるので、気軽に変えて違うかったら戻せば良い。

面白く働いていきたいですね

Pebble Time 2を買った

repebble.com

配送するためにはメールに反応する必要があってそれに気づいてなくて遅くなった。結構良い。バンドはかぶれたので変えたけど最高！とまでは思ってないので良い感じのものを探したい。

睡眠を記録出来るようになった。前はiPhoneだけで取れてたのに取れなくなって悲しんでいた。

新しいPebbleを作っているところとRebbleが揉めたりしていて緊張感があったがOSS化して大体解決した模様。

最近の開発 2026-08

前回 最近の開発 - パルカワ2

大枠は変わらないが、ちょっと変わってきたので書く。

  • brainstorming スキルで考えていることを書き出してから進めている
    • grilling スキルと一緒に使うと質問がいい感じになるような気がしているが、気のせいかもしれない
  • 生成されるspecは https://crit.md/ を使ってレビューしている。
    • わからないことや見た感じ微妙だなと思ったところに代替案がないか聞いたりして、良さそうなら対応してもらうという感じ。やり取りは、Round 15くらいまで行くこともあるが、最近はFable 5, Opus 5のおかげか減ってきた
  • specが良さそうなら次に writing-plans スキルで plan を作成してもらい、同じように https://crit.md/ を使ってレビューしている。
    • planを頑張っても実際コードを書き始めると違ったということがあるが、最近はFable 5やOpus 5であればムムッとなることを言わなくなった感じがある
    • あとは、Claude Codeがリポジトリ内のドキュメントを参照してるというのもありそう
  • specとplanが終わったら、コンテキストが50%くらいになっていることもあるので一旦clearして進めたい。handoff スキルを使って引き継ぎ資料を作る
    • 本来handoffスキルで作成する引き継ぎ資料はtmpディレクトリに作成されるが、最近は plan.md, spec.md と同じ場所に置くようにCLAUDE.local.mdに記載している。（後述）
  • clear したあとに handoff.md を読み込ませて実装に進ませる。
    • 実装中は、並列で小さめのタスクのplan, specを作成したりしている。小さめのタスクもplan, specが終わったら using-git-worktrees スキルで作業環境を分けて実装している
  • 実装が終わったら、https://crit.md/ を使ってレビューする
  • crit上で自分のレビューが終わったら、create-pr スキルでDraftの状態+Copilotへのレビューアサインが済んだ状態でプルリクエストが作成される
    • AIが生成したものを人に見せる場合は、自分がすべてを見るぞという気持ちでいるので、自動でオープンにしない
    • オープンするとレビュアーがアサインされて通知がいって目に入るので。
    • Copilot のレビューは、Draftで出来るしレビューの日本語が壁みたいにならないので採用したが、最近レビューで助かることはほぼなくfalse positiveなことをよく言ってくるので使うのをやめようか悩んでいる
  • プルリクエストを作成したら改めて自分でタイトルとdescriptionと変更をレビューする。Copilotのレビューはrespond-to-reviewスキルで対応を検討してもらう
    • レビューの対応は検討はしてもらうが判断までは任せておらず、最終的には人間がヨシと言わないと進まないようにはなっている
    • 変更も見る。GithubのUIで改めて見て見逃しがないか見直す。
  • その他、動作確認含めて「すべてヨシ！」となったらプルリクエストをオープンしてレビューお願いしますと言う

上記のように基本的に既存のスキルを利用していて、既存スキルについてこうしたいなと思ったことは CLAUDE.local.md に書いている。

例えば、自分の頭の中にあるものを実装する気はないがとりあえずspecを先んじて書くとかよくやるんですが、superpowersのディレクトリ構成だとspecとplanの関係がわからなくなったりするので、issuesとしてまとめていて結構気に入っている。現状issuesはリポジトリにコミットはしていないけどコミットしようかなの方向に気持ちが傾きつつある。

他には、planしたことが実装時にうまくいかなかったら deviations.md として記録していて、後から見直せるようにしている。何回も同じこと繰り返している場合は CLAUDE.local.md に書いたりする。

またプルリクエストを分けるのは、自分がレビューする時にデカいと見たつもりなのに見れてないことがあったので、細かく分けるのがいいなとなった。最近Stacked PRという神機能がパブリックになったので愛用している。

- brainstorming / writing-plans の成果物は superpowers 既定の置き場を上書きし、変更単位ごとに 1 ディレクトリへ spec と plan を同居させる
  - spec（brainstorming）: `docs/issues/YYYY-MM-DD-<change-summary>/spec.md`
  - plan（writing-plans）: 元にした spec と同じ `docs/issues/YYYY-MM-DD-<change-summary>/` に `plan.md` として作成する（新規ディレクトリを切らず、その spec のディレクトリを再利用する）
  - `YYYY-MM-DD` は作成日、`<change-summary>` は変更内容を表す短いスラッグ
  - spec を伴わず plan だけ書く場合は、同形式で新規ディレクトリを作成する
  - spec・plan は git add / git commit を行わない。
  - spec を作成した後（brainstorming）と plan を作成した後（writing-plans）に、それぞれ crit スキルで `crit <対象ファイル>` を実行してレビューを行う
    - スキル既定の「ユーザーに確認を依頼する」レビュー工程（brainstorming の User Review Gate 等）は crit の実行で置き換える
    - crit のレビューが完了（コメントなしで Finish Review され approved になる）するまで次工程（spec なら plan 作成、plan なら実装）へ進まない
    - crit のコメントに対応する前に、必ず `superpowers:receiving-code-review` スキルを呼び出す。各コメントを技術的に検証・評価したうえで、「修正を適用する」か「`crit comment --reply-to` で技術的な根拠を添えて反論する」かを選ぶ。指摘を鵜呑みにして一括適用しない
- plan の実行中に plan の記述と実際が食い違ったら（設計が成立しない・想定外の既存実装・手順の変更・手戻りなど）、対応する前に plan と同じ `docs/issues/YYYY-MM-DD-<change-summary>/` の `deviations.md` に追記する
  - 記録項目: 対象タスク / plan の記述 / 実際どうだったか / 取った対応 / plan 作成時に何を確認していれば防げたか
  - `deviations.md` も git add / git commit を行わない
- `docs/issues/YYYY-MM-DD-<change-summary>/` の作業（spec / plan / 実装）を扱っている最中に handoff スキルを実行した場合、引き継ぎ資料は OS の一時ディレクトリではなく、対象の issues ディレクトリ配下に `handoff.md` として置く
  - 既に `handoff.md` があれば上書き更新する
  - `handoff.md` も git add / git commit を行わない
- plan 時にタスクを作成する時、レビュアーがレビューしやすいようにプルリクエストの作成は、意味のある単位で分割する。
  - プルリクエストを分割する時、 gh-stack スキルを利用して Stacked PRとして作成する
- プルリクエスト作成後は、人間が作業を行うので、そのまま次のタスクは進めず、人間の指示があるまで停止する。

自分は「AIを生産性向上のためではなく品質向上のために利用する」という気持ちでいて、品質を向上させるには実装より手前で潰せるものは極力潰し切るのがよいと思っているので、自分はこのフローが合っている。

最近触ったが合わなかったもの

モバイルアプリの画面をリアーキテクチャする前に仕様書を書き始めた

  • 画面仕様書と呼んでいる
  • リアーキテクチャをするとき「振る舞いは、原則現行通り」となるが、現行通りとはなにかがわからない
  • 自分の場合、とにかくコードを読んで理解するために頑張るわけだが大変。QAEはコードを読めないので、ドキュメントや実際に動作させて調べているらしい
  • 今はClaude Codeがあるし、レガシーの実装から振る舞いを書き出してみるのがいいのではないかとやり始めた
  • Claude Codeで一発で書き出して終わりというわけではなく、1,2時間くらいかけて修正している。人間が1から書くよりは早いかなという印象。あと人間が書いてもAIが書いても100点は取れないなと思っており、間違うことはあるなという前提でいる
  • 実装がそう振る舞っているだけで、意思を持って決めた仕様ではないため仕様と言いたくないという気持ちにはなるが、ユーザーにとってはそんなの知らんがなという話なので、仕様とする！！！とした
  • また、そう振る舞っていることを言語化しただけなので、意図はまったくわからないことが多い。「なぜそういう実装/仕様に？」は全くわからないので、意図負債は残り続けている
  • 最初はレガシーの画面仕様書だけ書いていたが、リアーキテクチャ時にバグを直したり「これはやめよう」と振る舞いを変えたいことがあることに気づいた
  • レガシーの画面仕様書は、as-isだが、to-be も必要になってきたということ
  • ほな、作りましょうということで、レガシーの画面仕様書を元にリアーキテクチャ後の画面仕様書を書き出すようにした
  • レガシーの画面仕様書には元々バグっぽい挙動や変な仕様を書き出す章があり、そこに「リアーキテクチャ時に直す」とかを記載していたので、それを元にto-beな画面仕様書を書き出すようにした
  • to-beの画面仕様書は、リアーキテクチャを行う前に書き出している
  • リアーキテクチャの前に書き出すことで、実装のタイミングで画面仕様書を更新できる。例えば、Golden テストを書いたら画像を貼ったり、リンクを貼れたりするわけですね。
  • このあたりは、すべてスキル化されている。あとはto-beの仕様書と実装を比較するスキルとかも用意した。
  • それぞれレビューややり取りをかなり細かくして、自分が説明可能な成果物が出てくるという感じ。
  • まあ、実装と同じですね
  • これはCritにかなり助けられている

リポジトリ内の技術ドキュメント

元々 .claude/rules/*.md に「ーーーはこうあるべし」を色々書いていたが、superpowersを使ってspecやplanを書いた時に参照されなかったりと微妙だなぁと思えてきた*1ので、やり方を変えることにした。

  • docs/ 配下にドキュメントを書く
  • CLAUDE.md から 「ーーーする時は docs/xxx/xxxx.md を参照すること」と記載

という形に変更した。現状単体テスト、Golden テスト、Widget テストについてしか書いてないが、specやplanやレビューでいい感じなのでこのまま他も揃えていく予定。

目的 → 目指す状態 → やり方の流れで書く

元々rulesを書いた時はAI向けだ！と思っていてなるべく短くしたい気持ちでいて「こうするべし」というやり方しか書いていなかったが、docsに移行するにあたって、「目的」と「目的を満たしている状態」と「どうやってその状態にするのか」を書くようにした。

少なくとも人間は、目的を理解していないと行動を変えにくいだろうし、ドキュメントで書かれてることだけやりました*2となるのもおかしな話なので書くようにした。AIもそうなのかもしれない。

例えば、テストも「なぜGolden テストを書くのか？」を理解出来ていないと意味のないテストやテスト範囲が大きすぎるテストをAIが書いてもレビューで指摘出来ないとかがある。このあたりの認識をチームで揃える必要があるし、自分含め常にアップデートしていく必要があるので言語化しておくの大事そう。

スキルにしない

最初はスキルにしようかと思っていたが、CLAUDE.mdで参照するように言えばいいかと気づいてやめた。

1つのドキュメントの長さ

最初は単体テストに関することが複数あるので、それぞれファイルを小分けにしようと思っていたが、単体テストを書くとき・レビューするときに全部参照してほしいなと思ったので分けずに1つのドキュメントにまとめた。最近は1M Contextとかになっているし、気にしすぎなくて良い気がする。とにかく小さく保て！と言われると小さく保ちたくなるが、早すぎる最適化と思って堪える。

*1:正確にはCLAUDE.local.mdなりで指定すればいいのだろうが、ほなrulesで書く意味ないやんと思ったし、設定するしないがあるのは微妙そう

*2:そんな同僚はいません

最近の開発 2026-05

  • obra/superpowers を使っている
  • brainstormingでぼんやり考えていることを書き出してもらってから進めている
  • 自分の悪いクセでやろうとすることが大きく変更も大きくなりやすいことが多い
  • Claude Codeが賢いので、大雑把に言ったことでも実現出来るが当然やるべきことが多いので変更は大きくなる
  • 変更が大きくなると全ての変更に目を通したつもりが漏れてることがあったりして、理解負債が貯まっていくように感じた
  • なのでまずは分解するためにやろうとしていることを洗い出すというのが自分には向いてそうだった
  • 洗い出したものを眺めて、こう分割して進めようとか考えることが多い。分割するのが決まったらまた改めてbrainstromingから始めることもあるし、writing-plansで範囲指定して実装計画を書き出すこともある
  • specやplanは今のところコミットしていない。おそらく自分しか利用していないので、コミットする価値があるのかよくわかってない

最近のLinter事情

analyzer 9.x.xにアップデート出来た*1ので、元々custom_lintで書いてたものに加えて新たにカスタムルールを書いたりしている。

なぜLinterが必要なのか

  • AIは確率論的に動くため人間と同様に抜け漏れがある。逆にLinterは、抜け漏れが*2ない
  • Linterはルールのテストが書けるというのも自分的には大事
  • 基本的に自分が扱うリポジトリは、Claude Codeを前提にしてルールなどを書いているが、チームメンバーがそれ以外を使って開発することは止めることは出来ないし、プルリクエストが必ずAIを通しているとは限らない

すべてをAIで解決するのではなく、適材適所いい感じに使いたい。プログラムで問題発見出来るものを都度AIで発見するのではなく、問題発見するためのプログラムをAIで書く。手動テストせずに自動テスト書くみたいな感じ。

どういうルールを書くのか

プロジェクト特有のルールやライブラリ特有のルールを書く。 例えば、以下のようなのを書いて設定している。

  • このレイヤーからこのレイヤーは逆流してはいけない
  • このファイルは、こういう命名規則のクラスでなければならない
  • Widgetは1ファイルにつきpublic classは1つでなければならない
  • sealed classは、freezedを利用しなければならない
  • RiverpodのRefをProvider以外に引数として渡してはいけない

どういうルールを作るべきか？もAIと話して見つけることがある。また元々custom_lintを使っていた時からこういうルールがあると良さそうというのを溜めていたのでそこからちまちま作っている。

その他、考えていること

コードレビューをAIに任せようという話があり、自分も任せているし有益である。一方で、Linter、テストカバレッジ、循環的複雑度、認知的複雑度、Code smellsなどを機械的に示すことで解決できることも多くあり、まずはそっちを頑張ろうかとぼんやり思っている。

*1:アップデートした日に13.0.0が出ましたが...

*2:ルールにバグがない限り