2 2 1
Download
1 / 88

? 2 ? ???????????? 2-1 ????????????? - PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on

第 2 章 システム化の全体をつかむ 2-1  システム化のプロセス全般. 株式会社ディー・アート 上野淳三・広田直俊・白井伸児 [ 著 ] 「システム設計の考え方」. 全社情報化中長期計画. 会社の情報化計画は、経営計画とリンクされていなければならない。 事業部門の経営計画の中から情報化ニーズを吸い上げる必要がある。. 経営計画と情報化計画. 規模の大小を問わず、いかなる企業も中長期経営計画を作成する。 計画には、人、物、金の他に情報も重要な経営資源であるという認識の下に、情報化計画が含まれるのが一般的である。. 経営計画と情報化計画 2.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '? 2 ? ???????????? 2-1 ?????????????' - basil


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
2 2 1

2章 システム化の全体をつかむ2-1 システム化のプロセス全般

株式会社ディー・アート

上野淳三・広田直俊・白井伸児[著]

「システム設計の考え方」


2 2 1 1343845
全社情報化中長期計画

  • 会社の情報化計画は、経営計画とリンクされていなければならない。

  • 事業部門の経営計画の中から情報化ニーズを吸い上げる必要がある。


2 2 1 1343845
経営計画と情報化計画

  • 規模の大小を問わず、いかなる企業も中長期経営計画を作成する。

  • 計画には、人、物、金の他に情報も重要な経営資源であるという認識の下に、情報化計画が含まれるのが一般的である。


2 2 1 1343845
経営計画と情報化計画2

  • 情報は人、物、金と同列の概念ではなく、それらを効率的に活用するための手段である。

  • 会社の情報化計画は、会社の事業計画をにらんで作成される。

  • 情報化はそれ自体に意味があるわけでなく、あくまで経営を支援する手段ということである。


2 2 1 1343845
全社情報化中長期計画

  • 立案はシステム部門が担当する。

  • 各事業部門からの事業計画の中にすでに含まれている。

システム部門から見て、情報化が必要と思われるにもかかわらず、計画されていない場合

システム化の働きかけを行い、各部門の情報化計画を全社的にとりまとめる。



2 2 1 1343845
全社情報化中長期計画3

  • 各事業部門で共通に利用できると思われるハードやソフトは、どのようなものであり、どれくらいの投資額になるかを大まかに見積もる。


2 2 1 1343845
全社情報化中長期計画4

  • 全社情報化中長期計画の要点

    各事業部門のシステム化計画の適否や優先順位を決定

    それらをまとめて全社共通インフラ(ハード、ソフト)計画を作成

    全社的な投資計画や推進方針などを立案すること



2 2 1 1343845
全社情報化中長期計画6

  • 情報化の案件は専門的な検討が必要になる。

      例:案件はシステム開発の優先順位や全社共通のインフラや情報技術                       事項など

  • ある程度以上の規模の企業では、経営会議の事前審議を行なう専門委員会を設置している場合が多い。


2 2 1 1343845
全社情報化中長期計画7

  • 経営会議での審議の二つの要点

    • 提出された情報化計画が中長期的に経営にどう寄与するかということ。

    • 投資額として会社の実情に見合っているかどうかということ。


2 2 1 1343845
全社情報化中長期計画8

  • 情報化投資は省力化の効果のあるものは、ほぼ実現している企業が多いこともあり、効果が定量的にわかりにくい。



2 2 1 1343845
費用の年度計画

  • 一般に、各事業部門及びシステム部門は、年度計画(上期、下期)を立案する。

  • 上期末には当初の下期計画を見直す。

    各部門にとって活動計画の全般にわたる費用の予算・実績をトレースする作業である。


2 2 1 1343845
費用の年度計画2

  • 投資額は、ハード関係は固定資産として、またソフト外注費は無形固定資産として償却され、各期に費用として計上される。

  • 償却期間は、ハードは取得金額や機器構成によって異なるが、ソフト外注費は5年間に固定されている。

  • ハードはリースする企業も多く見られる。



