はじめに

弊社ソニックガーデンの社内勉強会で、「個々人が実践している生産性向上の取り組みをお互いに共有し合おう」という勉強会が開かれました。

ちゃんとした準備時間が取れず、勉強会の10分前ぐらいに「そりゃー」と思いついたものをバババッと書き出したのですが、いくつかみなさんの参考になるものもあるかもしれないので、こちらでもシェアしてみます。

簡単に取り入れられそうなライフハック的なテクニックからそうでないものまで、とりあえず僕が思いついた内容を雑多に書き出したので、よかったら参考にしてみてください！

ググるキーワードが思いつかないときは生成AIに聞く

メソッドの仕様とかは「Ruby prepend」みたいなキーワードでググるのですが、「○○を△△する方法」みたいな問いはググっても意図したページを探し当てにくいです。

そういうときはChatGPTに雑な文章を放り込んでやり方を尋ねたりします。

ただし、ChatGPTの回答は間違いが含まれる可能性があるので、「その回答は間違ってるかもしれんぞ」と自分に言い聞かせるのが大事です。

完璧な答えを求めるより、「答えを見つけるためのとっかかりを得たい」というのがChatGPTを使う一番の理由ですね。

なお、ChatGPTだけでなくPerplexityという生成AIも時々使います。

この生成AIは参考文献（参考URL）付きで教えてくれるので、AIの回答の根拠を確認したいときに便利です。

よく指摘するレビューコメントは記事にしておく

コードレビューをしていると、「これ、この間も別の人に同じことを指摘したぞ？」と思うときは、その内容をQiitaやブログに記事として書いておきます。

そうすると、次回同じ指摘をしたくなったときに「詳しくはここを読んでね」で済むのでレビューコメントを打ち込む時間の短縮になります。

なお上のスクショで紹介しているのは、こちらの「【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法」という記事です👇

記事を書けばエンジニアとしてのアウトプットにもなるので一石二鳥ですね。

自動テストを回しながら機能実装する

テストコードを書くのは面倒くさい、テストコードなんて書かない方が速く開発できるのに、と思ってる人はいませんか？

そんなことはないですよ！

テストコードを「自動実行プログラム」と考えれば、テストコードも生産性を向上させる便利ツールになります。

たとえば、ユーザーの新規登録（サインアップ）画面に新しい機能（ユーザー登録完了時にありがとうメールを送信する機能など）を追加するケースを考えてみてください。

リロードすれば何度でも再実行できる一覧画面とは異なり、ユーザーの新規登録ができるのは新規登録時の1回きりです。

動作確認するたびに新しいユーザーを新規登録しないといけないので、開発用のデータベースには

新規ユーザー1
新規ユーザー2
新規ユーザー3
……以下略

のように、動作確認のためだけに作った「新規ユーザー」さんがどんどん追加されていきます。

ユーザーの新規登録画面がウイザード形式になってたりすると、動作確認のたびに、画面1、画面2、画面3を遷移しないといけないかもしれません。
入力の必須項目が多かったりすると、毎回必須項目を埋めるだけでも時間を取られてしまいます。

こういうときは先にテストコードを書いてしまいましょう。
テストコード上でユーザーを新規登録するシナリオ（E2Eテスト）を書いてしまうのです。
こうすればボタンひとつで何度でも新規ユーザー登録を繰り返すことができます。

たとえば、テストコードを活用する場合、実装の流れは以下のようになります。

最初から最後まで新規ユーザー登録できるテストコードを書く
ありがとうメールが送信されたことを検証するテストコードを追加する
テストが失敗することを確認する
ありがとうメール送信機能を実装する
テストがパスすることを確認する
必要に応じてリファクタリングをしたり、メールの文面を改善したりする
実際にブラウザ上で動作確認する（人間の手と目を使った最終の動作確認）

こうすれば毎回ブラウザ上で、必須項目の入力を繰り返したり、「新規ユーザー41」さんを作成したりしなくて済みます。

同じような話はその昔「Tama Ruby会議01」でお話したので、こちらもご覧ください。

なぜかCIでしか発生しないエラーは専用のブランチでデバッグする

たまに自分のローカル環境ではエラーにならず、CI（GitHub Actions等）でしかエラーが発生しないことがあります。

こうなると原因や解決策を探るための試行錯誤をCI上で行うしかありません。
こういう場合、僕は以下のような手順を踏みます。

