前書き
Googleは個人的にエンジニアのパラダイスではあります。数えられないほどの発想はGoogleから発信してきました。Don't be evilのフェーズにもとても同感できます。
今の開発は1人でできるものじゃなくなってきました。強い、幸せ、楽しいチームを作るのが今の自分の目標となります。「Googleのソフトウェアエンジニアリング」本に出会って、これは「夢のチーム作りに最高な本ではないか」と確信して即購入しました。外国人にとって日本語版の1章が難しくてなかなか進みませんでした。年末になり、ようやく勇気を出して一気に読んでみました。
このシリーズは自分の経験＋本の読後感となります。
チームメンバー
若いごろ実力は全てと信じました。1社目で働いている時、自分のメンバー選択基準はとても単純のプログラミングの実力順でした。能力のあるメンバーを集めれば、強いチームを立ち上げられ、プロジェクトがスムーズに進められると考えました。しかし、このモットーで立ち上げたプロジェクトがしばらくスムーズに進んだが、自分が選んだ頭脳のすごいサブリーダーが他のメンバーと激しい衝突が起こり、結局あのメンバーの離職につながりました。とても残念な結果でした。
フリーランスの時にもとても優遇される正社員の1人と出会いました。その方がC#にとても詳しい、技術的にすごく優れていると言われています。夜型なので、出勤いつも午後となり、しかし、午後のいつ出勤されるか、そもそも出勤されるかどうか誰も把握していません。文字ベースのコミュニケーションにも苦手で、発言はいつも攻撃的に見られています。幸い彼を理解、フォローできるもう1人の正社員がいらっしゃいましたので、その理解者の働きによって、ギリギリのラインで回っていました。
上記の経験を踏まえて、現在僕が理想的なチームメンバーはGoogleのソフトウェアエンジニアリングの本の中と似ています。
求めない素質
- 天才
コーディング力がすごいのは問題ありません。問題になるのはコミュニケーションを取りづらいことです。プロジェクトの成功は単に1人、2人の天才に頼るのがとても無理ではあります。プロジェクトが大きければ大きほど、つまらない、創造性のいらない作業が増えます。1人、2人より、チーム全体のモチベーションが重要なこととなります。
- 傲慢
自分が傲慢だと誰も思わないでしょう。しかし、自分がどう思うかキーポイントではなく、他のメンバーがどう思うのが一番となります。出したプルリクエスト（PRへ略）に対して、指摘が入ってきたらどう反応するか、自分のPRを他のメンバーがわかるように努力して説明できるか、他のメンバーから愚かな質問に対して忍耐強く丁寧に答えられる、あるいは導くことができるか、傲慢さの判断基準の一部になるでしょう。
- 音信不通
テレワーク時代で、1日、2日で音信不通、進捗が自分以外誰でも把握できなく状態の働き方。
求める素質
- 謙遜（from Googleソフトウェアエンジニアリング）
自分のコードが宇宙の中心的存在ではなく、自分が全能ではないがわかります。指摘があったら真剣に考え、多少チームのために妥当できます。
- 尊敬（from Googleソフトウェアエンジニアリング）
他のメンバーを心から思いやります。他のメンバーの能力、成果を認めます。PRをレビューする時、相手を批判するより、どうすれば成長させることを念頭に置いています。
- 信頼（from Googleソフトウェアエンジニアリング）
他者が有能であろうと信じます。他のメンバーが自分が詳しい領域をチャレンジしたい時、励ましたり、サポートしたりできます。
- 好奇心
新しいものにチャレンジしたい、勉強したい、コンフォートゾーンから出られます。
- ある程度な基礎力
Googleソフトウェアエンジニアリングにはないでしょう。Googleに入るために、LeetCodeなどで腕を磨くのが普通でしょう。なので、一般会社でもコーディングテストで基礎力を確かめるのが必要だと考えます。
※あくまで基礎力の確認。これが一番重要だと考えるスタートアップが多いだが、個人的にコーディングテストは1つの判断基準に過ぎない。
- チームに貢献したい
個人だけではなく、チームの成長を貢献、促進できます。例えば：ドキュメントの全くないチームに入り、チームの未来のためにドキュメントを充実させること。
コーディング力とバス係数の思考
コーディング力が非常に重要です。ただし、他のチームメンバーが理解できないコードばかりになると、バス係数が1となり、プロジェクトが非常に危険な状態に陥ります。
個人的は。
a. 書いたソースコードを少なくても自分以外1人に説明でき、メンテできるようにする。
b. 他者が理解できるために、もっとシンプルな書き方に変える。
いずれが必要だと考えています。aとb両方ともできなかったら、コーディング力がいくら高くても、今の会社にふさわしくないと思います。
もちろん、スタートアップ企業が起業したばかり、2人、3人しかいない時は論外かもしれません。
非難なきポストモーテム文化作り
バグのないソフトウェアが世に存在しないと自分が信じています。いくら精密な機械でもバグると同じです。ただし、人間は教訓から学び、同じ過ちは行わないことができます。
なので、チームとしてはバグの発生をできるだけ避けるのが当たり前ですが、「バグのないソフトウェアをリリースする」をOKRにするのが不適切だと考えます。逆に、発生したバグが今後発生させない（デブレ）の方がよほどいいではないでしょうか？
そうすると、メンバーが失敗に恐れず、どんどんチャレンジできるようになります。バグったら原因分析だけではなく、防止策を考えるのが必要でしょう。その上、人為的なミスなら、自動化により再発を防ぐ、コードのバグであれば、自動テストの充実により再発を防ぐのが良いと思います。要は教訓を文面化し、人間の力で防ぐ仕組みを作るより、自動化にすることで取り込むことです。人間は忘れたり、ミスしたりするからです。ストレスも感じるし。
テストに関しては別のブログで紹介したいと思います。
DX改善のためのポジション
これは今の会社から得られた経験です。必ずすべてのチームに当てはめられるのに限りません。
スタートアップ会社が開発スピードを優先するのがほとんどです。製品を一刻も早く出して、ランウェイを長くしたい気持ちは理解できます。短いプロジェクトだったら問題がないかもしれませんが、SaaSシステムなどデカいプロジェクトを作ったら長い目で見るとスピード優先だっと破綻に繋がります。品質担保ができなくなり、開発スピードが徐々に落ちるからです。
しかし、品質が重要だといくら考えているスタートアップだとしても、やっはりスクラムプラニングする時、DXの改善、品質改善のストーリーをスプリントに入れるのが至難の業です。優先度高いものはお客さんからの要望、バグ修正、いつまで経っても終わらない新機能の開発となります。じゃ、どうすればいいでしょうか？
偶然なんですが、今のチームに週3しか参画できない方がいらっしゃいます。スクラムプランニングに参加できず、スクラムに組み込むのが難しかったです。無論ストーリーポイントを見積もる時も対象外にしました。彼にスプリント対象外のDXの改善、テストの充実など品質のためのストーリーを頼むことができました。そのおかげで、担当しているプロジェクトの品質が高く、DXも落ちずに心理的に安全で開発がスムーズに進んでいます。
なので、個人的に、DX改善のためのポジションを設けるのがおすすめです。そのポジションに適切な方は下記の素質が必要でしょう。
謙遜
DX改善はチーム全員に影響するので、他者のフィードバックを素直に受け入れ、丁寧に説明できるのが求められます。
好奇心
最新の動向にアンテナを立てて、チームにベストの案を導入できるのが求められます。
チームに貢献したい
DXを改善したい、テストの追加などでチームを貢献したい方が求められます。
まとめ
チームメンバーの選定は能力だけではなく、謙遜、尊敬、信頼、好奇心、チームに貢献したい素質のある方がむしろ重要でしょう。技術高いメンバー1人しかメンテできないバス係数1になるソースコードの存在は避けるべきしょう。非難なきポストモーテム文化を作るのもパフォーマンスのいいチームにとっては必須です。スタートアップのスクラムチームであれば、DX改善のためのポジションを設けるのが個人的におすすめです。
