第2章 システム化の全体をつかむ 2-1 システム化のプロセス全般 株式会社ディー・アート 上野淳三・広田直俊・白井伸児[著] 「システム設計の考え方」 H102124 宮澤新一 1 全社情報化中長期計画 • 会社の情報化計画は、経営計画とリンクされ ていなければならない。 • 事業部門の経営計画の中から情報化ニーズ を吸い上げる必要がある。 2 経営計画と情報化計画 • 規模の大小を問わず、いかなる企業も中長 期経営計画を作成する。 • 計画には、人、物、金の他に情報も重要な経 営資源であるという認識の下に、情報化計画 が含まれるのが一般的である。 3 経営計画と情報化計画 • 情報は人、物、金と同列の概念ではなく、そ れらを効率的に活用するための手段である。 • 会社の情報化計画は、会社の事業計画をに らんで作成される。 4 経営計画と情報化計画 • 情報化はそれ自体に意味があるわけでなく、 あくまで経営を支援する手段ということである。 5 全社情報化中長期計画 • システム部門から見て、情報化が必要と思わ れるにもかかわらず、計画されていない場合 には、システム化の働きかけを行い、各部門 の情報化計画を全社的にとりまとめる。 6 全社情報化中長期計画 7 全社情報化中長期計画 • 各事業部門で共通に利用できると思われる ハードやソフトは、どのようなものであり、どれ くらいの投資額になるかを大まかに見積もる。 8 全社情報化中長期計画 • 全社情報化中長期計画の要点は、各事業部 門のシステム化計画の適否や優先順位を決 定し、それらをまとめて全社共通インフラ (ハード、ソフト)計画を作成し、全社的な投資 計画や推進方針などを立案することである。 9 全社情報化中長期計画 10 全社情報化中長期計画 • 情報化の案件はシステム開発の優先順位や 全社共通のインフラや情報技術事項など専 門的な検討が必要になる。 • ある程度以上の規模の企業では、経営会議 の事前審議を行なう専門委員会を設置してい る場合が多い。 11 全社情報化中長期計画 • 経営会議での審議の要点は、次の二つにな る。 – 提出された情報化計画が中長期的に経営にどう 寄与するかということ。 – 投資額として会社の実情に見合っているかどうか ということ。 12 全社情報化中長期計画 • 情報化投資は省力化の効果のあるものは、 ほぼ実現している企業が多いこともあり、効 果が定量的にわかりにくい。 13 全社情報化中長期計画 14 費用の年度計画 • 一般に、各事業部門及びシステム部門は、年 度計画(上期、下期)を立案する。 • 上期末には当初の下期計画を見直す。これ は、各部門にとって活動計画の全般にわたる 費用の予算・実績をトレースする作業である。 15 費用の年度計画 • 投資額は、ハード関係は固定資産として、ま たソフト外注費は無形固定資産として償却さ れ、各期に費用として計上される。 • 償却期間は、ハードは取得金額や機器構成 によって異なるが、ソフト外注費は5年間に固 定されている。 • ハードはリースする企業も多く見られる。 16 費用の年度計画 17 費用の年度計画 • 費用というものは投資した以上どうしようもな いのだが、企業決算に影響を与えるものだけ にこの数値が今後の投資計画すなわちシス テム計画に影響を及ぼすことがあるというこ とを知っておかなければならない。 18 費用の年度計画 • 今日、すべての企業が情報化の重要性を認 識しているが、情報化の効果は短期的な利 益の向上につながることは少ない。 • 長期的な企業の体質向上などが主目的にな ることが多いので、経費削減の対象になりが ちである。 19 費用の年度計画 • 各事業部門に情報化のコスト意識を持っても らうために、システム部門の費用は、各事業 部門に直接付け替えられるか、または予算立 案時に費用配賦するという制度をとっている 企業が多い。 20 システム開発計画 • システム開発計画の作成は、一般に次のよう な手順で進む。 1.システム開発の手順を明らかにした上で、現状 の調査分析を行う。 2.業務設計、システム機能の検討へと進み、システ ム構想を作成する。 3.システム構想を実現させる手順を検討し、システ ム開発計画を立案する。 21 システム開発計画 • システム開発計画は、投資案件として、その 企業で想定された決済基準に従い、委員会、 経営会議の承認を受ける。 • 承認が得られれば、次のステップであるシス テム開発を進めることができる。 22 システム開発計画に盛り込むべき必要事項 23 システム開発計画に盛り込むべき必要事項 • 給与計算や経理処理などの歴然とした定量 効果が大きい業務は、既にコンピュータ化さ れており、それ以外のコンピュータ化で得られ る効果のほとんどは数値化できない「定性効 果」と言われるものである。 24 システム開発計画に盛り込むべき必要事項 • 経営者に当該案件の定性効果をわかりやす く説明し、了承してもらうことが大切である。 • 定性効果を定量効果に変換せず、定性効果 を定量的に表現することがひとつの方法であ る。 • コツは、効果を体言止めで表現せずに、「動 詞形」で表現するように心掛ける。 25 システム開発計画に盛り込むべき必要事項 • 効果を体言止めで表現せずに、「動詞形」で 表現する例。 – 「在庫の縮小」→「3ヶ月分の在庫を1ヶ月分に減 らす」 – 「納期の短縮」→「納期を1ヶ月から20日に短縮す る」 – 「決算日程の短縮」→「財務諸表の出力を月初10 日から月初3日に早める」 26 システム化に伴う業務の見直し • SLCP-JCF98委員会が作成した「共通フレー ム98(SLCP-JCF98)」では、業務の視点から 見たソフトウェアのライフサイクルを、「企画プ ロセス→開発プロセス→運用プロセス→保守 プロセス」といった4つのプロセスでとらえてい る。 27 システム化に伴う業務の見直し • 共通フレームでは、企画プロセスがソフトウェ アのライフサイクルの先頭にあり、システム化 の起点になる。 28 システム化に伴う業務の見直し • 企画プロセスと開発プロセスの関係を業務の視点から下の 図のように概観している。 29 システム化に伴う業務の見直し • 企画プロセスを業務層・利用層に位置づけ、 開発プロセスの開発層とは別の層に区分して いる。 • 業務層・利用層では、企画プロセスのみを行 なうだけでなく、開発プロセスに入ってからも、 開発層の開発業務と並行して、業務詳細設 計を行なう。 30 システム化に伴う業務の見直し • 業務層・利用層はユーザ部門が主体になる 領域である。 • 「システム開発計画」は、企画プロセスの中の 「システム構想・計画」を指している。 31 システム化に伴う業務の見直し • システム部門もソフトウェア開発そのものは 外注化し、システム企画・業務改革・改善と いった機能への指向を必要とされてきている。 • システム部門は、システム化の早期検討段 階から入ってゆく必要がある。 32 システム化に伴う業務の見直し • ユーザを無視して突っ走っても、本当にユー ザに役立つものにはならないので、あくまでも ユーザが真剣に考えるように、うまく関わって ゆくことが大切である。 • 「やりすぎてもいけないが、無関心もいけな い」というさじ加減がユーザ部門との係わりの 難しさであり、工夫が必要な点である。 33 外部SEなどのシステム開発計画への参画 • 企画プロセスは顧客の中でもユーザ部門の 仕事だが、これをコンサルティング会社やベ ンダーやソフトハウスが中心的役割を担う場 合がある。 • 単にシステム化とかシステム構築などと言わ ずに、顧客の問題を解決するという意味で「ソ リューション」などと呼ぶ。 34 外部SEなどのシステム開発計画への参画 35 外部SEなどのシステム開発計画への参画 • 図2-5のようなケースでは、顧客(ユーザ部 門・システム部門)とコンサルティング会社や ソフトハウスのSEとでプロジェクトチームを編 成して、調査分析やシステムの仕様検討と いった作業を進める。 36 外部SEなどのシステム開発計画への参画 • システム開発計画が完了し、開発を外部委託 するとなれば、プロジェクトチームが検討した システムの要求仕様書が開発者に対する指 示になる。 37 外部SEなどのシステム開発計画への参画 • 開発者が行う開発作業は、ユーザ側から提 示された要求仕様書を確認する要件定義か らスタートし、開発プロセスは、以下のように なる。 要求定義→システム設計→プログラム開発 38 外部SEなどのシステム開発計画への参画 39 外部SEなどのシステム開発計画への参画 • 図2-6のように、業者への発注は、システム開 発計画の段階から行なわれる場合と、システ ム開発の段階から行なわれる場合のふたつ に大きく分けられる。 • 発注形態としては、請負か応役かのふたつ のケースになる。 40 システム開発プロセス • システム開発は、人間的な要素が大きく、し かも単なる作業ではなく、常に意味を考えて 作業することが求められる。 • 色々な開発モデルが提唱されているが大きく は「ウォーターフォールモデル」と「ノンウォー ターフォールモデル」に分かれる。 41 システム開発プロセス • システム開発のプロセスは、大まかには「要 件定義→システム設計→プログラム開発」と なるが、もっと詳細に見れば、次の表2-2にあ るような項目から成り立つ。 42 システム開発プロセス 43 ウォーターフォールモデル • ウォーターフォールモデルとは、システム開 発のプロセスについて、水がウォーター フォール(滝)を流れるように開発プロセスを順 次、実行してゆくやり方。 44 ウォーターフォールモデル 45 ウォーターフォールモデル • ウォーターフォールモデルは大規模システム に有効なモデルだが、色々なバリエーション もあり、どんなシステムでも原則的に通用す るものである。 • テストとの関係でウォーターフォールモデルを 「V字モデル」とも呼ぶ。 46 ウォーターフォールモデル • 前半部が開発そのものであり、品質を作りこむ過程。 • 後半部は品質をテストする過程。 47 ウォーターフォールモデル • ウォーターフォールモデルの問題点として、 開発期間が長い場合、すなわち要件定義と 運用テストとの間が開きすぎて要件定義で欠 陥があった場合に、その発見が遅くなる。 • ウォーターフォールモデルの欠点を改善した 手法が、「ノンウォーターフォールモデル」であ る。 48 ノンウォーターフォールモデル • 「ノンウォーターフォールモデル」の基盤となっ ている開発手法にプロトタイピング法がある。 • プロトタイピング法は、要件定義や外部設計 のような開発の初期段階で、システムの一部 のプロトタイプ(試作品)を作成し、ユーザ部門 にチェックしてもらうというものである。 49 ノンウォーターフォールモデル • プロトタイピング法は、ユーザの反応を見な がら、スパイラル的に開発作業を進めるので、 スパイラルモデルとも呼ばれる。 50 ノンウォーターフォールモデル 51 システム保守の重要性 • システムは、開発、運用(保守)、再開発という ようなライフサイクルを持つ。 • 現実にはシステム保守が重要な意味を持ち、 長期的にみるとコストもかかってくる。 • 開発期間は平均2～3年ぐらいに対し、保守 期間は一般的に10年間ぐらいは続く。 52 システム保守の重要性 • システム保守は「修正のための保守」と「改訂 のための保守」の2種類に大きく分類できる。 • システム開発後、地道なシステム保守こそが システムを使いやすくし、業務の効率アップに つながるといっても過言ではない。 53 システム保守の重要性 54 システム保守から学ぶこと • システム保守から学ぶことは少なくない。そ の理由としては以下の2つがある。 1.システム効果の確認 • 次の開発へのフィードバック 2.優れたシステムの学習及び業務知識の吸収 • 次の開発への準備 55 2-2 Uploadなし 56 ２‐３ プロジェクト管理 Ｈ１０２０４２ 小林弘晃 57 プロジェクトという仕事の特徴 • プロジェクトの特徴 – 活動期限が限られている – システムはプロジェクトごとに異なる – 仕事の進め方が定型的でない 58 プロジェクト計画 • 目標の計画 – 目標とは経営課題や企業の抱える問題点をシス テム的な観点から解決すること • コストの計画 – コストは人件費、ハード、パッケージソフトから構 成される • 期限（スケジュール）の計画 – クリティカルパスを明確にし、クリティカルな工程 を重点的に管理することが重要 59 プロジェクト管理 • 目標の管理 – 作業の適当な時点での「ウォークスルー」が大切 • 予算の管理 – 作業実態はどうなっているのかを把握すること （進捗管理）が重要 • 期限（スケジュール）の管理 – 予算管理と同じく進捗管理が重要 60 プロジェクトチームの編成 • メンバー編成のプロセス – プロジェクトを強力に推進するリーダーを選ぶ – 決定権限者を参画させる – 仕事のできる実務担当者を参画させる 61 開発要員の変動 • プロジェクトチームは開発プロセスに応じて変 化する • 質的な仕事から、量的な仕事に移行していく • 無計画な要因の増加は失敗の元 62 プロジェクトチームの形態 • 開発システムが、全社的か専門的かによって プロジェクト編成や形態、メンバーが異なる • プロジェクトチームはユーザ側と開発側から 構成される 63 一般的なプロジェクトチーム形態 • 図 大規模システムのプロジェクトチームの形態 プロジェクトリーダー 事務局・スタッフ Ａサブシステム Ｂサブシステム チームリーダー チームリーダー ・・・ メ ン バ ー ・・・ メ ン バ ー メ ン バ ー ・・・ メ ン バ ー 64 プロジェクトチーム形態の別の見方 • 自社開発 – 部分的な外注化が避けられないケースが多い • 一括外注化 – システム部門は、ソフトハウスへの指示など窓口 的な機能を果たす • ユーザ部門による開発 – ＥＵＤ（End User Development）が進展 65 リーダーの役割 • プロジェクトに一定のルールは無い – ルーティンワークよりも高いスキルが求められる • ＥＱ（Emotional Quality）の高さが重要 – 単に論理的能力や分析力が優れて、専門的知識 があるだけでは、他人を動かすことは出来ない 66 リーダーシップを発揮すること • プロジェクトの目的・戦略・方針を熱く伝える • メンバーに対して意識付けをする • メンバーのモチベーションを向上させる • コミュニケーションをうまく図る 67 科学的にアプローチすること • ものごとを総合的に見る – 部分の総和は必ずしも全体とは一致しない – 部分にとらわれず、全体を見渡して問題を解決す ることが大切 • ＰＤＣＡサイクルの実践 – 仕事を論理的に推進してゆくことが大切 68 キーマンを発掘する • プロジェクトの成功は、ユーザ側とＳＥ側の キーマンにかかっている • リーダーは、キーマンを発掘するチャンスを 意識的に作ることが必要 • リーダーは、メンバーへの配慮をしつつ、キー マンを片腕として使ってゆくことが必要 69
© Copyright 2025 ExpyDoc
