- 行動そのものだけが実際の実行であり、考えたり準備したりすることは実行ではないと強調
- 計画、学習、議論、道具の購入などはすべて「やることをやる」ことではないと繰り返し指摘
- 失敗しながらでも、不器用でも直接試みる行為だけが本当の実行と見なされる
- 小さくても始めることが重要であり、完璧な準備や理想的な条件は不要
- 実際の行動に移す姿勢が創作と開発の核心であることを思い出させる文章
実行と非実行の区別
- 文章では「考えること、夢見ること、可視化すること、準備すること」などはすべて 「やることをやる」ことではないと列挙
- 例: 「考えること」「夢見ること」「成功を想像すること」「準備が整うまで待つこと」など
- 話したり、説明したり、議論したりする行為も実行とは見なされない
- 「他人に説明すること」「オンラインで議論すること」「始めると宣言すること」などが含まれる
準備と消費の落とし穴
- ポッドキャストを聞くこと、チュートリアルを見ること、他人の事例を読むことなどはすべて実行ではない
- 完璧なシステムを設計したり、道具を買ったり、作業スペースを片付けたりする行為も実行とは見なされない
- 罪悪感や忙しさに慰めを見いだす態度もまた実際の行動ではない
本当の実行の形
- 失敗しながらやること、不器用にやること、小さくてもやることはすべて「やることをやる」こととして認められる
- 文章の後半では「ブログを書くことさえ、やることをやることではない」と述べ、自己反省的な結論を示している
核心メッセージ
- 行動だけが本当の実行であり、それ以外のすべては実行の代替物ではない
- 小さくても始め、失敗を受け入れ、自分でやってみることが唯一の前進である
- 文章の最後の一文「では、また仕事に戻らなければ」は、即時に実行する姿勢を象徴している
2件のコメント
私のように実行力があまりない人たちには、いいフレーズですね。
Hacker Newsの意見
「下手でもやる」という原則が、自分の考え方を完全に変えた。
完璧なアーキテクチャを設計しようとして何週間も費やしたが、結局計画をやめて、自分の問題を解決する粗いバージョンを作った。
驚いたのは、その最初のバージョンが、計画だけでは絶対に学べないことを教えてくれた点だ。ユーザーが実際に重要視すること、実運用で重要なエッジケース、そして何が「十分に良い」のかを学べた。
一番難しいのは、欠陥があると分かっていながら公開を許すことだ。でも実際の利用から得られるフィードバックループは、何週間もの仮想的な議論よりはるかに価値があった。
最近は生産性系のサブレディットにこういう文章があふれている。個人用の自動化ツールを作るのに何週間もアーキテクチャを計画するというのが、現実的にあり得るのか疑問だ。
投稿者のコメント履歴を見ると似た文体が繰り返されていて、信頼しづらい。
その過程を見るのは本当に興味深かった。
実際に実装してリファクタリングする過程では、問題そのものやプログラミング全般について学ぶことが非常に多い。
最初に考えた抽象化はたいてい間違っている。実装していくと構造が完全に変わり、最終的には最初とはまったく違う美しいコードになる。
最初のバージョンは捨てるつもりで作れという話だが、実際にはたいてい捨てずに反復的に改善していく。
今ではツールとプロセスのおかげで、継続してiterate**できるようになった。
内部構造にも反復とプロトタイピングは必要だが、データ構造、エラー処理、ロギング、命名のような部分は、後で素早く改善できるよう初期に慎重に決めるべきだ。
「Doing it badly is doing the thing」という一文が気に入った。
HNで学んだ教訓だが、行き詰まったときは完璧にやろうと悩むのではなく、とにかくやってみるのが大事だ。
最初はひどくても少しずつ改善していけば、いつの間にか全体像が見えてくる。まるで魔法みたいだ。
1つはDan Harmonの writer’s blockに関する助言 で、
もう1つはIra Glassの 「The Gap」 だ。
要点は、完璧を待たずにひどい初稿でも書いて、それを批評家の目線で直していけということだ。
だから最近は、完成するまではわざと「まだできていない」と言うようにしている。
自分はまず素早く作り、それから磨き、最後に新しく書き直すというやり方をしている。
重要なのは、beta段階で完璧主義に陥らないことだ。
実際、段階的改善が効果的なら、人間かAIかは関係ない。
前の会社では、経営陣のことを**「問題感嘆協会」と呼んでいた。
問題を議論し、分析し、責任者を探すことにばかり熱中し、実際には解決しなかった。
結局重要なのは、「実際にやること」**だった。
最善のアプローチは、問題への関心と反復的に解決しようとする意志を両方持つことだ。
社内で実際に使うdogfoodingは、そのバランスを取る良い方法だ。
できる限り自分に有利な方向に決めることが重要だ。
更新のための調整が減り、実際に仕事をする組織のほうが効率的だ。
この記事は、strangestloop.ioのエッセイ と非常によく似ている。
タイトルを見て見覚えがあると思ったが、クリックしたら別のサイトで、投稿時期も数日前だったので驚いた。
内容があまりに似ていて、偶然とは思えない。
昔は準備が重要だと思っていたが、ある時点で準備が無限ループになることに気づいた。
うちのチームは2ページの仕様書で4か月で製品を完成させたが、競合チームは8か月間文書ばかり書いて解散した。
計画は20%でも80%の問題を潰せる。その先は不安を厳密さで包んだものにすぎない。
結局、恥ずかしいものを出して直しながら学んだことがほとんどだった。
以前のHNコメント で引用されていた。
Analysis paralysisは本当に存在する。
止まらないためには、とにかく始めるしかない。まずハッピーパスを処理し、あとでエッジケースを磨けばいい。
今はプロトタイプのコストが低いのだから、失敗を恐れず試すべきだ。
LLMが驚くほど効果的な理由もまさにここにある――分析の代わりに即座に実行するからだ。
結果が完璧でなくても十分使えることは多く、必要なら後で最適化すればいい。
フレームワークを作る前に、実際のシステムを最低3回は作ってみるべきだ。そうすれば、どこが過剰でどこが不足しているか分かる。
「十分よい」という言葉は自己欺瞞になりうる。
失敗したプロトタイプは市場がない証拠ではない。ただ何かが足りなかったというサインにすぎない。
この記事は、以前の投稿 とほぼ同じメッセージを伝えている。
以前のHN議論 でも扱われていた。
逆に、ときには**「doing the thing」自体が間違った選択であることもある。
だから自分は今でもデザインドキュメントとコードレビューを重視している。
GenAIの時代には「計画なしにとりあえずやってみる」があまりに簡単になったので、そのぶん釣り合いを取る重り**が必要だ。
非決定性やレイテンシの問題に時間を取られ、結局ユニットエコノミクスを成立させることが本当の課題になる。
『Remains of The Day』では、「the thingについて話すだけのこと」を自己満足的な行為と呼んでいる。
実際には何も成し遂げていないのに、気分だけよくなる会話で終わることが多い。
一方で、計画や準備、mise-en-placeは実行そのものを助けることがある。