iiinova — where your digital self keeps evolving

Claude Codeのスキルに書いたワークフローの掃除をしました。手順は徐々に変わるところがあるので、掃除をさぼると、血の巡りが悪くなってきたような感じを受けます。

sosuisen @sosuisen.bsky.social · 27/09/2026

テスト駆動開発は探索的な手法であるため、そこはもう分かりきってる実装だ、という意識では旨味が小さくなりそうです。本当にやってみないとわからんぞこれは、という課題には使うとよいだろうし、そうでないとしても、じゃああえて課題を難しくしてちょっと負荷をかけてみようか、という形での探りを入れることのできる道具なのかもしれません。

000

sosuisen @sosuisen.bsky.social · 27/09/2026

《ギアのメモ》 2速の開発。PCのスクリーン&サウンドキャプチャ（sss-scene-capture-lib）。・testを書くことでRustを勉強することも目的のためじっくり2速。ひとつひとつ調べながら。・実際に必要かつ難しいところから触れてゆくのは刺激的。

000

sosuisen @sosuisen.bsky.social · 27/09/2026

今日起こったことは、次の2つでしょうか。・もともと人間側が考えていた腹案がある場合、すぐに問題修正の指示をだせる。・人間側の未来の心づもりが、最初の指示に含まれてないことは不思議ではない。エージェントが出した案を見てから、違和感を感じて（「なんでidxは同期させないんだ？」）、今後の計画のために足りないことを思い出した。

000

sosuisen @sosuisen.bsky.social · 27/09/2026

《ギアのメモ》 4速の開発。PetaJournalをDropbox経由でPC間同期する。・4速の理由：急遽1週間後に必要を感じたがもう時間がない。Writeを伴うが、データはDropbox側に変更履歴が残るため、壊れたときの実害が小さい。自分しか使わない。5速のつもりだったが、同期アルゴリズムは難しいので不安があり、手順は確認した。コードそのものは見ていない。・4時間程度で動作確認まで。いったんこれで乗り切る。・DB <-> Markdown <-> (Dropbox) <-> Markdown <-> DB の同期は、衝突と削除に関わる処理を手動にすれば、素朴に実現できることを確認。

100

sosuisen @sosuisen.bsky.social · 25/09/2026

開発におけるエンジニア個人の成果物は、Architecture Decision Record (ADR) ではないかという感じがしています。探索機会が確保されていると、どういう選択肢があって、なぜ、その技術を選択したのか？という意思決定の記録であるADRも増えてゆくはずです。これは自分の実験と学びの記録で、ノートそのものです。

000

sosuisen @sosuisen.bsky.social · 25/09/2026

この辺りを意識してみます。

000

sosuisen @sosuisen.bsky.social · 25/09/2026

エージェントの書いたコードを嫌々レビューしているエンジニアのための、夢中になれるような工夫集（暫定）。・探索機会の確保（ソフトウェアの振る舞いに関する気づきや広がりを得られるよう、技術的な疑問を盛り込む。）・つかみ（機能はあっけなく実現できるため、興味を維持できる非機能要件を盛り込む。使い勝手や表現上の工夫など。）

000

sosuisen @sosuisen.bsky.social · 25/09/2026

Read系の場合、普通の表現だと飽きてしまうので、自分が興味を持てるような表現の工夫を目標に盛り込んでゆくとよさそうです。

000

sosuisen @sosuisen.bsky.social · 25/09/2026

Markdownをパースして、特定の図面として表示するアプリを作っていますが、レビューする気持ちが顕著に低下しています。スタンドアローンなので通信の問題がないことと、Read系は失敗したときの問題がWrite系よりも小さいからだと思います。

000

sosuisen @sosuisen.bsky.social · 25/09/2026

素朴な発想でいうと、人間が関与する必要があってかつ人間の理解の速度がボトルネックだとすれば、エージェントの速度を落とすだけでなく、人間の探索機会も増やして、全体のフローをよくしてゆくことが、いい結果を生むのかなぁ。

