リスキルテクノロジー

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

カーネル

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

「カーネル(Kernel)」

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

カーネルとは和訳すると

「核」

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

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

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

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

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

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

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

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

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

「橋渡し」

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

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

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

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

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

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

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

「システムコール」

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

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

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

 

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

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

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

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

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

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

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

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

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

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

先ほどの例で

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

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

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

「営業力」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「売上」

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

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

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

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

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

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

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

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

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

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

「営業」

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

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

「大切なパートナー」

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

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

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

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

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

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

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

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

PS

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

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

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

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

Linuxエンジニアの未来

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プログラミングを勉強するならリスキルテクノロジー

データセンターって何をするところ?

データセンター写真

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

クラウドの利用者が増える一方で
データセンターを活用する企業も増えています。

データセンターという言葉は
誰でも一度は聞いたことがあると思いますが...

このデータセンターとは
一体何をするところなのでしょうか。

今回はデータセンターについてお話ししましょう。

データセンターってどんなところ?

データセンターとは
サーバーやネットワークといった機器を
設置・運用する施設のことです。

ラックと呼ばれる棚に
サーバーなどの機器を設置し、
通信回線や電源などが提供されます。

データセンターが
提供しているものを細かく言うと、
大きく分けて以下の7種類になります。

(1)土地

機器を設置するための土地を提供します。

(2)建物

自然災害や盗難などに備えた
安全性の高い建物を提供します。

(3)ファシリティ(設備)、コネクティビティ(通信)

サーバーを設置するラックや電力設備、
インターネットなどの通信回線などを提供します。

(4)ハードウェア

サーバーなどのハードウェアを提供します。

(5)OS、ソフトウェア

LinuxなどのOSやソフトウェアを提供します。

(6)ミドルウェア/

Webサービスなどに必要なソフトや
データベースなどのミドルウェアなどを提供します。

(7)アプリケーション

実際に使用するアプリケーションを提供します。

基本的に(1)~(3)までが
整備されている施設をデータセンターにあたり、

「インターネットデータセンター(iDC)」

...とも呼ばれています。

また、(4)~(7)は
データセンターが提供するサービスにより、

データセンターで管理・運用するか、
使う人が管理・運用するかが分かれます。

データセンターで提供しているサービスとは?

それでは、
データセンターで
提供されているサービスをご紹介しましょう。

■ハウジング(コロケーション)サービス

自社にサーバーを設置せず、
安全性の高いデータセンターに預けますが、

サーバーの設定や運用、管理は
自社で行いたい場合に最適なサービスです。

利用者はサーバーの設置場所や電源など
ハード面に関する問題を解決することができ、

サーバーにリモート接続することで
自由にサーバーをカスタマイズできます。

■マネージドサービス

ハウジングと同じように
サーバーをデータセンターに預けますが、

運用や管理なども
データセンターに任せるサービスです。

利用者はハード面に関する問題だけでなく、
運用・管理のコストも削減することができます。

■ホスティングサービス

データセンターに設置された
サーバーやネットワーク機器を
購入することなく利用したい場合に最適なサービスです。

代表的なものとして、
レンタルサーバーやクラウドなどがあげられますね。

1台のサーバーを丸ごと利用することを
専用サーバーサービスと言い、

1台のサーバーを複数の利用者で共有し、
仮想的に作られたサーバーを利用することを
共有サーバーサービスと言います。

■バックアップサービス

重要なファイルを
データセンターにバックアップできるサービスです。

増え続ける
バックアップファイルは
多くのハードディスク容量を必要としますが...

バックアップサービスを利用すれば
利用者はハードディスクを気にすることなく、
バックアップすることができます。

ハウジングやホスティングなどと
併用されることが多いですが、
バックアップサービスだけを利用することもできます。

データセンターが増えている訳とは?

データセンターが増えている背景には
さまざまな理由があるのですが、

そのうちのひとつに
企業が抱えている「ある問題」があります。

それは...

「事業継続性(BCP)」

...という問題です。

BCPとは、
自然災害などが発生した時でも
事業を中断することなく行えるようにすることで...

仮に事業が中断したとても、
すぐに復旧できるように日頃から備えておくことです。

