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

[【関連記事】「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年以下というのが一般的だ。

[【求人特集】「システムエンジニアの転職」](https://mynavi-agent.jp/it/systemengineer/?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)

平均勤続年数を読むときに、気をつけておかなければならないポイントが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年以下

「プログラミングなんか必要ない」と言わず、遊び感覚でSwift Playgroundsをやっておくだけで、仕事ががぜんやりやすくなる。「コードを学ぼう」は、詰めてやれば2日程度、楽しみながらのんびりやっても1週間もあれば終わる程度のボリューム。その程度の時間が取れないわけはない。「数学や情報は学生の時から苦手で」という人もいるかもしれないが、この程度のコーディングの学習は、英語の学習で言えば、初歩の旅行会話を暗記する程度のレベル。もし、本当にそれすらできないとおっしゃるのであれば、5年後、あなたの仕事はなくなっているかもしれない。

## 小学生でも遊びながら、Swiftプログラミングを学ぶことができる

すでにエンジニアになっている人、これからエンジニアになろうと考えている人は、絶対にiPadを買っておかなければならない。絶対だ。なぜなら、iPad版Swift Playgroundsという素晴らしいチュートリアルアプリが利用できるからだ。

ユニークなキャラクターを迷路を走らせるゲームを楽しみながら、プログラミング言語Swiftの基礎を学ぶことができる。

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

~~ 美しいグラフィックで表示される迷路を解いていくプログラムを実際に書きながらSwiftプログラミングを学んでいく。 ~~

すでに仕事や学校の課題でプログラミングをしている人にとっては、基本すぎていまさら感のある内容かもしれないが、インスタンスあたりは意外にきちんと理解せずに使ってしまっている人も多い。そういう人にとっては、もう一度基礎を確認するいい機会となる。

このSwift Playgroundsが素晴らしいのは、迷路というフィールドがあらかじめ用意されている点だ。そのため、コーディングはキャラクターの動きだけでいい。前に進むはmoveForward()であり、3歩前に進むはmoveForward(step: 3)であり、左に曲がるはturnLeft()でいい。キャラクターの位置座標を計算して指定するなどという面倒なコーディングは一切必要ない。

このため、小学生でも遊びながら、Swiftプログラミングを学ぶことができる。実際、小学生、中学生向けのプログラミング教材として使われている例は多く、個人的にお父さんが自分の子どもにiPadを買い与えて遊ばせている例もよく聞く。「小学生ではwhileなどの単語の意味がわからないのではないか？」と心配する方もいるかもしれないが、それは小学生のスポンジのような吸収力を見くびっているかもしれない。whileの意味も読み方もわからないけど、小学生は「同じことを繰り返してくれる呪文」としてすぐに覚えてしまう。Swift Playgroundsには、キーボードから関数名や変数名を入力すると、自動補完してくれる機能があるので、まったく心配する必要ない。

~~ キーボードからコマンドを入力すると、キーワードが自動補完される。これを利用すれば、英語のスペルに不慣れな小学生でもコーディングができる。 ~~

## 非ITの人もぜひSwift Playgroundsを、できないなら5年後あなたの仕事はなくなっている!?

また、非ITの人にもぜひSwift Playgroundsをやってみてほしいと思う。今どき、ITシステムをまったく使っていない企業というのはほとんど存在しない。非ITの職種であっても、IT系のデザイナーやエンジニアと接点を持ちながら仕事をするのが当たり前になっている。このSwift Playgroundsをやっておくだけで、IT系の人がどこで困って、どんな苦労をしているのかがある程度わかってくる。もっと言えば、IT系の人と仕事をするときにイニシアティブを握ることができるようになる。コーディングがまったくわからないと、デザイナーやエンジニアから「そんなことは実現不可能です」「この修正には最低でも1ヶ月の作業時間が必要です」という真っ赤な嘘をつかれても、反論ができない。少しでもコーディングの経験があれば、そういうデザイナーやエンジニアのウソに対しても、勘が働くようになる。デザイナーやエンジニアという人たちも、勘のいい人が多いので、開発がわかっている人に対してはいい加減なことを言わなくなる。

「プログラミングなんか必要ない」と言わず、遊び感覚でSwift Playgroundsをやっておくだけで、仕事ががぜんやりやすくなる。

「コードを学ぼう」は、詰めてやれば2日程度、楽しみながらのんびりやっても1週間もあれば終わる程度のボリューム。その程度の時間が取れないわけはない。

~~ 「コードを学ぼう」の２つで学べるSwiftの文法。「コードを学ぼう1」では、プログラミングの基本的な命令を覚えていくが、「コードを学ぼう2」では、インスタンスや配列といった中級レベルのことまで学べるようになっている。 ~~

~~ 最初にやるべきなのは「コードを学ぼう」だが、その他ドローンやロボットのプログラミングも用意されている。メーカーがテンプレートを提供しているので、実際のドローンをiPadから制御することもできるようになる。 ~~

「数学や情報は学生の時から苦手で」という人もいるかもしれないが、この程度のコーディングの学習は、英語の学習で言えば、初歩の旅行会話を暗記する程度のレベル。もし、本当にそれすらできないとおっしゃるのであれば、5年後、あなたの仕事はなくなっているかもしれない。

## SwiftはiOSアプリを開発する際にメインで使われる言語、他の言語も習得しやすい

Swift Playgroundsのもうひとつの素晴らしい点は、学習できるプログラミング言語がSwiftであるという点だ。Swiftは、iOSアプリを開発する際にメインで使われる言語で、Swiftを習得しておけば、他の言語も習得しやすい。

さらに、手軽に本格的な開発環境が手に入れられ、豊富な学習教材が存在している。本格的に開発をしたいというのであれば、MacのXcode（無料）を手に入れれば、その中にMac版のSwift Playgroundsが含まれている。こちらには、迷路のようなお遊び要素はないかわりに、本格的に開発を進めビルドすることで、iOSアプリを完成させることが可能だ。

また、学習教材はネットに山ほど存在している。YouTubeで「Swift Learning」で検索をしてみれば、無数のビデオ教材が見つかる。多くの教材は英語ベースだが、Swift Playgroundの画面が表示され、プログラムコードを見ながら学習するというパターンが多いので、英語がわからなくてもじゅうぶん学習していくことができる。

時間さえあれば、プログラミング初心者がiPad版Swift Playgroundsでまず遊び、一通り覚えたところで、Mac版Swift PlaygroundsとYouTubeの無料教材を使えば、アプリ開発ができるところまで独学することが可能だ。

## まずはiPadを購入し、SwiftPlaygroundsを触ってみるべき

デザイナー、エンジニアはiPad版で、チュートリアルの表現方法を学ぶべし。文系の人はiPad版でコーディングとはなにかという感覚をつかむべし。学生はiPad版で遊んでから、Mac版で本格的にSwiftのコーディングを学ぶべし。

いずれにしても、まずはiPadを購入し、SwiftPlaygroundsを触ってみるべきだ。iPadは37800円からのいちばん低価格のものでまったく問題ない。

iPad版Swift Playgroundsは、プログラミング初心者からエンジニアまで必須のアプリ。このアプリのためだけにiPadを買っても損はない！

一般的なパンケーキアルゴリズムは堅実だがどこか無駄のある緩さを感じるが、ゲイツのアルゴリズムは一手も無駄にしない鋭さを感じる。ゲイツが発見したアルゴリズムをなぞることで、ゲイツの思考に触れることができ、ゲイツのエンジニアとしての大きさを実感できるはずだ。数学の知識がある方は、ゲイツの論文そのものを読んでみるもの楽しいと思う。

## 数学者、遺伝学者、コンピューター技術者、、、どれになるか迷っていたビル・ゲイツ

ビル・ゲイツは、高校時代からコンピューターに夢中になり、すでにソフトウェアを受託開発するというビジネスを始めている。しかし、そのままマイクロソフトを起業するつもりだったわけではなく、ハーバード大学に進んでからは、数学者になるか遺伝学者になるかコンピューター技術者になるか決めかねていた。

まずは数学者になることを目指して、「数学55」というハーバードの中でも最高レベルの数学の講義を受講した。しかし、ここでゲイツは人生で始めての挫折を味わったのではないかと言われている。ゲイツは数学の成績も図抜けて優秀だったが、それでは単なる優等生にすぎない。ハーバードには数学の天才としか呼びようがない学生がごろごろいたのだ。努力ではどうにもならないものをゲイツは感じたのかもしれない。

## ビル・ゲイツが書いた唯一の学術論文『パンケーキ論文』

ゲイツが数学からコンピューターに転換をする時期に、ゲイツは唯一の学術論文を書いている。これが数学の論文なのだが、実にコンピューター的なのだ。

この論文は、パンケーキ問題に関するもの。パンケーキ問題とは、1975年にヤコブ・グッドマンが提案した数学問題。「あるシェフが複数のパンケーキを焼くが、腕が悪いために、大きさがまちまちになる。しかも、それをひとつに積み重ねてしまう。これを上から小さいもの順に並べ替えたいが、n枚のパンケーキを並べ替えるのに、何回操作を行えばいいか？」というものだ。

ここで注意したいのが、並べ替えるのが縦に積まれたパンケーキだということ。並んでいるパンケーキの一箇所にヘラを入れて、そこから上をひっくり返すという操作しかできない。

~~ 積まれたパンケーキのどこからにヘラを差し込んで、そこから上をひっくり返すことしかできない。これで小さいものから順に並べ替えるというのがパンケーキ問題だ。 ~~

ゲイツは授業でこの問題を知った時「簡単じゃないか！」とバカにしたように声をあげたという。その気持ちはわかる。プログラムの基礎課程で学ぶソートアルゴリズムのうちの選択ソートの簡単な応用問題に見えるからだ。

選択ソートは、ランダムに並んだ数字の中から最小値を見つけ、これを先頭の数字と入れ替えるというもの。これで先頭に最小値がくるので、次は2番目以降の中から最小値を見つけ、2番目の数値と入れ替えるというように、先頭からソートをしていくやり方だ。パンケーキ問題も、選択ソートを応用して、最も大きなパンケーキを見つけて、最も下と入れ替える。次は下から2番目より上で最も大きなパンケーキを見つけて、下から2番目と入れ替える、とやっていけば、選択ソートの応用でできそうな気がする。

しかし、事情はそう簡単ではない。なぜなら、パンケーキではヘラをどこかに入れて、そこから上をひっくり返すことしかできず、選択ソートのように「入れ替える」ということができないのだ。

## ゲイツが数日間夢中になって見つけた最適なアルゴリズムとは!?

簡単だと思ってバカにした問題が、意外に難しかった。ゲイツはそれから数日間、このパンケーキ問題に夢中になり、ようやく最適なアルゴリズムを見つけ、指導教官のクリストス・パパディミトリューに報告をした。そして、指導教官とゲイツは、この論文を仕上げ、「離散数学」1979年9月号に掲載された。これがビル・ゲイツ唯一の学術論文として、現在でもデジタルアーカイブなどで読むことができる。

ゲイツの着想はどんなところにあったのだろうか。

その前に、パンケーキ問題の一般的なアルゴリズムを紹介しておこう。パンケーキが（2,3,4,7,6,1,5)の順で並んでいるものとする。これを(1,2,3,4,5,6,7）に並べ替えるのが目的だ。

一般的なパンケーキアルゴリズムでは、末尾から大きいものを並べていくようにする。しかし、いきなり最大値を末尾に移動させることはできないので、最大値の下でひっくり返して、いったん先頭に出し、それから全体をひっくり返すという2段構えで行う。この例では、最大値の7の下にヘラを入れて、その上の（2,3,4,7）の部分をひっくり返す。

そして、全体をひっくり返す。

これで末尾に最大値の7がきたので、上6枚から最大値6を探して、そこから上の（5,1,6)をひっくり返す。

末尾の7は定位置なので触らず、その上にヘラを入れて（6,1,5,2,3,4）をひっくり返す。

これで、末尾の6と7が決まったので、その上から最大値を探し…ということを繰り返していく。

とても堅実な方法だが、1つのパンケーキの位置を決めるのに2手かかる。並び順の関係でうまく手数が少なく済む場合もあるが、最悪のケースでは2n回かかることになる。堅実だが、どうもバカ正直で面白くない。もっと手数の少ないアルゴリズムがあるのではないか。ゲイツが悩んだのはここだった。

## 「連続ブロック」を利用すると、より洗練されたアルゴリズムになることを発見

そして、ゲイツは「連続ブロック」を利用すると、より洗練されたアルゴリズムになることを発見した。連続ブロックとは[2,3,4]などのように、数字が連続している並びのことだ。

初期状態（2,3,4,7,6,1,5)では、（[2,3,4]7,6,1,5)のように[2,3,4]の部分が連続ブロックになる。また、[6,7,1]は連続ブロックと考え、[4,3,2]は逆順になるので連続ブロックとは考えない。

