最新記事一覧

オープンソースの普及が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サイクル

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を意識するようにしましょう。

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

最近よく聞くIoTって何のこと?

IoTとは?

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

最近よく聞く言葉に...

「IoT」

という言葉があります。

ITじゃなくてIoT?

IoTとは
いったい何なのでしょうか?

IoTって何のこと?

IoTとは

「Internet of Things」

の略で、
「モノのインターネット」のことです。

じゃあ
モノのインターネットって何?

という話になりますよね。

これまでのインターネットは
パソコン同士がネットワーク通信していましたが、

モノのインターネットでは
パソコンに限らず...

家電製品や機械などが
インターネットで通信することを言います。

IoTはビジネスから日常生活まで
幅広いシーンで活用することができます。

たとえば
自宅にある家電を
スマートフォンから操作したり、

自動販売機などで
在庫が少なくなったら
自動的に商品を発注したりと、

活用シーンはさまざまで、
これからもアイディア次第で
IoTの活用シーンはどんどん増えてゆきます。

IoTとLinuxの関係

IoTの普及には
Linuxが大きく役立っています。

アメリカの調査会社である
VDC Research Groupの調査によると、

家電製品などを
制御するために組み込むOSとして、
Linuxを活用する企業が増えています。

まぁ、そりゃそうですね。
一個一個の家電に有料OS入れる訳には
いきません。

Linuxの活用は
2012年には市場シェアの56.2%でしたが、

2017年には64.7%にまで
増えるであろうと予測しています。

このLinuxシェアの増加の背景には
IoTの普及があります。

IoTの急伸が、
機械に組み込むOSとして、

従来の組み込みOSから
Linuxに移行することを加速させているのです。

誰でも入手できる、
オープンソースで無償であるLinuxを、

IoTの活用において、
第一の選択肢となる企業が増えています。

個人でもできるIoT

IoTの活用は
企業でないとできないのでしょうか?

いえ、そんなことはありません。

その気になれば
個人でも少しの出費で
IoTの環境を作ることができます。

ちょっとIoTをやってみたい!

という方向けに...

「Raspberry Pi(ラズベリーパイ)」

というコンピューターが売られています。

手のひらサイズで、
5,000円もあれば買えてしまいます。

小さいけれど性能は高く、
ひと昔前のコンピューターと同じ性能です。

温度や気圧などの
さまざまなセンサーや、
カメラなどのUSB機器が接続できます。

実はこれ、
Linuxベースのコンピューターなのです。

Raspberry Piを使って
自宅のペットを監視するカメラや、

音声で自宅のドアの開閉や
照明のON/OFFを制御するなど、
IoTを活用した環境が作れます。

もちろん、
ある程度の知識は必要ですが、
興味のある方はチェックしてみてください。

Linuxはエンジニアの標準スキル

IoTは世界的に注目されており、
今後もますます広がってゆく分野です。

大手CPUメーカーであるIntelは
IoTのための標準機能の提供を予定しており、

そこに
Linuxの普及促進機関である
LinuxFoundationが全面協力しています。

IoTの世界的な普及は確実であり、
IoTにおけるLinuxの活用も確実に広がります。

ソフトウェアエンジニアでも
コンピューターの小型化によって、

Raspberry Piのような
小さなコンピューターで
動作するソフトを開発する機会は増えるでしょう。

どのようなエンジニアでも
あなたの前には必ずLinuxが存在するのです。

Linuxはこれからの時代、
エンジニアとしての標準スキルなのです。

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

PS

このIoTの活用には
以前お話ししたIPv6の技術が必要不可欠です。

数多くのモノがインターネットするので
それぞれのモノにIPアドレスが必要となります。

膨大な数のIPアドレスを管理できる
IPv6の技術があってこそIoTは実現します。

インターネットは
新しい時代に入りつつあるのです。

Linuxとネットワークの専門スクール リスキルテクノロジー

エンジニアのキャリアプランを実現するために大切なこと

エンジニアのキャリア

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

エンジニアとして活躍する上で

「キャリアプラン」

...をしっかり持つことが大切です。

そして
キャリアプランは持つだけでなく、
実現させることも重要です。

今回は

「キャリアプランを実現するためのポイント」

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

キャリアプランを意識することが必要

入社1年はプログラマー。

入社2~3年はSE。

入社4年目以降で上級SE...。

昔の企業では
社員のキャリアプランを
企業が設定してくれていました。

なんとか仕事に
しがみついてさえいれば、

会社が敷いた
キャリアプランというレールに乗って
活躍できるという保証(?)がありました。

しかし、
今はどんな大企業でも
いつ倒産するかわからない時代です。

企業が設定したキャリアプランは
ほとんど意味がなくなっています。

また、
今の企業のほとんどは、

「自分はこうなりたい!」

...という主体的な
キャリアプランを持つ方を求めています。

エンジニアにとって
キャリアプランをしっかり意識することは、

IT業界で活躍するためには
必要な意識のひとつです。

年齢と案件

あるエンジニアの話をご紹介しましょう。

そのエンジニアは50代前半で
小さなSIerに15年以上勤めていました。

15年選手ともなると
エンジニアとしてもベテランの域に入りますが、

どういう訳か
参加できる開発案件がなくなってきました。

その理由は、

年齢とスキルがマッチしない

...ということでした。

エンジニアは
ある程度のキャリアを積むと、

上流工程のスキルや
マネジメントスキルなどが求められます。

しかしその方は、
会社から紹介された
プログラミングやテストの案件など

フェーズの限られた
短期的な開発案件にばかり参加しており、

自分が思い描いていた、

「マネジメント系のスキルを磨く」

...というキャリアプランを
実現することができなかったのです。

仕事をこなすのに精一杯で、
何もできなかったという例ですね。

そういった仕事ばかり取る会社にも
原因があるかとは思いますが、

仕事を理由に
キャリアプランを実践できなかった
エンジニアにも原因はあります。

仕事をしながら
キャリアプランを実践するのは大変ですが、

毎日少しずつでも、
キャリアプランの実現のために何かをすることで、
将来に大きな差が付くこともあるのです。

未経験から業界に入る場合

未経験から業界に入る場合にも注意が必要です。

IT業界は建設業界などと同じように、
ピラミッド構造で成り立っています。

元請け、一次請け、二次請けと仕事が
流れる構図になっているということです。

はじめに働く階層により、その後のキャリパスが大きく変わるのが
ピラミッド構造の特徴です。

「初心者歓迎」「未経験者OK」という求人はたくさんありますが、
その企業はどの階層でしょうか?

もし、成長していいエンジニアになりたいと思っているのであれば、
かつ新卒でないのであればある程度のスキルを持った上で、
入らなければパーツを作る作業を繰り返すだけになってしまいます。

キャリアプランを描くためには?

キャリアプランを
描くにあたって大切なことは、

「どんな自分になりたいのか?」

ということを強く意識することです。

エンジニアと言っても
さまざまな職種があるので
具体的なことはここでは話しませんが、

「なりたい自分」

...を意識することで
あなたの中に目的意識が生まれます。

そして次に、
なりたい自分になるために、

・今のあなたでもできること
・今のあなたではできないこと

...をリストアップしてください。

今のあなたでもできることは、
キャリアプランを実現するために
必要なものを持っているということです。

必要であれば
既に持っているスキルなどを
伸ばしてゆけるようにしましょう。

そして、
今のあなたではできないことは、
キャリアプラン実現のために必要なことです。

できないことを
できるようにするために、

どのようなことをすれば良いのか?

それを考えて実践しましょう。

既に持っているスキルは
更にスキルを伸ばせるように、

持っていないスキルについては、
どのようにすれば身に付けられるか、

常に自分を分析して、
なりたい自分になるために
必要なことを見極めることが大切です。

あなたが思い描いている
キャリアプランを実現した人がいたなら、
その人に相談してみるのもひとつの方法です。

そこから
自分では気が付かなかった
新しい視点が発見できるかも知れませんね。

学び続ける姿勢、前に進もうとする姿勢が大切

また、
キャリアプラン実現のためには、
たとえどんなに忙しくても
何かを学ぶ姿勢は忘れないようにしてください。

新人エンジニアの頃は
毎日が学びの連続で得る物も多いですが、

数年経つと
学ぼうとしなくなる
エンジニアが増えるのも事実です。

毎日数分でもかまいませんので、
目標のために進み続けることが大切です。

そして、
キャリアプランは
変更してもいいという事も覚えておいてください。

IT業界では
毎日新しい技術が生まれ、
新しい職種が次々に生まれています。

状況に応じて
なりたい自分が変わることもありますし、

最初考えていたキャリアが
数年後には需要が低いことも考えられます。

ですので、
キャリアは柔軟に考えるようにしてください。

大切なのは
学び続ける姿勢や、
前に進もうとする姿勢です。

その姿勢を持ち続けることができれば
数十年後も活躍できるエンジニアになれるのです。

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

PS

スクールで学ぶことは
キャリアプラン実現のために有効な手段です。

あなたのキャリアプランの実現をサポートします。

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

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

ip v6とは

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エンジニアの未来

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」

...があります。

U.S.News
[URL]http://money.usnews.com/careers/best-jobs/rankings/the-100-best-jobs
usnews

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

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

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

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

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

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

...という点です。

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

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

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

Dice.com
[URL] http://marketing.dice.com/pdf/LinuxJobsReport_2014.pdf

demand

これによると
企業の採用担当者の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)

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

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

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

var

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

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

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

変数の場合は、
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つの配列に複数のデータを入れることができます。

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

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

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

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

array

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

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

例えば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プログラミングを勉強するならLAプログラマースクール

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

データセンター写真

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業界にデスマーチが多い訳ではありません。

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

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

エンジニア専門スクールの資料請求はこちらから

プロトコルとネットワークシステムの基本的な概念とは

プロトコルとは

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

ネットワークにおいて
コンピューター同士が通信する際、
取り決められた規格によって通信する必要があります。

その規約を「プロトコル」と言い
コンピューター通信において鍵となる規約です。

今回はプロトコルと通信の基本をご紹介しましょう。

そもそもプロトコルとは?

人と人が会話する際、
実際にはさまざまな規約の上で
会話が成り立っています。

まず会話する側は...

(1)会話内容や話題を決める
(2)言葉のイントネーションで感情を加える
(3)文法的な表現内容を決める
(4)使用する言語を選ぶ
(5)実際に発声して言語を伝える

...という手順で相手に話します。

そして話しかけられた側は...

(1)耳から言語を聞きとれたか
(2)言語を正しく理解できたか
(3)表現方法を理解できたか
(4)イントネーションから感情が伝わったか
(5)会話内容、話題を正確に理解できたか

...という手順で話を受け取ります。

人と人の会話であれば、
多少言葉が聞き取りにくくても
ニュアンスが伝われば会話が成立しますが、
コンピューターではそうはゆきません。

コンピューター同士の会話(通信)では
プロトコルによって取り決められた方法で
通信を行う必要があります。

通信プロトコルは
ISO(国際標準化機構)やITU-T(国際電気通信連合)など
いくつかの標準化期間において定められています。

これらで定められていない
プロトコルを独自に作成することも可能ですが、
基本的に受け側がそのプロトコルを理解できなければ
通信は成り立ちません。

ほとんどのネットワークでは
このような標準化機関が定めたプロトコルを用いて
通信が成り立っているのです。

OSI参照モデルとは?
ネットワークシステムの基本的概念

OSI参照モデルとは
ISOによって定められた通信機能を分類化した、
ネットワークシステムの基本的な概念。

プロトコルはOSI参照モデルに則って作成されるため、
異なる機器やメーカーのコンピューター同士でも通信できるのです。

OSI参照モデルは一見すると複雑です。

ですが、
先ほどの会話の例と同じ様に考えれば
理解することは可能です。

できるだけ解りやすく説明しましょう。

OSI参照モデル

OSI参照モデルは
7つの層(レイヤー)に分かれており、
7~5層を上位層、4~1層を下位層と言い、
各層で取り扱うプロトコルはおおよそ定められています。

それぞれの層の役割は以下の通りです。

・第7層:アプリケーション層

最も上位に位置するこの層では、
ユーザーが使用するアプリケーションの動作を下位の層に渡したり、
相手から受け取ったデータを
アプリケーションに表示したりする役割を持ちます。

例えば...

・送信側がファイルを送信し、
 受信側がそのファイルを正しく受け取って
 アプリケーションで開ける。

・送信側が「こんにちは」と入力し、
 受信側が自分のコンピューターで受信し
 「こんにちは」と表示させる。

...などです。

送信側が送信する内容によって
受信側でどのようなアプリケーションで
動作をさせるのかといった情報を渡す役割があります。

・第6層:プレゼンテーション層

