前回、 間違えやすいHTMLのタグの読み方、 について書きました。 なぜ読み間違えやすいのか？ これは、タグの表記が 英単語を省略した形になっている、 ことが要因の一つです。 そこで今回は、 この英単語の省略形について 書きたいと思います。 一見、 無造作に省略しているように見えますが、 実はあるルールに基づいて省略されています。

なぜ省略するのか？

そもそも、 なぜ英単語を省略するのでしょうか？ それは、 全てを綴ると文字数が長くなるので、 短く簡潔に表現するためです。 歴史的な背景をみてみましょう。 インターネットやファックスが発達する前、 通信にはテレックスというものが 使用されていました。 テレックスの料金は文字数に比例します 文字数が少ないほうが料金が安い、 ということで省略形が使われていました。 テレックが一般的でなくなった今では 見やすさや覚えやすさのために 省略形を使うことが多いです。

省略系のルール

では早速、省略形のルールについて 見ていきたいと思います。

ルール1: 頭文字あるいは先頭の数文字で表現する

<a href=...>は、このルールに該当します。 「a href」は 「Anchor Hypertext REFerence」の省略形です。 このルールは、HTMLだけではなく、 一般的によく使われています。 例えば、銀行の「ATM」。 これは、 「Automated Teller Machine」 の省略形です。

ルール2 母音を消して表現する ※先頭の母音は消さない

<img src=...>は、このルールに該当します。 「img src」は 「IMaGe SouRCe」の省略形です。 大文字の部分（子音）だけで構成されています。 （先頭のIは省略しない） 英語を発音するときに、 母音よりも子音が単語の音を出します。 そのため、母音を消した綴りでも 単語が分かるという発想から生まれました。 また、このルールはIT系でよく 使われています。 例えば、 電子メールを送信する際のルールに SMTPというルールがあります。 そのルールにおいて、 宛先を指定するコマンドとして 「RCPT」というコマンドがあります。 「RCPT」とは「ReCeiPT」の省略形で 「受取り」という意味です。

何でも省略すればいいわけではない

今回は、英単語の省略ルールについて 書いてきましたが、 何でもかんでも省略すればいい、 というものではありません。 省略することで、 全く意味をなさないものもあります。 省略形は、意味が通じる範囲で 適切に使うようにしてください。 ただ、こうしたルールを知ることが、 HTMLだけではなく、 IT業界で多用される、いわゆる「略語」を 理解する手がかりになると思います。 ------------------------------------ PS.選ばれ続けて15年には理由があります。 卒業生5,000名以上！ プログラミングスクールなら実績豊富なIT専門スクールで -------------------------------------

この社会では
コンピューターを触らない日はない！

...と言っても過言ではありません。

そのコンピューターを
危険な状態にしてしまうプログラムに

「マルウェア」

...があります。

今回はマルウェアについて
お話ししましょう。

マルウェアって何？

マルウェア（malware）

とは

英語で「悪いこと」を意味する

「mal-」

という接頭語にソフトウェアの

「ware」

を付けた言葉です。

マルウェアと言うと
わかりにくいかも知れませんが

「コンピューターウィルス」

と言えば皆さんご存知でしょう。

とはいえ、
コンピューターウィルスは
あくまでマルウェアのうちの１種類で、

他にもコンピューターに
さまざまな障害をひきおこす
マルウェアが存在します。

ひと昔前までは
せいぜいコンピューターを
実行できなくする程度のものでしたが、

今では
ネットワーク環境の発展にあわせて
さまざまな障害を引き起こしています。

マルウェアは
現代のネットワーク社会において
非常に大きな問題となっているのです。

代表的なマルウェアの種類

それでは、
マルウェアの種類を見てみましょう。

とても多くの種類がありますが、
ここでは代表的なものをご紹介します。

■1:ウィルス

ユーザーが
気づかないうちに増殖して
ファイルに感染していくマルウェアです。

メディアやネットワークを通じて
他のコンピューターに感染します。

