CentOSのインストール方法

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

このブログを
読んでくださっている方は、

Linuxに大きな関心を
持っている方が多いことでしょう。

「Linuxを実際に触ってみたい!」

そう思うこともあるかと思います。

では、
実際にLinuxに触ってみましょう。

下記でより細かいことを解説もしてみましたので、こちらもご参考ください。

かなり詳しく!CentOS7のインストール方法

Linux環境の構築方法

今回はLinux環境の
構築方法をお教えします。

パソコンを1台だけ
用意しておいてください。

Linuxに興味はあって
パソコンも持っているけど、
他のOSが入ってしまっている...

という方でも大丈夫です。

ほとんどのOSには
無償の仮想化ソフトがあります。

仮想化というのは
1台のパソコンの中に、

別のパソコンがあるかのように
新しい環境を作ることを言います。

詳しくは
ネットで検索してみてください。

また、このブログでも近いうちに
ご紹介していきます。

もちろん
仮想化ではなく、

他のOSから
Linuxに乗り換えるのもアリですね。

まぁ、なかなか難しいかと思いますが、
楽しいですよ。

CentOSをインストールしよう

CentOSとは
Linuxディストリビューションのひとつで

Red Hat Enterprise Linux(RHEL)と
互換性のあるディストリビューションです。

RHELのクローンOSとして有名で、
安定性の高さで評判が高く、

Webサーバーの
およそ20%でCentOSが使われており、

当スクールの授業でも
このCentOSを使っています。

それでは、
CentOSを入手しましょう。

CentOSは
以下のサイトで手に入ります。

CentOS
[URL]https://www.centos.org/download/
centos

今回は

「DVD ISO」

を選択して
CentOSのDVDファイルを選びます。

すると、
何やらリンクの一覧が出てきます。

mirrorサイト

これはCentOSを
ダウンロードできるサイトの一覧です。

「Actual Country(現在の国)」

にあるリンクが
日本で入手可能なサイトになります。

この中のいずれかから
ダウンロードしましょう。

ダウンロードした
DVDイメージをメディアに書き込んで
準備完了です。

なお、現時点での
CentOSの最新バージョンは7です。

CentOSインストール手順

いよいよインストールです。

先ほど準備した
メディアからをパソコンに入れて
起動しましょう。

step1

インストールの初期画面です。

Enterキーを押せば
インストールが始まります。

step2

しばらくすると
言語の選択画面が表示されます。

日本語を選択しましょう。

step3

インストールの概要画面です。

ここではいくつか設定変更します。

・ソフトウェアの選択(S)

次に表示された画面で
「GNOME Desktop」を選択して
[完了(D)]ボタンをクリックします。

・インストール先(D)

次に表示された画面で
何もせずに[完了(D)]ボタンをクリックします。

最後に
[インストールの開始(B)]
を選択すると、インストールが始まります。

step4

インストールが始まると
root(管理者)パスワードと
ユーザーが作成されていないと表示されます。

それぞれ、

・rootパスワード(R)
・ユーザーの作成(U)

をクリックして設定します。

インストールが終われば
[再起動(R)]ボタンをクリックします。

step5

これでCentOSが使えるようになりました。

実践で活躍するには多くのノウハウが必要

いかがでしたか?

Linuxのインストールは
意外と簡単にできるのです。

ただ、
今回ご紹介した構築法は
あくまでLinuxに触れるためだけの構築法です。

実践で活躍できる
エンジニアになるためには、
多くのノウハウの習得が必要になります。

まずはLinuxを
身近に感じるためにも

CentOSを
インストールしてみるのもいいでしょう。

それが、
あなたがエンジニアになるための
第一歩になるかも知れません。

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

PS

Linuxの
体系的なノウハウの習得は、
独学ではなかなか難しいと言えます。

基礎から実践まで
体系的にマスターしたいならこちらから。

Linuxの専門スクール

Linuxディストリビューションとは?

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

Linuxには
さまざまな種類があり、

それらを