プレゼンテーション層では
コンピューターで通信しやすいように
通信したいデータの表現形式を変換します。

文字コードやファイル形式などを識別し、
「0110001110」といったビット化したデータに変換して
下位の層にデータを渡します。

受信側はビット化されたデータを受け取り、
文字コードやファイル形式などといった情報を
上位層であるアプリケーション層に渡します。

・第5層:セッション層

セッション層では
プレゼンテーション層でビット化されたデータを送信します。

受信側では逆に
ビット化されたデータをプレゼンテーション層に渡します。

それ以外にも、
相手側コンピューターとの接続(コネクション)の確立や、
送受信における通信開始と終了のタイミングを管理する役割があります。

・第4層:トランスポート層

トランスポート層では
実際に通信を行っている際に
伝送エラーが発生しているかどうかを管理します。

データはパケットと呼ばれる単位で
分割された状態で送信されるのですが...

このパケットを送信する際、
通信エラーが発生してパケットが欠けてしまうと
受信側に正しい内容が伝わりません。

このためトランスポート層では、
パケット送信エラーがあるかどうかを監視しており...

送信エラーが発生している場合は
送信側にデータ再送の要求を行う事によって、
正しくデータを同期できる役割を持っているのです。

・第3層:ネットワーク層

ネットワーク層では
異なるネットワークでも通信できるように
IPアドレスによってデータの送信先を識別します。

トランスポート層で送信する
パケットにヘッダー(宛先情報のようなもの)を付与し、
パケットヘッダーに送信先IPアドレスを設定。

ネットワークでは
ルーターによってデータを送信する経路を特定し、
IPアドレスで指定されたコンピューターにデータを届けますが、
ルーターはこのネットワーク層で送信経路を識別するのです。

なお、受信側では、
受け取ったパケットからヘッダー情報を削除して
上位階層にパケットを渡します。

・第2層:データリンク層

実際のネットワークでは
複数のルーターや通信機器により構成されていますが...

データリンク層ではデータを送信する際、
次に通信する必要がある通信機器を管理する機能を持ちます。

パケットヘッダーに加えて、
フレームヘッダーと呼ばれるヘッダーが付与され
次にパケットを送信する通信機器などの情報が管理されるのです。

・第1層:物理層

物理層では文字通り
通信に必要となる物理的な面を管理します。

データリンク層から受けとった
ビットデータを電気信号に変換したり、
受信した電気信号をビットデータに変換したり機能があります。

他にも、ケーブルの形状や
コネクタに関する情報も管理しています。

OSI参照モデルに則った
ファイル送受信のイメージは以下の様になります。

ファイル送受信のイメージ

イメージできましたでしょうか?

TCP/IPモデルとは?
インターネットの普及により広がった概念

OSI参照モデル以外にも、
TCP/IPモデルというネットワークシステム概念もあります。

OSI参照モデルがISOにより定められたのに対し、
TCP/IPモデルはアメリカ国防総省が作成したモデルであり...

仮に戦争が起きたとしても存続できるネットワーク設計を!

...という思想の元に作成されました。

TCP/IPモデル

OSI参照モデルが7層あるのに対し、
TCP/IPモデルは以下の4層で構成されています。

・第4層:アプリケーション層
・第3層:トランスポート層
・第2層:インターネット層
・第1層:ネットワーク・インターフェース層

インターネットの普及により広がり、
実装面で優れていることから現在はこちらのモデルが主流。

しかし、TCP/IPモデルは
OSI参照モデルの概念をベースとしており、
各層の役割はOSI参照モデルとほぼ同等です。

ここではOSI参照モデルとTCP/IPモデルの対比図のみ掲載します。

プロトコルや通信の仕組みを知ることは
セキュリティの必須条件

プロトコルやOSI参照モデル、
そしてTCP/IPモデルを紹介しましたが、いかがでしたか?

ややこしく思えますが、
基本的にはコンピューターの通信は
冒頭で説明した人間同士の会話とそれほど変わりありません。

今回、プロトコルや
このOSI参照モデルなどを説明した目的は...

「ネットワークセキュリティにおいて必要な知識」

...であるからなのです。

コンピューターでは
さまざまなサービスが、
さまざまなプロトコルを用いて通信を行いますが...

通信を行う上で、
通信を常に許可しているプロトコルがあると
ネットワークセキュリティ的に問題が発生する場合も。

例えばファイル転送する必要がない場合、
サーバーやネットワーク設定でFTPが有効になっていると、
悪意あるユーザーからウィルスが送信される場合もあります。

また実際にコンピューターを
遠隔操作できるTELNETサービスなどが動いていると
サーバーを不正に操作される可能性もあるのです。

ルーターでは
パケットフィルタリングという機能を使用して
特定のプロトコルの通信許可/通信拒否という設定を行う事ができます。

Linuxでも
iptablesというコマンドを使用することにより、
パケットフィルタリングの設定を行うことができます。

このパケットフィルタリングを行うには、プロトコルの知識は必須。

サーバーやネットワークで
使用するサービスやプロトコルを制限することにより
セキュリティ性の高い、堅牢なシステムを築くことができるのです。

プロトコルやネットワークの仕組みを知ることは
ユーザーの資産や悪意あるユーザーからシステムを守ることに繋がります。

サーバーエンジニアや
ネットワークエンジニアを目指す方は、
これらセキュリティの基本事項をしっかり覚えておいてください。

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

PS

当校のLinux/CCNA系のコースでは
セキュリティに関する実践的な講義を取り入れております。

セキュリティ対策は
全てのシステムにおいて必要な分野であり、
ノウハウを知るエンジニアはどの企業も欲しがる人材。

そんな人材を目指すのであれば、ぜひ資料請求を。

ネットワークのエンジニアなるならリスキルテクノロジー

トータル的に開発に携われる パッケージベンダーの魅力とは?

パッケージベンダーとは

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

IT未経験の方には、
どのような企業に就職・転職して
どのように活躍したいかを試案されている方が多くいらっしゃいます。

IT系企業と言えども
企業によっては扱う業種はさまざま。

一般的な企業と同じように
IT系企業にも取り扱う内容により業種があります。

IT活用シーンの多様化により、
その種類は年々増えて来ているのが現状。

今回は数ある業種の中から...

「パッケージベンダー」

...についてご紹介しましょう。

パッケージベンダーとは?
パッケージシステムの開発・運用が主な業務

パッケージベンダーとは
パッケージシステムを開発・販売する企業を意味します。

パッケージシステムとは
特定の業種や業務で汎用的に使用可能な
アプリケーションのこと。

家電量販店の店頭などで見かける
会計ソフトやはがき作成ソフトなど
一般的なユーザーに使用されるものから...

企業の営業担当が売り込むような
数百万円以上する業務用途で使用するソフトまで、
世の中には多種多様なパッケージシステムが存在します。

業務用途のパッケージシステムとしては、
人事、会計など企業業務に必要な機能を
統合管理するERP(統合業務パッケージ)が有名。

他にも特定の業務に特化した...

・タクシー配送管理システム
・浄化槽管理システム
・介護支援システム
・ホテルフロント支援システム

...など、数え上げるとキリがありません。

パッケージシステムは
汎用的に使用できるように開発されているシステムです。

ですので、そのまま使用する場合は
オリジナルのシステム開発をオーダーするよりは安価に導入できます。

しかし、
導入企業の希望により、
機能をカスタマイズする場合にはカスタマイズ費用が必要。

店頭で販売しているような
ツール系パッケージシステムは
カスタマイズできない事が多いですが、
企業向けのパッケージシステムはカスタマイズするケースがほとんど。

カスタマイズ費用が発生するとしても
オリジナルでソフトを作成するよりは安い費用での開発が可能です。

また、パッケージシステムという
ベースとなるシステムがあらかじめ出来上がっている為、
開発期間を短縮でき、短期間で導入できるというメリットもあります。

デメリットとしては、
ある程度決められた機能しかないので、
ユーザーがパッケージシステムに合わせないといけないケースがあったり、
パッケージの改修・保守は開発元ベンダーに依存せざるを得ないという点です。

幅広い業務内容が特徴
開発だけでなくネットワークやサポート業務も

あなたがパッケージ開発を行っている
IT系企業で働くことになったとしましょう。

主な業務内容はパッケージシステムの
カスタマイズやバージョンアップに関する事がメインとなります。

企業業務で使用するパッケージシステムの場合、
カスタマイズしないでパッケージシステムを導入する例はほとんどありません。

どのような業務でも
その企業独特の運用方法があり、
ユーザーからのカスタマイズ要望があれば対応する必要があります。

また、パッケージシステムを使用しているユーザーから...

「こういう点を改良してほしい」

「こんな機能が欲しい」

...と、基本機能に関する改良要望が多くあった場合には、
次のバージョンアップの際の改良点として修正対応を行います。

パッケージベンダーにもよりますが
年1回の定期バージョンアップを行っている企業もあり、
そのような企業では毎年、次期バージョンに向けての開発が発生します。

また、
パッケージベンダーに必要とされるIT技術者は
プログラマやシステムエンジニアだけではありません。

ベンダーによっては
自社でデータセンターを保有、
または契約データセンターでサーバーを管理している企業も。

そのようなベンダーの場合
ネットワーク設定もパッケージベンダーが行う為、
ネットワーク技術者が活躍できる場があるのです。

そしてもう一つ大切なのは
販売したパッケージシステムに対するサポート業務。

ほとんどのパッケージベンダーの場合は
サポート専用の部署を設けていますが、
小規模ベンダーの場合は開発者が兼務するケースもあります。

ユーザーの声には耳を澄ませてください。

サポートで挙がる声を通じて次の機能改良に繋がり、
新しいオプション機能として販売するチャンスも発生するのです。

パッケージベンダーの技術者に求められるもの
仕様把握とコミュニケーション能力は必須

パッケージ開発技術者として
求められるスキルは多々あります。

まずは自社が開発している
パッケージシステムの仕様を把握すること。
パッケージ開発技術者になった場合、これが最優先事項です。

ERPなどといった
大規模なパッケージシステムの場合は...

まずは会計、次に原価管理、人事、営業管理…

...と、徐々にマスターしてゆかないと、
なかなか難しいのも現状。

それでもできるだけ
まずは仕様を把握しないといけないという理由としては、
自社が開発しているシステムの仕様を知らないと
ユーザーと話ができない為です。

パッケージベンダーは
最初はパッケージシステムのカスタマイズ業務が主業務であっても、
後々キャリアアップしてゆくに従って、ユーザーと話をする機会が多い業種。

見込み営業と言って、
システムを導入してくれる可能性のある企業に
営業担当と同行して技術的な質疑応答を行う機会もあります。

その時に...

「いや~、その機能はまだよく知らないのですよ」

...というのでは、ビジネスチャンスを逃してしまいます。

実際には、もし不明な点があっても...

「持ち帰って調査の後、ご返答させて頂きます」

...という対応で多くのユーザーは納得してくださいますが...

できればその場で返答して、
ユーザーに対する心象を良くしておきたいところです。

そしてもうひとつ必要なのがコミュニケーション能力。

先ほどの話でも、
ユーザーと話す機会が多いという事を述べましたが...

見込み営業以外にもユーザーと機能改修の話をしたり、
サポートの為に現地に赴いてユーザーと相談しながら対応したりと、
ユーザーとコミュニケーションをとりながら業務を遂行することが多いです。

他にも、
新しいパッケージを開発した時や、
システムをバージョンアップした時には、
プレスリリースイベントやバージョンアップ内容の説明会をする企業もあります。

そういったイベントがあるのも
パッケージベンダーならではの特徴で、
イベント会場に行ってユーザーからの技術的な質疑応答を行ったり、
バージョンアップ内容のプレゼンテーションを行ったりするケースもあります。

もちろん、入社当初から
いきなりそのような業務を行うケースは少ないですが、
ゆくゆくはそのような業務を行う事があるということを覚えておいてください。

独特の苦労点もある業種だが
パッケージ開発技術者ならではの醍醐味も!

パッケージベンダーにも独特の苦労はあります。

パッケージシステムの特徴として
短期間での導入が可能という点が挙げられますが...

カスタマイズ要望によっては、
大幅にプログラム修正を改修しないといけない場合もあるのです。

既にベースが出来上がっているシステムですので
改修することによって他のプログラムに影響が出ないかなど、
パッケージシステムとしての影響調査や確認に時間がかかるケースも。

既にバランスが取れているシステムに対し
そのバランスを変えようとしてカスタマイズする訳ですから
細心の注意をしつつ、カスタマイズ対応を行わなければなりません。

また、法改正などがあった場合の対応も必要です。

最近の話で言えば、
消費税の段階的導入が発表された時点で
それに対応可能なシステム変更を行う必要がありました。

あるERPベンダーの話によると...

