Clever Geek Handbook

サーバーレス技術が製品管理の革命である理由

画像

サーバーレスアーキテクチャは、製品開発を制限する制限要因に根本的に影響します。



組織内のプロダクトマネージャーは、さまざまな役割を果たします。 「顧客の声」と呼ばれることもあれば、 「企業のキャットハザード」の役割を果たすこともあります。 彼らは太い兄弟であり、倫理や言い訳にもかかわらず、容赦なくあなたを製品の配達に導く人々です。 優れたプロダクトマネージャーがめったに誰かのアイドルになることはありませんが、そのような人々の仕事のおかげで、これまでに使用した技術的ソリューションのほとんどが具体化されています。



PMは常に、問題を解決するための最高品質のツールを探しています。 競合他社が常に足を踏み入れており、顧客が待つことにうんざりしていることを知っているので、私たちは常により賢く、より速く、より効率的に行動しなければなりません。 サーバーレス技術の出現により、それらが製品管理ウィッシュリストにどのように適合するかはすぐには明らかではありませんでした。 しかし、これらの技術を1年間使用した後、永遠に思われたソフトウェア開発の問題を解決することがわかりました。



パラドックス：チームの規模とパフォーマンス



製品管理の最初のルールは次のとおりです。実行する作業の量は常に増加しています。 バックログは膨らみ続け、たった1つの場合、つまり製品が排除された場合にゼロになります。 最も難しいのは、バックログの最も重要な要素を、すぐに出荷できる製品に変えることです。 他のすべての条件が等しい場合、次の関係を守る必要があると考えられています。



画像






1人の坑夫が1日に1トンの土壌をリサイクルできる場合、10人の坑夫が10トンをリサイクルできると想定されます。 原則として、企業のリソース管理はこの原則に基づいて構築されています。売上を増やしたい場合は、より多くの営業担当者を雇います。 ソフトウェアを開発するとき、バックログが大きくなると、単にチームを増やしたいという誘惑に駆られます。 ただし、複雑な製品やサービスを使用する場合、通常、次のスケジュールが時間の経過とともに発生します。



画像






スタハノフのペースで巨大なチームがどのように機能するかを見るのはまれです。 しかし、うらやましい不変の小さなチームが飛躍的に進歩することがよくあります。



多くのスタートアップにはこの種の間違いがあります。製品が成功するとすぐに、新しい開発者とマネージャーがスタッフに追加されます。 すぐに、速度が低下し始めることが突然判明しました。 問題は何ですか？ 最初の開発者はより才能があり、官僚主義は会社で成長し、アーキテクチャはどのように計画されましたか？



これらはすべて症状であり、問​​題の根本原因ではないと思います。 問題自体は3つの重要な要因の相互作用に帰着しますが、直接制御できるのはそのうちの2つだけです。





私は特に、存在の夜明けに、これらすべての要因が最適にバランスが取れていることに興味があります：壊れやすいものはなく、仕事の量は特に大きくありません（そして、通常は顧客に同意することができます）、そして複雑さは実質的にありません。 したがって、チームがGDPR準拠のサイトを作成する必要がある場合、この問題を調査する時間があり、すぐに決定が下され、チームはサイトが計画どおりに機能することを確認します。



大企業では、これらの要素が組み合わされてチームの規模が拡大し、実行される作業量が削減されます。 そのような企業でGDPR対応のウェブサイトを作成するには、弁護士の署名、マーケティング承認、取締役会レベルでのプロジェクトの承認、最も破壊的な実装のA / Bテスト、管理者チームとの開発中断の調整、他のチームが採用した展開計画との調整が必要になります-リストが続きます。 この量の制御とプロセスの数を使用しても、システム全体の脆弱性とエコシステム内の多くの未知の要因により、チームは成功する自信がはるかに低くなります。



この例を実際のプロジェクトのサイズに拡張すると、数十の機能と数百の変更が存在する可能性があり、これらの要因の影響により、「チームサイズ/作業量」の比率のグラフが最初から2番目にどのように変化するかを簡単に理解できます。 チームが成長するにつれて、組織の巨像をどのように追い抜こうとしても、単位時間あたりの作業量を減らす運命にあります。 またはそれはちょうどそうです-しかし、その後、何をすべきですか？



