第 1 章 SE の仕事とは 1-1 システム設計と SE

1. 第1章 SEの仕事とは1-1　システム設計とSE 株式会社ディー・アート 上野淳三・広田直俊・白井伸児[著] 「システム設計の考え方」 H102124　宮澤新一

2. システム開発におけるSEの役割 • システム設計。 • システム要件を定義し、それを実現するシステムの機能および構造を具体化する。 • システム設計者としてのSEの役割は、システム要求の把握からシステムの設計内容をプログラマへ伝達するまでである。

3. ユーザのシステム要求を把握する • システム要求を把握する作業を一般に「要求分析」、「要求定義」あるいは「要件定義」と呼ぶ。 • 要求分析の内容や進め方はユーザの開発システムに関する検討状況や、推進体制によって大きく変わる。

4. ユーザの検討状況との関係 図1-1　ソフトウェアのライフサイクル

5. ユーザの検討状況との関係 • ソフトウェアのライフサイクルは企画から始まるが、通常、SEは開発段階からプロジェクトに参画する。 • 開発段階の要求分析工程はライフサイクルの出発点でなく、さらに上流にある。

6. ユーザの検討状況との関係 • 要求分析は企画と開発の両方の段階で行われる。 • どの段階からSEがプロジェクトに参画するかにより要求分析の作業内容は異なる。

7. ユーザの検討状況との関係 • 社内SEの場合 • 企画段階から入るケースが多い。 • ユーザが白紙に近い状態からシステムの企画に着手することになる。 • システム開発の目的や対象業務を定めるところから要求分析が始まる。

8. ユーザの検討状況との関係 • ユーザがシステム仕様を固めている場合 • ユーザから要求仕様書の説明を受けるところからSEの作業が始まる。 • ソフトハウスなどの社外のSEはどちらかと言えば、このケースにあたる。

9. ユーザの推進体制との関係 • ユーザ側の推進体制が異なれば、要求分析の進め方も変わる。 図1-2 ユーザからシステム要求を聞きだす

10. ユーザの推進体制との関係 • 最も単純なケース 図1-2(1)ユーザの代表者からシステム要求を聞き出す

11. ユーザの推進体制との関係 • 最も単純なケース • 小規模な部門システムを開発するケース。 • ユーザがあらかじめ要求仕様を固めているケース。 • ユーザの代表者とSEが1対1で対話するため、システムイメージを頭合わせしやすい。 • 比較的外乱が少ないが、代表者の背後にいる本当のユーザの意識をつかめないこともある。

12. ユーザの推進体制との関係 • 一般的なケース 図1-2(2) 複数のユーザからシステム要求を聞き出す

13. ユーザの推進体制との関係 • 一般的なケース • 複数のユーザグループの代表者からシステム要求を聞き出す。 • 相反する要求や矛盾する要求もある。 • 相反・矛盾する要求を整理してグループ間の調整を行い、要求を集約する必要が出てくる。 • コントロールできない不確定要素が現れてくることもある。

14. ユーザの推進体制との関係 • 複数のSEが分担するケース 図1-2(3) 複数のSEがシステム要求を聞き出す

15. ユーザの推進体制との関係 • 複数のSEが分担するケース • システム規模が少し大きくなり、ユーザの代表者が多くなるため、複数のSEが分担して要求分析を行う。 • SE側で、それぞれが聞き出したシステム要求をSE同士で整理・調整・集約する必要が出てくる。 • コントロールできない不確定要素が一段と大きくなり、作業プロセスも複雑になる。 • 統制のとれた活動を展開する必要が出てくる。

16. ユーザの推進体制との関係 • 新しい情報システムに求める役割が次第に経営や事業活動に密着したものになるにつれて、ユーザ主導でシステムを企画する傾向が強くなっている。 • システム設計を担当するSEは、ユーザ主導の企画プロセスがどのように進められるかを理解しておく必要がある。

17. システムを設計する • SEがシステム設計で心得ておくべきことは、ユーザの要求をそのまま鵜呑みにしてシステム設計を行なってはいけないということ。 • 業務システムとしてやるべきこと、やってはいけないことをユーザに直言できないようでは、専門家の資格はない。

