slide1
Download
Skip this Video
Download Presentation
第 2 章まとめ

Loading in 2 Seconds...

play fullscreen
1 / 71

第 2 章まとめ - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

第 2 章まとめ. 山本恭平. 目次. 2-1 システム化のプロセス全般 2-2 システム化における各種法 2-3 プロジェクト管理. 2 - 1 システム化のプロセス全般. 山本恭平. 全社情報化中長期計画. 会社の情報化計画は、経営計画とリンクされていなければならない 事業部門の経営計画の中から情報化ニーズを吸い上げる必要がある. 経営計画と情報化計画. いかなる企業も中長期経営計画を作成する 計画には、人、物、金の他に情報も重要な経営資源であるという認識の下に、情報化計画が含まれるのが一般的

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 章まとめ' - fia


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
slide1

第2章まとめ

山本恭平

slide2
目次
  • 2-1 システム化のプロセス全般
  • 2-2 システム化における各種法
  • 2-3 プロジェクト管理
slide4
全社情報化中長期計画
  • 会社の情報化計画は、経営計画とリンクされていなければならない
  • 事業部門の経営計画の中から情報化ニーズを吸い上げる必要がある
slide5
経営計画と情報化計画
  • いかなる企業も中長期経営計画を作成する
  • 計画には、人、物、金の他に情報も重要な経営資源であるという認識の下に、情報化計画が含まれるのが一般的
  • 情報化はそれ自体に意味があるわけでなく、あくまで経営を支援する手段
slide6
全社情報化中長期計画(1)
  • 立案はシステム部門が担当
  • 各事業部門からの事業計画の中にすでに含まれている
slide7
全社情報化中長期計画(2)
  • 各事業部門で共通に利用できると思われるハードやソフトは、どのようなものであり、どれくらいの投資額になるかを大まかに見積もる
  • 全社情報化中長期計画の要点
  • 各事業部門のシステム化計画の適否や優先順位を決定
  • 全社共通インフラ(ハード、ソフト)計画を作成
  • 全社的な投資計画や推進方針などを立案
slide9
全社情報化中長期計画(4)
  • 情報化の案件は専門的な検討が必要なため経営会議の事前審議を行なう専門委員会を設置している場合が多い
  • 審議の要点
  • 提出された情報化計画が中長期的に経営にどう寄与するか
  • 投資額として会社の実情に見合っているか
slide10
全社情報化中長期計画(5)
  • 承認された計画
  • 個別案件を推進していくが、多額の投資を伴う場合は実行段階で、委員会、経営会議の審議が必要
slide11
費用の年度計画(1)
  • 各事業部門及びシステム部門は、年度計画(上期、下期)を立案
  • 上期末には当初の下期計画を見直す
  • 各部門にとって活動計画の全般にわたる費用の予算・実績をトレースする作業
slide12
費用の年度計画(2)
  • 投資額は、ハード関係は固定資産として、ソフト外注費は無形固定資産として償却され、各期に費用として計上
  • ソフト外注費は5年間に固定されている
  • ハードはリースする企業も多く見られる
slide13
費用の年度計画(3)
  • 費用の年度計画の数値が今後の投資計画すなわちシステム計画に影響を及ぼすことがあるということを知っておかなければならない
slide14
費用の年度計画(4)
  • 情報化の効果は長期的な企業の体質向上などが主目的になることが多い
  • 各事業部門に情報化のコスト意識を持ってもらうために、システム部門の費用は、各事業部門に直接付け替えられるか、予算立案時に費用配賦するという制度をとっている企業が多い
slide15
システム開発計画
  • ユーザ部門中心で検討
  • システム開発計画の作成の順序

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

          業務設計、システム機能の検討

              システム構想を作成

             実現させる手順を検討

            システム開発計画を立案

slide16
システム開発計画
  • 次のステップ

 企業の決済基準に従い、委員会、経営会議の承認を受ける

         システム開発を進める

  • 承認を得るためには?
slide18
システム開発計画に盛り込むべき必要事項(2)

経営者の関心 

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

つまり・・・

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

例)

  • 「在庫の縮小」→「3ヶ月分の在庫を1ヶ月分に減らす」
  • 「納期の短縮」→「納期を1ヶ月から20日に短縮する」
  • 「決算日程の短縮」→「財務諸表の出力を月初10日から月初3日に早める」
slide19
システム開発計画に盛り込むべき必要事項(3)
  • 期待効果の確認は実施例の調査が良い
  • ユーザ部門が前面に出るように仕組む事が必要
slide20
システム化に伴う業務の見直し(1)
  • 共通フレーム98(SLCP-JCF98)の業務の視点から見たソフトウェアのライフサイクル

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

slide21
システム化に伴う業務の見直し(2)
  • 現実には「コンピュータ化以前の問題」という状況
  • システム部門もシステム化の早期検討段階から入っていくことが必要
  • ユーザが真剣に考えるように、うまく関わってゆくことが大切
slide22
外部SEなどのシステム開発計画への参画
  • 企画プロセスは顧客の中でもユーザ部門の仕事だが、これをコンサルティング会社やベンダーやソフトハウスが中心的役割を担う場合がある。

     ソリューション

slide24
外部SEなどのシステム開発計画への参画(2)
  • 顧客(ユーザ部門・システム部門)とコンサルティング会社やソフトハウスのSEとでプロジェクトチームを編成して、調査分析やシステムの仕様検討といった作業を進める
slide25
外部SEなどのシステム開発計画への参画(3)
  • 開発者が行う開発作業は、ユーザ側から提示された要求仕様書を確認する要件定義からスタートし、開発プロセスは 

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