3つの要素すべてをハックする方法



この問題は長年私を悩ませてきたので、考えられる原因の研究に着手しました。 スタートアップでのみ可能ですか、急速な進歩は可能ですか？ しばらくの間、大企業での製品管理の困難に直面して、私はそう思っていました。 しかし、その後、3つの要因すべてを詳しく調べました。



脆弱性は常にあなたの不利益につながります。あらゆる規模のプロジェクトにおいて、技術的負債が増大し続けます。 状況は「逆に半減期」を連想させます。プログラムの要素は時間とともに成長し、このため（開発中）脆弱になり、これらはすべてコードの新しい行と複雑になります。



作業量は、製品の特定の機能（「Pay with Alexa」）ではなく、「前」と「後」の状態を比較すると、インフラストラクチャのアウトラインの違いに関連しています。 「後」が難しくなればなるほど、行われる作業の量が減ります。 そのため、多くの企業では、仕事を計画する際に、クライアントのニーズ（「Alexaで支払う」）から組織のニーズ（「Alexaで支払う」機能の実装に関わる人に会って話し合う）に重点が移ります。



複雑さは、適切な開発者の検索期間に直接影響する社会的、組織的、技術的要因の組み合わせであり、プログラマーを任意のジョブに割り当てることができるマルチタスクの人々として扱う能力です。 さらに、それは複雑さです-目に見えないままで、文書化されておらず、誤解されている可能性が非常に高い側面です。 開発者は自宅でReactアプリケーションを作成して自分でリリースすることができますが、組織では時間をかけるために追加の手順を数十回行う必要があり、ユーザーにとって興味深い機能はまったく変わりません。 プログラマはほとんどの時間をそれらに費やします。



これらの3つの要因が合わさって悪循環を形成するため、実行される作業量が減少し、脆弱性が増加し、開発者が完了できる機能が少なくなり、製品は目に見えない泥として複雑になりすぎます。 そのため、チームの成長は役に立たず、スピードとスピードは意識的に数字と指標を巧みに上げることによってのみ高めることができます。 古典的な症状：スプリントレポートでは、「会議開催」の位置が表示されます。



大企業では、このサイクルを破るために設計されたいくつかの欠陥のあるアプローチを観察する必要がありました。 1つ目は「大規模アジャイル」であり、特定の機能の開発に参加するすべての参加者が参加し、作業を調整しようとする大規模な会議が行われます。 したがって、作業を調整し、複雑さを理解してください。 このようなアプローチは、魅力的なランチを提供する配給会社には適していますが、私たちの場合はうまくいきません。 事実、優先プロジェクトのグループの規模が大きくなるにつれて、プロジェクトはますます増えますが、プロジェクト自体は減少します。 したがって、脆弱性と複雑さの問題を根本的に解決することはできません。 時間が経つにつれて、大規模なアジャイルは買い物リストに似た戦術的なタスクのリストを提供し、思慮深い機能から別の機能への全体的な道のようになります。



第二に、企業内の「イノベーショングループ」は、この作業が脆弱なマシンに根付き、構造全体がより良く変化することを期待して、周辺の変更をプッシュしようとすることがよくあります。 このアプローチは奇妙な副作用をもたらします。そのような「イノベーターのグループ」だけがプロセスを変更する権利を持っているという信念が統合されています。 したがって、同様の方法でも組織の複雑さの問題を解決できません。



何年にもわたるさまざまな失敗を見てきましたが、3つの要素すべてをハッキングして、実行される作業への複合的な影響を防ぎ、慣性に対処する必要があるという結論に達しました。





これらのアイデアを採用することに成功した場合、人類の歴史の中ですべてのソフトウェア製品を追求する岩から保護されます。 それは素晴らしいように聞こえますが、これをどのように達成できますか？



サーバーレス技術が限界を打ち破る