000

sosuisen @sosuisen.bsky.social · 25/09/2026

探索機会の喪失、とまとめておきたいと思います。その深刻さの度合いにはまだ確信がありませんが。

000

sosuisen @sosuisen.bsky.social · 21/09/2026

わたしが昔いた小さなベンチャーでは、メインプログラマー（わたし）の手を煩わせるわけにはいかん、といって、営業、マーケティング、経理の書類に関するバッチ処理は社長がBASICのスクリプトで書いてました（まれに私がデバッグ）。2010年代の話です。あれで会社は回ってたので、ああゆうところがまずギア5速のフルオートAI開発に変わります。

001

sosuisen @sosuisen.bsky.social · 21/09/2026

認知負債、理解負債の問題はまだ新しすぎて、事例や実験結果はいくつかあるものの、具体例が十分には積まれていないようにみえます。なので、わたし自身にそういうものがなにかあらわれて、どう問題になりそうなのかを確認してゆかないと、学生さんに対して自信をもって話せることがありません。

000

sosuisen @sosuisen.bsky.social · 21/09/2026

そのうえで、ソフトウェアエンジニアの卵のみなさんにいま学んでもらうことは何か、ということを改めて考えています。

000

sosuisen @sosuisen.bsky.social · 21/09/2026

たぶんちょうど高校の情報Iくらいの知識があれば、5速で自分の、現場の針仕事を片づけるには十分かもなぁと思います。ネットワークアクセスが伴う際のリスクは気にしておいたほうが安全なので。次第に気にされるようになったインターネット利用上のリスク感覚、と地続きな感じもします。

000

sosuisen @sosuisen.bsky.social · 19/09/2026

エンジニアの場合、ソフトウェアの開発プロセスをエージェントに外注するほど、技術を起点としたソフトウェアの振る舞い（機能）に関する気づきや広がりは減少するかもしれない、という仮説です。

010

sosuisen @sosuisen.bsky.social · 19/09/2026

具体的に起こったことを書いてみます。・お絵描きチャットアプリを開発中（2速）・別の作業中に .png -> .ico/.icns変換アプリが欲しいと思った。・お絵描き系のアプリを開発中だから、.ico/.icnsについて知っておくとなんかいいことある気がした。このため変換アプリも2速で開始して、画像フォーマットを理解した。・その後、変換アプリは加速して3速、4速へ。・.ico/.icnsは複数の画像を1ファイルに収める素直なフォーマットだった。昔よく似た自作フォーマットを作ったことを思い出した。・お絵描きチャットアプリでレイヤのファイル保存は検討してなかったが、ここで頭に浮かんだ。

000

sosuisen @sosuisen.bsky.social · 19/09/2026

開発者としての関心の面では、自分がエージェントに任せたいくつかのアプリではそういう気配があります。そうなってないのは、毎日つかっていてユーザの観点での気づきが多いアプリかな。

000

sosuisen @sosuisen.bsky.social · 19/09/2026

《将来必要となるすべてのコードを一度に書くことはできない。それができるのは、私たちが何も学ばなかったときだけだ。》（Kent Beck, "Tidy First?"）フルオートでエージェントにアプリを作ってもらうことは、ここでいう将来必要となるすべてのコードを一度に書いてしまうことかも知れないと思いました。一気にもう完成した、と錯覚させられたアプリに対しては、まだ未完成だから変えてゆきたいという関心や駆動力が長期的にはどこか損なわれて、最初の完成の時点で凍結されてしまう部分があるかもしれないという点で。

000

sosuisen @sosuisen.bsky.social · 19/09/2026

《プロのプログラマーとは、自分の技巧そのものや仕事を小さく改善して大きな成果を出すことに対して、ギークのように深くまで関心を持つソフトウェア開発者だ。》（ラリー・コンスタンチンによるTidy First?のまえがき）日々の仕事の小さな工夫を楽しく語っている人の話には惹かれるところがあります。カイゼン、と片仮名になるとなんか違うのですけども。