試行錯誤用のブランチ＆プルリクを作る
RSpecのfocusタグを使って、落ちるテストだけを実行対象にする
並列で実行している場合は並列数も1にする
エラーが解決するまで思う存分試行錯誤する
問題が解決したら、元のブランチで変更を適用する
試行錯誤用のブランチとプルリクは削除する

この方法のメリットは以下の通りです。

テスト全体を回すのではなく、実行対象のテストを絞り込むので、CIの実行が短時間で終了する
試行錯誤用のブランチでいくら試行錯誤してもmainブランチのコミット履歴が汚れることはない

テキストで伝えにくい内容は口頭で話す

弊社ソニックガーデンのメンバーは全員リモートで働いています。
ですので、コードレビューコメントなども基本的にテキストで伝えます。

しかし、以下のような場合はテキストは不向きです。

コメントしたい内容が複雑で、テキストで伝えようとするとものすごく時間がかかる場合
書き方に気を付けないと相手を責めるような物言いになって角が立ちそうな場合

「あー、これテキストで書こうとしたらめっちゃ時間かかるやつだわー」と思ったら、「今ちょっといい？」と声をかけて1対1のビデオ会議を始めます。

口頭で話した方が速く終わりますし、ニュアンスもよく伝わるので相手の気分を害しにくいです。

応用：レビューコメントを動画で残す

何らかの理由で相手と1対1で話すことができない場合は、動画でレビューするのも有効です。

ざっくりとした流れは以下の通りです。

QuickTime Playerの画面収録機能などを使って、画面を表示しながら口頭でレビューコメントを収録する
保存した動画を社内の共有ドライブに保存する
レビューコメントで動画ファイルのURLを伝える

動画レビューをもらった人に感想を聞くと「動画でコメントしてもらうとよくわかるし、ニュアンスも伝わりやすい」と好評ですね😄

画面共有時「そこのボタンを〜」と話す代わりにペン（注釈ツール）を使う

Zoomで1対1で話すとき、相手が画面共有しているときに「あ、そこのボタンをクリックしてみて」「いや、それじゃなくてもうちょっと右の・・・」「あ〜、いきすぎいきすぎ！！」みたいなことになってイライラしたことはありませんか？

Zoomにはこちらから相手の画面に対して手描きの文字や印を書き込む注釈機能があります。
これを使えば「このボタンをクリックして！（ペンでぐるぐる）」というふうにさくっとコミュニケーションが取れます。

早急に手を動かさない

銀の弾丸でもなんでもないですが、なんだかんだで手を動かす（＝コードをいじる）前にしっかり情報収集して、しっかり設計してから手を動かすことが、速く開発するコツじゃないかと思います。
急がば回れ、ってやつですね。

詳しい話は以下の記事に書いたので、こちらをご覧ください。

若いエンジニアほど「プログラマの仕事は手を動かすことだ」「できる人は常に手が動き続けている（常にコードを書き続けている）に違いない」と思うかもしれませんが、業務レベルの巨大なシステムになると「じっくり調べる＆じっくり設計する」という作業の方が、コードを書く時間よりも圧倒的に長かったりします。

正常系の実装が終わった時点でフィードバックをもらう

大きなタスクの場合は最後まで一気に完成させようとせずに、正常系のシナリオが一通り動くようになった段階で、顧客や開発リーダーにプログラムの動きを見せてフィードバックをもらうようにしましょう。

これは何のためかというと、手戻りを防ぐためです。
致命的な勘違いや認識の相違があったりすると、手戻りが発生します。
最後まで作りきってしまった段階で問題が発覚すると、手戻りが半端なく大きくなってしまいます。

手戻りはない方がよいですが、もし手戻りが発生するとしても、早めに引き返せる方がダメージが少ない（＝時間的ロスが少ない）です。
なので、正常系の最もシンプルな処理フローが一通り動くようになったあたりで途中経過を報告するのが一番良いと思います。

この話は前述のQiita記事にも書いているので、こちらもあわせてどうぞ。

一人で悩まない、ハマったら誰かに頼る

「ヤバい、これは完全にハマってるぞ」とか「3時間経過したけど、全然進捗してない。やべ〜」みたいな経験はないですか？

そんなときはどうするか？
　↓
同僚や先輩を頼りましょう！

一人で悩んでいても同じところでぐるぐる無限ループしてしまうだけです。

「あのー、すいません。ちょっとハマってるんで一緒に見てもらえませんか？」と声をかければ、きっとその無限ループから抜け出せるはずです。