2 2 1 1343845
費用の年度計画4

  • 費用の年度計画の数値が今後の投資計画すなわちシステム計画に影響を及ぼすことがあるということを知っておかなければならない。


2 2 1 1343845
費用の年度計画5

  • 今日、すべての企業が情報化の重要性を認識しているが、情報化の効果は短期的な利益の向上につながることは少ない。

  • 長期的な企業の体質向上などが主目的になることが多いので、経費削減の対象になりがちである。


2 2 1 1343845
費用の年度計画6

  • 各事業部門に情報化のコスト意識を持ってもらうために、

    システム部門の費用は、各事業部門に直接付け替えられる

    または予算立案時に費用配賦するという制度をとっている企業が多い。


2 2 1 1343845
システム開発計画

  • システム開発計画の作成は、一般に次のような手順で進む。

    1.システム開発の手順を明らかにした上で、現状の調査分析を行う。

    2.業務設計、システム機能の検討へと進み、システム構想を作成する。

    3.システム構想を実現させる手順を検討し、システム開発計画を立案する。


2 2 1 1343845
システム開発計画

投資案件として、その企業で想定された決済基準に従い、委員会、経営会議の承認を受ける。

承認が得られれば、次のステップであるシステム開発を進めることができる。


2 2 1 1343845
システム開発計画

経営会議の承認を得るためには?

 ・ユーザー部門、システム部門、事務者、SEと共に、システム構想やシステム化に伴う業務の見直し、ソフトハウス等の利用などについて検討する。



2 2 1 1343845
システム開発計画に盛り込むべき必要事項

経営者の関心 

・費用対効果がどうなるか

つまり・・・

→経営者に該当条件の定性効果をわかりやすく説明し、了承してもらうことが大切。


2 2 1 1343845
システム開発計画に盛り込むべき必要事項

コツ

→効果を体言止めで表現せずに、「動詞形」で表現する。

例)

  • 「在庫の縮小」→「3ヶ月分の在庫を1ヶ月分に減らす」

  • 「納期の短縮」→「納期を1ヶ月から20日に短縮する」

  • 「決算日程の短縮」→「財務諸表の出力を月初10日から月初3日に早める」


2 2 1 1343845
システム化に伴う業務の見直し

  • SLCP-JCF98委員会が作成した「共通フレーム98(SLCP-JCF98)」では、業務の視点から見たソフトウェアのライフサイクルを、

     企画プロセス→開発プロセス→運用プロセス→保守プロセス

    といった4つのプロセスでとらえている。


2 2 1 1343845
システム化に伴う業務の見直し

  • 企画プロセスと開発プロセスの関係を業務の視点から下の図のように概観している。


2 2 1 1343845
システム化に伴う業務の見直し

  • 企画プロセスを業務層・利用層に位置づけ、開発プロセスの開発層とは別の層に区分している。

  • 業務層・利用層では、企画プロセスのみを行なうだけでなく、開発プロセスに入ってからも、開発層の開発業務と並行して、業務詳細設計を行なう。


2 2 1 1343845
システム化に伴う業務の見直し

システム化で効果を上げるには?

→業務そのものを見直し、コンピュータ化するべき。

 しかし、業務ルートを変えることで効率化でることも多くあり、コンピュータ化するまでもないという結論に達することもある。


2 2 1 1343845
システム化に伴う業務の見直し

・人権上の問題や権限などの問題より、現状業務を変えることは難しい。

→どうすればよいか?

・ユーザ部門をコンピュータ化以前の問題と批判するだけなく、システム部門から業務自体を改善するように助言すべき。


2 2 1 1343845
システム化に伴う業務の見直し

  • ユーザを無視して突っ走っても、本当にユーザに役立つものにはならないので、あくまでもユーザが真剣に考えるように、うまく関わってゆくことが大切である。

  • 「やりすぎてもいけないが、無関心もいけない」というさじ加減がユーザ部門との係わりの難しさであり、工夫が必要な点である。


