第2話 ブランチとは？ポインタってどういう意味？作成・確認・切り替え方法【連載】マンガでわかるGit ～コマンド編～

Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。

第1話 では、

$ git init （リポジトリを作る）
$ git status （状況を確認する）
$ git add （ステージする）
$ git commit （コミットする）
$ git log （履歴を見る）

を習得しました。

今回の第2話では、ブランチの概念の理解と、ブランチの作成・確認・切り替えを実践していきます。主人公のわかばちゃんと一緒に、楽しくGitコマンドを学んでいきましょう！

【筆者】湊川 あいさん

フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』『わかばちゃんと学ぶ Webサイト制作の基本』『運用ちゃんと学ぶ システム運用の基本』が発売中のほか、マンガでわかるGit・マンガでわかるDocker・マンガでわかるRuby・マンガでわかるScrapbox・マンガでわかるLINE Clova開発・マンガでわかる衛星データ活用といった分野横断的なコンテンツを展開している。

･Amazon著者ページ
･Twitterアカウント

ブランチとは？ブランチを活用しないとこんなことに

「ブランチとは並行世界である」と例えられることが多いですが、実際の活用場面がわからないとイメージできませんよね。そこで、ブランチを活用しないとき・活用したときの違いをマンガで見てみましょう。

たとえば「Webサービスに新機能を追加してほしい」と言われたとします。

そんなときにブランチを活用せず、本番環境に新機能を直接付けていくと、こんなことになってしまいます。

ブランチを活用するとこんなに便利！

では、ブランチを活用するとどうなるでしょうか？

「masterブランチ」というのは最初から存在するブランチです。$ git init でリポジトリを作ったときから存在しています。先ほどはmasterブランチひとつしか使っていませんでしたが、この例では「developブランチ」というものを新しく作りました。

複数のブランチを活用すると、本番環境に使われているソースコードに影響を与えず、安心して別のブランチで開発を進めることができます。開発用のブランチのコミットが更新されたら、テスト用URLの内容も自動で更新することも可能です。

新機能が安定し「もう本番に公開しても大丈夫だね」とわかってから、満を持して本番環境にマージ（統合）するというわけです。

「ブランチとはポインタである」ってどういう意味？

せっかくなので、ブランチについてもう一段深く理解してみましょう。

Gitの公式ドキュメント によると

ブランチとは（中略）コミットを指す軽量なポインタに過ぎません

と説明されています。

Gitにおけるポインタとは、具体的にどのようなものなのでしょうか？これを理解していると、今後Gitの概念をより理解しやすくなりますよ。

ブランチの正体を解き明かそう

え！？
リポジトリの中って入れるの！？

もちろん入れるとも。
「.git」という名前の、半透明のフォルダがリポジトリだ。

第1話 で作ったlessonファイルを開こう。
こんな状態になっているはずだ。

さっそくリポジトリの中身を見てみるぞ。
「.git」という名前の、半透明の隠しフォルダがあるな。
こいつがリポジトリだ。ダブルクリックして開いてくれたまえ。
（.gitフォルダが確認できない場合は、隠しファイルの表示設定をONにしましょう）

その中にある refs > heads の順にフォルダを開いていくと、masterというファイルがあるはずだ。
これがmasterブランチの正体だ。
さて、このファイルには何が書いてあるだろうか？
テキストエディタで開いてみたまえ。

masterっていうのは、最初からあるブランチの名前だよね！
開いてみると…
アレッ？たったこれだけ？

そう、ブランチの中身は驚くほどシンプルなんだ。

英数字の羅列が書いてあるけど…
02f11b759bfeb461e117c5da18bb2dcbe06d862a
これは何かの暗号？

HAHAHA、この文字列は「コミットID」だ。
「コミットハッシュ値」とも呼ばれているな。

そういえば前回、この長～い文字列、見た気がする！
コミットの履歴を見ようと $ git log を実行したときに、コミットメッセージと一緒に表示されてたわ。

いかにも。
コミットによって生成されたデータのことを「コミットオブジェクト」と呼ぶ。
Gitはひとつのコミットオブジェクトに対して、40文字のIDを割り当ててくれる。
これがコミットIDだ。

ほほう…！？なんだか面白くなってきたぞ。
で、つまりどういうこと？

つまり、ブランチは「ただ単に特定のコミットIDを指差しているだけ」なんだ。

ええ～っ！
拍子抜けするほどカンタンな話じゃん！

コミットオブジェクトの中身をのぞいてみよう

コミットが「コミットを指し示している」とはどういうことでしょうか？実際に見てみましょう。

同じ練習用フォルダの中で、もうひとつコミットを作り、コミットログには計2つのコミットがある状態にしてください。操作方法は次の通りです。

1. sample.txtに何かしら変更を加える
2. $ git add sample.txt
3. $ git commit -m “2回目のコミット”
4. $ git log

2回目のコミットが記録できましたね。コミット履歴がこのようになっていればOKです。

さて、このとき2回目のコミットオブジェクトには何が記録されているでしょうか？次のコマンドで見てみましょう。

$ git cat-file -p 0e9556

▼ 表示結果：これがコミットオブジェクトだ

treeee290b48b356d721ae54d1edb03993802cc98bad8
parentt02f11b759bfeb461e117c5da18bb2dcbe06d862a
authorrllminatolll<XXX@mail.com>l1562052826 +0900
committerrllminatolll<XXX@mail.com>l1562052826 +0900

「parent」の部分に注目です！02f11b…と書かれています。

あっ！ このコミットIDは、ひとつ前のものだよね。
2つ目のコミットが、1つ目のコミットを指差してるってワケだ！

▼ 今の状態

コミットとコミットを結びつけているのは、このparent（親）の記載です。一番初めのコミットを除き、すべてのコミットオブジェクトには必ずparentが記載されています。

▼ 試しに、一番初めのコミット（イニシャルコミット）のコミットオブジェクトも見てみましょう。記載があるのはtree、author、committerの3つだけ。parentの記載がないのが見てとれます。

$ git cat-file -p 02f11b759

treee4576025551dd04fafbcb36bd7e1e7814018d11ea
authorrllminatolll<XXX@mail.com>11559898094 +0900
committerrllminatolll<XXX@mail.com>11559898094 +0900

 

★コミットIDは何を元に作られているの？

コミットID（コミットハッシュ値）は、実はこのコミットオブジェクトのバイト数と中身を使い、計算されて作られています。よって、コミットした人の名前やコミットした時間、指し示すparent、treeが違えばコミットハッシュ値も違うものになります。

その証拠に、同じ内容をコミットしていても、あなたの練習用リポジトリとわかばちゃんのコミットIDは違うはずです。コミットハッシュ値についてもっと深く知りたい方は、こちらの記事が詳しいのでおすすめです。

▼ Gitのコミットハッシュ値は何を元にどうやって生成されているのか

https://tech.mercari.com/entry/2016/02/08/173000

今存在するブランチを確認しよう

$ git branch

今、存在するブランチの一覧が表示されます。現段階では、masterブランチしかないので、* master と表示されると思います。

ブランチを作ろう

$ git branch [ブランチ名]

新しいブランチを作るコマンドです。$ git branch develop と打ち込みましょう。その後 $ git branch でブランチ一覧を見ると、このように表示されます。

  develop