法改正対応は月々のサポート費用で対応しているが、
さすがに今回の段階的導入は影響範囲が大きすぎたので
今回に限っては、若干費用を頂戴した上でご対応させてもらった。

...という例も。

法改正の内容にもよりますが、
出来る限り柔軟にカスタマイズできる様な
パッケージシステムを設計するという工夫も必要です。

他にもユーザー別に
どのようなカスタマイズを行ったかを管理する必要も。

ユーザー毎に導入システムの
バージョン管理やカスタマイズ内容の管理を行い...

万一システムに不具合が発生した際には、
該当ユーザーに不具合修正を行う必要があるか、
影響度はどれくらいかを判断した上で対応を行わなければなりません。

さまざまな苦労点があるとは言え、
パッケージベンダーにおける開発業務には、
そういった苦労を払拭できる程の醍醐味があります。

それは、上流工程から下流工程まで一貫して開発に携われる点。

開発工程やテスト工程のみを下請けする業務ではなく...

・ユーザー折衝
・要件定義
・設計、開発、テスト
・リリース
・運用サポート

...と、一連の開発の流れを経験できる点は技術者にとって大きな経験。

そして長年対応すればするほど
パッケージ仕様に精通し、経験ユーザー数も増えるため...

新しくシステムを導入するユーザーに対しては、
業務コンサルタント的な視点からさまざまなアドバイスをすることも可能。

「トータル的にシステム開発に携わりたい!」

「ゆくゆくは業務コンサルティングに挑戦したい!」

...という方には、パッケージベンダーはオススメです。

もちろん、
パッケージベンダーでなければ
上流から下流までの開発業務に携われない、
コンサルタントになれないという訳ではありません。

チャンスというものは自分で掴むものです。

しかし残念ながら、
ある程度環境に左右されてしまうというのも現状。

IT技術を身に着けた後、
どのような技術者になりたいか、
どのようなキャリアパスを描いてゆくか...

将来的な事も検討して就・転職活動を行い、
あなたが活躍したい企業(環境)において、
あなたの「なりたい!やりたい!」が可能なのかどうかを見極めてください。

あなたが描く未来が叶えられることを
最優先にして行動しましょう。

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

PS

未経験者の方は...

「まずはIT技術者になる!」

...という想いが強いのが実状なのですが...

「どんな技術者になりたいか?」

今のうちから、
そのことを自問自答するようにしてください。

未経験だから
わからないことも多いと思われますが、

当校ではあなたの...

「なりたい!」

...をサポートする個別ガイダンスを随時受け付けています。

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

セキュリティの基本 ポートとポートスキャンとは?

ポートとポートスキャン

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

あなたが住む家に戸締りが必要なように、
システムにも戸締りが必要です。

システムのセキュリティには
さまざまな方法がありますが...

今回はセキュリティの基礎、
ポートとポートスキャンについてお話しします。

ポート=ネットワーク通信の為のゲート

飛行場をイメージしてください。

○○発羽田便の飛行機は5番ゲート、
△△発成田便の飛行機は15番ゲートというように
飛行機は着陸するゲートが決められています。

決めておかないと
飛行場は混乱し、事故にも繋がりかねません。

これと同じことが
システムにも当てはまります。

インターネット等のネットワークにおいては、
TCP/IPという通信プロトコルによって通信しますが...

通信時に使用するサービスによって、
使用できるポートが決められています。

代表的なポートとサービスを見てみましょう。

ポート番号表

このように、ポート番号ごとに
使用できるサービスが割り当てられています。

なお、TCP/UDPと言う列がありますが...

TCP(Transmission Control Protocol)とは
データ送受信の際に相手とコネクションを確立した
信頼性の高い通信プロトコルのこと。

UDP(User Datagram Protocol)とは
相手とのコネクションを確立せずに通信する
信頼性を確保しない通信プロトコルのことです。

この図の例で見ると、
21番ポートのFTPではTCP方式のみ使用しますが...

80番ポートのHTTPでは、
TCP方式もUDP方式も使用可能という意味です。

通信方式が少し違うという程度に覚えておいてください。

使用できるポートの数とその種類

コンピュータが使用するポートは
0番~65535番まで存在しており、
番号帯によって既にサービスで予約済のポートや、
自由に使用できるポートなど分かれています。

・0番~1023番:一般的なポート番号
(WELL KNOWN PORT NUMBERS)

一般で使用される主要なポート番号で、
IANA(Internet Assigned Numbers Authority)という
インターネットに関する番号を管理する組織によって
管理されている番号帯。

使用目的が定められたポート番号で、
先ほどの図で出たポートは
全てこのWELL KNOWN PORTにあたります。

・1024番~49151番:登録済ポート番号
(REGISTERED PORT NUMBERS)

IANAが登録を受けて公開しているポート番号帯。

企業が作成した
特定のアプリケーションで使用されるポートが
多く存在します。

・49152番~65535番:動的・プライベートポート番号
(DYNAMIC AND/OR PRIVATE PORTS)

ユーザーが自由に使用できる番号帯。

業務アプリケーションなどで使用する場合や、
一時的なポート使用を行う際に使用されるポートです。

ポートスキャンとは?
悪意あるユーザーが最初に行う行為

最近メディアでも
顧客情報の流出事件や
システムのハッキング・クラッキングという
ニュースが多く見られます。

このような事件は
内部の人間の手引きによる事例もありますが、
外部からの不正な接続により発生する事件も多くあります。

悪意のあるユーザーが
外部からシステムに接続する際、
まず初めに行われるのは「ポートスキャン」です。

このポートスキャンとは
サーバーにどんなサービスが実行されているかを
確認する方法です。

空港の例で言えば...

1番ゲート:閉鎖中
2番ゲート:解放中(警備員なし)
3番ゲート:解放中(警備員あり)

...と言うように、空いている場所を特定し、
2番ゲートのセキュリティが甘ければ、そこから侵入を企てます。

コンピュータの場合も同様で、
悪意あるユーザーは開いているポートが見つかると、
そのポートを通じて接続を試みます。

ユーザーIDとパスワードが
容易に想像できるようなセキュリティの甘さや、
そのサービスのセキュリティホール(不具合やバグ)がある場合、
接続される危険性が高まるのです。

ポートスキャンは特別なソフトではなく、
Linuxであればnmapというコマンドで実行できます。

実行例を見てみましょう。

nmap_example

PORT(ポート番号)、
STATE(状態)、
SERVICE(サービス)の項目があり、
ポートの状態とサービスが一覧表示されます。

STARE(状態)が
openとなっているポートは解放されており、
closedとなっているポートは閉鎖されている状態です。

この例で言えば
23番ポートのTELNETがopen状態なのが危険(図①)。

悪意あるユーザーが
セキュアな接続を行わないTELNETで接続し、
ユーザーIDやパスワードが盗まれると
サーバーが乗っ取られる可能性もあります。

21番ポートのFTPサービスがopenなのも要注意(図②)。

FTPには匿名接続(anonymous FTP)できる機能があり
匿名接続可能なサーバーであれば誰でもファイル転送できるため
ウイルスファイルを送られる可能性もあります。

あと、念のため...

勘違いしないで頂きたいのですが、
nmapはハッキング・クラッキングの為のコマンドではなく、
あくまでシステムのセキュリティチェックを行う管理用ツールです。

それが悪用されるケースもあるということですね。

必要ないポートは「戸締り」しておく事が
基本中の基本!

悪意あるユーザーから
システムを守るための方法はいくつかありますが、
その中でも基本的な事項として...

「必要のないポートは解放しない」

...という事が挙げられます。

先ほどの例で言うと、
SSHというセキュアなリモート接続が可能なのだから
TELNETは不要といったように、
必要のないポートは解放しておく必要がありません。

使用するOSやサービスの
セキュリティホールがあるかどうかを
予め確認しておく必要もあります。

セキュリティホールがある場合は、
最新の修正プログラムを適用するなど、
システムを守るために先手を打った対策が必要。

企業などが行っている
セキュリティ診断サービスを利用するのも効果的。

第三者の視点と分析による
セキュリティ診断を受けることにより
システムにどのような弱点があるのかが判明し、
どのような対策を行う必要があるのかがわかります。

システムのセキュリティ対策には
これ以外にも非常に多くの方法があります。

それらは今後、ご紹介してゆきますが...

いずれの方法も、
ユーザーの資産を守るために必要なものであるという事を
忘れないでいてください。

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

PS

戸締りはきちんとしておかないと
泥棒に入られたらイヤですもんね。

だからといって
全てのドアや窓に3重ロックをかけるとかすると
今度は使い勝手が悪くなってしまいます。

家の戸締りもセキュリティも、
使用に適した方法で行う必要があるのです。

PPS

セキュリティに関しての知識もつく、
ネットワークエンジニア・サーバエンジニアになるならリスキルテクノロジー

柔軟なシステム変更を可能とするアジャイル開発とは?

アジャイルフロー

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

日本ではシステム開発の手法として
ウォーターフォールモデルが広く採用されています。

それ以外の手法も多々ありますが
その中で特に、近年注目されている手法として...

「アジャイル開発」

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

これは2000年頃に考案され、
アメリカなどで広く採用されている開発手法です。

今日はアジャイル開発手法の特徴などについて
サラッとみていきます。

アジャイル
柔軟な変更を可能にする開発手法の特徴とは?

アジャイル(agile)とは、
和訳すると「機敏な、俊敏な」という意味で、
その名のとおり機敏な対応を可能とする開発手法です。

開発中に仕様変更が発生した場合、
変更内容を全システムに反映させないといけませんが...

アジャイル開発では以下の特徴により
開発中にも仕様変更でも柔軟に対応することができます。

(1)ユーザーとエンジニアの共同開発チームを編成

システム開発を行う際、
ユーザーと共同の開発チームを編成します。

チーム内にユーザーがいることにより、
ユーザーニーズに迅速に対応できる体制となり、
変更が発生してもエンジニアに変更内容が伝わりやすくなるのです。

(2)開発範囲を分割

開発対象範囲全体から
開発対象となる機能に優先順位をつけ、
それらを1~4週間単位に開発可能な単位に分割します。

例えば開発対象となる機能が
機能1~機能4まで4種類あった場合...

優先度A:機能4(マスタ管理機能)
優先度B:機能3(顧客管理機能)
優先度C:機能1(案件管理機能)
優先度D:機能2(入出金管理機能)

...といった様に優先順位をつけて、
それぞれを1~4週間など、定められた期間で開発するのが特徴です。

(3)開発業務

開発は優先順位に従って進められます。
上記の例では機能4(マスタ管理機能)から開発を始め、

定められた期間内に
要件定義、製造、テスト、リリースまで全て行います。

ウォーターフォールモデルでは
最初に全機能の要件定義を行うのが特徴ですが、
アジャイルでは定められた期間に要件定義~リリースまで実施します。

ただし、開発規模が小さい場合は、
全機能をプログラムして、一気に要件定義~リリースまで行うケースも。

その場合、リリースするプログラムは
プロトタイプや初期バージョン的な扱いになり、
ユーザーの全要求を満たしているとは言えない場合が多いです。

(4)リリース後の検討

リリースしたプログラムをユーザーと共に検証し
次に行うべき対応を検討します。

この検証を行うことにより、
ユーザーからのフィードバックを素早く受けることが可能になり、
迅速な仕様変更にも対応できるのです。

アジャイル開発は(2)~(4)を
優先順位で定められた順番に繰り返し開発することが特徴であり、
これを「イテレーション(反復)」と言います。

イテレーションを実施することにより、
ユーザーからのフィードバックが反映されやすく、
柔軟な仕様変更にも対応できる開発を行う事ができるのです。

多くの種類が存在するアジャイル開発手法
そこに見られる3つの共通点とは?

アジャイル開発とひとことで言っても、
実際にはさまざまな開発手法があります。

代表的な手法としては...

・エクストリーム・プログラミング(Extreme Programming、XP)
・スクラム(Scrum)
・フィーチャー駆動型開発(Feature Driven Development、FDD)
・クリスタルファミリー(Crystal Family)
・リーンソフトウェア開発(Lean Software Development)
・適応的ソフトウェア開発(Adaptive Software Development、ASD)

...など、細かく分ければ手法はさまざま。

それらの違いも明確になっているかというと、
まぁ曖昧です。

それぞれで、
重視する内容や細かい点は異なりますが、
基本的には以下のように3つ共通点があります。

(1) イテレーションによる柔軟な変化に対応可能
(2) 短期間での開発が可能
(3) 開発範囲を分割し、小さな単位で開発を行う

そしてもうひとつ
アジャイル開発において共通しているのは
プロジェクトメンバー間のコミュニケーションを重視する点です。

