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

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技術者になりたい!
もっと技術を磨きたい!

そんな方に向けて
当校では授業体験セミナーや個別カウンセリングを実施しています。

生の体験をして、あなたの視野を広めてください。

エンジニア研修ならこちら

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講師に興味はありませんか?

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

IT講師に応募する