「ディストリビューション」

...と呼びます。

今回はさまざまな
Linuxディストリビューションについて
お話ししましょう。

そもそもディストリビューションとは?

ディストリビューションとは

「流通」
「配布」

という意味で、
Linuxが配布される形態のことを言います。

本来、
Linuxという言葉は
Linuxカーネルのことを意味していますが、

カーネルだけでは
OSとして手軽に使うことはできません。

そこで、
Linuxを利用しやすいように

アプリケーションなどをパッケージにして
すぐに使える状態にしたものを

「ディストリビューション」

...と呼びます。

自動車で例えるとわかりやすいですね。

自動車には
エンジンの他にハンドルやタイヤなど

さまざまな部品があって初めて
自動車として利用することができます。

Linuxも同じで、
カーネル以外にも
さまざまなアプリケーションがあって初めて

Linuxとして
利用することができるのです。

そして同じ自動車でも
いろいろな車種があるように

Linuxにも
いろいろなディストリビューションがあるのです。

代表的なLinuxディストリビューション

代表的なディストリビューションを
いくつかご紹介しましょう。

■Red Hat Enterprise Linux (RHEL)

アメリカのRedHat社が開発した
商用向けのLinuxディストリビューションです。

クライアントPC用途ではなく
大規模システムのサーバーに利用されています。

■Fedora

FedoraはRedHat社が
支援しているディストリビューションです。

RHELは商用向けで有料なのに対し
Fedoraは無料で使うことができます。

Fedoraは次世代のRHEL向けの
検証用ディストリビューションとしての役割があり、

実際にFedoraで検証された
多くの新しい技術がRHELに採用されています。

■Debian

Debianは
世界中の有志が集結して作り上げた、

100%フリーで使うことができる
Linuxディストリビューションです。

さまざまなCPU上での動作サポートと
数万にもおよぶ膨大なアプリケーション数が特徴で、
多くの企業のシステムに採用されています。

■CentOS

CentOSはRHELのクローン(複製)OSで
RHELの商用部分を取り除いたディストリビューションです。

Fedoraのように
RHELの実験的要素を含んだOSとは異なり、

安定性も比較的高く、
商用でも使われる機会も増えています。

うちの授業はこれでやっています。
Centいいですよ。

■Ubuntu

Debianをベースに作られた
世界的な人気を持つディストリビューションです。

使いやすいデスクトップで
初心者にも抵抗なく使えるのが特徴ですが、

Debianと同じく
多くの企業のシステムにも使われています。

Linuxディストリビューションのトレンドは?

Linuxには
多くのディストリビューションがありますが、

実際に使われているのは
どのディストリビューションなのでしょうか。

実際にWebサイトで使われている
ディストリビューションを見てみましょう。

W3Techs
[URL]http://w3techs.com/technologies/history_details/os-linux

dist

これは
2014年から2015年にかけて、

Webサイトで使われている
Linuxディストリビューションの割合を示したものです。

2015年3月時点で...

1位:Debian … 32.4%
2位:Ubuntu … 26.2%
3位:CentOS … 20.3%

…と全体の78%以上を
Debian、Ubuntu、CentOSが占めています。

リリース当初は人気が高かった
Red Hat Enterprise Linuxですが、

Debian系ディストリビューションの人気が高く、
少しずつ利用率が減ってきています。

どのLinuxを使うかは企業によりますが、

・Debian系(Debian、Ubuntu)
・RedHat系(RHEL、CentOS)

...といったLinuxが
現時点でのトレンドであることを覚えておいてください。

操作自体は大きく変わりませんが、
コマンド等が変わってくるので、
注意しましょう。

Linuxテクノロジーをしっかり学ぶことが大切

ディストリビューションは違っても
Linuxというテクノロジーに違いはありません。

まずはLinuxという
テクノロジーをしっかり学ぶことが大切です。

ディストリビューションに左右されない
正しいノウハウがあれば、

どのようなディストリビューションにも
対応できるエンジニアになれるのです。

