要件定義系と、ニーズ調査しつつクオリティ上げる系の仕事が重なったらつらいという話。
個人的にタスクの種別としては一番美味しいタスクだと思ってるけど、〆が重なったタイミングで死ぬ。

最近、仕事でAI-DLC的なことをしていて思うこと。

AIの稼働が高ければ高いほど、ソフトウェア開発は速い。
人が手を動かす時間が減るぶん、アウトプットの量もスピードも増していく。
一方で、商用サービスを提供するなら品質に問題がないことを担保しなければならず、その手段としては人が品質ゲートになる手法が主流（少なくとも、いまいる会社では）。

手戻りのリスクを最小化するには、この品質ゲートを品質が最大化できるタイミングで入れる必要がある。
ただ、人による品質ゲートはそのままAIの稼働を止めるボトルネックにもなる。
なのでこのボトルネックをいかに減らし、本質的なチェックだけに絞れるかが効率と品質を両立させる鍵になると思う。

そう考えると、人が確認しておかないと本当にリスクになる要素は限られてくる。
線引きの基準は「あとから直すのが可逆か、不可逆か」だと思う。
仕組みで検知して後追いで直せるもの＝可逆なものは、AIと仕組みに任せて流していい。
一方で、一度ボタンを掛け違えると後戻りのコストが跳ね上がるもの＝不可逆なものだけは最初に人が止めるしかない。
その観点で優先度が高いのは以下あたりだろう。

• ユーザーストーリー
  • ユーザに対してどういう価値を提供するか
• 画面設計
  • ユーザに対してどういう形で提供するか
• データ構造
  • そのソフトウェアが扱うドメインを正しく表現できているか

もっとも、どこまでを「不可逆」とみなすかの線引き自体がドメインの理解を要する判断で、たぶんここが一番難しい。
逆に言えば、この見極めさえできていれば、あとは人が介入せずどんどんAIに進めてもらえばいい。
そして品質の悪化は、レビュー以外の手段で気づけるようにしておく。
こうすれば品質と開発速度を同時に最大化できる気がしている。

レビュー以外の手段とは、たとえば以下のようなもの。

• lintでの静的解析
• テストカバレッジ
  • 網羅率というよりも、カバー範囲に懸念がないか
• 依存関係グラフ
  • dependency-cruiserなど
  • 構造としてカオスになっていないか（ドメインを正しくコードに落とし込めているか）
• 実装時に参照したドキュメント

こういう仕組みを入れてプロダクトの健全性を徹底的に可視化すれば、実装のタイミングでコードの詳細を確認しなくても品質はある程度担保できる。
可視化で見えた問題は、たいてい可逆な品質だ。
それを後追いでどんどん直していくほうが、人が逐一確認するよりも結果的に高品質だし速い。
逆に言えば、人が事前に止めるべきなのは「可視化では見えない、かつ不可逆なもの」に絞られる。

そして、これまで人のレビューが担保していた領域も、できるだけ仕組みに寄せていく。認可の抜けや破壊的変更、異常系の見落としといった、ロジックの考慮漏れに気付ける構造をつくっていく。

今のプロダクトでもこういう思想をもとに、開発ダッシュボードを用意してプロジェクトの健全性を可視化しCIを手厚くする試みをしている。
今のところ、結構良い感じに機能している気がする。

結局のところ、人の仕事は「コードを一行ずつ確認すること」から「どこに品質ゲートを置き、何を可視化するかを設計すること」へ移っていくんだと思う。
人が見るべき本質的なポイントを見極めて、それ以外はAIと仕組みに任せる。
その線引きがうまくできるほど、開発は速くそして品質も高くなる。

映画の鑑賞メモから、ベスポジ早見表にしてみる。完全に自分用。

★ は、メモ本文に「ベスポジ」とハッキリ書いてあった席。それ以外は複数回行った中での◎評価からの推定。

2025年の鑑賞メモからAIで作ったデータ。

シネマシティ

