カテゴリー: 3.システム開発

オフショア開発とは、国内企業が海外の企業や開発チームを利用してシステム開発を行うことを指す。

【メリット】

コスト削減
オフショア開発を利用することで、人件費や開発環境のコストが削減されるため、開発コストを抑えることができる。

人材の確保
海外には優秀なIT人材が多数存在するため、オフショア開発を利用することで、人材不足に陥ることなくプロジェクトを進めることができる。

時間の利用効率化
海外との時間差を利用することで、開発時間を効率的に活用することができる。例えば、日本の昼間に開発を進めて、海外の夜間に確認・テストを行うことで、開発時間を短縮することができる。

 

【デメリット】

コミュニケーションの困難
言語や文化の違い、物理的な距離が原因で、コミュニケーションがスムーズに行えないことがある。そのため、要件定義や設計など、技術的な詳細が必要な業務の場合は、コミュニケーション面で問題が生じることがある。

セキュリティ上のリスク
オフショア開発を利用することで、企業の機密情報が海外に流出するリスクがある。そのため、セキュリティ対策には十分に注意する必要がある。

品質管理の難易度
海外で開発されたシステムの品質を確保するためには、日本側のチェックが必要となるため、品質管理の負担が増加する。また、日本の品質基準と海外の基準が異なる場合もあるため、品質基準の統一が必要となる。

アジャイル開発とは、ウォーターフォール開発に代わるソフトウェア開発プロセスの一つで、開発プロセスの進捗状況を継続的に確認し、短いサイクルでリリースする手法である。

【メリット】

顧客とのコミュニケーションが密接
アジャイル開発では、開発チームと顧客が密接にコミュニケーションを取りながら開発を進めるため、顧客の要求に応えやすく、満足度の高い成果物を提供できる。

変更への対応が容易
アジャイル開発では、リリースサイクルが短いため、顧客の要求変更に対応しやすく、迅速な改善が可能になる。

開発プロセスの改善が継続的に行われる
アジャイル開発では、継続的に反省し、改善点を見つけることができるため、開発プロセスが改善され、より良い品質の成果物を提供できる。

 

【デメリット】

プロジェクトの進捗管理が困難
アジャイル開発では、進捗状況を短いサイクルで把握するため、プロジェクト全体の進捗管理が難しい。

ドキュメンテーションが不足する場合がある
アジャイル開発では、短いサイクルでリリースするため、ドキュメンテーションが不足する場合がある。

開発チームのスキルに依存する
アジャイル開発では、開発チームが高いスキルを持っていることが求められるため、人材確保が難しい場合がある。また、チームメンバーが脱退した場合にはプロジェクトに悪影響を与えることがある。

ウォーターフォール開発とは、ソフトウェア開発プロセスの一つで、要件定義・設計・実装・テスト・リリースといった工程を順番に進めていく手法である。

【メリット】

プロジェクトの進捗管理が容易
ウォーターフォール開発は、各工程が明確に区切られているため、進捗状況を把握しやすく、管理することができる。

プロジェクト全体を予測しやすい
各工程が明確に区切られているため、プロジェクト全体を予測しやすく、計画を立てやすい。

ドキュメンテーションが充実
ウォーターフォール開発は、各工程ごとに文書化が進められるため、ドキュメンテーションが充実し、後での修正や保守作業がしやすい。

 

【デメリット】

顧客の要求変更に対応しづらい
ウォーターフォール開発は、各工程が明確に区切られているため、顧客の要求変更に対応するのが難しい。

問題が見つかっても後戻りが難しい
ウォーターフォール開発は、各工程が順番に進められるため、問題が見つかっても後戻りが難しい。

リリースまでの時間がかかる
ウォーターフォール開発は、各工程が順番に進められるため、リリースまでの時間がかかる。特に、要求定義や設計などの前段階が時間を要する場合、開発の遅れにつながることがある。

フロント要件が進化して複雑化している。
インターネット初期（ホームページ時代）は、HTMLとデザインといったシンプルな要件だった。
web2.0なんて呼んだ時期には、CSSやSEO、CMSといったシステム的要素が加わってきた。
今やスマホ・タブレット対応も含め軽量化や高速化の要件もフロント要件に加わってきている。
その要件にあわせてレスポンシブデザインやJavaScript、APIといった知識もフロント要件に必要になってきている。
これって、システム要件となにが違うの？　な状態である。

ちょっと前ならHTMLを知っていれば多少は通用していたが、今ではシステムエンジニア的な要素が必要になってきている。
それを、フロントエンジニアと呼んでいるようだ。