「環境に左右されないエンジニア」

そんな素晴らしいエンジニアを目指してください。

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

PS

Linuxテクノロジーを学び
環境に左右されないエンジニアを目指すならこちらから

Linuxならリスキルテクノロジー

エンジニアに必要なスケジュール管理能力とは?

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

先日、
あるプログラマーが
こんなことを言っていました。

「仕事をこなしても家に帰れない」

スケジュールが遅れたり
プログラミングが進まなかったりすると
よくあることですが...

いつまでに仕事をすればいいのかわからない

そのプログラマーは
大きなプロジェクトに参画しています。

システム化にあたって
作らなければいけない機能は多いのですが、

参加している
エンジニアの数も多いので
何とかなるだろうと考えていたようです。

彼は割り振られたプログラムを
難なく作っていくのですが...

「いつまでに作ればいいのかわからない」

...と言うのです。

プロジェクトリーダーに
いつまでにプログラムを作ればいいか尋ねても...

「できるだけ早く!」
「できるだけ前倒しで!」

...と言われるだけで、
期日がはっきりしないのだそうです。

そのため、
毎日遅くまで残業が続き
なかなか家に帰れないのだそうです。

欠けているのは「スケジュール管理能力」

同じ経験をしている
エンジニアは多いと思いますが...

このようなプロジェクトでは
ひとつ欠けているものがあります。

それは、

「スケジュール管理能力」

...です。

もちろん、
突発的な仕事が起きた場合には

スケジュールが進んでいれば
対応しやすいと言えるでしょう。

しかし、単純に...

「早く仕事を済ませたい!」

...という理由で

「できるだけ早くしてほしい」

といった指示をする管理者も少なくありません。

ほとんどの場合、
最終的な納期しか理解しておらず、

いつまでに、
何をする必要があるのか

プロジェクトを
詳細まで分解して理解できていない場合に
このような指示がされやすいのです。

スケジュールを立てるには
やることを詳細まで分割したうえで、

それぞれの作業ごとに
スケジュールを立てなければいけません。

スケジューリング能力が
不足しているということは

全体の仕事を
作業項目に分ける能力が
不足しているということにもなるのです。

管理者以外にも必要な能力なの?

もちろん
プロジェクトを管理する側だけでなく

プロジェクトメンバーにも
スケジュール管理能力は必要です。

仕事をするにあたっては、
自分が受け持った作業の期日だけでなく...

自分のスキルも判断したうえで
いつまでに終わらせることができるか?

その仕事を終わらせるために
どのような作業項目があって、
どのような流れで対応するのが効率的か?

そして、
想定した作業で高い品質を保てるか?

...といったことを
意識して対応する必要があります。

スケジューリングの対象が...

プロジェクト全体なのか、
個人の作業レベルなのか、

...それだけの違いです。

いずれにせよ、
しっかりスケジューリングできなければ、

作業の期限ギリギリになって
慌てて作業することになってしまいます。

慌てて仕事をすることは、
品質を下げる結果に繋がりかねません。

エンジニアとしての価値を高めるために

エンジニアの仕事には
必ず納期というものがあります。

なければ決めるべきでしょう。
締め切り効果って実際にありますからね。

その納期に向けて
早めに対応する越したことはありませんが、

早く終わらせることを目的にすると
品質が低下するリスクが高くなります。

システムやサービスを提供する側としては、
品質の低下は避けなければなりません。

そのためにも...

いつまでに、
何を、
どこまで終わらせるか、

といったスケジューリングは
エンジニアにとって必要な能力なのです。

たとえそれが
プロジェクトを管理する
立場の者であってもなくても、

普段から
スケジュールを意識しておかなければ、

その場その場の
対応だけになってしまいます。

全体を見据えて個々の仕事を行う...

その姿勢は
あなたのエンジニアとしての
価値を高めてくれることでしょう。

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

PS

スクールの開発演習で力をつけましょう

アルゴリズムの基本3:ソート(並べ替え)

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

