第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）を行い、これを反復することで、その後のスプリントにおける精度の向上を図ります。α版は苦戦しても、β版では余裕をもって開発が進められるようにするのがポイントです。

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

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

【イベントレポート】今注目のRPAの考え方を知り、実務に活かす

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

最近何かとよく聞くRPA。Robotic Process Automationの略で、ロボットによる処理の自動化を意味します。ロボットといっても、物理的な実体があるわけではなく、コンピュータの中にあるソフトウェアを使って事務作業などを自動化することを指す言葉です。

これまでも事務作業を効率化するために業務システムが開発され、プログラムによる自動化は多く行われていました。RPAも目的は同じですが、注目されている理由としてRPAツールの登場があります。

そこで、2019年3月27日のイベントでは「今注目のRPAの考え方を知り、実務に活かす！」を開催。RPAツールがこれまでの自動化とどのように違うのか、無料で使えるRPAツールでどのようなことができるのか、事例や注意点を含めて増井さんに解説いただきました。

【講師】増井 敏克さん

増井技術士事務所代表。技術士（情報工学部門）。情報処理技術者試験にも多数合格。ビジネス数学検定1級。「ビジネス」×「数学」×「IT」を組み合わせ、コンピュータを「正しく」「効率よく」使うためのスキルアップ支援や、各種ソフトウェアの開発、データ分析などを行う。著書に『おうちで学べるセキュリティのきほん』『プログラマ脳を鍛える数学パズル』『エンジニアが生き残るためのテクノロジーの授業』『もっとプログラマ脳を鍛える数学パズル』『図解まるわかりセキュリティのしくみ』（以上、翔泳社）、『シゴトに役立つデータ分析・統計のトリセツ』『プログラミング言語図鑑』『プログラマのためのディープラーニングのしくみがわかる数学入門』（以上、ソシム）がある。

 

■今回のイベントのポイント
・RPAとこれまでの自動化との違い
・個人（無料の範囲）、現場でのRPA導入例
・RPAを導入する際の注意点

RPAとこれまでの自動化との違い

これまでの業務システムなどの場合、開発するにはプログラミングが必要で、修正したいときには開発者に依頼する必要がありました。しかし、RPAツールはプログラミングに関する知識が不要で、事務担当者が自分で修正できます。

同じように担当者が自動化する仕組みとして、これまでもExcelのマクロがありました。操作を記録して再生する程度であれば誰でも使えましたが、あくまでもExcelの中だけで、他のプログラムを操作するにはプログラミングの知識が必要でした。

同様に、Web画面を操作するには、Seleniumを使ってChromeやMozillaの操作を記録、実行する方法はテストやスクレイピングで多く使われていました。これも簡単に使えますが、Webブラウザ内の操作しかできませんでした。

RPAツールはマウスやキー操作を自動的に記録することで、定型作業を自動化でき、複数のアプリケーションを操作できます。このようなツールはデスクトップ自動化と呼ばれ、これまでも存在しました。しかし、RPAツールであればサーバーで実行することでパソコンを使っていない時間帯でも処理できる、OCRなど最新の技術を簡単に使える、豊富なパッケージで機能を拡張できる、などの特徴があります。

無料で使える自動化ツールとその特徴

RPAツールは多くの企業が製品を提供しており、有料の製品から無料のものまで様々です。有料のツールはサポートや研修なども含めて安心して使用できますが、少し試してみたいという場合には高価です。

そこで、最初は無料で使える自動化ツールを試してみるのが良いでしょう。例えば、日本語で簡単に使えるツールとしてUiPathがあり、Community Editionであれば無料で使用できます。フローチャートのような分岐が自在に実現でき、マウスの操作などを直感的に記録、実行できます。

Windowsでよく使われているツールとして、他にWorkFusion RPA Expressがあります。メモリの使用量が多く、コンピュータのスペックが要求されますが、タスクリストのようなイメージで簡単に処理を追加できます。英語のツールですが、それほど難しい単語も出てこないので、それほど苦労せずに使えると思います。

macOSの場合は、標準でインストールされているAutomatorを使う方法もあります。図のように、実行したアクションを並べるだけで様々な処理が可能なため、初心者でも簡単に自動化できます。

パソコンに限らず、スマートフォンでも自動化すると面倒な操作が不要になります。例えば、iOSであれば「ショートカット」という無償のアプリを使うと、便利なライブラリが最初から用意されているだけでなく、ウィジェットに登録すると簡単に実行できます。

現場で使われている事例