相手の時間を奪ってしまうから申し訳ない、と思う人もかもしれませんが、あなた一人が悩んで3日浪費するよりも誰かに聞いて30分で終わる方が、チーム全体として見たときの生産性は間違いなく高くなります。

また、普段からチーム内で、

「困ったときはお互い様だから気軽に聞こうね」
「でも、どうしても忙しいときは「ごめん、ちょっとあとしてもらえる？」と返事してもOKだよ」

という合意を取っておきましょう。
そうすれば誰かに頼るときのハードルも下がるはずです。

誰も頼る人がいなかったら？→一度パソコンから離れましょう

誰も頼る人がいなければ、いったんパソコンの前から離れてください。

たとえば以下のような行動を取ると良いでしょう。

トイレに行く
飲み物を買いに行く
外を散歩する
昼寝をする
ご飯を食べる
お風呂に入る
その日はもう寝る

しばらくパソコンの前を離れてまた戻ってくると、まったく違う観点が生まれてあっという間に解決したりすることがよくあります。

体調を整える（休息を十分にとる）

プログラミングは頭を使う仕事です。
体調が悪かったり、眠かったりすると脳の働きが鈍くなって十分なパフォーマンスが出せません。

「こんな状態でコードを書いても全然パフォーマンスが出ない気がするぞ？」と思ったら、いったん休憩をして体調を整えてください。

そしてスッキリした頭でバリバリコードを書きましょう！

できるだけまとまったコーディング時間を確保する

同じ2時間でも、連続した2時間と、間にミーティングが挟まって細切れにされた2時間ではプログラミングの効率が全然違います。

プログラマのみなさんには言わずもがなだと思いますが、「連続した2時間」の方が圧倒的に効率が良いはずです。

ですので、なるべくまとまったコーディング時間を確保するようにしましょう。

「この時間空いてるよね？ミーティング入れていい？」と聞かれたら、「はい、どうぞ」と答える前に前後の予定を確認してみてください。

「あ、ここにミーティングを入れられるとコーディング時間が中途半端に分断されてしまうぞ？」と思ったら、ミーティングの日時を変更できないか交渉してみましょう。

応用：隙間時間で終わらせるタスクを用意しておく

上に書いたとおり、プログラミングをするときはできるだけまとまった時間を確保することが大事です。

しかし、ミーティングを完全にゼロにすることはできないので、どうしても「今からコーディングを始めても10分後にミーティングが始まるからコーディングしづらい」というケースは出てきます。

こういうときは「隙間時間でこなせる小さなタスク」を用意しておいて、それをミーティングが始まるまでに終わらせましょう。
逆に言うと、隙間時間で終わらせた方がいい小さなタスクはコーディング中に対応しない方が良い、ということを意味します。

たとえばコーディング中にSlackでメンションが飛んできても、チラッと通知を見て今すぐ反応しなくても大丈夫そうな内容であれば、対応は後回しにします。
コーディング中はコーディングだけに集中し、貴重な「まとまった時間」を自ら細切れにしないようにしましょう。

なお、こういった日々の業務における生産性向上のテクニックは「エンジニアのための時間管理術」という本にたくさん載っているので、こちらを読むのもお勧めです。

脳のバッファからはみ出る情報は紙にメモする

「私は天才なんで脳内にいくらでも記憶できます！」という人はいいのですが、僕の脳みそはバッファがかなり小さいので、大きなプログラムを読んでいると、すぐに「えーっと・・・あれ？さっき見てたクラスはなんだっけ？」と思い出せなくなってしまいます。

そういうときはいつも手元に置いている紙とペンを使います。

覚えきれない情報は紙の上にメモっていくと、脳のバッファが枯渇しても紙に情報が残っているので大きなプログラムも解析しやすくなります。

また、パソコンだとどうしてもテキスト形式のメモになりがちですが、紙とペンがあれば雑な形でも図をスラスラ書ける、というのも大きなメリットですね。
僕はテーブル同士の関連を確認するために簡易的なER図を紙の上に書くことがよくあります。

「プログラマならオールデジタルでしょ！紙とペンみたいなアナログなツールを使うなんて！！💢」

・・・みたいなプライドは捨てて、デジタルでもアナログでも、使えるものはなんでも使いましょう。

応用：コードを紙に印刷する

同じ理由で僕はときどきコードを紙に印刷して、既存のロジックを解析することがあります。

コードを印刷すると、「ここのメソッドがここで呼び出されて、そのメソッドを呼んでいるのがここで・・・」と紙にどんどん記入していけるので、コードの解析が捗ります。

というわけで、プリンタを持ってない人は、一台プリンタを買いましょう🖨️