ゲイツは、この連続ブロックに注目をして、連続ブロックの先頭がさらに連続ブロックを伸ばすようにひっくり返していくと、ステップ数の少ないアルゴリズムになることを発見した。

では、[2,3,4]という連続ブロックがあり、この連続ブロックの先頭の2が、さらに連続ブロックを伸ばすために1の隣にくればいい。つまり、6と1の間にヘラを入れて、（2,3,4,7,6)をひっくり返せば、連続ブロック先頭の2が1の隣にきて、連続ブロックが伸びていくことになる。

[2,3,4]の連続ブロックは反転されたので、連続ブロックではなくなってしまったが、1と隣接して、[1,2,3,4]という潜伏する連続ブロックとなった。一方で、新たに[6,7]という連続ブロックが生まれている。この先頭の6がさらに連続ブロックを伸ばすには5の隣にくればいい。そのためには、1と5の間にヘラを入れて、（6,7,4,3,2,1）をひっくり返す。

最小値である1と最大値である7は隣り合っていると考え、連続ブロックの先頭の1が7と隣り合うようにするため、4と7の間にヘラを入れ、（1,2,3,4)をひっくり返す。

ここで連続ブロックがひとつもなくなった。連続ブロックがない場合は、基本のアルゴリズムを適用する。最大値でひっくり返し、それから全体をひっくり返す。

