Umi Blog
ウミブログ
こんにちは、スタジオ・ウミの森山です。
スタジオ・ウミでは、2026年10月から社内の技術書読書会、その名も「読む会」がスタートしました。記念すべき第1冊目は、エンジニアにはおなじみの『リーダブルコード』。入社して間もないメンバーからCTOまで、エンジニア以外のメンバーも含めた9名が参加し、毎週水曜日に30分、同じ本を読み進めています。
今回は、そんな「読む会」がどのように始まり、どんな話が飛び交っているのか、初回の様子を少しご紹介します。
今回の読書会を企画したのは、ディレクターの菊池さん。初回のイントロダクションで、会の目的について話していたのですが、そこで出てきたのが「読書会をなくすこと」という言葉でした。
どういうことかというと、読書会の開催自体が目的ではないということです。本を読んで得た知識を実際の仕事に活かすこと、そして最終的には、読書会という場がなくても各自が自然と本を読むようになることを目指しているのだそうです。
私たちの仕事は技術の進歩や環境の変化が多く、日々新しい知識を取り入れていくことが欠かせません。とはいえ、忙しい日常の中で、なかなか読書の時間を確保できないという人もいるはず。こうした機会をきっかけに、知識を得ることや学んだことを実践することの面白さを感じてもらえたら、というのが菊池さんの考えです。
ちなみに、これまでに読書会や輪読会に参加した経験があるメンバーはほとんどおらず、今回が初めての試み。進め方も含めて、みんなで手探りしながらのスタートとなりました。
最初の1冊に選ばれたのは、オライリー・ジャパンから出版されている『リーダブルコード』。2012年の刊行以来、長く読み継がれている技術書です。技術書というと、技術の進歩とともに内容が古くなってしまうものも少なくありませんが、この本が今も多くのエンジニアに読まれているのは、それだけ普遍的な内容が詰まっているということなのでしょう。
選書にあたってはAIにも相談し、菊池さん自身も図書館で借りて改めて読み直したそうです。AIがコードを書いてくれる時代に、あえて人間がコードの読みやすさを学ぶ意味はあるのか。そんなことも考えたうえで、最初の1冊に決めたとのことでした。
コード例やイラストも多く、特定のプログラミング言語に依存しない内容なので、比較的読み進めやすい構成になっています。
今回の参加者は全部で9名。入社してまだ2か月のメンバーもいれば、Drupalエンジニアとして10年以上の経験を持つベテランエンジニアも参加しています。エンジニア以外のメンバーも加わっているのが特徴です。
実は、書籍は会社負担で購入する予定だったのですが、いざ確認してみると、すでに手元に持っているメンバーが結構いました。さすがというか、やはりというか。美しいコードを書きたいという思いは、みんな共通しているようです。
一方で、読書の習慣は人それぞれ。「本を読むのは苦手。目の前の仕事をやってきた結果が今」と話すベテランエンジニアもいます。このほか、技術書よりビジネス書や経営関連の本を読むことが多いという方や、毎週数冊を読む読書家のメンバーもいます。同じ本を読むといっても、普段のインプットの仕方はさまざまで、こうした違いが、どんな議論につながっていくのかも楽しみなところです。
読む会は、毎週水曜日の16時から16時30分まで、Google Meetで開催しています。本当は60〜90分くらい時間を取りたいところですが、それぞれ業務があるため、まずは無理なく続けられる30分から始めることになりました。
進め方はいたってシンプル。
コメントは任意ですが、ページ番号と一緒に気づいたことを残しておくと、当日の議論も進めやすくなります。当日はファシリテーターが参加者を指名して、内容の要約や感想を話してもらうことも。学校のテストではないので、正解を答える必要はなく、自分の言葉でアウトプットしてみることを大切にしよう！という共通認識のもとに進めます。
また、運営面でも少し工夫がされています。書籍の情報や読む範囲、参加者、各回の記録などは、社内のGitLabリポジトリに集約。できるだけ人の手を介さず、情報が残る仕組みを作っています。こういうところにも、ウミらしさが出ている気がします。
11月4日の第2回では、いよいよ本編に入り、第1章「理解しやすいコード」と第2章「名前に情報を詰め込む」を読みました。30分という限られた時間でしたが、思いのほか議論が盛り上がりました。
本書では、理解しやすいコードを「他の人が最短時間で理解できるコード」と定義しています。言われてみれば当たり前のようですが、実際にコードを書くとき、つい短くまとめることや、スマートに見える書き方を優先してしまうこともあるのではないでしょうか。
if文の早期リターンを使った書き方について話していた際には、三項演算子に複雑な条件を詰め込んでしまうケースについても話に上がりました。1行に収めることよりも、多少行数が増えても意図が明確に伝わることの方が大切。コードの行数だけで作業量を判断することの難しさにも話が広がり、普段何気なく書いているコードについて、改めて考えさせられる内容でした。
個人的に面白かったのが、関数名の付け方をめぐる議論です。本書では、不要な単語を省く例として「ConvertToString()」を「ToString()」にする、という話が出てきます。
これに対して一人のエンジニアから、「変換を伴う処理ならConvertを残した方がよいのでは？」「具体的な名前を付けるという方針と矛盾しない？」という疑問が。確かに、言われてみると気になります。
他のメンバーからは、「ToString」と書けば文字列への変換だと伝わるので、Convertがなくてもよいのではという解釈が紹介されました。一方で、英語のニュアンスや処理の意味合いによっては、Convertを残す選択もあり得るとのこと。ベテランエンジニアからは、$object->toString() であれば「object to string」と英文のように読めるので、かえって分かりやすいこともあるという補足がありました。
こうした話は、普段の業務では意外とじっくり話す機会がありません。一人の素朴な疑問から、それぞれの考え方や経験が出てくるのが読書会の面白いところだと感じました。
変数名の付け方についても、いろいろな意見が出ました。例えば、時間を表す変数なら秒なのかミリ秒なのかまで名前に含めておくと、後からコードを読む人にとって親切です。
また、英語の単語選びについても話題になりました。似た意味の単語でも、sendとdeliverではニュアンスが違いますし、英語に慣れていないと、どちらが適切なのか迷うこともあります。
そんな中、ベテランエンジニアから出てきたのが「伝わりにくい英単語なら、あえてローマ字にすることもある」という話。例えば国内限定のシステムであれば「estimate」と書かずに、あえて「mitsumori（見積）」と記載したり。判断のポイントになるのは、やはり「第三者が見たときに、理解しやすいかどうか」ということでした。
なるほど、確かに。英語として正しいことも大切ですが、コードを読む人にとって分かりやすいことはもっと大切なのだと気づかされました。
最近では、AIに処理の意図を伝えれば、変数名や関数名を提案してくれるようになりました。若手エンジニアからも、sendとdeliverのような似た単語のニュアンスを理解しておくことは大切だけれど、今はAIに相談できるので、命名で悩むことが減ったという話がありました。
他のエンジニアからも、AIが提案する名前は見やすく、参考になるという意見が。
ただ、そこであるメンバーが話していたのは、「良い名前を付けられるのは、たくさんのコードを読んできた人だからこそ」ということ。世界中のオープンソースのコードを学習しているAIが命名を得意とするのも、ある意味当然といえます。
AIの担う領域が広がっていく時代だからこそ、提案された名前の良し悪しを判断できる知識や感覚は、これまで以上に求められそうです。
ファシリテーターの菊池さんが「この章には何が書かれていましたか？要約してください、中井さん」「著者は何を言いたいと思いますか？では、南さん」と指名していく様子は、学生時代の国語の授業のようでした。普段の業務とは違った切り口からの議論は、大変興味深いものでした。
また、次回読む第3章〜第5章の内容を目次から予想していたときのこと。第5章「コメントすべきことを知る」について、あるエンジニアが以前社内レビューで指摘された経験から「『何でもかんでもコメントしない』と書いてあると思う」と話しました。すると、当時レビューをしたエンジニアから「実はリーダブルコードを読んだうえで伝えていたんですよ。懐かしい」という一幕も。
コードレビューで何気なく伝えられていることも、こうした共有の場を設けることで、経験豊富なメンバーが持っている知識や考え方を社内全体に共有できるのは、とても良いことです。
新人とベテラン、役職の違いに関係なく、同じ本を読んで、それぞれの視点から意見を出し合う。ひとりでは気づかなかったことに気づいたり、自分の考えを言葉にすることで理解が深まったり。こういう時間は、普段の業務とはまた違った刺激がありますね。
第2回を終えてみると、30分では少し物足りないという声もあり、次回からは読む範囲を少し広げることになりました。こうした進め方も、実際にやってみながら参加者の意見を取り入れて調整されていく予定です。
『リーダブルコード』の次には、IPAのセキュリティー関連の書籍や『世界一流エンジニアの思考法』など、技術に関する本が候補に挙がっています。さらに、『仕事に追われない仕事術 マニャーナの法則・完全版』やアサーションなど、コミュニケーションや働き方に関する本も候補です。技術力を高めることはもちろん、職種を越えて知識や考え方を共有できる場になっていくといいですね。
今回の読書会を通じて、改めて感じたのは、学ぶことに経験年数や役職は関係ないということ。知っている人が教えるだけ、誰かが一方的に学ぶだけの場ではありません。それぞれの知識や経験を持ち寄り、一緒に理解を深めていく場です。こうした小さな積み重ねが、チーム全体の力にもつながっていくはずです。
スタジオ・ウミでは、こうした学びや挑戦を楽しみながら、一緒に成長していける仲間を募集しています。技術が好きな方、新しいことを学ぶのが好きな方、そして何より、周囲のメンバーと一緒により良いものを作っていきたい方。ご興味を持っていただけましたら、ぜひ採用ページを覗いてみてください。最後までお読みいただき、ありがとうございました！
森山 智華
スタジオ・ウミ取締役。デザイナーとして15年以上のキャリアを持ち、Drupal の特性を踏まえた、開発のしやすさと美しさを両立する設計に定評があります。現在はデザイン業務を後進に引き継ぎ、経理・人事・採用などの総務業務を一手に引き受けてチーム全体をデザイン中。糸を紡いだり庭いじりをしたり、手を動かすアナログな時間が好きです。
小さなご意見も、私たちにとっては大きなヒントです！
ぜひ率直なご感想をお寄せください
この
Masters of Drupal Engineering.
人に、