制限や制限などにより開発を進めるのではなく、
チームメンバー全員の相互作用を活性化させることにより、
システム開発を高効率、高品質、低リスクで進めることが重要です。

前述のように、
チームメンバーにはユーザーも含まれています。

ユーザーからのフィードバックや
ミーティングなどといったコミュニケーションを通じて、
ユーザーが望むシステムを開発しやすいという特徴があるのです。

日本でアジャイルが普及しない3つの理由

このように一見すると
メリットの多いように見えるアジャイル開発ですが、
日本ではあまりメジャーな開発手法であるとは言えません。

IPA(独立行政法人 情報処理推進機構)が
2012年に6カ国を対象にアジャイル普及度に関する調査を行い、
各国におけるアジャイル開発の普及・成長状況を以下とおりまとめました。

アジャイルとは

欧米では既に主流な開発手法であり、
普及が拡大しているという調査結果ですが...

日本ではまだ普及が遅れており、
ようやく認知されるようになったとの結果です。

今ではアメリカでは約30%のIT企業が
アジャイルを採用するほど普及しているのですが、
アジャイル開発が日本で普及しない理由はなぜでしょうか?

(アジャイルもどきは多いですけど 苦笑)

それには主に3つの理由があります。

(1)開発チーム編成の問題

アメリカではユーザー企業にIT技術者が多く、
チーム編成しやすく、コミュニケーションを取りやすいのですが...

日本ではIT技術者のほとんどが
SIerやベンダーに所属しているため、
チーム編成を行いにくく、またコミュニケーションも取りにくい。

ユーザー企業にIT部門がある場合は
ユーザーをアジャイル開発チームに含めやすいですが...

IT部門は人不足な状態が多く
自社の通常業務で手一杯になってしまい、
ユーザーをチームに含めたとしても連携しづらいのが現状です。

(2)多重請負の問題

2次請け、3次請けといった
日本のIT業界の特徴とも言える多重請負により、
アジャイル開発の特徴である迅速・柔軟な対応が行えないことも。

ユーザーとの直接交渉が
元請のエンジニアしか行えない場合、
開発側とユーザーの意思疎通が迅速に行うことができず、
柔軟な対応を行うことができない状況になってしまいます。

また変更が発生した場合も、
元請→2次請け→3次請け...と多重構造を通して
変更を行ってもらう必要があるため、スピード感に欠けるのです。

(3)商習慣の問題

ユーザー(発注側)は開発側(受注側)よりも
立場が上という日本的な商習慣が普及を
遅らせる原因にもなっています。

欧米ではユーザーと開発側は
ビジネスパートナーとしてほぼ対等な形で取引されますが...

日本では「お客様は神様です」的な考えがあり、
ユーザーも開発チームの一員として迅速なフィードバックを可能にする
アジャイルの特徴を活かしきれないケースもあるのです。

これもサービスの質という意味では、
いい面もあるのですが、考えどころですね。。

開発手法にとらわれすぎず、
柔軟に行こう!

アジャイル開発は小規模開発向けと言われており、
日本ではスマホアプリ開発などで一部採用されていますが、

海外では小規模案件だけでなく、
MicrosoftやIBMなどといった大企業による
規模の大きな開発でも採用されている事例もあります。

最近は日本の企業にも
アジャイルを積極的に取り入れようとする動きが見られ、
日本型開発におけるアジャイル活用の方法が研究されています。

海外でもアジャイル開発の取り組みを行う企業は多く、
たとえオフショア開発(海外委託開発)であったとしても、
双方がアジャイル開発に精通している場合は柔軟な対応が可能となるのです。

日本ではウォーターフォールモデルが主流ですが、
それだけでは対応できない状況になりつつあるのは事実です。

ユーザーのスピード感が非常に高くなり、
変化する経済情勢に柔軟に対応できるような
システムの変更を行うことができるアジャイル開発は魅力的な開発手法。

ただし、
アジャイルを導入したからと言って
全てがうまく進む!という訳ではありません。

イテレーションによる開発と
ユーザーからのフィードバックは確かに良い手法ですが...

「この機能もつけたい」
「あの機能はもう少しこうしてほしい」
「その画面とこの画面を連携させて情報を表示したい」

...などというユーザーからの意見が頻発することも。

仕様が膨らみ続けて止められず、
逆に迅速な対応ができなくなってしまうケースもあります。

そして、アジャイルに精通したエンジニアが少ないのも現状。

急激にアジャイルを導入した場合、
逆にパフォーマンスが落ちるエンジニアが
発生する可能性もあります。

大切なのは...

「ユーザー、案件、納期、チーム等を考慮し、最適な方法で開発を行う」

...ということです。

あなたがもし、
開発手法を選択できる立場になったとしても...

特定の手法だけとらわれず、
それぞれの手法の良い面を組み合わせるのも良いでしょう。

アジャイルにはアジャイルの、
ウォーターフォールにはウォーターフォールの良さがあります。

エンジニアとして様々な開発経験を積んで、
どのような案件でも柔軟に対応できるノウハウを身に付けましょう。

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

PS

日本のIT業界において、アジャイルはまだ黎明期。

どのようなものか知っておくのは良い事ですが、
アジャイル開発は更に数種類に細分化されるので、
未経験の方や経験の浅い技術者が、全てを把握することは難しいです。

ウォーターフォールから勉強しましょう。
それが今のあなたにとって大切なことです。

PPS

開発手法を含めて勉強できるJavaのスクール

プロフェッショナルエンジニアとして求められる姿勢

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

「最近、終電帰宅ばかりで疲れたわ...」

知り合いのSEがぽつりと漏らしたひとこと。

あまり愚痴っぽいことを言わない人なので、
そのひとことに少し驚きました。

彼はあるプロジェクトのリーダーを
任されているようです。

軽く話を聞いてみたところ、
小規模プロジェクトの割に納期は長く、
それほど難易度の高いプロジェクトでは
なさそうなのですが...

一体、彼に何が起こったのでしょうか?

終電の理由は
すぐにギブアップするプログラマのフォロー

彼が担当する開発案件は小規模で
彼をリーダーに、プログラマが3名の計4名のチーム。

マネージャは他の案件と兼務しており
実質的に顧客折衝や進捗管理も彼が担当しています。

しかし、
ユーザーからの要件はほぼ固まっており、
彼自身もユーザー業務をよく知っているので、
それほど難易度は高くない開発案件でした。

彼が終電帰宅になる理由...

それは、
開発チームに所属するプログラマから頻発する
「少し調べればわかる程度の質問」と
「ギブアップ宣言」が原因でした。

チームにいる3名のプログラマは、
みな昨年~今年入社したばかりの新人エンジニア。

新人エンジニアでもプロ意識をしっかりと持ち、
スキル的なポテンシャルが高い人も多いのですが...

彼のチームのエンジニアの場合...

・プログラムでつまずくと、簡単なことでも調査せずにすぐ質問
・「できません」「わかりません」と、すぐにギブアップする

...というエンジニアが揃ってしまった模様。

彼はリーダーとして
解決方法をアドバイスするのですが、
結局彼らのしわ寄せがリーダーに集中して
日中に自分が担当する業務ができず、終電帰宅となるようです。

問われるプロフェッショナルエンジニアとしての姿勢

リーダーとしての彼の指導方法にも
何らかの問題がある可能性も否定はできませんが、
新人エンジニア達にも問題がありそうです。

誰もが最初はわからないことだらけ。

それはそれで、全く問題ありません。

そしてわからないからこそ、
できないことも多い。

しかし、彼らは新人とは言えプロなのです。

問題なのは、プロであるにもかかわらず...

「何が問題となって、自分が解らないのか?」

...ということを理解しようとしない姿勢にあります。

わからないことを質問するのは
全く問題がありません。

むしろ、
質問して早く問題が解決するならば
積極的に質問して開発を進める方が良いでしょう。

ただし...

1.プログラムが思う通り動かない
2.とりあえず人に聞いてみよう
3.それで動けば問題なし
4.それでもできなかったらギブアップ

...という考えであれば、プロフェッショナルの姿勢とは言えません。

単なる流用はNG
優れたノウハウをスキルアップに繋げることが大切

プログラミングの際、
インターネットなどでサンプルソースを検索して
それを参考にしてプログラミングする方も多いでしょう。

実際に他の人が作った優れたソースを参考にして、
開発業務を行ったという経験を持つエンジニアは多いです。

しかし、
優れたソースを参考にする場合、
必ず心がけておくべきことがあります。

それは...

「単なる流用ではなく、仕組みを理解する」

...ということ。

単純にサンプルをコピペして、
少し変更すれば問題は解決するかも知れません。

しかしそれでは、
常に他人のスキルに依存してしまうため、
先ほどの新人エンジニアの事例と何ら変わりないのです。

優れたサンプルソースを参考にして...

・どのような仕組で動作するのか?
・自分では解決できなかった問題はどこにあるか?

...ということを理解し、
自分のノウハウに蓄える必要があります。

優れたノウハウを自分のものにすることで、
自分自身のスキルアップにも繋がってゆきます。

単に流用して解決するエンジニアと比較すると、
将来的な技術力に大きな差がつくのです。

姿勢次第で大きな差がつく!
現状把握と分析力に加えて提案力があればベスト

エンジニアだけに限らず、
何か問題に直面した時に必要なことは...

何が原因となって問題が発生しているか?

...という現状を把握し、分析する能力です。

プログラム系に関して言えば...

・どこでどんなエラーが発生しているか
・エラー発生前の処理はどのような処理か
・関連クラスの処理や変数の内容は正常か
・引数に問題はないか

...など。

ネットワーク系で言えば...

・ルーティング設定に問題はないか
・どの機器に問題があるか
・断線や配線方法など物理的なことが原因になっていないか

...など、自分で考えられる範囲で現状把握を行います。

そして考えられる対処法を検討・実施し、
それでも原因が解決しなければ、
高スキル保有者に相談しましょう。

開発期間には限りがあります。
問題を自分だけで抱え込む時間が長すぎると、
それは開発の遅れに繋がるケースもあるのです。

そして相談する時は、
わかりません、できませんではなく...

・現状どのような事象が発生しているか
・それに対し、どのような調査を行ったか
・解決には至らないが、その調査で判明した情報

...を必ず伝えるようにしましょう。

これが...

問題発生→現状分析・調査→相談→解決

...という理想的な解決パターンです。

さらにもう一歩踏み込んで
問題を解決する為に調査・検討した、
自分なりの解決策を説明できれば申し分ありません。

簡単に言えば「回避策」の提案です。

そうすれば...

問題発生→現状分析・調査→相談・回避策の提案→検討→解決

...という流れで、自らの発案によって問題回避できることも。

プログラム言語で言えば、
言語的な仕様でどうにもならない!
という問題が発生するケースもあります。

そういう時に
回避策を提案できるエンジニアがいると重宝されます。

業務に対してどのような姿勢で臨むか?

受け身のエンジニアになるか?

それとも...

積極的な提案ができるエンジニアになるか?

姿勢の持ち方次第で、
エンジニアとして数年後に大きな差が開くのです。

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

PS

卒業した瞬間にプロとしての実力と姿勢が身に付く…

私たちのプロフェッショナルとしての姿勢です。

詳細はこちらから
エンジニアになるための専門校

アルゴリズムの基本:アルゴリズムとフローチャート

アルゴリズム

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

「アルゴリズム」

あなたがプログラムを学習中なら、
きっとどこかで一度は見たことがある言葉しょう。

このアルゴリズムは
プログラムを作成するにあたって
とても重要なことです。

が、これが実際なんなのか、
よくわかりませんよね?

そもそもアルゴリズムって何なの?

...というところからこの記事では
お伝えしたいと思います。

あなたも使ったことがあります

アルゴリズムとは、
計算方法や処理手順などのことです。

アルゴリズムという言葉を使うのは
何もコンピューターに限ったことではありません。

数学やその他の学問でも、
問題や課題を解くための処理手順として
アルゴリズムという言葉が使われています。

算数とか数学とかを勉強したことがある人なら、
だれでも一度はやっています。

例えば、
2つの整数の最大公約数を求める方法を
覚えていますか?

割り算を続け、
割り切れた時の割る数が
最大公約数になります。

euclid

これもアルゴリズムです。

最大公約数を求めるのに
いちいち数値を比較してゆくのは手間がかかります。

そこでこのような...

「効率の良い手順で処理を行う」

という手法がアルゴリズムなのです。

処理手順を表現するフローチャートとは?

プログラムで
アルゴリズムを表現するものとして...

「フローチャート」

...という図があります。

フローチャートとは
処理手順を表現するための流れ図のことです。

例として、
押しボタン信号式の交差点を渡るプログラム(?)

...のフローチャートを見てみましょう。

ちなみに信号が赤の間は
スマホを触って信号が青になるのを待ちます。