感染して
すぐに発症するものもありますが、

潜伏期間を過ぎて
発症するものもあります。

■2:ワーム

ウィルスのように
ファイルに感染することなく
自己増殖してゆくマルウェアです。

ネットワークを通じて
自分のコピーを別のコンピューターに作るため、

コンピューターの
ネットワークリソースを消費します。

■3:トロイの木馬

一見すると
何もないプログラムですが、

実際には
ウィルスやワームなど

害を与えるプログラムを
運ぶためのマルウェアです。

プログラムを
知らずに実行すると、

トロイの木馬が
運んできたマルウェアが動作します。

■4:スパイウェア

ユーザーが知らないうちに
クレジットカードやパスワードなど、
個人情報を盗み出しマルウェアです。

盗み出された情報は
スパイウェアの製作者に送信されます。

■5:ボット

コンピューターを
外部からコントロールするためのマルウェアです。

ボットに感染したコンピューターは

「ゾンビPC」

と呼ばれ、
他のコンピューターに操られてしまいます。

■6:ボットネットワーク

ボットに感染した
複数のゾンビPCで構成されたネットワークで、

悪意あるユーザーが
ゾンビPC指令用サーバーを経由して
ゾンビPCに一斉に命令を指示します。

マルウェアに感染するとどうなる？

感染するマルウェアによって
引き起こされる症状はさまざまですが、

大きく分けると
次のような影響があります。

■1:ウィルスの拡散

ネットワーク内にある
他のコンピューターにウィルスを拡散します。

遠隔操作系のマルウェアなら
新しいマルウェアを
次々と送り込まれる可能性もあります。

■2:情報の漏えい

システム情報や
ルートパスワードなど

コンピューターにとって
非常に大切な情報を盗まれることもあります。

管理者権限を持つ
ユーザー情報を盗まれた場合は

コンピューターが
乗っ取られる可能性もあります。

■3:他のコンピューターへの攻撃

マルウェアの1種である
ボットに感染したコンピューターの場合、

ボットネットワークを通じて
ゾンビPCに一斉に命令を置くることで、

迷惑メールの送信や
ネットワーク障害を起こすことがあります。

マルウェア対策の重要性

「Linuxはマルウェアに強い」

と言われています。

しかし、
Linuxユーザーが増えるにつれ、

Linuxを狙ったマルウェアが
増えているのも残念ながら事実です。

基本的なマルウェア対策としては...

・ファイアウォールを利用する
・セキュリティソフトを利用する
・不要なサービスを起動しない
・知らないファイルを実行しない
・パスワードを定期的に変更する

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

Linuxは
サーバーやクライアントだけでなく、
家電製品などに組み込まれるケースが増えています。

そして
ライフラインを管理するような
重要なシステムにも使われているため、

これまで以上に
セキュリティ対策が必要です。

万が一、
マルウェアの標的にされたとしても

問題を起こさないような
セキュリティ対策を心がけるようにしましょう。

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

PS

Linuxの構築から運用
そしてセキュリティまで学びたいならこちら

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

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

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

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

「SLA」

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

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

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

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

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

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

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

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

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

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

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

「SLA（Service Level Agreement）」

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

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

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

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

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

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

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

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

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

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

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

簡単に言えば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

これは学習も同じです。

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

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

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エンジニアとして就職転職を目指すなら、
このスクールがおすすめです。

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

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

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

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

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

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

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

データセンターが
提供しているものを細かく言うと、
大きく分けて以下の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はエンジニアにとって
なくてはならないスキルなのです。

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

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

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

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

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

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

「死の行軍」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「3か月でできます！」

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

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

(2)人的要員の不足

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

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

(3)予算が足りない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

やっぱり。

しかし、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

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

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

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

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

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

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

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

「パッケージベンダー」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「こんな機能が欲しい」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

その時に...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...という例も。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS

未経験者の方は...

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

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

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

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

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

当校ではあなたの...

「なりたい！」

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

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

視野の狭い技術者はとてもとても厄介です。

