大規模技術プロジェクトの構築に対する私のアプローチ (2023)

228日前原文(mitchellh.com)

概要

大規模な技術プロジェクトの モチベーション維持 方法を解説
小さな成果 を積み重ねて進捗を可視化する重要性
デモ作成 を目標にタスクを細分化する手法
自己利用 を意識した開発のすすめ
継続的な改善と反復作業の実践例

大規模技術プロジェクトを完遂するためのモチベーション管理術

新規プロジェクトや大規模リファクタリングなど、 大きな技術的課題 でのモチベーション維持の難しさ
目に見える成果 を重視し、作業順序を工夫するアプローチ
プロジェクト開始直後の 高揚感 と、徐々に失われる集中力への対策
成果が見える小さなタスク に分解し、達成感を得ながら進める重要性
エンジニア全般に有効な方法として、 自分自身へのデモ を作ることの推奨
本記事は個人の経験則であり、 新規性や独自性を主張しない 立場
例として Terminal Emulatorプロジェクト を題材に具体的な進め方を紹介

スタートライン：最初の一歩の切り方

大規模プロジェクト の開始時は、どこから手を付けるかが最も難しい課題
端末エミュレータの場合、 端末パーシング・シェルプロセス管理・フォント描画・グリッド描画・入力処理 など多岐にわたる要素
「Neovimが動くターミナルを作る」などの 巨大な目標設定はNG
目に見える成果がすぐ得られる サブプロジェクト を選定することが重要
- VTパーシング（端末エスケープシーケンスの解析）
- 空ウィンドウ描画（ウィンドウを開き空キャンバスを描画）
- 子プロセス起動（シェル起動とTTY設定・出力取得）
全ての要素を最初に洗い出す必要はなく、 経験値が高いほどプロジェクトの輪郭を早く掴める
未経験分野では 試行錯誤や作業のやり直し も想定内

早期成果の重要性

初期作業は 目に見える成果が少なく、進捗を実感しにくい
バックエンド先行の場合、 自動テスト （ユニットテスト等）で動作確認するのが有効
グラフィカルでないタスク は特に、テストで成果を可視化することがモチベーション維持に直結
Terminal Emulatorでは VTパーシング を最初に選択し、 テストケースの増加 で進捗を実感
「テスト1件成功」「テスト4件成功」など、 小さな成功体験の積み重ね

デモ作成までのスプリント

初期サブプロジェクトの目的は 完成度よりデモ実現 を優先
完璧主義を捨て、 必要最低限の実装 で次のステップへ進む
将来的な拡張性や最適化 は一旦脇に置き、まずは動くデモを目指す
週1～2回のペースで デモ作成 と 自動テスト を交互に行う
デモを作ることで 製品としての手応えや課題 を早期発見
Terminal Emulatorの例では、 CLIでのASCII描画 を初期デモとし、実際に動く様子を確認
長期的には不要なコードでも、 短期的な達成感や進捗の可視化 がモチベーション維持に有効

自分のために作る

個人プロジェクト では「自分が使いたいもの」を最短で作る意識が重要
自分自身がユーザー となることで、必要な機能だけに集中
Terminal Emulatorでは、 fishシェル設定の読込・Neovimの起動 に必要な機能だけを優先実装
- 例：最初は スクロール・マウス選択・検索・タブ機能 などを省略
実際に日常利用しながら 不足機能やバグ を洗い出し、次のタスクへ反映
自作ソフトを使う誇り が継続的なモチベーションにつながる

パッケージ化と反復

大きな課題を小さな問題に分解 し、それぞれで成果が見えるように設計
小さな問題ごとに デモやテスト で進捗確認、次の課題へ進む
頻繁なデモ作成 で自己フィードバックを得る
自己利用を意識した機能優先 で開発を進める
必要に応じて各コンポーネントを 繰り返し改善

結論

本手法は 個人・グループ・業務・学業 など様々なプロジェクトで有効
リリースやツール選定 にはこだわらず、どんな環境でも適用可能な個人プロセス
各自が 自分に合ったモチベーション維持法 を見つけることが大切
成果が見えること が自分のモチベーション源であり、このスタイルが長年有効だった実体験

備考

自分が使いたいプロダクトを開発する企業で働く ことを重視した個人的選択
学習方法はリファレンスマニュアルの精読が好みだが、 開発スタイルは真逆 という皮肉

Hackerたちの意見

以前の記事: 大規模な技術プロジェクトの構築に関する私のアプローチ - https://news.ycombinator.com/item?id=36161397 - 2023年6月（コメント27件）

ミッチェルにはすごくリスペクトしてる。彼が成し遂げたことは本当に印象的だよね。この記事のポイントには全部同意するけど、一つ追加したいことがある。素早いフィードバックループを持つこと。自分にとっては、変更を加えてすぐに結果が見えるのがすごくモチベーションになる。ソースコードを遊び感覚で修正して、その効果を観察すると、多くの問題が消えたり、解決可能な形になるんだよね。

└

時間があれば、ブレット・ビクターの「原則に基づく発明」というトークをぜひ見てみて。フィードバックループについて話してるよ。https://www.youtube.com/watch?v=PUv66718DII

└

テストケースはここで役立つと思う？見つけたバグにe2eテストを適用しようか考えてるんだけど、それで修正されたか確認できるから。

└