プログラムでは必ずデータを扱いますが...

データ量が増えれば増えるほど、
並べ替えしておいた方が扱いやすくなります。

今回は並べ替えのアルゴリズムである、

「ソート」

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

ネット検索にも使われている

インターネットのウェブサイトの数は
2014年に10億件を突破しました。

Yahoo!やGoogleなどの
検索サイトからサイト検索をするときに、

いちいち10億件のサイトを
検索していたのでは時間がかかって仕方ないですよね。

このため、
インターネットで何かを検索すると
必ず訪問者の多いサイトが上位に表示されます。

これはサーチエンジンが
有効な情報を持っているサイト順に並べ替えて、
訪問者の多いサイトを上位に表示しているからです。

データというのは
量が増えれば増えるほど、
きちんと並べ替えられている方が管理しやすいですよね。

この並べ替えのことを...

「ソート」

...と言い、非常によく使われるアルゴリズムです。

ソートする時には
以前にお伝えした「配列」が必要で、
配列にデータを入れてからソートするのが一般的です。

値の小さい順にソートすることを「昇順」、
値の大きい順にソートすることを「降順」と言います。

どちらの順でソートするかはケースバイケースですね。

それでは、
代表的なソートアルゴリズムを
いくつかご紹介しましょう。

バブルソート
~単純なソートアルゴリズム~

ソートのアルゴリズムで
もっとも単純なもののひとつがこの「バブルソート」です。

バブルソートとは、
隣り合ったデータの値を比べて、
単純に並べ替えていくというものです。

イメージを見てみましょう。

bubblesort

1、4、3、2と並んだ
4つの値が入っている配列があります。

これを左から順に...

1番目と2番目のデータを比べ、
1番目と3番目のデータを比べ、
1番目と4番目のデータを比べ...と、

単純に順序だてて比べていって、
左側の値が大きければ位置を交換する仕組みです。

1番目の値を比べ終わったら、
2番目のデータを元に比べてゆきます。

数字が上に上がっていく様子が、
泡が水の中で上に浮いてくる様子に似ていることから
バブルソートと言います。

ソートのアルゴリズムの中では単純で、
少ないデータを扱う時には問題ありません。

ですが、
データ量が増えれば増えるほど、
バブルソートでは処理に時間がかかってしまうのです。

例えば、全ての値を
比べ終わるのに必要な処理回数は最大...

1,000個の配列だと49万9500回、
10,000個の配列だと4999万5000回かかります。

ちょっとかかりすぎですよね。

そこで、バブルソートよりも
高速なアルゴリズムが必要になってきます。

クイックソート
~文字通り高速にソートできるアルゴリズム~

バブルソートよりも処理の速いアルゴリズムで、
代表的なものに「クイックソート」があります。

簡単に言うと、
データの中から基準となる値を決めて、
それより大きいグループと小さいグループに分けてから、
ソートしてゆくアルゴリズムです。

ちょっとややこしいので、
今はわからなくても大丈夫です。

クイックソートのイメージだけ掴んでくださいね。

それでは、イメージを見てみましょう。

quicksort

3、4、5、2、1と並んだ
5つの値が入っている配列があります。

一番左にある3を
とりあえず基準値として、
3よりも大きいグループと小さいグループに分けます。

このとき、3の位置はもう確定しています。

ちょうど大きいグループと小さいグループの間ですね。

そして今度は、
それぞれのグループから基準値を決めて、

その基準値と
グループの中のほかの数を比べて、
相手の値が小さければ並べ替えます。

最終的に比較するものがなければ、
そこでソートが終わりです。

ちなみに、この5つの値のソートを
バブルソートですると処理回数が10回かかります。

クイックソートは名前のとおり、
素早くソートできるアルゴリズムなのです。

適切なアルゴリズムを使って効率性を上げよう

バブルソートやクイックソート以外にも、
さまざまなソートのアルゴリズムがありますが...

それらは必要に応じて覚えてゆけばいいでしょう。