* master

ちなみにこのアスタリスクマーク「*」は、簡単に言うと「あなたは今そのブランチの中にいますよ」という意味です。

▼ 今の状態

任意のブランチへ移動しよう

$ git checkout [ブランチ名]

さて、masterブランチからdevelopブランチに切り替えてみましょう。

$ git checkout develop と打ち込み、その後 $ git branch でブランチ一覧を見ると、今自分はdevelopブランチの中にいることが見てとれます。

▼ 今の状態

試しに、developブランチの中にいる状態で、sample.txtに何かしら文字を追加して新たにコミットを作ってみてください。

developブランチの指差しだけが動き、masterは2回目のコミットを指差したままです。こういう仕組みのおかげで、masterブランチに影響を与えることなく、開発用ブランチにコミットを積み重ねていくことができるのです。

▼ 今の状態

★知っていると便利！ git checkout コマンドの豆知識

「-b」オプション

$ git checkout -b [ブランチ名]

ブランチの作成とチェックアウトを同時に行えます。

「-f」オプション

$ git checkout -f [ブランチ名]

ブランチを強制的に切り替えることができます。
（コミットしていない作業データは消えるので注意）

まとめ

さて、ここまでで、ブランチの概念の習得と合わせて

$ git branch（ブランチを作る）
$ git checkout （チェックアウトする）

が使えるようになりましたね！

Gitにはまだまだたくさんのコマンドがあります。
次回は、ブランチとブランチを併合する「マージ」について解説します！

▼登場キャラクター紹介

▼わかばちゃんが登場する書籍

・わかばちゃんと学ぶGit使い方入門
・わかばちゃんと学ぶGoogleアナリティクス
・わかばちゃんと学ぶWebサイト制作の基本

▼ これまでの「マンガでわかるGit」

第1話「リポジトリの作成」
第2話「ブランチの概念」
第3話「マージの仕組み」
第4話「コンフリクトの修正」
第5話「git revert」
第6話「git reset 3種類」
第7話「git reflog」
第8話「git switchとgit restore」
第9話「git diff」
第10話「git cherry-pick」
第11話「git stash」
第12話「git grep」
第13話「git blame」
第14話「git remote」
第15話「.gitconfig でコマンドを短縮」
第16話「.gitconfig と .git/config で複数のGitアカウントを使い分ける」
第17話「prune オプション」
第18話「git tag」
第19話「detached HEAD 状態って何？」

【イベントレポート】プログラミング未経験者でもできる！動かして学ぶRPA超入門ハンズオン

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年5月24日のイベントでは「プログラミング未経験者でもできる！動かして学ぶRPA超入門ハンズオン」と題し、株式会社完全自動化研究所の代表であり、RPAについての書籍も執筆する小佐井 宏之さんを講師にお招きし、RPAについて教えていただきました。今回のイベントは、実際に手を動かすハンズオン形式。参加者は各自ノートPCを持ち込んで学ばれました。

■今回のイベントのポイント
・RPAとは？
・簡単なロボットを作ってみよう
・RPAツール「SikuliX」のテクニック

【講師プロフィール】
小佐井 宏之さん
エンジニア。株式会社完全自動化研究所代表取締役社長。京都工芸繊維大学造形工学専攻修士課程修了。大学院まで現代アートやデザインを勉強していたが、客先常駐のプログラマとしてIT業界に飛び込み、現場でプログラムやシステム開発を身に付ける。2010年フリーランスとして独立し、2016年RPAと出会う。2017年に起業し、2018年に書籍「オープンソースで作る！RPAシステム開発入門」（翔泳社）を上梓。執筆・講演の傍ら、顧客企業内の業務自動化をサポートしている。

RPAとは？

RPA（Robotic Process Automation）とは、コンピュータにできることはコンピュータにさせるということ。人員不足や働き方改革が叫ばれる今、注目されているテーマでもあります。

▲RPAが注目される理由は大きく3つ。システムが乱立している環境下で、異なるシステム間のつなぎ業務を行うというニーズもある

RPAツールには、実行環境と認識タイプにそれぞれの種類があるそうです。今回のイベントで使われた「SikuliX」は、デスクトップ型、画像認識型に分類されます。

SikuliXは、Windows上で動作し、無料で使えるアプリケーションで、人の目のように画像を認識し、人の手のようにマウスやキーボードを動かしてくれます。また、条件に応じた操作や、繰り返しなどの処理は、プログラミング言語のPythonを使うことで対応できます。

RPAツールを使って簡単なロボットを作ってみよう

まずは簡単なロボットを作ってみます。今回作るロボットの作業は次のようなもの。

▲デスクトップ上のテキストファイルを開き、文字列を書き加え、別名で保存し、メモ帳を終了させる

SikuliXでは条件分岐、繰り返しなどの複雑な処理も行えますが、今回は順次処理のみを使います。

作業登録の準備として、事前にデスクトップに「hello.txt」という名前のファイルを作成。中身は何も入力されていない空の状態です。

次に具体的な作業手順を登録していきます。手順は、小佐井さんのとても分かりやすいスライドがあったため、参加者の皆さんも戸惑うことはありませんでした。

ポイントは、あらかじめSikuliX以外のウィンドウを最小化にしておくなど、登録作業がスムーズに行えるのと同時に、SikuliXが画面認識を間違えないようにしておくことだそうです。

▲コマンドリストの「マウスの動作」から「doubleClick()」をクリックする。すると、SikuliXのウィンドウが最小化され、デスクトップが表示される。この状態をキャプチャーモードと呼ぶ

キャプチャーモードの状態から、マウスでhello.txtのアイコンを範囲指定の要領で囲んで、クリックをします。アイコンを囲むのに失敗したら、ソースコードウィンドウに記述されたコードを削除して、やり直します。

成功したら、SikuliXの「実行」ボタンをクリック。hello.txtのアイコンがダブルクリックされ、メモ帳が立ち上がればOK。うまくいけば、テキストを入力する部分をプログラミングします。

SikuliXのソースコードウィンドウに次のプログラムを追加します。

sleep(3)
type("Hello")
sleep(3)

sleep(3)は3秒待つための命令で、ウィンドウが開く前にテキスト入力してしまうのを避けるためのものだそうです。

▲SikuliXでは、画面キャプチャーと、プログラムコードの記述で、作業を登録していく

次に名前を付けて保存する作業を登録します。

SikuliXのコマンドから「click()」を選択し、キャプチャーモードで、メモ帳の「ファイル」メニューを選択。これで「ファイル」メニューをクリックするところは登録できました。

問題は次です。キャプチャーモードにしてから、「ファイル」メニューを開き、一覧から「名前を付けて保存」を選択するのですが、どうしても間に合いません。

そんなときは、SikuliXの「ファイル」メニューから「環境設定」をクリックし、「環境設定」ダイアログボックスで「キャプチャーを実行するまでの時間」を1秒から3秒に変更します。

▲キャプチャーモードに移行するまでの時間を調整できる（スライド右下の囲み）

「名前を付けて保存」の選択ができたら、ファイル名を入力させます。

「ファイル名を付けて保存」のダイアログボックスは、表示されたとき、ファイル名を入力するテキストボックスの文字列が選択されている状態。なので、そのまま新しいファイル名を入力します。

