専門用語を使わずデザイナー向けにnpmの役割や働きを説明をする

## この記事の概要

デザイナーもフロントエンドを触るプロジェクトにおいて、こんな会話がありました。

デザイナー「新しくブランチ切ったら開発環境が動かなくなっちゃいました。」
私（この前のpull requestでライブラリが追加されていたなあ。）
私「一度`npm install`をしてもらって良いですか？」
デ「やってみます。動きました！」
デ「ところで`npm なんとか`をすることがよくありますけど、npmって何なんですか？」
私「パッと説明するの難しいですね。」

ということでデザイナー向けに説明する用の記事を書きました[^1]。

[^1]: 会話内容的に私がエンジニアっぽく振る舞ってしまっている気がしますが、私自身もデザイナーです。悪しからず。

:::note
話を具体的にするため、npmに絞って記載していますが、大抵のパッケージマネージャーは似た仕組みだと思います。npm以外のパッケージマネージャーを使っている際でも、適宜言葉を置き換えながら説明していただければ使えるとは思います。
:::

:::note warn
正しい言葉や仕組みを説明するためのものではなく、概念を伝えるための記事です。正確でない記載がある自覚はありますが、分かりやすさを重視していることをご了承ください。
:::

エンジニアへのメッセージ：似たようなコミュニケーションがあった際はこの記事を共有してもらえれば説明が楽かもしれません。

デザイナーへのメッセージ：npmって何なの？と思ったときにこの記事を読んでもらえば理解できるかもしれません。

## 結論

- 同じプロジェクトに関わるみんなが、同じツールを使うための仕組み
- ツールのバージョンを統一して、バージョンアップも共有するための仕組み
- ツール一覧だけを共有しているような状態で、インストールは各自でする必要がある

## 同じプロジェクトに関わるみんなが、同じツールを使うための仕組み

例えば以下のような仕事があったとします。

:::note
- チームでバナーを作る
- 1度作って終わりではなく、作ったものを日々更新する
- バナーのデータは色々な人が触る
:::

このとき、AさんはPhotoshopを使い、BさんはFigmaを使っていたらどうでしょうか？

それぞれのデータに互換性がないので、Aさんの作ったデータをBさんは開けません（逆もまた然りです）。
かと言って、同じバナーのPhotoshop用データとFigma用データを作るのは無駄過ぎますし、データの管理も大変です。

最終的にバナーが完成すれば過程はどうでも良いとも言えますが、チームで使用するツールを統一した方が確実に効率は上がります。

ただし統一するにしても「**このプロジェクトではPhotoshopを使います！**」と口頭で話しただけだとルールとしては弱いです。
例えば、今いるメンバーはちゃんと理解していても、新しく入ったメンバーは**うっかり**Illustratorを使ってしまうかもしれません。

そういった事態を防ぎ、みんなで使うツールを統一するための仕組みとしてnpmがあります。

あくまでイメージを伝えるための例え話で実態とは違いますが、次のような動きで統一化が図られます。

:::note
- プロジェクトのフォルダの中に「**ここで使用するツール一覧のファイル**」がある
    - 例として、Photoshopが記載されているとする
- そのフォルダの中でPhotoshopを立ち上げると通常通り使える
- そのフォルダの中でIllustratorやFigmaを使おうすると「そんなツールは存在しません」とエラーが出て起動しない
- よそで作ったIllustratorやFigmaのファイルを持ってきても「そんな拡張子は知りません」とエラーが出て格納できない
:::

個人がどうこうするのではなく、上記のようなイメージで、システムとして統一できるようになります。

## ツールのバージョンを統一して、バージョンアップも共有するための仕組み

無事に全員がPhotoshopを使うようになったとしましょう。
しかし、Photoshopでさえあれば良いわけではありません。

極端な話、チーム内で使っているバージョンに`CS3`と`CC 2024`が混在していたら大変なことになります。
`CC 2024`で作ったデータを`CS3`で開いたらどうなるのでしょう？
というか、開けるのかも分かりません。

というわけで、ツールそのものを統一した後に、使用するバージョンも揃えておく必要があります。

これも先ほどの話と同様で「**このプロジェクトではCC 2024を使います！**」と口頭で話しただけでは弱いです。
「プロジェクトAが`CC 2024`で、プロジェクトBが`CC 2023`」などのように、微妙に違う場合なんか、覚えていられるわけもありません。

またもやイメージ優先の話ですが、次のようにバージョンは統一されます。

:::note
- 先ほどの「**使用するツール一覧のファイル**」に、使うバージョンも記載されている
    - 例として、CC 2023が記載されているとする
- CC 2023のPhotoshopを立ち上げると通常通り使える
- CC 2022やCC 2024のPhotoshopを立ち上げると「バージョンが違うので動きません」とエラーが出てうまく動かない
    - 指定より新しければ良いということでもない
:::

このようにして、メンバーみんなが使うバージョンを固定できます。

ただし、一度バージョンを指定したからと、永遠に同じバージョンを使うわけもありません。
最新バージョンの新機能が便利だから使いたいとか、古くなり過ぎたらサポートが切れてしまうとか、色々な理由で使用バージョンを上げるタイミングは生まれます。

その場合は次のようにして使用バージョンを変更します。

:::note
- 「**使用するツール一覧のファイル**」のバージョンを書き換える
    - 例として、CC 2023からCC 2024に書き換えたとする
- 「**このプロジェクトで使うツールをインストールする**」というコマンドを実行する
- CC 2024のPhotoshopを立ち上げると通常通り使える
- もう、CC 2023のPhotoshopを立ち上げても「バージョンが違うので動きません」とエラーが出てうまく動かない
:::

## ツール一覧だけを共有しているような状態で、インストールは各自でする必要がある

こういった説明をすると、勘の良い人は「メンバーそれぞれがインストールしないで、最初から正しいバージョンのPhotoshopを配ってくれたら良いのに」といったことを言います。
実際、そういう仕組みであれば冒頭の会話にあった「なんか動かない→`npm install`のし忘れ」といった事態は防げる気もします。

ただ、その仕組みにしようとすると、次のようなことになります。

:::note warn
- Google Driveなどの共有フォルダを使っているとする
    - その中に複数のプロジェクトがある
    - プロジェクトごとに使うPhotoshopのバージョンが違っているとする
- フォルダの変更履歴の中に、Photoshopのソフトそのもののコードの変更内容まで記録されて、情報としてノイズになる
- 各プロジェクトフォルダにPhotoshopのソフトそのものが保存してある状態
    - ソフトは4, 5GBの容量→そんなのが複数あったら、あっという間にストレージ容量を食い潰す
:::

こういった状態にならないための仕組みとして、次のようになっています。

:::note
- 「**使用するツール一覧のファイル**」には、あくまでツールとバージョンだけが書いてある
- 各メンバーが「**このプロジェクトで使うツールをインストールする**」というコマンドで、ファイルの情報をもとにしてツールを追加したりバージョンアップをしたりする
:::

## おさらい

- 同じプロジェクトに関わるみんなが、同じツールを使える
- ツールのバージョンを統一して、バージョンアップも共有できる
- ただしツールのインストールは各自でする

## おまけ：正しい用語を覚えたい人向け

この記事で使った言葉と、本来の用語の対応表を載せておきます。

| この記事で使った言葉 | 本来の用語 |
| --- | --- |
| 使用するツール一覧のファイル | package.json |
| プロジェクトで使うツール | dependencies, devDependencies |
| 使うツールをインストールするコマンド | npm install |