最新記事一覧

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

完成している商品は
価格が設定されていますが、

システムは受注してから作ることが多く、
価格がいくらになるのか決まっていません。

しかし、それでは売りようがないので、
あらかじめ見積りしてから価格を決めます。

今日はシステム開発における
見積りについてお話ししましょう。

見積りはプロジェクトの成否を左右する

システム開発において
開発費用の見積りはとても重要です。

見積り金額が多すぎると
受注できませんし、

見積り金額が少なすぎると
受注できたとしても大変な目にあいます。

割とよくあることなのですが。。

そのため、
見積りに求められるのは正確性です。

500万円で作れると思ったものが
実際には1,000万円かかるとなると、
プロジェクトは大赤字になります。

見積りは、
「プロジェクトの成否を左右する」
...と言われのもまま理解ができます。

パッケージシステムは
価格が設定されているものが多いですが、

カスタマイズする場合には、
やはり見積りが必要になります。

社内開発でも
どれくらいの費用や期間がかかるかを
見積もったうえで開発しなければいけません。

どのような形態の開発でも
見積りという作業は必ず発生するのです。

工数の考え方と代表的な工数見積りの手法

見積りでは、

「工数」

...という単位が使用されます。

工数とは作業量を表す考え方のことで、

1人日 ＝ 1人が1日(約8時間)で作業する量

...という意味です。

たとえば
最終的に100人/日かかる案件の場合、

100×開発単価(人件費など)＋管理費＋交通費など

...のようにして開発費用を算出します。

システム開発における工数見積りには
いくつかの手法があります。

代表的なものをご紹介しましょう。

■トップダウン見積り法

システム全体をまず見積り、
そこから工程別に工数を細分化してゆく方法です。

見積もる人の経験によって
正確性が大きく左右される方法ですので、
あまり経験のないエンジニアには向いていません。

■係数モデル見積り法

過去の事例などから
見積りのモデルを設定し...

そのモデルに対して
開発規模などを考慮した係数を加え、
数学的に工数を算出する方法です。

採用される見積りモデルによって、
正確性が左右されるという特徴があります。

■ボトムアップ見積り法

各工程で作成する
設計書などの成果物や作業内容を細かく分けて、
それぞれの要素に必要な工数を積み上げる方法です。

それぞれの作業は、

WBS(Work Breakdown Structure)

...という手法で細かく分けられ、
作業ごとにどれくらい工数が必要かを見るので、
比較的正確な見積りが作成できます。

この他にも
さまざまな手法がありますが、
実際には複数の手法を組み合わせて
見積りが行われるケースがほとんどです。

それでも尚外れることも多く、
いわゆる炎上というのは見積もりの甘さが
原因だったりします。

リスクを考えることも大切

見積りするにあたっては、

「リスクを考える」

...ということも大切です。

最初は簡単だと考えていたが、
実は難易度が高いということがわかり、
開発工数が増えてしまうこともあります。

このような
不測の事態に対応できるように、
リスクを考えたうえで見積もる必要があります。

あまりリスクばかり気にすると
正確性に欠けてしまうので問題ですが（笑）

難易度が高い機能の開発などは
リスクを考慮した上で見積もるのが良いでしょう。

また、
次から次へと追加仕様が増えてしまい、
予定していた工数では作れなくなることもあります。

このような追加仕様対策としては、

「大幅な仕様追加が行われる場合は再見積りする」

...という条件を付ける企業が多いです。

見積りは作る前のことですので、
依頼する側もされる側も予測できないことがあります。

予測できないことも
発生するということを踏まえた上で、
できる限り正確な見積り作りが必要なのです。

できるかぎり正確な見積りで
安全なプロジェクトを

システム開発を行う企業には
独自の見積り方法を持つ企業もあります。

複数の見積り法を組み合わせて
企業独自の視点を設けて見積りを行いますが、

それでも不確定要素などで
プロジェクトが赤字になる場合もあるのです。

見積りは航海準備に似ています。

太平洋を船で横断するのに
どれくらいの燃料、食料が必要なのかというように、

必要なリソースを予測して、
安全な航海ができるようにしなければいけません。

プロジェクトを安全に進めるには
正確な見積りが必要不可欠であることを
しっかりと覚えておいてください。

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

PS