そこで、SikuliXのソースコードウィンドウに、

type("hello2.txt")

と入力します。

今回のイベントでは作業を進めるため、実際の「ファイル名を付けて保存」のダイアログボックスの方にも、人間の手でファイル名を入力。

次に、「click()」でキャプチャーモードにして、ダイアログボックスの「保存」ボタンを選択します。

この後、実際のメモ帳の方は保存ぜず、操作をキャンセルし、メモ帳の画面に戻ります。こうしておかなければHello2.txtが作られ、SikuliXに作業をさせるとき、既にファイルが存在する旨の警告メッセージが表示されてしまい、手順通りに進まなくなってしまうからです。

そして最後にメモ帳を終了させます。ウィンドウを閉じるには、ウィンドウ右上の「×」（閉じる）ボタンをクリックする、F4キーのショートカットを使う、「ファイル」メニューから「終了」を選ぶなど、複数の異なる方法があります。今回は「ファイル」メニューから「終了」を選びます。手順は「名前を付けて保存」のときと同じです。

以上でSikuliXへの登録作業はおしまい。実際に、SikuliXの「実行」ボタンをクリックしてみると、あっと言う間に、メモ帳が勝手に立ち上がり、文字列が入力され、勝手に新しいファイルに保存され、メモ帳が終了。参加者の皆さんは、感動されていたのと同時に驚かれていました。

SikuliXのテクニック

基本的な操作が理解できたところで、小佐井さんがSikuliXのちょっとしたテクニックをいくつか教えてくださいました。

■ターゲットオフセット
Webのログイン画面などで、IDとパスワードを入力するテキストボックスが同じように並んでいる場合に、それぞれの入力で、テキストボックスを画像として指定しても、それがIDなのか、パスワードなのか、SikuliXには区別がつきません。

そのままだと、先に一致したIDのテキストボックスにパスワードを入力してしまうといったミスが起きてしまう可能性もあります。

これを解決するのが「ターゲットオフセット」という機能で、テキストボックスのタイトル文字列などで位置を特定しておき、そこからオフセットさせたテキストボックスに文字を入力させることができます。

▲type(カメラマーク, text)コマンドを使うと、見出しなどを選択し、そこからさらにオフセット位置を指定したテキストボックスに文字を入力できる

■Region
指定した画面領域の中から画像を探させる「Region」という機能もあります。こちらは、異なる複数の領域に同じ画像がある場合も特定できるように、画面内の絶対座標で定められた領域内で判断しています。ただし、絶対座標で画像を探すため、ウィンドウの最大化や、表示位置の変更で、正しく認識できないこともあるそうです。

イベントの最後には小佐井さんが、WebブラウザからIDとパスワードを入力してシステムにログインをしたあと、特定の期間の売上データをダウンロードして保存するという、本格的なロボットのデモを披露。毎日、あるいは毎週の売上をダウンロードして保存するなどといった「定型業務」をこのような形で自動化できたら便利ですね。

【イベントレポート】サーバーから見るシステムとITの動向～システム開発未経験者でもOK！～

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年5月10日のイベントでは「サーバーから見るシステムとITの動向～システム開発未経験者でもOK！～」と題して、書籍『図解まるわかり サーバーのしくみ』の著者である西村泰洋氏を講師にお迎えし、サーバーの基本から話題のAIやIoT、RPAといったシステムについても、サーバーからの視点で解説していただきました。

※本レポートで使用する図版は、西村さんの著書『図解まるわかり サーバーのしくみ』より抜粋しております。

■今回のイベントのポイント
・企業や団体で稼働しているシステムについて
・サーバーの基本
・話題のAI、IoT、RPAなどのシステムとしての実態

【講師プロフィール】
西村 泰洋さん
富士通株式会社フィールド・イノベーション本部 金融FI統括部長。デジタル技術を中心にさまざまなシステムと関連するビジネスに携わる。著書に『図解まるわかり　サーバーのしくみ』『絵で見てわかるRPAの仕組み』『RFID+ICタグ システム導入・構築 標準講座』（以上、翔泳社）『デジタル化の教科書』『図解入門 最新 RPAがよ～くわかる本』（以上、秀和システム）『成功する企業提携』（NTT出版）がある。

企業や団体で稼働しているシステム

今回のイベントは「サーバーのしくみ」と「エンジニアのキャリア」という2つのテーマを巧みに組み合わせた構成でした。今回のレポートでは「サーバーのしくみ」を中心にお伝えします。

今やインターネットサービスで多数のサーバーが使われていますが、台数から言えば、組織や団体内で日々の業務を支えているものが圧倒的な多数を占めています。

そこで、まずは組織内の典型的なサーバー構成を見てみることに。

▲「進んだ企業」の業務システム例。一部オンプレミスのシステムが残るものの、かなりの部分はクラウド化されている（P221）

最初は「進んでいる企業」（西村さん）のケース。この企業では200を超えるシステムが稼働しており、多くのシステムはクラウドに置かれ、ERPは、まだクラウドに移行されておらず、オンプレミスのサーバー上で運用されています。各部署では部内ファイルサーバーなどが運用されているケースも、実際の現場でよく見受けられます。

一方で、比較的規模の小さな組織では、ほぼオンプレミスで構成されています。

▲別の企業の業務システム例。オンプレミスのサーバー上でシステムを利用している（P223）

企業によっては、一度作ったシステムをできるだけ長く使おうとする傾向にあり、IT投資の割合が大きくありません。エンジニアから見ると寂しい限りですが、西村さん曰く「意外と、こういう会社のほうが儲かっていたりする」のだそうです。

続いて、これらのサーバーに関する基礎知識について解説してくださいました。

サーバーの基本

まずは企業や団体で使われている業務システムのサーバーについて、基本形から学んでいきます。

業務システムにおいて重要なのはユーザーが入力する「データ」。そのため多くの業務システムは、データベースサーバーとシステム規模が大きくなる場合にはアプリケーションサーバーという2つで構成されています。

▲業務システムに限らず、インターネット上でさまざまなサービスを提供するサーバーにおいても、データベースとアプリケーションサーバーで構成されることが多くなっている（P103）

この後、サーバーのハードウェアについてや、ファイルサーバー、プリントサーバー、メールサーバー、Webサーバー、DNSサーバー、プロキシサーバーといった各種サーバーについて、そしてインターネットの基本的な仕組みについても解説がありました。

話題のAI、IoT、RPAなどのシステムとしての実態

この中で、クライアントサーバー型のシステム構成に対して、サーバーから命令や指示を出し、配下のコンピュータおよびデバイスに処理をさせる「サーバーからの処理」に興味をひかれました。具体的には、運用監視、RPA（Robotic Process Automation）、IoT（Internet of Things）、BPMS（Business Process Management System）などだそうです。

RPAは、事務処理を自動化するためのソフトウェアで、単体のデスクトップPC上の操作を自動化するものもありますが、サーバーからの処理で複数のデスクトップPC上の操作を統合して、処理を大幅に効率化するものもあるそうです。

▲RPAでは、サーバーのなかに仮想化された複数のロボットファイルと実行環境を備えて、デスクトップがそれらを取得して実行することで、複数のデスクトップPCの操作を統合し、処理を大幅に効率化するものもある（P139）