前は、こうしていたから・・・
この前携わった業界ではこれが常識だったから・・・
この方法が一番いいに決まっているだろ！・・・

などなど。

こういった技術者にならないために、
必要なことがあります。

さまざまなユーザーと話すことで
技術者としての視野は広がる

IT技術者と言っても、その役割はさまざまです。

プログラマーやシステムエンジニア、
プロジェクトリーダーやプロジェクトマネージャなど
それぞれに役割があり、扱う業務内容も異なってきます。

小さな企業や個人事業主のIT技術者の場合は、
それらの役割をほぼ全てこなさないといけません。

ですが、ほとんどの技術者は、
プログラマーから始まり、徐々にステップアップします。

そしてステップアップに従って、
直接ユーザーと話す機会は確実に増えてゆきます。

打ち合わせなどでは
同年代の担当者や管理職クラスの方、
企業の幹部クラスの方々や経営者と直接話すことも。

システム開発の際はさまざまな方と話しをしますが、

業界は違っていても企業課題としている内容は
同じであったり、

業界が同じでも企業課題としている内容が
全く別ものであったりします。

生の情報は実際に話す事により得られます。

さまざまなユーザーとの話しを重ね、
生の情報を知る事により、
IT技術者の視野は広がってゆくのです。

異業界の開発案件は視野を広めるチャンス

前の業界の常識を持ち込むのはやめましょう。

新しい業界には違った常識があり、
ノウハウがあります。

（これを、面倒だな、ではなくチャンスだと考えるべきです）

幅広い業界のシステム開発を行うIT技術者の場合、
それまで経験してきた開発案件によって、強みや弱みはあります。

たとえば、
あなたが金融系システムは詳しくなったけど、
それ以外はあまり経験がない技術者だとしましょう。

会社の都合により開発要員がどうしても
確保できない。

急きょ物流系システムの
プロジェクトリーダーを任されとしたら...

物流系業務については
ほとんど業務知識がないため、
かなり大変な思いをするでしょう。

物流業界や業界用語を勉強し、
システム開発を行わなければいけません。

しかし、
書籍などからある程度の情報は知る事ができても、
最終的にはユーザーの業務内容を知る事が必須要件。

何度も打ち合わせを重ねた上で、
ユーザー業務のノウハウを知る必要があるのです。

知らない事が多すぎて、
場合によってはユーザーに頭を下げて、
物流業界の基本的な事について教えて頂くこともあります。

「そんな事も知らなくて大丈夫か？」

...とお叱りをうけることもあります。

それでもユーザーと打ち合わせを重ね続け...

どのようなシステムを作りたいか？

どのような課題があり、
どのように解決したいか？

IT技術者として課題解決を可能とする
システムを構築する必要があります。

何も知らない状態から作り上げることは、
並大抵のパワーでは達成することができません。

しかし、それを乗り越えて
自ら積極的にユーザーに働きかけてノウハウを身に着けることは、
あなたを技術者としてより高みに押し上げてくれます。

そして何も知らない状態から
ユーザー業務の知識を知るにはどうすればよいか？

そのような「ノウハウを得る手法」を
身につける事もできるのです。

その手法を知っていれば、
次回また、全く経験のない業界の開発案件を
任されたとしても、

あなたは既に...

「ノウハウを得るにはどのようにすれば良いか」

...という基礎能力を身につけています。

ユーザと話すことによって、
身につく能力です。

同一業界の開発案件は
コンサルタント的な視野を広める

視野が広がるのは、
何も異なる業界の案件を
対応した時だけではありません。

たとえば今度は、
あなたが飲食系のパッケージシステム開発を
行っているとしましょう。

飲食系パッケージですので、
業界は飲食業に限られます。

パッケージシステムは
その業務を行うにあたって基本的な
機能を備えているのですが...

企業によって業務内容は異なりますので、
ユーザーの要望によってカスタマイズを
行うことがほとんど。

そして同じ飲食業界の企業でも、
重視している機能は異なります。

