このシリーズの目的と免責事項
本シリーズでは、ITの技術や概念をできるだけ身近な例に置き換えて紹介し、「なるほど！」と感じてもらうことを目指しています。
筆者は「技術インストラクター」という立場上、複雑な内容をわかりやすく伝えることの重要性を日々痛感しています。
例え話はすべての人に刺さるとは限らないかもしれませんが、広い心で読んでいただけると嬉しいです。
本記事で取り上げること／取り上げないこと
本記事では、IT業界において主にソフトウェアのソースコードの変更管理に使われることが多いバージョン管理システム(Version Control System)について、身近な例えを交えながら考えていきます。
想定読者は次のような方々です：
- バージョン管理システムって何？と思っている方
- Gitって何？(関連事項としてGitHub、GitLabって何？)と思っている方
- Gitを活用したインフラの仕組みにこれから関わっていきたい人
なお、本記事は「Gitの使い方」や「GitHubやGitLabなどの使い方」といった技術的な具体論には踏み込まず、あくまでなぜ使うのか？という利点や考え方に焦点を当てています。
このため、Gitが持つあらゆる機能を紹介するわけではないため、熟練者からすると断片的な情報に見えるところはあると思いますが、あくまでも焦点としては『なぜ情報の一括管理、集中管理、バージョン管理があると助かるのか』という点に主軸を置いているのでその点を念頭に置いていただけると幸いです。
筆者自身の経験に基づく視点も含みますので、「そういう見方もあるのか」と気軽に捉えていただけると嬉しいです。
そもそも電子棚札とは何なのか？
皆さんも一度くらいはスーパーマーケットなどのいわゆる小売り店舗で買い物をしたことがあるでしょう。
最近様々な小売店で、商品棚をよく見ると次のような値札を見かけることが増えました。
(引用: https://dcross.impress.co.jp/docs/usecase/002526.html)
(引用: https://business.ntt-east.co.jp/bizdrive/column/dr00121-021.html)
電子棚札は、商品の価格や名称などを紙ではなく電子ペーパーで表示するためのものです。
筆者である私自身、直感的にはこの仕組みはとても効率的であり、技術をうまく実生活に取り入れられているなと感じました。
紙の値札の場合、次のような課題があるためです。
紙の値札の課題(=手作業/マニュアルでの変更管理)
- 紙の値札を書く人によって読みやすさが異なる(フォームや文字の大きさ、綺麗さに差が出てしまう)
- 店舗ごとで誤って異なる情報を掲載してしまう可能性がある(同じ商品なのに、値段や名称を誤記載してしまう)
- そもそも現在の値札が最新なのか、更新が必要な古いバージョンかの判別がつけられない
このように、紙を主体とした管理にはいくつもの異なるチャレンジが存在します。
電子棚札の利点は？
電子棚札を使用すれば、上記の課題は次のように解決が可能です。
- 商品名や値段の情報を電子棚札に配信することで、情報を掲載ができる(統一されたフォーム)
- 複数の店舗だとしても、同じ情報を同期すれば良い(店舗ごとに一貫性を持たせられる)
- 配信するデータそのものに、日時情報をを付与すれば最新かどうかわかりやすい(情報のバージョン管理)
このように、商品名や価格などの情報をデータ化しかつ集中的に管理をすれば、マニュアルで行なってきた際に生じた課題を解決できます。
まとめてみるとこうなります。
| 紙の値札の課題 | 電子棚札による解決方法 |
|---|---|
| 人によって書き方にばらつきがある | 統一フォーマットで自動配信される |
| 店舗ごとで情報の誤りが生じる | 中央から同じ情報を全店舗に配信できる |
| 最新かどうか分からない | データに日時がついておりバージョン管理が可能 |
それだけではなく、次のような更なる利点もあると言えるでしょう。
- 店舗担当者が値札を書き直す作業をしなくて良い(ビジネスの効率化)
- 第3者が値札を不正に書き換えることを防げる(セキュア)
- 紙やペンを使用しないため、エコである(SDGs的な視点)
なお、電子棚札の利点については次のページにもまとまっています。
こうした「情報の見た目・正確性・バージョン」がバラバラになる問題は、ITの現場では日常茶飯事です。
ITにおけるマニュアルでの変更管理とその課題
実は、こうした課題はITの現場でもよく見られます。
例えば、ソースコードや業務手順書など、複数人で編集・更新する「情報」は紙の値札と同じように管理が難しいのです。
ソースコードの手動管理
アプリケーションのソースコードを複数名で別々のコンピューター端末から書くと、どの行を残すべきか、どの行を消すべきかを各自でコミュニケーションをとりながら連携しないといけない(これを行わない場合、不要なコードの行が残ったり、必要なコードの行が欠損してしまったりして、アプリケーションのバグなどを産んでしまう)
作業手順書の手動管理
作業手順書ガイドを更新する場合に、Wordなどの文書管理ツールを使用して、複数名の異なるPCでそれらを読んだり更新をすると、どのPC(誰のPC)に存在する作業手順書ガイドが最新の情報を含んでいるのか判別が難しくなってしまい、不要な作業を行なってしまったり、必要な作業が抜けてしまったりして、作業現場では作業ミスが発生してしまう。
課題の解決策＝集中管理
値札の管理を、紙から電子棚札に変えた際のポイントは次の2つでした。
- 商品に関する情報を電子化
- 情報の集中管理
図内の真ん中をご覧いただけると、電子棚札内に配信をするデータは、クラウド(雲の絵)で管理されており、
安全な通信網(VPN)を介して店舗およびその中の棚札に配信されていることがわかります。
こちらの図もよりわかりやすいですね。
これは、現在のIT環境におけるGitを用いた考えと合わせて考えることができます。
Gitとは？
Gitは、ソフトウェア開発における「変更履歴の管理システム」です。
Linuxの生みの親、リーナス・トーバルズ氏が、Linuxカーネル開発のために開発しました。
Gitを使うと、次のようなことができます：
- ソースコードの変更履歴を記録する
- いつ、誰が、何を変えたか追跡できる
- 複数人が同時に作業しても、あとで安全に統合できる
Gitは、ソフトウェア開発において「情報を履歴付きで管理するための仕組み」です。
たとえば、ファイルの内容を変更した場合に「いつ・誰が・どこを」変えたのかを記録しておくことができ、以前の状態に戻したり、複数人の作業を統合したりといった操作も行えます。
実際の運用では、全体の情報を集約して管理する「共有の場所」を設けておき、そこに対して各自の作業を反映させることで、1つの情報源を信頼して管理・更新していくという考え方がよく使われます。
このような情報の「一元管理」や「変更履歴の追跡」は、ソフトウェアだけでなく、文章や手順書、設定ファイルなど、あらゆるデジタル情報にも応用できます。
※ 本記事ではGitの技術的な詳細には踏み込みませんが、より深く知りたい方は「バージョン管理システム」や「Git 分散型」などで調べてみるのもおすすめです。
Gitと電子棚札：一元管理の考え方
電子棚札の情報管理は、Gitにおける一元的なバージョン管理の考え方とよく似ています。
通常、小売チェーンにおける電子棚札では、本部がすべての商品情報を一括で管理し、それを各店舗へ配信するという形がとられます。これは、情報の一元管理・集中配信という構造です。
ただし、現場によっては個別の事情で「値段の調整が必要」といったケースもあるでしょう。
たとえば、ある店舗で「特定のお惣菜が売れ残っているので、値引きして売り切りたい」といった判断がされた場合、店舗から本部に価格修正の依頼を出すことになります。
こうした「提案型のフィードバック」は、Gitにおける「変更提案」の運用に例えることができます。
Gitでは、各作業者が変更案を作成し、それを中央の履歴管理に統合するよう求める操作を「Pull Request」や「Merge Request」と呼ぶことがあります（ツールによって呼び方は異なります）。
補足：ここで紹介している電子棚札の仕組みは、あくまでGitの運用概念に重ねたものであり、実際にGitそのものを使っているわけではありません。
この記事では、Gitそのものの基本や現場での一般的な使い方などには触れませんので、必要に応じて次のような補足資料をご覧下さい。
補足 - GitHubやGitLabとは？
Gitは、先ほど紹介したように、ソフトウェアのソースコードなどを対象に「誰が」「いつ」「何を」変更したかを記録・追跡できるバージョン管理システムです。
このGitを活用したチーム開発を支援するサービスとして、GitHub や GitLab などがあります。
これらは「Gitリポジトリをホスティングして管理できるプラットフォーム」であり、以下のような機能を提供しています。
- ソースコードのクラウドホスティング
- チームでの共同編集・レビュー（Pull Request や Merge Request）
- 問題管理（Issue管理）
- 自動テストやCI/CDパイプラインの統合
- アクセス制御と権限管理
オンプレミスでGitを使いたい場合は？
セキュリティやコンプライアンスの要件から、ソースコードをクラウド上ではなく社内ネットワーク内で管理したいというケースもあります。
そのような場合には、次のようなオンプレミスで使えるGitサーバー用ソフトウェアの導入が検討されます：
- Gitea：軽量で自己ホスト可能なGitプラットフォーム
- GitLab CE（Community Edition）: GitLabの無償オンプレミス版
以下の記事では、GitLabの導入方法がわかりやすく紹介されています：
なお、ここで紹介したものはあくまで一例です。他にもオンプレミス向けのGitサーバーやホスティングソリューションは多数存在しますので、必要に応じて要件に合ったものを調査して選定するとよいでしょう。
Gitは単なるコマンドラインツールではなく、チーム開発やDevOpsを支える基盤技術のひとつとして広く使われています。GitHubやGitLabのようなツールと組み合わせることで、バージョン管理を起点とした開発プロセスの自動化や品質向上が可能になります。
あとがき
この記事では、小売店の電子棚札の仕組みと、Gitによる「情報の集中管理」や「変更履歴の追跡」が似ている点に注目し、その共通点をご紹介しました。
Gitは、ソースコードの管理に使われることが多いツールですが、実はそれだけにとどまりません。たとえば、GitHub や GitLab といったサービスを使えば、コードだけでなく学習メモや技術記事の執筆、チームでのドキュメント共有などにも活用できます。
こうしたプラットフォームを使えば、複数人で編集しても「いつ」「誰が」「どこを」変更したかが明確になるため、後からの見直しや修正もスムーズです。
Gitは開発者だけのためのものではなく、「情報を整理したい人すべてに役立つ道具」 です。
もし興味があれば、まずは GitHub や GitLab にアカウントを作ってみて、自分用のリポジトリを作成してみるのもおすすめです。
学習のメモや備忘録、ちょっとしたアイデアの記録などから気軽に始められます。
なお、GitHub や GitLab のほかにも、Gitea や Bitbucket、オンプレミス用のソリューションなど選択肢はさまざまあります。気になる方はぜひ調べてみてください。