西村さんによれば、「近年、BPMSとの連携が増えている」とのこと。BPMはその名の通り業務プロセスの管理なのですが、各種のシステムを連動しながら、業務プロセスを見える化し、PDCAサイクルを用いて、業務プロセスを改善・効率化していくものだそうです。

また「IoTには手を出すな」という話も興味深いお話でした。IoTは、（ハードウェアなどの）素の性能がきちんと分かっていないと、システムの効果を見積もれないという難しさがあるそうです。西村さんの経験談として「東京で実績のあるICタグのシステムを北海道に展開したときに、大雪が原因でタグが読めなくなるという不具合」が実際にあったそうです。システムの開発・構築時に、大雪を想定できるかどうかは、なかなか難しそうです。

不正アクセスやデータ漏洩に対するセキュリティについてもお話がありました。冒頭にお話があったように、業務システムにおいて大切なのはデータです。これを勝手に持ち出されないよう、暗号化通信やファイアウォール、DMZ設置などの外部からの不正アクセス対策に加え、ユーザーグループの設定やアクセス権の制限など、組織内部からの不正アクセス防止も忘れてはなりません。運用レベルでも、きちんと考える必要があるそうです。

▲不正アクセスは外部だけでなく、内部からもあり得る。アクセス権の設定なども含め、運用レベルでのセキュリティ対策も忘れてはならない（P153）

今回のイベントでは、こうしたサーバーの解説と並行して、エンジニアとしてのキャリア形成や技術スキルの向上などについても、さまざまなアドバイスがありました。ソフトウェア開発エンジニアだから、フロントエンジニアだから、サーバーやネットワークのことは知らなくても良いということはなく、こうした基本的な知識は、しっかりと備えておくべきだと再認識した内容でした。

第1話 リポジトリを作ってコミットしてみよう【連載】マンガでわかるGit ～コマンド編～

Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。4月のイベントでは、Gitの基礎の基礎をお伝えしましたが、この連載コラムでは、「Git コマンド編」をマンガで解説します。

Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。今回は、ある程度のGUIでならGitは使えるけれど、コマンド操作は苦手という方のために、主人公のわかばちゃんがカンタンなGitコマンドを実践していきます。みなさんも一緒に操作してみましょう！

【筆者】湊川 あいさん

フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』『わかばちゃんと学ぶ Webサイト制作の基本』『運用ちゃんと学ぶ システム運用の基本』が発売中のほか、マンガでわかるGit・マンガでわかるDocker・マンガでわかるRuby・マンガでわかるScrapbox・マンガでわかるLINE Clova開発・マンガでわかる衛星データ活用といった分野横断的なコンテンツを展開している。千代田まどかさんとのコラボレーション企画をTECH PLAY Magazineで連載中。

･Amazon著者ページ
･Twitterアカウント

 

GUIとCLIの違い

みなさんが普段パソコンを操作するとき、どのように操作していますか？マウスやタッチパッドを使って、デスクトップのアイコンをクリックしたり、ファイルをドラッグしてゴミ箱に捨てたりしていると思います。これがGUI（グラフィカルユーザーインタフェース）です。

対して、キーボードのみを使ってOSに命令を送り、パソコンを操作するのがCLI（コマンドラインインターフェース）です。プログラマが使っている「黒い画面」と言えばイメージが付きやすいでしょうか。

▼CLIの例：ターミナル（Windowsだとコマンドプロンプトという名前）

もともと、初期のコンピュータは、キーボードからコマンドを打ち込んで操作するものでした。1980年以降、コンピュータの処理性能が上がったことによって、直感的に操作できるGUIが普及し始めたのです。

Gitも本来はCLIで操作するものですが、普及に伴って、コマンドを打ち込まずともクリックで操作できるGUIソフトが登場してきました。SourceTree（ソースツリー）やGitKraken（ギットクラーケン）、GitHub Desktop（ギットハブデスクトップ）などです。

▼GUIの例：SourceTreeの操作画面

これだけを聞くと「操作しやすいGUIがあるなら、わざわざ玄人向けのCLIを使う必要はないじゃない」と思うかもしれません。ところがCLIには様々なメリットがあるのです。

CLIのメリット

たとえば、今から新規リポジトリを作るとしましょう。

GUIの場合、ソフトを立ち上げてから「新規リポジトリ → ローカルリポジトリを作成」の順にクリックする必要があります。

対して、CLIならこう打つだけです。

$ git init

これだけで新規リポジトリができてしまいます。
どうですか？簡単でしょう。

単に操作がシンプルになるだけではありません。CLIにしかできない操作もあります。GUIは初心者でも使いやすいことを目的として作られているため、基本的な操作はできるものの、一部削ぎ落とされている機能があるからです。

いざというとき便利なコマンド、かゆいところに手が届くコマンドがGitにはたくさんあります。この連載でひとつずつ知っていくことで、「pushできなくなった」「マージしていないブランチを間違って消してしまった」といった問題が起きても、すぐ対処できるようになります。きっとあなたもGitをもっと好きになることでしょう。

CLIを使ってみよう

ではさっそく、CLIの画面を出してみたまえ。

Macの場合：
MacのCLIは「ターミナル」と呼ばれているぞ。Launchpadの「その他」から選んでクリックします。もしくは[Control] + [スペース]キーを同時に押して、「terminal」と入力、検索すると出てきます。

Windowsの場合：
Windowsでは「コマンドプロンプト」と呼ばれています。
[スタートボタン] > [すべてのプログラム] > [アクセサリ] > [コマンドプロンプト] をクリックすると立ち上がります。

Gitがインストール済みか確認しよう

$ git --version

と入力して、

git version 2.19.0

のように出てくればインストール済みです。次に進みましょう。

インストールがまだの方は、Git公式ドキュメントのGitのインストールの手順を実行するか、SourceTreeをインストールしてください。SourceTreeのパッケージの中にGitも含まれています。

コマンドでGitを使ってみよう

基本的なコマンド

---

まずは、もとからパソコンに入っている基本的なコマンドを使ってCLIに慣れてみよう。「pwd」と打ち込んでエンターを押したまえ。あぁ、先頭の$マークは打たなくていいぞ。

$ pwd

たった3文字でいいんですか？pwd エンターっと…

$ pwd

/Users/wakaba

おお！？なんか文字が出てきた！

これが、君が今いるディレクトリ（階層）だ。　ディレクトリはわかるな？

フォルダ構成みたいな感じだよね。今私は、Usersというフォルダの中の、wakabaというフォルダにいるってワケだ。

その通り。pwdというのは「Print Working Directory」の略なんだ。今どこにいるか表示して」という意味だな。

お次は「ls」とだけ打ち込んでみたまえ。（Windowsコマンドプロンプトの場合は「dir」）

$ ls

Desktop

Documents

Downloads

Library

Movies

Music

Pictures

Public

……

お見事！今自分がいるディレクトリの直下にあるものが表示されたな。ちなみにlsはList Segmentsの略だ。

今表示された中にあった「Desktop」という場所に移動してみようか。 「cd」というコマンドに続けて、移動したいディレクトリ名を打つと、その階層に行けるぞ。

$ cd Desktop

「cd」はなんの略なの？

Change Directoryの略だ。覚えやすいだろう。

ディレクトリ（フォルダ）を作ろう

