リスキルテクノロジー

エンジニアとしての視野を広めるには?

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技術者が最も恐れるもの

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の研修はこちら

そもそもサーバーの役割とは?

サーバールーム

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

サーバーの方が普通のパソコンよりも優れているという
漠然としたイメージを持っているのではないでしょうか?

ただ、どんなものか、
何をしているのか、すごく漠然としか理解していない、
そんな人も多いと思います。

今日は私たちの日常生活において、
必要不可欠な存在となっているサーバーについて、
その役割と特徴をご紹介します。

知らない間に実は使っている?
日常生活に密接な関わりを持つサーバーとは

例えばあなたが
スマホでメールを送ったり、
Webサイトの閲覧やYouTubeで動画を見たりするとします。

これらが実現している背景には
ネットワークとサーバーの存在があります。

他にもカードキーでのドアロック解除や、
銀行のATMでお金を入出金や振込みするなど、

私たちの日常生活においてサーバーは密接に関係しており、
あなたは知らない間に数々のサーバーを利用しているのです。

サーバーの役割は
さまざまなシステムを使用したサービスを提供することです。

サービスを提供する人(モノ)だから、
サーバーです。

ネットワークを経由して
サーバーのサービスを利用します。

サービスの提供はパソコン、スマホ、ATMなどの
クライアントと呼ばれるコンピューターからの要求をサーバーが受信し、
サーバーで処理を行った結果をクライアントに提供するという流れで進みます。

ATMの例で簡単に流れを説明すると...

(1) ATMから残高照会をサーバーに要求
(2)サーバーで口座残高を確認し、ATMに情報を返す
(3)ATMで表示された残高を確認し、10,000円を出金
(4)10,000円出金した事をサーバーに通信し、口座残高を減らす

...というような流れでサーバーとクライアントの通信が行われるのです。

普通のパソコンでも
サーバーとして利用することはできます。

が、
基本的に故障やシステムダウンさせないため、
膨大な数のクライアントからの要求を高速に処理するために、
通常のパソコンよりも遥かに高性能な処理能力を持ちます。

上等なPCを使っていると思ってください。

サーバーで提供するサービスは
使用するユーザーの数や予想される要求数に応じて
処理性能を考慮し、処理するサーバーの数も検討する必要があります。

サーバーの役割はインストールする
アプリケーションによりさまざま

サーバーを構築する際、
提供したいサービスに適した
アプリケーションをインストールします。

サーバーの役割は
インストールするアプリケーションにより
決定されるのです。

大規模なシステムにおいては
1サーバーにつき1つの役割となる事が多いですが、
1サーバーにつき複数の役割を持つケースもあります。

我が社で使っているシステムなんかはそうですね。

優秀なエンジニアが頑張ってくれているので、
同じサーバーでたくさんの役割が入っています。

(褒められたものじゃないって?
 ええ、知っています。 苦笑)

たくさん入っていると、
サーバーの費用が抑えられます。

反対に、そのサーバーが壊れると
とても大変です。

なんとなくイメージがついたでしょうか?

以下に代表的なサーバーの役割と、
アプリケーションを紹介しましょう。

1.Webサーバー

インターネットの必須サーバー。

クライアントからの要求に応じた
Webページをクライアントのブラウザに表示します。

代表的なアプリは「apache」。

2.Mailサーバー

メールの送受信を管理するサーバーで、
受信サーバーを「POP(Post Office Protocol)サーバー」、
送信サーバーを「SMTP(Simple Mail Transfer Protocol )サーバー」と言います。

簡単に言えば
郵便ボストがSMTPサーバーで、郵便受けがPOPサーバーです。

代表的なアプリは「sendmail」「postfix」。

3.SSHサーバー

通信する内容を暗号化して
コンピューターとリモート通信する為のサーバー。

パスワード等の重要な情報を
暗号化しないままの通信を行うと
パスワード盗聴などの恐れがあり、
セキュリティ的に問題があります。

このため、暗号や認証などの
セキュリティを施した上で通信を
行う必要があるのです。

