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

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

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