膨大なIPアドレスを管理できるIPv6とは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

ネットワークでは

「IPアドレス」

...が使用されています。

IPアドレスとは
コンピュータの住所とも言えるものですが、

このIPアドレスに変化が起きているのです。

今回は新しいIPアドレスである

「IPv6」

についてお話ししましょう。

IPアドレスが不足している?

IPアドレスは

"192.168.25.100"

というように、
0~255までの数字を
組み合わせて割り振られています。

ホームページなどのアドレスは

http://www.linuxacademy.ne.jp/

というように
文字でアドレスが指定されていますが、

実際には...

"203.174.70.235"

というIPアドレスで管理されているのです。

このIPアドレスの仕組みを

「IPv4(Internet Protocol version 4)」

と言い、
インターネット通信の規約である
プロトコルのバージョン4を意味します。

そしてこのIPv4には

「IPアドレスが不足している」

と言う問題がおこっているのです。

現在の世界人口は
70億人を超えていますが、

IPv4で割り当てることができる
IPアドレスの数は、およそ43億個です。

世界中の人に1つのIPアドレスを
割り当てることすらできなくなっています。

そして
インターネットサービスの普及などにより
IPアドレスの需要が増加しているため、

IPv4でのIPアドレス管理は
すでに限界に達しているのです。

IPアドレス不足を解消するIPv6

そこで登場したのが

「IPv6(Internet Protocol version 6)」

と呼ばれるプロトコルです。

インターネットプロトコルの
バージョンが4から6にアップしたのですが、
仕様が大幅に変更されています。

まず、IPアドレスの表現が...

"192.168.25.100"

といった4つのブロック表記から、

"2015:c900:0000:0bc1:0000:4321:1256:0000"

といった、
「:」(コロン)で分けられる
8つのブロック表記に変わりました。

これにより、
設定できるIPアドレスの組み合わせが
以下のように飛躍的に増えているのです。

[IPv4]
4,294,967,296個
(2の32乗 約43億)

[IPv6]
340,282,366,920,938,463,463,374,607,431,768,211,456個
(2の128乗 約340潤(かん))

ものすごい量に増えていますね。

IPv4で管理できるIPアドレスを
バケツ1杯の砂の数だとすると...

IPv6で管理できるIPアドレスは
太陽一個分の体積の砂になると言われています。

IPv6の登場によって
IPv4のアドレス不足問題が解消されるのです。

アドレス数だけではないIPv6の特徴とは?

IPv6にはIPアドレスの数以外にも
さまざまな特徴があります。

IPv4とIPv6の
特徴を比較した表を見てみましょう。

IPv4v6

■IPアドレス数

IPアドレス数は既にお話しした通り、
圧倒的にIPv6の方が多いです。

世界中の機器に割りあてることも
可能だと言われています。

■NAT

IPv4では
アドレス不足を解消するために

「NAT(Network Address Translater)」

という技術が使用されています。

これはIPアドレスを
一時的に書き換える技術なのですが、

IPv6ではアドレス数が多いので
NATが不要になります。

■オートコンフィグレーション

オートコンフィグレーションとは
IPアドレスを自動で設定する方法です。

IPv4ではIPアドレスの設定を
手動で行う必要がありましたが、

IPv6では
オートコンフィグレーションにより
自動的に設定されます。

■セキュリティ

IPSecとは簡単に言えば
通信を暗号化する手法です。

IPv4では
オプションで実装できますが、

IPv6では標準で実装されているので
通信内容を読み取られる危険が少なくなります。

■処理速度

送受信されるデータの
共通情報などが見直しされたことで、

ネットワーク機器の処理負担が減り、
処理速度が早くなりました。

これからのエンジニアに必須のノウハウ

IPアドレス不足問題の
救世主のようなIPv6ですが、

実際には
通信機器のIPv6対応不足や、

IPv4との互換性の問題などにより、
十分に普及しているとは言えません。

そして...

「IPv6のノウハウを知るエンジニアが少ない」

...というのも普及が遅れる理由のひとつです。

これからのネットワーク社会は
IPv6の技術が必要になってきます。

それはIPアドレス不足の問題からも
明らかなことです。

しばらくは、
IPv4とIPv6が共存する時代が続くでしょうが、
いずれはIPv6に変わる時代が来ます。

IPv6についてのノウハウは、
これからのエンジニアに必須だと言えるのです。

リスキルテクノロジー
松田

PS

IPv4からIPv6まで
ネットワークに関するノウハウを学ぶなら、
ネットワークの専門スクールリスキルテクノロジー

プロジェクトの成否を左右する工数見積りとは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

完成している商品は
価格が設定されていますが、

システムは受注してから作ることが多く、
価格がいくらになるのか決まっていません。

しかし、それでは売りようがないので、
あらかじめ見積りしてから価格を決めます。

今日はシステム開発における
見積りについてお話ししましょう。

見積りはプロジェクトの成否を左右する

システム開発において
開発費用の見積りはとても重要です。

見積り金額が多すぎると
受注できませんし、