SSHは各サーバーをリモート操作する為、
ほとんどのサーバーに同時に設定されます。

代表的なアプリは「OpenSSH」。

4.DNS(Domain Name System)サーバー

通常、インターネット上のサーバーは
IPアドレスと呼ばれるもの(8.8.8.8など)によって
識別されます。

サーバーの住所みたいなものです。

しかし、いかんせん、
わかりにくい。

そこで、
人間にわかりやすいドメイン(www.linuxacademy.ne.jp)で
アクセスできるようにしています。

これを変換しているのが、
DNSサーバーです。

代表的なアプリは「bind」。

5.FTP(File Transfer Protocol)サーバー

FTPを利用して
サーバーとのファイル送受信を可能とするサービス。

誰でも接続できる様な設定も可能ですが、
FTP接続のための専用ユーザーを作成して、
権限を持ったユーザーのみ送受信する事も可能。

代表的なアプリは「vsftpd」。

この他にも、
データベースを管理するDBサーバーや、
ストリーム配信を行うストリームサーバー、
サーバーサイドJavaプログラムを実行可能とするAPサーバーなど、
サーバーには提供するサービスによってさまざまな種類があります。

まぁ、わからなくても気にしないでください。

とにかくたくさんアプリケーションがあって、
それをサーバーに入れることによって、
動くようになるということです。

これらをいかに使うか?
どうやって利用して行くか?

などが、Linuxの世界共通試験 LPICの
内容のメイン部分になります。

サーバーの過酷な稼働環境で
トラブルを回避するには

サーバーはメンテナンス等を除き、
基本的に24時間365日稼働することが
前提とされています。

通常のパソコンの様に、
1日使い終わったら電源を切るという
サーバーはまずありません。

しかし機械にはトラブルは付き物。

24時間365日稼働させる為に、
故障やシステムダウンといったトラブルを避けるために
さまざまな技術が採用されています。

1.RAID

ハードディスクを複数用意し、
データを分散して記録することにより
障害発生時の負荷分散と処理の高速化を行う技術。

RAID1(ミラーリング)と言う手法で、
2代のハードディスクに同時に同じデータを記録したり...

RAID0(ストライピング)と言う手法で、
複数のハードディスクに分散してデータを記録することにより
データを記録する速度を高速化する技術などもあります。

RAIDには0~6までの7種類の手法が存在し、
各手法を組み合わせて運用されるケースもあります。

2.UPS(Uninterruptible Power Supply)

日本語では「無停電電源装置」という意味で、
万一停電が発生した場合でも、サーバーに電源を供給して
サーバーダウンを回避する装置です。

大量のサーバーを管理する
データセンターには必ず備え付けられており、
データ保護のため普通のパソコンに使用している企業もあります。

3.ホットスワップ

サーバーの電源をONにしたまま
ハードディスクやケーブル、パーツを交換できる技術。

サーバーの一部に障害が発生した場合でも、
サービスを停止させることなく故障した部品の交換が可能です。

4.クラスタリング

複数のサーバーを1台のサーバーの様に見せかける技術。

例えば2台のWebサーバーとした場合...

1台を運用、1台を休止状態にして待機させ、
トラブル発生時に切り替えを行う
フェイルオーバーというクラスタリング手法や...

2台とも同時に運用させておき
一方のサーバーに問題が発生してもサービスが継続できる
負荷分散型クラスタリングといった手法があります。

5.ディザスタリカバリ

データのバックアップを行う際、
サーバーと同じ場所ではなく遠隔地のサーバーにバックアップする手法。

事業継続性を考慮する上で有効な方法で、
災害などによるトラブルが発生してサーバーが故障しても、
バックアップデータは遠隔地に保存しているので、
バックアップデータをリカバリして短期間で事業再開できるのが特徴です。

いかにしてダウンタイムを抑えるか
それがサーバーエンジニアの究極の目標

このようにサーバーは
日常生活や企業業務と密接な関わりがあり、
24時間365日稼働させないといけない過酷な状況下で
高い処理能力を発揮させる必要があります。

