人間関係はここでは考えないでおきます。
技術関連視点で今はこのあたりを重点的に取り組んでいます。
・難しい/新しい技術も簡単にできる環境を用意して、知識と合わせて共有できる人。
・適切に小分け、役割を分け、一見してやりたいことが分かるコードをかける人。
・コーディング規約や、テストの実行、よろしくない作法など自動化できるものは自動化できる人。
これらを通して、チーム全体の技術力底上げと、クオリティの均一ができればと考えています。
・難しい/新しい技術も簡単にできる環境を用意して、知識と合わせて共有できる人。
例えば開発環境の構築。
それは昔、開発環境ですらwebではサーバーを立てるところから始まって必要なライブラリのインストール、設定などが必要で
必然的にLinux系サーバーを黒い画面でいじる知識が必要でした。
今ではvagrantやdockerを駆使して、経験が浅い/無い人でもさくっと同じ開発環境を構築できるようになりました。
こういったものは取り入れつつ、他メンバーでも簡単に使えるようにしたうえで勉強会を開き、知識の底上げをしていくとチームの技術力はあがっていきます。
・適切に小分け、役割を分け、一見してやりたいことが分かるコードをかける人。
比較的新しいフレームワークを使えば適切に役割分担されていますが
自身で開発する機能の部分でも適切に書かないといけません。
一見してわかりにくいコード、例えば複数行にもわたる正規表現や、やたら長いSQL文などは避けなければなりません。
たいていの場合、書いた人でも1週間すれば「何がしたかったのか」「I/Oの仕様はどうだったのか」など忘れます。
テストも書きにくくなりますし、他の人が読んで何がしたいのか把握に時間がかかります。
methodを適切に小分けし、methodの命名や、場合によってあえてローテクな文で書いたりすることで
バグの混入も減り、その後の改修のため・修正のためのソース確認の時間を減らすことができます。
・コーディング規約や、テストの実行、よろしくない作法など自動化できるものは自動化できる人。
今はいろんなCIが用意されていて、コーディング規約に合わせた自動整形、テスト、セキュリティテスト、ソースのきれい度など、自動で動かすことができます。
これらを使用し、通知することで、
やれ()の前後にスペースがどうのこうのなど、コーディング規約は気にしないでよくなり、
テストコードやセキュリティで一定の品質を維持し、開発者は本来の開発に専念することができるようになります。
本来の開発に専念できるってとても大事です。