見積り金額が少なすぎると
受注できたとしても大変な目にあいます。

割とよくあることなのですが。。

そのため、
見積りに求められるのは正確性です。

500万円で作れると思ったものが
実際には1,000万円かかるとなると、
プロジェクトは大赤字になります。

見積りは、
「プロジェクトの成否を左右する」
...と言われのもまま理解ができます。

パッケージシステムは
価格が設定されているものが多いですが、

カスタマイズする場合には、
やはり見積りが必要になります。

社内開発でも
どれくらいの費用や期間がかかるかを
見積もったうえで開発しなければいけません。

どのような形態の開発でも
見積りという作業は必ず発生するのです。

工数の考え方と代表的な工数見積りの手法

見積りでは、

「工数」

...という単位が使用されます。

工数とは作業量を表す考え方のことで、

1人日 = 1人が1日(約8時間)で作業する量

...という意味です。

たとえば
最終的に100人/日かかる案件の場合、

100×開発単価(人件費など)+管理費+交通費など

...のようにして開発費用を算出します。

システム開発における工数見積りには
いくつかの手法があります。

代表的なものをご紹介しましょう。

■トップダウン見積り法

システム全体をまず見積り、
そこから工程別に工数を細分化してゆく方法です。

見積もる人の経験によって
正確性が大きく左右される方法ですので、
あまり経験のないエンジニアには向いていません。

■係数モデル見積り法

過去の事例などから
見積りのモデルを設定し...

そのモデルに対して
開発規模などを考慮した係数を加え、
数学的に工数を算出する方法です。

採用される見積りモデルによって、
正確性が左右されるという特徴があります。

■ボトムアップ見積り法

各工程で作成する
設計書などの成果物や作業内容を細かく分けて、
それぞれの要素に必要な工数を積み上げる方法です。

それぞれの作業は、

WBS(Work Breakdown Structure)

...という手法で細かく分けられ、
作業ごとにどれくらい工数が必要かを見るので、
比較的正確な見積りが作成できます。

この他にも
さまざまな手法がありますが、
実際には複数の手法を組み合わせて
見積りが行われるケースがほとんどです。

それでも尚外れることも多く、
いわゆる炎上というのは見積もりの甘さが
原因だったりします。

リスクを考えることも大切

見積りするにあたっては、

「リスクを考える」

...ということも大切です。

最初は簡単だと考えていたが、
実は難易度が高いということがわかり、
開発工数が増えてしまうこともあります。

このような
不測の事態に対応できるように、
リスクを考えたうえで見積もる必要があります。

あまりリスクばかり気にすると
正確性に欠けてしまうので問題ですが(笑)

難易度が高い機能の開発などは
リスクを考慮した上で見積もるのが良いでしょう。

また、
次から次へと追加仕様が増えてしまい、
予定していた工数では作れなくなることもあります。

このような追加仕様対策としては、

「大幅な仕様追加が行われる場合は再見積りする」

...という条件を付ける企業が多いです。

見積りは作る前のことですので、
依頼する側もされる側も予測できないことがあります。

予測できないことも
発生するということを踏まえた上で、
できる限り正確な見積り作りが必要なのです。

できるかぎり正確な見積りで
安全なプロジェクトを

システム開発を行う企業には
独自の見積り方法を持つ企業もあります。

複数の見積り法を組み合わせて
企業独自の視点を設けて見積りを行いますが、

それでも不確定要素などで
プロジェクトが赤字になる場合もあるのです。

見積りは航海準備に似ています。

太平洋を船で横断するのに
どれくらいの燃料、食料が必要なのかというように、

必要なリソースを予測して、
安全な航海ができるようにしなければいけません。

プロジェクトを安全に進めるには
正確な見積りが必要不可欠であることを
しっかりと覚えておいてください。

リスキルテクノロジー
松田

PS

あなたが憧れのエンジニアになったら
どんな作業にどれくらい時間がかかるのかを
覚えておくようにしてください。

最初の内は時間がかかりますが、
経験を積むにつれてスピードアップしてゆきますよね。

その作業時間の違いから
未経験者が開発に必要な工数と、
経験者が開発に必要な工数の目安がわかるのです。

あなたがプロジェクトを
管理する立場になったとき...

未経験者と経験者の
作業工数の目安がわかっていれば、
プロジェクトの計画を立てやすくなります。

java研修の資料請求はこちらから

システムリリース時のトラブルにはどう対処すればいい?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

システムの開発中やリリース後に
何らかのトラブルが起きることはあります。

特にリリース後であれば
本来あってはいけないことですが...

まぁ、率直にいいまして、
割と発生します。

自社のWebアプリケーションだと特にですね。
心理的にテストが甘くなるから。

トラブルが発生した場合は、
早めに問題を修正するのが重要なポイントです。

トラブルの原因を調査して解決することを
トラブルシューティングと言います。

今回はトラブルシューティング方法について
お伝えしましょう。

トラブルの原因は必ずどこかにある

システムは思った通りに
動いてくれないことがよくありますが、

作った通りにはきちんと動いてくれるものです。

