はじめに
初めましての方ははじめまして、お久しぶりの方はお久しぶりです。
去年からマッハバイトでAndroidエンジニアをしている設計大好きおじさんお兄さんこと木内です。
先日のこと、自分が入社してから約半年くらい続けていた設計に関する輪読会が一区切りつきました。
今回はこの輪読会について少しお話ししたいと思います。
なぜ設計に関する輪読会をやろうと思ったのか
読者の方の職場ではClaude CodeやCodexの導入は進んでいるでしょうか。マッハバイトチームでも自分が転職してきて少ししたらClaude Codeでの開発が可能になりました。
導入当初はGeminiとやり取りしながら自分で書いた方が早いのでは？と思っていましたが、今ではClaudeに書いてもらうことが9割以上です。
この大きなパラダイムシフトを受け、当時２つのことが頭をよぎりました。
- 「あっ、このスピードで開発が進むと近い将来詰むな...」
- 「エンジニアの役割が変わったな...」
でした。
開発スピードの変化
すでに利用されている方はわかる通り、Claudeを使うと数分程度で何百行以上のコードが生成されます。しかも普通に動く。
しかし「同時に技術負債も同じくらいのスピードで溜まっていくのでは？」という気がしてきました。ベースのコードが綺麗であればそこまで深刻ではないですが、10年以上継ぎ足され続けた秘伝のコードの前では「1箇所直したいだけなのに付随して数箇所直さないといけない...」みたいなことが割と起きがちです。
そこにClaudeのスピードが合わさるので「今までは1年で貯まるような負債が1ヶ月で貯まる」みたいなことが起きそう..という予感がしました。
エンジニアの役割の変化
AIの登場により「自分はAndroidが書ける」「自分はPHPが読める」といった、開発言語習得によるアドバンテージはほぼ皆無になりました。なんなら小5がAIとやりとりしてPythonでアプリすら作れるとんでもない時代です。
そんな中でエンジニアに求められるものは何かと考えた時「この設計で問題ないか」を判断する能力ではないか、と考えました。
単に動くだけのコードならすでにAIが書けます。しかしそこに「プロダクトの背景」「保守性」、「拡張性」、「堅牢性」など複合的に見てベストな設計をする、というのは(現時点では)AIも難しいと考えてます。
チーム全員が設計できる必要がありそう
これらのことを考えた時、チーム全員がどういう設計が良いかを理解し議論できる土壌を作らないとヤバそうだな、と思ったのが輪読会を思い立ったキッカケです。
チーム全員がプロダクトの現状を理解し、何が問題かを把握し、どうすれば解決に向かえるか、を共有し議論出来なければ技術負債の返済も私の一人相撲で終わってしまいます。
輪読会の目標
輪読会を開催する上でやはり目標はキチンと定めておきたいなと思い、当時の説明資料で自分は以下のように定めてました。
- 良い設計とはどういう実装なのか、をチーム全員が学ぶことで以下の状態を目指す
- 自分のコード、既存のコードに対してどこが問題/課題なのかを気づけるようになる
- 問題や課題に対してどういうアプローチをとることで解決できるかがわかるようになる
第一の目標として課題を見つけられるようになる、次のステップとしてその課題に対してアプローチを取れるようになる、という感じです。
もちろん輪読会が終わってすぐ出来るようになる類のものではないのですが、一度理解してしまえば今後ずっと使えるスキルなので習得する価値は高いと考えました。
何の本を読んだの？
前半と後半に分けて２つの本を読みました。
元々はCleanArchitectureの本だけを題材にする予定でした。しかしこの本を読んだことがある方はわかる通り...まぁ難解です。内容も抽象的なことが多く、いきなりこの本を読んでも？？？となりそうな予感がしたのでこの本を読む前にワンクッション挟んで、まずは設計について触れてみるほうが良いのでは？と考え直しました。
そこで白羽の矢が立ったのが「良いコード/悪いコードから学ぶ設計入門」でした。この本は実際の現場でありそうなあるあるな例を交えつつ設計について学べるので都合がよさそうということで採用しました。特にCleanArchectureの本が抽象的な内容が多いため、事前に具体例にそった設計の話がインプット出来ていれば後続の本の理解もしやすいだろう、という目算もありました。
その甲斐あってか...は定かでないですが、CleanArchitectureの本を読み始めて「マジ何言っているかわからん...」みたいな人はいなかった...ように思えます。
どうやって進めたか
輪読会の開催は毎週1時間で次のようなサイクルで行なっていました。
- 事前に輪読会で取り上げる章を読んできてもらう
- 最初の10分くらいで気づいたこと、疑問におもったことなどをMiroの付箋に書き出してもらう+その章を読んでこれなかった人のためにサマリーを自分が話す
- その後付箋をみんなで見ながら意見を出し合う+自分が補足する
といった流れで行っていました。これはすでに同じような流れで別の輪読会を行なっていたこともあり、その方法を踏襲した形になります(大きく形を変えると参加者の負担になるため)。
加えて輪読会を読書会みたいな状態にしたくなかった、という意図もあります。限られた時間で本を読む行為まで含めると明らかに時間が足りず、かつ本を読むことが主目的になってしまう恐れがあったためです。
最後にワークショップを実施した
元々は本を読み終えたらそこで終わりにしようかな、と考えていました。しかしCleanArchitectureの本を読み進めるうちに「言いたいことはわかるんだけどつまりどうすれば...？」という空気感が出てきました。
実際くだんの本はかなり抽象度が高く、かと言って前半で読んだ設計入門ほどの身近な具体的な例もなく、若干不親切な状態でした。
そこで急遽ワークショップとして自分たちのプロダクトのユースケースを題材にしてドメイン層を設計してみよう、というのをやってみました。大体輪読会2回分の時間を使って、前半ではやり方を説明し、後半ではそれに基づいて実際に手を動かしてみる、といった流れでやってみました。そのおかげか設計の基礎的な考え方は伝えられた...ような気がします。
輪読会を終えて思ったこと
そんなこんなで約半年の輪読会＋ワークショップを終えました。その上で反省点だったり、逆に参加者にこうして欲しいな、といった改善点などが見えてきました。
反省点
自分が喋りすぎてしまう
特にCleanArchitectureの本は内容が難しいこともあってシーン..となることが多く、そのたびに何とか伝えようと自分が色々喋ってしまってました。今思えば相手が内容を噛み砕くまで少し待って、疑問点を引き出しつつそれに答える、という流れにすればよかったなと思いました。
こうして欲しいな
リアクションプリーズ！
輪読会や登壇して話すとき、やはり相手の反応が気になるところです。ちゃんと伝わったかな、別の言い回しの方が良いかな、ちょっと待った方がいいか..?など逐次相手の様子を伺いながら話すテンポや内容を調整してます。
その上で今回の輪読会ですが、すべてオンラインで行ったため相手の反応がすごく見えづらいということが起きました。いわゆるオフライン特有の空気感というものを感じづらく、さらに表情もウィンドウに小さく表示されてるだけ、小さな相槌はノイキャンによって消えてしまう..などなど登壇者泣かせの状況でした。
なので、特にオンラインでの登壇や発表を聴く側にまわっている時はオーバーリアクションで頷いたり、あるいはチャットなどで積極的に反応してくれると話している側としてはとても助かるなぁと思いました。
さいごに
輪読会を開いた自分が言うのもアレですが、輪読会で本の内容を完璧にマスター出来る！..ということはどんな本でも正直かなり難しいかなと思ってます。
むしろ輪読会をきっかけにしてもう一度本を読み直したときに「あぁ、あの時の話ってこういうことだったんだ！」という気づくきっかけになったり、そもそもの技術書を読む動機づけになる、くらいの位置付けだと思っています。
なので、輪読会はあくまで本を読む補助イベントと捉え、自ら技術書などを読む習慣をつけ、学んだことを活かせないかとアンテナを張って日々の業務をこなしていくことが大切だと考えています。