000

sosuisen @sosuisen.bsky.social · 18/09/2026

《ギアのメモ》 2速から4速の開発。作業用の自作アプリが増えて、標準アイコンでは区別できなくなった。.pngから.icoと.icnsを簡単に生成できるsss-png2iconを開発。・.icoと.icnsの画像フォーマットに興味があったので最初は2速。・フォーマットを理解したら、あとはやるべきことが自明なこともあって3速、最後は4速まで加速。3時間。・GUIのテストは手間であり、そこをエージェントに頼ると、なし崩し的に加速しがち。・1つのプロジェクトを全て同じギアで走らなくてもよいが、Low->High方向は要注意では？・.iconと.icnsの中身が分かったのはよかった。

000

sosuisen @sosuisen.bsky.social · 18/09/2026

どういうときにどのギアで進めるのか、感覚を掴んでゆこうとしています。なんにせよギアが成立する要はTDDでして、ほっとくとアクセルべた踏みなエージェントに対して、意図的に「速度を落とす」ことの出来る手順が効いていると思います。

000

Reposted by sosuisen

Tak. @wordpiece.bsky.social · 18/09/2026

文章におけるテストとは何か、考えてみるとけっこう深いです。

033

sosuisen @sosuisen.bsky.social · 18/09/2026

《ギアのメモ》 5速の開発。PowerPoint標準のPDFエクスポート結果には 'git add index.html' のような文をコピーすると半角スペースを無視するケース（gitaddindex.htmlになる）があるため、回避するためのpptx2pdfを開発。・授業準備で使うため急ぎ。問題発生時の回復が容易な用途。・問題と解決方法の議論は事前にClaudeと行った。・その後、10分で作成。・JavaFXでもPowerShell経由のCOM呼び出しで手軽にWindows自動処理を組めるという実証が生まれた。ただし、コードの中身は見ていない。・4年越しの問題が解決。

000

sosuisen @sosuisen.bsky.social · 17/09/2026

これは人間が介入することで「余計なことをした」パターンですね。企業の製品開発だと良くない手筋ですが、個人だとそうでもないかと。

000

sosuisen @sosuisen.bsky.social · 17/09/2026

《ギアのメモ》 3速の開発。WAV->MP3の変換が必要になったため。・テスト駆動で手をつけ始めたとき、せっかくなのでリリースされたばかりのJavaFX27の拡張スタイル（StageStyle.EXTENDED）を適用しようと思った。・すると自作のBuilder APIも27対応する必要に気付いた・半時間かけてBuilder APIを更新リリースしてからアプリに戻った。・全所要時間は90分。・セミオートの4速以上ならJavaFX26のまま10分で作れたアプリ。最速でアプリが欲しいだけなら余計な回り道をした。・この機会がないとBuilder APIの更新リリースは後回しになってた。

000

sosuisen @sosuisen.bsky.social · 15/09/2026

エンジニアリングとアートの違いとして、2倍の時間で1％の違いが生まれる技法が、アートとしては歓迎されて、エンジニアリングとしてはそうでもないことがまああると思います。ただ、プログラミングそのものはエンジニアリングの場面でもアートの場面でも用いられます。その中間のようなコードもあります。精密機器と日用品という区別もありそうです。だれがどういうものをつくるときにはこういう方法が向いてるかもしれない、ということが、エージェントとの付き合い方に関しても次第に見えてくるんじゃないかと思います。

010

sosuisen @sosuisen.bsky.social · 15/09/2026

なお、テスト駆動開発は、いまのところ、基本的には人間向けの技法だと思います。フルオートのエージェントがわざわざRGRのステップを踏むことの効果は、よく判ってないとおもいます。エージェントの場合はコードを書いてからテストを書く手順でも同じ結果になりそうな気もします。じっさいに3速で書いていると、エージェントは答えのコード（実装）を知った上でテストを書いてるように感じられました。人間のテスト駆動開発では、実装方法は判らないけどまずテストを書いてみるところが妙味となっています。