2 2 1 1343845
外部SEなどのシステム開発計画への参画

  • 企画プロセスは顧客の中でもユーザ部門の仕事だが、これをコンサルティング会社やベンダーやソフトハウスが中心的役割を担う場合がある。

     これをソリューションと呼ぶ。


2 2 1 1343845
外部SEなどのシステム開発計画への参画


2 2 1 1343845
外部SEなどのシステム開発計画への参画

  • 図2-5のようなケースでは、顧客(ユーザ部門・システム部門)とコンサルティング会社やソフトハウスのSEとでプロジェクトチームを編成して、調査分析やシステムの仕様検討といった作業を進める。


2 2 1 1343845
外部SEなどのシステム開発計画への参画

  • システム開発計画が完了し、開発を外部委託するとなれば、プロジェクトチームが検討したシステムの要求仕様書が開発者に対する指示になる。


2 2 1 1343845
外部SEなどのシステム開発計画への参画

つまり・・・

 開発者が行う開発作業は、ユーザ側から提示された要求仕様書を確認する要件定義からスタートし、開発プロセスは、以下のようになる。

要求定義→システム設計→プログラム開発


2 2 1 1343845

システムの開発過程

   ・必要に応じて進めていると、システムが

   完成している

   ・人間的な要素が大きく、常に意味を考慮に入れ

   て作業を行う

 開発効率の上昇および品質改良のために、様々な開発プロセスモデルが誕生

システム開発プロセス(1)


2 2 1 1343845
システム開発プロセス(2)

具体的にはどのようなモデルが開発されたの

か??

大きく大別すると

・ウォーターフォールモデル

   ・ノンウォーターフォールモデル


2 2 1 1343845
システム開発プロセス(3)

システム開発プロセスの大まかな流れ

要件定義

システム設計

プログラム開発



2 2 1 1343845
ウォーターフォールモデル(1)

  • ウォーターフォールモデルとは

      ・開発プロセスをウォーターフォール(滝)の

       ように、順次実行していくやり方。

      ・大規模システムに有効であるが、バリエー

       ションが豊富なことから、原則的にどんな

       システムにも対応可能。



2 2 1 1343845
ウォーターフォールモデル(3)

同じウォーターフォールモデルでも、図2-8

のようなV字型モデルと呼ばれるものも存在


2 2 1 1343845
ウォーターフォールモデル(4)

  • V字型モデル

      ・要件定義を起点に下り、プログラミングを

       境に上っていく

      ・前半部は開発そのもので、品質の作成

      ・後半部は完成して品質のテストの実行


2 2 1 1343845
ウォーターフォールモデル(5)

  • ウォーターフォールモデルの問題点

      ・開発期間が長い場合に、要件定義に存在

       する欠陥の発見が遅れる(特にV字型モデル)

この欠点を改善したのが、「ノンウォーターフォールモデル」


2 2 1 1343845
ノンウォーターフォールモデル

  • 基となっている開発手法:プロトタイピング法

  • 初期段階でシステムのプロトタイプをユーザー

     部門がチェック

  • 現実的には、サブシステム単位で作成し、部

     分的に更新してユーザー部門がチェックし、

     プログラムの改善を行う。


2 2 1 1343845
スパイラルモデル

ユーザーの反応を見ながら、スパイラル的に

行うことから、スパイラルモデルとも呼ばれる。


2 2 1 1343845
システム保守の重要性

  • システムライフサイクルは、開発、運用(保守)、再開発

  • 現実にはシステム保守が重要な意味を持ち、長期的にみるとコストもかかってくる。

  • 開発期間は平均2~3年程度に対し、保守期間は一般的に10年間程度。


2 2 1 1343845
システム保守の重要性

  • システム保守は大きく分類すると、「修正のための保守」と「改訂のための保守」の2種類

  • システム開発後、地道なシステム保守こそがシステムを使いやすくし、業務の効率アップにつながるといっても過言ではない。



2 2 1 1343845
システム保守から学ぶこと

  • システム保守から学ぶことは少なくない。その理由としては以下の2つがある。

    1.システム効果の確認

    次の開発へのフィードバック

    2.優れたシステムの学習及び業務知識の吸収

    次の開発への準備


