成長プロジェクトにおける開発者の考え方

スタートアップや成長中のプロジェクトの開発者にとって、多くの技術を習得し、複雑で負荷の高いサービスを構築する方法を知っているだけでは十分ではないことがわかります。私はこれまでのキャリアで、多くの成長中のプロジェクトに関わり、ゼロから 2 つのスタートアップを立ち上げました。この記事では、開発中に何に焦点を当てるべきか、そして完璧主義が最高のアイデアさえも台無しにする理由について、私の経験を共有します。

ツールは手段であり、目的ではない

すべての開発者にとって、プロジェクトを単独で立ち上げるのは大変な挑戦です。すべてを完璧に行う必要があると感じるのはごく自然なことです。完璧主義への欲求は、ほとんどの場合、同僚が余分な「プリント」やパターンやツールを使用しないことで私を判断するのではないかという恐怖の反映であることに気づくまで、しばらく時間がかかりました。そして、実際のところ、本番サーバーがダウンし、クライアントが苦情を言い、私は解雇され、世界は終わりを迎えます。

あらゆるツール、パターン、プログラミング言語は単なるツールであり、目標ではありません。もっと頻繁に質問してください。なぜ今これが必要なのか。何を提供してくれるのか。どのメトリックが改善されるのか。たとえば、なぜ今リンターを設定するのか。なぜ今 CI/CD をカスタマイズするのか。1 日に 10 回デプロイメントを実行している場合は、おそらく必要です。リリースを週 1 回または月 1 回デプロイしている場合は、おそらく必要ありません。CI/CD のカスタマイズに多くの時間がかかり、開発をスピードアップしたり、プロジェクトや顧客に価値をもたらしたりしない場合は、今すぐ実装する必要がありますか。

個人的なプロジェクトでは、リポジトリとコードの構造を絶えず改善したり、パターンを試したりして、何か新しいことに挑戦するのは理にかなっています。この場合、私たちが実装するツールが目標です。実稼働プロジェクトの主な目標は、クライアントに価値を提供することです。クライアントは、私たちが一重引用符ではなく二重引用符を使用し、シングルトンを使用しており、ハードコードがないことに気付くことはありません。

リファクタリングは、開発速度とパフォーマンスの向上、バグの削減、バックログのブロック解除につながる場合にのみ必要です。

品質へのこだわりは、完璧主義への欲求ではなく、製品の目標を追求するものであるべきです。したがって、成長中のプロジェクトの開発者は決して完璧主義者ではないということを覚えておくことが重要です。

ビジネス価値を第一に

成長中のプロジェクトの開発者にとって、ビジネス価値を理解することは不可欠です。既成の仕様に従ってのみコードを書く一般的な開発者であることに慣れている場合、最初は難しいかもしれません。

製品が誕生したばかりのときは、ユーザーにとっての価値はまだ証明されていませんが、証明すべき価値は関係者の心の中に存在しています。この段階では、コードベースに不要なロジックを詰め込みすぎるというミスを犯す可能性があります。たとえば、注文ハンドラーを作成する必要があります。データベースに注文を格納するテーブルを 1 つ作成し、注文タイプを格納する 2 つ目のテーブルを作成しますが、まだタイプは 1 つしかありません。

ステークホルダーが、いつかこのロジックが必要になるかもしれないと主張したために、これを実行するとします。実際には、必要になることはないかもしれません。現時点で価値がないのであれば、不要なエンティティを生成しないでください。さらに重要なのは、そのためにビジネスの時間とお金を無駄にしないことです。

「利害関係者と議論するつもりか?」というもっともな疑問が湧くかもしれません。確かに、時にはそうなるでしょう。利害関係者は詳細な分析を期待しています。成長中のプロジェクトの特徴は、ほとんどの場合、リソース不足であるため、開発者は分析スキルを持っていなければなりません。製品の実現可能性は文字通りそれに依存するため、製品の機能の価値を常に検証する必要があります。

多岐にわたる業務に手を広げると、ビジネスのリソースが不足し、リポジトリがアーカイブ化されてしまいます。