これ、私の経験と完全に一致してる。私が関わった大規模プロジェクトは、セットアップや実行のしやすさと、バグや納期遅れといった問題の数との間に明確な相関関係があった。

これがアジャイルの理想の姿だと思う。集中して、反復的で、常に機能している。

私にとっては、まず始めることが一番の方法だね。多くの人が大きなプロジェクトを見て、分析麻痺に陥っちゃうんだ。

└

ああ、始めるのは簡単だよ。難しいのは終わらせること。

「これは経験が実際には足かせになる分野だと思う。シニアエンジニアが完璧なものを作ろうとして足止めされて、デモをする頃にはそれがダメだと気づくことがある。実装自体は悪くないけど、製品や機能そのものが実際にはダメなんだ。」これ、すごく共感できる。たまには「脳をオフに」して、クソみたいなコードを書きたくなることもある。昔はたくさんのおもちゃプロジェクトを作ったな。ソースコードが一つのファイルに全部入ってたりして、モジュラリティなんて全く無視してた。でも楽しかったし、ちゃんと動いてた。今はおもちゃプロジェクトを完成させるのが、以前よりずっと難しく感じる。

└

これが新しい言語が早い段階で盛り上がる理由だと思う。経験の浅い人たちが、古い言語の退屈な「ベストプラクティス」を全部置いていけるからね。

└

これって「第二のシステム問題」って呼ばれるやつじゃない？前にやったことがあると、いろんな機能が必要だと思っちゃうよね。

└

練習できると思うよ。コーディングの演習をやってみて。例えば、Advent of Codeがまたやってくるし、後半の問題は最適化や賢いアルゴリズムが必要になることが多いよね（…私はそこまで行けなかったけど）。それか、pico-8みたいな制約のある環境でやるとか。ハッカソンやゲームジャムみたいに時間制限があるのもいいかも。

└

LLM（Cursor）は、私にとってこの問題をほぼ解決してくれたよ。DBテーブルは手動で設計して、実装はある程度自由にやらせてる。

いい記事だったけど、タイトルから期待してたのとはちょっと違ったな。彼のアプローチは個人プロジェクトに関するものみたい。大きな技術チームのプロジェクトについてもすごく興味があるんだけど、どうやってみんなが同じ目標に向かって進むようにするのがベストなんだろう？ 15年経っても、予算オーバー、時間オーバー、期待外れ、燃え尽きたプロジェクトを見たことがない。大規模なプロジェクトをうまく進める方法を知ってる人がいるはず。リンクやおすすめの本があれば教えてほしい！

└

予算オーバー、時間オーバー、期待外れぶっちゃけ、これらは俺的には問題ないよ。「予算オーバー」は本当にお金がない場合だけ問題で、ITプロジェクトではかなり珍しいと思う。大体は誰かが見積もりが外れたって文句言ってるだけ。「時間オーバー」も同じで、実際の締切があったら問題だけど、ベストプラクティスは、ほぼ完成する前に柔軟性のないイベント（例えば、日付付きの大規模PRキャンペーン）を計画しないことだよ。「期待外れ」は期待の問題で、実際に納品されたことが重要なんだ。 > 燃え尽きた人たち。これは他とは違うね。人はくだらない締切で燃え尽きるべきじゃない。

投稿をすごく楽しんでる、シェアしてくれてありがとう。 > 早い段階のサブプロジェクトの目標は、完成したサブコンポーネントを作ることじゃなくて、デモに向けて次のことに進むために十分なサブコンポーネントを作ることなんだ。これはすごく啓発的だね。そして、これをするためには何かを「スキップ」しなきゃいけないことに気づいた。他の人たちは、これをやるときにコードのモジュール性を無視するって言ってるけど、俺はそうはしないつもり。コードをきれいに保って、そういうコードベースで読み書きするのが実際に満足感とモチベーションを与えてくれるから。俺の場合は、アルゴリズム、データ構造、パフォーマンスを「スキップ」するつもり。だから、ここでのポイントは、何かをスキップすべきだけど、もしそれがモチベーションになるなら、スキップしない方がいいってことかな？

面白い考慮点は、選んだモジュール化のアプローチが新しい貢献者のオンボーディング時間にどう影響するかってことだね。よく構成された分解は、初期の開発スピードを助けるだけじゃなくて、将来のチームメンバーや外部のコラボレーターの立ち上がりの摩擦を減らすことにもつながるかもしれない。これはソロで進めるプロジェクトではしばしば過小評価される重要な要素だよ。

//大きな問題を小さな問題に分解する。デモに進むために小さな問題を解決するだけでいい... ...その後、より多くの機能を反復していく。できるだけ頻繁にデモを作る。自分のソフトウェアを採用するために必要な機能を優先する。将来の改善のために各コンポーネントを必要に応じて反復する// つまり、我々が持っているのは：経験的プロセス管理、自己組織化、コラボレーション、価値に基づく優先順位付け、タイムボックス、反復開発だね。これはただのソロSCRUMなのか、それとも何か見落としてるのかな？

私にとって最高のデモは、テストモジュールが全部緑に光ることだね。これをどうやって経営陣にアピールするセクシーな画像にするかが問題。確かにビジネスロジックはまだ未完成だけど、私が丁寧に作った強い型のインターフェースが全部うまく組み合わさってるんだ！未来の配当を想像してみて！

ハクソク