あなたが憧れのエンジニアになったら
どんな作業にどれくらい時間がかかるのかを
覚えておくようにしてください。

最初の内は時間がかかりますが、
経験を積むにつれてスピードアップしてゆきますよね。

その作業時間の違いから
未経験者が開発に必要な工数と、
経験者が開発に必要な工数の目安がわかるのです。

あなたがプロジェクトを
管理する立場になったとき...

未経験者と経験者の
作業工数の目安がわかっていれば、
プロジェクトの計画を立てやすくなります。

javaスクールの資料請求はこちらから

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

ほとんどのプログラムで
必ず使われるアルゴリズムがあります。

それは「変数と配列」です。

基本中の基本なので、
理解している人は読み飛ばしましょう。

そもそも、変数と配列って何？

…というところから話してゆきましょう。

変数は中学生の時に習っています

変数というのは
みなさん中学生の数学で習っています。

x + 2 = 10

そう、方程式ですね。

この「x」と言うのが
アルゴリズムで言うところの
変数にあたります。

上の方程式の答えは、

x = 8

変数xという箱に
8という値が入っていると考えると
わかりやすいでしょう。

方程式では数字しか使いませんので、
変数xという箱の中身は必ず数字になります。

しかし、実際のプログラムでは数字だけでなく、
いろいろなデータを扱わなければいけません。

いろいろなデータの形式を「データ型」と呼び、
それぞれのデータ型にあった変数（箱）があります。

(1)整数型：整数を扱う箱（0, 100, -100など）
(2)実数型：実数を扱う箱（1.23, 0.987, -123.456など）
(3)文字列型：文字列を扱う箱（”ABC”, “あいう”, “リナックス”など）
(4)論理型：真、偽を扱う箱（TRUE, FALSE）

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

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

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

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

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

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

変数の場合は、
1つの変数につき1つのデータしか入りません。

x = 8

この場合はxという箱に
既に8という値が入っている状態です。

xという箱に...

x = 10

...として別の値を入れてしまうと、
8という値は消えてなくなってしまいます。

1つの値しか扱えない変数だけだと
大量のデータを扱うプログラムの場合、
何かと不便ですね。

もっと多くのデータを扱う必要がある時に
登場するのが配列です。

変数は値を入れる箱でしたが
配列は変数の箱を整理して並べた状態をイメージしてください。

配列A [4]の
カッコの中の4という数字は...

配列Aには
変数の箱が4個ありますよという意味です。

そして配列には
それぞれ箱番号が割り振られており、
例えば...

0番の箱 = 100
1番の箱 = 200
2番の箱 = 300
3番の箱 = 400

...というように、
1つの配列に複数のデータを入れることができます。

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

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

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

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

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

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

例えば3つの変数を計算し、
最後にそれぞれの変数を足して
画面に表示する以下のようなプログラムがあるとします。

1： 変数A = 100 + 10
2： 変数B = 100 + 20
3： 変数C = 100 + 30
4： 画面表示（変数A + 変数B + 変数C）

ここで、それぞれの変数に足している
100という値が間違っていることが発覚しました。

200という値が正しい値だった！という場合、
100と書かれている場所すべてを修正しなければなりません。

この場合は1行目～3行目に修正が必要ですね。

しかし、100という数字を
最初から変数として持っていれば
修正箇所は1箇所で済みます。

1： 変数X = 100
2： 変数A = 変数X + 10
3： 変数B = 変数X + 20
4： 変数C = 変数X + 30
5： 画面表示（変数A + 変数B + 変数C）

変数Xがある場合は...

1： 変数X = 200

...と1行目だけを修正すれば良い訳です。

そして配列ですが、
例えば100件のデータを
全て変数で管理するとどうなるでしょうか？

1： 変数A-1
2： 変数A-2
3： 変数A-3
～
100： 変数A-100

というように、
変数を100個も用意しなければいけません。

ですが配列にすれば…

1： 配列A[100]

...このように1行で済みます。

変数や配列は
プログラムの余分な記述を減らしてくれます。

ほかにも、
後からプログラム修正が必要になった時、
プログラムを解析しやすくする効果もあるのです。

誰が見てもわかりやすいプログラミングを！

変数と配列について
初歩的な知識をお伝えしましたが...

これらは
プログラムを書くにあたって
大切なことです。

