※この記事はAgileStudioに掲載した記事の転載です。
元記事：「良いコードってなんですか？」心折れた若手が声を上げ、チームが動くまでの試行錯誤（トナリノ）
「良いコードを書くために、みなさんが意識していることを知りたい」
このチームがその問いを言葉にしたのは、1年前の合宿でした。
今回ご紹介するのは、エンジニア7人（うち若手5人、シニア2人）の開発チームです。コードレビューはあるけれど「良いコード」の基準がどこにも言語化されていない──そんな課題を抱えていました。
この記事は、そんなチームの試行錯誤の記録です。
トナリノは、隣のチームの泥臭い試行錯誤をそのまま届けるコミュニティです。
様々なチームの「うまくいかなかったこと」「試してみたこと」「今の現在地」を記録しています。正解やTipsではなく、あるチームのリアルな試行錯誤をお届けします。
「良いコード」の基準が、チームになかった
このチームには、コードの質をめぐる「歴史」がありました。
もともとはモブプロ（複数人で1つのコードを書くスタイル）で開発を進めていました。複数人で書いているからレビューも不要だよね、ということで、コーディングが終わるとそのままマージしていました。
モブプロは「全員で考える」が強みですが、裏を返せば「コードの責任が全員に薄く分散する」構造でもあります。「ここは読みにくいかも」と感じても、「みんなで決めたから」と通ってしまう。品質への違和感が言語化されにくい状態でした。
その結果、「汚いコード」が蓄積していきました。動きはするけど、読みにくい、設計が悪い──いわゆる技術的負債です。
やがてチームはモブプロをやめ、1人ひとりでコードを書くスタイルに移行します。同時に、シニアエンジニアによるプルリクエストレビューも導入しました。
ここで新たな問題が起きました。
汚くなった既存コードをベースに書かれたプルリクが次々に来る。シニアエンジニアのレビュー工数が膨らみ、本来やるべきことに時間を割けなくなっていきます。
そして、若手エンジニアが直面したのはこんな体験でした。
レビューのコメントが来ます。「○○が微妙です」という一言。シニアエンジニアは育成も意識して、あえてそういう書き方をします。でも若手にとっては、「どこが微妙なのか」「どう直せばいいのか」を自力で解釈しなければなりません。
コードを直す。「また違う」と言われる。解釈して、書いて、また指摘。このサイクルが繰り返され、プルリクのコメントのやりとりは非効率なほど長くなっていきました。
そして何より、 解釈が合っているのかどうか分からないまま対応しなければならない 、という不安が若手に積み重なっていきました。
若手は心折れ、自信を失っていきました。でもリリースへのプレッシャーもあり、この状況を変えるためのアクションを取る余裕さえありませんでした。
この状態が3ヶ月続きました。シニアと若手の間には、言葉にならない緊張感が漂い始めていました。
合宿のふりかえりから生まれた「Try」
リリースが終わったタイミングで、チームは合宿を行いました。日常の業務の中では、ふりかえりに時間を割く余裕がなかった。合宿という場が、強制的にその時間を作りました。
合宿では、これまでのチームのふりかえりを実施。「チームの追い風になること」を出し合う時間の中で、あるTryが提案されました。若手エンジニアからの提案でした。
「キレイなコードについて話し合う会をやる」
ポイントは「話し合う」という言葉です。シニアエンジニアのワンマンプレーにしたくなかった──だから、対等に語り合う場にしたかったのです。
このTryに最初に食いついたのは、シニアエンジニアでした。
「これ、いいんじゃないですか」
その一言が空気を変えました。賛同が広がり、チームでやることが決まりました。
週2回・10分の「語る会」
こうして生まれたのが、「良いコードとはを語る会」です。
進め方はシンプルです。
- 週に2回開催する
- ファシリテーションはその日の朝会担当が行う
- 基本は10分間。長くなりそうなら「また次の会で」と持ち越す
- 良いコードについて語り合い、開発時のお作法やルールを話し合う
「10分」という短さが重要です。時間がない中でも、このチームには「必要だ」という感覚がありました。だから「最低限でやろう」で10分。「これならできそう」という感覚が全員にあったのです。
特別なフォーマットも、複雑なルールもありません。ただ「語り合う」だけです。
ただ、話題がなければ流会します。「今週、話すネタがない」──そのまま会がなくなる週もありました。完全に回り続ける仕組みではなく、チームに語るべきモヤモヤがある限り続く、という性質の場です。
最初の語り合い──DRY原則と、テストの派閥
最初の会では、「コードを書くときに意識していること」をメンバーそれぞれが話しました。コード全体の話を各々が喋り合う、いわば「棚卸し」のような時間でした。
一通り語り合うと、次第に話題が変わっていきます。「今のコードへのモヤモヤ」を話すようになりました。「1ファイルにずらっと処理が書いてあるけど、どう分割すればいいかの基準がわからない」「バックとフロントでそれぞれ意識していることが違う」──そういった、開発中に感じていた具体的な引っかかりが出てくるようになりました。
最初に「共通認識が取れた」と感じた瞬間がありました。
DRY原則 （Don't Repeat Yourself：同じコードを繰り返し書かない）についての議論です。
意識している人と、していない人がいた。それが語り合ったことで、チームの共通認識になりました。「DRY原則を守ろう」というたった一つの合意でも、コードの書き方に変化が生まれました。
その後も議論は続きます。例えば、フロントエンドのテストの書き方。
「ページ単位でテストを書く派」と「パーツ（コンポーネント）単位で書く派」に分かれました。どちらの方が読みやすいか。チームで話し合い、「パーツ単位」に統一することを決めました。
「え、その解釈は違う」という発見が積み重なるたびに、チームの「良いコード」の定義が少しずつ形になっていきました。
メモがコード規約になった
語り合った内容は、最初はMiroに書き留めていました。みんなが見える場所に、メモ程度に。
2〜3回実施したタイミングで、メンバーからの提案が出ました。
「このメモをもとに、コード規約を作ったらいいんじゃない？」
こうして、語り合いの積み重ねがコード規約として形になっていきました。コーディングで迷ったときに見れば答えが分かる場所として、Miro上で育ち続けています。
プルリクの「わからない」が、コード規約を育てる
語る会が続く中で、ある循環が生まれました。
プルリクのレビューコメントに対して、「わからない」と素直に返せるようになった若手エンジニア。以前は解釈が合っているか不安なまま対応していたのが、今は「ここが分からない」と質問を投げられる。
そして、「わからない」が出たということは、 それはまだコード規約に書かれていない ということ。
だから次の語る会で、チームみんなでアップデートします。
シニアと若手の二者間でプルリク内に閉じていたやりとりが、「語る会」のテーマに昇格する。チーム全員がそのやりとりを知ることができる。そしてコード規約が更新される。
この循環が、コード規約を「チーム全員で育てるもの」にしています。
「冷戦みたいな空気」が、変わった
語る会を始めてから、チームに変化が起きました。
語る会でコードの基準が共有され、コード規約が育つにつれ、コードの品質そのものが変わっていきました。そのことを、シニアエンジニアは掛け持ちしている他のシステムとの比較で感じ取っていました。
「コード、ちゃんと書けてるね」。
その一言が、若手エンジニアの自信になりました。
最初のころよりも、不安なくプルリクを出せるようになりました。コメントでの非効率なやりとりも減りました。コードレビューに対して「わからない」を素直に言えるようになりました。
そして、チームの空気が変わりました。
「冷戦みたいな空気感」が、「穏やかな空気」に。
2026年6月現在、この語る会は約1年続いています。
あなたのチームでは、「良いコード」について語り合っていますか？
コードレビューはある。でも「なぜそれが良いのか悪いのか」を語り合う場はない、というチームは少なくないと思います。
暗黙知のまま残っているシニアの判断基準。何が正解か分からないまま書く若手のコード。そのズレは、レビューで修正するたびに積み重なっていきます。
このチームが取り組んだのは、そのズレを「語り合うことで埋めていく」ことでした。週2回・10分、完全には決まらなくてもいい。語り続けること自体が、チームの「良いコード」の定義を育てていく。
そして、プルリクの「わからない」が次の語る会のテーマになる。その循環が、コード規約をチーム全員のものにしていく。
もちろん、このチームの形がそのまま別のチームに当てはまるとは限りません。合宿というきっかけ、シニアエンジニアの一言、リリース後の余白──この会が続いた背景には、このチーム固有の条件があります。
皆さんのチームでは、何がきっかけになるでしょうか。あるいは、そもそも「語り合う場」が必要だと感じているでしょうか。
このチームの試行錯誤が、皆さんのチームへの「問い」になれば嬉しいです。
この記事は、「トナリノ」から生まれた試行錯誤の記録です。
様々なチームの泥臭い試行錯誤を、定期的に届けています。
他のチームの話も気になった方は、フォローしてもらえると嬉しいです。
Xでも同じテーマで発信しています → X（@はんそで）