give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

ソニックガーデンにおけるコードレビューの文化を若手と一緒に語りました #エンジニアtype

お知らせ

エンジニアtypeさんのサイトで『コードレビューは「間違い探し」でも「テスト」でもない。“気持ちいいレビュー文化”が育つチームに共通すること』というインタビュー記事が公開されました。

type.jp

この記事では僕だけじゃなく、弊社ソニックガーデンの若手エンジニア「ざっきー」も一緒に話をしてくれています。


どんな話をしたの?

いろいろ話をしていますが、たとえば以下のようなテーマをお話ししています。

  • コードレビューに対する誤解
  • “気持ちいいレビュー”を生む文化の作り方
  • 手戻りを減らす工夫
  • etc

ある意味、当たり前の話ばかりかもしれませんが、その当たり前を自分自身が実践できているか、そして自分の現場でもその当たり前を全員共有できているか、この記事を読んであらためてチェックしてみるといいかもしれません!

ベテラン視点だけではなく若手のリアルな視点も交えています

もともとインタビューの依頼を受けたのは僕一人だったんですが、編集者の人にお願いして弊社の若手エンジニアも入れてもらうことにしました。

というのも、僕みたいなベテランが一人で話しても、きっと偉そうな説教にしか聞こえないんじゃないか、と思ったからです。

コードレビューをテーマにした記事であれば、「コードレビューが怖い」と思いがちな若手エンジニアがターゲット層になると思います。
であれば、若手エンジニアの率直な感想も含めた方が、きっと読者のみなさんも自分目線で記事の内容を受け止めやすくなるはずです。

そんな思いを込めて、「ざっきー」も含めてもらうようにお願いしたのでした。
なので、若手エンジニア代表(?)の「ざっきー」の発言にもぜひ注目して読んでみてください!

まとめ

というわけで、今回のエントリではエンジニアtypeさんのサイトで紹介されたインタビュー記事を紹介してみました。

レビュアーであれ、レビューイであれ、コードレビューで何か迷いや悩みがある人は、ぜひこの記事を読んでみてほしいです。
そして、いいなと思ったら現場やSNSで本記事をどんどんシェアしてください!

みなさん、よろしくお願いします〜😄

type.jp

あわせて読みたい

弊社ソニックガーデンでは、「いいコード研究会」というエンジニアコミュニティを主催しています。
「いいコードとは何か」を探求するために、オンライン勉強会や動画配信で、実際のコードをコードレビューしています。
www.sonicgarden.jp

最近発売されたコードレビュー関連の書籍に関する書評記事です。
こちらもあわせてどうぞ。
blog.jnito.com
blog.jnito.com

【書籍連動企画】あなたの技術記事、添削してもいいですか?

これはなに?

あなたが書いた技術記事を僕、伊藤淳一が添削します!・・・という特別企画のお知らせです。

もうちょっとくわしく

あなたの書いた技術記事を僕が読んで、「ここがちょっとわかりにくいので、こうすればもっとよくなりそう」とか、「タイトルはこう変えると注目度が増すかも?」みたいなアドバイスをお伝えします。

頑張ってアウトプットしてるけど、自分の書いた記事がいけてるのか、いけてないのか、自分ではよくわからないので客観的な意見を聞いてみたい、という方はぜひこの企画にご参加ください!

ところであなたはだれ?

僕はRubyやRailsの話題を中心に、いろいろ技術記事を書いているエンジニアです。
エンジニアとして働きつつ、10年以上ブログやQiitaに技術記事をアウトプットし続けています。

いちおう、現時点ではQiitaのランキング1位です。

「プロを目指す人のためのRuby入門」という書籍も書いています。

ほかにもSoftware Design誌に寄稿したり、各種ITエンジニア向けWeb媒体に記事を寄稿したりしています。

自分で言うのもなんですが、アウトプット歴も長いですし、執筆した技術記事のわかりやすさには定評があるので、きっと良いアドバイスができると思います!

どんな技術記事を書いたらいいの?

基本的には何でもOKです!・・・と言いたいところですが、「何でもいい」と言われると困ると思うので、いくつか条件を書いておきます。

  • プログラミング言語や技術分野は問いません(RubyやRails以外の話題でもOKです)
  • 初心者向けの内容でも上級者向けの内容でもOKです
  • 公開先のサービスはなんでも良いです(QiitaでもZennでも個人ブログでも可)
  • 何かしら技術的な要素を含まれる記事を書いてください(私のキャリアについて、みたいな記事は対象外とします)
  • 大作じゃない方がいいです(添削が大変になるので💦)
  • ちょっとぐらいの隙のある出来の方がいいです(よく書けてます、終わり、だと企画の意義が薄れるので😅)

重要:添削内容は書籍で紹介させてもらうかも?

実は現在、僕はITエンジニアのアウトプットに関する書籍を執筆しています。

この書籍ではITエンジニア向けにアウトプットする際のコツやテクニックを紹介しているのですが、本書の1コンテンツとして、応募してくださったみなさんの記事と僕の添削コメントを書籍内で紹介することを検討しています。

