エンジニアリング・プリンシプル。 putting our values into practice
VP of Engineering, Ilya Kozlovが、弊社のエンジニアリング原則に秘められた論理と価値について話します。 これらの原則によって、当社のエンジニアがどのように成長し、配信のオーナーシップを持つことができるかを垣間見てください。
Taxfix では、すべてが当社の価値観から始まります。 タックスフィックスは、「Deliver」「Trust」「Develop」「Understand」というバリューを掲げています。 社内でどのような役割を担っているかにかかわらず、誰もがこれらの価値観を共有しています。 エンジニアリング・プリンシプルは、バリューを具体的なコンセプトで実現し、公平で構造化された方法で皆を導きます。 目標は、発見、意思決定、納品、および成長において、チームを可能な限り自律的にすることです。
原則は、新入社員がここでどのように物事を行うかについて迅速にスピードアップするためのロードマップです。 行動や新しい課題への取り組み方についてのプレイブックを提供するものです。 たとえば、2人の異なる人が同じような状況で同じ問題に直面した場合、同じガイドラインに導かれているため、その解決策はほぼ同じになるでしょう。 また、私たちの原則は、フィードバックと発展のためのベンチマークとしても機能します。 すべての原則の背後には、エンジニアの行動に対する期待値があり、それが自己改善の方向性を示しているのです。
どのようにしてこれらの原則を形成したか
価値は日常生活の不可欠の部分ですが、これを行動に移す方法は必ずしも明らかではありません。
私たちは、私たちが何を重視し、チームに何を期待するかを正確に詳述した、エンジニアリングのプレイブックが必要であることに気づきました。 マドリードのエンジニアリング マネージャーである Juan Ramirez、CTO の Alex De Leon、そして私が集まり、最初のブレーンストーミング セッションを行いました。 その結果、取り組むべき重要な分野がいくつか見つかりましたが、私たちの考えは完全ではないことがすぐにわかりました。 7117>
それから数カ月間、一連のワークショップを通じて、私たちはアイデアを話し合い、互いに挑戦し、市場をリードするエンジニアリング文化のいくつかを参照しました。
エンジニアリングの原則は実際には何を意味するのか
ここで、私たちのエンジニアリングの原則のいくつかを見てみましょう。 これは、誰もがどんなアプリケーションやサービスにも貢献できることを意味し、弱いコード所有権としても知られています。 内部オープン ソースは、コード ベースが共有されている場合、事実上依存関係がなくなるので、私たちが製品を提供するのに役立ちます。 あるチームが新しい機能を提供したい場合、しばしば、自分たちのサービスで何かを構築し、それから他のチームに連絡を取り、すべてのピースが集まるのを待つ必要があります。 通常、企業として大きくなればなるほど、この問題はより複雑になります。 依存関係に阻まれるのが基本です。 しかし、私たちは部門を超えたチームを編成し、ほぼすべての場所でJavaScriptというひとつの言語を使っています。 このため、誰でも社内の特定のサービスに行き、そこで変更を加えることができます。
信頼
信頼という価値観のもと、私たちには「We are One Team」という原則があります。 これは、個人ではなく、チームや組織のアウトプットを最適化することを意味しています。 個人は確かに自分の求める結果を出すことができますが、組織の他の部分にはどんな犠牲を払っているのでしょうか。 自分の目標だけを考えていては、会社全体が効率的になりません。 そこで、専門知識や経歴、視点を組み合わせることで、より良い結果を出す方法を考えているのです。 一人でできる仕事はなく、コラボレーションが必要なのです。
Develop
私たちの価値観「Develop」の中に、「We Learn from Each Other」という原則が含まれています。 ミートアップへの参加やカンファレンスへの参加といった一般的な学習活動に加え、チームメンバー間での知識の共有も奨励したいと考えています。 ここで実現しようとしているのは、チーム内の異なるスキルセットのマッチングです。 例えば、フルスタックに移行したいフロントエンドエンジニアがいるとしたら、バックエンドエンジニアとマッチングさせます。 この 2 人をペアにすることで、彼らは自分の専門外の新しいプロジェクトを推進し、チームとして、また個人として成長することができます。 この原則は、単なる文書化にとどまらず、双方向のものです。 私たちは、自分のチームが他の人のためにコンテキストを作成することを期待しています。 そのうえで、受け取ったコンテキストを積極的に読み、咀嚼することが求められます。 例えば、プルリクエストに適用する場合、人々は必ずしもあなたのコンテキストや、あなたがチームで何を達成しようとしているのかを知らないのです。 もしあなたが共同作業で他の人のリポジトリを変更しようとしているなら、できるだけ多くの文脈を伝えなければなりません。 自分の意図、妥協点、タイムライン、そしてこの変更がこの先の大きな変更とどう繋がるのかを説明する必要があります。 私たちは、意思決定に正しいとか間違っているとかいうことはないと考えています。 私たちが信じるのは、正しい文脈でなされた意思決定、あるいは文脈が欠落している意思決定だけです
。
Leave a Reply