情報システムの開発
■システム開発の概要
■システム開発の形態
システムを外部に委託する事によって開発力を補う形態と、すでに開発された情報システムのパッケージを活用する形態がある。
一般的には、定番である様な情報システムは、パッケージの活用が有利であり、特殊な仕様が多い情報システムは、自社開発が有利である。そして、自社の開発工数が不足するところを外部に委託するというのが、基本的な判断基準といえる。
■システム開発の外部委託
①外部委託の形態
外部委託の形態は、委託する範囲や規模などによって異なる。従来では、工数で提供するものが多かったが、最近ではシステム単位で開発を請け負う様な形態が主流となっている。ＳＩやオフショア開発が増えてきている。
| ①ＳＩ |
|---|
| システムインテグレータは、顧客の業務内容の分析とその課題解決に合わせた情報システムの企画、開発、運用等の業務を一括して請け負う業者の事である。 規模が大きくなると、情報システム全体を最適に構築する為には、非常に高度なスキルが必要であるが、これを顧客に代わって行うのがＳＩの役割である。 |
| ②オフショア開発 |
|---|
| オフショア開発とは、ＳＩなどが発注元となり、システム開発を比較的人件費が安い中国やインドなどの海外のシステム開発業者に委託する事である。海外であるので日本の常識が通用しないので、要求仕様を正しく伝達する事に注意しなければならない。 |
②システム開発の外部委託時の留意点
客観的基準による外部委託の評価・選定
他社のシステム開発力は、わかりづらいので客観的にシステム開発力の成熟度を示すＣＭＭの利用が有効になる。
ＣＭＭ（Capability Maturity Model）は、組織の能力を向上させるためのモデルであり、いくつかの種類がある。通常は、「ソフトウェア能力成熟度モデル（ＳＷ－ＣＭＭ）」の事をさす事が多い。
| ＣＭＭのレベル | |
|---|---|
| 最適化しているレベル （レベル５） |
技術・要件環境の違いによって、標準プロセスを最適化し、持続的に改善できる段階 |
| 定量的に管理されたレベル （レベル４） |
標準化されたプロセスを定量的に測定し予測が可能な段階 |
| プロセスが管理されたレベル （レベル３） |
組織として一貫した標準プロセスを持っており、成果物が明確に出来ている段階 |
| 基本的な管理のレベル （レベル２） |
特定個人に依存した経験則による管理が出来ており、規律がある段階 |
| 混沌としているレベル （レベル１） |
場当たり的で一貫性がなく、プロセスが確立されていない段階 |
委託先への書面による要求事項の伝達
ＲＦＰ（Request For Proposal：提案依頼書）と呼ばれる文書で情報システムについて求める内容を明示しておく。
ＲＦＰには情報システムの概要、予算、納期、保証要件、契約条件などが記述され、通常、受託側はＲＦＰを確認した上でシステム提案書を作成する。
■システム開発の方法
①システム開発の工程
システム開発とは、ソフトウェア開発だけではなく、情報システムの構想から導入までの一連の行為を指している。この工程全体は、ＳＤＬＣ（System Development Life Cycle）と呼ばれている。
②ウォーターフォール・モデル
ウォーターフォール・モデルは、ＳＤＬＣの工程に合わせて開発する方法であり、滝（ウォーターフォール）の流れのように逆流することなく、順を追って進める。工程ごとの成果物が明確になっており、全体の進捗が管理しやすい特徴を持っている。
また、工程ごとに品質をつくり込んでいく考えがあり、各工程の最後にレビューを行い、成果物を確認する方法を取る。逆戻りしない事が原則となっているが、現実には前の工程に戻らないと対応できない様な問題が発生する事もある。この様な場合は、多大な工数を要してしまう為、結果として非効率になる事が多い。
③システム開発方法論の発展
ウォーターフォール・モデルの問題点を克服する為に、スパイラルモデルやプロトタイピングといった開発方法が利用される事もあるが、それぞれ一長一短があり、システム開発の規模や特性によって、方法を選択する必要がある。
| ①スパイラルモデル |
|---|
| 開発する情報システムを、設計段階で独立性の高いサブシステムに分解し、サブシステムごとに設計－開発－確認を何度も繰り返す事で徐々に完成を目指す手法である。 繰り返しのつど、開発上の不具合点を改善していく事が出来るので、経験の少ない業務システムや新しい開発技術を採用した場合に用いられる事が多い。ただし、いくら繰り返しても仕様が決まらず、結果として非常に効率が悪くなるという問題点もあり、注意が必要である。 |
| ②プロトタイピング |
|---|
| プロトタイプとは、ひな型・試作品の事である。プロトタイピングは、出来上がりの運用イメージなどを仕様確認の段階で作成し、イメージのズレを事前に排除する方法であり、作成後に修正するより手戻りが少なくて済む。比較的小規模な開発に向いている。 |
④アジャイル開発手法
スパイラルやプロトタイピングの良さを活かしつつ、これらの問題点を排除した開発方法論として確立されたのがアジャイル開発手法である。
| ①ＲＡＤ |
|---|
| システム利用者を含む少人数のチームを構成し、プロトタイピング手法で進める開発手法である。 ＲＡＤでは、無制限に設計・開発・テストのサイクルを繰り返さないように「タイム・ボックス」と呼ぶ期間を設けておき、期間がおわれば強制的に次に進むようにしている。 |
| ②ＸＰ |
|---|
| スパイラル型システム開発手法であり、短いサイクルで設計、プログラム、コーディング、テストを連続して繰り返し、短期間に精度の高いプログラムを開発する事を狙いとしている。 「シンプルデザイン」、「リファクタリング」、「ペアプログラミング」、「スモールリリース」、「週40時間労働」、「オンサイト顧客」など、ＸＰには12個の実践項目がある。 |
■システム開発工程
■各システム開発工程の内容
①システム化計画
システム化計画では、まず現行の業務がどのように行われているかを調査・分析し、現行の業務フロー図（As-Is）を作成する。これに対し、経営戦略上の狙いからあるべき業務プロセスが設計され、目指すべき業務フロー図（To-Be）を作成する。次に目指すべき業務フロー図から情報システム化する範囲と内容を決定し、大まかな情報システム化の規模を見積もる。これらをもとにシステム開発の体制とスケジュールを決める。ＲＦＰ：提案依頼書は、この段階で委譲先に提出される。
②要求定義
情報システムの利用者の要求を分析し、明確に定義する段階である。この定義があいまいなまま設計に入ると、設計で矛盾が生じたり、利用者のニーズとの不一致が起きたりし、品質悪化や納期遅延の原因となる事が多い。また、要求定義が終わった段階で、情報システムの処理概要、主要な入出力の種類、システム基盤で必要なサーバやネットワーク機器などが決まり、設計以降に必要なシステム開発コストとスケジュールがより詳細に決定できる。
③外部設計
要求定義をもとに新システムの持つべき機能を明確にし、システム概要を設計する。情報システムの利用者からみた時、利用者からも見える部分を「外部」、見えない部分を「内部」と位置づける。その「内部」までは入らず、「外部」から見て設計するので外部設計と呼ばれる。
具体的には、要求定義を確認し、オンライン画面やレポートの設計、コード設計、論理データ設計を行う。また、比較的規模が大きなシステムの場合は、この段階で独立したサブシステムに分割し、以後の作業や管理が分担できるように工夫する。
④内部設計
外部設計で出された機能について、新システムのプログラム開発ができるレベルまで、システムを詳細に設計する。システム詳細設計やシステム機能設計と呼ばれる事もある。具体的には、外部設計書を理解した上で、システム機能をさらに分割し、親子関係に構造化していく事で、開発が必要なプログラムの仕様を決める。入出力情報は、プログラミングが可能な詳細レベルまで設計し、データベースは物理データ設計を行う。
⑤プログラム設計
内部設計で分割されたプログラムごとに内部構造を設計する。プログラムを構成するモジュールという単位に分解し、コーディングが行えるように「プログラム設計書」を作成する。
⑥コーディング
プログラム設計書に基づき、モジュールごとにアルゴリズムを決め、プログラミング言語でコーディングする。フローチャートを作成し、メンテナンスしやすいプログラムにする事が必要である。その技法のひとつに順次、反復、分岐の３つの論理構造だけでプログラムを組む、構造化プログラミングという方法がある。
⑦単体テスト
コーディングしたプログラムごとに行うテストである。単体テストは、コーディングした全てのロジックがテストされる必要があり、内部構造を確認しながら行い、どのロジックを通って、ある結果に至ったのかを確認するテストを行う。この様なテストをホワイトボックステストと呼ぶ。
⑧結合テスト
複数のプログラムを組み合わせて行う結合テストである。階層化されているプログラム群を組み合わせていく結合テストでは、テストを行う順番によってトップダウンテストとボトムダウンテストに分類される。
トップダウンテストは、上位のプログラムから順番に結合しながらテストする方法であり、結合していない下位のプログラムの代わりにスタグと呼ばれる仮のプログラムを用いる。ボトムアップは、その逆でドライバと呼ばれる仮のプログラムを用いる。
⑨システムテスト及び運用テスト
システムテストは、設計段階で出された機能単位で行うテストであり、システム開発サイドが単独で行う最後のテスト工程である。その次に行う運用テストは、利用者サイドが参加し、実際の業務を想定したテストを実施する。通常、システムテストや運用テストでは、テスト対象を中身が見えない箱とみなし、インプットに対して期待通りのアウトプットが出されるかを確認するテストで、このようなテストをブラックボックステストと呼ぶ。
■ＤＯＡ
①ＤＯＡの考え方
業務の自動化・コンピュータ化といったシステム開発が主流であった頃は、システム化の範囲も比較的狭く、業務機能をシステム化するＰＯＡ（Process Oriented Approach：プロセス中心アプローチ）にも合理性があった。しかし、より戦略的な情報システムが求められシステム化の範囲が広がった事に加え、経営環境の変化が激しくなり、情報システムにもより速い変化対応力が要求されるようになった。このような背景から、経営環境の変化に影響を受けやすい業務プロセスではなく、より安定したデータに着目したＤＯＡ（Data Oriented Approach：データ中心アプローチ）の注目度が高くなった。ＤＯＡの原則に「one face in one place（一つの事実は一か所で管理）」がある。これは、業務システムごとにデータを重複して持つのではなく、データを一元的に管理しようとする考え方である。
■ＯＯＡ
①ＯＯＡとオブジェクト
オブジェクトには、「もの」「対象」「目的」などの意味があるが、ＯＯＡ（Object Oriented Approach：オブジェクト指向アプローチ）でのオブジェクトは、単純な「もの」だけではなく、「もの」がもつ「振る舞い」にも着目して、システムを開発する方法である。関連するデータの集まりと、その手続きをオブジェクトとしてとらえ、オブジェクト毎にカプセル化し、あたかも部品を利用するようにそれらを組み合わせる事で効率的にシステムを構成しようとする考え方である。大規模なシステム開発では、主流な考え方となっている。また、オブジェクト指向の考え方でプログラミングすることを、ＯＯＰ（Object Oriented Programming：オブジェクト指向プログラミング）といい、これに対応しているＣ＋＋やＪＡＶＡなどのプログラミング言語をオブジェクト指向プログラミング言語という。
②オブジェクトとは
| ①属性 | 固有の姿、形、性質などオブジェクトの形態 |
| ②操作 | オブジェクト固有の振る舞い |
| ③関係 | ほかのオブジェクトとの関係 |
| ④アイデンティティ | ほかのオブジェクトとの違いを識別するもの |
これらの特性が同じであるオブジェクト集まりをクラス（class）と呼び、そのクラスに属するオブジェクトをインスタンス（instance）と呼ぶ。クラスは階層構造を成し、集合のように「含む」「含まれる」という関係が成り立つ。含むクラスをスーパークラス、含まれるクラスをサブクラスという。
サブクラス ⇒ スーパークラス ・・・ 汎化
スーパークラス ⇒ サブクラス ・・・ 特化
サブクラスがスーパークラスの属性、操作、関係を引き継ぐ事を継承という。
③ＵＭＬ
ＯＯＡでもＤＯＡと同様に、対象となるシステムを図で表現するモデリングという方法をとる。ＯＯＡでは、モデリング言語としてＵＭＬを用いる。
| ①利用者の要求事項を要求図であるユースケース図に表現する。 |
| ②オブジェクトを抽出し、オブジェクトの静的な面に着目し、構造図であるクラス図とオブジェクト図を作成する。 |
| ③オブジェクトの動的な面のうち、オブジェクト間の相互作用をシーケンス図とコラボレーション図に表現する。 |
| ④オブジェクトの生成から消滅までをステートチャート図に表現する。 |
| ⑤オブジェクトの振る舞い（アクティビティ）の流れをアクティビティ図に表現する。 |
| ⑥物理的な実装を意識し、ソフトウェアの構成や構造をコンポーネント図と配置図に表現する。 |
■プログラミング言語
①プログラミング言語の発達
機械語 ⇒ アセンブリ言語（低水準言語）
人間が使う言語に近いものに改良されたものを高水準言語という。高水準言語は、実行する処理手続きの順番通り記載する手続き型言語と、処理の順番では無く、何をしたいかという事柄を記述する非手続き型言語に分類できる。
さらに、定型的な事務処理を行うアプリケーションを、より簡単に効率的にプログラミングできるようにした第４世代言語が登場してきた。４ＧＬと呼ぶ
②プログラミング言語の翻訳
プログラミング言語をコンピュータで実行する為には、機械語に変換する必要があるが、プログラミング言語で記述されたものをソースプログラムといい、コンピュータで実行可能な形にしたものをロードモジュールという。
ソースプログラムをロードモジュールに変換するプログラムが言語プロセッサと呼ばれるソフトウェアである。
| アセンブリ言語を翻訳するプログラムは、アセンブラと呼ばれる。 |
| 高水準言語の場合は、コンパイラやインタプリタが使われる。 |
| コンパイラは、一括して翻訳する |
| インタプリタは、１行ずつ機械語に変換していく。デバッグ（修正）には便利である。 |
③プログラミング言語の種類
| ①ＣＯＢＯＬ |
|---|
| データベースとの連携機能やファイル操作やレポート作成機能を有する事務処理向きのプログラミング言語で文法が英語に近い。主にメインフレームで利用される事が多い。 |
| ②ＦＯＲＴＲＡＮ |
|---|
| 科学技術用のプログラミング言語。数式に似た記述をそのままプログラムに利用できる特徴がある。主にメインフレームで利用される。 |
| ③ＢＡＳＩＣ |
|---|
| 初心者の教育用に開発されたプログラミング言語。インタプリタ型。発展させたVisual Basicがあり、ＧＵＩを駆使した高い開発生産性を目指したシステム開発用言語である。 |
| ④Ｃ |
|---|
| Ｃは、ＯＳなどの制御プログラムを記述するのに適したプログラミング言語であり、ＵＮＩＸの殆どは、Ｃで記述されている。Ｃをベースにオブジェクト指向に対応したものが、Ｃ＋＋である。 |
| ⑤Ｊａｖａ |
|---|
| Ｊａｖａは、オブジェクト指向のプログラミング言語であり、業務系システム開発のほか、携帯電話用アプリケーションなどにも利用されている。Ｊａｖａで記述したプログラムをコンパイルすると、Ｊａｖａ仮想マシン用のバイトコードが生成される。Ｊａｖａ仮想マシンとは、プログラムを実行するときに必要となるソフトウェアである。このような仕組みの為、Ｊａｖａ仮想マシンさえ搭載していれば、どのようなプラットフォーム（システム環境）でも同じプログラムを実行できる。 また、ネットワーク上にあるプログラムをダウンロードしてｗｅｂブラウザ上で動作可能なものをＪａｖａアプレットといい、ｗｅｂブラウザなしに単体で動作するものをＪａｖａアプリケーションと呼ぶ。 |
| ⑥Ｐｅｒｌ> |
|---|
| インタプリタ型のプログラミング言語。元々はテキスト処理を目的に開発されたが、ｗｅｂアプリケーションによく用いられる。利用者の入力情報によって表示内容を変更する様な動的なページを実現する為にＰｅｒｌとＣＧＩを組み合わせてｗｅｂアプリケーションが構築される。 |
| ⑦ＨＴＭＬ |
|---|
| マークアップ言語のひとつである。文章の一部を「タグ」と呼ばれる特殊な文字列で囲う事で、文章の構造や修飾情報を記述する言語であり、以前はＳＧＭＬが普及していた。ＨＴＭＬは、ＳＧＭＬの書式を踏襲しつつ、画像や音声などを含めた表現を可能にしている。 |
■ＣＡＳＥ
ＣＡＳＥは、コンピュータを利用して、情報システムの要求定義以降の各工程と導入後のメンテナンスを行う考え方である。ＣＡＳＥでは、ＣＡＳＥツールと呼ばれるシステム開発用のツールを用いて生産性の向上を実現する事ができ、システム開発成果物の一元化やプログラムの自動生成などが可能になる。
①上流ＣＡＳＥツール
要求定義や設計などの上流工程を支援するツール。ＤＯＡやＯＯＡに対応したものが多く、ＥＲＤなどの作成支援機能や成果物の一元管理機能を持つ。
②下流ＣＡＳＥツール
プログラム開発やテストなどの下流工程やシステムの保守を支援するツール。自動コーディング機能、テスト支援機能などを持つものがある。最近では、オブジェクト指向プログラミングに対応したものが多い。
③統合ＣＡＳＥツール
上流ＣＡＳＥツールと下流ＣＡＳＥツールの両方の機能を持ち、設計情報を連携する事でより高い生産性の達成を狙ったものである。
■プロジェクト管理
■プロジェクト管理とは
①プロジェクト管理の必要性と概要
システム利用者が求める品質、コスト、納期に応える情報システムを限られた資源を有効に使用して実現する事を目的としている。昨今の経営情報システムは、経営への影響度が非常に大きく、短納期と同時に高品質も要求されており、プロジェクト管理の重要性は、ますます高まっている。
②ＰＭＢＯＫ
民間団体のＰＭＩが作成したプロジェクト管理に関する知識と能力の体系である。現在では、ＩＳＯ１０００６のベースとなっている。
ＰＭＢＯＫは、「立ち上げ」「計画」「実行」「コントロール」「終結」という５つのフェーズと９つの知識エリアから構成される。
| ①統合マネジメント |
|---|
| プロジェクトの様々な要素を調和させる為の管理であり、統合する為に必要なプロセスを定義する。 |
| ②スコープ・マネジメント |
|---|
| 目的を範囲の定義や検証・変更等の管理であり、プロジェクトを成功させる為に必要な作業を過不足なく洗い出す。 |
| ③タイム・マネジメント |
|---|
| プロジェクトを所定の期間内に完了させるために必要なプロセスを定義。 |
| ④コスト管理 |
|---|
| プロジェクトを所定の予算内で完了させるために必要なプロセスを定義。 |
| ⑤品質マネジメント |
|---|
| プロジェクトが確保すべき品質を管理する為に必要なプロセスを定義。 |
| ⑥人的資源マネジメント |
|---|
| プロジェクトを組織化し、管理する為に必要なプロセスを定義する。 |
| ⑦コミュニケーション・マネジメント |
|---|
| プロジェクトのステークホルダーなどとのコミュニケーションを円滑に進めるために必要なプロセスを定義する。 |
| ⑧リスク・マネジメント |
|---|
| プロジェクトに関するリスクを管理するために必要なプロセスを定義する。 |
| ⑨調達マネジメント |
|---|
| 外部からの物品やサービスの調達にかかわる発注先の選定、引き合い、契約などの管理であり、これらの管理に必要なプロセスを定義する。 |
■プロジェクト管理で用いる手法
①見積もり手法
見積もりは、ＰＭＢＯＫのコスト・マネジメントに含まれ、システム開発において非常に重要である。
| ①ＣＯＣＯＭＯ法 |
|---|
| 開発するシステムについて予想されるコード行数に、開発者の能力や要求の信頼性といった補正係数を掛け合わせて算出する方法である。 |
| ②ファンクションポイント法 |
|---|
| 初期の段階で見積もる事が容易な画面やレポートなどの見積り数に一定の係数を乗じて全体の工数を見積る方法である。 |
②工程管理
ＰＭＢＯＫでいうとタイム・マネジメントに含まれる。重要なポイントは、計画を策定する事と、進捗状況を管理する事であり、特に工程を段階的に管理する事や先行関係を加味した管理が必要になる。
| ①ＷＢＳ |
|---|
| 計画立案時に用いられる手法であり、プロジェクト全体から作業を分割し、分割された作業を更に分解していき、これらを構造的に示した構成図である。ＷＢＳの最も下位にある作業を集めたものをワークパッケージを呼ぶ。 |
| ②ＰＥＲＴ | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| 工程管理手法のひとつであり、プロジェクト全体の各作業の先行関係をネットワーク図にする事で、各作業の日程を見積り、プロジェクト全体の所要時間を算出する手法である。さらに、時間的に余裕のない作業をつないだクリティカルパスを明らかにする事でプロジェクト全体の所要時間を短縮する事が出来る。 | |||||||||
| （ア） | ＷＢＳを作成し、作業を洗い出す。 |
| （イ） | 各作業が要する所要時間を見積もる。 |
| （ウ） | 作業の先行関係を明確にし、ネットワーク図を作成する。 |
| （エ） | プロジェクト全体の所要時間を算出し、完了タイミングを明らかにする。 |
| （オ） | 時間的に余裕のないクリティカルパスを見つけ出し、所要時間短縮を検討する。 |
③ＥＶＭＳ
恣意的になりがちな進捗管理を進捗度を金額換算する事により客観的に判断する手法である。ＥＶＭＳを使う事によって、スケジュールをコストの両面から計画とのずれを把握し、完了時期や完了時のコスト納期遅れや予算超過を高い精度で予測する事が出来る。ＥＶＭＳでは、横軸に時間、縦軸にコストを取る。まず計画段階でグラフを作成しておく。実行途上のチェックポイントで、現在までの実績に基づいて、出来高ベースのグラフとコストベースのグラフを記述する。
| ①ＰＶ | 出来高計画値 |
| ②ＥＶ | 出来高実績値 |
| ③ＡＣ | コスト実績値 |
| ④ＳＶ | スケジュール差異 |
| ⑤ＣＶ | コスト差異 |
| ⑥ＢＡＣ | 完了までの当初予算 |
| ⑦ＥＡＣ | 完了時見積り総コスト |
| ⑧ＶＡＣ | 完了時のコスト差異 |
| ⑨ＥＴＣ | 残作業見積りコスト |
【裏ワザ】覚えやすいメールアドレスでEメール上級者の仲間入り！