何らかの災害や問題により
サーバーが使用不能になった場合、
システムを利用することができなくなりますが…

データセンターという社外の施設に
サーバーやデータがあれば、
早めに事業を再開することができるのです。

今でもサーバーやデータを
社外に保管したくないという企業は多いですが...

BCP対策にもなり、
セキュリティ性も高く、
業務負担が解消されるというメリットから、
積極的にデータセンターを利用する企業が増えています。

データセンターの普及はチャンス!

IT業界では
データセンターの普及に伴って、
インフラ系スキルを持ったエンジニアを求めています。

ニーズの割にできる方が少なく、
どの企業でも常に求めています。
(本当です)

ハードウェアやネットワークなど、
インフラ系エンジニアを目指す方にはチャンスです。

自社開発であっても
クラウドを利用して開発を進める企業もあり、

どのようなエンジニアでも
データセンターに接する機会はあります。

これからの時代、
エンジニアとして活躍したいのであれば...

データセンターの仕組みや、
提供するサービスなどといった知識を
知っておく価値はあると言えるでしょう。

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

PS

多くのデータセンターでは、
サーバーOSにLinuxが採用されています。

これからのクラウド時代、
Linuxはエンジニアにとって
なくてはならないスキルなのです。

リスキルテクノロジーの資料請求はこちらから

システムのトラブルシューティング

システムのトラブル

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

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

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

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

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

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

トラブルの原因は必ずどこかにあります

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし、

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

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

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

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

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

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

例えば...

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

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

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

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

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

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

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

特に問題がない...

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

プログラムの場合だと
AさんのPCだと問題なく動くのですが、
BさんのPCだと計算結果が違うといったケースですね。

そのようなケースでは
OSやサービスのバージョンが、
正しいものを使っているかどうか調べましょう。

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

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

しかし、ベンダーにサポートを依頼した場合、
原因がわかるまでに時間がかかります。

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

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

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

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

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

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

つまり、

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

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

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

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

PS

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

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

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

システムエンジニアになるならリスキルテクノロジー

ハイブリッド型開発とは? (WF + アジャイル)

ハイブリット開発

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

これまで、
ウォーターフォールモデル開発(以下「WF」)と
アジャイル開発(以下「アジャイル」)についてご紹介しました。

それぞれに特徴はありますが
ではどのような点が異なっているのでしょうか?
今回はWFのアジャイルの違いについて説明しましょう。

また、最近では
WFとアジャイルそれぞれのメリットを活かせる...

「ハイブリッド型開発」

...という開発手法も注目されています。

ハイブリッド型とはどのような開発手法なのでしょうか?

ウォーターフォールとアジャイルの違い

WFとアジャイルの違いについて表にまとめました。

アジャイルとウォーターフォール

1.開発文化

WFはプロジェクトの制御や命令系統を重視しますが
アジャイルはプロジェクトチームの協力を重視します。

組織的な統制を重視するのがWFであり
協業による自由な結合を重視するのがアジャイルです。

2.計画・管理

WFは統制を重視するため、
開発計画を立てやすくプロジェクト管理が行いやすい。

対してアジャイルは柔軟な変化に対応すべく
案件や規模に応じての管理を行うため、管理方法には工夫が必要です。

3.仕様変更

WFは基本的に仕様変更しないことが前提。
変更が発生すると後工程に大きな影響を与えますが、
アジャイルは柔軟な仕様変更にも対応できるような手法です。

4.ドキュメント

WFは工程別に成果物として
ドキュメントの作成が必須要件になっています。

対してアジャイルでは
不必要なドキュメントは極力作りません。

「アジャイルではドキュメントを全く作らない」

という誤解を持っている方もいるのですが
実際には開発において最低限必要なドキュメントは作成します。

というより、きちんとしたアジャイル開発では、
ドキュメントは必須です。

5.ユーザー承認

開発費用の支払は
ユーザー承認のタイミングで行われる事が多いですが、
WFはドキュメント等の成果物をもって承認を受けます。

対してアジャイルでは
実際に動作するアプリケーションをもって承認を受けます。

6.プログラム

WFでは要件定義~詳細設計の上流工程で設計された
全機能を一気にプログラミングします。

