ハクソク

世界を動かす技術を、日本語で。

プロジェクトを妨害する過剰思考、スコープクリープ、構造的差異分析

5時間前原文(kevinlynagh.com)

概要

  • Babashka ConfとDutch Clojure Daysへの参加告知
  • プロジェクトの進め方と成功基準の重要性の考察
  • スコープの肥大化とYAGNI原則の再認識
  • 構造的diffツールに関する調査と知見の共有
  • 学びと実践のバランスへの個人的な悩みと気づき

Babashka Conf・Dutch Clojure Days参加とプロジェクト進行の悩み

  • Babashka Conf（5月8日）、**Dutch Clojure Days（5月9日）**に参加予定
  • 参加者やAmsterdam滞在者との交流呼びかけ
  • プロジェクト着手時、2つの方向性に分かれる傾向
    • 即実行型：そのまま作り上げ、満足するパターン
    • 先行事例調査型：既存事例を調べてスコープ拡大に悩むパターン
  • 成功基準の明確化がプロジェクト満足度に直結
  • 最近の例：友人と木工プロジェクトを週末で完遂
    • 目的は「友人と木工を楽しむこと」
    • 必要以上に完成度や汎用性を求めず、体験重視で満足

スコープ肥大化とYAGNI原則の再認識

  • difftasticの精度不満から、構造/意味的diffツールを調査
  • 既存ツール調査に数時間消費し、目的を見失いかける
  • 最終的に「Emacs用の自分向けdiffワークフロー」という最小目標に立ち返る
  • **YAGNI（You Ain't Gonna Need It）**原則の再理解
    • LLMでFinda風ファイル検索を実装→余計な機能追加で複雑化
    • 本当に必要な機能だけに絞ることで、満足度と効率を両立

長期的な興味と学びのジレンマ

  • ハードウェアプロトタイピング用UI
  • ClojureとRustの良さを融合した言語
  • CAD向け言語設計
    • いずれもリサーチや試作に多大な時間を投入
    • 成果物に至らず、知識習得だけが進行
    • 成功基準が曖昧なため、満足感が得にくい
  • 「やってみる」ことの価値を再認識
    • 失敗や未完成でも、実践が学びや充実感に直結

構造的diffツール調査まとめ

  • 従来のdiff：行単位での差分表示（+/-記号等）
  • 問題点：関数や型などの高次構造を認識できない
  • difftastic：treesitterベースで構造的diffを実現
    • ただし、エンティティのマッチング精度に課題
  • semanticdiff.com：VSCodeプラグイン・Webアプリで高精度なsemantic diffを提供
    • コードライブラリの提供は無し
  • diffsitter：treesitter利用、MCPサーバー必須
  • Gumtree：Java依存、アルゴリズムの高速性と精度の課題
  • mergiraf/weave：Rust製、treesitterベースのマージドライバ
    • Gumtreeアルゴリズムや独自工夫あり
  • diffast：ASTのツリー編集距離計算（Python/Java/Verilog/Fortran/C/C++対応）
  • autochrome：Clojure向け、動的計画法によるdiff
  • Tristan Humeの記事：ツリーディフアルゴリズム設計の詳細解説
  • 主な用途：LLM生成コードのターンごとのレビュー用

学びと実践のバランスへの気づき

  • 考えすぎず、手を動かすことの重要性
  • スコープを絞り、「まずやってみる」姿勢の再評価
  • 失敗や未完成でも、実践が最良の学びにつながるという実感

Hackerたちの意見

