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

1. 第2章 システム化の全体をつかむ2-1　システム化のプロセス全般 株式会社ディー・アート 上野淳三・広田直俊・白井伸児[著] 「システム設計の考え方」

2. 全社情報化中長期計画 • 会社の情報化計画は、経営計画とリンクされていなければならない。 • 事業部門の経営計画の中から情報化ニーズを吸い上げる必要がある。

3. 経営計画と情報化計画 • 規模の大小を問わず、いかなる企業も中長期経営計画を作成する。 • 計画には、人、物、金の他に情報も重要な経営資源であるという認識の下に、情報化計画が含まれるのが一般的である。

4. 経営計画と情報化計画2 • 情報は人、物、金と同列の概念ではなく、それらを効率的に活用するための手段である。 • 会社の情報化計画は、会社の事業計画をにらんで作成される。 • 情報化はそれ自体に意味があるわけでなく、あくまで経営を支援する手段ということである。

5. 全社情報化中長期計画 • 立案はシステム部門が担当する。 • 各事業部門からの事業計画の中にすでに含まれている。 システム部門から見て、情報化が必要と思われるにもかかわらず、計画されていない場合 システム化の働きかけを行い、各部門の情報化計画を全社的にとりまとめる。

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

7. 全社情報化中長期計画3 • 各事業部門で共通に利用できると思われるハードやソフトは、どのようなものであり、どれくらいの投資額になるかを大まかに見積もる。

8. 全社情報化中長期計画4 • 全社情報化中長期計画の要点 各事業部門のシステム化計画の適否や優先順位を決定 それらをまとめて全社共通インフラ(ハード、ソフト)計画を作成 全社的な投資計画や推進方針などを立案すること

9. 全社情報化中長期計画5

10. 全社情報化中長期計画6 • 情報化の案件は専門的な検討が必要になる。 　　例：案件はシステム開発の優先順位や全社共通のインフラや情報技術　　　　　　　　　　　　　　　　　 　　　　　事項など • ある程度以上の規模の企業では、経営会議の事前審議を行なう専門委員会を設置している場合が多い。

11. 全社情報化中長期計画7 • 経営会議での審議の二つの要点 • 提出された情報化計画が中長期的に経営にどう寄与するかということ。 • 投資額として会社の実情に見合っているかどうかということ。

12. 全社情報化中長期計画8 • 情報化投資は省力化の効果のあるものは、ほぼ実現している企業が多いこともあり、効果が定量的にわかりにくい。

13. 全社情報化中長期計画9

14. 費用の年度計画 • 一般に、各事業部門及びシステム部門は、年度計画(上期、下期)を立案する。 • 上期末には当初の下期計画を見直す。 各部門にとって活動計画の全般にわたる費用の予算・実績をトレースする作業である。

15. 費用の年度計画2 • 投資額は、ハード関係は固定資産として、またソフト外注費は無形固定資産として償却され、各期に費用として計上される。 • 償却期間は、ハードは取得金額や機器構成によって異なるが、ソフト外注費は5年間に固定されている。 • ハードはリースする企業も多く見られる。

16. 費用の年度計画3

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

18. 費用の年度計画5 • 今日、すべての企業が情報化の重要性を認識しているが、情報化の効果は短期的な利益の向上につながることは少ない。 • 長期的な企業の体質向上などが主目的になることが多いので、経費削減の対象になりがちである。

19. 費用の年度計画6 • 各事業部門に情報化のコスト意識を持ってもらうために、 システム部門の費用は、各事業部門に直接付け替えられる または予算立案時に費用配賦するという制度をとっている企業が多い。

20. システム開発計画 • システム開発計画の作成は、一般に次のような手順で進む。 1.システム開発の手順を明らかにした上で、現状の調査分析を行う。 2.業務設計、システム機能の検討へと進み、システム構想を作成する。 3.システム構想を実現させる手順を検討し、システム開発計画を立案する。

21. システム開発計画 投資案件として、その企業で想定された決済基準に従い、委員会、経営会議の承認を受ける。 承認が得られれば、次のステップであるシステム開発を進めることができる。

22. システム開発計画 経営会議の承認を得るためには？ 　・ユーザー部門、システム部門、事務者、SEと共に、システム構想やシステム化に伴う業務の見直し、ソフトハウス等の利用などについて検討する。

23. システム開発計画に盛り込むべき必要事項

24. システム開発計画に盛り込むべき必要事項 経営者の関心　 ・費用対効果がどうなるか つまり・・・ →経営者に該当条件の定性効果をわかりやすく説明し、了承してもらうことが大切。

25. システム開発計画に盛り込むべき必要事項 コツ →効果を体言止めで表現せずに、「動詞形」で表現する。 例） • 「在庫の縮小」→「3ヶ月分の在庫を1ヶ月分に減らす」 • 「納期の短縮」→「納期を1ヶ月から20日に短縮する」 • 「決算日程の短縮」→「財務諸表の出力を月初10日から月初3日に早める」