シンプルな例として、私の場合、Amazonで書籍の売上ランキングを確認する場面を考えます。手作業でWebブラウザを操作して、各書籍のページを開き、ランキングが表示されている部分までスクロールすると取得できますが、チェックする書籍の数が増えてくると面倒です。

そこで、自動的にWebブラウザを開き、対象のテキスト部分を取得、テキストファイルに保存することを考えてみます。例えば、Automatorでは上述のAutomatorの図のようにやりたいことを並べるだけで簡単に実行できます。

事務作業を効率化する目的では、Excelで受領した発注書を自社のWebフォームに転記、入力するような作業もよく見かけます。このような定型的で単純な処理はRPAツールが得意とする作業です。

最近では、AI機能が身近になっており、これらを連携すると便利に使える例があります。例えば、スマートスピーカーと連携すると、Google Homeに話しかけたものをEvernoteに登録するような連携はIFTTT（https://ifttt.com/）などを使うと簡単に実現できます。また、Evernoteには、登録されたメモ（ノート）をメールで送信する機能もありますので、そのメールを使った処理をRPAで自動化することもできます。Google Homeから直接メールを送信することもできますので、このような連携は手軽に実現できます。

また、最近はOCRの精度も向上しているため、受信したFAXをPDFとして処理し、そこに書かれている文字を取り出してフォームに入力する、といったことも実用的になってきました。

RPAを導入するときの注意点

RPAはプログラミングなどが不要なため、情報システム部門が関係しなくても簡単に導入できてしまいます。これは、「シャドーIT」のリスクがあると言えます。ファイル共有サービスなどを従業員が勝手に利用して情報が漏洩することなどを指す言葉ですが、RPAツールでも様々な問題が発生する可能性があります。例えば、管理者が行っていた作業を自動化すると、IDの使い回しが発生したり、一般社員でも管理者権限で実行できてしまったりするかもしれません。

また、作成した処理を誰がメンテナンスするか、という問題もあります。例えば、使用しているシステムに以下のような変更が発生すると、RPAツールが処理の実行に失敗します。

● フォルダ内のデータを処理している場合、フォルダを移動した、フォルダ名を変更した、といった操作が行われた
● Webサイトから何らかのデータを取得している場合、サイトがリニューアルされた
● 社内システムで、情報システム部門がシステムを改修した

このような場合、RPAの処理を作った人が異動したり退職したりすると、中身がわからなくなってしまいます。さらに、これまでのシステム開発では丁寧に設計し、全体最適となるように検討していましたが、RPAだと担当者が思いつくままに実装してしまい、個別最適になってしまう可能性があります。

何よりも問題なのが、ロボットの数が増えてくると、その管理ができないことです。動いているつもりでもエラーが発生している、間違った処理をしていても気づかない、といった状況が発生します。そもそも誰がログを管理するのか、という問題もあります。

このように、RPAは手軽に導入できて便利に使える一方で、運用面も含めて検討しておかないと、後々トラブルが発生する可能性もあることに注意が必要です。メリットとデメリットを正しく理解し、導入するようにしましょう。

【イベントレポート】IoTセキュリティとソフトウェアの脆弱性を考える

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

2019年3月8日のイベントでは「マジメだけどおもしろいセキュリティ講義 ～IoTセキュリティとソフトウェアの脆弱性をめぐる議論～」と題し、書籍『マジメだけどおもしろいセキュリティ講義』の著者でもあるすずきひろのぶさんを講師にお迎えして、コンピュータセキュリティの最前線について教えていただきました。

■今回のイベントのポイント
・大規模DDoS攻撃を引き起こしたMIRAIのケーススタディ
・過去例からIoT機器の脆弱性について考える
・現状におけるIoT機器のセキュリティの問題を整理
・脆弱性情報流通の枠組みと運用について
・政府のあたらしい取り組みNOTICE

【講師プロフィール】
すずき ひろのぶ（鈴木裕信）さん
1985年、株式会社SRAに入社。UNIXやネットワーク関連のソフトウェア開発を経験後、同社ソフトウェア工学研究所にてネットワークやソフトウェア品質の研究を行う。1997年にソフトウェア・コンサルタントとして独立。JPCERT/CCの立ち上げ時から運営に参加し、現在も一般社団法人JPCERTコーディネーションセンター理事として情報セキュリティに携わるほか、実践女子大学、専修大学、中央大学で非常勤講師として勤めると同時にユニバーサル・シェル・プログラミング研究所に在籍しSELinuxの実践的利用の研究や実践的IoTセキュリティの研究を進める。

大規模DDoS攻撃を引き起こしたMIRAIのケーススタディ