面白い読み物だけど、著者の考えがバラバラだったね。
└
自分の考えを教えてもらいたいって言ってるようなもんだね。
└
ここで言えるのは、範囲の広がりについてだね。
└
これは特定のテーマに焦点を当てたブログ記事じゃなくて、その人をフォローしている人向けのニュースレターの更新だね。
ちなみに、これが博士課程の研究の大変さを表してると思う。興味のあるテーマを選んで、それに関連する文献を全部読まなきゃいけないから、どんどん範囲が広がっちゃうんだよね。最初のエネルギーやワクワク感が尽きた後、残りの20〜30%を無理やり進めて、出版できる状態に持っていかなきゃならない。
└
それ、めっちゃわかる。これを軽減するアドバイスある？
└
1日目：商業利用されていない新しい応用において、既存の工業触媒の効果を示すことを目指す。これにより、必要な医薬品の前駆体の生産コストを下げる可能性がある。400日目：すべてのものの普遍的な理論を徹底的に説明した後、既知の宇宙のすべての観測可能な力の媒介となる普遍的な粒子を検出できる実験装置をラグランジュポイントの軌道に構築することを目指す。
└
> 興味のあるトピックを選んで、それに関連するすべての研究を読む必要がある これは研究プロジェクトの進め方としては間違ってると思うし、こんな風にアプローチする人はほとんど見たことがない。2本か多くても3本の論文を読んで、それを基に進めるべきだよ。研究文献の深いレビューは、プロジェクトの後半で結果が出てきてから始めるべきなんだ。
└
大多数の博士課程の候補者はこれに悩まされる。博士号の目的は「通常の科学」を証明することで、要するに「このシステムを1%観測可能から1.001%観測可能にするにはどうするか」ってことなんだ。これは学術キャリアにいるためのゲートみたいなもので、特に面白いとか新しい、科学に直接適用できるような博士論文はほとんど見ないよ。[1] https://en.wikipedia.org/wiki/Normal_science
著者が言いたいのは、人間は本質的に賢くて、似たようなアイデアを考えがちだってことだと思う。だから、知らず知らずのうちに他のプロジェクトの複製になっちゃうか、先にリサーチして部分的に複製だと気づいてがっかりするかのどっちかなんだよね。解決策は、自分の学びのためにプロジェクトを完成させることが一番大事だって気づくことかもしれない。（これは新しい学術研究を完成させようとする時や、自分のユニークなプロジェクトで利益を上げようとする時には言うは易しなんだけど。）でも、既存のものを少しだけ改良する研究にも、十分な理解があると思うよ。
計画過剰やスコープクリープは問題だけど、逆に振りすぎるのも良くないよね。成功したプロジェクトの中には、データをモデル化する過程で、動作するソフトウェアがない状態でほとんどの機能を事前に計画して進めたものもある。あのフェーズにいると、どれくらいが多すぎるのかよく分からないんだよね。自分やユーザーが欲しがる機能を省いちゃうと、コードのコア部分を大幅に再設計する羽目になる。もし間違えたら、プロジェクトが大きくなりすぎてスコープクリープになっちゃう。これをうまくやるためには、どれだけその分野を知っているかが重要だと思う。自分が思っているほどその分野を知らないと、再作業が多くなるし、逆に知識が豊富だと、もっとスムーズに進められるのに、無駄な手間をかけちゃうことになる。これって大きな判断が必要で、どちらに転んでも「後悔」があるんだよね。
└
間違えることを心配しすぎだよ。とにかく何かやってみて、必要に応じて調整すればいいんだ。
└
理想的な解決策は、分析フェーズにたっぷり時間をかけて正しいコンテキストを頭に詰め込むことだけど、その後は過剰に設計された解決策を捨てて、直感に従って作る準備をすることだと思う。埋没費用の誤謬に陥らないようにね。たとえ博士号レベルのトピックを何時間も調査したとしても、それがプロジェクトに適さないなら、使う必要はないんだから。
Rec RoomのCEOが言ってたことがすごく好きなんだけど、「チームはいつも短いプロジェクトをやりたいって言ってる。『もっと複雑なことをやって、リリースを遅らせたかった』なんて言うチームはほとんど聞いたことがない。」100%の状況に当てはまるわけじゃないけど、どちらかに間違えるなら、小さいことを早めにリリースする方がいいと思う。
オバマがスピーチで「より良いことは良いことだ」と言ってたのをよく考える。時間が経つにつれて、より良いことが積み重なっていく感じがする。小さな改善が大きな成果につながる。経験上、新しいことは最初から完璧じゃないから、完璧なデザインを考え続けるのは逆効果だよ。「行動の障害は行動を促進する。障害物が道となる。」
└
オバマ - 生きている時代って最高だね。
サボタージュは意図的だけど、問題は意図しない逸脱で、これはどんな調査でも起こりうること。真の問題は回避で、必要なカットを避けたくて、他のことに一生懸命取り組んで隠れちゃうこと。解決策は、自分の時間を大切にすること。ほとんどの人はそうしないから、（自己）マネージャーは他の機会を提示する必要がある。「これを終わらせたらあれができるよ。」赤ちゃんからお菓子を奪うのは大変だから、代わりに何かを交換するんだ。
今、まさにこの状況にいるんだ。サイドプロジェクトで、あまり経験のない分野（情報検索）に取り組んでる。だから、学べる先行研究がたくさんあるし、統合することもできる。この記事を読んで、もっと自分のものを作ることに集中して、行き詰まった時やアイデアが必要な時に先行研究を覗くことが大事だなって思った。最近、Clojureのドキュメンタリーが出たけど、Rich Hickeyのアプローチは真逆っぽかった。長い時間をかけて先行研究や論文、他の言語を深く研究してた。でも、彼も以前に他の言語を作ったことがあるって言ってたから、実際にはもっと前から物を作って学ぶっていう大きなストーリーがあるんだよね。多分、これが大きな教訓かも：考えすぎずに、まずは作り始めること。だけど、実践からいろいろ学んで、壁にぶつかったりしたら、さらに深い研究が必要になるかもしれないね。
└
[遅延]
締切を設定することで、ほとんどのスコープクリープの問題が解決できるって気づいた。経験上、ゲームジャムやプログラミングコンテスト（厳しい締切がある）でプロジェクトを完成させる可能性が、オープンエンドのプロジェクトを終わらせるより高いんだよね。「C++の標準が3年ごとに出る理由」も参考にしてみて：https://news.ycombinator.com/item?id=20428703 (2019-07-13, 220コメント)
私の答えは、#1と#2の両方だね。少数の時間でプロトタイプを作って、大多数の時間は研究する。ある時点で、その比率が逆転して、研究が減って生産が増えていくんだ。