第56回の挑戦：「知識管理」システムが“走るジョーク”になったとき
正直に言います。私は「パーソナル知識管理システム」を作るのに1,847時間を費やしましたが、毎日使っているのは1日15分ほどです。効率0.05%ですね、みなさん。素直にただのノートを使っていれば、人生の1年半を節約できたはずです。
準備：AIの夢から String.Contains() へ
最初は壮大なビジョンから始めました。私の状況を理解し、記事をおすすめし、考えを“セカンドブレイン”のように整理してくれる、AIパワーの知識システムです。私はこう作りました：
// 私が必要だと思っていたもの：高度なAIによる知識管理
@Service
public class AdvancedKnowledgeService {
@Autowired
private SemanticSearchEngine semanticSearch; // クエリあたり47秒
@Autowired
private RecommendationEngine recommendation; // クリック率0.2%
@Autowired
private AIContentAnalyzer contentAnalyzer; // 90%のケースではやり過ぎ
public List<KnowledgeItem> findRelevant(String query) {
// 複雑なニューラルネットワーク処理
// ベクトル埋め込み
// 機械学習マジック
// 本番コード2000行以上
return semanticSearch.find(query);
}
}
で、実際に今なにを使ってるのか？
// 現実はこんなもの：持ち上げた文字列マッチング
@Service
public class SimpleKnowledgeService {
public List<KnowledgeItem> findRelevant(String query) {
// 実際に使われる、20行のコード
return knowledgeItems.stream()
.filter(item -> item.getTitle().contains(query.toLowerCase()) ||
item.getContent().contains(query.toLowerCase()))
.collect(Collectors.toList());
}
}
無慈悲な計算：56本の記事 vs 毎日の15分の利用
この“見事な失敗”を分解してみましょう：
- Dev.toの記事56本：「知識管理システム」を宣伝
- 実際のシステム利用84回（1記事あたり1.5回です！）
- 開発時間1,847時間
- 純ROI -112,090ドル
- 効率0.05%（誤植ではありません）
そして、夜も眠れなくなる皮肉がこれです。私は知識管理システム（56記事で705,000語以上）について書いた量のほうが、実際に使った回数（合計84回）より多いのです。
本当に得た「知識」
率直に言うと、このプロジェクトから学んだ中で最も価値があったのは、知識管理とは基本的に“期待値を管理すること”だという点です。私自身の期待値も、他のみんなの期待値も。
私のシステムの長所：
- 速い（最適化後：3〜7秒 → 50ms）
- 信頼できる（文字列マッチングは壊れない）
- シンプル（動くコード20行）
- 自分が何をしているのか理解できる
私のシステムの短所：
- 実は“インテリジェント”ではない（驚き！）
- 文脈を“理解”しない（さらに驚き！）
- Webインターフェース付きの強化されたgrepみたいなもの
- これに気づくまでに1,847時間かかった
本当のキモは？私はこの経験を何にも取り替えたくありません。なぜなら、“メタ宣伝パラドックス”が本当にあるからです。知識管理システムを作ろうとして見事に失敗したことで、ある意味で私は……そう、知識管理システムを作って失敗することの専門家になってしまったのです。
じゃあ「メタ」についての話をすると
今の私は、「情熱プロジェクト」がメタなジョークになってしまったという、妙な立場にいます。動かないシステムを宣伝していて、その宣伝の中身は「動かないシステムの作り方」なのに、人々は実際に読んでいます。
1,847時間かけて、ほとんど使わないものを作り、その失敗の仕方について56本の記事を書く。しかも、正直さを評価してくれる観客をなぜか見つけてしまう――この美しい皮肉には、なにか特別なものがあります。これは知識管理ではありません。パフォーマンスアートです。
本当に機能したもの vs 私が約束したもの
私が約束したこと： 思考と作業の仕方を一変させる、AIパワーの“セカンドブレイン”。
私が届けたもの： 基本的な文字列マッチングでテキストファイルを検索する、ほんの少し速い方法。
約束と現実のギャップ： 約1,847時間と112,090ドル。
でも率直なところ、単純なシステムは実際に機能します。複雑なほうは？ 使われない機能の寄せ集めで、存在しなかった問題への過剰設計の解決策、そして髪を引きちぎりたくなるような性能問題の数々でした。
本当に大変な形で学んだ教訓
シンプルは、いつだって複雑に勝つ。私の20行の文字列マッチャは、ユーザーが実際に必要としていることの95%をこなします。
ユーザーテストは、完璧なアーキテクチャに勝つ。 AIパワーの“全部”が必要だと決めつける代わりに、人に何が欲しいか聞いていれば1年は節約できたはずです。
宣伝は、実際の有用性に勝つ。私は、“動く”実システムよりも、失敗を語った記事のほうがより多くの反応を得ています。
メタは新しいメタだ。 （平凡な）成功の物語よりも、失敗の物語のほうが面白い。
効率は嘘をつかない。 0.05%——それは、情熱が実用性に勝ってしまったときに起こることだ。
インタラクティブな結末
さて、私はこの仕組みを動かそうとしてきた56回目の試行のすべてをさらけ出してきた。残された問いはこれだ：
どの時点で粘り強さが頑固さになるのか？「もう十分だ」と言って次のことに移るのは、いつだろう？
ただ……うまくいかないプロジェクトに、何百時間も注ぎ込んだ経験はある？ あなたは意地になって突き進んだのか、それとも損切りするタイミングを知っていたのか？ 「決して諦めない」と「やめるべきだと分かる」の境界線はどこにある？
コメントで教えてほしい。私は57本目の記事のためにメモを取っている。
P.S. はい、これは私の失敗したナレッジマネジメントシステムに関する56本目の記事です。いいえ、その皮肉は私にも見えていません。 ♂️
