0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@NekoByte(NekoByte)

Macで開発に使える無料ツール10選 ― 駆け出しエンジニアが実際に手放せなくなったもの

0
Posted at

はじめに ― 「ツールが多すぎてどれが本当に必要？」という壁

新しいプロジェクトを任されたとき、まず頭を悩ませたのは「何をインストールすればいいんだろう？」ということだった。Macはデフォルトで多くの開発向き機能を備えているものの、実際に手を動かし始めると「エディタはどれにすればいいのか」「デバッグはどうやってやるのか」など、選択肢の多さに圧倒されてしまう。特に、最初の数ヶ月は「自分だけが置いてきぼりにされているんじゃないか」という不安が募り、作業が進まなくなることもあった。

そんなとき、先輩エンジニアが「まずは無料で揃えるものから始めろ」と言ってくれたのがきっかけで、実際に使い続けている10個のツールに絞ってみた。ここでは、私が導入した順番と、なぜそれが「必須」になったのかをエピソード交えて紹介する。どれもインストールは簡単で、費用がかからないので、まずは試してみるだけでも開発環境が格段に快適になるはずだ。

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

最新ツール・トレンド情報をずんだもん×めたんが解説するYouTubeチャンネルを運営しています！
いいね、チャンネル登録してもらえると嬉しいです🙇‍♂️

ハジメル.dev: https://hajimeru-dev.vercel.app/

「ひとりで続けるのは難しい」「何から学べばいいか分からない」という方向けに、
プログラミングのマンツーマンレッスンサービス「ハジメル.dev」も運営しています。
未経験OK・オンライン完結・月額制/違約金なしなので、気軽に無料相談してみてください🙇‍♂️

海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
Hacker News の話題を日本語でサクッと追える「HackerNews 日本語まとめ & AI要約」
を個人開発しました！
技術トレンド収集に使ってもらえると嬉しいです🔥🙇‍♂️
→ HackerNews 日本語まとめ & AI要約: https://hn-matome-2ht.pages.dev/

「ニャンパイアサバイバー」というヴァンパイアサバイバーリスペクトのゲームを作成しました！
もしよろしければ遊んで頂けると嬉しいです😭

習い事教室の先生向けに、SNS 投稿・生徒募集・保護者通知の文章を AI で生成する Web サービス「おしらせAI」を個人開発しました。Next.js + Supabase + LLM で構成しており、無料で月 10 回まで試用できます。よければ触ってみてください。

→ おしらせAI: https://oshirase-ai.vercel.app/

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

1. Visual Studio Code ― カスタマイズ性と拡張機能で作業が楽になる

なぜVS Codeに辿り着いたのか

最初はMacに標準で入っているテキストエディタでコードを書いていたが、シンタックスハイライトが不十分で、エラーが出てもすぐに気づかないことが多かった。そんなとき、GitHubのリポジトリで見かけた「VS Code」の紹介記事を読んだ。無料であること、軽量なのに拡張性が高い点が魅力的だった。

具体的にどんな拡張機能を入れたか

  • Prettier: コード整形を自動化。毎回インデントを調整する手間が省け、プルリクエストのレビューがスムーズになった。
  • ESLint: JavaScript/TypeScriptの静的解析ツール。エラーがリアルタイムで表示されるので、実行前にバグを減らせた。
  • GitLens: Gitの履歴やブランチ情報をエディタ内で可視化。誰がどの行を書いたかすぐに分かり、コードレビューの際に「場違い感」を感じずに済んだ。

私の体験談と効果

導入直後は拡張機能が多すぎて重くなるのではと心配したが、必要最低限のものだけに絞ると軽快に動作した。実際に、Prettierを入れた翌日からチーム全体でコードスタイルが統一され、レビューコメントが「インデントが揃っていない」から「ロジックの方が気になる」へと変化した。これにより、自分の不安が減り、コードを書くこと自体が楽しくなった。

2. iTerm2 ― ターミナルの快適さが作業効率を左右する

なぜターミナルがボトルネックになったか