具体的にどういう形で掲載するのかは未定ですが、「もしかしたら書籍に掲載されるかもしれない」という点を念頭において応募してください!

応募先はこちら!

技術記事を書いてネット上に公開したら、以下のGoogleフォームから記事のURLを貼り付けて送信してください。
なお、この企画のために新しい記事を書く必要はなく、過去に書いた技術記事でもOKです。
ただし、応募は1人につき1回でお願いします。

docs.google.com

書籍に載せる・載せないにかかわらず、後日僕から添削コメントを個人的にお伝えします!

応募締切

2025年7月14日(月)

ただし、応募が多数あった場合は早期に締め切る場合があります。

さらに:アウトプットに関するお悩みも同時募集しています

ITエンジニアのみなさんのアウトプットに関するお悩みも募集しています。
「何を書けばいいかわからない」「書く時間がない」「数本書いたけど長続きしない」「反応がなくてつらい」等々、アウトプットについてこんなことで困っている、こういうことをもっと詳しく知りたい、という場合は、その内容を以下のGoogleフォームから送信してください。

docs.google.com

こちらは1人何回でも送信OKです。
書籍内でできるだけみなさんのお悩みにお答えしようと思います!

まとめ

というわけで、今回は「書籍連動企画・あなたの技術記事、添削してもいいですか?」のご案内でした。
コードレビューならぬ、記事レビューですね。
「私の書いた記事を伊藤さんにレビューしてほしい」という方はぜひ!
たくさんの応募をお待ちしています〜😄

・・・で、その本はいつ出版されるの?

僕が執筆している「アウトプット本」は現在鋭意制作中です!
とはいえ、まだまだ時間がかかりそうで、早くてもたぶん2026年以降になりそうです💧
出版時期や書籍タイトルといった詳細は、決まり次第このブログで紹介しますね。
みなさん、お楽しみに!!

「なぜあなたの記事には「いいね」が付かないのか?」を解説してみた&Qiitaのスライド機能の感想など #QiitaConference

前回のエントリでもお知らせしたとおり、2025年4月23日に開催されたQiita Conference 2025で、「なぜあなたの記事には「いいね」が付かないのか?〜あるいは「いいね」よりも大事な技術記事の価値について〜」という発表をしました。

当日使った資料はこちらです。

qiita.com

いつもはKeyNoteを使ってスライドを作るのですが、今回は訳あってQiitaのスライド機能を使ってみました(理由は後述)。

タイトルのとおり、この発表ではQiitaに記事を書いてもなかなか「いいね」が付かない人たちに向けて、いいねが付かない理由と、どうすればいいねが付きやすくなるのかを解説してみました・・・と言いたいところですが、それは表向きの(?)テーマで、本当は「いいねのために記事を書いても仕方ないんやで」というメッセージが、この発表の真のテーマです。

なお、スライドは全画面表示にして、なるべく大きなモニタで見るのをお勧めします。
具体的にはこれぐらいのサイズ感です↓


Qiitaのスライド機能を使った理由

前述のとおり、今回初めてQiitaのスライド機能を使って登壇用の資料を作ってみました。
スライドモードについて | Qiita ヘルプ

なんで、KeynoteじゃなくてQiitaのスライド機能にしたのかというと、3〜4月は息子の大学入学準備にかかりっきりで資料作成のスタートが遅くなってしまったため、スライド作成に費やす時間を減らしたかったからです。
もう少し詳しく言うと、「自由度が高すぎるKeynoteだと、いつもの癖でスライドいじりに時間をかけすぎてしまうので、あえて自由度の低いQiitaのスライド機能を使って、自分自身に制約を課そうと考えたから」です。

決して、「発表のついでにみんなに「いいね」を付けてもらおうとしたから」ではありません!😅
(まあ、それはスライドを作ってる途中に「あ、そういえば💡」とひらめいたのですがw)

実際、マークダウンでちゃちゃちゃっとテキストを書いていったら8割方できてしまったので、初速は結構速かったですね。
ただし、「やっぱりここをこうしたい」といういつものこだわり癖が出てくると、逆にKeynoteのような自由度がないぶん、「うーん、どうしよう?」と頭を抱えることが多かったです。

具体的には以下のような内容です。

スライドの縦横比やサイズが固定されない

Keynoteだとスライドを新規作成するタイミングで縦横比やサイズが固定されますが、Qiitaのスライド機能はブラウザのウインドウサイズに応じて縦横比やサイズが変わります。
ですので、「このテキストや画像が画面内に収まるかどうか?」は、そのときどきのブラウザのウインドウサイズによって答えが変わってきます。

今回は「モニタの解像度=1280x828」「Chromeの拡大率=90%」という設定を当日の発表で使うことにして、その設定でプレビューしながらテキストや画像を収めるように調整しました。
でもKeynoteみたいに「スライドの枠はこれだけです!」と、最初から固定されている方がプレビューの手間がかからず楽ですね。

文字のサイズをむりやりCSSでいじった

デフォルトだと、以下のようにQiitaのスライド機能はリストの2段目以降も文字サイズが変わりません。