未来の自分に引き継ぎメモを残す

前述の通り、僕は記憶力が悪いです。
月曜日の朝に先週の仕事の続きをやろうと思っても、「あれ、先週は何やってたっけ？そして今日は何をすればいいんだっけ？」というのが全然思い出せません。

なので、僕はいつも金曜日の仕事終わりに「ひきつぎメモ」を残します。
メモに書き残すのは、

今週はここまでやった
次はここからやる

という、ただそれだけの内容です。
ですが、これがあるかないかで「先週の記憶のローディング時間」が圧倒的に短く済みます。

エディタの操作や機能に習熟する

自分が使っているエディタの機能を存分に使いこなしているかどうかも、開発効率に大きな影響を及ぼします。
具体的に何？と言われると無意識にやってることも多くて具体例はぱっと挙げづらいのですが。

個人的にはVimコマンドを覚えるのがお勧めですね。
Vimはコードを編集するのに便利な編集コマンドがたくさん用意されており、このコマンドを知っていれば知っているほど、コードを素早く編集できます。

たとえば、矩形選択（くけいせんたく）なんかは開発効率を大きく左右する便利機能の一つです。

Vim初心者の人はまずこの記事を読んで、Vimの便利コマンドを習得していきましょう。

VSCodeやJetBrains系のIDEでもVimコマンドを使えるプラグインが用意されています。
今使っているエディタを捨ててVimに乗り換えろ、という意味ではないので誤解のないように。

編集コマンドだけでなく、エディタやIDEの便利機能をたくさん知っておくことも重要です。
たとえばJetBrains系のIDEにはgitを便利に操作できる機能がたくさん用意されています。
なので、僕はgitのコミットやプル、プッシュは全部RubyMine上で実行しています。

特に、コンフリクトしたコードのマージはめちゃくちゃ便利なので、この機能なしではコンフリクトしたコードを触りたくないですw

エディタのファイルメニューやヘルプページをチェックして、自分の知らない便利機能が隠れていないかチェックしてみましょう。

👇まだ知らない機能がたくさんあるかも！？

応用：長文はエディタで書いて、ブラウザやSlackにコピペする

ブラウザのテキストエリアやSlackの入力欄は長文を打ち込むのに向いていません。
理由は以下の通りです。

入力欄のサイズ的に一度に表示できるテキストが少ない
うっかりブラウザを閉じると入力していた内容が消える
サービスによってはリターンキーを押すと書きかけの文章が勝手に投稿されることがある
単純なテキスト編集しかできない

なので僕は長文を打ち込むときはVimのようなテキストエディタを使って、それをブラウザやSlackにコピペします。
こうすれば、以下のようなメリットが得られます。

画面を広々使えるので、テキスト全体を見渡せる
うっかりアプリを閉じそうになっても「終了しますか？」のアラートが出る
書き終わったテキストをブラウザやSlackにコピペするまで投稿されることはない
便利なVimコマンドを活用しながらテキストを編集できる

詳しくは以下のブログ記事にまとめたのでこちらをどうぞ。

ショートカットを活用する（≒マウスを触るな）

「エディタの操作や機能に習熟する」に近しい話ですが、OSやエディタには様々なショートカットキーが用意されています。

普段あなたがマウスでポチポチやっている操作も、実はマウスに一切触れずにキーボードだけで実現できる可能性が高いです。

たとえばmacOSであれば、「コマンド + タブ」でアクティブなアプリケーションを切り替えることができます。
マウスでポチポチとウインドウをクリックするよりも、コマンド＋タブで切り替えた方が圧倒的に速いはずです。

もしあなたが今、macOSのChromeやSafariでこの記事を読んでいるなら、「コマンド + L」を押さえてみてください。
URL欄にフォーカスが移り、検索したいキーワードを検索することができます。

・・・等々、ショートカットキーを知っていれば知っているほど、キーボードから手を離さずにコードを書いたり調べ物をしたりすることができます。

「マウスに触ったら負け」をマイルールにして、ふだん使えていないショートカットキーを探す修行をしてみましょう。

参考：生産性UP！開発テクニック・操作Tips集

僕がメンターをやっているフィヨルドブートキャンプで作成したTips集があります。
便利なショートカットがたくさん載っているので、こちらもぜひ参考にしてみてください。

デバッガを活用する

デバッガ使ってますか？

ここでいうデバッガとは、プログラムにブレークポイントを設定し、実際にコードを動かしてブレークポイントでコードを停止し、ステップ実行しながらコードの動きや変数の中身をチェックできるツールを指します。