セキュリティにおいて、注目すべきホットな話題が、IoT機器をボット化させてDDoS攻撃をしかけたマルウェア（悪意を持つソフトウェア）「MIRAI」の登場です。

MIRAIを知る前に、まずDDoS攻撃について説明されました。DDoS攻撃は、いわばDoS攻撃の進化版です。DoS（Denial of Services：サービス拒否）攻撃でもいちばん困るのは、正常に見えるアクセスを大量にサーバに送り付け、処理をマヒさせてしまうというもの。

しかし、単一のIPアドレスから送信されるパケットは制御可能な上、サーバ側の処理能力が攻撃側の処理能力を上回っていれば攻撃は成り立ちません。パソコンを一台、二台用意しただけでは企業や官庁などの規模のサイトを麻痺させることはむずかしいのだそうです。

そこで登場するのがDDoS（Distributed DoS：分散サービス拒否）攻撃です。一斉に異なるIPアドレスからパケットを送り付けてオーバーフローさせてしまうというもの。どれだけ多くの攻撃ノードを用意できるかが重要になってくるそうです。

▲DDoS攻撃のイメージ。マルウェアに感染した攻撃botが、ターゲットとなるサーバに一斉に攻撃を仕掛ける（出典: 講演スライドより）

2016年9月に登場した「MIRAI」は、約14万5千もの攻撃ノードから、1秒間に9300万パケット、転送量にして約799Gbpsの攻撃を仕掛けたそうです。すずきさんによれば「このパケット量に耐えられるシステムはそうそうありません」とのこと。

では、なぜMIRAIは、このような前代未聞の大量攻撃を仕掛けることができたのか。それは「IoT機器が攻撃ノードとして使われたから」だそうです。

今では、街中のいたるところに設置され、防犯や安全に貢献しているカメラですが、それらはIPネットワークで接続されており、撮影画像を送信するために通信機能を備えています。

MIRAIは、こうしたネットワークカメラ1台1台に内蔵されているコンピュータに侵入し、C&Cサーバと呼ばれる司令塔からの命令によって、一斉攻撃を仕掛ける仕組みになっています。また、MIRAIは非常に考えて作られており、感染したマルウェアが周辺のIPアドレスをサーチし、見つけた対象のアーキテクチャ（ARM、X86、SuperH、MIPS等）に最適なバイナリを送り込みます。そうして、わずか72時間で、約14万5千もの攻撃ノードを手に入れたのだそうです。恐ろしいですね。

MIRAIのC&Cサーバも設計が練られていて、200万台のノードをコントロールできるように設計されていたそうです。200万台のノードが一斉攻撃を仕掛けると考えただけでも、ぞっとします。

MIRAIの感染対象はインターネットカメラが搭載する「組込みLinux」というOSでしたが、これはインターネットカメラだけでなく、家庭で利用しているブロードバンドルータなどにも利用されています。そして、感染した機器には共通の条件がありました。telnetのポートをオープンにしていたこと、デフォルトアカウントからroot権限が使えたこと、管理用ログインアカウントとパスワードが出荷時のままであったこと、などです。

この話を聞くと、自宅のブロードバンドルータのパスワードを購入時のものから変えておいたかどうか、不安になる方もいるかもしれません。

ちなみに、MIRAIを作成した犯人はすでに逮捕されており、MIRAIおよびC&Cサーバのソフトウェアは公開されており、その手口は解明済みです。

現状におけるIoT機器のセキュリティの問題を整理

イベントでは、このほかにも、東芝のHDDレコーダーや、I・Oデータ機器のネットワークカメラなどが狙われた過去の事例や、海外事例としてHospira Lifecare PCA輸液ポンプのroot権限が乗っ取り可能という重大な脆弱性が存在していたケースなども紹介されました。輸液ポンプは医療現場で使われるだけに、人命に直結する脅威です。

こうしたIoT機器が、今後も狙われることは間違いなく、新たな対策が必要です。その対策の1つとして、すずきさんが紹介してくれたのが「SHODAN」というサービスです。

▲SHODANを使えば、自分が使っているIoT機器が外部からどう見えているかがわかる （出典 https://www.shodan.io）

「SHODAN」は、合法的な手法で、オンラインになっているサービス機器を見つけるサービスです。インターネット側からアクセス可能なIoT機器はインターネットに接続した瞬間に、第三者に見つけられるのは時間の問題になります。それなら、「SHODAN」を使って、自分たちの設置したIoT機器が、外部からどう見えているのかを確認しておこうというポジティブな使い方をすずきさんは提案していました。本来はインターネット側からアクセスされる意図はなかったのにアクセスできてしまうような誤った設定などを見つけるのにたいへん有用で、これはIPA（独立行政法人 情報処理推進機構）も推奨しています。