アジャイルではあらかじめ
優先順位で定められた機能を順番にプログラミングします。

ただ、小規模な開発案件の場合は
一気にプログラミングを行うケースもあります。

7.リリース

WFでは原則的に全機能を一度にリリースします。

ただし、リリース計画によっては
サブシステム単位にリリースするケースも。

アジャイルではイテレーション毎にリリースを行い、
ユーザーからのフィードバックを受け、次のイテレーションに移ります。

8.開発規模

WFは計画、管理のしやすさや
指揮系統が重視されることから大規模開発に向いています。

アジャイルは小規模開発向きですが
最近では管理方法なども工夫されつつあり
大規模なシステム開発にも採用される傾向にあります。

見える開発、見えない開発

WFとアジャイルの違いをまとめましたが
もうひとつ大きな違いとして...

「ユーザーから見える開発・見えない開発」

...という特徴があります。

WFでは要件定義や基本設計、
そして総合テストやユーザーテストなど
上流工程と下流工程においては開発の動きが見えやすいですが...

詳細設計や製造、単体テストなど
開発チームが主体となってしまうフェーズでは
どのような開発を行っているのかユーザーからは見えにくいのです。

対してアジャイルでは
原則的にユーザーも開発チームの一員とすることから、
開発中でもどのような開発を行っているのかが見えやすい。

大型の長期案件ともなると
WFで開発されることが多いのですが、
製造などの中流工程になるとユーザーによっては...

「ちゃんと開発は進んでいるのだろうか?」

...といった不安を抱くケースも。

不安を払拭する為に
定期的な進捗報告などは行うのですが、
開発やテスト内容が見えないというのは変わりありません。

ユーザーは後から成果物で
開発結果やテスト結果を知るのみです。

では、アジャイルの方が
ユーザーにとって安心かというと、そうでもありません。

確かに開発中の動きが見えるのは良いのですが...

WFの様に最初から綿密に要件定義などを行うのではなく、
優先順位別に開発・リリース・フィードバックを繰り返すため...

見えるからこそ、
変更が頻発して要件が膨れすぎたり、
他機能との整合性が取れなくなったりするケースも。

また、システムの最終形が完成するのは
複数回のイテレーションを繰り返した後になることから、
総合テストなど、他機能と連携したテストを行いにくいという特徴も。

このような理由により、
アジャイルは小規模開発向きと言われているのです。

それぞれのメリットを最大限に発揮する
ハイブリッド型開発とは?

WFは上流工程と下流工程、
アジャイルは中流工程における変化に強い。

最近では、
それぞれのメリットを活かした手法として...

「ハイブリッド型開発」

...という開発手法があります。

これは要件定義や基本設計、総合テストなど
WFが得意とする上流工程や下流工程はWFで行い...

詳細設計や製造、単体テストなど、
アジャイルが得意とする中流工程はアジャイルで開発するというもの。

ハイブリッド型開発の流れを簡単に説明すると...

(1)要件定義
(2)基本設計
(3-1-1)機能A 詳細設計
(3-1-2)機能A プログラミング
(3-1-3)機能A 単体テスト
(3-1-4)機能A ユーザーフィードバック
(3-2-1)機能B 詳細設計
(3-2-2)機能B プログラミング
(3-2-3)機能B 単体テスト
(3-2-4)機能B ユーザーフィードバック
 …
<(3)は必要に応じてイテレートを行う>
 …
(4)結合テスト
(5)総合テスト・ユーザーテスト
(6)リリース

...といった流れで開発が進みます。

WFのデメリットである...

・フィードバックが少なく、変更対応に弱い
・開発内容が見えにくい

アジャイルのデメリットである...

・開発管理を行いにくい
・上流工程、下流工程に弱い

ハイブリッド型においては
このようなWFとアジャイルのデメリットをカバーし、
それぞれのメリットを活かした開発を行えるのが特徴です。

開発手法にのみ捉われてはいけない
トータル的なシステム開発サービスの品質が大切

企業における
ビジネススピードは加速しており、
システム開発側もそのスピードに対応すべく、
さまざまな開発手法が検討されています。

ハイブリッド型も
そのような風潮から生まれた手法のひとつであり、
アジャイル体制を構築しにくいと言われる
SIerでも注目されています。