たとえば、とある複数チェーン店を
展開する企業はお店の社員やアルバイトの
カラ出勤が問題視されていました。

カラ出勤とは、
お店の同僚にメールや電話で…

「遅れそうだからタイムカードを打刻しておいて！」

…と連絡して、実際には出勤していないのに
出勤したことにする事です。

この企業はカラ出勤問題を解決する為に、
パッケージシステムと静脈認証機器を連携させ、
出退勤は静脈認証で登録するカスタマイズを
実施するようにしました。

また、別の飲食チェーン店では
食べに来てくれるお客様とのコミュニケーションを強化する為、
お店のポイントカードとシステムに含まれる顧客情報を連携させて、
そのお客様の嗜好や来店頻度を管理するカスタマイズを行った例もあります。

同じ業界であっても
企業によって課題やシステムに対する要求はさまざま。

ユーザーとの仕様検討段階で
どのような課題があり、
どう解決するかを検討するのですが...

「Ａ社ではこのような問題はなかったのに、
　Ｂ社では問題となっているのか」

といった企業による差異は
あなたの業界に対する知識を深めますし...

「過去に開発したＣ社のノウハウを、
　Ｂ社にご提案したらどうだろう」

といった新しい業務改善の提案にも
繋がるケースもあります。

同一業界についてのノウハウが
深まる事によりコンサルタント的な立場での
ユーザー課題改善を行う事も可能になるのです。

コンサルタント的に動ける様になれば、
得られる利益が大きくなります。

コンサルティングほど利益率の高い
ビジネスはなかなかありません。

脳みそ以外は不要ですから。

生の体験こそが
視野を広める最良の方法

視野を広げる事は大切とよく言われますが、
これは人が生きていく上でも、
本当に大切なことです。

あなたはどのような技術者に
なりたいのでしょうか？

IT技術者になりたての頃は
「将来なれる技術者像」という
選択肢はたくさんあります。

ITコンサルタント、
業務系エンジニア、
ネットワークエンジニア...

プログラマーとして
特化してゆくという方もいるでしょう。

どのような技術者になろうとも
自分の視野を広めるという努力だけは
怠らないようにしてください。

「情報誌や専門誌をちゃんと見てるし、
　スキルアップも欠かしていない」

中にはそう言う方もいることでしょう。
それも視野を狭めない為に行える、大切なことです。

しかし、
実際に自ら行動することによる
生の体験ほど約に立つものはありません。

苦労しつつもノウハウを習得した経験。
ユーザーと何度も打ち合わせを重ねた経験。
同業他社と協力してシステム開発を行った経験。

そこには全て「人」の存在があり、
コミュニケーションがあります。

そういった生の体験こそが、
その人の視野を広げ、活躍できるフィールドを
広げる事に繋がるのです。

インターネットや情報誌からノウハウを
得る事も大切ですが、

時には自ら行動して体験することが、
あなたの視野を広げてくれます。

先ほどの例で、
プログラマーとして特化する道を選択する方なら...

ワーキンググループなどに参加して
同じ志を持つ人に出会える事により、
プログラマーとしての視野は広まります。

情報を集めること。
行動をすること。
そして人との交流を続けること。

これらを欠かさず行うことにより、
あなたの視野は確実に広がってゆきます。

苦手だな、と思う人もいると思いますが、
そこを踏ん張ってこそ未来が見えます。

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

PS

ほとんどの事は
インターネットや書籍などから知ることができます。

しかし生の体験というのは、
自ら動かないことには解りようがありません。

IT技術者になりたい！
もっと技術を磨きたい！

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

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

日本No.1エンジニア専門スクール

インフラやプログラミングの勉強を進める上で、
何がわからないか、わからない！！！
という状況になったことはありませんか？

最近、中堅エンジニアの方から...

「何がわからないのかを、わかっていない新人が多い」

...といった事をよく聞きます。

何がわからないのかを把握していない
新人エンジニアから質問を受けたとしても、
何を聞きたいかわからないので回答に困るそうです。