Macの標準ターミナルはシンプルすぎて、ウィンドウ分割や検索機能が不十分だった。特に、複数のプロセスを同時に走らせる必要があるときに、タブが増えて管理が煩雑になり、作業中に「どのタブがどのプロセスか分からない」という混乱が起きた。

iTerm2の主な機能と設定例

  • ウィンドウ分割: 水平・垂直に自由に分割でき、同時にサーバー起動とログ確認が可能。⌘ + D（水平分割）や⌘ + Shift + D（垂直分割）で瞬時にレイアウト変更できる。
  • 検索とハイライト: ⌘ + Fで過去の出力を検索。特定のエラーメッセージをすぐに見つけられるので、デバッグ時間が大幅に短縮された。
  • プロファイル: プロジェクトごとにカラースキームや起動コマンドを設定。例えば、Node.jsのプロジェクトではnpm startを自動実行させるようにした。
# ~/.zshrc に iTerm2 用のエイリアス例
alias srv="npm run dev"
alias db="docker-compose up -d"

私が体感した変化

iTerm2に切り替えてから、ターミナルでの操作が直感的になり、作業中に「どのウィンドウが何をしているか分からない」という不安が激減した。特に、Dockerコンテナのログを別ウィンドウで常に監視できるようになったことで、コンテナが落ちた瞬間にすぐに対処できるようになり、開発サイクルがスムーズに回るようになった。

3. Homebrew ― パッケージ管理がシンプルになると心が軽くなる

パッケージ管理の悩み

Macに新しいツールを入れようとすると、公式サイトから.dmgをダウンロードしたり、手動でパスを通す作業が必要になることが多く、バージョン管理も自分でやらなければならない。特に、Node.jsやPythonの複数バージョンを使い分ける際に「どのバージョンが実行されているか分からない」という場違い感に陥った。

Homebrewの基本コマンドと活用例

  • インストール: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
  • パッケージ検索: brew search <名前>
  • インストール: brew install <名前>
  • アップデート: brew upgrade

例えば、brew install ffmpeg と一行でマルチメディア変換ツールが入る。さらに、brew services start mysql でMySQLをバックグラウンドで起動でき、起動スクリプトを書かなくても済む。

失敗談と学び

最初は brew install node だけで完了と思っていたが、別途 nvm（Node Version Manager）を導入したくなり、環境が二重に管理されて混乱した。そこで「Homebrewはシステム全体のパッケージ、nvmはユーザー単位のバージョン管理」と使い分ける方針を決め、設定ファイル（.zshrc）に明確にコメントを書き込んだ。結果、バージョン切替がワンクリックででき、開発中の不安が減った。

4. Rectangle ― ウィンドウ管理で作業領域を最大化

ウィンドウが乱れがちな日々

デスクトップにたくさんのアプリケーションを開くと、ウィンドウがごちゃごちゃになり、必要な情報にたどり着くまでに余計な時間がかかっていた。特に、デバッグコンソールとブラウザ、エディタを同時に見たいときに、手動でサイズ調整を繰り返すのが面倒だった。

Rectangleの主要機能とショートカット例

  • 左半分/右半分: ⌥ + ⌘ + ← / ⌥ + ⌘ + →
  • 左上/右上/左下/右下: ⌥ + ⌘ + ← と ⌥ + ⌘ + ↑ の組み合わせで四角に配置。
  • 全画面: ⌥ + ⌘ + F

設定画面で「ウィンドウサイズのスナップ感度」を微調整し、MacBookの小さなディスプレイでも快適に使えるようにした。

私の実践例と効果

開発中は常にエディタを左半分、ブラウザを右半分に固定し、ターミナルは画面上部に小さく表示するレイアウトにした。これにより、コードを書きながら即座にブラウザで結果を確認でき、ターミナルでエラーログを追うというサイクルがシームレスに。結果として、1日の作業時間が約15%短縮できたと実感している。

5. Docker Desktop（無料プラン） ― 環境構築の手間を減らす

環境依存で苦労した経験

過去に、ローカルで動かしていたアプリが本番環境で動かないというケースがあった。原因はNode.jsのバージョンやデータベースの設定がローカルと本番で微妙に違っていたことに起因していた。環境差異が不安要素となり、デバッグに時間が取られた。