いまや　システムエンジニア　≒　フロントエンジニア　である。

案件によっては、システムエンジニア（＝SE）の仕事ではなく、フロントエンジニアの仕事がほとんど、、というのが現実になりつつある。

 

 

 

 

 

 

 

 

 

システム開発の開発手法には、大きく３つの手法がある。
・ウォーターフォール型
・プロトタイピング型
・アジャイル型
また、それぞれを組み合わせたハイブリッド型も最近のトレンドである。

全ての基本（基礎）は、ウォーターフォール型開発である。
ウォーターフォール型開発が理解できてこそ、プロトタイピング手法であり、アジャイル手法である。
未熟な（悪質な？）開発ベンダは、ウォーターフォールの簡易版（プロセスを省略したり、成果物を省略する＝つまりは手抜きである）をアジャイル手法と呼称する傾向にある。
いわゆる、安かろう悪かろうの炎上プロジェクトの典型である。
※何かを省略するのがアジャイル開発ではない。

■ウォーターフォール型開発
ウォーターフォール＝滝のように、上流から下流へプロセスが連なる開発手法である。
具体的には、企画→要件定義→設計→開発→テスト→受け入れといったシステム開発のV字モデルに準拠する。

■プロトタイピング型開発
ウォーターフォール型開発の発展系であるが、上流工程（要件定義～設計）の段階でプロトタイプ（＝モック）を作成し、UI/UXを優先に設計を進める手法である。

■アジャイル型開発
アジャイル型とイテレーション型と大別される。
どちらも反復開発なのだが、目的が異なる。
・アジャイル＝結果・成果重視
・イテレーション＝プロセス重視
プロセス重視のイテレーションは、超短期型ウォーターフォールとも言える。
ウォーターフォールは、プロジェクト全体を半年や１年２年といった比較的長期で考える。
アジャイルやイテレーションは、プロジェクトを細分化し１ピースを１週間や１ヶ月といった短期間のサイクルで考え、反復する事を前提としている。

プロジェクト体制は、大きくはユーザ側体制とベンダ側体制になる。
基本体制は、ユーザ側もベンダ側もPM・PL・担当・メンバの構成となる。
その上位にシステムオーナとステコミ（ステアリング・コミッティー）が存在する。（明確ではない場合もあるが、相当する役割は必ずあるハズ）
ステコミは、開発規模が大きい時に必要な組織で「運営委員会」を示す。
目的は、ほぼPMOと同じだが、より上流思考（経営、マーケティングなど）の判断となる。

システム開発の体制は、既に　PM・PL・SE・PG　が画一化されている。
※そうでない場合は、革新的か原始的かのどちらかだろう。

フロント体制は、比較的トレンドがあり、最近は細分化される傾向にある。
兼務することも多く、プロデューサ兼ディレクタ兼デザイナも珍しくない。
最近はフロント要件とシステム要件の境界が曖昧になり、フロントエンジニアがシステム要件を担うシーンが多くなっている。
UI/UXを重視する場合は、アートディレクタを別途たてる場合もある。
都市伝説かもしれないが、フロント体制はいろいろな意味で比較的「ゆるい」感じは否めない。

システム開発のV字モデルとは、
ウォーターフォール型開発手法をモデル化したもので
・上流工程（設計・開発）とテスト工程の関係性
・ユーザ主幹のプロセスと開発ベンダ主幹のプロセス
が理解できる。

V字モデルでは、各工程での納品物定義も表されており
・システム要件定義工程では、受け入れテスト計画および仕様書
・基本設計工程では、システムテスト計画および仕様書
・詳細設計工程では、結合テスト計画および仕様書
が、必要（＝準備できる）と理解できる。

V字モデルを意識してプロジェクトマネジメントを実践することによって
目先の工程管理ばかりにとらわれず
後工程も含めたマネジメントを計画・実行できる。

WBSとは、Work（作業）Breakdown（分解）Structure（構造化）である。
Workは、Task（タスク）と同意。
構造化は、フォーマット定義があれば難しく考えなくともよいので
簡単に言えば「タスクの分解」となる。

タスクの分解をしましょう！と、言うと３つのプロセスになるようだ。
１、無邪気に考える。　　　　＜－－７割くらい？
２、ボトムアップで考える。　＜－－２割くらい？
３、トップダウンで考える。　＜－－１割いるかな？