## 「プログラマーというものは、楽をするためであれば、どんな苦労もいとわないものだ」

いかがだろうか。時間のある時に、メモ帳に適当な数字を並べて、一般的なパンケーキアルゴリズムとゲイツのアルゴリズムを手段計算して、比べてみていただきたい。あるいはプログラムを組んでみてもいいだろうし、数学の力がある人はn枚のパンケーキを並べる時のパンケーキアルゴリズムとゲイツアルゴリズムの最小手数の一般解を求めても面白い。

一般的なパンケーキアルゴリズムは堅実だがどこか無駄のある緩さを感じるが、ゲイツのアルゴリズムは一手も無駄にしない鋭さを感じる。ゲイツは後年、「プログラマーというものは、楽をするためであれば、どんな苦労もいとわないものだ」と語っている。

ゲイツが発見したアルゴリズムをなぞることで、ゲイツの思考に触れることができ、ゲイツのエンジニアとしての大きさを実感できるはずだ。数学の知識がある方は、[※ゲイツの論文そのもの](https://people.eecs.berkeley.edu/~christos/papers/Bounds%20For%20Sorting%20By%20Prefix%20Reversal.pdf)を読んでみるもの楽しいと思う。

~~（※）ビル・ゲイツ唯一の学術論文。学会誌に掲載される頃にはゲイツはすでに起業していたため、肩書きは「マイクロソフト」となっている。ただし、住所は、後のシアトル市ではなく、創業地のニューメキシコ州アルバカーキになっている。~~

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

ビル・ゲイツの思考に触れられるゲイツ唯一の学術論文「パンケーキ論文」とは!?

macOSで利用できるパソコンはMacだけです。細部までこだわったMacのデザインは魅力的ですが、一般的なWindows PCに比べて、同じようなスペックでもMacは価格が高いのが玉にキズ。だから、もっと低価格なPCやもっと高スペックなPCでmacOSを使いたいという声が昔から根強く上がっていました。そんなmacOSの解放を求める声に対するテリー・ランバート氏のQuoraでの解説が神回答であると話題になっています。

## 根強い「どうしてmacOSはMac限定?」

Macは、macOSがUNIXベースのため、多くの開発者に使われています。仕事用のパソコンも、OSを選べたり、BYOが認められるようになって、スマートフォンがiPhoneだからMacを選ぶという人が増えています。しかし、Windows PCに比べてMacは価格が高いのが玉にキズ。スペックが同程度の機種を比べると、Windows PCならMacの半分ぐらいの価格の製品が見つかります。細部までこだわったMacのデザインは魅力的ですが、価格差ほどの価値の差はあるのでしょうか？

そんなユーザーのもやもやとした気持ちに対して、Appleで長くソフトウエアエンジニアとして活躍していたテリー・ランバート氏のQuora（Q&Aサイト）での解説が神回答であると話題になっています。同氏はAppleでmac OS Xのカーネル開発を担当、その後はGoogleでもChrome OSの開発に携わりました。

Quoraの質問は「どうしてAppleブランド以外でOS X（macOS）が動作するPCがないの?」でした。MacはIntelのCPUを採用しているので、乱暴な言い方をすると多くのWindows PCやLinux PCと中身は同じx86/ x64プラットフォームです。だから、macOSを使いたくて使っている人の中には、もっと価格の安いPCや高スペックなPCにmacOSをインストールして使ってみたいと考えている人が少なくありません。

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

~~昨年末に登場したMacBook Pro（右）、MacBook Air（左）よりコンパクトになりましたが、Proモデルとして、もっと高スペックを追求してほしいという声も。~~

## 同じスペックでも異なるPCとMacのパーツ

それができない理由を一言で説明すると「Appleが認めていないから」。もう少し長いバージョンだと「ハードウエアをMacに限定して、Macに最適化したOSとしてmacOSを開発することで、パソコンとして最高の使用体験を提供できるから」、これが最もよく見る回答ですね。でも、「ハードウエアに最適化」と言われても、具体的にどういうことなのか、一般的にはイメージできません。他のPCだってハードウエアに最適化しているはずです。「それならMacは何が違うのか？」という点についてランバート氏は分かりやすく説明していますので、かいつまんで紹介しましょう。AppleがMacにこだわるのは、一般的なスペックの性能ではなく、Appleが求める性能を発揮させるためです。

今日のMacBookシリーズではRAMのユーザーを交換できません。Appleは電力管理を向上させるためにRAMの動作周波数や電圧も変動させており、その動作を効果的に実行できる水準のRAMに限定するためです。CPUも同様に、動作周波数を上げるバーストモードや安定した電圧コントロールなどで微細なコントロールを求めています。そのため、スペック上は他のブランドのPCと同じIntelのCoreプロセッサを採用していても、Intelの基準ではなく、より高いAppleの基準を満たす部品を求め、Intelへの支払いにはその分のプレミアを乗せているそうです。

macOSではKEXT（Kernel EXTension）というモジュールを通じてカーネルの機能を拡張し、デバイスドライバなどを、カーネルと分離しながら安全に、そして容易に追加/削除できます。KEXTには「The Stepper」と呼ばれる電力や周波数などを微細にコントロールするモジュールが組み込まれています。厳選したパーツをKEXTで微細にコントロールすることで、パワフルな性能と効率的な動作が実現します。効率的な動作によって放熱が抑えられ、よりスリムで軽量なデザインも可能になります。

以前はデスクトップは据え置き型のデザインでしたが、今日では全てのMacでモバイルノートに見られる電力効率優先が徹底されています。たとえば、量販されているPCのマザーボードは信号の遅延を抑えるようにデザインされていますが、Appleは電力効率と放熱を優先してロジックボードを設計しています。ボードだけ見ると冗長で奇妙なデザインに思えますが、それが筐体と組み合わさった時に、小さなヒートシンクや最小限の冷却ファンで効率的に熱を逃がせる設計が完成します。

~~MacBook Proの内部、エアフローに沿って効率的に放熱されるように全てがデザインされています。~~

## マージンを確保するMac、低価格競争に向かうPC

厳選したハードウエア、その性能や機能を存分に引き出すOSとソフトウエア。最初から最終的な製品をイメージした統合的な設計によって生み出される相乗効果がMacならではの使用体験です。対照的に、Windowsは存在するあらゆるPC向けパーツをサポートする必要があるので平均的になってしまいます。汎用パーツと平均的なWindowsの組み合わせはスペック通りの性能に納まり、性能で差別化できないPCメーカーは「低価格」で競争し始めます。より安くを求めすぎると、粗悪なパーツや低品質なパーツが含まれる可能性が高まるという悪循環です。

Macのマージンは35％程度と言われています。それほどあれば、2011年にタイの水害でHDDの価格が上昇したようなパーツ価格の変動があっても吸収できます。また、コストのかかる新しい素材や機能の採用にも挑戦可能です。一方、低価格競争にあるWindows PCのマージンは3〜6％程度。コストの上昇によって利益が吹き飛んでしまいかねません。

もちろん、Appleのモデルがいつでも正しいというわけではありません。ムーアの法則が有効で、CPUの性能の向上がそのままPCの価値になっていた頃は、汎用パーツを組み合わせて低価格を実現したWindows PCがMacを圧倒していました。

ただ、ムーアの法則の進行が鈍って、差別化のポイントがCPU性能から総体的な使用体験に移ったことで風向きが変わり始めました。PCの主流はデスクトップからモバイルノートに、そして従来型のPCからポストPCへと移るに従って、Macの価格の価値を認める人が増えています。見方を変えると、限られた電力の中でPC並みの性能が求められるスマートフォンをAppleが編み出せたのも、統合的なデザインを是とするAppleであってこそ。Macで培ってきたモデルは、iPhoneの強みにもなっています。

「Macはなぜ高い」に元Appleエンジニアが神回答

2017年5月、Unityの一大イベントであるUniteが開催されました。
Unity2017に関する魅力的な機能も色々発表され、期待に胸が膨らんじゃいます。

そういえば、今回のUniteには会社の後輩がボランティアスタッフとして参加しました。
「大変だったけどとっても楽しかった！」とのことですので、予定が確保できそうな方はぜひ次回のUniteに参加してみてください！（筆者も参加してみたい・・・！）

さてさて、今回はシミュレーションゲームのアルゴリズムを作ってみましょう。（賀好 昭仁）

## シミュレーションゲームというジャンルは広すぎました

改めて調べてみると、シミュレーションゲームには

・シミュレーションRPG
・恋愛シミュレーション
・フライトシミュレータ

など多種多様なゲームが含まれております。

ということで、今回はシミュレーションゲームの中でも特に歴史のある「マス目を使ったターン制戦略シミュレーションゲーム」のアルゴリズムを作ってみます。

※「マス目を使ったターン制戦略シミュレーションゲーム」ですとちょっと長いので、以降は「戦略シミュレーション」と称させていただきます。

＜余談＞
最近、ファイアーエムブレムヒーローズ（FEH）で久々にシミュレーションRPGをプレイしました。
筆者はこれまでシミュレーションRPGをいろいろプレイしてきましたが、すべて1マップに1時間前後かかるガッツリ系のゲームばかりでした。
FEHもその類かと思いきや、1マップ数分で終わるというスマホゲームらしいライトさ。
本格シミュレーションPRGでも工夫次第でここまでライトに作れるものなのか、と驚いたものです。（そして、ライトでも面白い・・・！）

## 戦略シミュレーションの要素を考えてみる

ゲームを作っていくにあたって、まずは戦略シミュレーションの要素を考えてみましょう。

戦略と名がつく通り、自軍のユニットを使って敵軍のユニットと戦うゲームですので、

・自軍ユニット
・敵軍ユニット

そして、戦うための舞台も必要です。
障害物の無い平原、うっそうとした森、山岳地帯など、さまざまなマップが登場すると楽しそうですね。

戦略シミュレーションに最低限必要な要素はこれくらいでしょうか。要素はとっても少ないですが、ユニットの種類・マップの種類・自軍と敵軍の戦力バランスや戦況・敵AIなどに変化をつければ、要素は少なくてもさまざまな楽しみ方ができます。

そういえば、将棋やチェスなどはユニットの種類が固定でマップも1種類しかありません。
それでも打ち手次第でさまざまな局面が楽しめることを考えますと、戦略シミュレーションの根本的な部分の奥深さが垣間見えますね。

## ユニットの動ける範囲を考えてみる

いざ戦略シミュレーションを作ろうとしたとき、まず頭を悩ませるのは「ユニットが動ける範囲をどう計算するか」だと思います。

将棋やチェスでは各コマの移動のルールがシンプルなため、動ける範囲を求めるのは簡単です。
ただ、戦略シミュレーションではユニットの移動力に応じて1回の行動で複数マス動けたり、同じ1マスでも平原と森で移動コストが変わったりと、さまざまな要素が絡んできます。

これらを解決するために、移動可能範囲を計算するためのアルゴリズムを実装する必要があります。

移動可能範囲は、簡単なアルゴリズムで求めることができます。まずはマップの各マス目の移動コストを列挙します。
移動不可のマス目は、どのユニットも移動不可能になるような大きな値を入れておけばOKです。
下の図では、移動コスト1の茶色のマスは平原、移動コスト2の緑色のマスは森、移動コスト9の灰色のマスは岩山（進入不可）と考えてください。

続いて、移動力の計算を行います。まずは動かしたいユニットが居るマスの座標に、そのユニットの移動力分の数値を入れておきます。下図は移動力4を持つユニットがマップ中央にいた場合の例です。

続いて、ユニットの居る上下左右のマスに、対象マスの移動コスト分を引いた値を入れます。
※対象マスに既に値が入っていた場合、上書きせずそのままにします。

下図では、ユニットの居る赤いマスを基準に、その四方のマス（黄色いマス）に値を入れています。
右側のマスは森（移動コスト2）なので、ここだけ数値が2になっています。

続いて、移動力の値を1減らしたマス、つまり値が「3」のマスを基準に同じ計算を行います。

あとは値を1ずつ減らしていき、0になるまで同じ処理を繰り返せば、移動可能範囲を導き出すことができます。
ちなみに、値がマイナスになったマスは移動力が足りず移動できないマスですので、最終的な移動可能範囲は下図の青いマスとなります。

特殊なマス（後述）がない限り、移動力や地系が変わっても同じ処理で移動範囲を求めることができます。

シミュレーションPRGや戦略シミュレーション全般で大活躍しそうなアルゴリズムですね！

ユニットを移動させる際にユニットが移動先にパッとワープしたり、移動不可マスを通って移動したりすると、プレイヤーは違和感を感じてしまいます。
違和感を感じさせないようにするためには、目的地までの移動経路を算出する必要があります。

移動経路は、先ほどの移動範囲の計算と逆の手順で導き出すことが可能です。

下図は赤いマスが移動先だった場合の例です。
まずは移動先マスの値（残りの移動力）に、そのマスの移動コストを足します。
四方にあるマスを見ると、上記の値に合致するマスが必ず1つ以上存在します。（図中の黄色いマス）
ユニットはこの黄色いマスを通って移動したことになります。
続いて黄色いマスを基点に同じ処理を繰り返すことで、徐々に移動経路が明らかになっていきます。

~~図 6 経路算出（移動先から2歩手前まで）~~

もし黄色いマスが複数存在する場合は「どちらからでも来られる」ことになります。

あとはユニットが元居た位置までこれを繰り返せば、移動経路が明らかになります。下図では、中央にある「4」のマスから「←↓←←」の経路と「↓←←←」の経路の2パターンが割り出せました。

## アルゴリズムの注意点と改良方法

今回は不要ですが、もしもマップに下記のようなマスが存在する場合は前述のアルゴリズムをそのまま使うことができません。

・移動力を消費しないマス
・通ると移動力が回復するマス

このようなマスに対応する場合、下記のような処理を加える必要があります。

・該当マスから周りのマスに対し、移動力の計算＆書き込みが終わったかどうかのフラグを設ける
・数字（残りの移動力）が埋まっているマスに対して、より大きい値が入れられる場合は値を上書き、上記フラグをクリアする処理
・ひと通りの計算が終わったのち、マス目上の最大移動力をベースに再度同じ計算を行う（この際、上記フラグが立っているマスは計算対象から除外）、全てのマスにフラグが立つまで何周も続ける

また、移動力回復マスにワープするマスを組み合わせると無限ループに陥る可能性もありますので、このようなマスを実装する場合は注意しましょう。

今回のサンプルプロジェクトはこちら。

https://github.com/akako/gamealgorithm-war-simulation/releases/tag/for_algorithm10

Unityで作ろう！ゲームアルゴリズム10 1

ユニットを選択して移動可能マスをハイライト、マスを選択して経路計算＋移動するところまでを作りました。
まだまだゲームとは言えませんが、これだけでも戦略シミュレーションの香りがプンプン漂ってきますね。

今回のアルゴリズムは、マス目を使った戦略シミュレーションであれば必ず活躍します。
HEX（6角形）のマス目でも同じアルゴリズムが適用できますので、ぜひ試してみてください！

【Unityで作ろう！ゲームアルゴリズム】シミュレーションゲームのアルゴリズムを作ってみる

お役立ち記事