000

sosuisen @sosuisen.bsky.social · 15/09/2026

英語のハノンのプレイヤーは3速で作りました。これは半分以上、わたしが作り方を知っているタイプのアプリでした。いままた新しく作ってるのは未知の部分が多いアプリで、2速にしています。やはり、速度はだいぶ遅いですが・・？

000

sosuisen @sosuisen.bsky.social · 15/09/2026

Lowギアで直接介入して試行錯誤したときに得られる人間側の気づきや形成されるメンタルモデルが、開発を駆動する上で、どういうときにどういう形であらわれうるのか。トルク、というメタファーは、おそらく坂道発進のような、最初に高いハードルのある開発で効いてくるのでは？という予想に基づいています。

001

sosuisen @sosuisen.bsky.social · 15/09/2026

わたしがコードを書くときの、エージェントのギアについて確かめようとしています。（テスト駆動開発が前提） 1速：テストもコードも人間が書く。 2速：テストもコードも人間が書く。ただし、AIによるコード補完やリファクタは用いる。 3速：テストもコードもAIが書く。ただし、RGRのステップごとに人間がレビューしながら進める。 4速：テストもコードもAIが書く。人間は気になるところだけレビューする。 5速：テストもコードもAIが書く。人間はなにもしない。ギアがLow側のほうがトルク（？）が高く、速度は遅い、という仮定での分類です。これがどういう対象についてどの程度成立するのか確かめたいなと。

120

sosuisen @sosuisen.bsky.social · 15/09/2026

あと半年間は、次どのドリルをやるかが明確に判ります。Last playedが空欄かそうでないかの切れ目。3周目は下から上にさかのぼっています。半年後にはLast playedが全て埋まりますが、4周目の練習をどうするかはまたそのとき考えればいいかな。カラムを追加するとか？デジタルツールは5年日記みたいにあらかじめ5年分の行（や列）を持っている必要はなくて、必要になったら追加できます。一方、5年日記みたいにあらかじめ「枠」が用意されているものは、たぶん覚悟のようなものとか、こういうメンタルモデルで臨むぞ、というところが違ってくるとは思います。

000

sosuisen @sosuisen.bsky.social · 08/09/2026

Last playedはなんとなく付けたものですが、レッスンごとに埋まってゆくのはよいですね。レッスンした日はカレンダーに色がついてくみたいなのもよいかも。

000

sosuisen @sosuisen.bsky.social · 07/09/2026

駆動、という考え方が面白いなと感じています。人間の側の行動を促すもの。なかなか手を動かせない、気が進まない、よく判らないようなときに、なるべく軽い一歩を提供する呼び水として「テスト」を置くことが提案されています。このあたりが、フリーライティングでちょっとしたことから書き始めてみる感じに似ていると思ったんですよね。

021

Reposted by sosuisen

Tak. @wordpiece.bsky.social · 07/09/2026

執筆はエンジニアリング的に捉えられる部分とそうでない部分があり、しかもその境目は目的や書き手の状況によっても変わるんですよね。

111

Reposted by sosuisen

倉下忠憲 @rashita.bsky.social · 07/09/2026

最大の問題は、書き始めてみないと、何をテストしたらいいのかわからないことが多いことですね。文章の種類によっては。

042

Reposted by sosuisen

倉下忠憲 @rashita.bsky.social · 07/09/2026

つまり、テストを意識することで書いたものを固めていける、という構造があるという点が面白いんですね。どんなテストが必要かを考える思考法があるというか。

011

Reposted by sosuisen

倉下忠憲 @rashita.bsky.social · 07/09/2026

"「ローソンのうずまきロールケーキがおいしかった」という記事を書く"、ということすらわからないことがあるのです。とは言え、テスト的な概念が有効だとは思います。むしろ書くときはそれをしているような気すらします。

123

sosuisen @sosuisen.bsky.social · 07/09/2026