クラウドテクノロジーの出現により、重要なトレイルを新しい「ハッキングされた」状態に導くことができました。 一般に、クラウドの出現により、ソフトウェア製品を提供するプロセスはよりコンパクトになりました。プロバイダーがあなたのために多くの日常的なことを始めたからです。 クラウドが出現する前に、新しいユーザー機能を実装する必要がある場合は、サーバーを注文し、ラックに機器を設置し、データセンターにネットワークを敷設することに同意し、この機器をメンテナンスする必要がありました。 クラウドでは、これらすべてをレンタルできるため、数十個の組織アイテムを取り除き、月全体を節約できます。



さらに、データセンター内の機器をアップグレードする必要性を排除し、オンデマンドでハードウェアへのアクセスを提供することで、脆弱性と複雑さの両方を軽減します。 プログラムを使用することは、昔よりもはるかに簡単です。 ただし、時間の経過とともに、大規模な仮想インフラストラクチャを管理する負担が大幅に増加し、多くの時代遅れの配信方法は変わりません。 クラウドを使用すると、作業が遅くなり始める前にチームを大幅に増やすことができますが、何らかの方法で遅くなり始めます。



サーバーレステクノロジーは、このダイナミックを根本的に変えます。 サーバーレスアプリケーションは、チームによって記述された小さなコード（いわゆる「接着剤」）と、クラウドプロバイダーによって管理される機能的な「ブラックボックス」で構成されています。 ブラックボックスは単に構成を受け入れ、変更に反応します。 高品質のアーキテクチャを備えたアプリケーションでは、アプリケーションの操作に関連する運用作業の標準部分は、標準のブラックボックスに分類されます。 アプリケーション自体はもはやモノリシックな機能ではなく、機能とブラックボックスの連邦構造です。



実際には、これは上記の3つの要因に劇的に影響します。





非常に大規模なサーバーレスアプリケーションを管理する場合でも、プロダクトマネージャーは、加えられた変更の影響を受けたごく少数の要素を詳しく調べることが簡単です。 また、機能のフラグを配置することにより、2つのバージョンを簡単に競争力を持って起動できます。 さらに、通常、古いバージョンのコードを破壊する必要さえありません。



サーバーレスアプリケーションでは、インフラストラクチャは常に周辺に構築され、完全に管理されたサービスを組み合わせた必要最小限のコードのみを記述します。 運用上の観点からそれらについて考える必要はありません。 モノリスを制御したり、古いコードを整頓したり、鳥瞰図でシステム全体を表示したりするつもりはありません。



なぜそれが非常に重要なのか



変更のペースが変わると、プログラムが将来どのように見えるか、またはユーザーがあなたに何を望むかを予測することがますます難しくなります。 そのため、変更を加えても将来機能するように「何世紀にもわたって」コードを記述しようとすると、ますます無駄になります。 ほとんどの企業でコードの再利用がいかにひどく、レガシープラットフォームへの順守が進捗を遅らせるかを見てきました。



今では、古いシステムができる限り長く開発および保守されるように、すべての準備が整い、そのサポートがほぼ常にプログラマーから奪われ始めます。 その後、会社は新しいシステムで最初からやり直し、古いシステムで犯した間違いを繰り返さないことを厳soleに約束しました。 遅かれ早かれ3つの要因が新しいシステムを窒息させると、技術的な「森林火災」が発生し、その後再びすべてを新たに開始する必要があります。



私たちは複雑さの症状との戦いを開始しました。これが、非常に多くのパラダイムが行き来する理由であり、製品管理の歴史に大きな痕跡を残していません。 サーバーレス開発により、チームは複雑さの増加を最小限に抑え、数十年もソフトウェア開発の惨事であった古典的なtrapに陥ることなく、かなり均等なペースで価値ある製品を提供し続けることができます。



サーバーレスのパラダイムは開発され始めたばかりですが、すでに非常に有望なようです。 クライアントがこれまでにないような新しい機能を必要とするとき、製品マネージャーは最終的に、新しい機能の準備に基づいて正確に考えることができるプラットフォームを獲得できます。 このプロセスは、組織の複雑さを増すことによって妨げられることはなく、過度の脆弱性のために停止することもありません。


More articles:


All Articles