スタジオ	センター番	ベスポジ	コメント
A	12番	L12（次点 M12）	Flow「12。ベスポジ」/ ララランド L12「ど真ん中」/ スーパーマン L12「完璧」。M12 はもう一つ前がサラウンド真横で音重視なら可
B	12番	H12〜J12	ロボドリ G12「素晴らしい位置」/ ロズ H12「ど真ん中」/ YOASOBI J12「高さセンター◎」。サラウンド真横は I12。低音強め
C	8番	G8（音重視は E8）	ビーキーパー G8「シネスコならここ・迫力◎」/ イノセンス g8「前後感◎ サラウンド位置も◎」。白雪姫 E8「音めっちゃ良い」
D	13〜14番	F13 前後	プリプリ g13「センターでいい席、もう一個前でも」/ 岸辺露伴「13・14がセンター」（記録2件）
E	13番	★ F13	都市建設中 F13「ベスポジ」と明記。H21 はスピーカー指向性外で非推奨
F	—	データ不足	席付きの記録なし
G	11番前後	J11 前後	東京MER J10「ダブセン左／もう一つ右が良い」。ただし抜け感不足・中域モタつき、Bスタで見たい
I	11番	G11 前後	キミプリ G11 / ストレンジ・ダーリン F11「右め」。記録少
J	8番	C8〜E8	はたらく細胞「E8センターだけど C8でいい（小箱）」/ 孤独のグルメ c8「前後感◎ だが傾斜無く頭被り注意」
K	—	データ不足	K11 一回のみ、評価なし

その他の劇場

劇場 / スクリーン	ベスポジ	コメント
新宿バルト9 シアター1	C5 付近（前め）	「センター、サラウンド真横。Cバランスの最前線」
新宿バルト9 シアター3	★ F10	「ど真ん中前後も良い。ここがベスポジ」。5.1ch 音良すぎ・サラウンド優秀
新宿バルト9 シアター9	H18〜I18	H18（5/28）「座席完璧・ここ一択レベル」音量◎音質△ / I18（9/15）「ど真ん中・めちゃいい席」音デカめ
チネチッタ LIVE ZOUND（8番）	L15 前後	「L15がど真ん中、前後いい感じ」
Tジョイ横浜 シアター2	C10（近め）	「ど真ん中。近いが上下は苦じゃない、近くで見たい時◎」
横浜ブルク13 シアター2	C8	「どまんなか。前目だがいける」
横浜ブルク13 シアター8	B8	「ど真ん中。前目だがスクリーン距離あり前目で見たいなら◎」
109シネマズプレミアム 新宿	D4	「センター。これより前は無し」。音わかりやすい
109シネマズ 二子玉川 SC9	E13（映写品質△）	「ど真ん中」。暗い・ノイズ・周辺光量悪、音は控えめ
シアタス調布 3	E5（映写暗い）	色薄い・周辺光量減光酷い。スクリーンは大きい

まとめ（よく行く所だけ）

• シネマシティ A → L12
• シネマシティ B → H12〜J12
• シネマシティ C → G8（音優先なら E8）
• シネマシティ E → F13
• 新宿バルト9 シアター3 → F10

従来と比べると、実装の速度が爆速になった。
そうなると、意思決定での足踏みがかなり目立つようになってきたように思う。

昔はアサインを割り振って並列で進めることが、そのまま効率化につながっていた。

ただ、今は速度が出るので、並列で進めようとすると逆に以下のようなことがボトルネックになる。

• 他の人の設計や実装ができるのを待つ必要がある
• 他の人の設計や実装とのすり合わせや認識合わせに割と時間がかかる

従来は考えを洗練させる時間、文章化する時間、整合性を確認する時間など諸々時間がかかっていたが、そのあたりはLLMで爆速でできるようになってきた。

なので、源泉となるアイデアや思想さえあれば、上記のような時間のかかる作業に対して人が時間を割く必要が無くなってきていて、そのせい（おかげ）で足踏み感がかなり目立つようになったと感じる。