しかし、
WFが良い、アジャイルが良い…というように
開発手法にばかり目が行ってしまうのも問題です。

開発の進め方については
ユーザーに提案し、きちんと説明することが大切。

そして開発中には
ユーザーに不安を抱かせず、
不透明な部分ができるだけないように進めることも重要です。

自社のアプリケーションであれば、
内部のエンジニアの総意を汲み取って決めるべきでしょう。

アジャイルはひとりが理解していないと、
その時点で崩壊しがちです。

手法も確かに大切ですが、
エンジニアが考えるべきは...

・ベストプラクティスなシステム
・アプリケーションの品質
・柔軟性
・スピード

...などといった...

「トータル的な品質」

であるという事を忘れないでください。

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

PS

どの業界でもそうですが
ユーザーに提供するのはトータル的な品質です。

いくら品物が良くても
売り手の対応が良くなければ、
それはユーザーにご提供するサービスとして
品質が低いと言わざるを得ません。

講師・テキスト・環境 すべてが揃ったシステムエンジニア研修

デスマーチとは?

デスマーチ

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

『デスマーチ』という言葉は知っていますか?
今回はデスマーチについて話をしましょう。

IT業界だけではない
社会問題化しているデスマーチ

「デスマーチ」というのは
アメリカのプログラマーが提唱した
プロジェクトマネジメントに問題が発生している状態。

日本では略して「デスマ」とも言われています。

日本語にすれば、文字通り...

「死の行軍」

を意味し、
進んでも進んでも解決しない...

つまり、どれだけ開発を行っても
なかなかシステムが完成しない状況を意味します。

具体的に言えば、以下の様な状況に陥っています。

・残業時間が極端に多く、月間労働時間が300~400時間にも

・休日出勤は当たり前で、休みが取れない

時間がいけないというよりかはこれだけ働いても、
進まないことが問題でしょうか。

また、自らの意思がないことも。

私自身は上記2つとも、
常にやっていますね。
好きで。

個人的な話はおいておき、
このような状態が長期間続くことにより
プログラマーを始め多くの開発者が心身共に疲労しきってしまい...

体調不良で出勤できない者、
翌日から連絡なしに急に来なくなる者、
心の病になってしまう者など、脱落者が出るケースも。

まず、最初にお断りしておきますが、
この事象はIT業界に限ったものではありません!

むしろ業界は関係ありません。

どちらかというと
昔はIT業界でこのような状態が目立った為、
最近のIT業界ではデスマーチを避ける努力が行われています。

業界を問わず、
企業によってデスマーチと同様の事象が起きており、
社員が過重労働が強いられて労災問題にまで発展するなど、
近年、重大な社会問題とされているのです。

デスマーチはなぜ起こるのか?

デスマーチが発生する理由はさまざま。

ですが、最も簡単に表現するなら...

「安請け合いと状況把握能力の欠如」

...という言葉が妥当な表現になります。

IT業界において
デスマーチが発生する原因をいくつか挙げてみましょう。

(1)開発期間不足の問題

本来開発に1年は必要な案件を...

「3か月でできます!」

...と顧客に応えて受注してしまった。

つまり開発期間が圧倒的に足りていない。

(2)人的要員の不足

どう少なく見積もっても
SE2名、PG5名はプロジェクトに必要であるが、
実際にはSE兼PGが1名と初級PG2名しか要員が確保できない。

つまり開発に必要な人手が足りない。

(3)予算が足りない

開発に対する予算がなく
外部から開発要員を雇おうにも雇えない。

また開発するには
特殊な機器や必要となるが
それらを購入・レンタルする予算がない。

つまり開発に必要な運転資金がない。

(4)ユーザーニーズが多すぎる

ユーザーが開発システムに対し、
あの機能もほしい、この機能も欲しいと
多くの機能的な要求を提示してくることにより、
対応しなければいけない機能が膨大な量に膨れ上がる。

また、一度作った機能に対しても...

「やっぱりこうしてほしい!」

...と、頻繁に仕様変更を行うため、プログラム変更が頻発する。

つまり開発期間や開発要員、開発費用など、
それらに見合うもの以上の要求がユーザーから発生している。