26. システム化に伴う業務の見直し • SLCP-JCF98委員会が作成した「共通フレーム98(SLCP-JCF98)」では、業務の視点から見たソフトウェアのライフサイクルを、 　企画プロセス→開発プロセス→運用プロセス→保守プロセス といった4つのプロセスでとらえている。

27. システム化に伴う業務の見直し • 企画プロセスと開発プロセスの関係を業務の視点から下の図のように概観している。

28. システム化に伴う業務の見直し • 企画プロセスを業務層・利用層に位置づけ、開発プロセスの開発層とは別の層に区分している。 • 業務層・利用層では、企画プロセスのみを行なうだけでなく、開発プロセスに入ってからも、開発層の開発業務と並行して、業務詳細設計を行なう。

29. システム化に伴う業務の見直し システム化で効果を上げるには？ →業務そのものを見直し、コンピュータ化するべき。 　しかし、業務ルートを変えることで効率化でることも多くあり、コンピュータ化するまでもないという結論に達することもある。

30. システム化に伴う業務の見直し ・人権上の問題や権限などの問題より、現状業務を変えることは難しい。 →どうすればよいか？ ・ユーザ部門をコンピュータ化以前の問題と批判するだけなく、システム部門から業務自体を改善するように助言すべき。

31. システム化に伴う業務の見直し • ユーザを無視して突っ走っても、本当にユーザに役立つものにはならないので、あくまでもユーザが真剣に考えるように、うまく関わってゆくことが大切である。 • 「やりすぎてもいけないが、無関心もいけない」というさじ加減がユーザ部門との係わりの難しさであり、工夫が必要な点である。

32. 外部SEなどのシステム開発計画への参画 • 企画プロセスは顧客の中でもユーザ部門の仕事だが、これをコンサルティング会社やベンダーやソフトハウスが中心的役割を担う場合がある。 　これをソリューションと呼ぶ。

33. 外部SEなどのシステム開発計画への参画

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

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

36. 外部SEなどのシステム開発計画への参画 つまり・・・ 　開発者が行う開発作業は、ユーザ側から提示された要求仕様書を確認する要件定義からスタートし、開発プロセスは、以下のようになる。 要求定義→システム設計→プログラム開発

37. システムの開発過程 　　　・必要に応じて進めていると、システムが 　　　完成している 　　　・人間的な要素が大きく、常に意味を考慮に入れ 　　　て作業を行う 　開発効率の上昇および品質改良のために、様々な開発プロセスモデルが誕生 システム開発プロセス（１）

38. システム開発プロセス（２） 具体的にはどのようなモデルが開発されたの か？？ 大きく大別すると ・ウォーターフォールモデル 　　　・ノンウォーターフォールモデル

39. システム開発プロセス（３） システム開発プロセスの大まかな流れ 要件定義 システム設計 プログラム開発

40. システム開発プロセス（３）

41. ウォーターフォールモデル（１） • ウォーターフォールモデルとは 　　・開発プロセスをウォーターフォール（滝）の 　　　ように、順次実行していくやり方。 　　・大規模システムに有効であるが、バリエー 　　　ションが豊富なことから、原則的にどんな 　　　システムにも対応可能。

42. ウォーターフォールモデル（２）

43. ウォーターフォールモデル（３） 同じウォーターフォールモデルでも、図２-８ のようなV字型モデルと呼ばれるものも存在

44. ウォーターフォールモデル（４） • V字型モデル 　　・要件定義を起点に下り、プログラミングを 　　　境に上っていく 　　・前半部は開発そのもので、品質の作成 　　・後半部は完成して品質のテストの実行

45. ウォーターフォールモデル（５） • ウォーターフォールモデルの問題点 　　・開発期間が長い場合に、要件定義に存在 　　　する欠陥の発見が遅れる（特にV字型モデル） この欠点を改善したのが、「ノンウォーターフォールモデル」

46. ノンウォーターフォールモデル • 基となっている開発手法：プロトタイピング法 • 初期段階でシステムのプロトタイプをユーザー 　部門がチェック • 現実的には、サブシステム単位で作成し、部 　分的に更新してユーザー部門がチェックし、 　プログラムの改善を行う。

47. スパイラルモデル ユーザーの反応を見ながら、スパイラル的に 行うことから、スパイラルモデルとも呼ばれる。

48. システム保守の重要性 • システムライフサイクルは、開発、運用(保守)、再開発 • 現実にはシステム保守が重要な意味を持ち、長期的にみるとコストもかかってくる。 • 開発期間は平均2～3年程度に対し、保守期間は一般的に10年間程度。

49. システム保守の重要性 • システム保守は大きく分類すると、「修正のための保守」と「改訂のための保守」の2種類 • システム開発後、地道なシステム保守こそがシステムを使いやすくし、業務の効率アップにつながるといっても過言ではない。

50. システム保守の重要性