何がわからないかわからないのは
質問する側もされる側も困っている状態

何がわからないかわからない...

これは新人エンジニアにはよくあることです。

実際に、ベテランエンジニアの方たちでも
新人の頃は同じような状態だったという人も多くいます。

何がわからないかわからない人から
質問を受けても、答える側も困ってしまうのです。

それは状況が伝わらず、
質問者がどんな答えが欲しいのかが、
答える側に明確に伝わっていないからなのです。

わからないから聞く事は、全く問題ありません。

しかし毎回毎回、
何がわからないかわかっていないのに
質問ばかりをするというのは業務的には
最高に非効率です。

質問側にも担当業務があるように、
質問される側にも担当業務があります。

理解できていない状態で質問することは
質問される側の業務を中断させることに繋がり、
全体的な進捗を遅らせる原因にもなるのです。

質問にはある程度の知識が必要
そして正しく質問するためのスキルも大切

講義や講演会に参加した際、決まって最後に...

「何か質問がある人はおっしゃってください」

...と、プレゼンテーターが参加者に問いかけます。

このような問いかけは
参加者がある程度、講義内容や講演内容に対する
基礎知識や興味がある方に対しては有効な問いかけなのです。

もう少し詳しく言うと、
初心者は基本的な事項に対する質問は出来るけど
難しい専門的な内容については質問することができません。

難しい専門的な事項を知っているベテランは
基本的な内容に対する質問はほとんどありませんが
難しい専門的な質問はたくさんできます。

つまり「質問する」という行為には、
その習熟度は別として、ある程度の知識が必要とされるのです。

例えば小学生に対して
Linuxカーネルに関する専門的な内容や
相対性理論を難しく説明したとしましょう。

説明の最後に...

「何か質問がある人はいますか？」

...と聞いても、質問はないでしょう。

Linuxカーネルや相対性理論に対する知識がなく、
質問することができないからです。

（天才小学生がいれば別ですが）

何がわからないかわからないと言うことは、
何を質問していいのかわからないのと同じことなのです。

いざと言う時に役立つ質問スキル
質問する時には5つのポイントを心がけるように

何がわからないかわからないと言う方は、
まず基本的な知識を身に付ける事を心がけてください。

何がわからないかわからない方は、
基本的な知識の習得を後回しにして、
答えだけを求めやすいという性格的な傾向があります。

面倒臭がらずに根気よく、
基本的な知識を身に付けることを優先しましょう。

とは言え、
そんな方にも業務があり、
基本的な知識が不足していたとしても
ベテランエンジニアに質問しなければならないケースもあります。

そんな時に役立つのが「質問スキル」です。

質問スキルとは、
質問者が相手に質問したい事を正確に伝え、
目的とした回答やアドバイスを得る技術を言います。

質問スキルを習得するには、
質問するたびに以下の5つのポイントを心がけるようにしてください。

(1)自分が理解している範囲を明確にする

わからない事に対して、
自分がどこまで理解しているかを明確にしてください。

基本的な知識が不足していても、
自分が理解している範囲内で問題ありあません。

理解している範囲を相手に明確に伝えることで
質問を受ける側は、質問者が理解できていない内容を把握でき、
回答しやすくなります。

(2)基本的な質問を恐れない

さっきと矛盾するようで、
あれですが、、

質問の内容が違います。

局所的な質問をし続けると、
かえって相手の迷惑になります。

おそらく基本的な事項なのだろうけど
自分で調べてみてもいまひとつ理解できない...

人によっては、
基本的な事を質問するのは失礼だ、
基本的な質問くらいは何とか自分で解決したい、
といった、配慮とも取れ、プライドとも取れる理由で
質問をしない方もおられます。

基本的な事を質問したい場合は...

「基本的な質問ですみませんが...」

...と前置きをつけて質問することで質問しやすくなります。

(3)問題に対して行ったことを明確にする