Docker Desktopの使い方と無料プランの範囲

  • インストール: Docker公式サイトから.dmgをダウンロードし、アプリケーションフォルダにドラッグ。
  • docker-compose.yml の例:
version: "3.8"
services:
  app:
    image: node:18-alpine
    working_dir: /usr/src/app
    volumes:
      - ./:/usr/src/app
    ports:
      - "3000:3000"
    command: npm run dev
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: mydb
    ports:
      - "3306:3306"
  • 起動: docker compose up -d でローカルと同一環境が即座に立ち上がる。

無料プランでもローカル開発に十分なリソースが確保でき、Docker Hub から公式イメージを取得できる点が魅力的だ。

私が得た学びと改善点

Dockerを導入したことで、チーム全員が同じ環境で動作確認できるようになり、「自分だけが環境構築で苦労している」という劣等感が解消された。また、Dockerfileの記述を通じて、インフラ側の知識も自然に身についた。最初は docker compose up が重く感じたが、不要なボリュームやキャッシュを削除することで軽量化できた。

6. Postman（無料版） ― APIテストを手軽に可視化

APIテストの壁

フロントエンドとバックエンドが分かれたプロジェクトで、手動で curl コマンドを書いてリクエストを送ると、パラメータを間違えるたびに「どこが違うんだ？」と焦ってしまった。テストケースが増えるほど、手書きのリクエストは管理が大変になり、テストが疎かになるリスクがあった。

Postmanの基本操作と便利機能

  • コレクション: 複数のリクエストをまとめて保存。プロジェクトごとにフォルダを作成し、バージョン管理と連携できる。
  • 環境変数: {{baseUrl}} のように変数化し、ステージごとに切り替え可能。テスト実行時に環境を切り替えるだけで済む。
  • テストスクリプト: JavaScriptでレスポンス検証を自動化。例:
pm.test("ステータスコードが200である", function () {
  pm.response.to.have.status(200);
});
pm.test("レスポンスにnameフィールドがある", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property("name");
});

実際に得た効果

Postmanを導入した最初の週で、フロント側のバグ報告が30%減少した。なぜなら、リクエストパラメータのミスが事前に検出できるようになり、デバッグの手間が減ったからだ。また、チーム内で「このコレクションを使ってテストしてください」という共有ができ、情報の齟齬が減り、作業の自信がついた。

7. Fig（無料プラン） ― ターミナルの補完で入力ミスを防止

入力ミスに悩んだ経験

ターミナルで長いコマンドやファイルパスを打つたびに、スペルミスやディレクトリの抜け漏れが頻発した。特に git checkout -b new-feature のようにブランチ名を打ち込むときに、既存ブランチと似た名前を間違えてしまい、余計な git branch -D 作業が増えていた。

Figの主な機能と設定例

  • コマンド補完: git や npm のサブコマンドをリアルタイムで表示。git checkout と入力すると、ローカルブランチ一覧がポップアップ。
  • ファイルパス補完: cd のあとにディレクトリ名を自動でサジェスト。階層が深いプロジェクトでも数キーで移動できる。
  • カスタムスニペット: よく使う長いコマンドをショートカット化。例えば、npm run storybook を sb と入力するだけで実行できる。

私の使用感と改善点

Figを入れた瞬間、ターミナルでの入力ミスが激減し、作業がスムーズに流れた。特に、git 系の操作ミスが減ったことで、リポジトリの履歴が汚れる心配がなくなり、心理的な負荷が大きく軽減された。無料プランでも十分な機能が提供されているので、まずは試してみる価値がある。

8. LottieFiles Desktop ― アニメーション素材を手軽に確認

アニメーションの取り扱いでの壁

フロントエンドで Lottie アニメーションを導入したとき、JSON ファイルのプレビューができず、実装したはずが期待通りに動かないケースが多発した。ブラウザで確認するたびにビルドが走り、時間が無駄に感じた。

LottieFiles Desktop の使い方

  • インストール: 公式サイトから .dmg を取得し、ドラッグでインストール。
  • ドラッグ＆ドロップ: JSON ファイルをアプリにドロップするだけで即座にプレビュー可能。
  • テーマ切替: 背景色やサイズを変更でき、実装環境に近い形で確認できる。

