完璧主義と肥大化がプロジェクトを殺す！技術的負債を生まないための「引き算」思考

「完璧に作り上げたい」という過度な思考、終わりのないスコープクリープ（機能の肥大化）、そして無意味な構造の微調整。これら全てが、あなたのプロジェクトを自滅させる最大の要因です。エンジニアとして最高の仕事をするためには、時にブレーキをかける勇気も必要ではないでしょうか。

興味深い記事だけど、著者の考えがまとまりきっていない感じがするな。

偶然だけど、これって博士課程の研究の最大の難しさを言い当てている気がする。興味のあるトピックを選んで関連文献を片っ端から読んでいくと、やろうとしていることが既に先人たちによってどれだけ網羅されているか気づいてしまって、どんどんスコープが広がっちゃうんだよね。プロジェクトに対する最初の熱意や興奮が冷めきった状態で、残りの20～30％を気力で押し切って論文として発表できる状態まで持っていかなきゃならない。

著者は結局のところ、人間は本質的に知的で、似たようなアイデアを思いつきやすいってことを言いたいんじゃないかな。だから、無意識のうちに誰かのプロジェクトの焼き直しのようなものを作ってしまうか、あるいは先にリサーチして「あ、これ一部被ってるわ」と気づいてガッカリするかの二択になりがちだ。解決策としては、自分自身の学習のためにプロジェクトを完結させることが一番大事だと割り切ることかもしれないね。（学術的に新しい研究をしようとしたり、独自のプロジェクトで利益を出そうとしている時には口で言うほど簡単じゃないけど）。ただ、そういった分野でも、既存のものに少し手を加えた程度の研究に対しては、意外と寛容なものだよ。

Rec RoomのCEOが言っていた、すごく共感できる考え方を紹介するよ。「チームから『プロジェクトをもっと短くすればよかった』という声はよく聞くけど、『リリースを遅らせて、もっと複雑に、もっと磨きをかければよかった』なんて言うチームはほとんど聞いたことがない」。100％正しいとは言わないけど、どっちかに失敗するなら、後で大きく修正して時間を浪費するより、小さく作って早めにリリースする方がマシだと思う。

オバマが大統領の演説で「Better is good（より良くなることは良いことだ）」と言っていたのをよく思い出す。改善って積み重なるものなんだよね。小さな改善の積み重ねこそが重要。経験上、どんな新しいものでも最初から完璧なんてことはあり得ないから、完璧なデザインを求めて足踏みするのは逆効果。そんなもの存在しないんだから。「行動への障害こそが行動を前進させる。立ちはだかる壁こそが道となる」ってやつだね。

今まさにサイドプロジェクトで全く同じ状況に陥ってる。経験が浅い分野（情報検索）だから、学べる先行事例がたくさんあるし、なんなら統合できそうなものもある。この記事を読んで、まずは自分で作ってみて、行き詰まった時やアイデアが欲しい時に先行事例を覗くっていうスタイルで進めていこうと改めて思った。最近出たClojureのドキュメンタリーで、Rich Hickeyは真逆のアプローチをとっていたのが印象的だったな。長い時間をかけて先行事例や論文、他の言語を深くリサーチしていたから。でも彼も、それ以前に別の言語を作った経験があるからこそなんだよね。物語はもっと前から、実際に作って実践から学ぶことで始まっている。結局のところ、「難しく考えすぎず、まずは作る」ことが大事で、壁にぶつかったり実践的な知見が溜まってから深いリサーチに戻るのがいいのかもしれない。

スコープクリープの問題は期限を設けるだけで大体解決するよ。個人的な経験だけど、オープンエンドなプロジェクトより、ゲームジャムやプログラミングコンテストみたいに厳しい期限があるものの方が最後までやり遂げられる確率が格段に高い。参考までに、「なぜC++の標準仕様は機能が完成してからではなく、3年ごとにリリースされるのか」についての議論も貼っておくよ。

スコープクリープに悩まされているなんて言いつつ、記事の最後にはあらゆるトピックへのリンクが貼られていて、めちゃくちゃこなしてるじゃないか。著者は本当に学ぶことや色々なことに手を出すのが好きなんだろうね。あちこちに脱線して深掘りすること自体が、脳を刺激する楽しみの一部なんだと思うよ。

同じゲームでも攻略法は人それぞれだよね。何も考えずにボタンを連打して突き進みたい時もあれば、あえてステルスで慎重に最適なルートを探して、5分で連打クリアできるステージに1時間以上かけちゃう時もある。どっちもアリだ。

これ、組織を内側からサボタージュするのにも最適なやり方だよね。CIAの単純な現場サボタージュマニュアルにもこの手法が載っているよ。