---

デスクトップに移動したところで、Git練習用のディレクトリ（フォルダ）を作ろう。「mkdir」に続けて、希望のディレクトリ名を打ち込んでエンターだ。

じゃあlessonっていう名前にしたいわ。

$ mkdir lesson

わぁ、デスクトップにlessonっていうディレクトリが爆誕したよ！いつもクリックでやっている作業が、短い文字を打つだけでどんどんできていく！スゴイ！

リポジトリを作ろう

---

さて、いよいよGitコマンドを使っていくぞ。Gitコマンドは先頭に「git」をつけるのが特徴だ。

▼lessonディレクトリに移動して

$ cd lesson

▼リポジトリを作る

$ git init

すると……

たったこれだけでリポジトリができました！

そうそう、.gitっていう隠しファイルがGitリポジトリの証なんだよね。

サンプルファイルを作ろう

---

リポジトリを作ったはいいけど、lessonディレクトリにはまだ何もファイルがないや。テキストエディタを開いて、適当なファイルを作ろうかな。

おっと！せっかくならテキストファイルもコマンドで作ってみようか。

$ echo “Hello Git” > sample.txt

 

わわっ！ファイルが作成されて、しかも内容も入力されてる！CLIってなかなかやるじゃん！

ステージングエリアに乗せてコミットしよう

---

じゃあ、今作ったsample.txtをリポジトリに記録しよう。まずは git status コマンドを使って、作業ディレクトリの状態を確認するんだ。

$ git status

赤文字で表示されているのは、まだステージングエリアに乗せられていないファイルです。

では、sample.txtをステージングエリアの上に乗せてあげましょう。

私がいつも使ってるGUIでは、チェックマークを入れてステージングエリアに乗せてるけど、コマンドではどうやるんだろう？

あれは、裏で git add コマンドを実行しているだけだ。ステージングエリアに乗せたいファイルの名前を git add に続けて打ち込みたまえ。

$ git add [ファイル名]

git add sample.txt っと。……ん？しかし何も起こらないけど……？

git status で、もう一度状態を確認してみるのだ。

$ git status

おや？さっき赤文字だったファイル名が、緑色になってる！

その通り！緑色になっているファイルは「今ステージングエリアの上に乗っていて、コミット待ちですよ～」ということを示している。

最後に、いよいよコミットしてみよう。コミットは、撮影台（＝ステージングエリア）に乗っているものをパシャッとカメラで撮って、アルバム（＝リポジトリ）に記録するイメージだ。

$ git commit -m “ここにコミットメッセージを書く”

 

コミットメッセージは -m の後ろにダブルクォーテーションで囲って書くんだね。$ git commit -m “はじめてのコミット” っと…

コミットログ（履歴）を見てみよう

よし！では、ちゃんとコミットされたか確認してみよう。

$ git log

おおーっ！ちゃんとコミットした人・時間・メッセージが記録されてる！

履歴を見れたはいいけど… これ、履歴が多くなってきた場合は一番古いコミットログにたどり着くまで終われないよ！閲覧を終わらせるにはどーしたらいいの！？

アルファベットの「q」を押すんだ！Quit（辞めるという意味）の「q」だと覚えよう。

ちなみに、--graph というオプションをつけて実行すると、コミットログをアスキーアートでカラフルに表示してくれるぞ。今はまだコミットをひとつしか記録していないから、代わり映えがしないと思うが、たくさんブランチがあるリポジトリでやってみるとおもしろいだろう。

$ git log --graph

▼CLIで見た場合のコミットグラフ

コミットグラフを見るときはGUIの方が見やすいので、操作はCLIで行って、確認用にGUIを横に置いて作業する人もいます。
このあたりはいろいろ試しながらやってみて、あなたがやりやすい方法を選んでくださいね。

▼SourceTreeで見た場合のコミットグラフ

 

★魔王教授 本日の豆知識

---

CLIで「↑」キーを押せば、最近自分が打ちこんだコマンドを再利用できて便利だぞ！

▼上下キーで使いたいコマンドを選び、エンターで実行できる

まとめ

さて、ここまでで

$ git init （リポジトリを作る）

$ git status （状況を確認する）

$ git add （ステージする）

$ git commit （コミットする）

$ git log （履歴を見る）

が使えるようになりましたね！

Gitにはまだまだたくさんのコマンドがあります。次回は、さらに役立つGitコマンドも登場。わかばちゃんと一緒に学んでいきましょう！

▼登場キャラクター紹介

▼わかばちゃんが登場する書籍

・わかばちゃんと学ぶGit使い方入門
・わかばちゃんと学ぶGoogleアナリティクス
・わかばちゃんと学ぶWebサイト制作の基本

▼ これまでの「マンガでわかるGit」

第1話「リポジトリの作成」
第2話「ブランチの概念」
第3話「マージの仕組み」
第4話「コンフリクトの修正」
第5話「git revert」
第6話「git reset 3種類」
第7話「git reflog」
第8話「git switchとgit restore」
第9話「git diff」
第10話「git cherry-pick」
第11話「git stash」
第12話「git grep」
第13話「git blame」
第14話「git remote」
第15話「.gitconfig でコマンドを短縮」
第16話「.gitconfig と .git/config で複数のGitアカウントを使い分ける」
第17話「prune オプション」
第18話「git tag」
第19話「detached HEAD 状態って何？」

【イベントレポート】トップエンジニアが実践する思考整理法 テクニカルライティングを用いた課題解決の基本

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年4月24日のイベントでは「トップエンジニアが実践する思考整理法 テクニカルライティングを用いた課題解決の基本」と題し、エンジニアのみならず、今やあらゆる立場の人に必要とされると言っても過言ではない、テクニカルライティングの実践手法について、技術経営コンサルタントであり弁理士でもある藤田肇さんが、分かりやすく教えてくださいました。

■今回のイベントのポイント
・エンジニアが養うべき言語化能力とは何か？～テクニカルライティングの重要性
・誰もが実践できるテクニカルライティングのフレームワークを用いた思考整理法

【講師プロフィール】
藤田 肇さん
技術経営コンサルタント・弁理士。株式会社リジー 代表取締役。「人工知能 冬の時代」に機械学習・人工知能を専攻し、研究者・データサイエンティストとして活躍後、弁理士資格を取得。大手特許事務所でテクニカルライティングを習得し、AI関連企業で技術戦略・知財戦略の立案・推進に携わる。その後、技術・事業・知的財産の融合領域における専門知識を生かして独立。テクノロジー企業を中心に、技術経営・知財戦略に関するコンサルティングを提供する。朝日新聞社主催「AI FORUM 2018」、ソフトバンクC&S主催研修会、日本弁理士会主催継続研修など各種イベント・研修会の講師を多数務めるほか、「人工知能が支える先進医療」（野村ヘルスケアノート）など多数執筆。

エンジニアが養うべき言語化能力とは何か？～テクニカルライティングの重要性

藤田さんは、今でこそテクニカルライティングに関する書籍まで執筆されていますが、大学時代は、指導教官から「お前の書いた文書を読んでも何も分からない」と言われていたそうです。ところが「先生が赤を入れてくれれば、分かりやすくなるので、元の文章はそれほど悪くない」と思い込み、その後、エンジニアになってからも「自分は技術文書を書くのが上手い」と勘違いしていたそうです。

