- 大規模技術プロジェクトを進めるうえで、モチベーションを維持し最後までやり切るには、日々の目に見える成果が重要
- プロジェクトを大きく曖昧な単位ではなく、目に見える小さな単位に分割し、各段階で実際の進捗を確認できる方法を選ぶ
- 初期段階では、密なフィードバックループで素早くデモを作ることが、没頭と自己動機づけに大きく役立つ
- 自分のために必要な機能を中心に先に開発し、実際の利用を通じて継続的に改善していくやり方が効果的
- 完璧さより前進を重視し、小さく成功する体験を繰り返し確保することが、長いプロジェクトの完遂につながる
出発点で
- 大規模プロジェクトを始めるときの最大の山場は、どこから始めるかを決めること
- すべての構成要素を一度に考えると曖昧すぎて、興味を失いやすい
- 実際に早い結果が見える小さな単位から着手することが重要
- 各サブプロジェクトは独立しており、はっきりした完了の兆候を提供すべき
- 経験が多いほど、プロジェクトのおおよその全体像とサブコンポーネントをより把握しやすい
初期の成果を作る
- 初期作業は表に見える部分が少なく、進捗が見えないことがある
- こうしたときは、**自動化テスト（例: ユニットテスト）**を適切に活用して可視的な結果を得ることが重要
- たとえばターミナルパーサーを作るとき、入力文字列に対する解析結果をテストですぐ確認する
- 繰り返しテストが通る体験そのものが達成感を与える
- こうした小さな成功を通じて、プロジェクト全体の進行に対する客観的な証拠を継続的に積み上げられる
素早くデモを作る
- 初期目標は完璧なサブコンポーネントではなく、デモに十分な実装である
- 長期的に必要な複雑さ（例: データベース、高度なデータ構造など）はいったん後回しにし、シンプルな実装で素早く前進することを最優先にする
- **「完璧さは前進を妨げる敵になりうる」**ことを常に意識する
- 週に1〜2回、簡単なデモを作ることを目標にする
- 不完全なデモでも自分で確認しながら直感的なフィードバックを得られ、それがモチベーション維持に大きく寄与する
自分のための開発
- 特に個人プロジェクトでは、自分が必要とする機能から実装し、それを自ら採用して使ってみる過程を重視する
- 実際に使いながら不足点を体感し、本当に必要な機能に集中して改善することで、実際のユーザーの立場からプロジェクトを育てていく
- 使い始めの段階では不便さやバグが表面化するが、それが次にやるべきことを明確にしてくれる
- 自分で書いたソフトウェアを使う誇りが、プロジェクト継続を支える要因になる
- 最初は不要な機能（スクロール、マウス選択、タブなど）をすべて省く
プロジェクト全体をパッケージングする方法
- 問題全体を目に見える小さな問題に分割する。各問題は実際の結果を確認できなければならない
- 各小問題はデモ作成に十分なレベルまでだけ解決し、次の問題へ進む
- できるだけ早く動くデモを作り、その後で機能を反復的に追加する
- 優先して自分にとって意味のある機能を実装する
- 必要に応じて各コンポーネントを反復的に改善し、このプロセスを循環させる
結論
- 上記の方法によって、個人、グループ、仕事、学業などさまざまなプロジェクトで自分自身を動機づけながら最後までやり切れる
- デプロイやツーリングよりも、実際にどのようなやり方が継続的なモチベーション維持を可能にするかに焦点を当てる
- すべての人に同じ方法が合うわけではないが、目に見える進捗の成果が長期プロジェクト完遂の最大の力になる
- 自分の興味とモチベーションの仕組みを理解し、それに合った作業プロセスを構築することが重要
1件のコメント
Hacker Newsの意見
記事で示された意見にはすべて同意するが、1つ付け加えたいのは、速いフィードバックループの重要性だ。
変更を加えてすぐにその結果を見られると、本当にやる気が出る。
コードを遊び感覚でいじってその効果を観察していると、多くの問題が消えたり、簡単に解決できる形に変わったりするのを経験する。
巨大なプロジェクトでは、セットアップと実行がどれだけ簡単かと、プロジェクトの問題（バグ、納期遅れなど）の量には明らかな相関があった。
この講演はフィードバックループについて語っている。
YouTubeリンク
見つけたバグに対してe2eテストを適用して、確実に直ったか確認しようかと考えている。
何かを試したり直したりしたいときに、セットアップ自体に何時間もかかると、やる気が失われて結局先延ばしにしてしまう。
だからlispのように実用的なREPLがある言語が好きだ。
その場で結果を見られる即時的な満足感がある。
やる気を失った瞬間、そのプロジェクトは消えてしまう。
だから、開発そのものが楽しい経験になるようにすることが、ほとんど最重要の要素だ。
経験がむしろ邪魔になる部分だと思う。
シニアエンジニアが完璧なものを作ろうとして深く掘り下げたのに、いざデモをしようとすると成果物がいまいちなことをよく見る。
実装自体はよくできていても、機能や製品そのものが完全にいまいちなのだ。
たまには頭を空っぽにして、雑なコードをどんどん書きたくなる。
昔は遊びのプロジェクトをたくさん作っていて、すべてのソースコードを1つのファイルに放り込んだりもしていた。
モジュール化なんて気にしなくても楽しかったし、ちゃんと動いた。
でも今では、ちょっとした遊びのプロジェクト1つ完成させるのも本当に難しくなった。
一度やった経験があるせいで、不要な付加機能を全部入れたくなる傾向のことだと思う。
たとえばAdvent of Codeのようなコーディングチャレンジに参加すると、序盤の問題は簡単で、後半になって初めて最適化や複雑なアルゴリズムが必要になる。
あるいはpico-8のように制約のある環境では、長時間コーディングすることができない。
または、ハッカソンやゲームジャムのように時間制限のある環境でやってみるのも役に立つ。
経験の少ない人たちが、以前の言語でうんざりしていた「ベストプラクティス」をすべて忘れて自由に試せるからだ。
DBテーブルは自分で設計し、実装部分はLLMにある程度自由に任せる。
初期のサブプロジェクトの目的が「完成されたサブコンポーネント」を作ることではなく、次の段階に進めるだけの「十分に良い」サブコンポーネントを作ることだという点が印象的だった。
こういうやり方を実践するには、何かを「省略」しなければならないのだと気づいた。
他の人たちは、こういうモードではコードのモジュール化を無視すると言っていたが、私はコードをきれいに管理することがむしろ満足感とモチベーションを与えてくれる。
だから私は、アルゴリズム、データ構造、性能のような部分を「省略」するつもりだ。
結局のところ重要なのは、確かに何かは飛ばさなければならないが、その何かが自分に動機を与える要素なら省略してはいけない、ということだ。
デモは、ソフトウェアを開発すること（プログラミング）と文章で説明すること（ドキュメント化）の中間段階として機能してくれる。
デモを通じて、自分のプロジェクトが何をすべきかについての仮説を継続的に検証でき、一種のフィードバック機構にもなる。
デモは長く残るので、機能を壊したときにすぐ確認して修正する反復ループを続けられる。
個人的に開発しているゲームエンジンでも、このやり方で作業している。
デモ例のgithubリンク
こういうやり方が一般常識になってほしい。
個人プロジェクトに焦点が当たっている感じがする。
私は、大規模な技術系チームプロジェクトで全員が1つの目標に向かって働き、物事をきちんとやり遂げるための良い方法が知りたい。
15年近く働いてきたが、予算超過、納期遅延、機能不足、バーンアウトのない技術プロジェクトは見たことがない。
逆に、こうした大規模プロジェクトをうまく成功に導いた事例があるなら、追加で読めるリンクやおすすめ資料を共有してほしい。
予算超過は、本当に資金が尽きるのでない限り、よくあることだ。
たいていは、誰かが見積もりを間違えたと文句を言っているだけのレベルだ。
納期遅延も同じで、本当に絶対守るべき締め切りがあるのでなければ深刻な問題ではない。
実際、大きな宣伝キャンペーンなど日程連動のイベントは、プロジェクトがほぼ終わるまで計画しないほうがいい。
機能不足も結局は期待値の問題だ。
本当の問題は、「完全に消耗して人がバーンアウトすること」だ。
この点だけは、少なくとも確実に避けなければならない。
個人的には、Scaled Agile Frameworkにだんだん好感を持つようになった。
これをフレームワーク、つまり状況に応じて変形して使う一種の「かかし」として活用している。
そのおかげで、より深い原資料を探り、自分なりの結論を出せるようになった。
本当の成功は、「なぜこれを作るのかを明確に理解すること」から始まると学んだ。
目標が明確でなければ、優先順位もつけられないし、どこから始めるべきかもわからなくなる。
こうした明確さは、「何をいつ作るか」を決めるうえではるかに役立ち、ときには「そもそも作らない」という決断すら可能にしてくれる。
その次に重要なのは「共感力」だ。
顧客の立場に立って、彼らの問題をきちんと完全に理解し、解決策を提示しなければならない。
単に顧客の望むものを全部与えるのではなく、核心の痛みを正確に理解して、本当に価値のあるものを届けることだ。
ほとんどのプロジェクトが失敗する本当の理由は、チームが「間違ったもの」を作ることに時間をかけすぎるからだ。
人々が本当に望み、お金を払う価値がある、必要な機能に継続して集中すれば、もっと多くのプロジェクトが成功裏に完成するはずだ。
大きなプロジェクトを見て、分析麻痺に陥る人は本当に多い。
本当に難しいのは終わらせることだ。
自分で使うソフトウェアを作れば、自分の問題を自分で解決できる。
自分で使いながらソフトウェアのバグも見つけられる。
実際にWebサーバーを自作して使う中で、いろいろなバグを見つけた。
集中していて、反復的で、常に動く成果物を志向する開発文化だ。