クイックソートは
実用的で処理の早いアルゴリズムとして
多くのシステムで使われますが、

データ件数によっては
別のアルゴリズムの方が速いケースもあります。

扱うデータ件数によって
アルゴリズムを使い分けると処理速度が上がるのです。

アルゴリズムはあくまで
効率的に処理を行う手順です。

1つの手順にこだわることなく、
常に適切なアルゴリズムを使うことができれば、
効率の良いプログラムを組めるエンジニアになれます。

柔軟な考え方のできるエンジニアになってください。

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

PS

柔軟な発想を持つには、
基本から応用まで、幅広いノウハウが必要です。

基本的なアルゴリズムを始め
現場で使える応用力を身に着けたいなら資料請求を。

アルゴリズムも勉強できるリスキルテクノロジー

高品質サービスの指標となるSLAとは?

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

インフラエンジニアでも
アプリケーションエンジニアでも

何らかのサービスを作って
ユーザーに提供するのは変わりありません。

どのようなサービスを提供するかは
ユーザーと話し合った上で取り決められます。

今回はその取り決め内容をまとめた、

「SLA」

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

もしもコンビニが営業していなかったら

どこを歩いていても
必ず目に入るのはコンビニエンスストア。

コンビニは
24時間営業と豊富な品揃えが特徴ですが、

あなたがコンビニに行ったとき
営業していなかったり
ほとんどの商品が売り切れだったらどう思いますか?

ちょっと珍しい光景かもと
面白く感じるかも知れません。

しかし、
コンビニとあなたの間で、

24時間営業と豊富な品揃を提供するという
「合意」を取り決めていたとしたら、

「ちゃんと合意していた何どうして?」

...と思ってしまうことでしょう。

このように、
サービスを提供する側と
受ける側との間で取り決められた合意内容を、

「SLA(Service Level Agreement)」

...と言い、提供する側は
SLAで取り決めた内容を目標として
サービスをユーザーに提供するのです。

実際にはコンビニと利用者はSLAを結びません。

あくまで例です。
念のため。

データセンターなどで見られるSLA

SLAはデータセンターや
通信サービスなどでよく結ばれています。

データセンターにおける
SLAの内容について例をあげてみましょう。

SLA(INFRA)

SLAでは評価項目に対して、

「目標とする水準をクリアできたかどうか」

...を客観的に判断できる目標が設定されます。

この例で言うと、
サーバー可用性は99.9%以上ですが、

サーバーが99.9%以上の確率で
正常に動いていることを保証するという内容です。

簡単に言えば、

「1年のうち99.9%は使用できることを保証しますよ」

...という意味になります。

この他にも、
障害が発生した場合の回復時間や、
問合せの対応可能時間など

データセンターに関するサービス内容が
SLAで取り決められています。

Webやメールサービスを
提供しているレンタルサーバー業などでは、

SLAの基準をクリアできない場合は
月額料金を返還する業者もあるほどです。

インフラ系のサービスにおいては
SLAの取り決めは基本的なものになっていますね。

システム開発にもSLAは有効です

SLAはインフラ系サービスだけでなく、
システム開発でも取り決められています。

システム開発における
SLAの例を見てみましょう。

SLA(SYSTEM)

システム開発におけるSLAでは
比較的アプリケーションよりの内容になっています。

たとえば
オンラインレスポンスですが、

ボタンをクリックして
次の画面に移動するまでの時間について
取り決められています。

処理速度が遅く、
画面表示に1分以上かかるのでは
実際の業務では使うことはできません。

そのため、
要件定義や基本設計段階で
処理時間について目標を決めて開発します。

他にも、
障害回復時間など
障害発生後の対応をランク分けすることで
復旧時間を決定するケースもあります。

システム稼働に問題がない
軽度な不具合は対応がややゆっくりの対応、

障害復旧しないと業務できないといった、
深刻な不具合は即対応などですね。

システム開発におけるSLAは
企業間のシステム開発だけでなく、

