CTOチャット:開発者エクスペリエンスのギャップを克服する(feat. RedMonk & Flow.io)

組織が従業員にポジティブな体験を提供することに集中すべきだという考えは、新しいものではありません。 これは当然ソフトウェア開発チームにも当てはまりますが、組織はどのようにして開発者が権限を与えられていると感じ、ビジネス目標をサポートするために最高の仕事をするための適切なツール、プロセス、リソースを確保できるでしょうか。

レッドモンク プリンシパルアナリスト兼共同創設者のStephen O'Gradyは、Docker CTO、Justin Cormack、 Flow.ioの CTO の Mike Bryzek が、優れた開発者エクスペリエンスを構築する上で成功したアプローチと教訓について語ります。 以下の 彼らの会話の完全な17分間の記録 をチェックして、ハイライトをキャッチするために読み続けてください。

開発者エクスペリエンスのギャップとは何ですか?

会話の中で、Stephen は今日を「ツールの黄金時代」と表現しており、開発者は、そこから引き出して構築できるライブラリ、サービス、オープンソース プロジェクトが無限にあるように見えます。 この豊富な選択肢が、Stephen が "開発者エクスペリエンスのギャップ" と呼ぶものを生み出すため、これは両刃の剣になる可能性があります。

ギャップは、組織がこれらのツールを調達、比較、評価、および実装するために開発者に課す膨大な量のオーバーヘッドによって形成されます。 そのオーバーヘッドに加えて、これらのサービスは開発チームによって維持および保護される必要があります。 実際には、これは、開発者がツールを使用して革新するのではなく、ツールの管理に多くの時間を費やす必要があることを意味します。 秘訣は、自由と標準化のバランスを見つけることです。 Mike と Justin が指摘しているように、そのバランスを見つけることで、より良い開発者エクスペリエンスを生み出し、ビジネスへの影響を高めることができます。

開発者エクスペリエンスのギャップを生み出すものは何ですか?

開発者エクスペリエンスのギャップは、どこからともなく生まれたわけではありません。 多くの企業にとって、開発者により多くの速度を与え、代理店をより早く出荷した結果、これは自然な進歩です。 良い例は、ギルトグループでのマイクの経験です。 2007年、マイクはオンライン小売グループの共同創設者兼CTOでした。 当時、Gilt は典型的な QA、開発、製品、インフラストラクチャの各チームを持つ従来のソフトウェア開発組織でした。 しかし、数年後、Gilt は成長の痛みを経験し、ビジネスの優先順位が絶えず変化し、エンジニアリングプロセスが遅いため、製品を提供できませんでした。 QAプロセスには多数の手動テストが含まれていましたが、リリースはモノリシックで数時間かかりました。 さらに、新しい機能や製品の変更が製品の他の部分に影響を与えていたため、組織内でほぼ麻痺し、Gilt は絶え間ない解約期間に置かれました。

解決策は、チームが互いに独立して動く方法を見つけることでした。 ギルトはまた、人々が適切な決定を下すことを信頼され、ビジネスに与える影響について責任を負う組織になりたいと考えていました。

Docker を使用した継続的デリバリーによって速度を向上させる方法

その信頼と独立性を構築するために、Gilt は継続的デリバリーに投資することを決定しました。 しかし、この移行は容易ではありませんでした。 開発者が安全に本番環境にリリースできると確信できる反復可能なビルドが得られるようになるまでに約1年半かかりました。 Mike にとって、Docker はこの移行を可能にする大きな役割を果たし、Gilt がマルチサービスデプロイメントを採用できるようにしました。

「[Docker]は、インフラストラクチャや本番環境でのアプリケーションの外観を標準化する上で、これらの重要な構成要素の1つでした。 [これにより]開発チームが実行できる自動化を構築することができました...インフラストラクチャを安全に展開、監視し、(必要に応じて)ロールバックします。」

マイクロサービスを構築し、破壊的変更にノーと言う

継続的デリバリーは最初のステップにすぎませんでした。 これは開発者がリリースをより早くリリースできることを意味しましたが、Mike は、デプロイがシステム全体に影響を与えないことを真に確信するために、アプリケーションの一部を分離する必要があることに気付きました。 これを達成するために、Mike と Gilt チームはいくつかの重要な戦略的決定を下しました。 まず、彼らはサービスの構築と技術契約への投資にシフトしました。 彼らの新しい道筋とソフトウェア構築のデフォルトの方法は、確固たる契約を結んでいるサービスに取り組んでいるすべてのチームが、必要なときにいつでも自信を持ってそのサービスを展開できることでした。

