チームと自分を成長させるためにチーム開発で心がけたいこと

こんにちは。Androidエンジニアのkenzoです。
今回は普段チームでプロダクトを開発を行う際に、プロダクト・チーム・そして自分自身の成長のために心がけていること、またそうありたいと思っていることを少しだけご紹介します。
これらは内容としては当たり前のことかもしれませんが、改めて意識し実践することで、少しずつそれぞれの成長に繋げていくことができると考えています。

失敗から学ぶ

開発を進める中で、大小様々な事故やミスが発生することがあります。
リリース後のアプリがクラッシュするような大きな事故や、実装時に見つけてハッとして直すような小さなミスなど、失敗の種類は多岐にわたります。
できれば全て事前に防ぎたいところですが、起きてしまったものは仕方ないので、それらについては事後にきちんと振り返り、そこからきちんと学んで繰り返さないようにします。

・失敗は成長の種
大抵の事故は、複数の要因が組み合わさることで発生します。たとえば、変更に弱い実装だった、コードレビューで見逃された、テストケースにそのパターンが含まれていなかった、仕様を勘違いしていた、特定の条件でしか起きないものだった、他の施策との兼ね合いで本番環境でのテストが難しいタイミングだった、などなど、様々な要因が影響します。どれか1つでも防げていれば回避できたかもしれませんが、実際にはどれもすり抜けた結果、事故は起きてしまいます。
適切な対応をした後にきちんとチームで振り返れば、いくつもの改善点を発見できると思います。これらに対処することがプロダクト・チーム・自身の成長に繋がるかもしれません。
それぞれをタスクに起こして一つずつ解決していけば（難しいものもあるでしょうが）、全く同じ要因による再発は防げます。
小さいかもしれませんが、成長ができたと言えるのではないでしょうか。

・失敗について話しやすい環境
チームでの失敗には様々な物がありますが、元を辿れば個人の失敗に起因することがあります。それをチームで振り返る際には、誰かのミスを指摘することになりがちですが、する側もされる側も嫌だと思います。そのため、普段から全員が失敗は共有してみんなで振り返るのが当たり前という認識を持てるような環境をつくることや、失敗を取り上げる際の方法にも配慮することが必要です。

・個人の場合
個人の場合も、事故には至らなくとも、ちょっとしたミスや「あの時こうしていれば」と後悔することはよくあると思います。
こういう日々の伸びしろを逃すことなく、それぞれに積極的に対応することで少しずつ成長していきたいですね。

未来の読み手を意識したコード

今度はコードの話です。
長く続くプロダクトの仕様や技術が古くなるにつれて、コードの理解が難しくなっていきます。開発が速かったり、変化の激しい環境においてはなおさらで、数ヶ月後にはもはや別のプロダクトのようになっていることもあります。
現時点でさえ理解しにくいコードは将来さらに読みにくくなります。
過去のコードに苦しんだ経験のある開発者も少なくないと思います。自分の書くコードを読む未来の開発者にそんな思いをさせないためにも、未来の読み手を意識した親切なコードとその周辺環境を作っていきたいところです。
背景を知らずドメイン知識のない開発者が一人でそのリポジトリを見たとして、どれくらい理解できるのだろうと考えたりしています。

・ベストプラクティスに従う
基本的には公式のドキュメントで紹介されている書き方や一般的に良いとされている書き方に従うことを推奨したいです。更新頻度の高い新しいフレームワークを使ってる部分でなければAIに教えてもらうのも良さそうです。
世の多くの開発者に良いと認識されているものがベストプラクティスなので、そのベストプラクティスに則ってコードが書かれていれば、新たにそのコードを触る開発者に「こう書いてね。」と伝えるコストも低く抑えられます。
また、より良いものが新たに生まれた場合には、誰かが紹介してくれるマイグレーションのプロセスにそのまま乗ることもできるかもしれません。
独自のより良い書き方を生み出して使うのも良いですが、その場合にかかる諸々のコストも考慮し、覚悟の上で導入する必要がありそうです。

・書き手は最強
ある処理の実装を書いたとします。書いた直後はその処理についての全てを把握しているので、そのコードの把握も非常に容易です。
そのため、もしそのコードが複雑で読みにくいものとなっていたとしても、それに気付くのは難しいでしょう。
簡単にはいかないかもしれないですが、他の人や未来の自分が見たらどう思うか、◯◯を見て☓☓だとわかるか、というように一旦意識的に客観的な視点から再度コードを読んでみてもいいかもしれません。
これはちょっと前に自分の書いたコードがクソコードに見える現象の一因にもなっている気がします。

・なぜ必要？なぜここに？なぜこう書く？
自分の書いたコード全てについて、これらの質問に明確に答えられるようにしておきたいです。
回答が明確でないコードは、他の人が理解するのに時間がかかったり、誤解によるバグを生む可能性もあります。
逆に明確なコードは、他の人がその意図に沿って開発できたり、意図の共有による技術力の向上にまで貢献するかもしれません。
できることならこの質問を何段階か深堀りすると良さそうです。

・手がかりを正しく残す
プロダクトを開発していると、ドメインの仕様に依る箇所や複雑な仕様の処理など、コードからきちんと仕様を把握するのが難しかったり時間がかかるものがあります。
それらを正しく理解するためにコメントやドキュメント、仕様書等で手がかりを残すことになりますが、それを有用なまま維持しておくことが意外と難しいこともあります。
変更に追従できていないドキュメントや、作ったものが何らかの移動やツールの変更のタイミングで失われるなど、環境によって様々ではありますが、時間の経過でアクセスが難しくなったり害悪になってしまうものもあります。
残す場合にはそれが将来必要な時が来るまで維持できる仕組みまで考えたいところです。