そしてエンジニアを辞め、弁理士になり特許事務所に勤務するようになってから「自分はまともな技術文書が書けていなかった」と気づいたといいます。

藤田さんは、仕事柄いろいろな特許技術者に会い、出願前に必ず説明資料をもらいます。そのうちの8割の人から受け取る資料は読んでも分からない。しかし、2割の人からは読むだけで「スゴイな」と感じる資料が出されてくるそうです。当初、藤田さんは「優れた発明ほど、資料が分かりやすい」と考えました。しかし実はそうではなく「日常的に正しくテクニカルライティングをしているから、優れた成果を出せる」ということだったのです。

そのきっかけは、年に3～4件、優れた発明を出してくるクライアントに藤田さんが「なぜ、そんなに発明を生み出せるのか？」と尋ねたところ、研究時のノートを見せてくれたことでした。そのノートには、自分は今、どんな課題に直面しているか、その課題にどうアプローチするかが、整然と書かれていて「これはスゴい」と思ったそうです。

こうした経験から藤田さんが導き出した提言が「思考を整理して課題解決するために、適切なテクニカルライティングを実践しよう」というもの。

「適切な」というのは、「オリジナリティ」と「インパクト」をきちんと浮彫にさせること。より具体的には「先行技術との差分」がオリジナリティであり、「差分の大きさ」がインパクトに相当します。

▲オリジナリティとインパクトをきちんと浮彫にさせる

これを、ラジオを搭載した自転車の発明という例で説明してくれました。

▲ラジオを搭載した自転車のオリジナリティとインパクトを明確化する

「でも、自分は発明をしないし……」という人は、インフラエンジニアあるいはソフトウェアエンジニアという立場で同様のケースをイメージしてみます。障害発生時の対応を上司に報告したり、新たに開発したサービスを営業部門の人たちに説明したりするシーンに置き換えて考えてみる必要があります。

誰もが実践できるテクニカルライティングのフレームワークを用いた思考整理法

ここで、藤田さんの冒頭の経験に立ち返ります。適切なテクニカルライティングについて、ほとんどの人ができていない。できていないことにも気づいてない。そこで何らかのソリューションが必要だと考えたそうです。

それが藤田さんの考案した「黄金フォーマット」です。

▲テクニカルライティングを磨くための黄金フォーマット

このフォーマットは、2×2の4つのボックスに「背景・前提」「課題」「手段・アプローチ」「効果・結論」というテーマが付けられており、それぞれのボックスの中身を埋めていくことで、思考が整理され、適切なテクニカルライティングができるといいます。

その秘密は、それぞれのボックス間の関係にあります。藤田さんは「ボックスの内容よりも、ボックス同士の関係が大切」だと言います。先ほどのラジオ搭載自転車ならば次のようになります。

▲ラジオ搭載自転車を黄金フォーマットに当てはめるとこうなる

ところで「なぜテクニカルライティング＝思考整理」になるのでしょうか。藤田さんによれば、それは言語の構造化を強制されるからだそうです。たとえば象という生き物を知らない人に象について伝えるなら、象の紹介動画を見てもらうのが一番早い。文章は、映像に比べて情報量が少ないのです。それでも他人に理解してもらいたい。となれば、思考の本質を浮彫にするしかありません。

思考を整理するためには、記述の際に、次の点に留意しておくと良いそうです。

▲思考を整理する際に留意しておくべき項目

ちなみに、よくあるダメなテクニカルライティングをこのフォーマットに当てはめると、次のようになるそうです。

▲ダメなパターンを黄金フォーマットに当てはめるとこうなる

「ダメ資料は単なるエッセイに過ぎない」というのが藤田さんの考えです。しかし、なぜこうした書き方になってしまうのか。その原因は小学校時代の「読書感想文の罠」に陥っているからだと分析します。知らず知らずのうちに「思ったままに書く」「自由な書式で書く」ということに慣らされてしまっているのではないか、ということです。

そして読書感想文の罠に陥った人がやってしまいそうなことも、紹介してくださいました。

▲読書感想文の罠に陥った人がやってしまうダメなこと

テクニカルライティングを上達させるには、繰り返し現状を把握し、ノートに書いて「見える化」することが大切だそうです。いくら思考の整理といっても、頭の中で考えているだけではダメで、整理した思考を文章化する習慣をしっかりと身につける必要があるそうです。日常の報告書作成などにも、実際にこの黄金フォーマットを試してみてはいかがでしょうか。

【イベントレポート】マンガで学ぶ、Gitの使い方超入門ハンズオン

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年4月5日のイベントでは「マンガで学ぶ、Gitの使い方超入門ハンズオン」を開催。プログラム開発者からWeb制作者まで、幅広い層に使われているバージョン管理ツール「Git（ギット）」。まだ使ったことがない人のために、基礎の基礎から教えてくださいました。書籍『わかばちゃんと学ぶ Git使い方入門』のマンガのエピソードを交えながら解説してくださる上、自分のノートPCを持ち込んで実際に操作するハンズオン形式だったので、とても楽しく分かりやすいイベントでした。

■今回のイベントのポイント
・Gitってなに？どう便利なの？
・リポジトリとは
・ステージングとコミットの概念
・ブランチの概念
・GitHub上のリポジトリにプッシュとプルができるようになろう

 

【講師】湊川 あいさん

フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。著書『わかばちゃんと学ぶ Webサイト制作の基本』『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』が全国の書店にて発売中のほか、動画学習サービスSchooにてGit入門授業の講師も担当。「マンガでわかるGit」「マンガでわかるDocker」「マンガでわかるUnity」といった分野横断的なコンテンツを展開している。
Twitterアカウント： https://twitter.com/llminatoll

 

Gitってなに？どう便利なの？

Gitというと「難しそう」とか「エンジニアが使うもの」という印象があるかもしれません。そもそもメリットがわからないと学ぶ気になれないものです。書籍『わかばちゃんと学ぶ Git使い方入門』の主人公であるわかばちゃんが、マンガでGitのメリットを紹介してくれました。

大学に通うわかばちゃんは、Webのゼミを選択しており、誰もいないゼミの教室で、勉強を兼ねて個人サイトを制作しています。しかし、CSSをちょっと編集しようとしたら、デザインが壊れてしまいました。元に戻したいと思い、修正を加える前のファイルを探すのですが、過去に保存したファイル名の付け方がいい加減で、見つからず、思わず「どれだよ」と叫びます。

Web制作、プログラム開発だけでなく、ワープロや表計算ソフトで文書を作成する際もよく見かける「あるある」です。わかばちゃんの気持ちがよく分かります。

Gitは、プログラムのソースコードやドキュメントのバージョンを管理するためのツールです。例えるならば、ロールプレイングゲームで、ボスキャラを倒す前にセーブしておくイメージです。ボスに負けてゲームオーバーになっても、ボス戦前に戻ることができるアレです。つまり、間違ったコードを書き込んでしまい、プログラムが動かなくなったとしても、正常に動いていた頃の状態をいつでも復元できるというわけです。

Gitのメリット

Gitには、さらに大きなメリットがあります。複数名で開発や制作を行う現場では、誰が・いつ・どこで・何のために・どう修正したかという記録が煩雑になります。Gitは、それを一元的に取りまとめることができます。