作った通りに動くということは
トラブルの原因は必ずどこかにあるのです。

プログラムの例で言えば
バグの種類は大まかに分けて2種類あります。

ひとつは
エラーが発生してシステムが動かなくなるケースで、

特定の処理ができなくなったり
最悪の場合はシステム全体が止まってしまいます。

そしてもうひとつは
エラーは発生しないけど
システムが誤った結果を出してしまうケースですが、

実はこちらの方がトラブルとしては怖いのです。

例えば消費税の計算で
8%で計算しないといけないところを
5%で計算してしまっている場合、
請求書の金額やデータベースの登録内容が間違ってしまいます。

このような場合はエラーが出ないので、
バグに気付くのが遅くなってしまうのです。

プログラムでもサーバー構築でも、
テストをしっかりと行うことが大切ですが…

それでも起きてしまったトラブルは、
どうやって解決してゆくのでしょうか?

トラブルシューティングってどうやるの?

プログラムの場合は、
エラーが発生している場合は
エラーメッセージやログファイルを見ます。

これらには、どこでどのような原因で
エラーが発生したのかが詳しく記録されており、

その情報をもとに
エラーの原因を解析するのが基本です。

しかし、

エラーの発生場所と
エラーの原因を生み出している場所が
必ず同じという訳ではありません。

エラーが発生するもっと前の処理で
エラーの原因を作ってしまっている場合もあります。

その時に行うのが
「ステップ実行」という開発ツールの機能で、

プログラムを1行ずつ実行させて、
データの内容や処理結果を確認しながら実行できます。

エラーが発生しない種類のバグだと、
ステップ実行で確認しないと原因がつかめません。

サーバートラブルの場合も、
基本的にはログファイルの解析から始まります。

例えば...

Webサーバーがうまく動かない!
メールを送っても送信されていない!

...などといった場合、
Webやメールサービスのログファイルを確認します。

プログラムの場合と同じで、
ログファイルにエラー内容が書かれていますので
そこから原因を調査してゆくのが基本です。

ただし、サーバーの場合は
物理的なトラブルが原因となる場合もあります。

ハードディスクが破損したとか、
電力不足でサーバーダウンするなど、
物理的な原因も含めて調査しなければいけません。

原因不明のトラブルの場合はどうする?

プログラムや設定ファイルを見ても、

特に問題がない...

一見すると原因不明の
トラブルが発生する場合もあります。

これがしんどい。
テストをロジカルに組み立てつつ、
問題を絞り込んで行きます。

下記のようなところまで
いったとしましょう。

AさんのPCだと問題なく動くのですが、
BさんのPCだと計算結果が違うといったケース。

そのようなケースでは
ブラウザのバージョンが、
正しいものを使っているかどうか調べる。

バージョンが違っていると
動きが変わってくるケースがありえます。

ウェブアプリケーションでなければ、
OSやミドルウェア系を調べる。

他にも調査ポイントはありますが、
それでも原因不明の場合は
ベンダーにサポートを依頼して原因を究明しましょう。
(できるなら 笑)

オープンソースはそこら辺大変ですが、
コストの変わりにその部分の大変さを引き受けているので、
頑張るしかありません。

しかし、ベンダーにサポートを依頼した場合でも、
自分が探す場合でも、なかなか原因がわからないバグは、
時間がかかります。

特にリリースしている
システムのトラブルであった場合は、
早急にトラブルを解決しなければいけません。

原因がわかるまでに時間がかかる場合は、
一時的なプログラムの修正や、
代わりのサーバーを用意するなどの対策が必要です。

エンジニアの価値を高める
トラブルシューティングスキル

バグやエラーの対処方法は
エンジニアが習得しておきたいスキルのひとつ。

トラブルシューティングのスキルが
高いのと低いのでは、
エンジニアとしての価値が格段に変わってきます。

さまざまなトラブルは
開発者の作業やユーザーの業務を途中で止めてしまう、

つまり、

発生するだけで損失を与えてしまっているのです。

損失を最小限に抑え、
トラブルをできるだけ早く解決して
通常の業務を進めてもらう...

それが生産性の向上に繋がるのです。

リスキルテクノロジー
松田

PS

どんな機械でも
使っているとあちこち痛んできます。

システムでもそれは同じこと。

トラブルがない方がもちろんいいのですが、
万一の時は素早く対処できる方がいいですし、
ユーザーの信頼も失わずに済みます。

本当のエンジニアリング力が付く リスキルテクノロジー

多くの開発案件を手掛けて視野を広めるSIerとは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

IT企業の業種紹介。
前回はパッケージベンダーについてご紹介しました。

今回ご紹介するのはSIer。

SIerはITバブルと言われた
1990年~2000年頃に多数の企業が立ち上げられ、
今でも多くのシステム開発において活躍している職種です。

SIerとは一体何か?
3種類に分類されるSIerの特徴

SIerと言うのは造語で、
System Integration(SI)に
「~する人」を意味する「~er」を付けたもの。