データはできるだけ
変数や配列などを使って
プログラムを書くという事を覚えておいてください。

変数や配列を上手に使わずに
プログラムを書いた場合、
後から修正する時に内容がわかりにくくなる場合もあります。

プログラムを作る人は
1人だけかも知れません。

しかし、

そのプログラムを修正するのは
作った本人であるとは限らないのです。

変数や配列を使って
どのプログラマーが見てもわかりやすく、
修正しやすいプログラムを作ること。

これが開発の効率化や、
修正後のバグ発生防止にもつながるのです。

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

PS

あるプログラマーから聞いた話ですが...

変数を使わずに
数値や文字をプログラムに直接書くプログラマーは
今でもけっこう多いそうです。

プログラマーを目指すなら、
後々のメンテナンスを考えて、
誰が読んでもわかるプログラムを心がけましょう。

Javaプログラミングを勉強するならLAプログラマースクール

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: リスキルテクノロジー 松田航
新宿本校にて、、、

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

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

「アジャイル開発」

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

これは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: リスキルテクノロジー 松田航
新宿本校にて、、、

「アルゴリズム」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そこでこのような...

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

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

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

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

「フローチャート」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実はこのなかでも...

「3分以上待ったか？」

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

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

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

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

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

停止性とは...

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

...という意味です。

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1)要件定義

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

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

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

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

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

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

(2)基本設計

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

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

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

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

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

(3)詳細設計

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

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

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

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

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

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

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

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

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

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

(5)単体テスト

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

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

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

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

(6)結合テスト

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

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

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

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

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

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

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

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

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

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

(9)リリース

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

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

(10)運用・保守

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

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

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

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

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

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

■メリット

・計画を立てやすい

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

・進捗管理のしやすさ

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

・成果物ベースでの開発

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

■デメリット

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

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

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

・仕様変更時の影響

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

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

・成果物管理の稼働負荷

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

ウォーターフォールモデルには、
この様なメリット、デメリットがあるのです。

ドキュメントによる品質・工程管理
しかしそれは両刃の剣にも成り得る可能性が？

ここで、メリットにもデメリットにも登場した
ウォーターフォールモデルにおける成果物（ドキュメント）管理について、
もう少し詳しくお話ししましょう。

ウォーターフォールモデルは
ドキュメントの作成量が多いことが有名です。

各開発工程の最後には
成果物として設計書やテスト結果報告書など
さまざまなドキュメントをユーザーに提示します。

提示したドキュメントを
ユーザーが承認することによって、
開発側は次の工程に進むことができるのです。

実際には納期が短く、
ドキュメントは後から提出して、
できるだけ早く工程を進めて行くというケースもありますが...

ウォーターフォールモデルは
前工程の成果物ありきで進められるので
ドキュメントがないと先々の工程に進みにくい性質を持ちます。

そして大規模なシステム程
ドキュメント量が膨大な量になる傾向があり、
その作成や管理稼働に大きな負荷がかかってしまうのです。

工程は進んだものの、
後になって要求仕様が変更された場合には
多くのドキュメントを修正する必要があります。

また、ウォーターフォールモデルの特徴として
計画の立てやすさ、進捗管理のしやすさがありますが、
これらの管理資料の作成だけでも、かなりの稼働がかかってしまいます。

代表的な管理資料としては
WBS（Work Breakdown Structure）といい、
開発プロジェクトを細かい作業項目に分割し、
誰が、何を、いつまでに対応するか、進捗率はどうかなど、
開発計画や実績を把握できる資料を作成してプロジェクト管理を行います。

しかし、
作業項目単位で作成する必要があるため
WBSを作成するだけでもかなりの稼働負荷がかかりますし...

ユーザーの都合でスケジュール変更があった場合には、
その変更内容を反映し、スケジュールを組みなおす必要が発生します。

このように、ウォーターフォールモデルでは
ドキュメントによる品質・工程管理が行われますが、
逆にドキュメントに対する稼働負荷が高いという特徴もあるのです。

多くの開発現場で採用される基礎的手法
基礎力を身に付けておけば、他の開発手法でも対応可能

ウォーターフォールモデルは
大規模開発向けの開発手法と言われています。

その理由は、
きちんと何もかも整えた状態で
プロジェクト全体や各開発者の進捗管理ができる為です。