企業やプロジェクトでGitを複数名で利用する際、よく使われているのがGit Hub（ギットハブ）というサービスです。GitHubは、簡単に言うとソースコードの保管場所です。とはいえ単なるソースコード置き場ではなく、メンバー間のコミュニケーションの場として機能するのが特徴です。たとえば、修正した箇所をプルリクエストという形で提案したり、掲示板のような見た目でお互いのソースコードにレビューしあったりすることができます。

リポジトリとは？

ここからは、実際にGitを動かしながら、使い方を学んでいきました。

まずはリポジトリについてです。Gitにおけるリポジトリは、コードの過去の状態が記録されている貯蔵庫のようなもの。

はじめに、あらかじめイベント開始前に自分のPCにダウンロード&インストールしておいたGUIツール「SourceTree」を起動します。SourceTreeは、もともとコマンドラインツールのGitをGUI環境で手軽に使うためのものです。まずはリポジトリを新規作成します。

▲作業用フォルダ「R-TEST」を作成しておき、SourceTreeの「Create」ボタンをクリックし、先ほどのフォルダ「R-TEST」を指定してローカルリポジトリを作成する

ローカルリポジトリ「R-TEST」が作られます。これをダブルクリックして開いてみると、まだ何もありません。そこでフォルダR-TESTの中にテキストファイルを作成します。

リポジトリにファイルの更新履歴を記録していきます。リポジトリへの記録手順について理解するために、またわかばちゃんが登場します。

マンガでは、みんなでお好み焼きを作るのですが、その手順の要所要所で写真に記録を残していきます。粉と水と卵を混ぜたところを撮影台に乗せて撮影し、キャベツを千切りにしたものを混ぜて、また撮影台に乗せて撮影し……と。「料理ブログにでも載せるのかな？」と不思議に思うわかばちゃん。ところが、最後に、ゼミの教授がそこにコーラを混ぜてしまい残念な結果になってしまいます。

「はぁ、キャベツを混ぜたところに戻れれば……」

そんな声に応えてくれるのがGitです。Gitは、撮影した時点にいつでも戻せる魔法のカメラのようなものなのです。

▲変更作業をする、ステージングエリアに乗せる（撮影台に乗せる）、コミットする（撮影する）という手順を踏むことでリポジトリに変更が記録され、後からその時点の内容に戻すことができる

早速、先ほどR-TESTフォルダ内に作成したテキストファイルを、ステージングエリアに乗せてみましょう。

▲画面下の［ログ］タブをクリックして画面を切り替え、作業ツリーのファイル一覧から、目的のファイルを選び、［選択をインデックスに追加］ボタンをクリックする

次にステージングエリアに乗せたファイルを選び、コミットします。

▲［ファイルステータス］タブに戻し、ステージしたファイル一覧から目的のファイルを選び、［コミット］ボタンをクリックする

これで、初めてのコミットが記録されました。以降、同様にファイルに変更を加え、ステージングして、コミットすると、そのたびに更新履歴が記録されていきます。

▲masterブランチにソースが登録された。以後、コミットするたびに履歴が保存されていく

コミットを繰り返すうちに、以前の状態に戻したくなったら、SourceTreeの履歴一覧から目的のものをダブルクリックします。これでファイルの内容がその時点のものに戻ります。これをチェックアウトと呼びます。

▲ソースツリーから過去のものを選びダブルクリックすることで、その時点での内容に戻せる（ソースファイルの内容が戻っている）

もしかすると、ステージングエリアに乗せる作業が二度手間なように思った方もいるかもしれませんね。なぜステージングエリアは必要なのでしょうか？

それは、開発の中で、一度にいくつもの更新ファイルがあったとき、コミットを分けて行いたいというケースがあるからです。たとえば、CSSとJavaScriptを同時に編集し、まとめてコミットしてしまったとしましょう。コミットした時点では特に問題がないように思えますが、後々CSSだけを元に戻したくなった場合、JavaScriptまで一緒に過去の状態に巻き戻ってしまうと不都合です。そういうわけで、コミットの粒度を人間が選ぶことができるようにこのステージングエリアという仕組みがあるのです。

ブランチの概念

Gitには、ブランチという概念があります。これはいわば並行世界、つまり“同時並行で進む世界”と考えることができます。ここでは湊川さんのサイトにある「絵文字でわかるGit」をベースに解説が進みます。

▼絵文字でわかるGit
https://webdesign-manga.com/emojigit/

たとえば、お寿司を作ることを考えます。お寿司はシャリとネタからできていますが、これらを用意する過程をkomeブランチとsakanaブランチに分けるとします。

komeブランチでは、苗を植え→稲を育て→米を収穫するというように作業を進め、sakanaブランチのほうも、稚魚→魚→マグロと作業を進めていき、米とマグロを最終的にマージしてお寿司にします。

▲komeブランチとsakanaブランチで同時並行作業を進め、最終的に両者をマージしてお寿司が完成する（湊川さんのサイト「絵文字でわかるGit」より）

ソフトウェア開発のシーンでも、機能ごとに分け、同時並行で開発したり、本番用と新規機能用の開発を並行して進めることがあります。そういったときに役立つのがブランチです。それぞれのブランチで作業を進め、結果をマージ（合体）させます。

同時並行で開発を進めていくと、同じ行に異なる修正が入ることがあります。たとえばAさんとBさんが同じファイルの3行目をそれぞれ別の内容に書き換えていた、といった場合です。その状態でマージしようとすると、Gitが「コンフリクト（衝突）しているよ」と教えてくれます。AさんとBさん、どちらの修正を採用するかは、マージする人が適宜判断します。

GitHub上のリポジトリにプッシュとプルができるようになろう

後半では、複数メンバーでの開発について学びました。Git Hubにログインし、湊川さんが用意した練習用リポジトリ（すでにHTMLファイルが用意されているもの）を、自分のGit Hubアカウントにフォーク（分岐）させて、そのGit Hubのリモートリポジトリのクローンを自分のPCに作成（コピー）し、ローカルリポジトリを作成します。

そして、ローカルリポジトリ上でHTMLファイルに自己紹介を追加し、Git Hub上のリモートリポジトリにプッシュし、自身の変更を湊川さんのソースにマージしてもらうためプルリクエストを送ります。プルリクエストとは「こういう変更を加えたからあなたのリポジトリに反映して欲しい」という連絡です。これを見て、湊川さんはリクエストのあったソースコードを自分のGit Hubリポジトリに取り込みます。

▲SourceTreeでコミットしてプッシュした後、Git Hubの画面でプルリクエストを送る

会場では、イベント参加者から寄せられるプルリクエストに応じて、湊川さんが、それぞれの変更をマージして取り込み、GitHub Pages上でひとつのWebページを完成させました。

Gitは、もともとコマンドラインで使うツールとのことですが、今回はSourceTreeというGUIツールを使ったので、クリックするだけの直観的な操作で行うことができました。また、湊川さんの書籍『わかばちゃんと学ぶ Git使い方入門』のマンガを見ながら学ぶことで、概念を理解しやすく、苦手意識を持つことなく、参加者の皆さんもGitに親しむことができました。