また、
赤信号が3分以上かかる場合は
別の交差点を探しに行く処理を入れましょう。

flow_example

フローチャートで表現するとこのようになります。

まずは押しボタンを押して、
信号待ちループ処理に入ります。

信号を見てみて
青信号になっていたら
交差点を渡って処理が終了。

青信号になっていなかったら
「スマホを触る」という
処理で、別の処理を呼び出します。

スマホを触る処理では
スマホで時間つぶしをするという処理が記述されています。

処理が終われば待ち時間を確認。

3分以上経っていたら
別の交差点を探す処理を行って、
このプログラムの処理は終了。

3分経っていなかったら
ループの先頭に戻って、
信号を見る処理を行うという流れです。

実はこのなかでも...

「3分以上待ったか?」

..という判断が非常に重要です。

この判断がない場合、
もし信号機が壊れていて
ずっと信号が赤のままだったとしたら、
永久に信号が青になるのを待ち続けなければいけません。

つまり、ループ処理が永久に繰り返されるのです。

この状態を「無限ループ」と呼び、
無限ループに陥ったプログラムは、
強制終了させて実行を停止するしか方法がなくなるのです。

このような無限ループを避けるため、
アルゴリズムでは「停止性」という定義があります。

停止性とは...

「プログラムは必ず終了しなければならない」

...という意味です。

アルゴリズムにおいては、
必ず終了させる処理を持たせる事が必要なのです。

だんだん難しくなって来ましたが、
無限ループ(脱出不可能ゲーム状態)が続かない様にしましょう、
ということです。

アルゴリズムを理解して効率の良いプログラムを

アルゴリズムの組み立て方によっては
プログラムの計算量を少なくし、
効率よく処理できる…つまり高速なプログラムを作れます。

プログラムを作成したとしても、
処理が遅いと使いにくいと言われるケースも。

そうならないためにも
プログラムの基本であるアルゴリズムのノウハウを
必ず押さえておく必要があります。

ベテランエンジニアになると、
仕様書を見ながらフローチャートが頭に浮かぶそうです。

これはアルゴリズムを理解し、
処理効率の良いプログラムを作成できる
ノウハウを習得しているからだと言えます。

今回はアルゴリズムの例として
ユークリッド互除法をご紹介しましたが...

プログラミングする上で役に立つ
定番とも言えるアルゴリズムはたくさんあります。

ソートや検索法などがそうですが、
それらについてはまた別の機会にご紹介しましょう。

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

PS

プログラマーを目指すなら
基本的なアルゴリズムは習得しておきましょう。

全てのアルゴリズムが
全て必要になる訳ではありませんが、
基本的なものはほとんどのシステムで使用されます。

また、処理速度を上げる為に、
自分でアルゴリズムを構築するケースも。

そのためにも、
基本はしっかりと押さえておきましょう。

アルゴリズムも勉強し、システムエンジニアになるならこちらのスクール

苦手なエンジニアが多いドキュメント制作スキル

エンジニアのドキュメント

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

IT技術者にとって必要な事。

設計スキルや
プログラミングスキルなど
直接システム開発に必要なスキルはもちろん必要です。

しかし実際のシステム開発においては、
一見するとITスキルとは直接関係がないようなスキルも必要になります。

数え上げるとキリがない程あるのですが、
まずはそのような間接的に必要となるスキルのうち...

「ドキュメントスキル」

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

多くの技術者が苦手意識を持つ
ドキュメントスキル

ドキュメントスキル!

この名を聞いただけで
嫌な顔をする技術者はかなり多いです(笑)

多くの技術者はドキュメントの作成を苦手としています。

「ドキュメント」とは資料的な文章を意味しますが、
システム開発におけるドキュメントとしては以下の種類が挙げられます。

(1)設計書

要件定義書や基本設計書、
プログラム定義書やテスト仕様書など
システムの仕様を定義するための文書群です。

上流工程で作成される為、
設計書に仕様不備や設計バグがあった場合には
プログラム作成やテスト等、下流工程に大きな影響を与えます。

(2)計画書

システムの導入スケジュールや
システム移行計画の立案などといったものから...

プロジェクトにおいて、
開発メンバーがいつ、どのタイミングで、何人必要なのかといった…

内部的な開発計画(アサイン計画と言います)など、
ユーザー向け、開発チーム内部向けなど、様々な計画書があります。

(3)提案書

ユーザーに対する新規開発の提案や、
既存システムの問題点などを解消する為の提案などを行うドキュメント。

最近では新規システムの導入検討をしている企業が
「RFP(提案依頼書)」の提示をシステム開発企業に求め傾向があります。

RFPには新規システムに必要な
ハードやソフト、サービスの内容や契約条件などを記載しており、
多くの場合は営業担当が作成しますが、SEが作成する場合もあります。

(4)ユーザーマニュアル

新システムの使い方などをまとめたマニュアルです。

システムの概要や目的に始まり、
各画面や帳票の説明、その他システムに関して
ユーザーが行わなければならない事項を手順としてまとめます。

(5)報告書

新システムの各種テスト結果の報告から、
トラブルが発生した場合のユーザーに対する報告まで、
場合によってさまざまな報告書が必要となります。

このように、システム開発において、
多くの文書を作成する必要がある事をおわかり頂けたでしょうか。

ユーザーによって求められる文書の種類は異なりますが
多くのドキュメントを作るとなると、かなりのマンパワーが必要です。

基本的にSEやPGには...

「きちんと動くシステムさえ作れば、ドキュメントは程々で良い!」

...という考えを持った人が(残念ながら)多いです。

そのためドキュメントについては
必要最小限の労力をもって作成する傾向があり...

必要最小限の労力しか費やさない為に
ドキュメントスキルが磨かれず、苦手意識を持つ人が多いのが現状です。

作成負荷を減らしたいからドキュメントを簡素化
それが逆に稼働負荷が掛かる結果を招く事も!

開発案件によっては
納期までのスケジュールが短いため...

「ドキュメント作成量をできるだけ減らしたい!」

そういった現場の声があるもの事実。

現場の声としては理解できるのですが、
ドキュメントをしっかり作成しない事が原因で、
全体的に開発稼働が余分にかかってしまうというケースもあります。

例えば、以下の様な画面設計書があるとしましょう。

顧客管理するシステムの、顧客情報を登録する画面です。
画面の下表は、設計書の説明内容になります。

顧客情報入力画面1

項目名 内容
顧客コード 顧客コードを入力します。(必須項目)
顧客名 顧客名を入力します。
  ~中略~
キャンセルボタン 登録をキャンセルし、画面を終了します。

一応、画面設計書っぽく見えなくはないですが
正直言って、この設計書を渡されたプログラマーは困惑します。

顧客コードは何ケタなのか?
顧客名は何バイトまで入力できるのか?
顧客名カナは全角なのか半角なのか?

このような確認事項が増える事により
開発時間がズルズルと遅れてしまうケースもあります。

では、先ほどの顧客情報登録画面を以下の様にしたとしましょう。

顧客情報入力画面2

~中略~

項目名 種類 属性(バイト数) 入力 内容
顧客コード テキスト 半角英数字(10) 可(必須) 顧客コードを入力する。コード体系は半角大文字英字4バイト+半角数値6バイト。入力必須項目。
顧客名 テキスト 全角文字 (40) 顧客名称を入力する。全角文字であれば全て入力可能。
キャンセルボタン ボタン - - 入力内容を破棄し、「キャンセルしますがよろしいですか?(はい/いいえ)」ダイアログを表示して「はい」が押下された場合はメニュー画面に戻る。

この状態でもプログラマーからの質問は発生するでしょうが、
先ほどの例と比べると各段に質問の量は減ります。

ドキュメントを作成するにあたり
簡素にできる部分は簡素にして構いません。

1~100まで記述すれば
ドキュメントの作成稼働だけについやされて
他の作業を行うのに支障をきたします。

ただ、「時間がないから」という理由で
本来記述しておくべき内容を書かないというのは…

あなたにとってもチーム全体にとっても、
そしてシステムにとっても良いことではありません。

ドキュメントは開発者を守るもの

IT技術者の中には...

「とりあえず動くプログラムがあれば良いのでは?」

...という発言をする方もいます。

その理由は...

「何か不明な点があればプログラムソースを見れば良い」

「ソースがその処理内容の仕様なのだから」

...という意見から出ています。

その意見にも一理ある様に見えますが、
残念ながら正しいとは言えません。

例えば部署異動などで
あなたがそのシステムの保守担当から外れたとしましょう。

後任の担当者が
あなたのレベルにまで該当システムに精通していない場合、
コードから仕様を把握しろというには、現実的に無理があるのです。

また、システムというのは
平均すると約5年間は使用する事を想定されており、
場合によっては10年以上使用されるシステムもあります。

システムに不具合らしき事象が発生した場合、
それが本当にユーザーが当初から求めていた仕様なのかどうか?

ドキュメントに記載していないと判断がつかないのです。

ユーザーはプログラムの中身までは見ません。

ユーザーはプログラムを見て
正しいかどうかを判断するのではなく、
設計書などユーザーが認証したドキュメントを見て判断します。

現在起きている不具合らしき事象が
設計書にも打ち合わせ議事録にも、
どのドキュメントにも記載されていない場合、
プログラムのバグとして扱われてしまうケースが多いです。

バグ修正は基本的に無償で行う必要があり、
またバグ修正の為のデータ修正や現地対応の費用、
ユーザーへのバグ終息報告資料の作成など、多くの稼働が発生します。

ドキュメントというのは、
何が正しいかを判断するものであり、
ユーザーに確認してもらったという覚書でもあり...

長期のシステム運用を踏まえた場合、
開発側に余計な稼働負荷を掛けない保険にも成り得るのです。

誰でも理解できるドキュメントが大原則
専門性だけでなくビジネス力も身に着ける

ドキュメントを作成するにあたり
守らないといけない大原則があります。

それは...

「誰が読んでも理解できるドキュメントを作る」

...という事です。

もちろん、
システムが扱う業界によっては
専門用語の知識が必要な場合もあり、
また基本的なITの知識も読み手には必要とされます。

ですが、
システムはひとりで作るものでもなく、
ひとりで使用するものでもありません。

設計書であれば...

プログラマーには
プログラム作成の際に作りやすいように、

ユーザーには処理内容を
わかりやすく理解してもらうための工夫が必要。

計画書であれば...

どのような計画でプロジェクトを進め、
どのタイミングでどのようなイベントが発生するのかなど
誰が見ても理解できる計画書。

提案書であれば...

提案の目的を明確にし、
費用やスケジュールなどを考慮した上で
提案内容を実現する事によるメリットが伝わりやすい様に。

ユーザーマニュアルであれば...

たとえば新人のユーザーであっても
マニュアルがあればある程度の操作ができるような
操作方法や手順が明確に記載されている、読みやすいマニュアルを。

報告書であれば...

現在発生している事象の説明に始まり、
原因と結果、影響範囲、対応内容、対応時間など
ただ報告するだけの書類ではなく、どう対処するかまで報告すること。

基本的には、
誰が読んでも理解できる内容を心がける!

これがドキュメント作成するにあたって肝心な事です。

そしてドキュメントスキルを向上させる為にもうひとつ...

ダラダラと文字だけを書き連ねる!

…といったドキュメントは作成しないようにしてください。

図やグラフなど、
視覚的に把握しやすい資料があれば、
それは読み手の印象に残りやすくなります。

直接的な関連はなくとも、
ドキュメントの印象付けとして画像を挿入するのも良いでしょう。

プレゼンテーションで使用するドキュメントであれば
アニメーション効果や動画を使用するのも効果的です。

未経験からIT企業に入社した場合、
最初はプログラム作成ばかり行うかも知れませんが...

キャリアを積んで行くに従い、
プロジェクトリーダーやプロジェクトマネージャーになると、
さまざまなドキュメントを作成する機会が確実に増えます。

ドキュメントの作成は手間も時間もかかり、
多くのIT技術者が苦手としているスキルです。

しかし、
誰もが苦手にしているスキルだからこそ、
あなたがドキュメント作成スキルを身に着ける価値があるのです。

そしてこのスキルは、
IT分野に限った事ではありません。
例えばあなたが独立して、起業するとした場合にもきっと役に立ちます。

IT技術者にはもちろん専門性が必要です。

しかし、ドキュメント作成スキルの様な、
総合的な「ビジネススキル」を磨くという事も
忘れないでください。

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

PS

ドキュメントの作成の仕方は、
ひとりではなかなか学べません。

ドキュメント制作も含めて学べるIT教育専門スクール

開発手法の基礎、ウォーターフォールモデルの特徴とは

ウォーターフォール開発

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

システム開発の手法はさまざまありますが...