18. システムを設計する • ユーザもSEに対して専門家としての見識を期待しているため、その期待に応えて積極的に提案することが望まれる。 • ユーザの要求が、必ずしもユーザが求める真の要求でないことも知っておいた方がよい。

19. システムを設計する • ユーザは業務に慣れてしまっているため問題自体が見えなくなっていることがある。 • システム設計者において、ユーザの要求をしっかり見きわめ、取捨選択する必要がある。

20. システムを設計する • 必要と判断した要求を実現可能な形に構成し、システムを設計する。 • 設計した内容はユーザに説明して、ユーザの理解と承認を得る必要がある。

21. システムを設計する • 新しいシステムを構築するということは、ある意味で新しい業務モデルを設計する必要があるということである。 • 現在の業務モデルから直接新しい業務モデルを検討するのではなく、現行のモデルから物理的な要素を排除した論理モデルを作成して検討するようなことを行なう。

22. システムを設計する • 図1-3 論理モデルを使ったシステム設計プロセス

23. システムを設計する • 論理モデルを採用するのは、現実にある別の問題に気がとられて目的とする新しい業務モデルの検討が進まないといった理由があげられるためである。

24. システムを設計する • システム設計で用いる開発技法として、プロセス中心アプローチ(POA:Process Oriented Approach)やデータ中心アプローチ(DOA:Data Oriented Approach)などがある。 • POAが、処理手順やデータの流れに注目して現状を分析する手法であるのに対して、DOA では、データとその流れの分析に重点を置き、システム設計を進める。

25. プログラマへ設計内容を正確に伝達する • システム設計書は、プログラム開発を行なうための仕様書としての役割がある。 • システム開発プロジェクトの関係者がシステムの完成イメージや実現方法・製作プロセスなどの情報を共有する目的も合わせ持つ。

26. プログラマへ設計内容を正確に伝達する • システム設計書には、仕様書としての精緻な面と、関係者に対する新システムのガイドブックとしてのわかりやすさの両面が求められる。

27. 1-2　情報化の動向８～１７ページ H102002 安島澄人

28. 新情報革命 • 経営学者として著名なドラッカーは、現在の情報化、つまり、コンピュータの発明以来の情報化を「第４の情報革命」と称している。 • またドラッカーは、今後、情報技術（IT）の分野における重心は技術（T＝Technology)から情報（I＝Information)に移行していくと展望している。

29. 情報技術のパラダイムシフト • 思考の枠組みや考え方（旧体制）が壊れたり、根本的な変化が生じたりすることを「パラダイムシフト」と呼ぶ。 • 情報技術分野では、これまで、メインフレームを代表とするシステム中心のパラダイムから、80年代にPC中心のパラダイムへ、さらに90年代にはネットワーク中心のパラダイムへと2回のパラダイムシフトが起きている。

30. 1-3　情報システムとは • SEが取り組む情報システムはどういうものか。 • 情報システムの処理形態が発展してきた経緯 • 企業における業務面から見た情報システム • 企業における役割から見た情報システム 　　を紹介する。

31. 情報システムの処理形態 バッチ処理　（データの一括処理） 　　　　　　　　　　　↓ オンライン リアルタイム処理　（データの即時処理） 　　　　　　　　　　　↓ データベース処理　（データの共有化と一元管理）

32. バッチ処理 • コンピュータの処理方法 I：入力（Input) P：処理（Process) O：出力（Output)

33. コンピュータの利用形態の変化 • コンピュータ利用開始から 30年くらい前の利用形態 （１）技術計算などのコンピュータの計算能力 （２）給与計算などのデータ処理 （１）、（２）に重点を置いた使い方が中心だった。

34. コンピュータの利用形態の変化（２） 今日、技術計算は （１）CAD（Computer Aided Design: 　　　　　　　　コンピューター設計） （２）CAE（Computer Aided Engineering: 　　　　　　　モデルの特性解析シュミレーション） （１）、（２）やスーパーコンピュータを使った天気予報のシュミレーション計算などの分野に発展している。

35. バッチ処理方式 • 給与計算のデータ処理が今日のデータ処理に発展した。 • 給与計算のようなある期間に収集したデータをまとめて一括処理する方式を「バッチ処理方式」と呼ぶ。