実践エピソード

プロジェクトでローディングアニメーションを5つ導入した際、LottieFiles Desktop で事前にプレビューしたことで、サイズが大きすぎるものやループ設定が不適切なものを事前に除外できた。結果として、ページロード時のパフォーマンスが改善され、ユーザー体験が向上したと同時に、デザインレビューでの指摘が減った。

9. Raycast ― キーボードだけで作業を完結させる

キーボード中心の作業ができずに時間がかかっていた

マウスでアプリケーションを切り替えたり、Finder でファイルを探したりするたびに、手がキーボードと離れ、作業の流れが途切れがちだった。特に、頻繁に実行するスクリプトやシェルコマンドを手入力していたため、入力ミスが頻発した。

Raycast の主要機能とカスタマイズ例

  • コマンドパレット: ⌘ + Space で呼び出し、アプリ起動やファイル検索が瞬時にできる。
  • スクリプトコマンド: 任意のシェルスクリプトを登録し、キーワードで実行できる。例として、git pull を gpull として登録。
  • 拡張機能: npm, docker, git などのプラグインが豊富で、ワークフローを統合できる。
# Raycast 用スクリプト例 (~/raycast-scripts/gpull.sh)
#!/bin/bash
git pull origin $(git rev-parse --abbrev-ref HEAD)

体感した効果

Raycast を導入後、マウスに手を伸ばす回数が約30%減少し、集中力が持続した。特に、ターミナルを開かずに gpull と入力してプルできる点が便利で、作業のテンポが上がった。無料プランでも十分に使えるので、まずはデフォルトのコマンドだけでも試してみると良い。

10. Slack（無料プラン） ― コミュニケーションの可視化で孤独感を解消

コミュニケーション不足が生む不安

リモートでの開発では、質問したいことがすぐに聞けずに「自分だけが分からないのでは？」という不安が募った。情報が散在していると、過去の議論を遡るのも手間で、同じ質問を何度も繰り返すことになりがちだった。

Slack の活用テクニック

  • スレッド: 質問ごとにスレッドを立て、議論を一本化。検索しやすくなる。
  • ピン留め: 重要なリンクや資料をチャンネル上部に固定し、誰でもすぐにアクセスできる。
  • リマインダー: /remind me to review PR #123 in 2h で自分やチームにリマインドを設定。忘れがちなタスクを逃さない。

私の経験と学び

Slack のスレッド機能を徹底的に使うようにした結果、過去の質問が検索しやすくなり、同じ疑問で悩む時間が大幅に減った。また、リマインダーで PR のレビューを忘れずに行えるようになり、チーム全体のレビューサイクルが速くなった。無料プランでも機能は十分で、情報の透明性が高まることで「場違い感」や「孤立感」が和らいだ。

まとめ

今回紹介した10個の無料ツールは、どれもインストールがシンプルで、すぐに日常の開発フローに組み込めるものばかりだ。最初は「ツールが多すぎて混乱するんじゃないか」という不安があったが、実際に一つずつ導入し、使い方を自分の作業スタイルに合わせてカスタマイズしていくうちに、作業効率が上がるだけでなく、心理的な負担も軽くなったことを実感できた。

ポイントは「まずは無料で試す」こと、そして「自分に合わないと感じたらすぐに別のツールに切り替える」柔軟さだ。 すべてを一度に揃える必要はない。自分が最も苦手としている作業（エディタ、ターミナル、環境構築、コミュニケーションなど）から一つ選び、実際に使ってみよう。

ツールが増えると管理が面倒になることもあるが、Homebrew で一括管理したり、Raycast のようにキーボードショートカットで呼び出す仕組みを作れば、逆にシンプルに保てる。

駆け出しのうちは「完璧な環境」を求めすぎず、まずは「今の自分が少しでも楽になる」ことを目指してみてほしい。ツールが手助けしてくれることで、コードを書く楽しさやチームとの協働がもっと身近に感じられるはずだ。これからも新しいツールが出てくるたびに試し、最適な開発環境を自分で作り上げていこう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?