にもかかわらず、
実際には規模の大小を問わず
ほとんどの開発案件で採用され続けている手法。

それは一体なぜなのでしょうか。

理由はいくつかあり、
長年多くの技術者がこの開発モデルを経験し
ノウハウを持っている技術者が多いというのもありますが...

もうひとつ...

「成果物と一緒に費用を請求しやすい」

...という点も挙げられます。

大規模な開発になればなるほど、
開発期間は長期にわたりますので、
全て納品してから請求･･･となると、運転資金が調達できません。

そこで採られる方法が「分割検収」という方法。

全体の見積もり金額から、
要件定義の成果物を納品したら○万円請求、
基本設計～詳細設計までの成果物を納品したら○万円請求...

...というように、フェーズの終了毎に請求を行います。

企業側は開発者に給料を支払わないといけませんので、
資金繰りもしやすいこの手法が採られるケースが多いのです。

しかし、
最近ではユーザーのスピード感は増す傾向にあり、
実際には柔軟に仕様変更を行いたいユーザーが多いのも事実。

既にご説明したとおり、
ウォーターフォールモデルには
柔軟な仕様変更を可能とするスピード感に欠けるというデメリットがあります。

そこで登場したのがアジャイルなど、
ウォーターフォールとは異なる開発手法ですが、
最近ではウォーターフォールとアジャイルを組み合わせるような
ハイブリッド型と呼ばれる開発手法も存在します。

アジャイルやハイブリッド型については
また別の機会にご紹介しますが…

ウォーターフォールモデルは
開発手法の「基礎」とも言えるものですので、
各フェーズで行う作業内容は把握しておきましょう。

他の開発手法を見ても、
開発の進め方は異なりますが、
内容としてはウォーターフォールモデルの
各フェーズを分解・再構築して手順を変えたものが多いです。

ウォーターフォールモデルは、
IT技術者になれば、必ず1度は経験する開発手法。

開発の基礎。しっかり習得しておきましょう。

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

PS

ウォーターフォール型を実践できる
開発演習を含んだコースが多数あります。

プログラミングのスクールならリスキルテクノロジー

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

[ソースコード（一部抜粋）]

プログラムでは
SSL通信時にエラーが発生したら
エラー処理を行う命令にジャンプする様になっていますが...

たとえエラーが発生していなくても
エラー処理を行う命令にジャンプする様に書かれています。
※goto fail; エラー処理へのジャンプ命令が余分に書かれている

つまり、必ずSSL通信がエラーになるのです。

知らずに悪意のあるサイトに接続した場合、
クレジットカード番号やパスワード等が
解析可能な状態で通信が行われていたのです。
※現在は修正されています。

しかも、その原因となるコードはたった１行。

おそらくプログラマーが、
プログラムを作る際にコピペして作ったのでしょう。

たった１行の
ケアレスミスを犯したが為に、
「Apple史上最大のセキュリティバグ」
とまで言われるバグを生み出してしまったのです。

バグをなくす為のテストって、してないの？

もちろん、全てのシステムは
様々なテストをパスしてリリースされます。

今回のiOSの場合は、
SSL関連のテストケースが不十分、
または漏れていた可能性があります。

あるいは...

SSLならば
これまでのバージョンで
ちゃんと接続されてきた実績もあるし
大丈夫だろうさ！

...という思い込み。

こういった思い込みも
バグを生み出す大きな要因の1つです。

システム開発のテストは、
大きく分けると3つの段階を経て
システムに問題がないかをチェックします。

1.単体テスト

最初に行われるのは「単体テスト」です。

設計書を元にして、
プログラムが動作する際に
確認する必要がある項目を洗い出します。

これをテスト仕様書と言い、
プログラムが完成したら、
テスト仕様書を元にテストを行うのです。

2.結合テスト

そして次の「結合テスト」では、
別々に作成された画面や機能を組み合わせ、
システムとして連携できるかどうかを確認します。

例えば
販売管理システムの場合なら、
実際の販売管理において
想定されているシステムの流れ＝シナリオを組み
そのシナリオに則ってテストを行うのです。

3.総合テスト

単体テストや結合テストが
開発者が作った開発環境で行われるのに対し
「総合テスト」は原則的に
実際にユーザーが使用する環境で実施されます。