【イベントレポート】イマドキなシステム開発には、見積りの知識を身につけよう

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年3月22日のイベントでは「『イマドキ』ソフトウェア 開発プロジェクトを見積りを通して知る ～システム開発のための見積りのすべてがわかる本より～」と題して、書籍『システム開発のための見積りのすべてがわかる本』の著者である佐藤大輔さん、渡邉一夫さん、畑中貴之さんの3名を講師としてお迎えし、開発プロジェクトの見積りについて、さまざまな視点からレクチャーしていただきました。

■今回のイベントのポイント
・プロジェクトとお金の流れを知る
・「イマドキ」のITプロジェクトでは、アジャイルやチケット駆動もあたりまえ？
・事例研究：クラウド時代の現場では何が起きているのか

【講師プロフィール】
佐藤 大輔さん
大手SIerでプログラマ、SEを経験し、2003年にSI事業と自社サービスを行う企業「株式会社オープントーン」を創業。現在、同社代表取締役社長。
渡邉 一夫さん
Java ServeletなどサーバサイドJavaの登場初期からJavaに精通し、数々のエンタープライズシステムの開発を手掛けてきた実績を持つエンジニア。
畑中 貴之さん
エンジニア、個人事業主として数々のビッグプロジェクトをマネジメントしてきた経験を持ち、現在はオープントーンにて取締役兼観光ビッグデータ事業部長を務める。

そもそも見積りって？プロジェクトとお金の流れを知り仕事の組み立てに生かそう！

まずは佐藤さんが、見積りの基本的な考え方を紹介してくれました。

「見積り」というと、これからかかる費用の明細が書かれた見積書をイメージしてしまうのですが、佐藤さんによれば、見積りとは、予算、納期、品質などの要素を、あらかじめ明らかにしておくことであり、それは「いわばプロジェクト計画そのもの」だということです。

▲予算、納期、品質を明らかにする「見積り」とはプロジェクト計画そのもの

たとえば日常よくある「この作業、いつまでに終わりますか？」という問いに「今週中には終わります」と答えたとします。その根拠を計算することも立派な見積りの一つです。

これは、残りの工数を確認して、開発～テストの期間を計算して何人日必要、と算出します。つまり見積り作業自体は、エンジニアが日々やっていることなのです。ただし、プロジェクトが大規模になると、この作業がビジネスに組み込まれていきます。

ここで、見積りのやり方を学びます。見積りの手法にはいくつか種類がありますが、わかりやすい積み上げ法で説明してくれました。

積み上げ法（積算法）は、名前の通り作業をひたすら積み上げていく手法だそうです。「24時間365日動かしたい」「5000人同時ログインに耐える処理能力」などといったユーザーの要望を聞き、エンジニアは何が必要かを考えていきます。

▲1つの画面に紐づく機能を積み上げ、人日計算を行い集計していく

こうした作業でわかるように、見積りは概要設計をすることと同じです。すなわち設計を進めないと見積りはできません。

そのため、場合によっては見積りに、機能一覧、スケジュール、アクティビティ図、アーキテクチャ構成図、プロジェクト体制図（開発とユーザーの責任範囲等）が伴うこともあるそうです。

また、ここで紹介された積み上げ法以外にも、FP（ファンクションポイント）法、OP（オブジェクトポイント）法など、さまざまな見積り作成の手法があります。

見積りは、あくまでも予測に過ぎません。「やってみたら5日で終わらなかった」というのはよくある話。計画通りに進まなかったときに、それを次回の見積りのためにフィードバックしていくことが、現場において大事なことです。

「イマドキ」のITプロジェクトでは、アジャイルやチケット駆動もあたりまえ？

講師を渡邉さんにバトンタッチして、今度はアジャイル開発やチケット駆動開発についてのお話です。

先ほどの見積りのところでも触れられていたように、システム開発は不確実性との闘いであり、見積るのは難しく、常に不確実性とつき合いながらプロジェクトを進めていく必要があります。

従来のウォーターフォール型開発では、この不確実性を設計段階で解消していました。しかし、これをアジャイル型開発では、開発を進めながら解消していきます。

▲ウォーターフォール型とアジャイル型での違い

スプリントという単位で反復しながら開発を行うスクラム開発では、1スプリントごとに振り返りを行うことで、次回スプリントの不確実性を解消していくことができます。たとえば、今回のスプリントでは、チケットを消化できなかったとします。その原因を分析し、早々に修正をかけることで次回スプリントでは同じ過ちを回避するということができるとのこと。

また、チケット駆動開発においてGitのgit-flowやGitHub Flowなどの機能によるブランチモデルを利用して、開発フローの意思統一を図るというアイデアも紹介してくれました。

▲git-flowをチケット駆動型開発に利用することで、意思統一を図ることもできる

クラウド時代の現場では何が起きているのか

そして最後は畑中さんによる事例紹介です。

紹介されたのは観光ビッグデータを活用した情報提供サービスを構築するというプロジェクト。宿泊統計というビッグデータの分析基盤を構築し、そこから需要予測ロジックにより導き出される予測値を提供する「観光予報プラットフォーム」だそうです。

まずは、システム全体の概要図を作成します。

▲システム概要図を作り、システム構成を考える

システム構成が見えてきたら、ソフトウェア開発規模を見積ります。

▲このとき、見積りしやすい部分と、ブレやすい部分を分けて考えるのがポイント

ソフトウェア開発規模を見積る際は、見積りしやすいもの、見積りがブレやすいものに分けるのがポイントです。事例では、見積りしやすいものとして、データ登録・整形、プログラム（バッチ）、情報発信APIシステム（API）などを挙げ、ブレやすいものとしてデータ提供システム（Webシステム）の部分を挙げています。

そして、システムではクラウド環境を利用するため、インフラのコストも見積ります。事例ではAWSを利用していました。

▲AWSを利用する場合は、Amazonの簡易見積りツールを利用するのが便利とのこと

ソフトウェア開発規模とインフラの見積り、そしてプロジェクトに関わる作業を洗い出したら、概算見積表を作成します。

▲プロジェクトに関わる作業には、コンサルティング費用、インフラの構築や運用設計、脆弱性診断、プロジェクトマネジメントなどの費用が含まれる

工数見積りにはRedmineを使ったそうです。理由としては、スクラム開発でチケット駆動開発を行うのにRedmine Backlogプラグインが使えるからだといいます。

実際のスクラム開発での流れは2週間で1スプリントを想定。しかし、最初はどれぐらいかかるかわからないので、「簡易登録機能だからこれぐらいか？」とか「僕は3日欲しい」などの意見を開発チームから聞き出し、1つ目のスプリントのストーリーポイント（≒作業時間）の見積りを作成します。

▲開発チームの意見をもとにストーリーポイントの見積りを作成する

そしてスプリントを1回し、その結果から振り返り（KPT）を行い、これを反復することで、その後のスプリントにおける精度の向上を図ります。α版は苦戦しても、β版では余裕をもって開発が進められるようにするのがポイントです。

▲振り返りによって精度を上げ、β版では余裕をもって開発が進められるようになる

これまで「見積り」と聞くと「自分には縁がない」と思っていた方もいるかもしれません。しかしアジャイル開発が増えてきた昨今、日常業務にも深く関わってきそうです。改めて、自分のプロジェクトを確認してみるのもよいでしょう。