たとえばRubyであれば、debugライブラリ（debug.gem）があります。
これを使うとターミナル上でRubyプログラムをデバッグ実行できます。

しかし、個人的にはエディタやIDE上でデバッガを使った方が、簡単にブレークポイントを設定できて、なおかつデバッグ時の情報量も多くなるのでお勧めです。

前述のdebug.gemはVSCode用のエクステンションを使えば、VSCode上でデバッグ実行できるようになります。

僕は普段RubyMineを使っているので、RubyMineのデバッガを使っています。
RubyMineのデバッガもめちゃくちゃ簡単＆便利ですね。

ブラウザ内で実行されるJavaScriptをデバッグするときは、ブラウザの開発者ツールを活用しましょう。

ここで言う「デバッガ」とは若干異なりますが、Vue.js devtoolsのようなChrome用エクステンションもうまく動かないVue.jsコンポーネントのデバッグに役立ちます。

プログラミング初心者の人は、うまく動かないコードを前にして「なぜだ、なぜだ〜！」と頭を抱えている人が多いかもしれませんが、穴が空くぐらいコードを眺めるよりも、デバッガを使ってデバッグ実行した方が問題解決のスピードが圧倒的に速くなるはずです。

デバッガを使ったことがない人は、ぜひデバッガを使ってみましょう！

その他、効率良くデバッグするための知識あれこれ

コードを書く速さだけではなく、うまく動かないコードをちゃんと動かすためのデバッグの速さも生産性を左右する大きな要因です。

デバッグのテクニックについては以下の記事でいろいろ説明しているので、よかったらこちらも読んでみてください。

コラム：先輩や同僚の画面を見せてもらおう

生産性向上のテクニックとして、ここまで以下のようなTipsを紹介しました。

エディタの操作や機能に習熟する
ショートカットを活用する（≒マウスを触るな）
デバッガを活用する

しかし、この手のテクニックは独学では結構習得が難しかったりします。
というのも、「○○を使うとxxする代わりに△△ができる」というテクニックは、「○○を使うと△△ができる」という情報を前もって知らないと、これからもずっと「xxする」を続けてしまいがちになるからです。

なので、独学ではなく、他の人の力を借りながらそのテクニックを習得しましょう。

たとえば、もしあなたが経験年数の少ない若手のプログラマなのであれば、周りの先輩プログラマに「すいません、先輩がコードを書くところを見せてください！」とお願いしてみてください。
そして、画面を見せてもらいながら、気になるテクニックが出てきたら「今のそれ、どうやったんですか？」とか「そのツール、何ですか？」と、先輩に質問しましょう。

先輩に声をかけるのはハードルが高い、というときは、同僚を巻き込むのも一手です。
たとえば同僚と一緒にモブプログラミングをやってみましょう。

モブプログラミングでは一定時間でドライバー役を切り替えるので、同僚が使っている便利なショートカットや便利機能をチェックすることができますし、自分がドライバーをするときは他の同僚から「それ、こうやった方が便利だよ」とお役立ち情報を教えてもらえるかもしれません。

他にも「私だけが知っている？ショートカットキー古今東西ゲーム！」みたいなイベントを開くのも面白いかもしれませんね。
何人かで集まって、古今東西ゲーム方式で自分の知っているショートカットキーを順番に挙げていったりすると、楽しみながらみんなの知見をどんどん吸い上げることができそうです。

生産性向上のテクニックは往々にして暗黙知化しやすいので、こういった取り組みを通じて集合知＆形式知にしていきましょう。

まとめ

というわけで、この記事では僕が会社の社内勉強会で話した「生産性向上の取り組み」をあれこれ書いてみました。

ばーっと思いつくものを挙げただけなので、まだ他にも「そういえば」と追記したくなる内容が出てくるかもしれません。
この記事を「ストック」してもらうと、新しい内容を追記したときに通知を送るようにしますので、よかったらこの記事のストックをお願いします（あとできたら「いいね」も！）。

この記事がみなさんの生産性向上のヒントになれば幸いです😄

おまけ

「社内勉強会」と書きましたが、これは正確に言うと弊社ソニックガーデンのお客さまである、NRIセキュアさんの開発メンバーと一緒に実施した「開発チーム内勉強会」の話なのでした。

弊社ソニックガーデンがどういう形でNRIセキュアさんの開発と運用を担当しているのかは以下の記事に詳しくまとめられています。
興味がある方はチェックしてみてください！