36. オンラインリアルタイム処理 • その後、コンピュータの利用技術が進み、オンラインリアルタイム処理への移行が始まる。 • コンピュータに端末から直接データを入力し、処理結果が直ちに必要な場所に出力される処理方式である。 • コンピュータの対象領域の拡大。

37. システム設計の対象範囲 入出力設計や処理ロジックを中心としたバッチ処理システムの設計内容 　　　　　　　　　　　　　　↓ オンラインリアルタイムシステムのシステム設計では業務設計が主要なものとして加わる。 バッチ処理システムに比べて、SEが行うシステム設計の業務内容は質的に変わった。

38. データベース処理 • 業務システムで蓄積したデータや組織が保有する情報を有効利用するために、それらを整理してコンピュータ上に保存し、必要に応じて取り出す仕組みを「データベース」と呼ぶ。 • データベースを構築し、活用するソフトウェアを「データベース管理システム　DBMS（Data-Base Management System) • データベースを運用するシステムを「データベースシステム」と呼ぶ。

39. 企業における業務機能面から見た情報システム企業における業務機能面から見た情報システム • 基幹業務を対象とした基幹系システムに始まり、そのデータを活用する情報系システムへと発展してきた。 • 基幹系システム　販売管理、生産管理、在庫管理、財務会計、人事給与等 • 情報系システム　顧客情報管理、商品情報管理、業績情報管理 • OAシステム　ワープロ、表計算、プレゼンテーションソフトなど • グループウェア　電子メール、電子掲示板、文書共有など

40. 企業経営における役割から見た情報システム • 経営者が求めているのは、企業の将来にかかわる情報である。 • 企業の情報システムは、データを処理して業務を効率化することから始まり、経営に役立つ情報システムの構築を目指してきた。

41. EDPS (Electronic Data Processing System : データ処理システム） • コンピュータの初期に始まった情報ビジネスの概念。 • 経理計算、給与計算などの従来から手作業で行っていたデータ処理を機械化し、処理の効率性向上を狙いとしている。

42. MIS（Management Information System : 経営情報システム） • 1960年代後半に始まった概念。 • 経営に必要な情報をあらゆる階層で活用することを目指した。 • 業務の効率化だけでなく、経営面でコンピュータを活用する狙いがあったが、当時の技術レベルでは実現できなかった。

43. DSS(Decision Support System : 意思決定支援システム） • 80年代に始まった概念。 • MISが狙いとした、組織の目的に貢献する情報を作り出すという一面を焦点に絞ったシステムである。 • 経営レベルでの意思決定支援を目的としている。

44. SIS　（Strategic Information System : 戦略的情報システム） • 90年代にできた概念。 • 情報技術を活用して既存の企業活動を抜本的に再構築することを目指している。 • 業務の効率化よりも、売り上げ増や競争優位の確立を目的としている。

45. EC (Electronic Commerce :電子商取引） • 90年代にインターネットの普及とともに急速に広がったシステム • 情報技術を活用して、新しい市場機会を生み出すことを目指している。

46. 第1章 SEの仕事とは1-4　システム開発プロジェクトにおけるSEの役割 株式会社ディー・アート 上野淳三・広田直俊・白井伸児[著] 「システム設計の考え方」 H102124　宮澤新一

47. 情報サービス産業における職能別就業者数 • 情報サービス産業における職種別就業者数のうち、職種別で一番多いのは「システムエンジニア(SE)」である。 • 「プログラマ」、「管理・営業」と続き、この人員構成から、SEが情報サービス産業の中核であることがわかる。

48. 情報サービス産業における職能別就業者数 図1-8 情報サービス産業における職種別就業者数の 割合

49. SEの役割の拡大と専門分化 • 情報処理技術者の分類はソフトウェア開発における役割をもとに行なうのが一般的。 • ユーザの要求分析、システム設計などのシステム開発の上流工程を担当する技術者を「SE」と呼ぶ。

50. SEの役割の拡大と専門分化 • SEの事業範囲は、以下のものである。 • 利用者の要求分析 • システム設計 • プログラム開発の指導 • 総合テスト • 本番移行時のユーザ支援 • システム構築の保守 • ライフサイクル全体にSEが主導的な役割を担う。