社内システムの開発でも有効な方法として
多くの企業で取り組まれるようになっています。

高いサービス品質を保つことがエンジニアとしての質を高める

インフラ系でも
システム系でも、
SLAを取り決めることによって、

・システムのサービス提供範囲の明確化
・サービスレベルに応じたコストの明確化
・高品質のサービスレベルの維持
・ユーザーとの信頼関係の構築

...といった多くのメリットがあります。

サービスを提供するにあたり、

「高い品質を保つための目標」

...とも言えるのがSLAを、
エンジニアとして意識するようにしましょう。

それは、
エンジニアとしての質を
高めてゆくことにつながる姿勢なのです。

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

PS

提供するサービスの品質は
高ければ高いほどいいですよね。

これは学習も同じです。

品質の高いスクールはエンジニアへの近道です。

エンジニアの専門スクール

オープンソースの普及が4年間で2倍に

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

Linuxをはじめとする
オープンソースソフトウェアは

多くの企業のシステムに
採用されはじめています。

その傾向が、
2010年から急激に動き、
より顕著になってきました。

オープンソースの採用は標準的なアプロ-チに

ここに、
オープンソース管理ソリューションを提供する
アメリカのBlack Duck Software社と

ベンチャー企業を支援する
North Bridge社が共同で行った調査結果があります。

The Ninth Annual Future of Open Source Survey
[URL] https://www.blackducksoftware.com/future-of-open-source

blackduck

これは

「オープンソースの未来について」

というテーマで
企業に対して行われている調査で、

企業における
オープンソースソフトウェアの
使用状況などを調査しています。

調査結果では、
78%の企業が自社の業務で
オープンソースを採用していると回答しており、

42%だった
2010年度の調査結果と比べると
2倍近くにまで増えています。

また、
66%以上の企業は
システム的な課題解決のために

オープンソースを
まず先に検討すると回答しており、

オープンソースの検討が
標準的なアプローチになっています。

企業がオープンソースを選択する訳とは

オープンソースの検討が
標準的になっている背景には
どのようなことが起きているのでしょうか。

まず、
企業の58%はオープンソースが
拡張性に優れていると回答しており、

オープンソースと
そうでないソフトウェアを比べると、

オープンソースの方が
システム展開しやすいと回答しています。

また、
オープンソースと
そうでないソフトウェアを比べると、

55%の企業が
オープンソースの方が
セキュリティ性に優れていると回答しており、

この考えを持つ企業の割合は
今後2~3年間で61%にまで増える見込みです。

ビッグデータや
クラウドコンピューティング、

そして今後大きく広まる
モノのインターネット(IoT)などは

2~3年のうちに
オープンソースの影響を受けると予想されています。

オープンソースの課題は「管理体制」

しかしここで、
ひとつの課題が浮き彫りになっています。

確かに多くの企業で
オープンソースが採用されていますが、

オープンソースソフトウェアを
しっかりと管理できていないという点です。

55%以上の企業が
自社でオープンソースを採用するにあたり
正式な導入ポリシーを定めておらず、

正式なポリシーを定めている企業は
27%と低い水準にとどまっています。

これは
オープンソースを導入したはいいけど
きちんと管理できていないことを意味しています。

また、
50%以上の企業は
オープンソースに潜んでいる

セキュリティ的な弱点(脆弱性)を
把握するスキルが足りていないと回答しています。

オープンソースを使った
システムにおいて、

脆弱性が潜んだ
プログラムがあるかどうかを
監視しているのはたったの17%でした。

他システムと連携しやすく
無償で導入できるのはオープンソースのメリットですが、

それを使って
セキュリティ的な弱点を潜ませる
システムを構築してしまうのは問題ですよね。

オープンソースの未来のために

オープンソースが
多くの企業で選択されているのは喜ばしいことです。

Linuxをはじめとする
オープンソースの活用シーンが増えることで

エンジニアが
活躍できる機会が増えています。

しかし、
オープンソースと言っても