こうなると、機能ごとの縦割りのアサインよりも、全体像のアーキテクチャやポリシー設計をガッツリ固めてから、それをもとに詳細を各々が担当して深堀りしていく感じのワークフローが良い気がしている。

個人的にはアーキテクチャやポリシー設計を決めるのは1人がやったほうが、思想を1本化しやすくブレないので良いと思っている。ただ極端な話、全員でやってもいい。

というのも、「この部分は別の人が考えるから、自分はやらないでおこう」と切り分けた結果、あとから別の人の設計が上がってきて、それを受けてのすり合わせや修正がお互いに必要になる。
それが積み重なると、間違ってはいないし整合性は取れているけど、なんだかイケてない仕様ができた……みたいになりがちで、そういうのを避けたい。

• コードRVして
• ステージングしてる差分のRVして
• コミット前にステージング分の最終チェックとしてRVして
• 技術的負債にならないように、各種ベストプラクティスに沿っているかの観点を重視してRVして
• DRY原則、YAGNI原則などを重視して、技術的負債をできる限り減らせるように広くコードRVして

まぁ当たり前ですが、粒度が変わると応答が大きくかわる。
どれが良いというわけでもなくて、期待する結果に合わせて意識的に変えるのが良い。

その上で「目的」を厚めに伝えると、思考力の高いモデルは想像以上に良い結果を返してくれることが多い。

例えば何かを作るときも、
「A機能を実装して。これに注意して、必ずこうすること。動きは～～～～。」
というよりも
「XXをするのがめちゃくちゃめんどくさい。今はコレをするために、あれをこうして、こうしなきゃいけない。30分も時間がかかってるので1分でできる感じにしたい。なのでいい感じに機能Aを実装して」

こんな感じで「機能Aの詳細」よりも「機能Aが欲しい理由」を手厚く伝えたほうが経験上100倍いい成果物ができる。
で、具体的なアーキテクチャや実装手順/思想は、プロンプトではなく、スキルなどでワークフローとして定義してあげておくのが一番楽。

具体的に書きすぎるとLLMの持つ知識量を最大限活かせない代わりに思い通りの結果を得やすい。
抽象的に書くと、正しく意図が伝わればLLMの知識量を最大限活かせて、入力に対して出力のコスパが高くなる傾向が強い。ただしその代わり、プロンプトや外部ツールでLLMがブレないようにするハーネス的な仕組みの重要性が増す。

そんなことを最近思ってる。

nitlog.dev は以下のカテゴリで運用しています。

カテゴリ	内容
Tech	技術系の話
Movies	映画の鑑賞記録
Tane（種）	アイデアの種、TechやMoviesで記事にする前の断片

TechとMoviesは腰を据えてしっかり書きますが、このTane（種）では思ったことを気楽にどんどん書いていきます。

通常、ブログ記事などのエントリ一覧は平面に並ぶ。
見やすいが、暇つぶしにネットサーフィン（死語）をするときは案外微妙だったりする。

• 最近のやつのつもりで読んでたらめちゃ古いやんけ
• 同じような内容のやつを読みたいけど、どのタグ/カテゴリを見ればいいだろうか？

みたいな。

そこで、XY の 2軸で記事の意味的な近さを、Z 軸で時系列を表現してみる。

というのがこのページ。

X / Y は、記事本文を OpenAI の text-embedding-3-small でベクトル化して、それを UMAP で 2 次元に圧縮したものをプロットしている。
意味的に近い記事は埋め込み空間上で近いベクトルを持つので、2 次元に潰しても話題ごとにクラスタが自然と浮かび上がる、という仕掛け。結果として、類似の記事が近くに並ぶ。

Z（奥行き）は時系列。古いものほど後ろに行く。

ちなみに、しばらくは記事を追加するたびに結構位置が動くと思いますが許してください。
記事が増えてきたら安定するはず。

あとスマホ対応は追々。