System Integrationとは
システム構築にあたってユーザー業務の分析を行い、
システムによる課題解決から運用保守まで請け負う業務です。

ユーザー業務の分析から
運用保守まで請け負うというと
トータル的な業務を一括して請け負うように見えますが...

実際にはユーザーと直接取引しているSIerが
下請けの中小SIerに業務を発注して開発するケースがほとんど。

大小問わず多くのSIerが集まって
1つの開発案件に対応するケースがほとんどです。

SIerはさらに以下の3種類に分類されます。

(1)メーカー系

PCなどを開発している
ハードウェアメーカーから
分離独立するなどして設立されたSIer。

親会社となるメーカーの
ハードウェアと組み合わせたソリューションが強みですが...

親会社製ではないハードウェアを
ユーザーに提案しにくいといった不自由さもあります。

(2)ユーザー系

銀行、商社、流通などといった企業の
情報システム部門が独立して設立されたSIerです。

親会社のシステム開発が主な業務ですが
親会社以外の企業からも積極的に案件を受注する傾向があります。

親会社と同じ業種のシステム開発案件が強みで、
該当業種の業務に詳しいSEやコンサルタントが多いのが特徴です。

(3)独立系

特定のメーカーや親会社を持たないSIer。

メーカー系などの様に
親会社からの制約がない分、
SIerとして自由な発想による提案がしやすいのも特徴です。

ベンチャー企業に多く、
他のSIerから業務を受注して開発するケースがほとんどですが、
中堅クラスのユーザー系SIerになると直接ユーザーと取引することもあります。

SIerの業務形態とは?
契約形態によって業務場所が異なることも

SIerの開発業務は
自社内で行われるとは限りません。

開発場所がユーザー企業内といった場合は
その場所に席を借りて開発業務に携わりますし、
自社にプログラムソースなどを持ち帰って開発するケースもあります。

開発場所が自社でない場合は「常駐案件」、
自社である場合は「自社内案件」などと言いますが、
開発場所はSIerの案件契約形態によって変わります。

契約形態は大きく分けて以下の3種類です。

(a)請負契約

ユーザーや1次請け企業などから
特定の業務(製造のみ、テストのみ)または
全ての業務を請け負って開発対応を行う契約。

請負契約の場合は
自社内案件として自社での開発も可能ですが
最近はセキュリティや情報漏えいなどの問題により、
請負契約であっても常駐して開発するケースも増えています。

(b)準委託契約(SES契約)

常駐案件で主に採用される契約形態。

技術者の月あたりの稼働時間を...

「160時間~180時間の間で、180時間を超過したら別途追加料金を支払う」

...などといった契約を結びます。

つまり最低160時間働く必要があり、
180時間以内であれば定額料金となる仕組み。

180時間を超えないと
残業時間が発生しないという訳ではありません。

残業時間はあくまで自分が所属する企業の規則によります。

(c)特定労働者派遣

これも常駐案件で採用される形態ですが、
IT業界における特定労働者派遣は廃止になる可能性も。

いろいろ問題点があり、
ここでは詳しく触れませんが
2014年度の国会では派遣法改正の施行が廃案になったので、
IT業界の特定労働者派遣が廃止となるなら2015年度以降になります。

契約形態別の開発場所をまとめると、
請負案件の場合は自社に持ち帰って開発となる場合もあり、
準委託契約(SES契約)や特定労働者派遣では客先での開発になるのです。

多重な請負構造
1次請けや2次請け以降のSI業務の特徴とは?

ユーザーと直接関わる1次請け案件の場合
ユーザーの業務分析など、上流工程から開発に携われます。

そして実際の開発は
自社開発要員で行う場合もありますし、
別のSIerに発注して開発してもらうケースも。

メーカー系やユーザー系SIerには
1次請け案件が多く、自社の新入社員を鍛える為に
ベテラン技術者+新人技術者+別のSIerという開発チームが多いです。

1次請けの場合は
システムリリース後の運用保守も行いますが、
別のSIerが案件開発に多く関わりノウハウが多い場合は...

1次請けSIerは
ユーザーの窓口として運用保守を受け付け、
実際の作業は2次受けの別SIerが行うケースも。

そして、
2次請け以降のSIerの業務範囲は
1次請けSIerから受注した範囲内に限られます。

例えば...

・製造~単体テストまで
・詳細設計から結合テストまで
・運用、保守業務のみ
・製造でも、特定のサブシステムの製造~単体テストまで

...といったように、フェーズや機能単位で契約されることが多いです。

ただし、
業務やシステムに精通している技術者であれば、
1次請け企業の技術者と共にユーザー折衝するなど
上流工程から開発業務に携わることができるケースもあるのです。

また、
ユーザーから気に入られた場合は
何年もユーザー企業内で開発業務を行う技術者も。

実際にSIerに入社した技術者が
派遣先企業で何十年も開発を行っているケースも。

「自分がどこの社員かわからない」

...と、冗談交じりに話していたのを覚えています。

その技術者は、派遣先企業には
なくてはならない存在になっているのです。