第二に、彼らは物事を壊すような変更を決してしないことを標準化しました。 たとえば、開発者がデータベースやAPIに変更を加えたい場合は、破壊的ではない方法で変更する必要がありました。 この決定により、契約が破られてビジネスの他の部分に損害を与えることはないと人々が信頼できるため、多くの柔軟性が得られました。

開発者の選択 = 構築の自由

マイクが Flow.io に移ったとき、彼はこのアプローチを彼と一緒に継続的デリバリーにもたらしました。 この時までに、継続的デリバリーとマルチサービス展開は業界ではるかに一般的になっていました。 現在、開発者は、Mike が Gilt で解決したのと同じモノリシックな問題を回避するために、何百ものツールから選択できるようになりました。

しかし、それはまた、開発者エクスペリエンスのギャップという新しい問題を生み出しました。

組織はどのようにしてこれらすべての可動部分をまとまって組み合わせ、すべてを運用することと開発者に選択の自由を与えることのバランスを確立するエンジニアリング原則を設定できますか? マイクは、このトピックに関するFlow.ioの哲学を共有しました。

「私たちは開発者に多くの選択肢と自由を与えています。 しかし、私たちはそれを製品自体の開発に集中させようとしており、付随的な懸念についてはあまり焦点を当てていません...本番環境で高品質のソフトウェアを提供するために必要なものはすべて組み込まれており、テクノロジーの統合に基づいて投資を集中させました。」

マイクロサービスと継続的デリバリーの中で最高のテクノロジーを標準化することで、Mike はチームをサポートできるため、ツールの管理にすべての時間を費やす必要がなくなり、イノベーションの自由を得ることができます。

ベストオブブリードの標準化により、可視性、セキュリティ、応答時間が向上

セキュリティに関して、Mikeは、最高のソリューションを標準化し、すべての技術スタックで同じ標準ライブラリとアプローチを使用して、それらを開発プロセスに自動的に組み込むことの重要性について話しました。

「同様に、どのベンダーと協力したいかを決定するとき、そこで解決が難しいいくつかのことに多くのレバレッジを得ることができると思います。 例としてセキュリティとサプライチェーンに戻ると、レバレッジのポイントを提供するベンダーを選択することは、Dockerがその良い例だと思いますが、非常に重要であり、すべてのアプリケーションはDockerコンテナにあります。」

アプリケーション間の可視性: Log4j への対応

Flow.io チームは、組織が最近のLog4jの脆弱性にどのように対応できるかを確認することができました。 Mike は、Docker がチームの迅速な対応にどのように役立ったかを説明しました。

「log4jの脆弱性がリリースされた前四半期、組織がそれにどのように反応するかを見ることができます。 私たちの場合、それは非常に、非常に迅速でした。 24時間以内に、会社全体のすべてを完全に監査し、その後、公開されていないことを確認するために、より深く掘り下げるための候補リストがあったと思います。 これは、高度な標準化を行い、提供するさまざまなアプリケーションすべてを可視化できるパートナーを選択したためです。」

結論

では、どのようにしてポジティブな開発者エクスペリエンスを作成し、開発者エクスペリエンスのギャップを回避できるのでしょうか。 それはすべて、標準化と自由のバランスを見つけることです。 開発者が何を生み出しているかを考えるだけでなく、開発者がどのように働き、どのように機能させたいかを考える必要があります。 ジャスティンが言ったように:

「開発者が組織にどのように適合するかを考える人が必要であり、組織内で開発者エクスペリエンスを構築することについて考える必要があります。 ツールがどのように連携し、どのように使用するかについて意見を持つ必要があります。」

開発者と話してください。 それらを聞いてください。 使用しているツールを確認し、それらのツールを標準化して、開発者が開発者エクスペリエンスのギャップに費やす時間を減らし、アプリケーションのイノベーションにより多くの時間を費やせるようにする方法を考えます。

これらのトピックを深く掘り下げるには、 この投稿の冒頭 にある17分間のビデオ全体と、以下のいくつかの追加リソースを確認してください。

関連資料

• ホワイトペーパー: Docker Business を使用した最新の安全なアプリケーションを大規模に構築する
• 2022年以降のアプリケーション開発の状況
• DockerCon 2022: 開発チームを DockerCon に派遣して、Docker スキルをレベルアップする