ただ、これだとメリハリが付かず、読みにくい気がしたので、「2段目のテキストサイズだけちょっと小さくする」という対応を入れました。
よ〜く見ると、「釣りタイトル」のような文字が少し小さくなっているのがわかるはずです。

これはどうやったのかというと、StylusというChrome extensionをインストールし、以下のようなCSSをqiita.comに適用しました。

.slideMode-Viewer_content ul ul {
    font-size: 0.85em;
}

ですので、この設定を入れておかないと、僕の環境とみなさんの環境では、若干スライドの見え方が異なる、という違いが発生します。

画像の上に文字を重ねられない

Qiitaのスライド機能はマークダウンベースなので、当たり前と言えば、当たり前なのですが、画像の上に説明用の文字を入れたりすることもできません。
ですので、予め画像の中に文字を埋め込んでおいて、それを貼り付けました。

たとえば以下の例では「ランキング1位」とか「投稿数388件」のような文字を事前に埋め込んだ画像をQiitaにアップしています。

ただ、これって「文字を埋め込んだ画像」を作成するためにKeynoteを使ったりしているので、本末転倒というか、それなら最初からKeynote使っとけよ、という気がしましたね😅

もともとは「そこまでスライドに時間をかけない」という意気込みでQiitaのスライド機能を使い始めたのですが、リハーサルを繰り返していると、「うーん、やっぱりここはこうしたい」という欲が出てきてしまって、余計に時間がかかることになってしまいましたw

その他、むりやりハックした箇所多数💧

以下のスライドを見てください。

何の変哲もない、文字とQRコードが貼り付けられたページに見えると思いますが、これってどういうマークダウンテキストを書いたかわかりますか?

答えは、こうです↓

## この記事(スライド)も「いいね」してね!😘<br><br>感想や質問もお気軽にどうぞ<br><br>![qr.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7465/ce15e11e-3bc9-43f2-9a11-1d42fbbc9958.png)

なんと、1つの見出しの中にbrタグと画像を全部詰め込んでいます!!

「こういうレイアウトで表示したいな〜」「でも、これどうやればいいんだ?」と、試行錯誤した結果、行き着いたのがこのやり方でした。
Keynoteならちょちょいのちょい!で、終わってたでしょうね〜。

というわけで、僕のように「どうあがいてもスライドの見せ方にはついこだわってしまう」というタイプの人間は、最初からKeynoteを使った方が良かったかもしれません😅

ですが、「そこまでスライドの見せ方にはこだわらない」「時間がないから時間最優先でスライドを作りたい」という人には、Qiitaのスライド機能は便利だと思います!

Qiitaのスライド機能のいいところ

なんかQiitaのスライド機能の悪口(?)ばかりを書いてしまったので、よかったところも紹介しておきます!

スライドに「いいね」を付けてもらえる

Qiitaのスライド機能は、通常のQiita記事の一種なので、普通に「いいね」や「ストック」ができます。
今回はQiita主催のイベントだったこともあり、視聴者にもQiitaユーザーが多かったと思われるため、記事にたくさん「いいね」を付けてもらえました。

一晩で通知欄も「99+」になってしまいましたw

発表を聞いてくれた人の反応がこうやってすぐに伝わってくるのは、登壇者としてとても嬉しかったです😄

スマホ表示でも意外と見やすい

もともとPC画面の表示しか考えずに作成したのですが、スマホで表示しても意外と見やすかったです。

これはブラウザのウインドウサイズに応じて縦横比やサイズが変わる点が、メリットとして働いた例ですね。

他の人に事前レビューしてもらいやすい

作成した資料を「限定公開」にしておけば、全体公開する前でもURLを渡すだけで関係者にレビューしてもらうことができます。

今回はQiitaの運営スタッフに「画面共有がうまくいかなかったときの保険」としてスライドを共有する必要があったので、この機能が役に立ちました。

しかも、こちらでスライドを変更して保存すれば、それがそのまま相手側の画面に即反映される点も便利ですね。
Keynoteとかだと、「何か修正を加えるたびに、KeynoteをPDFエクスポート → 何らかの方法で運営スタッフに向けてアップロード」みたいな手順を取らないといけなかったと思います。

まとめ

というわけで、今回のエントリではQiita Conference 2025で登壇してきましたよ、という話と、Qiitaのスライド機能についていろいろ語ってみました。

僕の発表を聞いてくださったみなさん、どうもありがとうございました!
当日聞けなかったという人も、おそらく後日動画が公開されると思うので、そちらをチェックしてみてください。

また、発表聞いたよ、スライド見たよ、という人で、まだ「いいね」を押してない方は、ぜひポチッといいねをよろしくお願いします!!

qiita.com

おまけ:実はこのスライド自体が「いいね」してもらいやすい工夫をしている

発表の中で「こんな記事はいいねしてもらいやすい」という話をしましたが、実はこのスライド自体がそのフォーマットに沿っていることに気づいた人はおられるでしょうか?

よかったらスライドを見ながら、「たしかにこのスライド自体もそうなってるやん!」と思ってもらえると嬉しいです 😆