slide27
システム開発プロセス
  • 開発効率やソフトウェアの品質がよくわからないといった問題
  • 色々な開発モデルが提唱

大きく分けて

  • ウォーターフォールモデル
  • ノンウォーターフォールモデル
slide29
ウォータフォールモデル(2)
  • 開発プロセスをウォーターフォール(滝)のように順次実行していくやり方
slide30
ウォータフォールモデル(3)
  • メリット
  • 大規模システムに有効
  • バリエーションが豊富
  • どんなシステムでも原則的に通用
  • デメリット
  • 開発期間が長い場合に、要件定義に存在する欠陥の発見が遅れる(特にV字型モデル)

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

slide31
ノンウォータフォールモデル(1)
  • 基となっている開発手法:プロトタイピング法
  • 初期段階でシステムのプロトタイプを作成しユーザー部門がチェック
  • 現実的には、サブシステム単位で作成し、部

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

 プログラムの改善を行う

slide32
ノンウォータフォールモデル(2)
  • ユーザーの反応を見ながら、スパイラル的に行うことから、スパイラルモデルとも呼ばれる
slide33
システム保守の重要性(1)
  • システムライフサイクルは、開発、運用(保守)、再開発
  • 現実にはシステム保守が重要な意味を持ち、長期的にみるとコストもかかる
  • 開発期間は平均2~3年程度に対し、保守期間は一般的に10年間程度
slide34
システム保守の重要性(2)
  • システム保守の種類
  • 修正のための保守
  • 改訂のための保守
  • システム開発後、地道なシステム保守こそ重要
slide35
システム保守から学ぶこと
  • システム効果の確認

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

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

 次の開発への準備

slide36

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

4405087 宮崎雄吾

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

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

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

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

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

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

・文書化の留意事項 

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

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

3. 文章を構造化する。

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

slide41
システム化における各種方法(5)
  • 見積手法
  • ソフトウェア の見積もりは非常に難しい。
  • 上流工程ほど見積と実績の差が大きくなる。
slide42
システム化における各種方法(6)

・2・4・2・3の法則

slide43
システム化における各種方法(7)
  • 概算・積算見積法

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

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

slide44
システム化における各種方法(8)
  • 見積モデル

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

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

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

slide45
システム化における各種方法(9)
  • ファンクションポイント法(FP法)

・見積方法のひとつ。

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

slide46
システム化における各種手法・スケジューリング手法
  • 第1次作業計画

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

  • 第2次作業計画

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

slide48
WBS
  • WBSとは…

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

slide50
ネットワークダイアグラム

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

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

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

 の2種類がある。

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

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

slide55

2-3プロジェクト管理

4405019 小尾雅人

slide56
プロジェクトという仕事の特徴
  • プロジェクトの特徴
    • 活動期限が限られている
    • システムはプロジェクトごとに異なる
    • 仕事の進め方が定型的でない
slide57
プロジェクト管理の体系

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

slide58
プロジェクト計画
  • 目標の計画
    • 目標とは経営課題や企業の抱える問題点をシステム的な観点から解決すること
  • コストの計画
    • コストは人件費、ハード、パッケージソフトから構成される
  • 期限(スケジュール)の計画
    • クリティカルパスを明確にし、クリティカルな工程を重点的に管理することが重要
slide59
プロジェクト管理
  • 目標の管理
    • 作業の適当な時点での「ウォークスルー」(関係者のレビュー)が大切
  • 予算の管理
    • 作業実態はどうなっているのかを把握すること(進捗管理)が重要
  • 期限(スケジュール)の管理
    • 予算管理と同じく進捗管理が重要
slide60
プロジェクトチームの編成
  • メンバー編成のプロセス
    • プロジェクトを強力に推進するリーダーを選ぶ
    • 決定権限者を参画させる
    • 仕事のできる実務担当者を参画させる
slide61
理想とされるプロジェクトリーダー
  • 自社のあるべき姿を認識している
  • 課題や問題点を客観的に把握している
  • 妥協点を探る調整能力がある
  • 社内の各部門に対する説得能力がある
  • 使命感があり、経営陣の信頼が厚い
  • オープンな議論ができる
slide62
開発要員の変動
  • プロジェクトチームは開発プロセスに応じて変化する
  • 質的な仕事から、量的な仕事に移行していく
  • 無計画な要因の増加は失敗の元
slide63
プロジェクトチームの形態
  • 全社的か、部門的か

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

         バーが変わってくる。

  • プロジェクトチーム

             ユーザ

             開発

slide64
チームリーダー

チームリーダー

メンバー

メンバー

メンバー

メンバー

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

プロジェクトリーダー

事務局・スタッフ

Aサブシステム

Bサブシステム

・・・

・・・

・・・

  • プロジェクトリーダー

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

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

slide65
プロジェクトチーム形態の別の見方

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

    区別されてない。

  • 自社開発
  • 一括外注化
  • ユーザ部門による開発
slide66
プロジェクト管理の要点 (リーダーの役割)

  プロジェクト管理

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

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

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

  よりも重要。

slide67
リーダーシップを発揮すること(1)
  • リーダーシップ

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

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

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

slide68
リーダーシップを発揮すること(2)
  • リカートによると・・・ 

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

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

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

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

slide69
リーダーシップを発揮すること(3)
  • 目的・構想、戦略・方針をメンバーに熱く伝えること
  • メンバーに対して意識付けをすること
  • メンバーのモチベーションを向上させること
  • コミュニケーションをうまく図ること
slide70
科学的にアプローチすること(1)
  • ものごとを総合的に見ること

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

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

          を解決することが必要。

slide71
科学的にアプローチすること(2)
  • QCサイクルの実践

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

                 していく。

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

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

ad