「ウォーターフォールモデル」

...という開発手法がほとんどの開発で採用されています。

古くから開発手法であり
他の手法もあるにもかかわらず、現在でも主流の開発手法です。

ウォーターフォールモデルの進め方、
そしてメリットやデメリットなどについて、
少し詳しく説明しましょう。

ウォーターフォールモデルとは?
上流工程から下流工程までの特徴

ウォーターフォールモデルは
1970年に提唱されたソフトウェア開発手法。

開発を複数の工程に分け
各工程の終了時に成果物を作成することにより、
各工程における品質の確保を図ります。

ウォーターフォールという名は文字通り
「水が流れ落ちる」様に工程が進むことから名付けられており、
上流工程から下流工程まで流れる様に開発が行われます。

ウォーターフォールモデルの各工程については
当ブログでも何度かその名が登場しておりますが、
少し細かく説明しましょう。

(1)要件定義

ウォーターフォールモデルにおける最上流工程。

開発するシステム全体の機能を
ユーザーとの打ち合わせを重ねて具体化し、
開発するシステムの機能、目的、対象範囲を決定します。

システム開発を依頼するということは、
ユーザー側に「業務をもっと円滑にしたい!」など、
業務改善の為に何らかの対策をしたいという目的があるということ。

その目的の認識がズレたまま開発が進むと
下流工程に進むに従い、大きな認識違いが発生します。

どのようなシステムにしたいか?
システム化対象範囲やシステム導入によって業務がどう変わるか?

システムと業務の具体的な分析が必要となるフェーズです。

(2)基本設計

システム開発をするにあたり
要件定義フェーズで決定された事項を具体化するフェーズです。

主な設計内容としては...

・ハードウェア、データベース、ソフトウェアの選定
・データベース設計、テーブル設計
・システム、サブシステムの機能概要の設計
・インプット、アウトプット内容の決定
・データ移行・運用・セキュリティ方針の検討
・外部システムとの連携方法の検討
・システム内部で使用する区分の決定

...などが挙げられます。

データベース設計を行うことから
ある程度データ管理する項目も把握されるため、
画面や帳票などのサンプルを作成し、
ユーザーに見てもらってフィードバックする場合もあります。

(3)詳細設計

基本設計フェーズで決定された事項を
画面単位、帳票単位、プログラム単位など
より詳細に機能分割して設計するフェーズです。

主な設計内容としては...

・画面、帳票のレイアウト及び機能設計
・バッチ処理(自動実行処理)の設計
・メッセージ仕様(画面などに表示する内容)
・データベース設計(表領域、ファイルサイズなど詳細な設計)
・クラス設計などのプログラム設計
・システムで使用するコード設計
・開発規約、コーディング規約などの検討
・単体テスト仕様書の作成

...などが挙げられます。

基本設計では見えていない要件や
基本設計段階ではまだ不完全なものがあれば
詳細設計フェーズで修正を行い、仕様を確定させます。

このフェーズで作成されたドキュメント群を
「詳細設計書」と総称しますが、この詳細設計書をもって、
次の開発フェーズで実際にプログラミングが行われるのです。

(4)製造(プログラミング)

詳細設計書を元に
実際にプログラムをコーディングします。

作成する単位は画面、帳票、バッチプログラム単位ですが、
共通的に使用するプログラムがある場合は、先にそちらを作成します。

ほとんどの場合は製造と、
次のフェーズである単体テストを同時に行うケースが多いです。

(5)単体テスト

作成したプログラムに対し
単体テスト仕様書を元にテストを行います。

簡単なテストの場合はテストスクリプトを作成し
自動テストツールでのテストを行って効率化を図ります。

テスト結果で不具合があった場合は
不具合内容をプログラマに伝えて修正して再テストを実施。

全てのテスト項目が終了したら、
次の結合テストフェーズに移ります。

(6)結合テスト

各プログラムを統合し、
画面遷移やデータの受け渡しなど、
画面・プログラム・サブシステム間の連携が
正しく行われているかどうかを確認します。

具体的には業務フローを元に
実際の業務を想定したテストシナリオを作成し...

最初のインプットから
想定できる結果が正しくアウトプットされるか等のテストを実施。

単体テストでは問題なかったが、
連携方法や制御方法にバグがあった場合は
このフェーズで発見されます。

(7)総合テスト(システムテスト)

実際にユーザーの環境と同じか
それと同等の環境において行うテスト。

主に処理速度や障害発生時の処理、
実際の他システムと連携して正しく動作するかなどをテストします。

(8)運用テスト(受け入れテスト)

総合テストをパスしたシステムを
実際にユーザーに使用してもらい、
要求機能を満たしているか、操作感はどうかなどを確認してもらうフェーズ。

旧システムでインップットした内容が
新システム側でも旧システムと同じアウトプットかなども確認します。

(9)リリース

新システムを本番環境にリリースします。

リリースの方法についてはいくつかの方法がありますが、
以前ブログで書いておりますのでここでは割愛致します。

(10)運用・保守

システムの運用、保守を行うフェーズ。

実際に新システムを使用していて
不具合があった場合は速やかに修正を行ったり、

新しい機能要求が挙がった場合には
追加開発などを行ってシステムの保守を行ったりします。

少し説明が長くなりましたが、
ウォーターフォールモデルは、このような流れで進行するのです。

ウォーターフォールモデルの
メリット・デメリットとは?

ウォーターフォールモデルの
メリットとデメリットをまとめると以下の様になります。

■メリット

・計画を立てやすい

上流工程から要求機能を
詳細に落とし込む手順を踏んでゆくため、
事前に今後必要となる事項を想定しながら開発できる。

・進捗管理のしやすさ

全体を把握した上で
工程別・タスク別に管理可能なことから、
プロジェクト全体や、各開発要員の進捗管理を行いやすい。

・成果物ベースでの開発

ドキュメントなど成果物がある状態で開発を行うため、
どのような開発者でも仕様書を読めば開発する事ができる。

■デメリット

・上流工程でしか要件定義できない

要件定義や基本設計フェーズでは
ユーザーとの仕様検討を行いシステム要件を詰めますが...

仕様検討したのは「過去」の時点のものであるため、
企業のスピード感が早い場合、仕様変更が発生する可能性が高くなります。

・仕様変更時の影響

前工程の成果物をベースに開発を行いますが、
仕様変更や設計ミスなどによる成果物の変更が発生した場合...

プログラムの修正はもとより、
変更内容によってはテストのやり直しなどが発生するケースもあります。

・成果物管理の稼働負荷

成果物ありきで開発が進められるため、
ドキュメントなどの成果物の作成・修正稼働に負荷がかかるのが特徴。

ウォーターフォールモデルには、
この様なメリット、デメリットがあるのです。

ドキュメントによる品質・工程管理
しかしそれは両刃の剣にも成り得る可能性が?

ここで、メリットにもデメリットにも登場した
ウォーターフォールモデルにおける成果物(ドキュメント)管理について、
もう少し詳しくお話ししましょう。

ウォーターフォールモデルは
ドキュメントの作成量が多いことが有名です。

各開発工程の最後には
成果物として設計書やテスト結果報告書など
さまざまなドキュメントをユーザーに提示します。

提示したドキュメントを
ユーザーが承認することによって、
開発側は次の工程に進むことができるのです。

実際には納期が短く、
ドキュメントは後から提出して、
できるだけ早く工程を進めて行くというケースもありますが...

ウォーターフォールモデルは
前工程の成果物ありきで進められるので
ドキュメントがないと先々の工程に進みにくい性質を持ちます。

そして大規模なシステム程
ドキュメント量が膨大な量になる傾向があり、
その作成や管理稼働に大きな負荷がかかってしまうのです。

工程は進んだものの、
後になって要求仕様が変更された場合には
多くのドキュメントを修正する必要があります。

また、ウォーターフォールモデルの特徴として
計画の立てやすさ、進捗管理のしやすさがありますが、
これらの管理資料の作成だけでも、かなりの稼働がかかってしまいます。

代表的な管理資料としては
WBS(Work Breakdown Structure)といい、
開発プロジェクトを細かい作業項目に分割し、
誰が、何を、いつまでに対応するか、進捗率はどうかなど、
開発計画や実績を把握できる資料を作成してプロジェクト管理を行います。

しかし、
作業項目単位で作成する必要があるため
WBSを作成するだけでもかなりの稼働負荷がかかりますし...

ユーザーの都合でスケジュール変更があった場合には、
その変更内容を反映し、スケジュールを組みなおす必要が発生します。

このように、ウォーターフォールモデルでは
ドキュメントによる品質・工程管理が行われますが、
逆にドキュメントに対する稼働負荷が高いという特徴もあるのです。

多くの開発現場で採用される基礎的手法
基礎力を身に付けておけば、他の開発手法でも対応可能

ウォーターフォールモデルは
大規模開発向けの開発手法と言われています。

その理由は、
きちんと何もかも整えた状態で
プロジェクト全体や各開発者の進捗管理ができる為です。

にもかかわらず、
実際には規模の大小を問わず
ほとんどの開発案件で採用され続けている手法。

それは一体なぜなのでしょうか。

理由はいくつかあり、
長年多くの技術者がこの開発モデルを経験し
ノウハウを持っている技術者が多いというのもありますが...

もうひとつ...

「成果物と一緒に費用を請求しやすい」

...という点も挙げられます。

大規模な開発になればなるほど、
開発期間は長期にわたりますので、
全て納品してから請求・・・となると、運転資金が調達できません。

そこで採られる方法が「分割検収」という方法。

全体の見積もり金額から、
要件定義の成果物を納品したら○万円請求、
基本設計~詳細設計までの成果物を納品したら○万円請求...

...というように、フェーズの終了毎に請求を行います。

企業側は開発者に給料を支払わないといけませんので、
資金繰りもしやすいこの手法が採られるケースが多いのです。

しかし、
最近ではユーザーのスピード感は増す傾向にあり、
実際には柔軟に仕様変更を行いたいユーザーが多いのも事実。

既にご説明したとおり、
ウォーターフォールモデルには
柔軟な仕様変更を可能とするスピード感に欠けるというデメリットがあります。

そこで登場したのがアジャイルなど、
ウォーターフォールとは異なる開発手法ですが、
最近ではウォーターフォールとアジャイルを組み合わせるような
ハイブリッド型と呼ばれる開発手法も存在します。

アジャイルやハイブリッド型については
また別の機会にご紹介しますが…

ウォーターフォールモデルは
開発手法の「基礎」とも言えるものですので、
各フェーズで行う作業内容は把握しておきましょう。

他の開発手法を見ても、
開発の進め方は異なりますが、
内容としてはウォーターフォールモデルの
各フェーズを分解・再構築して手順を変えたものが多いです。

ウォーターフォールモデルは、
IT技術者になれば、必ず1度は経験する開発手法。

開発の基礎。しっかり習得しておきましょう。

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

PS

ウォーターフォール型を実践できる
開発演習を含んだコースが多数あります。

プログラミングのスクールならリスキルテクノロジー

エンジニアとしての視野を広めるには?

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

視野の狭い技術者はとてもとても厄介です。

前は、こうしていたから・・・
この前携わった業界ではこれが常識だったから・・・
この方法が一番いいに決まっているだろ!・・・

などなど。

こういった技術者にならないために、
必要なことがあります。

さまざまなユーザーと話すことで
技術者としての視野は広がる

IT技術者と言っても、その役割はさまざまです。

プログラマーやシステムエンジニア、
プロジェクトリーダーやプロジェクトマネージャなど
それぞれに役割があり、扱う業務内容も異なってきます。

小さな企業や個人事業主のIT技術者の場合は、
それらの役割をほぼ全てこなさないといけません。

ですが、ほとんどの技術者は、
プログラマーから始まり、徐々にステップアップします。

そしてステップアップに従って、
直接ユーザーと話す機会は確実に増えてゆきます。

打ち合わせなどでは
同年代の担当者や管理職クラスの方、
企業の幹部クラスの方々や経営者と直接話すことも。

システム開発の際はさまざまな方と話しをしますが、

業界は違っていても企業課題としている内容は
同じであったり、

業界が同じでも企業課題としている内容が
全く別ものであったりします。

生の情報は実際に話す事により得られます。

さまざまなユーザーとの話しを重ね、
生の情報を知る事により、
IT技術者の視野は広がってゆくのです。

異業界の開発案件は視野を広めるチャンス

前の業界の常識を持ち込むのはやめましょう。

新しい業界には違った常識があり、
ノウハウがあります。

(これを、面倒だな、ではなくチャンスだと考えるべきです)

幅広い業界のシステム開発を行うIT技術者の場合、
それまで経験してきた開発案件によって、強みや弱みはあります。