2 2 1 1343845

2-2 システム化における各種手法


2 2 1 1343845
システム化における各種方法(1)

システム開発状況の視覚化=「文書化」



2 2 1 1343845
システム化における各種方法(3)

DFD:フローとストックを記述するもの。

ER図:DFDに既述されたデータストック(データストア)を正規化し作成するもの。


2 2 1 1343845
システム化における各種方法(4)

・文書化の留意事項 

1、DFDやED図以外の記述は一般技術文章に従う。

2、仕様書には目的を必ず記述する。

3、文章を構造化する。や主旨

4、次の工程の担当者にわかりやすいように、フォーマットを統一する。


2 2 1 1343845
システム化における各種方法(5)

  • 見積手法

  • ソフトウェア の見積もりは非常に難しい。

  • 上流工程ほど見積と実績の差が大きくなる。


2 2 1 1343845
システム化における各種方法(6)

・2・4・2・3の法則


2 2 1 1343845
システム化における各種方法(7)

  • 概算・積算見積法

    ・概算法は過去のソフトウェアの経験に基づいて見積もる方法。

       ・積算法は作業を洗い出しその工数を過去の経験によって積み上げる方法。


2 2 1 1343845
システム化における各種方法(8)

  • 見積モデル

    プログラムのステップ数から工数を見積方法。

    Dotyモデル、COCOMO、Putnamモデルなど。

    工数=F(ステップ数、開発環境係数、開発要員係数・・・)


2 2 1 1343845
システム化における各種方法(9)

  • ファンクションポイント法(FP法)

      ・見積方法のひとつ。

      ・良く使われる手法の一つ。  


2 2 1 1343845
スケジューリング手法

  • 第1次作業計画

      システム稼動時期を確定し、システム開発の承認を得ること。

  • 第2次作業計画

      稼動時期を遵守するため、より詳細で実行可能なマスタースケジュールやワーキングスケジュールを作成する。



2 2 1 1343845
WBSについて

  • WBSとは…

      要件定義から外部設計、内部設計等への過程における作業を洗い出し構造的に表現したもの。



2 2 1 1343845
ネットワークダイアグラム

ネットワークダイアグラムとは…

WBSで洗い出された作業順序を決定し、作業計画を立てる際に用いる表記法。

  • プレジデンスダイアグラム法

  • アローダイアグラム法

     の2種類がある。


2 2 1 1343845

作業を表現するのにノード、作業順序を表現するのにアローを用いる表記法。作業を表現するのにノード、作業順序を表現するのにアローを用いる表記法。

プレジデンスダイアグラム法


2 2 1 1343845

作業を表現するのにアロー、作業順序を表現するのにノードを用いる表記法。作業を表現するのにアロー、作業順序を表現するのにノードを用いる表記法。

アローダイアグラム法


2 2 1 1343845
クリティカルパス作業を表現するのにアロー、作業順序を表現するのにノードを用いる表記法。

  • クリティカルパスとは…

      計画全体の完了期日に影響を与える工程「クリティカル」の経路のこと。


2 2 1 1343845

作業の開始日、終了日、期間などを簡単にして図に表したもの。作業の開始日、終了日、期間などを簡単にして図に表したもの。

ガントチャート


2 2 1 1343845

2-3  作業の開始日、終了日、期間などを簡単にして図に表したもの。プロジェクト管理


2 2 1 1343845
プロジェクトという仕事の特徴作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • プロジェクトの特徴

    • 活動期限が限られている

    • システムはプロジェクトごとに異なる

    • 仕事の進め方が定型的でない


2 2 1 1343845
プロジェクト管理の体系作業の開始日、終了日、期間などを簡単にして図に表したもの。

「当たり前のことをキッチリやる」ことが最重要