また、別のアプローチとして、IoT機器のネットワーク空間をインターネットから切り離し、セキュアな仮想ネットワークを構築するという試みもあり、すでに株式会社ソラコムやニフティ株式会社が、そうしたサービスを提供し始めています。

▲IoT機器をインターネットから切り離されたセキュアな仮想ネットワークで接続する取り組みもある（出典：講演スライドより）

脆弱性情報流通の枠組みと運用について

また、重要な課題であるソフトウェアの脆弱性についても、これを周知させるため、中立的な第三者による、統一した脆弱性情報ハンドリングの必要性についても説明しました。

米国では、これを国家安全保障の範囲と捉え、米国土安全保障省（DHS）の資金提供によるMITREという団体が脆弱性情報のハンドリングを行っていて、NIST（米国立標準技術研究所）では、脆弱性情報のデータベース化も行っているそうです。

一方、日本国内では、JPCERT/CCやIPAが経済産業省の告示に従い、海外とも連携しながら脆弱性情報のハンドリングを行っています。

▲日本国内での脆弱性情報のハンドリングはJPCERT/CCやIPAが推進。国際連携もしっかり行っている

政府のあたらしい取り組みNOTICE

最新の話題として、2019年1月に、総務省とNICT（情報通信研究機構）と各インターネットサービスプロバイダが連携してIoT機器への無差別侵入調査・注意喚起を行う「NOTICE」という取り組みが発表されました。

▲NOTICEは、botが行うような試みをNICTが行い、安全予防に対する注意喚起を行う

この「無差別侵入」が不正アクセス禁止法に触れるのではないかという疑念もありましたが、一方で、ルータやネットワークカメラのデフォルトパスワードはマニュアルに記載されて公知なものとなっており、「みだりに第三者に知らせてはならないものとされている符号」に当たらないという見解も主流になりつつあります。しかし、昨今の状況からそのままでは警察や検察がどう解釈するかは予想できません。

そこで、NOTICEの実施にあたっては法改正を行い、通称「NICT法」の中に新たに「特定アクセス行為」という概念が取り入れられました。

▲NICT法では合法的に新たに「特定アクセス行為」という概念が盛り込まれた（出典：講演スライドより）

今後は、IoT機器の販売に対してデフォルトパスワードのままでは使えなくなるように指導が入る流れが予想されるものの、海外製品の国内OEM販売などでも徹底できるかどうかなど、不透明な部分も多々あります。

いずれにしても、IoT機器が私たちの身近にどんどん増えていくことは間違いありません。こうした動きに、もっと敏感になっておく必要がありそうです。

増井敏克の「情報のキャッチアップが足りない」ときに読むコラム 第4回 脆弱性ってなんだろう？

情報システムやネットワークに対する攻撃は多様化し、情報漏洩や不正アクセスのニュースは世界中で後を絶ちません。脆弱性への知識や脆弱性診断の需要は高まるばかりですが、皆さんは脆弱性について、どれくらい理解しているでしょうか。今回のコラムでは、エンジニアとして、脆弱性について知っているとよい内容をまとめました。

【講師】増井 敏克さん

増井技術士事務所代表。技術士（情報工学部門）。情報処理技術者試験にも多数合格。ビジネス数学検定1級。「ビジネス」×「数学」×「IT」を組み合わせ、コンピュータを「正しく」「効率よく」使うためのスキルアップ支援や、各種ソフトウェアの開発、データ分析などを行う。著書に『おうちで学べるセキュリティのきほん』『プログラマ脳を鍛える数学パズル』『エンジニアが生き残るためのテクノロジーの授業』『もっとプログラマ脳を鍛える数学パズル』『図解まるわかりセキュリティのしくみ』（以上、翔泳社）、『シゴトに役立つデータ分析・統計のトリセツ』『プログラミング言語図鑑』『プログラマのためのディープラーニングのしくみがわかる数学入門』（以上、ソシム）がある。

脆弱性とバグの違い

ソフトウェアなどにバグがあると、利用者は想定した操作ができず、通常の使い方であっても問題になります。つまり、設計された通りに実装されておらず、利用者はその問題に気づきます。

それに対し、脆弱性の場合は利用者が通常の使い方をしている場合は気づきません。その製品の開発者すら気づいていないことがほとんどです。しかし、攻撃者がその脆弱性を見つけると、その問題点を狙った攻撃が可能となり、情報漏洩やファイルの破壊などの攻撃が成立してしまいます。