柔軟性や積極性は必須!
SIerは多くの開発案件を手掛けて視野を広める

SIerの魅力は
様々な業界のシステムを手掛ける機会が多いこと。

様々なユーザーのニーズに応える為には
技術者として幅広い技術やノウハウが必要です。

見知らぬ業種の開発案件でも
積極的に業務知識を得て対応する柔軟性と...

経験のない言語を使用する案件でも
自発的に技術を習得して開発を行う積極的が必要となります。

そしてSIerはユーザーだけでなく
他社SIerと協力してシステム開発を行う機会が多いため...

自社の開発手法だけにとらわれない
様々な企業の開発手法を経験することができます。

長年SIerを経験してゆけば...

「あの案件の開発手法はよかった」

「リスクマネジメントはあの案件を参考にしよう」

「あの失敗案件と同じ問題点は発生させないように」

...と言うように、技術者として開発手法の視野が広まります。

SIerになるにあたって
ひとつ注意しておきたいのは...

「何年経っても特定のフェーズしか経験できない」

...という点です。

たとえば製造~単体テストフェーズばかり
短期間で何社も案件を繰り返していった場合、
技術者としてのモチベーションアップが難しくなります。

上流工程を経験したいのに
実際にはプログラミングだけといったケースですね。

そういった場合は、
上流工程に関連する資格試験の勉強をするなどして
自分が所属する企業や、常駐先の企業にアピールしたりして
技術者としてのモチベーションを下げない工夫をするようにしてください。

SIerは技術者という面もありますが
ユーザーや他SIerと接する機会が多いことから
あなたの姿勢そのものが営業活動になります。

実際に仕事ぶりが認められたSIerに
別の開発案件を発注するといった事も多く...

あなたがその案件の
上流工程から携わる可能性も大いにあるのです。

多くの案件を手掛け、技術者としての視野を常に広く持っていたい!

そんな方には、SIerをオススメします。

リスキルテクノロジー
松田

PS

ITエンジニアとして活躍するならこの研修がおすすめです。

Linuxカーネルにはどんな役割があるの?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

「カーネル(Kernel)」

Linuxを学んでいると
必ず一度は耳にする言葉です。

カーネルとは和訳すると

「核」

という意味で、
文字通りLinuxの中心的役割を持っています。

今回はカーネルの基本について
お話ししましょう。

カーネルの役割は「橋渡し」

コンピューターには
ディスプレイやマウスなど
さまざまな機器が接続されています。

そしてコンピューターには
メールソフトやブラウザーなど、
さまざまなアプリケーションが動作しています。

アプリケーションの動作には
メモリーやハードディスクなど、
数多くの装置を動かす必要がありますが…

複数のアプリケーションが
メモリーやハードディスクなどの制御を奪い合うと
収拾がつかなくなってしまいますよね。

そこで活躍するのがカーネルです。

カーネルの役割は
アプリケーションとハードウェアが
上手に連携するための、

「橋渡し」

…をすることが役目です。

Linuxを起動した時に
カーネルはコンピューターの状態を初期化し、

アプリケーションが実行できる
環境を整えてくれます。

初期化した後は、
アプリケーションの動作にあわせて

コンピューター内部の
連携をコントロールしているのです。

カーネルを呼び出すシステムコールとは?

アプリケーションが
ハードディスクなどの
接続されている機器にアクセスするには...

「システムコール」

と呼ばれる方法が使われています。

システムコールとは
アプリケーションがカーネルに仕事を依頼することで、

コンピューターに接続されている
さまざまな機器を使えるようになるのです。

 

たとえば
あるアプリケーションがファイルを開いて、
ファイル内容を読み込むとしましょう。

アプリケーションからは
ハードディスクにあるファイルに
直接アクセスすることができません。

そこでアプリケーションは...

「ファイルを読み込みたい」

...とカーネルにシステムコールを行います。

すると、
カーネルはそのアプリケーションに対して

「ファイルを開いてもいいですよ」

...と、ファイルを開く権限を与えます。

このように、
カーネルから権限が与えられて初めて
アプリケーションはファイルを読み込むことができるのです。

2つの権限
特権モードと非特権モード

先ほどの例で

「カーネルがアプリケーションに権限を与える」

という内容がありましたが、
これについてもう少しお話ししましょう。

Linuxでは
カーネルとアプリケーションを正しく動作させるために、

「特権モード」と「非特権モード」

...という2つの権限を設定しています。

カーネルは特権モードの権限を持ち、
あらゆるハードウェアにアクセスすることができます。

対して、
アプリケーションは
非特権モードで動作しており、

ハードウェアに対して
直接アクセスすることができません。

カーネルが管理している領域に
アプリケーションが自由にアクセスすると、
深刻なシステムエラーが発生する可能性が高くなるためです。

アプリケーションが
ハードウェアにアクセスするためには、

システムコールをして、
カーネルに特権モードへと切り替えてもらい、
ハードウェアにアクセスすることができるのです。

カーネルを知ることでLinuxの理解度が深まる