そこで『網羅的』にね！と、条件を追加すると・・・
１、無邪気に考える。　　　　＜－－網羅的ではないと気づく
２、ボトムアップで考える。　＜－－考えやすい
３、トップダウンで考える。　＜－－複雑になればなるほどコッチ

となる。
これはナゼかというと、たとえば研修のような簡単で単純な（擬似的な）プロジェクトであればあるほどボトムアップが効率的であるが、実際の（複雑怪奇な）プロジェクトではボトムアップはほとんど通用しない場合が多い。
（・・・ということを研修等で説明するのは難しい）

ボトムアップ／トップダウンのどちらが網羅的になるのか、、、は、各々の経験値・経験則になると思うが
個人的な見解は「網羅的に・・」という意味では、圧倒的にトップダウンの考え方で実施するべきと考える。
「やりやすさ・・考えやすさ・・」という意味では、ボトムアップの考え方が選ばれる傾向にあると思うが、正直には実践向きではない。

いわゆる実践的なWBSとは、工程管理と進捗管理が可能なWBSである。
逆に言うと、工程管理と進捗管理ができないWBSは作成する意味がない。

システム開発のプロセスの基本といえば、ウォーターフォールモデルである。
上流工程から下流工程まで、水が流れるがごとくタスクが展開するプロセスの呼称である。
昨今は、ウォーターフォールをあえて採用せず、アジャイル・イテレーション・プロトタイプ・ハイブリッドなどなど様々な手法を採用している開発ベンダは多い。
全ての基本はウォーターフォールモデルである。

■ウォーターフォールの工程

 

■企画（戦略）
・KGI／KPI
やりたいことはなんだ？明確なゴールを決める。
ゴールに向けてマイルストーンを設定する。
・QCD
Quality：品質，Cost：費用，Delivery：納期を決める。
ドリームプランにならないように、どのレベルの品質を目指すか、
いつまでに、費用対効果を明確に具体的に「見える化」する。
・５W1H
何のために（目的）、だれが（体制）、何を、いつまでに、どうするか
を整理して計画する。

■要件定義①・・・ユーザ主導の業務要件定義
わかりやすいのは業務フローを見える化する。
業務フローのAsIs－ToBeが定義できれば、今はこうだけど、ああ成りたいが具体化され、要件整理ができる。
要件が整理できたら、システム開発ベンダ向けに提案依頼書：RFP（Request For Proposal）を作成する。
※情報提供依頼書：RFI（Request For Infomation）でも構わない。

■要件定義②・・・開発ベンダ主導のシステム要件定義
ユーザが思い描いている要件を、開発ベンダがどのように実現していくかをインフラ構成・画面仕様・バッチ処理などのシステム要件（仕様）に整理する。
ーー＞設計工程以降の見積り根拠を決める。

プロジェクト計画として、スケジュールや体制、マネジメント方針を決める。

■設計・・・基本設計と詳細設計
基本設計は、ユーザが積極的に介入するべきシステムの方向性を決める工程となる。システム構成（コンテキスト）、アーキテクチャ設計、データベース設計（論理設計）、機能一覧、画面設計（UIスケッチ）、インターフェース一覧など

詳細設計は、開発ベンダ主導でシステムの実装方法を決める工程となる。
データベース設計（物理設計）、機能詳細仕様、画面詳細仕様（UI仕様）、バッチ処理仕様、インターフェース詳細仕様、ログ仕様、バックアップ仕様など

■開発・・・単体テストも含む
開発ベンダ主幹の工程になる、ユーザは進捗管理の介入のみになるが
V字モデルを意識して後工程準備も含めてプロジェクト管理を継続する。

■テスト・・・結合テストとシステムテスト
シングルベンダやマルチベンダ、オフショアなどプロジェクト体系によって、テスト工程や複雑さ難易度は変わる。
インフラなど様々な周辺環境の状況を含め計画・実行・検証が必要になる。

■受入れテスト
開発ベンダの開発フェーズ（システム要件定義～システムテスト）が完了し
ユーザが品質検証する工程になる。
リリースを判定する（＝リリースするに値する品質が保たれている事を保障する）と同意。第三者（テストベンダ）に委託する場合もある。

■移行
リリース判定され本番稼動承認されたシステム（データを含む全ての資産）を、開発環境から本番環境に移行すること。
開発規模によっては、移行計画書・手順書（リハーサル）を準備する。

■監視・保守
リリース直後の短期間の特別監視を指す。
特別な監視条件は、プロジェクト毎（監視条件、ログレベルなど）に定める。

■運用
リリース後の通常運用。