だからまぁ、すでにアウトライナーでだいたいできてしまってることを、もっとシステム的にテスト駆動という手順でやる必要があるのかどうか、という感じではありますが、類似点には面白さを感じています。

010

sosuisen @sosuisen.bsky.social · 07/09/2026

ケント・ベックのテスト駆動開発は、「書き始めてみないと、何をテストしたらいいのかわからない」、に応える技法なので、アウトライナーを用いた執筆に似ているのはそういうところだと思います。たとえば「ローソンのうずまきロールケーキがおいしかった」という記事を書く場合、最初のテストは「クリームが甘かった」で、それに対応する本文は「ローソンのうずまきロールケーキはクリームが甘かった。」になると思います。この本文はテストを満たしています。当たり前に書けそうな本文をいったん書いてみてから、次になにをテストするかを考えてゆきます。テストによって駆動される、ということをケントはそういう風に論じています。

031

sosuisen @sosuisen.bsky.social · 07/09/2026

テスト駆動執筆、昔は自動回帰テストが不可能でしたので、原理的には可能でも現実的な実施が不可能だったのですが、いまは現在の原稿が過去のテストを全て満たしてるかの確認をわりと自動化できるので実現できなくもなさそうになりました。試したことはないのですが・・。

000

sosuisen @sosuisen.bsky.social · 07/09/2026

暮らしで使う道具の自作化が進んでいます。

010

sosuisen @sosuisen.bsky.social · 06/09/2026

英語のハノンを2周終えたので、3周目をやりやすいよう専用のプレイヤーを作っています。付録の音声ファイルを用いたドリルについて、ハノンでは音声を止めずに進めるのが流儀ですが、リスニングできなかった区間だけ何度もリピートで聞くためのインデックスがなくて不便でした。無音区間をヒントに音声を自動セグメント分割したので、簡単にリピートできるようになりました。3周目がんばるぞー。

130

Reposted by sosuisen

倉下忠憲 @rashita.bsky.social · 05/09/2026

考えてみると、執筆のテストにも単体テスト、結合テスト、全体テストなどがありそうです。

012

sosuisen @sosuisen.bsky.social · 02/09/2026

これが春の途中の出来事で、秋からはいったん4色体制に変わります。またもとに戻すかもしれません。しかし、もとに戻すことも以前よりだいぶ楽にできるようになりました。

000

sosuisen @sosuisen.bsky.social · 02/09/2026

資料を書く間に、こうなんじゃないか、という予想のもとにルールはまず生まれました。一方、スライド資料には「使う」ものという性質もあります。講義中じっさいにそのスライドを使って説明するなかで違和感をおぼえた点もまた、ルールになってゆきます。例えば、今年の春の講義中の気づきには、初心者向けの話と深い話とがスライドに区別なく混じっており、初心者がこれを全部理解しなくちゃならないの？って気持ちになるといけない、ということがありました。あまり色の種類は増やしたくないのですが、「研究」という色のスライドを増やして、初心者はいったんスキップしてよいことを示すようにルールを追加しました。

000

sosuisen @sosuisen.bsky.social · 02/09/2026

心配事を言えば、自動化されたプロセスの部分は、実はルールを生み出す土台になっていたかもしれない、というところですね。

010

sosuisen @sosuisen.bsky.social · 02/09/2026

自動化のおかげで「私のルール」を貫くことが楽になりました。講義資料のスライドには、こうあるべき、というルールを積み上げてきました。スライドのデザインはプレーンに、3色のテーマで種類が判る（目次、解説、演習）、セクションごとに目次を挟んで現在地を示す、日本語文に混じった英語のコード部は読みにくいのでハイライトする、等。 MS Officeは昔からCOMオブジェクトを公開しており、プログラムで操作できます。あまり使いこなしてはこなかったのですが、いまはアウトライナーで原稿を書いたら、Claude CodeがCOM経由で私のルール通りにPowerPointのたたき台まで作ってくれます。

120