サーバーダウンを回避する技術には
上で紹介した以外にもさまざまあるのですが、
いずれの技術においても...

「いかにしてシステム稼働停止時間(ダウンタイム)を短くするか」

...というのが究極の目標であると言えます。

ダウンタイムが長くなればなる程、
ユーザーはそのサービスを使用することができず、
ユーザーからの信頼を失墜させることにもなりかねません。

ダウンタイムが続けば続くほど、
ユーザーは利益を得る機会を失ってしまうのです。

普段私たちが使用している
パソコンも十分に大切な存在ですが、
サーバーはそのサービスを利用する
多くの人にとって大切な存在です。

一件、プログラマーよりも地味な職業ですが、
必要性は同等以上あり、やりがいのある職業です。

ITに興味があり、
業界に入っていきたいなら、
インフラ技術・サーバー技術をスキルとして体得することが、
近道になります。

ぜひ、学習を進めてみてください。

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

PS

現在のIT業界における
サーバーエンジニアの需要は高く、
データセンターや企業のIT部門など、幅広く活躍できるステージがあります。

未経験でもスキルさえ習得すれば、
就職や転職できるチャンスは非常に高いと言えます。

サーバーエンジニアには
ネットワークの知識も必要不可欠ですが...

当校ではサーバー構築からネットワーク、セキュリティまで、
インフラ系のスキルやノウハウを総合的に身に着けることができます。

現場で使えるインフラ系スキルを身に着けたい...

そんなあなたはまず、リスキルテクノロジーの資料をみて見てください。
↓↓↓
サーバーエンジニアになるならこちら

システムリリースを成し遂げるには?

システムの引っ越し

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

前回は「データ移行」についてお話ししました。

しかし、
システムリリース時に注意すべき事項は
データ移行だけではありません。

ユーザーに安心して新システムを使用していただく為、
考慮する事項はまだまだあります。

前回はデータの移行方法を説明しましたが、
今回は「システム移行」についてお話ししましょう。

システム移行は「引越し」に似たり

システム移行は
身近な話で言うと「引越し」に似ています。

旧システムという家では
家族も増えて手狭になって来たので...

最新式設備のある
新しく広いデザイナーズ設計の家に引越しするイメージです。

既に新しい家は建築済で、
これまで使用していたソファや冷蔵庫など、
新しい家で住むのに必要な資産は業者に運んでもらいました。

これが前回お話しした「データ移行」にあたります。

そして実際に人が移り住み、
生活を営む事が「システム移行」にあたるのですが...

システム移行方法には3種類あります。

(1)新旧の家で実際に住み比べる方法

今までの家で住み方と、
新しい家での住み方を比較し
今まで住んでいた家での利便性や快適性が確認できてから引越しします。

(2)部分的に順次引越しする方法

ひと部屋ずつ順番に引越しして住み心地を確認し、
住み心地に問題が無ければ別の部屋の引越しを始めます。

(3)一斉に引越しする方法

とりあえず一家全員
引越しして新しい家での生活を開始します。

移行方法にはそれぞれ特徴がありますが
具体的にはどのように異なっているのかを見て行きましょう。

3種類のシステム移行方法の特徴

上で述べた移行方法は、それぞれ...

(1)並行稼働 (新旧の家で実際に住み比べる方法)

(2)部分移行 (部分的に順次引越しする方法)

(3)一斉移行 (一斉に引越しする方法)

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

(1)並行稼働

これは最も安全性の高い移行方法ですが
移行期間や人的リソースが多くかかる方法です。

具体的には、
旧システムと新システムで
ユーザーに同じデータを入力してもらいます。

例えば入金伝票を登録する際、
旧システムにも入金伝票を入力し、
新システムにも同じ入金伝票を入力するのです。

並行稼働中は
新旧両システムの入出力内容を比較して同じであれば問題はなく、
これまでのシステムと同じ動作確認が取れているという意味を持ちます。

そして全体の動作確認が取れた上で、
新しいシステムに完全に切り替えてしまう方法です。