システムを作るための
ひとつの道具にすぎません。

どこでどの
オープンソースが使われているか、

しっかり管理されていないと
収拾がつかなくなってしまいます。

セキュリティについても同じです。

脆弱性を知らずに
システムを構築することは、

玄関の鍵が
壊れているのに気付かないまま
家を建てているのと同じことです。

エンジニアは
オープンソースを使うにあたって

オープンソースを使った
システムやサーバーの構築法だけでなく、

なぜシステム化するにあたって
そのオープンソースを選択したのか、

そのオープンソースに
どのような脆弱性があるのかを
理解したうえで活用しなければなりません。

あなたもプロフェッショナルエンジニアになるなら、
その意識を強くもっていきましょう。

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

PS

オープンソース一筋の
専門校リスキルテクノロジー

プログラマーは専門性だけではダメ?

From: リスキルテクノロジー 松田航
@新宿オフィス

「プログラマーを目指す以上、専門性を
身に付けることは必須ですよね?」

「やはりエンジニアを目指すなら、
高度な専門技術が必要ですか?」

エンジニアやプログラマーを目指すあなたが
感じている通り、

スペシャリストである以上、専門的な技術を
身に付けることは必要条件です。

しかし

専門的な技術を身に付けたからといって、
引く手あまたのエンジニアやプログラマー
になれるか?

というと、必ずしもそうではありません。

事実、未経験からエンジニアを目指した方々が、
転職後に活躍しているということは、
まったく珍しいことでありません。

つまり、専門的な技術だけではない、
ということなのですが・・・

それでは、エンジニアやプログラマーとして
活躍するには、一体何が必要なのか?

これについてお話したいと思います。

【ヒューマンスキルを磨く必要がある】

エンジニアやプログラマーを目指す方にとって、
専門性を身に付ける必要があるというのは、
ごく当たり前のことと考えられているようです。

確かに少し考えてみると、

料理人になるなら料理が作れないとなりませんし、
美容師になるならカットなどの技術が必要ですから、

仕事を遂行するにあたって専門的な技術を
身に付けることは、スペシャリストに不可欠です。

しかし専門性だけでお客さんと仕事をすることが
できるかというと、そうではありません。

たとえばプログラムの開発とサーバの構築の両方を
お客さんから受注した場合、

プログラマーやインフラエンジニア、営業担当などを集め、
プロジェクトチームを作る必要があります。

担当ごとに求められる専門性は異なりますから、
多くの会社では分業化や専門化が進んでいるはずです。

分業化や専門化が進めば進むほど、
一つのプロジェクトを完了するにあたり、
協力してもらうスペシャリストの人数が増えますから、

あなたの担当する仕事を終えるためには、
他のスペシャリストと協調して仕事をしていくスキルや

正しく依頼や相談をするためのコミュニケーション力が
必要になるわけです。

つまり、プロジェクトの完遂には技術的なスキルに加え、
ヒューマンスキルを磨く必要がある、ということです。

そして仕事というのは、
お客さんの課題を解決することですから、

課題を理解するといったコミュニケーション力を
はじめとする、ヒューマンスキルが必要不可欠です。

技術だけではだめ

エンジニアやプログラマーとして活躍し、
評価されるには専門性だけでは十分ではなく、
ヒューマンスキルが求められるということ。

また、結局給料が上がって行くのも、
技術力だけではなくバランスよく能力が上がっている
人材です。

なぜなら、上の立場の人間は、
人を育てることも重要な仕事になるからです。

専門性を身に付けなければならない、
という意識はきっとあなたも持っていると思いますから、

むしろヒューマンスキルこそ、
仕事を進めるにあたり大事なスキルである

こう、考えてみてもいいかもしれません。

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

PS

手っ取り早くエンジニアに必要なヒューマンスキルを上げるには、
開発演習をやるべきです。

開発演習も行うプログラミング講座

エンジニアリングの基本:PDCAサイクル

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

「PDCAサイクル」

という言葉を知っていますか?