デスマーチという状態は
これらの要素が複雑に絡み合って発生します。

共通しているのは、
ユーザーと話す立場の者(営業やプロジェクトマネージャなど)が...

・受注さえすれば何とかなる
・ユーザーの要求を鵜呑みにする
・現場の状況を把握できていない

...という傾向がある場合に
デスマーチは発生しやすくなります。

戦略案件という名のデスマーチ

しかし、あえてリスクを理解した上、
デスマーチ覚悟で案件を受けるケースもあります。

それは「戦略案件」と呼ばれる案件を
受注する場合です。

戦略案件とは、
今まで取引のなかった企業から
何とかしてシステム開発を受注したい場合や、
その企業と取引を開始することによって、
今後も継続的な受注が見込めそうな場合に言われる名称です。

例えば全国展開する
大手量販店の人事システム改定案件があったとしましょう。

システムの老朽化により
大手量販店がシステム改定を検討しており、
できるだけ安く、早くシステムを導入してくれる企業を探しています。

営業担当が何度か足を運び
SEも技術的はサポートとして営業同行し、
競合他社も多数ある中、最終候補企業にまで残ることができました。

大手量販店から要求された
予算と開発期間は、開発に必要な費用と開発期間を
大幅に不足していました。

今後のお付き合いができるなら!
運用保守まで当社にお任せいただけるなら!

いろいろな条件交渉をしつつ、
開発期間不足や赤字を覚悟した条件で
受注してしまうケースもあるのが現状です。

ここからがデスマーチの始まり。

要員の確保、
予算や運転資金の問題、
開発期間不足にともなう不十分なテストなど...

自らリスクを
わざわざ多くしているようなものです。

プロジェクトマネージャの手腕や
開発チームのスキルなどにもよりますが、
何らかのトラブルが発生するのは目に見えています。

もちろん、うまく納品できれば
戦略案件としては成功で万々歳なのですが...

だいたい何かしらの問題が発生します。

それでも取るのが、営業です。
また経営者もこちら側でしょう。

どちらの立場もわかる身としては、、、
うーん、でもまぁ取るでしょう。

やっぱり。

しかし、

ただ突き進むのだけはNG!
常に分析・提案を意識しながら進みましょう

一回経験しておいた方が、
確実に力はつきます。

なので、まだまだ経験が浅いうちは、
とりあえず頑張りましょう。

しかし、これが恒常的になると
よくありません。

IT技術者の飲み会などでは
デスマーチの経験自慢が聞かれることが
ままあります。

「あのプロジェクトでは月400時間いった」
「ええ!?400は行き過ぎでしょう?」
「負けた!俺は300時間程度しか経験ないや」

過酷な労働状況や
難しい案件を乗り切った場合、
困難を克服した達成感に満たされ、
このような話も出るのでしょう。

しかし、
働く時間が自慢の種になっている時点で
アウトです。

また、デスマーチは
マネジメントの観点から見ると、
明らかに失敗している状態であると言えます。

もし、あなたがIT技術者になって
デスマーチを迎えてしまった時には...

・何が原因となったのか?
・被害を最小限に抑えるにはどうすれば良いのか?
・人、物、金、時間のどれがボトルネックになっているのか?
・顧客に別の提案することで、被害を少なくできないか?
・開発チーム内だけで解決できない場合は全社問題として検討できないか?

...このような現状分析や提案事項の検討を
怠らないようにしてください。

ただあふれ出る作業に対応して乗り越えるだけでなく、
次に同じような状況を出さない為にはどうすれば良いか?

常に考えながら対応することを心がけてください。

常に考え続けることにより、
トラブルの対応方法を知ること、
トラブルを未然に防ぐ方法を知ること、
それこそが、何百時間働いたという充実感に勝るあなたの力になります。

あなたは今だけの技術者ではありません。

今後も技術者として活躍してゆく未来があるのです。

楽しく働いてゆきましょう。

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

PS

繰り返し言いますが
IT業界にデスマーチが多い訳ではありません。

近年では、
むしろ残業させないような、
休日出勤させないような仕組み作りに注力している企業が多いのです。

時代は変わって行きますね。

エンジニア研修の資料請求はこちらから

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

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

IT講師に応募する