パソコンやスマートフォン、スマート家電など、私たちが生活の中で日々手にするものの多くで使われているプログラミング言語「JavaScript」。エンジニアにとっては、プログラミング技術を知る上では避けて通れないほどの存在感を持つ言語です。

そのJavaScriptの基本の一つである「配列」についてここでは解説します。

[【関連記事】「未経験だけどIT業界に転職する方法! 職種や仕事内容もご紹介」](https://mynavi-agent.jp/knowledge/it/762.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

[【求人特集】「システムエンジニアの転職」](https://mynavi-agent.jp/it/systemengineer/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

配列(Array)とは、プログラミングにおいて複数の値を1つのデータのように取り扱うデータ構造のことです。

一般的にプログラミングでは、文字列や数値を変数に代入して処理しますが、そのデータが10個や20個、さらには100個以上もある場合、一つひとつ変数に代入するのが大変であるため、この配列がよく用いられます。

プログラミング言語であるJavaScriptでも、配列を利用することができるようArrayオブジェクトが用意されています。このArrayオブジェクトを活用することで、配列の作成や追加・削除などが簡単に行えるようになります。

まずは、実際にJavaScriptで配列を利用するための基本的な手順について解説します。

JavaScriptの配列の宣言には、2種類の方法があります。

1つ目は、配列コンストラクタ「Array」を使う方法で、newでArrayの引数に格納したい値を設定します。

2つ目は、配列リテラルを使う方法で、配列に格納したい値を[]内に設定します。具体例として、それぞれコードの記述は次のようになります。

```
//配列コンストラクタ例
var array1 = new Array(‘東京’, ’大阪’, ’愛知’);

//配列リテラル例
var array2 = [‘東京’, ‘大阪’, ‘愛知’];
```

なお、数値を格納する場合は注意が必要です。例えば、配列コンストラクタで「new Array(3)」のように宣言すると、「3つの空の要素をもつ配列を宣言する」という命令になり、”3”という値は格納されません。配列リテラルではそのまま入力した数値が配列の要素として格納されるため、目的にあわせてうまく使い分けましょう。

配列を初期化するには、配列コンストラクタでも配列リテラルでも空の配列であることを宣言します。具体例として、次のようなコードになります。

```
//配列コンストラクタ例
var array1 = new Array();

//配列リテラル例
var array2 = [];
```

配列内の要素を取得する場合は、配列のインデックス番号を指定します。具体例として、次のようなコードになります。

```
var KantoArea = [‘東京’, ‘神奈川’, ‘千葉’, ‘埼玉’, ‘栃木’, ‘茨城’, ‘群馬’];

console.log(KantoArea［1]);　//実行結果は『神奈川』
```

注意点として、インデックス番号は0から始まります。したがってインデックス1を指定している上記の例では、2番目の要素である「神奈川」が実行結果として表示されます。

JavaScriptでは、配列内の要素を検索するためにindexOfメソッドが用意されています。

indexOfメソッドは、引数に指定した値が配列データに存在する場合、そのインデックスを返します。具体例として、次のコードを見てみましょう。

```
var city = [‘新宿’, ‘渋谷’, ‘池袋’];
var n = items.indexOf(‘渋谷’);

console.log(n);　//実行結果は『1』
```

この例では、配列cityに対してindexOfメソッドで文字列「渋谷」が存在するかを確認しています。配列city内で「渋谷」は2番目にあるため、インデックス番号の「1」がnに代入されたことになります。

## 3.pushメソッドを使って要素の追加

JavaScriptで配列に要素を追加したい場合は、pushメソッドを使用します。

pushメソッドは、引数に指定した値を配列の最後に追加します。具体例として次のコードを見てみましょう。

```
var curry = [‘じゃがいも’, ‘たまねぎ’, ‘にんじん’];
curry.push(‘豚肉’);
```

この例では、配列curry宣言時にあらかじめ「じゃがいも」「たまねぎ」「にんじん」の3つの要素が含まれていますが、その最後列に「豚肉」という要素を追加しています。

## 4.delete演算子を使って要素の削除

JavaScriptで配列の要素を削除したい場合は、delete演算子を使用します。

delete演算子は、指定したインデックス番号の要素を削除します。具体例として、次のコードを見てみましょう。

```
var fruits = [‘りんご’, ‘ぶどう’, ‘すいか’, ‘いちご’];
delete fruits［2];

console.log(fruits); //実行結果は『りんご,ぶどう,,いちご』
```

この例では、配列fruitsからdelete演算子によってインデックス番号2の値である「すいか」を削除しました。要素を削除すると空の要素になりインデックス番号は変化しない点に留意しましょう。

## 5.joinメソッドを使って配列の結合

JavaScriptで配列の要素を結合させたい場合、joinメソッドを使用します。

joinメソッドは、配列の各要素を結合させ、ひとつのString型の要素として出力します。具体例として、次のコードを見てみましょう。

```
var christmasValue = [2019, 12, 25];
var christmasDate = christmasValue.join(‘/’);

console.log(christmasDate);　//実行結果は『2019/12/25』
```

このように、joinメソッドは配列内の各要素を引数に指定した文字列で連結させることができます。なお引数に何も指定しなかった場合は、カンマ区切りの文字列となります。

## 6.sliceメソッドを使って配列の分割

JavaScriptで配列の要素を分割させたい場合、sliceメソッドを使用します。

sliceメソッドは、指定したインデックス番号を境目に、新たな配列要素として出力します。第1引数に境目の開始位置、第2引数に終了位置となるインデックス番号を指定します。なお、第2引数を指定しなかった場合は最後の配列要素まで分割されます。

具体例として、次のコードを見てみましょう。

```
var fruitsList = [‘りんご’, ‘ぶどう’, ‘すいか’, ‘いちご’];

var newFruitsList1 = fruitsList.slice(1);
console.log(newFruitsList1);　//実行結果は『ぶどう,すいか,いちご』

var newFruitsList2 = fruitsList.slice(1, 2);
console.log(newFruitsList2);　//実行結果は『ぶどう,すいか』
```

この例では、newFruitsList1では第1引数のみ指定しているためインデックス番号1以降の要素が、newFruitsList2では第1引数と第2引数を指定しているためインデックス番号1〜2の要素が、新たな配列データとして分割されています。

配列内のデータをループ処理するには、for文を利用するのが一般的です。for文は、指定した回数だけ処理を繰り返すための構文で、『for(初期値; 条件式; 増減値)』と記述します。具体例として、次のコードを見てみましょう。

```
var array = [‘a’, ‘b’, ‘c’, ‘d’, ‘e’];

for(var i = 0; i < 5; i++) {
　console.log(array[i]);
}
```

このコードでは、iが0以上5未満の場合にiを1ずつ増加して繰り返し処理をするため、実行結果としては配列lists内のデータが順に出力されます。

## 8.もっと配列を便利に扱う方法

応用編として、JavaScriptで配列データを扱うために覚えておくと便利な方法について解説します。

### 8.1.concatメソッドを使って配列をコピー

JavaScriptにおいて、作成済みの配列をコピーして別の配列として使用したい場合はconcatメソッドを使うと便利です。

concatメソッドは指定した配列を対象の配列に連結するためのものですが、対象の配列が空だった場合指定した配列と同一の内容になります。具体例として、次のコードを見てみましょう。

```
var array = [‘a’, ‘b’, ‘c’, ‘d’, ‘e’];
var newArray = array.concat();

console.log(array);　//実行結果は『a,b,c,d,e』
console.log(newArray);　//実行結果は『a,b,c,d,e』
```

このように、引数を空にすることで元の配列データをそのまま新しい配列へコピーできます。

### 8.2.filterメソッドを使って要素の抽出

JavaScriptの配列内における特定の要素を抽出したい場合、filterメソッドを使います。

filterメソッドは、コールバック関数に取得したいデータの内容を指定し、任意のデータを抽出するためのメソッドです。具体例として、次のコードを見てみましょう。

```
var array = [2, 7, 3, 9, 8, 1, 5];
var result = array.filter(function(value) {
　return value < 5;　//5より小さい数値を抽出
}

console.log(result);　//実行結果は『2 3,1』
```

このコードでは5未満という条件を指定しているように、コールバック関数内に指定した条件だけをデータとして抽出できます。

なお、該当するデータが見つからない場合は空の配列が返ることになります。

### 8.3.lengthプロパティを使って要素数のカウント

JavaScriptの配列にて、要素数をカウントするにはlengthプロパティを使用します。具体例として次の例を見てみましょう。

console.log(array.length);　//実行結果は『5』
```

私たちが生活の中で日々手にするものの多くで使われているプログラミング言語「JavaScript」。エンジニアにとっては、プログラミング技術を知る上では避けて通れないほどの存在感を持つ言語です。そのJavaScriptの基本の一つである「配列」についてここでは解説します。

【初心者向け】JavaScriptの配列の基礎的な使い方！プログラミングに配列は必須！

## 手計算でQRコードを作る、目と手計算でQRコードを読み取るのは授業では格好の教材

QRコードを紙とペンで手書きする。あるいは紙とペンを使ってQRコードを解読する。そんな無駄なことをして何になると思われる方も多いだろう。しかし、何かの仕組みを理解するときは、手を動かしてみるのがいちばん早く、深く理解できる。最近では、決済にまで使われるようになったQRコード。その仕組みを体感しておくのは決して無駄にならない。

手計算でQRコードを作る、目と手計算でQRコードを読み取るというのはかなり面倒な作業だが、適切なワークシートを用意してあげれば不可能ではない。ワークショップや授業では格好の教材となるはずだ。

[【関連記事】「IT・エンジニアの職種図鑑」](https://mynavi-agent.jp/it/jobindex/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

まず、QRコードの基本仕様を確認しておこう。左上、左下、右上の3カ所にあるマークは、位置検出パターン。この3つがあるため、QRコードは斜めになっていても、逆さになっていても読み取ることができる。さらに、QRコードが、曲面に貼られて、歪んでいるような場合でも補正ができる。

位置検出パターンの間にある2カ所の「10101」はタイミングパターンと呼ばれる。これにより、QRコードの座標を確認する。

このような基準パターンをうまく使って、斜めになっていたり、歪んだりしているような場合にも読み取れる工夫をしている。

水色の部分は、形式情報が格納される領域で、誤り訂正レベルやマスクパターンの種別が指定されている。左上の14マス、左下＋右上の14マスには同じ内容が記述される。残りの黄色い部分にデータが書き込まれている。

~~ QRコードの構造。3つのシンボルにより、QRコード全体が傾いたり、歪んだりしていても読み取りができる。データは黄色部分に格納されている ~~

誤り訂正レベルというのは、データに冗長性を持たせて、QRコードが汚れたり破損したりしても読めるようにするための工夫だ。実データと同じ内容を一定の算法で変換して格納し、冗長性を持たせている。誤り訂正レベルには4レベルあり、最低7％から最高30%までコードが読み取れなくても、データ読み取りを可能にする。一般的には15%の誤り訂正レベルを採用しているが、工場内などのタフな環境では最高の30％の訂正レベルが採用される(この場合は、誤り訂正符号が多くなり、QRコードのサイズが大きくなる)。

~~ QRコードのデータは誤り訂正符号という冗長データが付加されている。これにより、コードの一部が汚れていても、読み取りができる ~~

マスクパターンは、データの内容によって、0ばかり、1ばかりになるのを防ぐ仕組みだ。QRコードが白ばかり、黒ばかりになってしまうと読み取りが難しくなるので、なるべく白と黒が均等に現れるようにする工夫だ。一定のパターンで、指定されたドットの色を反転させる。マスクパターンは8種類用意されていて、どのパターンを使うのが最も優れているかが評価され、決定される。

## 手書きでQRコードを作ってみよう

こんなことを頭に入れて、手書きでQRコードを作ってみよう。ここでは、GEEKROIDという文字列をQRコード化させてみる。

先頭は、文字種と文字数を指定する。この場合英数字モードなので、規格表に従って0010で指定し、文字数は8文字なので、000001000(2進数で8)と指定する。合わせて、

となる。この後に具体的なデータを加えていく。まず、GEEKROIDを数値化する。これは対応表に従う。単純に0から9までの数値はそのまま、Aが10、Bが11というものだ。

QRコードの英数字モードでは、2文字をひとつの単位として扱う。GEEKROIDであればGEが最初のデータ単位となる。最初のGを45倍して、Eに加え、これを11桁の2進数表記する。01011011110となる。

英数字モードでは、英数字と記号の45種類(2進数で6桁)の文字があるので、そのままだと、2文字を表すのに12桁が必要になる。最初の文字を45倍して合成することで、11桁に収めることができ、同じサイズのQRコードにより多くの情報を格納できるようになる。

0010 000001000 01011011110 01010001010 10011010111 01100110111

これをQRコードに記入していく場合は、右下から図のように、右左右左と上がっていき、上まで行ったら右左右左と下がってくる。これを繰り返していく。

~~ QRコードのデータは、右下から始まり、右左右左と上に上がっていく。上までいったら、右左右左と下がってくる ~~

データの後には、一定の算法で計算した誤り訂正符号をつけ、QRコード全体が埋まることになる。

最後に、最適なマスクパターンを適用し、指定ドットの白黒を反転させる。これでQRコードが完成する。

実際にワークショップなどの教材に使う場合、誤り訂正符号の計算が手計算では難しい。そこで、あらかじめQRコード作成ツールなどを使って出力したQRコードから、実データ部分だけを白抜きにしたワークシートを用意して、ここを手作業で埋めてもらうというような工夫をする必要がある。

## 既存のQRコードを目と手作業で読むのは、適切なQRコードを用意すれば不可能ではない

一方で、既存のQRコードを目と手作業で読むのは、適切なQRコードを用意すれば不可能ではない。

まず見なければならないのは、形式情報領域(水色の部分)だ。15桁あるが、重要なのは最初の5桁で、残りの10桁は誤り訂正符号になっている。

最初の5桁を読むと、00 100となる。00が誤り訂正レベルがレベルM(15%まで損失OK)であることを示し、100がマスクパターンの100が採用されていることがわかる。

右下の4マスは、文字種の指定で、マスクパターンに注意して読むと0010となり、英数字モードであることがわかる。次の9マスは文字数の指定、その後の11マスごとに2文字ずつデータが記録されている。データが終わった後には、一定の方式で計算された訂正符号で埋めつくされている。

~~ 簡単なものであれば、QRコードを目と手作業で読むことは不可能ではない。ただし、相当に面倒で、仕組みを理解するところから始めると、1日がかりの作業になる。QRコードを教材にしたワークショップや授業にちょうどいい教材となる ~~

QRコードの生成と読み取りは、実際にはかなり複雑で、すべてを手計算でやるのは難しい。特に訂正符号の計算は、電卓レベルを超えている。しかし、それ以外の部分は手作業でもなんとかなるので、フレームワークとなる教材を用意してやれば、中学生の情報科学系の部活動研究、高校生の情報科の授業や初級エンジニアのトレーニングなどに使っても面白いと思う。

(1)ツールで生成したQRコードから実データ部分だけを白抜きにしたワークシートを用意し、そこを手作業で埋めてもらう。

(2)簡単な内容のQRコードを生成しておき、手作業で読んでもらう。

であれば、2時間×3回程度で収まるのではないかと思う。その過程で、記数法、マスク、領域の節約手法、誤り訂正の仕組みなどの知識が身につき、さらに運用上の工夫を実感することができるはずだ。

身近になっている小さなQRコードの中に、これだけの知恵が込められることを知るのは、子どもたちや若いエンジニアにとって、貴重な経験となるはずだ。

なお、QRコードの仕様にはさまざまなルールがあるので、この記事の説明だけでは仕組みを理解するのは難しいかと思う。

キーエンスが公開している「[よくわかる2次元コードの基本](https://www.keyence.co.jp/downloads/?mode=tg&o=0&group_id=tcm%3A106-1619397&type_id=&webseries_id=&_fsi=x2Y9Smax)」、デンソーウェーブ公式のQRコード作成サイト「[arara](https://m.qrqrq.com/?_fsi=x2Y9Smax)」などを、合わせて読みながら理解していただければ幸いだ。

QRコードは手作りできる?肉眼でも読み取れる?「QRコード手作り体験」のススメ

## Felicaがあるのに、なぜQRコード決済が増えていくのか

新たなQRコード決済が続々登場している。「100億円還元」で有名になった「PayPay」、LINEのユーザー数を背景にした「LINEペイ」。携帯電話キャリアもNTTドコモが「d払い」、KDDIは「auペイ」を始めている。さらに、ゆうちょ銀行が「ゆうちょPay」を始め、今年秋には1000行以上もの銀行が参加する「Bank Pay」が始まる。ECサイトもアマゾンが「Amazon Pay」、楽天市場が「楽天ペイ」。コンビニでは、セブンイレブンが「7pay」、ファミリーマートが「ファミペイ」を始める。

もう「ペイ」だらけで、ここまでくると「QRコード決済のゴリ押し」とすら思いたくなる人も多いのではないだろうか。なぜ、こんなにもQRコード決済が乱立するのだろうか。

しかも、多くの人が疑問に感じるのが、Suicaに代表されるFelicaというタッチするだけ決済ができる素晴らしいテクノロジーが日本にはあるのに、なぜわざわざセキュリティも弱く、ユーザー体験も悪いQRコード決済ばかりが増えていくのかということだ。QRコード決済をするには、事前にスマホのアプリを起動して、QRコードを表示してからレジのスキャナーにかざさなければならない。あるいは、逆にアプリを起動して、カメラを起動し、店舗側のQRコードを自分でスキャンし、金額を入力して支払わなければならない。

Suicaならタッチするだけ完了だし、クレジットカードでも差し込んでPINコード(暗証番号)を入力するだけで終わる。日本は技術を持っているのに、わざわざQRコード決済に逆行していると思っている人も多いはずだ。

~~ファミリーマートで利用できる決済サービス一覧。クレジットカード、交通系カードはひとまとめにしているのに、21種類もある。スタッフもレジ操作を覚えるのがたいへんだと思う（[http://www.family.co.jp/services/payment.htmlより](http://www.family.co.jp/services/payment.html)より）。~~

## 鍵になっているのは決済手数料

なぜ、続々とQRコード決済がゴリ押しされるのか。鍵になっているのは決済手数料だ。多くのキャッシュレス決済では、3%から5%の決済手数料を取って、それで利益を出している。例えば、クレジットカードで100円の買い物をすると、お店の実入りは97円で、3円はカード運営会社に手数料として取られる。

わずか3%程度と言え、これは大きい。例えば、あなたがカフェを経営して、１日50万円の売上があったとする。月30日営業して、月の売上は50万×30日＝1500万円となる。すべてキャッシュレス決済だとすると、1500万円×3%=45万円が手数料として取られることになる。

よく「キャッシュレスの利点は、現金を扱う不要な業務コストを削減できること」と言われるが、現金を数えたり、釣り銭を用意したりという作業は、店長の1日の労働時間のうち10%程度ではないだろうか。多く見積もって20%とし、店長の人件費が月50万円だとすると、現金扱いコストは50万円×20%＝10万円となる。つまり、現金オンリーにしたらコストは10万円、キャッシュレスオンリーにしたらコストは45万円となり、現金の方がコストが抑えられるのだ。こんなパラドクスも生まれてしまう。

個人経営のカフェではどうしようもないが、体力のある小売チェーンなどでは、この手数料による利益の流出をなんとかしたい。解決策は自分でキャッシュレス決済を運営してしまうことだ。よその会社に取られるぐらいだったら、自社あるいは自社グループ内に還流させたい。

## 小売チェーンは、防衛的な理由でQRコード決済立ち上げ

かといって、クレジットカードやFelica決済という本格的なキャッシュレス決済はコストがかかりすぎる。そこで、決済システムもシンプルで、アプリで対応できるQRコード決済を始めることになる。

体力のある小売チェーンは、このような防衛的な理由で、QRコード決済を立ち上げている。

非小売業にとっては、手軽に決済業務に参入できるチャンスになる。キャッシュレス決済業を始めるには、システムだけあっても意味がない。決済方式に対応してくれる加盟店を集める必要がある。しかし、この加盟店開拓業務が大きな参入障壁になっている。なぜなら、基本的には街中の商店を1軒1軒回って、店主を口説いていくという伝統的な営業手法を取らざるを得ないからだ。

膨大な人数の営業部隊が必要になり、継続的に営業活動をしていかなければならない。既存のクレジットカード会社は、長年、この加盟店開拓業務を地道にしてきた蓄積があるため、多くの店舗で利用できるようになっている。

クレジットカードのビジネスは、大雑把にいって、加盟店から手数料を3.5%取り、このうちの1.5%が加盟店開拓と管理を行うカード会社(アクワイアラー)の収入となる。残りの1.5%がカード発行会社(イシュアー)の収入になり、さらにネットワーク接続料などに消える。つまり、クレジットカード手数料の半分弱が加盟店開拓、管理コストなのだ。

[『マイナビIT AGENT』なら、IT業界に精通した専任アドバイザーと豊富な求人で、あなたの転職を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

## QRコード決済では、加盟店開拓コストも大きく削減

QRコード決済では、この加盟店開拓コストも大きく削減できる。QRコード決済の加盟店になるには、スマートフォンかタブレットがあればよく、特殊なカードリーダー端末やPOSレジといった設備は必要ない。そのため、開拓営業をしなくても店主自らアプリをダウンロードして、セットアップして加盟店になることができるからだ。もちろん、従来的な加盟店開拓営業もしているが、1軒1軒回るなどというやり方よりも、商店会などで店主を集めて説明会をして、その場でアプリをインストールして加盟店になってもらうという手法もよく行われている。

つまり、QRコード決済が雨後の筍のように登場して乱立している理由は、企業側の都合なのだ。「アプリを起動してQRコードを表示し…」という消費者側の利便性は置き去りにされてしまっているようなところがある。さらに乱立しすぎて、どの店でどの決済方式が使えるのかをいちいち確認する必要があり、「現金の方が便利なんじゃないか？」と思うことすらある。

LINE、NTTドコモ、メルカリの国内３社と「アリペイ」「WeChatペイ」の中国２社は、統一したQRコードを開発することを表明した。これが呼び水となり、他のQRコード決済も統一の動きが進んでいくものと思われる。

一方で、QRコード決済の本家である中国では、QRコードを脱して、顔認証決済やNFCを利用した決済に移ろうとしている。数年後、日本だけがQRコード決済を使っているガラパゴスになっているなどということはまさかないですよね？

~~中国杭州市のケンタッキーが運営するファストフードレストラン「KPro」。入り口のタッチパネルで、メニューを選び、顔認証決済する。顔認証決済は、カルフール、フーマフレッシュなどのスーパーやファストフードを中心に広がり始めている~~

~~NFC対応スマホで使えるテンセント乗車カード。中国200都市の地下鉄、バスの料金がタッチするだけで支払える。中国では新機種にNFC搭載が定番化したのが2017年頃であるため、ようやくNFCスマホが普及してきた。地下鉄に乗るときは、QRコード方式よりもNFCの方が圧倒的に便利だと歓迎されている~~

「〇〇ペイ」だらけのQRコード決済乱立、FelicaががあるのにQRコード決済が増える本当の理由は企業の都合？--置き去りにされる消費者の利便性

エンジニアの方の”あるかもしれない”日常風景をデフォルメしてコメディタッチに描く「エンジニアあるある」。さて、今回はどんな風景なのでしょうか...

「サーバー」と「サーバ」、「コンピューター」と「コンピュータ」。長音符号をつけるかつけないかを議論することで、エンジニアは焼酎3杯は飲めます。

つい最近まで、エンジニアはいかなる場合にも長音符号をつけないという人が圧倒的でした。なぜなら、JIS規格にそう定められているからです。JIS規格では「その言葉が3音以上の場合には、語尾に長音符をつけない」「長音符号を書き表す音、はねる音及びつまる音は、それぞれ1音と認め、拗音は1音と認めない」となっています。ですから、サーバ、コンピュータが正しいわけです。

何しろ、エンジニアとってのバイブルとも言えるJIS規格で定められていたのですから、以前のエンジニアに「コンピューター」などという表記を見せたら、冷たい目で見下されるだけでした。

ところが21世紀になって事態は大きく動きます。あのJIS規格が2005年に改定され、長音符号はつけてもつけなくても誤りではないなどという曖昧なことを言い始めます。さらに、2008年になると、あのマイクロソフトが世間に合わせて「コンピューター」「プリンター」という表記を採用、これに追従するIT系企業が増えていきました。長音符号省く派＝エンジニアでも、長音符号をつける派のことを、大衆迎合の日和見修正主義者と罵れなくなったのです。

ということで、今、エンジニアの中には、つける派とつけない派が混在していて、日頃は会社のルールに従っていますが、プライベートな時間になると自分の主張が噴き出してくるというわけです。

[【求人特集】「インフラエンジニアの転職」](https://mynavi-agent.jp/it/infrastructureengineer/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

世の中では、長音符号をつけるつけないは「統一されているんだったら、どっちでもいいんじゃないの？」という人が大半だと思いますが、エンジニアにとってはそうはいきません。夜な夜なIT企業本社近くの居酒屋では長音符号について激しい議論が戦わされているのです。エンジニアがその話を始めたら、早めにお酒のピッチをあげて、先に酔ってしまったほうがいいかもしれません。

【エンジニアあるある】「サーバー」か「サーバ」かの話で、焼酎3杯は飲める。

[【関連記事】「IT・エンジニアの職種図鑑」](https://mynavi-agent.jp/it/jobindex/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)
[【関連記事】「SEの転職先は異業種もあり？転職先のパターンや企業選びのポイント」](https://mynavi-agent.jp/knowledge/it/763.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)
[【求人特集】「システムエンジニアの転職」](https://mynavi-agent.jp/it/systemengineer/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

エンジニアの天敵は、全角スペースと全角の「1」です。世の中に、なぜ全角と半角という忌まわしいものがあるのかと、エンジニアのほぼ全員が腹を立てています。

コーディングは基本的に英数字、つまり半角文字を使いますが、コメント欄には日本語、つまり全角文字を使うこともあります。この全角と半角の切り替えをいい加減にしておくと、コード部分に全角スペースや全角の「1」が紛れこんでしまいます。これが目では見つけづらい！コンパイルエラーにさんざん悩まされた挙句、実は全角文字が原因だったなどという経験を何度もしているのがエンジニアです。

もちろん、エンジニアですから、文字コードの歴史はよく知っていて、黎明期に全角と半角という仕組みが、コンピューターの発展に寄与したことも理解しています。でも、今はユニコードの時代。いい加減、全角、半角やめてくれないですかね。と、ECサイトに住所を入力するときに「郵便番号は半角でお願いします。番地は全角でお願いします」の注意書きを見ながら、腹を立てているのがエンジニアであり、そういうウェブを構築しているのもエンジニアです。

エンジニアがECサイトの画面に向かって怒鳴っていても、気にしないでください。半角、全角問題で、いちばん被害を受けているのがエンジニアなのです。

【エンジニアあるある】全角スペースと全角の「1」を異常なまでに敵視している。

エンジニアにとって勤続年数が長いことはいいことだろうか、悪いことだろうか。エンジニアにとってはあまりに長いのも考えものだ。なぜなら、エンジニアの成長は、ポジションが変わることによってもたらされるからだ。一生のうち、稼働時間はほぼ40年。3年ごとに成長しても13回しかステップアップするチャンスはないのだ。意外に人生は短い。

## 「平均勤続年数が長い企業はホワイト」と言えなくなっているのが現実

あなたは今の会社に入社して何年目だろうか。

よく平均勤続年数が長い企業はホワイト、短い企業はブラックと言われるが、今は一概にそうも言えなくなってきている。平均勤続年数が長い企業というのは、経営が安定をして、給与も年々上がっていく傾向にある。社員にとってはやめる理由が見当たらない、あるいはやめたくない企業だ。しかし、裏を返せば、社内の序列も安定していて、出世しづらい、責任ある仕事をなかなか任せてもらえない、個人としての成長はしづらいという欠点があるということにもなる。

一方、平均勤続年数が短い企業というのは、経営がいい意味でも悪い意味でも安定していないことも多い。業績が悪化する不安定さは困るが、急成長をしているため新人を大量雇用しているということかもしれない。そういう不安定さであれば、チャンスが豊富にあり、個人としての成長もしやすい。

特にIT企業のエンジニアは、入社時に契約した職能給ベースの給与のままで、自然に昇給していくことは少ない。給与をあげるには、社内で別の仕事を請け負うか、管理職になるか、事業を成功させてボーナスをもらうか、転職するかしかない。そのため、海外のITエンジニアの平均勤続年数は3年以下というのが一般的だ。

[【関連記事】「SEの転職先は異業種もあり？転職先のパターンや企業選びのポイント」](https://mynavi-agent.jp/knowledge/it/763.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv08)

平均勤続年数を読むときに、気をつけておかなければならないポイントが2つある。それは「平均勤続年数が3年」という場合、「入社した人が平均して3年で退社している」ということではないということだ。

平均勤続年数とは、現在勤務している社員の入社日から数えた勤続年数の平均なので、事業を大幅拡大して、大量雇用した直後は平均勤続年数はかなり短くなる。極端な話、創業2年のベンチャー企業であったら、平均勤続年数は当然2年以下になる。

また、ホールディングス制をとっている企業の場合も、平均勤続年数が短めになる可能性がある。なぜなら、グループ企業内で社員が移動するからだ。そのグループには勤続30年だとしても、現社では勤続年数3年などということがありえる。

## テスラ、ウーバーなどの新しい企業の平均勤続年数は2年前後と極端に短い

では、そのようなことを踏まえて、各企業の平均勤続年数はどのくらいなのだろうか。ビジネスインサイダーがシリコンバレーのIT企業の平均勤続年数を報じている（[https://www.businessinsider.com/average-employee-tenure-retention-at-top-tech-companies-2018-4](https://www.businessinsider.com/average-employee-tenure-retention-at-top-tech-companies-2018-4)）。これによると、シスコシステムズやオラクルのようなBtoB企業は勤続年数が長めだが、ユニコーン企業、ベンチャーなど新興のIT企業は短めになる。ほとんどが3年以下だ。特にテスラ、ウーバーなどの新しい企業は2年前後と極端に短い。

最近成長が著しい中国のIT企業は、平均勤続年数がより短い（[https://www.jiemian.com/article/2128045.html](https://www.jiemian.com/article/2128045.html)）。中国電信など携帯電話キャリアでも4年から5年程度であり、日本でも高給を支給することで話題になった携帯電話メーカー、ファーウェイでも4年。中国IT企業の中で時価総額の大きい御三家「アリババ」「テンセント」「百度」は3年以下。さらに、ライドシェアの滴滴出行は1.4年、シェア自転車のofo、Mobikeに至っては1年以下と極端に短い。

## 日本のIT企業の平均勤続年数、極端に長い企業と米国や中国並みに短い企業に二極化

では、日本のIT企業はどうなのだろうか。平均勤続年数は、有価証券報告書に記載されているので、主だった企業のデータは、ウェブから簡単に閲覧することができる。

大学生のIT企業就職人気ランキングの上位にくる企業のうち、有価証券報告書をウェブで公開している企業の情報をまとめた。そのため、外資系子会社などは含まれていない。また、有価証券報告書は公開されているものの中から最新のものを参考にしたので、報告時期は2017年から2018年にかけて企業ごとにバラツキがある。

一見してわかるのは、日本のIT企業は平均勤続年数が極端に長い企業と、米国や中国のIT企業並みに短い企業に二極分化されていることだ。勤続年数が長いIT企業はBtoB系であり、短い企業はBtoC系であることもよくわかる。平均年齢もBtoB系は高く、BtoC系は低い傾向がある。

いずれにしても、日本のIT企業の平均勤続年数は長い。米国のBtoB企業であるシスコシステムズやオラクルが7年程度であるに対して、同じドメインのビジネスを展開する日本のIT企業は15年以上にもなる。

変化の激しいBtoC系のIT企業でもぐるなび、サイバーエージェントなど５年を超える企業があり、これも米国や中国と比べると倍ぐらいの感覚になる。

## エンジニアにとっての勤続年数、あまりに長いのも考えもの!?

エンジニアにとって勤続年数が長いことはいいことだろうか、悪いことだろうか。エンジニアにとってはあまりに長いのも考えものだ。なぜなら、エンジニアの成長は、ポジションが変わることによってもたらされるからだ。例えば、あるシステムの開発に従事をして、そのシステム一筋何十年となったら、その人の成長には限界がある。一定期間そのシステム開発をおこなったら、次は別のシステム開発に関わることで、未知の知識に触れ、大きな成長が期待できる。その意味で、海外のITエンジニアたちが3年程度で転職を考え始めるというのは、自分を最も効率よく成長させるひとつのメソッドになっているかもしれない。

もちろん、転職といっても他社に移籍することだけが「転職」ではない。自社の中で別の部署に異動する、別のチームに異動する、チーム内で別のポジションに就くというのも「成長のための転職」のうちだ。

3年を1単位として、1年目は新しい知識を学び、スキルを身につける。2年目はアウトプットする。3年目は、アウトプットをしつつ次の「転職」を考える。もちろん、チーム内、社内、社外の「転職」選択肢を同じ平面上で選択をすればよく、結果的に社外には転職せず、同じ会社に何年も居続けることになるということでもかまわない。

3年でポジションを変えることを意識して仕事をする。それが最も効率よく自分を成長させることができるのではないだろうか。一生のうち、稼働時間はほぼ40年。3年ごとに成長しても13回しかステップアップするチャンスはないのだ。意外に人生は短い。

今の会社に長くいすぎ!? 世界の主要IT企業エンジニアの平均勤続年数は3年以下

お役立ち記事