LinuxはPCだけでなく
家電製品やスマートフォンなど
さまざまな環境で使用されています。

それぞれによって
接続されるハードウェアは違いますが、

カーネルをカスタマイズすることで
あらゆる環境でLinuxを動作させることができるのです。

また、
カーネルのパラメータを変更して
Linuxの性能をカスタマイズすることもできます。

開発エンジニアを目指すにしても、
インフラエンジニアを目指すにしても、

カーネルの仕組みを知ることで、
Linux学習の理解度がより深くなります。

今の段階では概要で構いませんので、
カーネルのイメージを掴んでおいてください。

リスキルテクノロジー
松田

PS

カーネルの
設定変更やコンパイルの方法などの
理解はサーバーエンジニアにとって必須です。

サーバーエンジニアになるための研修 リスキルテクノロジー

エンジニアに営業スキルは必要?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

「営業力」

エンジニアとは
関係のなさそうなこのスキルですが、

実は
エンジニアにとって
重要な意味を持っているのです。

どうしてエンジニアに
営業スキルが必要なのでしょうか?

ひとつの仕事が新しい仕事を生む

先日、
ある老夫婦の話を聞きました。

その老夫婦は
銀行で定期預金をしていたのですが、

銀行の営業マンの話を
楽しそうに話すのが印象的でした。

最初は自分たちの
定期預金だけだったのですが、

あるとき、
子供が他の銀行で借りている
住宅ローンの返済計画が適切がどうか調べ、

減額できる可能性を指摘したところ
住宅ローンの減額に成功したそうです。

老夫婦は
営業マンの対応の良さを気に入って、

自分の子供たちに
営業マンの銀行のローンなどを紹介して
多くの契約にまで至ったそうです。

自分たちのことを
考えて行動してくれている。

この姿勢が
老夫婦が営業マンを気に入った理由でした。

この営業マンの例では
ユーザーに対する対応の仕方によって

小さな定期預金だけの取引から、
ローンなどの他の契約につながっています。

仕事は単発ではなく
アプローチの方法によっては、

「ひとつの仕事が新しい仕事を生む」

...という特徴があるのです。

エンジニアにも営業力は必要

ひとつの仕事から
別の仕事に繋がるケースは
営業系の職種だけの話ではありません。

例えば、
SIerはユーザー企業での
システム開発業務が多いですが、

中小SIerの場合は
短期間の案件が非常に多いのが現状です。

その案件が終わると
次の案件があるとも限りませんので

次の案件につながるように
ユーザーに対して営業するケースもあります。

また、
開発案件を持ち帰って
自社内で開発を行おうとするSIerは多いです。

売上額が大きいのはもちろんですが...

自社内であれば
開発要員の計画を立てやすいですし

新人教育の一環として
新人を開発に参加させることもできます。

しかし、
その為に必要なのは
ユーザーとの信頼関係です。

信頼関係がなければ
案件を持ち帰らせて開発させてくれません。

そのためには
最高のパフォーマンスで開発にのぞみ、

銀行マンの例のように
顧客のためになる対応を心がけることが大切です。

営業は目に見えない効果も生む

営業力が必要なのは
SIerだけではありません。

自社で開発をしているエンジニアにも
必要なスキルだといえます。

例えば
パッケージベンダーなどですが、

いくら技術力だけを高めて
素晴らしいシステムを作ったとしても、

対応に問題があると
それだけの関係で終わってしまいます。

よくあるのは
アフターフォローでのトラブルです。

システムを納品して
清算を済ませてしまったら

対応の仕方が変わったという例は、
今でもかなり多くのユーザーから聞きます。

それきりの関係で終わらせないように、
信頼関係を深めるアフターフォローが必要です。

社内システム開発でも同じです。

社内向けの開発だから
営業スキルは必要ないのでは?

と思うかも知れませんが、

「売上」

という数値に表れないだけで、

社内での信頼関係や
部署間の連携を良くするなど

目に見えない効果はたくさんあります。

社内外を問わず
システムを利用する人はすべてユーザーなのです。

ユーザーを大切なパートナーと考えよう

基本的にビジネスは
ユーザーがいないと成立しないものです。

ユーザーがいるということは、
必ずコミュニケーションが発生します。

どれだけ優れた技術があっても
コミュニケーションの質が低ければ

「今後も付き合ってゆきたいエンジニア」

...とは思ってくれません。

「営業」

と考えてしまうから
敬遠してしまうエンジニアもいるのも確かです。

まずは、ユーザーのことを...

「大切なパートナー」

と考えることから始めましょう。

あなたが開発したシステムを利用する人は
あなたの大切なパートナーです。

そのパートナーのために...

・どれだけ質の良い対応ができるか?
・相手の目線で考えることができるか?
・どうすれば一緒に課題を解決できるか?

...ということを心がけて接してみましょう。

たったそれだけで
あなたとパートナーとの信頼関係は

今よりも大きく育まれることでしょう。

リスキルテクノロジー
松田

PS

パートナーの喜びは嬉しいものです。

当校にとってのパートナーは
これからエンジニアになろうとするあなたです。