ただし、
平行稼働中はユーザーの手間も2倍かかり、
またある程度の稼働期間を確保した上で行う必要があるため、
移行期間と人的リソースを大幅に確保しないといけません。

(2)部分移行

支店単位、業務単位、機能単位といった、
カテゴリ別に新システムを導入してゆく方法です。

新システムを導入して問題が発生した場合、
旧システムに戻してリカバリーを行う事により
トラブルの拡大を最小限に抑えられるという効果があります。

ただし、部分移行期間中は
旧システムと新システムの連携が必要となるため、
開発時に新旧システム連動が正しく行われる事をテストする必要があります。

実際に部分移行という方法は、
都市銀行の統合などで使用される手法として有名。

支店単位で移行する事により、
システムトラブルが発生した場合の影響を
支店という限定された範囲に抑え込むことができるのです。

全店でシステムトラブルとなるよりは、安全な移行策であると言えます。

(3)一斉移行

これは文字通り、
あるタイミングを持って新システムに一斉切り替えを行う方法。

ゴールデンウィークといった大型連休など、
一定の間、ユーザーがシステムを使用しない期間に行われる事が多いです。

休み明けにユーザーが出社したら
新しいシステムに切り替わっているという流れですね。

短期間でシステム移行を行う必要があり
予め立てておいたシステム移行の計画に則り移行が行われます。

移行コストという面では
他の移行方法に比べて抑えられますが、
システム移行後にトラブルが発生した場合に
どのように対処するかという事を想定した上で行う必要があります。

問題が大きい場合は
旧システムに戻すという手段も想定されますが…

その問題が一斉移行後に発覚した場合、
ユーザーの業務が停止してしまうため、リスクは大きいと言えます。

リハーサルによる事前確認で
リスク検知・安全性確認

システムの移行方法は
業種や案件の種類によって異なりますが、
多くの場合は一斉移行の方法が採用されています。

ただし、
その前にある程度の期間を設けて
ユーザーテスト的に並行稼働期間を設けるケースもあります。

例えばテスト的に約1カ月間、
経理担当に新旧両システムにデータを入力してもらいます。

そして請求書データの突合などを行い...

新旧システムで数値が一致した!

...という機能的な保障を取った上で、一斉移行を実行するのです。

会計データなどを扱うシステムの場合は
新旧システムで入力・出力したデータの整合性は特に注意されます。

また、システム移行において、
移行時のトラブルを極力避ける為、
システム移行実施前にリハーサルを行うケースがほとんどです。

本番環境と同様のテスト環境を構築し
データ移行とシステム移行を行い、
移行時に発生するリスクを前もって把握しておくのです。

リハーサルであまりにも大きな問題が発覚した場合
システムリリースが延期される場合もあります。

リリースが延期されるのは
何もシステムに重大なバグがある場合ばかりではありません。

ハードウェアやネットワークに問題があり
期待した以上の処理速度が出ずに、本番稼働に耐えられないといった
環境的な設計に問題がある場合にもリリースが延期されるケースがあります。

システムリリースには
ユーザーが協力しあうサポート体制が必要

システムリリースではサポート体制が重要です。

何度もリハーサルを行い、
何度もシステム設定を確認し、
移行はもう大丈夫!と判断しても、
移行本番時には何が発生するかわかりません。

これは何もITの現場にだけ言える事ではありません。

どのようなスポーツでも、
どのような業種職業でも、
どれだけ研鑚やトレーニングを積んだとしても、
試合本番や実際の現場では、何が起こるかわかりません。

本番という事で緊張する事もありますし
何らかの理由により、少し予定が変わってしまうだけで
冷静な判断ができなくなる場合もあります。

どのようなトラブルにも対応できるように
リリース時のサポート体制は特に重要なのです。

リリース時のサポート体制には、
システム開発側だけでなく、ユーザーにも協力者が必要です。

リスクを検知した際、
ユーザーの協力が必要な場合であれば、
速やかにユーザーに相談した上で解決策を講じる必要があります。

ユーザーとの連携力を高める為にも、
普段からユーザーとの関係を良好にして…