ユーザー環境が使用できない場合は
それと同等の環境を構築して実施するケースもあります。

総合テストは、システムテストとも呼ばれており...

・システムパフォーマンスの確認
・操作性や業務効率性に問題はないかの確認
・他のシステムとの連携確認

...等といった、
実環境におけるシステム動作・性能に関するテストが行われます。

1つのシステムが開発される際、
多くの人が集まり、多くの時間を費やしテストしますが
それでもバグが発生する可能性は大いにあるのです。

思い込みミスやケアレスミスを無くすには

思い込みが原因で発生するバグは、
「自分が作ったプログラムを、自分がテストする」
という時に発生しやすいです。

テスト仕様書を自分で作り、
そのプログラムを自分で作ると、
実際にテストする時になった際に…

ここはちゃんと
コーディングした時にチェックしたから
問題はないだろう！

そう思ってしまうんですよね。

大きなプロジェクトであれば
プログラマーとテスト担当が別なのですが、
小さなプロジェクトだと
プログラマーがテスト担当を兼ねるケースが多いです。

そして、
本来単体テストで発見されるハズのバグが
結合テストなどで発見されてしまうと、
ユーザーから不審な目で見られます。

本当にちゃんとテストしているのか？と。

思い込みをなくす為には
出来る限り別の技術者の観点も取り入れ
客観的な視点からテストするようにしましょう。

そして、ケアレスミス。

基本的な対策としては「見直し、確認する事」。
この行為に尽きます。

例えば
似ている箇所があるプログラムを
コピペして再利用する場合

ペースト先のプログラムで
正常に機能するのか、
期待した振る舞いを行うのかを、
きちんと確認する必要があります。

元のプログラムではバグが無かったとしても
別のプログラムではバグを生む可能性もあります。

プログラムを実行する際、
ステップ実行（１行ずつの処理確認）できる
開発環境で作成している場合は、
必ず1度はステップ実行することをお勧めします。

そして
これまで何度も使ったプログラムだからと言って
テストにも手を抜くことなく、動作確認を行うこと。

そうしていれば、
今回のApple社のiOSの様な不具合も
出る事はきっとなかったはずなのです。

信頼を損なわない為に
技術者ができる事

人間は完璧を求めますし、
システムは完璧を求められます。

しかし、人間は完璧ではありません。

バグが無いに越した事はありませんが、
様々な技術者のスキルを集め、
出来る限りバグのないシステムを作ること。

少なくとも
思い込みやケアレスミスは、
開発チームと本人の努力によって、防げるレベルのバグ対策です。

それは最低限のバグ対策だと言えます。

最低限のバグ対策を行った上で
更にバグを無くす為の対策を行ったとして、
それでもなお、後々になってバグが発覚した場合は...

・迅速に修正、復旧できるか
・被害を最小限に食い止められるか
・不具合の事象、原因、影響範囲を説明できるか
・再発防止策をどのように講じるか

...といったように、
誠意を持って、ユーザーの信頼を損なわない対応を行う事。

それが大切なのです。

バグはシステムだけでなく
ユーザーへの信頼までも貪るケースがある
その事を覚えておいてください。

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

PS

今回は主に
プログラム的なミスのお話しでしたが、
同じ事は設計者にも言えます。

設計者が仕様を勘違いしたり、
思い込んで設計したりすれば、
ミスを含んだ設計仕様でプログラムが作られる事になります。

また、このような
ミスを減らす為の取り組みは
IT業界に限った事ではありません。

1人1人が連携しつつ、
いかにミスを無くして
質の良い製品・サービスを提供できるか...

それはどの業界でも共通の課題なのです。

PPS

ミスが少なくするには、
ベテランエンジニアのコーディングを見る。
もっと言えば、直接教えてもらうのが、
最善です。

プロのエンジニアが教えるJavaのスクールはこちら

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1)並行稼働

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

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

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

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

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

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

(2)部分移行

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

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

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

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

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

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

(3)一斉移行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

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

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

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

PPS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

↓

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・随時処理（随時データ更新されるもの）
・日次処理（１日に１回処理されるもの）
・月次処理（ひと月に１回処理されるもの）
・年次処理（１年に１回処理されるもの）

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

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

PPS

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