たくさんの質問をしてください。「なぜ今この機能を実装するのか？この問題を今解決する必要があるのか？この問題はそもそも存在するのか？」これは、上で説明したテクノロジーの場合とまったく同じです。適切な質問をできることは、あなたのプロ意識を明らかにします。時間とビジネス リソースは、顧客に本当に価値をもたらすものにのみ費やす必要があります。

ハッカソンは、ビジネス価値を理解することが結果にどう影響するかを示す素晴らしい例です。限られた時間内に、明確に定義された問題に対する理想的ではないが実行可能なソリューションを提示する必要があります。開発者がプロジェクトに刺激を受け、なぜそれを行うのかを明確に理解していれば、2 日間でも良い結果が得られます。

計画はリスクに依存する

戦略ゲームを想像してください。木こりと新兵がいます。目標は戦士を作ることです。まず、木こりは木材を集めて兵舎を建て、新兵はそこで軍事訓練を受けます。木材を伐採するには、木こりはマップの未探索部分を通って森に到達する必要があります。マップから判断すると、森にはゲーム 1 日で到達でき、伐採には約半日かかり、兵舎の建設には 1 週間かかります。したがって、兵舎は約 10 日で出現します。

木こりが森にたどり着くまでにほぼ 1 日かかりましたが、突然川が道をふさいでしまいました。目標は変わります。反対側に渡るにはダム、橋、またはボートを建設する必要があります。あるいは、別の場所で森を探したほうがよいかもしれません。時期尚早な評価は戦略の崩壊につながります。偵察隊が最初に地図の未発見の部分を探索していれば、このリスクは回避できたでしょう。

経験豊富な開発者は、サードパーティのサービスとの統合、コードベースの拡張の複雑さなど、利害関係者には明らかではないリスクを認識しています。リスクを評価し、それについて警告するのは開発者の責任です。ほとんどの場合、利害関係者はこれらのリスクに気づいていませんが、利害関係者にとって重要な評価に影響を与えます。

タスクの例:サービスを支払いサービスと統合します。まず、支払いサービスをセットアップし、アクセスして、問題が発生する可能性のある場所を調査します。統合する前に、統合方法を理解します。開発に 2 ～ 3 週間かかった後で、支払いサービスが条件を変更したか、必要な機能のサポートを無効にしたために機能が予定どおりに完了しなかったり、統合が失敗したりしたことがわかった場合よりも、調査に 1 日を費やす方がよいでしょう。

リスクを解決した後は、作業を計画し、タスクにかかる時間を見積もる必要があります。私が使用しているフレームワークは次のとおりです。

• シナリオを書き込むか、ボード上で視覚化します。たとえば、ユーザーがボタンをクリックすると、ドキュメントがダウンロードされます。理解できるアプローチを選択してください。

• より技術的な観点からスクリプトがどのように機能するかを分析します。オプションが多ければ多いほど良いです。オプションを評価し、問題を最も迅速に解決できる、リスクを最小限に抑えたスケーラブルなソリューションを選択します。

• シナリオを、コード化する必要がある論理部分に分割します。

• 各部分を日数で見積もって、係数 1.11 を掛けます。これは私個人の魔法の係数で、10 月 11 日の私の誕生日です。もちろん、これは冗談です (冗談でなくてもかまいません)。私のアドバイスは、プロジェクトの範囲に応じて、見積もりに数日または数週間追加することです。私たちはできる限り多くのリスクを予測しようとしますが、予測できないものもあります。成功しないよりは、早く終わらせる方が得策です。

  
  

  大きめの見積もりを出すことを恐れないでください。利害関係者が「もっと早くできないのですか?」と尋ねたら、単に「いいえ」と答えるのではなく、その理由を説明してください。リスクについて説明し、シナリオを示し、例を挙げてください。利害関係者は、あなたが問題を分析したのであって、ただランダムに評価したのではないことを理解する必要があります。

重要な側面：あなたの心の状態もリスクとなります。休暇を計画し、モチベーションを維持し、燃え尽きないように心の健康に気を配ってください。それはあなたの責任です。

MVPは宇宙船ではない