脆弱性と似た言葉にセキュリティホールがありますが、一般的には脆弱性の方が広い意味で使われます。例えば、教育不足による「人の脆弱性」や、ハードウェアに存在する問題に使われることもあります。一方で、セキュリティホールは主にソフトウェアの脆弱性に使われます。

脆弱性やバグがソフトウェアに存在すると、多くの場合は開発会社から修正プログラムや更新プログラムが提供されます。このプログラムをダウンロードし、適用することで、脆弱性を修正できます。このようなプログラムの中でも、セキュリティに特化したものをセキュリティパッチと呼ぶこともあります。

ただし、サポートが終了した製品に対してはこのような修正プログラムが提供されない場合があるため、サポート期間には注意が必要です。もし修正プログラムが提供されない場合は、該当のソフトウェアを使用しない、代替のソフトウェアに切り替える、といった対応が必要かもしれません。

なお、「情報セキュリティ早期警戒パートナーシップガイドライン」が定められており、ソフトウェアやWebサイトに脆弱性を発見した場合にはIPA（情報処理推進機構）に報告することになっています。

参考）https://www.ipa.go.jp/security/ciadr/partnership_guide.html

脆弱性を防ぐために開発者が注意すること

開発者にとっては、開発の各ステップにおいてセキュリティを意識することが大切です。ソフトウェアの開発においては、要件定義から設計、実装、テスト、運用という大きな流れがあります。この各ステップにおいて、セキュリティレビューやソースコードレビュー、脆弱性診断やシステム監査・セキュリティ監査などを実施します。

特に脆弱性診断は重要で、開発したアプリケーションに脆弱性がないか調べるだけでなく、以下の図のようにネットワークの設定漏れやファームウェアの更新状況、サーバーの設定ミスやOS、アプリケーションの修正プログラム適用状況、不要なサービスの有無なども確認します。データベースには不要なユーザーが登録されていないか確認することも必要です。

また、脆弱性を作り込まないために最新の情報を仕入れることも大切です。例えば、Webアプリを開発する場合は、IPAによる「安全なウェブサイトの作り方」を読んでおくことは必須です。

さらに、最新の情報を収集します。IPAの情報セキュリティページ（https://www.ipa.go.jp/security/index.html）や、JVN（https://jvn.jp）を使う方法があります。JVNは情報セキュリティに関するポータルサイトで、各ベンダーのサイトを順に調べるよりも手軽に、統一されたフォーマットで一覧表示できます。

また、発見された脆弱性が対応を優先すべきかどうか調べるには、CVSS（Common Vulnerability Scoring System）を使う方法があります。JVNのサイトではCVSSの評価値が公開されていますし、以下の図のようなCVSS計算ソフトウェアを使って自分でCVSS値を計算することもできます。

参考）https://jvndb.jvn.jp/cvss/

脆弱性診断手法を知る

脆弱性診断は手作業で実施することもできますが、多くの場合は専用のツールを使用します。例えば、無料のツールとして、OWASP ZAPやBurp SuiteのCommunity版などがあります。また、脆弱性があるとどのような攻撃が可能なのかを学ぶには、IPAが公開している脆弱性体験ツールAppGoat（https://www.ipa.go.jp/security/vuln/appgoat/index.html）を使用するのも一つの方法です。

2019年2月にはIPAから「脆弱性対策の効果的な進め方(ツール活用編)」という資料も公開されています。この資料には脆弱性を取り巻く状況や脆弱性対策の考え方がまとめられています。 （参考：https://www.ipa.go.jp/security/technicalwatch/20190221.html）

なお、脆弱性診断を行う場合には、自分が管理しているサーバー、アプリ以外には行わないようにしてください。勝手に攻撃すると、不正アクセス禁止法などに抵触する恐れがあります。脆弱性診断を行うとデータを破壊する場合があり、ページの内容やデータベースが書き換えられるため、事前にバックアップを取得しておくことは必須です。

このとき、誤検知の可能性についても理解しておきましょう。脆弱性診断ツールが検知しても、攻撃が成立するとは限りません。また、脆弱性診断ツールが検知できなくても、脆弱性が存在しないとは言えません。このため、手作業での脆弱性診断と組み合わせて実施することが一般的です。

脆弱性に関する理解は深まったでしょうか。たとえば、Webアプリを公開してから脆弱性が見つかった場合、サービスの停止などに追い込まれ、企業の存続に関わる場合もあります。脆弱性に関する最新の情報をキャッチアップすることは、大きなアクシデントを防ぐ一助となり得ます。日々のセキュリティに関するニュースを見る際は、原因に目を向けてみると、また違った見方ができそうです。