たとえば、
あなたが金融系システムは詳しくなったけど、
それ以外はあまり経験がない技術者だとしましょう。

会社の都合により開発要員がどうしても
確保できない。

急きょ物流系システムの
プロジェクトリーダーを任されとしたら...

物流系業務については
ほとんど業務知識がないため、
かなり大変な思いをするでしょう。

物流業界や業界用語を勉強し、
システム開発を行わなければいけません。

しかし、
書籍などからある程度の情報は知る事ができても、
最終的にはユーザーの業務内容を知る事が必須要件。

何度も打ち合わせを重ねた上で、
ユーザー業務のノウハウを知る必要があるのです。

知らない事が多すぎて、
場合によってはユーザーに頭を下げて、
物流業界の基本的な事について教えて頂くこともあります。

「そんな事も知らなくて大丈夫か?」

...とお叱りをうけることもあります。

それでもユーザーと打ち合わせを重ね続け...

どのようなシステムを作りたいか?

どのような課題があり、
どのように解決したいか?

IT技術者として課題解決を可能とする
システムを構築する必要があります。

何も知らない状態から作り上げることは、
並大抵のパワーでは達成することができません。

しかし、それを乗り越えて
自ら積極的にユーザーに働きかけてノウハウを身に着けることは、
あなたを技術者としてより高みに押し上げてくれます。

そして何も知らない状態から
ユーザー業務の知識を知るにはどうすればよいか?

そのような「ノウハウを得る手法」を
身につける事もできるのです。

その手法を知っていれば、
次回また、全く経験のない業界の開発案件を
任されたとしても、

あなたは既に...

「ノウハウを得るにはどのようにすれば良いか」

...という基礎能力を身につけています。

ユーザと話すことによって、
身につく能力です。

同一業界の開発案件は
コンサルタント的な視野を広める

視野が広がるのは、
何も異なる業界の案件を
対応した時だけではありません。

たとえば今度は、
あなたが飲食系のパッケージシステム開発を
行っているとしましょう。

飲食系パッケージですので、
業界は飲食業に限られます。

パッケージシステムは
その業務を行うにあたって基本的な
機能を備えているのですが...

企業によって業務内容は異なりますので、
ユーザーの要望によってカスタマイズを
行うことがほとんど。

そして同じ飲食業界の企業でも、
重視している機能は異なります。

たとえば、とある複数チェーン店を
展開する企業はお店の社員やアルバイトの
カラ出勤が問題視されていました。

カラ出勤とは、
お店の同僚にメールや電話で…

「遅れそうだからタイムカードを打刻しておいて!」

…と連絡して、実際には出勤していないのに
出勤したことにする事です。

この企業はカラ出勤問題を解決する為に、
パッケージシステムと静脈認証機器を連携させ、
出退勤は静脈認証で登録するカスタマイズを
実施するようにしました。

また、別の飲食チェーン店では
食べに来てくれるお客様とのコミュニケーションを強化する為、
お店のポイントカードとシステムに含まれる顧客情報を連携させて、
そのお客様の嗜好や来店頻度を管理するカスタマイズを行った例もあります。

同じ業界であっても
企業によって課題やシステムに対する要求はさまざま。

ユーザーとの仕様検討段階で
どのような課題があり、
どう解決するかを検討するのですが...

「A社ではこのような問題はなかったのに、
 B社では問題となっているのか」

といった企業による差異は
あなたの業界に対する知識を深めますし...

「過去に開発したC社のノウハウを、
 B社にご提案したらどうだろう」

といった新しい業務改善の提案にも
繋がるケースもあります。

同一業界についてのノウハウが
深まる事によりコンサルタント的な立場での
ユーザー課題改善を行う事も可能になるのです。

コンサルタント的に動ける様になれば、
得られる利益が大きくなります。

コンサルティングほど利益率の高い
ビジネスはなかなかありません。

脳みそ以外は不要ですから。

生の体験こそが
視野を広める最良の方法

視野を広げる事は大切とよく言われますが、
これは人が生きていく上でも、
本当に大切なことです。

あなたはどのような技術者に
なりたいのでしょうか?

IT技術者になりたての頃は
「将来なれる技術者像」という
選択肢はたくさんあります。

ITコンサルタント、
業務系エンジニア、
ネットワークエンジニア...

プログラマーとして
特化してゆくという方もいるでしょう。

どのような技術者になろうとも
自分の視野を広めるという努力だけは
怠らないようにしてください。

「情報誌や専門誌をちゃんと見てるし、
 スキルアップも欠かしていない」

中にはそう言う方もいることでしょう。
それも視野を狭めない為に行える、大切なことです。

しかし、
実際に自ら行動することによる
生の体験ほど約に立つものはありません。

苦労しつつもノウハウを習得した経験。
ユーザーと何度も打ち合わせを重ねた経験。
同業他社と協力してシステム開発を行った経験。

そこには全て「人」の存在があり、
コミュニケーションがあります。

そういった生の体験こそが、
その人の視野を広げ、活躍できるフィールドを
広げる事に繋がるのです。

インターネットや情報誌からノウハウを
得る事も大切ですが、

時には自ら行動して体験することが、
あなたの視野を広げてくれます。

先ほどの例で、
プログラマーとして特化する道を選択する方なら...

ワーキンググループなどに参加して
同じ志を持つ人に出会える事により、
プログラマーとしての視野は広まります。

情報を集めること。
行動をすること。
そして人との交流を続けること。

これらを欠かさず行うことにより、
あなたの視野は確実に広がってゆきます。

苦手だな、と思う人もいると思いますが、
そこを踏ん張ってこそ未来が見えます。

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

PS

ほとんどの事は
インターネットや書籍などから知ることができます。

しかし生の体験というのは、
自ら動かないことには解りようがありません。

IT技術者になりたい!
もっと技術を磨きたい!

そんな方に向けて
当校では授業体験セミナーや個別カウンセリングを実施しています。

生の体験をして、あなたの視野を広めてください。

日本No.1エンジニア専門スクール

ITの勉強で、何がわからないかわからない?

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

インフラやプログラミングの勉強を進める上で、
何がわからないか、わからない!!!
という状況になったことはありませんか?

最近、中堅エンジニアの方から...

「何がわからないのかを、わかっていない新人が多い」

...といった事をよく聞きます。

何がわからないのかを把握していない
新人エンジニアから質問を受けたとしても、
何を聞きたいかわからないので回答に困るそうです。

何がわからないかわからないのは
質問する側もされる側も困っている状態

何がわからないかわからない...

これは新人エンジニアにはよくあることです。

実際に、ベテランエンジニアの方たちでも
新人の頃は同じような状態だったという人も多くいます。

何がわからないかわからない人から
質問を受けても、答える側も困ってしまうのです。

それは状況が伝わらず、
質問者がどんな答えが欲しいのかが、
答える側に明確に伝わっていないからなのです。

わからないから聞く事は、全く問題ありません。

しかし毎回毎回、
何がわからないかわかっていないのに
質問ばかりをするというのは業務的には
最高に非効率です。

質問側にも担当業務があるように、
質問される側にも担当業務があります。

理解できていない状態で質問することは
質問される側の業務を中断させることに繋がり、
全体的な進捗を遅らせる原因にもなるのです。

質問にはある程度の知識が必要
そして正しく質問するためのスキルも大切

講義や講演会に参加した際、決まって最後に...

「何か質問がある人はおっしゃってください」

...と、プレゼンテーターが参加者に問いかけます。

このような問いかけは
参加者がある程度、講義内容や講演内容に対する
基礎知識や興味がある方に対しては有効な問いかけなのです。

もう少し詳しく言うと、
初心者は基本的な事項に対する質問は出来るけど
難しい専門的な内容については質問することができません。

難しい専門的な事項を知っているベテランは
基本的な内容に対する質問はほとんどありませんが
難しい専門的な質問はたくさんできます。

つまり「質問する」という行為には、
その習熟度は別として、ある程度の知識が必要とされるのです。

例えば小学生に対して
Linuxカーネルに関する専門的な内容や
相対性理論を難しく説明したとしましょう。

説明の最後に...

「何か質問がある人はいますか?」

...と聞いても、質問はないでしょう。

Linuxカーネルや相対性理論に対する知識がなく、
質問することができないからです。

(天才小学生がいれば別ですが)

何がわからないかわからないと言うことは、
何を質問していいのかわからないのと同じことなのです。

いざと言う時に役立つ質問スキル
質問する時には5つのポイントを心がけるように

何がわからないかわからないと言う方は、
まず基本的な知識を身に付ける事を心がけてください。

何がわからないかわからない方は、
基本的な知識の習得を後回しにして、
答えだけを求めやすいという性格的な傾向があります。

面倒臭がらずに根気よく、
基本的な知識を身に付けることを優先しましょう。

とは言え、
そんな方にも業務があり、
基本的な知識が不足していたとしても
ベテランエンジニアに質問しなければならないケースもあります。

そんな時に役立つのが「質問スキル」です。

質問スキルとは、
質問者が相手に質問したい事を正確に伝え、
目的とした回答やアドバイスを得る技術を言います。

質問スキルを習得するには、
質問するたびに以下の5つのポイントを心がけるようにしてください。

(1)自分が理解している範囲を明確にする

わからない事に対して、
自分がどこまで理解しているかを明確にしてください。

基本的な知識が不足していても、
自分が理解している範囲内で問題ありあません。

理解している範囲を相手に明確に伝えることで
質問を受ける側は、質問者が理解できていない内容を把握でき、
回答しやすくなります。

(2)基本的な質問を恐れない

さっきと矛盾するようで、
あれですが、、

質問の内容が違います。

局所的な質問をし続けると、
かえって相手の迷惑になります。

おそらく基本的な事項なのだろうけど
自分で調べてみてもいまひとつ理解できない...

人によっては、
基本的な事を質問するのは失礼だ、
基本的な質問くらいは何とか自分で解決したい、
といった、配慮とも取れ、プライドとも取れる理由で
質問をしない方もおられます。

基本的な事を質問したい場合は...

「基本的な質問ですみませんが...」

...と前置きをつけて質問することで質問しやすくなります。

(3)問題に対して行ったことを明確にする

問題を解決するために、
自分を行った事を明確に相手に伝えることで
質問を受けた側は、質問者に足りない観点を理解でき、
回答しやすくなります。

いつ、何を、どのタイミングで、どのように行ったか?

自分が行った行動のログファイルを作ってください。

(4)何をしたいかを明確にする

問題を解決したい!というのは当然ですが
質問することによって何を相手に求めるかを明確にしてください。

漠然と問題点を挙げるだけでは
質問される側も、質問者が何を求めているかがわかりません。

・調べ方が間違っていないか確認してほしい
・プログラムソースを見てアドバイスしてほしい
・ある程度は自分の手でやりたいので、問題解決のヒントが欲しい

...など、質問する目的を明確にしてから質問すると良いでしょう。

(5)上に挙げた(1)~(4)を紙にまとめてから質問する

自分が理解していること、
基本的な質問を含めた質問事項、
問題に対して自分が行ったログファイル、
相手に何をしてほしいかということ...

まずこれらを紙にまとめてから質問しましょう。

頭で質問内容を理解していると思っていても、
実際に質問してみると、
質問を受ける側から予想外の逆質問を受けたり、
緊張して質問しているうちに頭が混乱したりすることもあります。

紙に質問内容をまとめておけば、
質問の趣旨がぶれることもなく、混乱することもありません。

慣れるまでは、
必ず質問内容をまとめた上で質問するようにしましょう。

全ての経験は未来のあなたの糧となります

新人エンジニアに限らず
新しい環境でなれない仕事を行うとなると、
誰しも不安になってしまうことはたくさんあります。

もちろんその人の性格にもよりますが...

「こんな事を質問していいのだろうか?」
「『何も知らないんだな』と思われないだろうか?」
「厳しい人だったら、注意されたりしないだろうか?」

...人に何か質問する時は、このように思う方もいるでしょう。

新しい環境であれば、なおさらのことです。

しかし、
自分自身でどうにもならない事を抱え込んでいるよりは
周りの人からアドバイスを貰って仕事を進める方が良いのです。

あなたが質問する時...

「調べられることは全部やった!」

...という自負があるのであれば存分に質問してください。

そして質問したことで、
認識不足と注意されるのであれば、
思う存分注意されてください。

それが将来的に
あなたの大切なノウハウとなるならば、
結果的には良いことだと言えます。

自分で解決できなかった、
解らなくて悔しい思いをした...

そんな経験もあなたの未来の糧となるのです。

新人であっても未経験であっても
ITエンジニアとして活躍するからには、
あなたは既にプロフェッショナルなのです。

技術的なスキルももちろん必要ですが、
このようなヒューマンスキルも磨く必要があります。