問題を解決するために、
自分を行った事を明確に相手に伝えることで
質問を受けた側は、質問者に足りない観点を理解でき、
回答しやすくなります。

いつ、何を、どのタイミングで、どのように行ったか？

自分が行った行動のログファイルを作ってください。

(4)何をしたいかを明確にする

問題を解決したい！というのは当然ですが
質問することによって何を相手に求めるかを明確にしてください。

漠然と問題点を挙げるだけでは
質問される側も、質問者が何を求めているかがわかりません。

・調べ方が間違っていないか確認してほしい
・プログラムソースを見てアドバイスしてほしい
・ある程度は自分の手でやりたいので、問題解決のヒントが欲しい

...など、質問する目的を明確にしてから質問すると良いでしょう。

(5)上に挙げた(1)～(4)を紙にまとめてから質問する

自分が理解していること、
基本的な質問を含めた質問事項、
問題に対して自分が行ったログファイル、
相手に何をしてほしいかということ...

まずこれらを紙にまとめてから質問しましょう。

頭で質問内容を理解していると思っていても、
実際に質問してみると、
質問を受ける側から予想外の逆質問を受けたり、
緊張して質問しているうちに頭が混乱したりすることもあります。

紙に質問内容をまとめておけば、
質問の趣旨がぶれることもなく、混乱することもありません。

慣れるまでは、
必ず質問内容をまとめた上で質問するようにしましょう。

全ての経験は未来のあなたの糧となります

新人エンジニアに限らず
新しい環境でなれない仕事を行うとなると、
誰しも不安になってしまうことはたくさんあります。

もちろんその人の性格にもよりますが...

「こんな事を質問していいのだろうか？」
「『何も知らないんだな』と思われないだろうか？」
「厳しい人だったら、注意されたりしないだろうか？」

...人に何か質問する時は、このように思う方もいるでしょう。

新しい環境であれば、なおさらのことです。

しかし、
自分自身でどうにもならない事を抱え込んでいるよりは
周りの人からアドバイスを貰って仕事を進める方が良いのです。

あなたが質問する時...

「調べられることは全部やった！」

...という自負があるのであれば存分に質問してください。

そして質問したことで、
認識不足と注意されるのであれば、
思う存分注意されてください。

それが将来的に
あなたの大切なノウハウとなるならば、
結果的には良いことだと言えます。

自分で解決できなかった、
解らなくて悔しい思いをした...

そんな経験もあなたの未来の糧となるのです。

新人であっても未経験であっても
ITエンジニアとして活躍するからには、
あなたは既にプロフェッショナルなのです。

技術的なスキルももちろん必要ですが、
このようなヒューマンスキルも磨く必要があります。

あまり人前に出ない職種だから必要ないとか、
技術さえあれば大丈夫とかいう考えは捨ててください。

専門的な技術力に対する信頼感と
ヒューマンスキルに対する信頼感は、
ビジネスも人間関係も円滑に進めるスキルなのです。

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

PS

みんな最初はわからないことだらけ。
それは当たり前のことです。

自由に、遠慮せず質問したいという方は、
スクールをお勧めします。

ITエンジニア専門スクールはこちらから

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

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

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

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

しかし注意があります

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

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

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

（最低限のスキルと知識は当然必要ですが）

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

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

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

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

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

少し考えてみると、

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

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

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

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

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

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

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

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

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

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

目的のためには協力が必要

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

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

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

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

むしろヒューマンスキルこそ、
意識してスキルアップしないと
いけない部分かもしれません。

ひとりで学ぶのではなく協力しながら

だからこそエンジニアになるためのトレーニングは
ひとりでやるよりも、複数人でやった方が良いのです。

少なくとも、
複数人で実際に開発することを
一度は体験すべきです。

それだけでエンジニアとしての意識が
大きく変わります。

＜ヒューマンスキル＞

なかなか意識できないところだと思いますので、
ぜひ意識する様にしてください。

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

PS

エンジニアを目指す仲間を見つけるならこのスクールです。