学生であれ
社会人であれ、

一度は聞いたことがあるかと思います。

今回は

「PDCAを意識する大切さ」

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

PDCAサイクルって何ですか?

PDCAサイクルとは
業務品質を高めるための手法で、

継続的に業務内容をチェックして
改善・改良しやすくするための理論です。

PDCAは以下の4つの要素に分かれています。

【P】Plan(計画)

目標を設定して計画をたてる。

【D】Do(実行)

計画に基づいて実行する。

【C】Check(評価)

実行結果を分析して評価する。

【A】Action(改善)

実行結果や計画通り進んでいない点について、
実行方法を改善する。

この4つの要素の頭文字を取って、

「PDCAサイクル」

と呼ばれています。

PDCAはサイクルですので、

P→D→C→A→P→D...

と繰り返してゆきます。

この繰り返しによって、
より良い品質を保つことができるのです。

個人の業務にもPDCAサイクルは当てはめられる

PDCAサイクルは
企業の品質管理や業務管理に使われますが、

個人の業務にも
当てはめることができます。

例えば、あなたが
プログラムを作るとしましょう。

その時には、
あなた個人の業務の中に
PDCAサイクルができているのです。

【P】Plan(計画)

仕様確認してどのように作るか計画する。

【D】Do(実行)

仕様に基づいて作成する。

【C】Check(評価)

動作確認を行う。

【A】Action(改善)

不具合があれば修正する。
もっと処理を効率化できる点を改善する。

プログラミングの例で言えばこうなりますが、

どのような業務でも
PDCAサイクルは個人の業務に生まれています。

もし、個人の業務に
PDCAサイクルが生まれていない場合は、

業務の品質が低くなってしまうのです。

PDCAを意識しない業務は品質が低い

業務の中に、
PDCAサイクルが
生まれていない例を見てみましょう。

例えばサーバー障害が発生して、
ネットワークが接続できなくなったとします。

あるエンジニアは、
やたらとコマンドを入力して
設定変更を行っては障害復旧しようとします。

思いつく限りの方法を試みますが、
まったく障害復旧する様子はありません。

時間は過ぎて行く一方で、
エンジニアには焦りだけが募ります。

…これって効率が悪いですよね。

「とりあえずやってみるか!」

というタイプの方に多いケースなのですが...

(私もこちらのタイプですね。)

このタイプのエンジニアには
Plan(計画)とAction(改善)がないのです。

Do(実行)とCheck(評価)だけです。

知っていることをひたすら試し続ける。

それが問題だとは言いませんが、
もっと効率的に業務を行う方法はあるはずです。

できるだけ短い時間で最大の効果を発揮する方法が、
高い業務品質を持った業務です。

そのためには、
サーバーログファイルなどを確認して
情報を集めた上でどのように対応するか計画し、

実行、評価して障害回復しなければ
改善策を検討して別の方法を試してみる...

といったように、
PDCAサイクルを業務に活かさなければ、

業務品質が低くなってしまうのです。

業務品質を高めるためのポイント

普段の業務では...

「PDCAサイクルをいかに早く回すか」

...という点がポイントです。

慎重なタイプの方に多いのですが、
Plan(計画)ばかりに気をとられていると、

なかなか行動が起こせずに
業務が進まなくなってしまいます。

何かの業務をするときには...

【P】手早く業務を進める手順をたてる。
【D】手順通りに業務を行う。
【C】業務内容をチェックする。
【A】不備や手順どおりにできていない点を確認する。

...というサイクルを
どれだけ早く繰り返すかが大切なのです。

PDCAサイクルは、

・大きく見れば企業全体の業務品質を高める
・小さく見れば個人の業務品質を高める

...ということを覚えておいてください。

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

PS

PDCAサイクルは
品質管理としてはスタンダードな手法です。

より良い品質を提供するために
個人レベルでPDCAを意識するようにしましょう。

エンジニアスクールのリスキルテクノロジー

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

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

IT講師に応募する