あまり人前に出ない職種だから必要ないとか、
技術さえあれば大丈夫とかいう考えは捨ててください。

専門的な技術力に対する信頼感と
ヒューマンスキルに対する信頼感は、
ビジネスも人間関係も円滑に進めるスキルなのです。

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

PS

みんな最初はわからないことだらけ。
それは当たり前のことです。

自由に、遠慮せず質問したいという方は、
スクールをお勧めします。

ITエンジニア専門スクールはこちらから

ざっくり説明 ルーターの役割とは?

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

通信やインターネットに接続するためには
ネットワークが必要です。

ネットワークとは何か?
的なお話もありますが、
とりあえず置いておきます。

ネットワークというと、
なんとなくイメージではわかりますよね?

今このブログを見ているあなたも
何らかのネットワークに接続して閲覧しています。

今回はネットワーク構築に欠かせない
ルーターの基本的な役割についてご説明しましょう。

ルーターの基本
~「ルーター=郵便局」~

ルーターという名前は、
あなたも聞いたことがあると思います。

インターネットの普及により
ルーターはどの家庭にも設置されています。

家庭に設置されているルーターは
インターネット用のブロードバンド回線に接続するため
ブロードバンドルーターと呼ばれる事が多いですね。

このようにルーターは用途によって
呼び名が変わるのですが、
ややこしいのでここでは全て「ルーター」とします。

ルーターの役割は
もちろんコンピューターと通信することですが
その通信するデータを「パケット」と言います。

パケットとは
データを細分化した単位で、
大きな荷物を分割して、小さな小包にして
郵送しているというイメージで考えてください。

そのパケットの宛先は
IPアドレスというコンピューター用の住所で指定されます。

インターネット上のアドレスなので、
IPアドレスです。(Pはプロトコル)

ただ、「東京都新宿・・・・」という感じではありません。

IPアドレスは「127.0.0.1」など、
数値の組み合わせで表現されています。

なので人間が見てパッとわかるものではありませんが、
コンピュータ側からはわかりやすい住所になっています。

ルーターの役割は
パケット(小包)を指定されたIPアドレス(宛先)の
コンピューターに届けることです。

以上。

要するに、
ルータは「パケット(小包)用の郵便局」だと考えてください。

送信経路を管理するルーティングテーブルとは

郵便局が日本全国にあるように、
ルーターもたくさん存在しています。

家庭に1台あるくらいですから、
郵便局よりもはるかにたくさんあります。

パケットのやり取りは
複数のルーターを経由して行われます。

ここで問題が発生します。

ルーターはIPアドレスがわかったとしても、
「どのルーターに送れば良いのか」というのがわからないのです。

そのため、ルーターには
「ルーティングテーブル」と言う
このIPアドレスの時には、あのルーターに送るといった
送信情報を管理しています。

郵便で言えば
新宿から難波(大阪)に小包を送る場合...

新宿で集荷した小包を
東京中央郵便局に一旦集荷し、
大阪中央郵便局に配送して最寄の難波郵便局に届け
自宅に配送する...というイメージに近いですね。

ルーティングテーブルの例を挙げてみましょう。

routing

ルーターAからEまで
5台のルーターが図の様に接続されており、
192.168.1.10宛のパケットがルーターAに届きました。

ルーターAのルーティングテーブルを参照すると
このIPアドレスの送り先はルーターCと設定されているので
ルーターCにパケットを送信します。

次に、ルーターCのルーティングテーブルを見ると
このIPアドレスの送り先はルーターDと設定されているので
ルーターDにパケットを送信します。

そしてルーターDに接続されている
IPアドレスが192.168.1.10のパソコンに
データが送信されるのです。

(きっと読み飛ばすと思いますが、
 イメージで掴んでもらえれば十分です)

ネットワークは現代のライフライン

今回はルーターにスポットを当てて
ざっくりとお伝えして来ました。

実際には、ルータには、
ネットワーク障害を起こさないため、
ネットワークセキュリティを守るため、
他にもさまざまな特徴や技術が使用されています。

それらについては
今後ブログでお話ししてゆきますが...

ネットワークは現代のライフラインです。

通信障害が発生した場合、
ネットワークというライフラインが絶たれてしまい、
社会全体に大きな影響を与えてしまいます。

もちろんセキュリティも重要。
昨今メディアを騒がせているサイバー攻撃や
ハッカー、クラッカーから情報を守らなければなりません。

現在のIT業界でも
ネットワークエンジニアは人がいなくて、
募集も多い職種。

ネットワークエンジニアには、
単にネットワークを構築して管理するというだけでなく、
社会のライフラインを守るという、大切な役目があるのです。

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

PS

ネットワーク資格で有名なのはCCNAですね。

これを持っているだけでも
エンジニアとしての道が開けます。

CCNAのスクールはこちら

ITエンジニアは専門性だけではダメ?

エンジニアの仲間

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

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

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

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

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

しかし注意があります

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

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

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

(最低限のスキルと知識は当然必要ですが)

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

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

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

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

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

少し考えてみると、

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

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

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

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

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

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

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

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

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

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

目的のためには協力が必要

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

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

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

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

むしろヒューマンスキルこそ、
意識してスキルアップしないと
いけない部分かもしれません。

ひとりで学ぶのではなく協力しながら

だからこそエンジニアになるためのトレーニングは
ひとりでやるよりも、複数人でやった方が良いのです。

少なくとも、
複数人で実際に開発することを
一度は体験すべきです。

それだけでエンジニアとしての意識が
大きく変わります。

<ヒューマンスキル>

なかなか意識できないところだと思いますので、
ぜひ意識する様にしてください。

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

PS

エンジニアを目指す仲間を見つけるならこのスクールです。

IT技術者が最も恐れるもの

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

IT技術者が最も恐れ、
出来ればその姿さえ見たくないもの...

それは、、、

「バグ」です

バグとは
主にプログラムの不具合によって
システムが正常に動作しない問題を言います。

バグが生まれる原因には様々です。

設計不足、
検討不足、
動作環境の問題など...

そして昔から
多くのバグの原因となっているのは、
思い込みによるバグや、
不注意によるケアレスミスなのです。

iOSでもあったケアレスミス

iPhoneやiPadの普及により、
ユーザー数が急増したApple社のiOS。

今年の2月21日、
iOS7.0.6のアップデートが発表されたときに
その問題は発覚しました。

iOS7.0.6での修正内容は
「SSLの接続に関する問題を修正」とされています。

SSLとは、
個人情報やクレジットカード番号など、
大切な情報を入力する時に
通信を暗号化して送受信する通信技術のこと。

この技術によって、
インターネット上の通信の安全性は保たれていますが
iOS7.0.6以前のバージョンでは
SSL通信が正常に行えていませんでした。

SSL通信技術は
既にメジャーとなっている技術です。
何故今さらになって、そんな不具合が起こったのでしょうか。

Apple社は
iOSがSSL通信する箇所の
プログラムソースを公開しました。

[ソースコードURL]
http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

[ソースコード(一部抜粋)]

applesource

プログラムでは
SSL通信時にエラーが発生したら
エラー処理を行う命令にジャンプする様になっていますが...

たとえエラーが発生していなくても
エラー処理を行う命令にジャンプする様に書かれています。
※goto fail; エラー処理へのジャンプ命令が余分に書かれている

つまり、必ずSSL通信がエラーになるのです。

知らずに悪意のあるサイトに接続した場合、
クレジットカード番号やパスワード等が
解析可能な状態で通信が行われていたのです。
※現在は修正されています。

しかも、その原因となるコードはたった1行。

おそらくプログラマーが、
プログラムを作る際にコピペして作ったのでしょう。

たった1行の
ケアレスミスを犯したが為に、
「Apple史上最大のセキュリティバグ」
とまで言われるバグを生み出してしまったのです。

バグをなくす為のテストって、してないの?

もちろん、全てのシステムは
様々なテストをパスしてリリースされます。

今回のiOSの場合は、
SSL関連のテストケースが不十分、
または漏れていた可能性があります。

あるいは...

SSLならば
これまでのバージョンで
ちゃんと接続されてきた実績もあるし
大丈夫だろうさ!

...という思い込み。

こういった思い込みも
バグを生み出す大きな要因の1つです。

システム開発のテストは、
大きく分けると3つの段階を経て
システムに問題がないかをチェックします。

1.単体テスト

最初に行われるのは「単体テスト」です。

設計書を元にして、
プログラムが動作する際に
確認する必要がある項目を洗い出します。

これをテスト仕様書と言い、
プログラムが完成したら、
テスト仕様書を元にテストを行うのです。

2.結合テスト

そして次の「結合テスト」では、
別々に作成された画面や機能を組み合わせ、
システムとして連携できるかどうかを確認します。

例えば
販売管理システムの場合なら、
実際の販売管理において
想定されているシステムの流れ=シナリオを組み
そのシナリオに則ってテストを行うのです。

3.総合テスト

単体テストや結合テストが
開発者が作った開発環境で行われるのに対し
「総合テスト」は原則的に
実際にユーザーが使用する環境で実施されます。

ユーザー環境が使用できない場合は
それと同等の環境を構築して実施するケースもあります。

総合テストは、システムテストとも呼ばれており...

・システムパフォーマンスの確認
・操作性や業務効率性に問題はないかの確認
・他のシステムとの連携確認

...等といった、
実環境におけるシステム動作・性能に関するテストが行われます。

1つのシステムが開発される際、
多くの人が集まり、多くの時間を費やしテストしますが
それでもバグが発生する可能性は大いにあるのです。

思い込みミスやケアレスミスを無くすには

思い込みが原因で発生するバグは、
「自分が作ったプログラムを、自分がテストする」
という時に発生しやすいです。

テスト仕様書を自分で作り、
そのプログラムを自分で作ると、
実際にテストする時になった際に…

ここはちゃんと
コーディングした時にチェックしたから
問題はないだろう!

そう思ってしまうんですよね。

大きなプロジェクトであれば
プログラマーとテスト担当が別なのですが、
小さなプロジェクトだと
プログラマーがテスト担当を兼ねるケースが多いです。

そして、
本来単体テストで発見されるハズのバグが
結合テストなどで発見されてしまうと、
ユーザーから不審な目で見られます。

本当にちゃんとテストしているのか?と。

思い込みをなくす為には
出来る限り別の技術者の観点も取り入れ
客観的な視点からテストするようにしましょう。

そして、ケアレスミス。

基本的な対策としては「見直し、確認する事」。
この行為に尽きます。

例えば
似ている箇所があるプログラムを
コピペして再利用する場合

ペースト先のプログラムで
正常に機能するのか、
期待した振る舞いを行うのかを、
きちんと確認する必要があります。

元のプログラムではバグが無かったとしても
別のプログラムではバグを生む可能性もあります。

プログラムを実行する際、
ステップ実行(1行ずつの処理確認)できる
開発環境で作成している場合は、
必ず1度はステップ実行することをお勧めします。

そして
これまで何度も使ったプログラムだからと言って
テストにも手を抜くことなく、動作確認を行うこと。

そうしていれば、
今回のApple社のiOSの様な不具合も
出る事はきっとなかったはずなのです。

信頼を損なわない為に
技術者ができる事

人間は完璧を求めますし、
システムは完璧を求められます。

しかし、人間は完璧ではありません。

バグが無いに越した事はありませんが、
様々な技術者のスキルを集め、
出来る限りバグのないシステムを作ること。

少なくとも
思い込みやケアレスミスは、
開発チームと本人の努力によって、防げるレベルのバグ対策です。

それは最低限のバグ対策だと言えます。

最低限のバグ対策を行った上で
更にバグを無くす為の対策を行ったとして、
それでもなお、後々になってバグが発覚した場合は...

・迅速に修正、復旧できるか
・被害を最小限に食い止められるか
・不具合の事象、原因、影響範囲を説明できるか
・再発防止策をどのように講じるか

...といったように、
誠意を持って、ユーザーの信頼を損なわない対応を行う事。

それが大切なのです。

バグはシステムだけでなく
ユーザーへの信頼までも貪るケースがある
その事を覚えておいてください。

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

PS

今回は主に
プログラム的なミスのお話しでしたが、
同じ事は設計者にも言えます。

設計者が仕様を勘違いしたり、
思い込んで設計したりすれば、
ミスを含んだ設計仕様でプログラムが作られる事になります。

また、このような
ミスを減らす為の取り組みは
IT業界に限った事ではありません。

1人1人が連携しつつ、
いかにミスを無くして
質の良い製品・サービスを提供できるか...

それはどの業界でも共通の課題なのです。

PPS

ミスが少なくするには、
ベテランエンジニアのコーディングを見る。
もっと言えば、直接教えてもらうのが、
最善です。

プロのエンジニアが教えるJavaのスクールはこちら

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

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

IT講師に応募する