あなたの一歩を
万全のサポート体制で応援します。

プログラマーになるならリスキルテクノロジー

Linuxエンジニアの未来

From: リスキルテクノロジー 松田航
新宿本校にて、、、

エンジニアとしてやってゆきたいなら
Linuxを学べばいい。

2000年代に入ると
IT業界ではそんな言葉が聞こえ始めました。

そしてそれは
今でも変わらない事実です。

今なお世界のIT業界で必要とされる
Linuxエンジニアの求人事情についてお伝えしましょう。

身近なOSとなったLinux
しかし技術者は毎年不足している

Linuxは誕生から
20年以上たっているOSで、

今では
家電製品やスマートフォンなど、
私たちの身近なところで利用されています。

私たちは知らない間に
Linuxテクノロジーを使っているのです。

Linuxは多くの企業が
導入を進めている技術であり、
Linux技術者の需要も高まっています。

IT業界では毎年毎年、

「Linux技術者の需要が高い!」

...と言われています。

これは裏を返せば、毎年毎年、

「Linux技術者が圧倒的に不足している!」

...ということになるのです。

Linux技術者の需要は海外でも高い

Linux技術者の需要の高さは
日本だけでなく海外でも同じです。

アメリカの雑誌「U.S.News」が
独自調査によって発表したランキングに、

「2015年有力な職業 BEST100」

...があります。

usnews

出典:U.S.News

これは数ある職業の中から

・10年間の成長性
・給与水準
・職業としての今後の展望

...など7つの項目に対して
有力な職業をランキングしたものですが、

ソフトウェアエンジニアが
第3位にランクインされています。

このランクインで注目したいのが、

「LinuxなどのOSに特化したエンジニア」

...という点です。

単なるソフトウェアエンジニアではなく、
Linuxスキルを持つエンジニアが有力とされています。

Linux技術者の確保が企業的な課題

求人状況については、
アメリカの求人情報サイト「Dice.com」が行った
Linux技術者に対する求人調査結果があります。

demand

出典:Dice.com

 

これによると
企業の採用担当者の77%は、

「Linux技術者の雇用は最優先事項」

...と回答しています。

前年の調査では70%であったことから
毎年その需要が高まっているのが見られますね。

そしてLinux技術者の86%は、

「Linuxの知識が就転職の機会を与えてくれた」

...と答えています。

Linux技術者のほとんどが、
Linuxを習得することによって
新しいチャンスを手にしているのですね。

しかし、ここでも日本と同じ問題があります。

採用担当者の90%は、

「Linux技術者を見つけるのは難しい」

...と答えています。

企業はLinux技術者を
切実に欲しがっているのですが、

正しい専門知識を持つ技術者が
不足しているのが現状です。

ITエンジニアを目指すなら今がチャンス!

アメリカだけでなく、
日本でも同じ問題が起きています。

過去2年間で
Linuxを導入した企業は75%以上にのぼり、
Linux技術者の採用を強化する企業が増えています。

ところがアメリカと同じく
肝心のLinux技術者の数が不足しているのです。

ITエンジニアを目指す方にとって、
ここにチャンスがあります。

企業が求めているのは
正しい専門知識を持つ技術者です。

Linuxにおいて
正しい専門知識のバロメーターとなる資格に、

「Linux技術者認定資格(LPIC)」

...があります。

世界中で50万人が受験しており
Linuxスキルを保障するグローバルスタンダートです。

このLPICを取得することで
就転職に圧倒的に有利になることは間違いありません。

もちろん
サーバーエンジニアを目指す方や
ソフトウェアエンジニアを目指す方にも、
十分役立つ資格です。

ネットワークエンジニアを目指すならば、
LPICとあわせて...

「CCNA(Cisco Certified Network Associate)」

...を取得することをおすすめします。

ネットワークエンジニアとしての
キャリアが確実に広がることでしょう。

Linux技術者が求められる今、
Linuxスキルを習得することはチャンスに繋がります。

エンジニアを目指しているのであれば、
Linuxの習得をオススメします。

リスキルテクノロジー
松田

PS

Linux教育のパイオニアスクール
Linux講座はこちらから

アルゴリズムの基本2:変数と配列

From: リスキルテクノロジー 松田航
新宿本校にて、、、

ほとんどのプログラムで
必ず使われるアルゴリズムがあります。

それは「変数と配列」です。

基本中の基本なので、
理解している人は読み飛ばしましょう。

そもそも、変数と配列って何?

…というところから話してゆきましょう。

変数は中学生の時に習っています

変数というのは
みなさん中学生の数学で習っています。

x + 2 = 10

そう、方程式ですね。

この「x」と言うのが
アルゴリズムで言うところの
変数にあたります。

上の方程式の答えは、

x = 8

変数xという箱に
8という値が入っていると考えると
わかりやすいでしょう。

方程式では数字しか使いませんので、
変数xという箱の中身は必ず数字になります。

しかし、実際のプログラムでは数字だけでなく、
いろいろなデータを扱わなければいけません。