「一緒に新システムを作りましょう!」

...という姿勢でシステム開発を進めて行く必要があるのです。

システム移行やデータ移行など
新システムのリリースをするということは、
システム開発ベンダー側だけが頑張ればできるというものではありません。

システム開発ベンダーとユーザーが協力し
リスクを極力回避できるサポート体制をもって臨む事により
新しいシステムをリリースすることができるのです。

システムはひとりだけでは作れないし、
リリースもできない。

関係各所の協力があって初めて、
成し遂げることができるのです。

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

PS

あなたが新しい家を買ったとして
欠陥住宅だとわかったらどう思いますか?

誰も欠陥住宅には住みたいと思わないですよね。

新システムを使うことによって
より快適で、より便利な生活が始まることが期待されています。

あなたが作るシステムは
ユーザーの生活の一部になるのです。

決して欠陥品を提供する訳にはいかないのです。

PPS

システムエンジニアになるならこちら

ユーザーの資産を守るということ

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

「システムリリースの際に注意しないと
 いけないことは何でしょうか」

この質問に対しては正直に言って、
ひとことでは答える事ができません。

システムリリースにおいては
ユーザーにできる限り負担がかからない様、
気を付けないといけない事は数多くあります。

今回はその中でも重要事項のひとつ、
「データ移行」についてお話ししましょう。

システムだけを作ってしまえば
それで終わりではない

携帯電話やスマートフォンの
機種変更をされた経験がある方は多いでしょう。

新しい機種に変えてから、まず何を行いますか?

そう、電話帳データの移行です。

多くの携帯電話ショップでは
電話帳データの移行サービスを行っていますが...

「完全に移行できるとは限りませんのでご了承ください」

...と言われる事が多いのが現状。

事実、私も何度か機種変更した時
携帯電話ショップでの移行を依頼したことがありますが、
正しく移行できたという経験はあまりないです。

同じキャリアだと移行しやすいそうですが、
別キャリアに機種変更する場合は、失敗する確率が高いようです。

電話帳が移行できないと
1件1件手入力で電話帳データを入力しなおすか、
電話帳移行ツール等を新しく購入して試してみるなど、
利用者に作業負担がかかってしまいます。

数十件程度ならそれほど苦になりませんが、
何百件、何千件も電話帳データがある場合は大変です。

これは、システムでも同じことが言えます。

既存のシステムを廃止して
新しいシステムを開発して導入する場合、
既存のシステムで使用していたデータを移行する必要があります。

システム開発とは、
システムだけを作ってしまえば終わりではありません。

既存システムのデータを移行した上で、
新システムを使用してもらう必要があるのです。

データはユーザーの大切な資産

既存システムにおいて
日々の業務で入力されてきたデータ。

これらはユーザーの大切な資産です。

新システムにおいて
その資産を有効に活用できないという事は、
ユーザーにとって新システムに移行するメリットがないという事を意味します。

ツール系アプリケーションの場合
定期的にシステム改良を伴ったバージョンアップが行われますが...

旧バージョンのデータが使用できない場合、
ユーザーからクレームが来ることは必至です。

アプリケーションの改良により
機能が増えました!処理が早くなりました!
だけど旧バージョンのデータは使えません!

それでは、ユーザーは納得しません。

業務系システムの場合も同様。

これまでの業務によって培った
会計データや、顧客データ、営業履歴、案件データなど...

それらの資産が使用できないと
新しいシステムに変わったところで意味がないのです。

また、業務内容やデータの種類にもよりますが
データには法律で保存期間が設けられている場合もあります。

例えば会計帳簿データであれば
会計法では10年、法人税法では7年と定められています。

あまりにも古いデータの場合
とりあえずCSV形式に変換して
磁気テープ等に保存するという企業がほとんどです。

ですが営業売上を管理するシステムなどで...

「過去3年間の月間利益率と当年の月間利益率の対比を見たい」

...といった要望がクライアントから出た場合、
最低でも過去3年間の売り上げに関するデータは移行する必要があります。