「MVP をどうやって作成するか」という質問は、私のキャリア全体を通して私を悩ませてきました。単純に聞こえますが、それは「最小限の実行可能な製品」です。

Wikipedia の定義:

最小限の実行可能な製品 (MVP) とは、初期の顧客が使用できるだけの機能を備えた製品のバージョンであり、初期の顧客は将来の製品開発にフィードバックを提供できます。

MVP を構築する必要がある場合、途方もなく長い時間を要する宇宙船の建造のような結果になることがよくあります。MVP 段階での主な目標は、クライアントから迅速にフィードバックを得て、このフィードバックに基づいて、ステークホルダーと「まっすぐ進む」か「右折する」かについて合意することです。フィードバックを収集する最良の方法は、メトリクスです。メトリクスがなくても成功すれば素晴らしいですが、成功しなくても、少なくともその理由はわかります。

私の最初の MVP についてお話しします。UML 、デザイン パターン、ロードマップ、ストーリー ポイント、システム要件仕様、ADR、UI テストなど、多くのツールとフレームワークを見つけました。これらのフレームワークは大企業で使用されており、カンファレンス、講義、YouTube でそれらについて聞いたので、これらすべてを使用することに決めました。

このサービスの目的は、テスト実行に関するデータを保存することでした。1年間のロードマップをまとめ、 UMLで詳細なアーキテクチャを描き、バックエンドのフレームワークの選択に長い時間を費やし、Sentryでテストとログのシステムを構築し、想定していた10〜15人ではなく、多くのユーザーにかかる負荷を計算して、完璧なプロジェクトを作りたかったのです。

最初のバージョンは完成までに6か月かかりました。すべての打ち上げやグラフを見たり、レポートをダウンロードしたりすることはできましたが、データ収集に問題がありました。週に2、3回は壊れたレポートが表示され、サービスが使用できなくなりましたが、私は頑固に計画に従いました。

その後数年間、私はさまざまなプロジェクトに携わり、スタートアップを立ち上げようとしました。マーケティング、セールス、顧客の悩みについて学びました。この経験によって私の考え方が変わり、この記事で紹介するアプローチを開発することができました。最近のタスクについて説明し、実際にどのように機能したかを説明します。

私は、API メソッドを高速化する必要がありましたが、その遅さでユーザーを悩ませていました。計画では、モノリスから別のサービスにそれを移動することになっていましたが、内部サービスやデータ構造との統合が多数あるため、困難がありました。このプロジェクトは実験的なものであり、高速化が可能かどうかは誰にもわかりませんでした。

もちろん、すべてを書き直して完璧にすることを提案することもできます。私はモノリスと内部サービスを調査し、統合のリスクを調査することから始めました。次に、Miro で簡単な図を使用して戦略を作成し、すべてを反復に分解してから作業を開始しました。

時々、ステークホルダーが最初に知る統合に関する問題が発生しました。まず、私たちはそれらを解決しました。はい、プロジェクトにはまだ技術的な負債がありました。リンター、不完全なテスト、データベース内の古いスキーマなどですが、クライアントの問題は解決されました。

すべての反復が目標を達成し、4 回目の試行で 100% を達成しました。すべてを最初から書き直すには 10 回の反復が必要ですが、それよりも短い時間で、問題を解決するスケーラブルなサービスを実現できました。唯一の問題は、アプローチです。

成長中のプロジェクトにおける開発者のコード

• 完璧主義は捨てましょう。世の中には問題を解決するテクノロジーが溢れていますが、人々にとって役立つプロジェクトを作るためにすべてを知る必要はありません。

• 可能な場合は既製のソリューションを使用してください。

• ビジネス価値が第一です。ユーザーは製品を求めて来るのではなく、問題の解決策を求めて来ます。

• 最初からリスクを評価し、関係者に明確に伝えます。

• 短期的な計画を立てます。タスクが 2 年間バックログに残っている場合、ユーザーにはおそらくそのタスクは必要ありません。

• あらゆる可能な方法でフィードバックと指標を収集します。指標は成長ポイントを見つけるための信頼できる方法です。

• 最初から「適切な」エンジニアリング パターンが使用されていなくても、スケーラブルなソリューションを実現できます。