こんにちは！たけぴです。
ソフトウェアエンジニアの皆さん開発プロジェクトでチームリードに悩んでいませんか？
開発リーダやマネージャ以上の方はどうやって上手くプロジェクトを回すか、という問題に直面することは少なくないかもしれません。
プロジェクトの構造定義とか開発プロセスの提案とか、ややもすると「めんどくさい」と思ってしまうかもしれませんね。
そんな悩みに対するヒントになればと、今回はDEVELOPER by Andrea Medda の記事をお届けします。それではどうぞ！
小規模で独立したチームで作業することは、エンジニアにとって難しい場合があります。 フィンテックセクターの急成長企業であるカーブのエンジニアとして経験して分かったのですが、チームごとにまったく異なるアプローチを使用する傾向があることがあり、チームの移動とチーム間のコミュニケーションが課題になります。
カーブでは、プログラミングにGolang（または略してGo）を使用します。 Goは、シンプルで信頼性の高い効率的なソフトウェアを簡単に構築できるオープンソースのプログラミング言語です。
複数のチームでオープンソース言語を使用すると、独自の課題が発生する可能性があります。 たとえば、構造の違いやさまざまな規格への適合から多くの問題が発生します。 すべてのプロジェクトがベストプラクティスに従うことを保証しながら、高いコード品質基準を維持しようとするのは困難な場合があります。
定義済みのプロジェクト構造をチームと共有すると、このような課題を克服できます。 また、Goなどのオープンソース言語を使用する場合は生産性も向上します。
これが発生すると、すべてのプロジェクトがより似たような外観になり、チーム間の移行がはるかに簡単になります。 また、経験豊富なGopher（Goのエンジニアと呼ばれます）は、関連するファイルやディレクトリを見るだけで何が起こっているかを知ることができるため、プロジェクトメンバーが貢献するのも簡単です。
明確に定義されたプロジェクト構造は、確立された標準に従うことが容易であるため、新しいGo開発者にも役立ちます。 新しいチームメンバーは、サービスの動作を学習する必要なく、変更を加えて他のプロジェクトに複製することができます。
問題は、組織でこのような仕組みをどのようにして確立するかです。
あなたの配置された立場では2つの選択肢があります。 1つ目は、go-kitやgo-microなどのフレームワークを使用して、構造とアプローチを提案することです。
このタイプのフレームワークを使用する利点には、すぐに使用可能なユーティリティ（ロギング、トレース）、および事前に合意され、コミュニティとオープンに共有されている標準が含まれます。ただし、この方法にはいくつかの欠点があります。それはこのようなフレームワークには多くの定型文が付属しており、コアコンポーネントに変更を加えることは困難であるということです。また、コミュニティによって管理されているという事は、変更を待つ時間が長すぎるため、バイナリのサイズが大きくなることも意味します。
2番目の選択肢は、単純に会社レベルでプロジェクト構造に同意することです。これを行うことで、あらゆるアプローチやライブラリを自由に使用でき、迅速な変更を行い、バイナリを小さくし、慣用的なGoを簡単に追跡できます。これの潜在的な欠点は、これらの変更に同意して適用するプロセスを促進するために、会社のエンジニアリング文化が十分に成熟している必要があることです。このような長く退屈なプロセスにより、仲間のエンジニアは価値があるかどうか疑問に思うかもしれませんが、一部の標準は自然に発生し、時間とともに進化します。詳細を確認した後、合意された標準を再検討することは何の問題もありません。
カーブでは、この2番目のアプローチを選択したのですがこれには課題がありました。たとえば、複数の会議と長い議論のため、合意プロセスには数ヶ月かかりました。急成長企業では、これは生産性レベルに大きな影響を与えてしまうでしょう。また、明確なフレームワークがないため、チームは通常「すぐに使える」要素を手動で実装する必要があり、場合によっては、複数のサービス間で誤ってコードが複製されてしまうこともありました。
多くの場合、開発しながら学習し、ほとんどの決定はエンジニアの日々の経験に基づいてフィードバックを受け取った後に行われました。それはコミュニティに注目しながら、また他の成功したGoベースの企業が何を行うかを調査しながらでした。
この方法を採用することで、時間の経過とともに大幅に改善されました。コアチームのエンジニアで構成してGo関連の決定を行うために、「Goチャプター」というものを設置しました。彼らは数週間ごとに会合を開き、関連するトピックについて議論し、新しい標準の採用案に投票します。次に、すべてのチームがすべての新しいサービスにそれを採用し、プロジェクトをリファクタリングする時間を自律的に割り当てて、プロジェクトをフォローします。
プロジェクト構造に関しては、採用する前にすべてのトピックについて何度も議論します。 また、ビジネス目標を確実に達成するために、必要に応じて何度でもプロセスを修正および変更します。
これまでのところ、この新しいアプローチは私たちにとってうまく機能しています。 これは、高品質で安定したサービスをより頻繁に出荷できることを意味し、譲渡を簡素化できます。 これにより、すべてのエンジニアが何をすべきか、問題を解決してバグを見つける方法を簡単に知ることができます。
ただし、次の2つの欠点も確認されています。
・レガシーサービスのリファクタリング
・既存のサービス全体に変更を置き換えること
後者については、最近、ログ記録と監視の戦略を見直し、それに従うためにすべてのサービスに関わる必要がありました。
これまでのところ、このアプローチの維持は比較的簡単です。エンジニアは、構造とコードの再利用に関連するサービスの問題を解決しようとして、新しいより良い方法を見つけるかもしれません。実験してチームメイトからのフィードバックをもらったら、エンジニアは「Goチャプター」で提案できます。
最近の例では、grpcではなくhttpまたは両方の可能性があるサービスを使用する必要性に基づいて、トランスポートレベルを分割することを決定したことです。これを容易にする素晴らしい方法を発見し、承認されました。
このプロジェクト構造は、チームや会社が十分に成熟しており、サービスを学習して改善したいがために間違いを犯してしまう場合にも有効です。明確なコミュニケーションと努力が必要ですが、最終的には合理化されたプロセスに取り組む価値があります。