データはユーザーにとって資産であり
今後の営業戦略を決定する上での判断材料ともなるのです。

どうやってデータ移行は行われるのか?

では、実際にどのようにデータ移行が行われるのでしょうか?

データの移行方法については
上流工程フェーズにおいて検討される必要があります。

既存システムと新システムのデータベース項目を比較し、
移行できる項目や、移行するのに加工が必要な項目などを検討。

基本的には
既存システムで使用中の全項目が
移行できるのが理想的ですが...

既存システムがオリジナルシステムで
新システムがパッケージシステムの場合など、

パッケージシステム側のデータベースに
既存システムで使用していた項目がない
といったケースもあり得ます。

その項目をどうしても移行しないといけない場合は、
追加費用を支払い、パッケージをカスタマイズした上で
移行しなければなりません。

移行するのに加工が必要な項目とは、
これまで使用していたコード体系を
新システム導入と同時にコード体系を変更して運用する項目などが挙げられます。

例えばこれまでの商品コードが10ケタであり
上位3ケタが商品分類、下位7桁が商品コードとしていたが
新システムでは商品分類と商品コードの2つの項目に分けたい場合...

既存システム「商品コード」
ABC0000001

新システム「商品分類」
ABC

新システム「商品コード」
0000001

...と分割した上で、新システムに登録しなければいけません。

データ移行では
主に移行用のプログラムを作成しての移行や
SQLを使用してデータ移行するのが一般的です。

データ加工が必要な項目の場合は、
移行用プログラムに加工条件をプログラムし、
新システム側のデータベースに加工データを自動登録します。

しかし中には、
ユーザーが判断しながら登録しないと
いけないデータもあります。

こういったデータ項目がある場合は
ユーザーに手入力で入力してもらうか、
あらかじめCSVデータをユーザーから入手して
CSVデータを新データベースに反映する方法が採られます。

データ移行はこのような流れで行われ、
新システムの動作確認を行った上で稼働準備が整うのです。

覚えておいてください
資産を守るという重要性

データ移行を疎かにしてはいけません。

データ移行が疎かにされ、
訴訟にまで発展したケースも実際にあるのです。

薬局の業務システム開発において
データ移行が適切に行われなかった為、通常業務に支障が発生。

裁判所から開発費用の返金命令が下った判例があります。
(東京地判平22・11・18)

先ほども言いましたが、
データはユーザーにとっての大切な資産です。

その資産を守る為に
データ移行については様々なケースを想定した上、
システムの上流工程から早めに検討しておく必要があります。

そしてシステムによっては...

・随時処理(随時データ更新されるもの)
・日次処理(1日に1回処理されるもの)
・月次処理(ひと月に1回処理されるもの)
・年次処理(1年に1回処理されるもの)

...など、処理されるタイミングがさまざまな場合も。

どのタイミングでデータ移行するのか
そういった事も含めて、移行計画を立案する必要があります。

もちろん、データ移行にはユーザーの協力も必要です。

場合によっては、
ユーザー企業の全社員にシステムの使用を中止してもらい
限られた時間内でデータ移行をしなければならないケースもあります。

ユーザーとの円滑なコミュニケーションなしには
データ移行どころかシステムリリースさえもうまく進みません。

ユーザーが新しいシステムに望んでいるもの。

それは効率性や利便性、
操作性や事業拡張性など、ユーザーによってさまざまです。

ただ共通している点は、
今現在使用しているシステムに限界を感じており、
新たな期待を込めて、新システムを導入しようとしている点。

IT技術者には、
ユーザーのさまざまな期待に応える必要がありますが
データ移行もそのうちのひとつです。

「ユーザーの資産を守る」ということ。

その重要性を、どうか覚えておいてください。

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

PS

ユーザの資産を守ることは
あなたとユーザーの信頼関係の良化に繋がります。

良好な信頼関係を育む事は
あなたにとって「最高の資産」となるのです。

PPS

Javaプログラミングとデータベースを学ぶなら、こちらのスクールで

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

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

IT講師に応募する