野心的なRailsプロジェクトを始めるための3つのアプローチ

先週は、先延ばしを克服して新しいRailsプロジェクトを実際に始めるための3つの習慣についてお話ししました。これで、目の前の作業量に圧倒されることは少なくなったはずです。しかし、まだ難しい決断が残っています。最初にどのコードを書けばよいのでしょうか?認証機能?Twilioと連携する部分?それとも、フォーラムの投稿レコメンダーエンジンには、そもそもどうやって取り掛かればいいのでしょう?

そう、いずれ実際にコードを書く必要があります。そのためには、スタート地点が必要なのです。

良いスタート地点とは何か?

まずは数分時間を取って、これから構築するシステムについて考えてみましょう。エンドツーエンドの処理の流れと、その流れがどんなリソースを必要とするかに焦点を当てます。ただし、深入りしすぎないこと!システムの全体像が少し見えてきたら、次のカテゴリに当てはまるパスを探してみてください。

1. プロジェクトの中核となる機能か?

ここでいう「プロジェクトの中核」とは、「あなたのアプリを30秒で説明して」と言われたときに語ることになるパスのことです。フォーラムソフトウェアを作っているなら、トピックへの投稿や返信が中核となります。プッシュ通知サービスなら、デバイスの登録と通知の送信が中心的なやり取りです。

中核となるやり取りは早めに実装するのがおすすめです。最小限の手間でアプリを動かして試せるようになり、新機能を構築するための確かな土台が手に入ります。そうすれば、次に取り組む作業もぐっと始めやすくなります。

2. 単体で完結する機能か?

新しいライブラリやAPIを学ばずに書ける機能を探してみましょう。ここから始めれば、コードから離れることなく作業でき、ドキュメントのウィンドウを行き来する必要もありません。「執筆モード」と「学習モード」を切り替える必要がないのです。中断を避けることは、すなわち先延ばしの機会を避けることでもあります。

朝一番に簡単なバグ修正を済ませて、「メール→Twitter→Reddit→メール」の無限ループに陥るのを防いだ経験はありませんか?それなら、適切なマインドセットで一日を始めることがどれほど重要か分かるはずです。これは、そのマインドセットに早く入り込み、そこにとどまり続けるための素晴らしい方法です。

3. リスクが高く、難しく、複雑に見える機能か?

こうした機能から着手するのは危険に思えるかもしれません。複雑な機能は通常、より多くの計画を必要とし、つまり行き詰まる機会も増えます。では、なぜこれが良いスタート地点になり得るのでしょうか?

開発者は興味深い問題を解くことに飢えています。難しい問題に挑戦することは、新しいプロジェクトへの着手を促す最も本質的なモチベーションにつながる方法なのです。さらに、高い難易度はフロー状態に入るチャンスも増やしてくれます。本当に良い成果が生まれるのは、まさにその瞬間なのです。

では、どれを選べばいいのか?

実は、どのアプローチを選んでも大きな差はありません!3つすべてが副次的なメリットを持つ優れたスタート地点であり、正しい方向を指し示してくれます。だから、1つ選んで(迷ったらランダムにでも)、試してみてください。

どのアプローチを選んだとしても、秘訣はTDDのフライホイール(勢いの輪)をできるだけ早く回し始めることです。その勢いが、リリースの日まであなたを運んでくれるでしょう。

新しいプロジェクトを始めるとき、これらのアプローチを使っていますか?それとも、自分なりの「最初の一歩」のお気に入りがありますか?ぜひコメントで教えてください!