いろいろなデータの形式を「データ型」と呼び、
それぞれのデータ型にあった変数(箱)があります。

(1)整数型:整数を扱う箱(0, 100, -100など)
(2)実数型:実数を扱う箱(1.23, 0.987, -123.456など)
(3)文字列型:文字列を扱う箱(”ABC”, “あいう”, “リナックス”など)
(4)論理型:真、偽を扱う箱(TRUE, FALSE)

このような
データ型を使い分けた変数を使って、
プログラムは動いているのです。

ちょっとややこしいので、
ここまでの話をまとめておきましょう。

【まとめ】
・変数はデータを入れる箱のこと。
・変数には整数や文字列など、さまざまな「データ型」がある。

 

ここではこれだけ覚えておいてください。

配列は整列された変数の箱

それではもうひとつの
配列について説明してゆきましょう。

変数の場合は、
1つの変数につき1つのデータしか入りません。

x = 8

この場合はxという箱に
既に8という値が入っている状態です。

xという箱に...

x = 10

...として別の値を入れてしまうと、
8という値は消えてなくなってしまいます。

1つの値しか扱えない変数だけだと
大量のデータを扱うプログラムの場合、
何かと不便ですね。

もっと多くのデータを扱う必要がある時に
登場するのが配列です。

変数は値を入れる箱でしたが
配列は変数の箱を整理して並べた状態をイメージしてください。

配列A [4]の
カッコの中の4という数字は...

配列Aには
変数の箱が4個ありますよという意味です。

そして配列には
それぞれ箱番号が割り振られており、
例えば...

0番の箱 = 100
1番の箱 = 200
2番の箱 = 300
3番の箱 = 400

...というように、
1つの配列に複数のデータを入れることができます。

この図の場合は
箱を横に並べた配列ですが、
縦横に箱を並べた配列もあります。

難しくなってくるので
ここでは説明しませんが、
配列には変数の箱の並べ方によって
いろんなデータの整理方法があると考えてください。

配列についてもまとめておきましょう。

【まとめ】
・配列は変数という箱を整理して並べたもの。
・配列の箱は番号で管理されている。
・配列には横整列、縦横整列などの整理方法がある。

 

変数や配列は効率の良いプログラミングに必要

変数や配列は
プログラムを効率よく書くのに必要なものです。

例えば3つの変数を計算し、
最後にそれぞれの変数を足して
画面に表示する以下のようなプログラムがあるとします。

1: 変数A = 100 + 10
2: 変数B = 100 + 20
3: 変数C = 100 + 30
4: 画面表示(変数A + 変数B + 変数C)

ここで、それぞれの変数に足している
100という値が間違っていることが発覚しました。

200という値が正しい値だった!という場合、
100と書かれている場所すべてを修正しなければなりません。

この場合は1行目~3行目に修正が必要ですね。

しかし、100という数字を
最初から変数として持っていれば
修正箇所は1箇所で済みます。

1: 変数X = 100
2: 変数A = 変数X + 10
3: 変数B = 変数X + 20
4: 変数C = 変数X + 30
5: 画面表示(変数A + 変数B + 変数C)

変数Xがある場合は...

1: 変数X = 200

...と1行目だけを修正すれば良い訳です。

そして配列ですが、
例えば100件のデータを
全て変数で管理するとどうなるでしょうか?

1: 変数A-1
2: 変数A-2
3: 変数A-3

100: 変数A-100

というように、
変数を100個も用意しなければいけません。

ですが配列にすれば…

1: 配列A[100]

...このように1行で済みます。

変数や配列は
プログラムの余分な記述を減らしてくれます。

ほかにも、
後からプログラム修正が必要になった時、
プログラムを解析しやすくする効果もあるのです。

誰が見てもわかりやすいプログラミングを!

変数と配列について
初歩的な知識をお伝えしましたが...

これらは
プログラムを書くにあたって
大切なことです。

データはできるだけ
変数や配列などを使って
プログラムを書くという事を覚えておいてください。

変数や配列を上手に使わずに
プログラムを書いた場合、
後から修正する時に内容がわかりにくくなる場合もあります。

プログラムを作る人は
1人だけかも知れません。

しかし、

そのプログラムを修正するのは
作った本人であるとは限らないのです。

変数や配列を使って
どのプログラマーが見てもわかりやすく、
修正しやすいプログラムを作ること。

これが開発の効率化や、
修正後のバグ発生防止にもつながるのです。

リスキルテクノロジー
松田

PS

あるプログラマーから聞いた話ですが...

変数を使わずに
数値や文字をプログラムに直接書くプログラマーは
今でもけっこう多いそうです。

プログラマーを目指すなら、
後々のメンテナンスを考えて、
誰が読んでもわかるプログラムを心がけましょう。

Javaプログラミングを勉強するならリスキルテクノロジー

未経験からの育成制度も充実
IT講師に興味はありませんか?

リスキルテクノロジーでIT講師の積極募集を開始! 経験・未経験問わずご応募可能。育成制度で講師スキル向上も目指せます

IT講師に応募する