2 2 1 1343845
プロジェクト計画作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • 目標の計画

    • 目標とは経営課題や企業の抱える問題点をシステム的な観点から解決すること

  • コストの計画

    • コストは人件費、ハード、パッケージソフトから構成される

  • 期限(スケジュール)の計画

    • クリティカルパスを明確にし、クリティカルな工程を重点的に管理することが重要


2 2 1 1343845
プロジェクト管理作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • 目標の管理

    • 作業の適当な時点での「ウォークスルー」が大切

  • 予算の管理

    • 作業実態はどうなっているのかを把握すること(進捗管理)が重要

  • 期限(スケジュール)の管理

    • 予算管理と同じく進捗管理が重要


2 2 1 1343845
プロジェクトチームの編成作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • メンバー編成のプロセス

    • プロジェクトを強力に推進するリーダーを選ぶ

    • 決定権限者を参画させる

    • 仕事のできる実務担当者を参画させる


2 2 1 1343845
理想とされるプロジェクトリーダー作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • 自社のあるべき姿を認識している

  • 課題や問題点を客観的に把握している

  • 妥協点を探る調整能力がある

  • 社内の各部門に対する説得能力がある

  • 使命感があり、経営陣の信頼が厚い

  • オープンな議論ができる


2 2 1 1343845
開発要員の変動作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • プロジェクトチームは開発プロセスに応じて変化する

  • 質的な仕事から、量的な仕事に移行していく

  • 無計画な要因の増加は失敗の元


2 2 1 1343845
プロジェクトチームの形態作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • 全社的か、部門的か

             これによりチームの形態やメン    

             バーが変わってくる。

  • プロジェクトチーム

                 ユーザ

                 開発


2 2 1 1343845

チームリーダー作業の開始日、終了日、期間などを簡単にして図に表したもの。

チームリーダー

メンバー

メンバー

メンバー

メンバー

一般的なプロジェクトチーム形態(1)

  • 図1 大規模システムのプロジェクトチームの形態

プロジェクトリーダー

事務局・スタッフ

Aサブシステム

Bサブシステム

・・・

・・・

・・・


2 2 1 1343845
一般的なプロジェクトチーム形態(2)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • プロジェクトリーダー

          ・・・顧客のシステムを利用する部門

            の実力管理者なることが大切。


2 2 1 1343845
プロジェクトチーム形態の別の見方作業の開始日、終了日、期間などを簡単にして図に表したもの。

    システム部門要員とソフトハウス要員が

    区別されてない。

  • 自社開発

  • 一括外注化

  • ユーザ部門による開発


2 2 1 1343845
プロジェクト管理の要点作業の開始日、終了日、期間などを簡単にして図に表したもの。            (リーダーの役割)

  プロジェクト管理

        ・・・ルーチンワークよりも一層高い

          管理スキルが求められる。

  管理者にはEQの高さが、IQや専門スキル

  よりも重要。


2 2 1 1343845
リーダーシップを発揮すること(1)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • リーダーシップ

         ・・・目標を達成するために、メンバーに

           その目的や方針を理解させ、自ら行

           動を起こす影響を与える力。


2 2 1 1343845
リーダーシップを発揮すること(2)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • リカートによると・・・ 

        リーダーは民主的であることを基本に、

        ときには専制的であることも必要。

  • リーダーたる者はプロジェクトに対する

     「情熱」を持たなければならない。


2 2 1 1343845
リーダーシップを発揮すること(3)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • 目的・構想、戦略・方針をメンバーに熱く伝えること

  • メンバーに対して意識付けをすること

  • メンバーのモチベーションを向上させること

  • コミュニケーションをうまく図ること


2 2 1 1343845
科学的にアプローチすること(1)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • ものごとを総合的に見ること

      「部分の総和は必ずしも一致しない」

              リーダーは全体を見渡して問題

              を解決することが必要。


2 2 1 1343845
科学的にアプローチすること(2)作業の開始日、終了日、期間などを簡単にして図に表したもの。

  • QCサイクルの実践

    P-D-C-Aサイクル・・・仕事を論理的に推進

                     していく。

       進行状況は目には見えないので、事実を正確に

       把握することは非常に難しい。


ad