システムのこといろいろ調べてみました

「Double-Entry Bookkeeping System」とは?

複式簿記(ふくしきぼき、英: Double-entry bookkeeping system)とは、簿記において、全ての簿記的取引を、その二面性に着眼して記録していき、貸借平均の原理に基づいて組織的に記録・計算・整理する記帳法のことをいう。

ビジネスパーソンなら世界中の誰もが知っている有名なシステムらしいです。

複式簿記(「Double-Entry Bookkeeping System」) - Wikipedia

システムとは?

「システム=業務の仕組み」なので、「システム開発」とは「業務の仕組みを創る」ことになるらしいです。

ハードウェア基盤の上にソフトウェアやプログラムを実装したコンピュータシステムは、「業務の仕組み」全体のうちの一部。

「業務の仕組みを創る」以上、全体最適を目指すことが重要。

 

 

「情報システム」の情報とは?

「受け手に意思決定、またはアクションを起こさせるもの」

「情報システム」とは、「ユーザーに意思決定やアクションを起こさせるような仕組みを提供するもの」

 

 

システム開発」とは?

  • 新しい業務の仕組みを考えること
  • 業務に合わせてコンピュータシステムを作ること
  • 業務を刷新し、その効果・効率を上げること

 

システム開発の流れ

要求分析

 ⇩ クライアントにどんなシステムが必要なのかヒアリング。

要件定義

 ⇩ 要求分析の内容をまとめる。

基本設計

 ⇩ システムを何で構成するのか決める。

詳細設計

 ⇩ プログラミングをするための細かな設計を行う。

プログラミング

 ⇩ プログラムを作成する。

テスト

 ⇩ 正常に動作するかのテスト。

稼働

  システムが実際に動き出す。

 

システム開発」の進め方

システム開発を成功させるためには、まず関係者の役割分担をはっきりさせておくことが大切。

例:建築に例えると以下のようになります

 
システム開発の関係者が担う役割
ユーザー(建て主) 新しい業務のイメージを発案、要望しコンピュータに期待することを示す
SE(建築士 業務の仕組み全体を設計し、業務・組織とコンピュータの連携方法を整理する
プログラマ(施工技術者) コンピュータへの期待を実現する
プロジェクトマネージャ(現場監督) システム開発の計画を立てて、業務刷新の進捗をコントロールする
 

開発手順は大きく分けて3段階

序盤──新しい業務の仕組みを考える

 序盤におけるシステムの検討段階ではユーザーが主体です。企業戦略に基づいて新しい業務をイメージし、コンピュータに期待することを明らかにします。その際、SEは“プロセスモデル”や“データモデル”と呼ばれるモデルを、専用の書式を使って表現し、コンピュータに対する要求を設計図にもれなくまとめていきます。特にSEが行う設計に先立って行われる検討作業は、上流工程のさらに上流という意味で「超上流」工程とも呼ばれ、システム開発における最も重要な工程として位置付けられています。

中盤──業務に合わせてコンピュータシステムを作る

中盤はモノ作りが主になります。序盤で作った設計図を基にシステム(ソフトウェアなど)を構築するのです。仕上がりに期待するなら、社屋の建築と同様、信頼できるプロの“施工技術者”に任せましょう。

 ソフトウェアが思いのほか融通の利かないものであることは、ご存じでしょうか? 現在の情報システムの機能や構造は、小屋ではなくビル並の複雑度を備えています。「ちょっとした変更」があちこちに影響するため、手直しには意外に大きなコストと手間が掛かります。「作りながら考える」ようなアプローチでは、とても満足できる完成品を手にすることはできません。

 確かに要求は日々変化しますから、「作りながら考えたい」気持ちは分かります。しかし、でき上がったシステムは結局何年も使うのです。思い切って、序盤で本当に必要な機能だけに絞り込んでしまいましょう。例外処理にとらわれず、本当に必要機能をしっかりと押さえたシステムを作ることが費用対効果を高めるコツです。

終盤──システムを導入して、業務の効果・効率を上げる

終盤では、出来上がったシステムがきちんと機能するかどうかテストし、さらにユーザー側で設計仕様書どおりに作られているか、検品・検収をしたうえで、いよいよ本番の業務環境に移行することになります。さらに、運用開始後は、投資に見合った効果が得られたか、運用に掛かる費用は最少化されているか──といったことをポイントに導入効果を測ります。

 その際、重要なことが2つあります。1つは、システムで得られる効果は序盤で検討した内容以上にはならないこと、もう1つは「情報化投資の7割以上に達する」といわれているシステムの維持・運用費も、やはり序盤で設計したアーキテクチャに依存してしまう、ということです。序盤での検討結果が、すべてを決めてしまうのです。

システム開発は“最初”が肝心

新しいシステム(=新しい業務の仕組み全体)が果たす機能や効果を得るための 目的と原理を明らかに

例:「在庫を減らすために、少量多頻度発注方式に移行する」「新たな顧客を獲得するために、無人端末の機能を拡張する」など。

業務の仕組み全体の見直しが必須。

 

要件定義と基本設計

「要求仕様に基づいて“開発するシステムの機能”を決定する工程」

(※基本設計は、「開発しようとするシステムが、コンピュータの外部(ユーザーや外部システム)に対してどのような機能、インターフェイスを提供するかを設計する」という意味合いから、外部設計とも呼ばれています。

状況が頻繁に変化する業務の場合、“外部”の変化に合わせていちいちシステムを改善しなければならなくなるため、できるだけコンピュータに頼らない業務設計としておくのが良い。

 

アーキテクチャと非機能要件

業務上の要件と並行して検討する。

アーキテクチャとは?

ハードウェアやネットワークなども含めたコンピュータシステムの基本構造のことです。

 

 

非機能要件とは?

 コンピュータシステムの基本性能や信頼性など、業務機能ではない要件のことで、具体的にはセキュリティや信頼性、保守性、BCP(事業継続計画)などが挙げられます。非機能要件の実現もアーキテクチャに依存し、必要な投資を大きく左右するので、業務上の要件である機能要件とのバランスを含め、慎重に検討しなければなりません。

 【“非機能要件”の関連トピックス】

「非機能要求を可視化したい、大手SIベンダが検討会発足」(@ITNews)

 

 

システム開発におけるユーザーの役割

 これらのバランスを考えて、どんなコンピュータシステムにするかを決めること。

費用対効果を高めるために優先順位を付け、無駄を省くこと。

コンピュータシステムはあくまで業務の道具であること。

 

よいシステムを適正な価格で作るためのポイント

 コンピュータシステムを開発しようとなると、

「最新のITに何をどこまで期待できるのか」「それにはいくらかかるのか」

といった疑問が浮かんでくる。

RFI(情報提供依頼)RFP(提案依頼)という手法を活用して解決。

 

 

RFI【 Request For Information 】 情報提供依頼書とは?

企業が調達や業務委託を行う際、自社の要求を取りまとめるための基礎資料として、外部業者に情報提供を要請することです。平たくいえば、メーカーやベンダに大まかな目的と制約事項などを伝え、

「どんなITを使うと業務をどう変えることができるのか」

「それにはいくらくらいかかるのか」

を問い合わせることです。

「自社開発か、パッケージ導入か」

「構築費を掛けて“購入”するのか、SaaS(software as a service)アウトソーシングを利用して“レンタル”するのか」

──開発の方向性を左右する、こうした大きな選択肢の1つ1つを検討するために、“桁ズレ”しない程度のだいたいの費用と、最新のITに関する情報提供を求めます。

これは社屋建築でいえば、「新築か、建て売りか、賃貸か」「鉄骨か、木造か、プレハブか」などをイメージする段階です。 

 RFIを活用するタイミングは、予算執行の前年に行う戦略立案の前後がよいでしょう。

 

 

RFP【 Request For Proposal 】 提案依頼書とは?

 RFIを元に作成されるもので、情報提供依頼書(提案依頼書)と呼ばれる。

具体的なシステム提案(個別具体的な業務のための機能要件に加え、自社のITインフラやアーキテクチャの強化計画、セキュリティポリシーなどを遵守するための非機能要件まで、具体的に示すことで、実際に「いくらお金をかけると、どんなシステムを作れるのか」)、ベンダから提案を受けます。

 

RFPの活用のタイミング

RFPは発注側の要求がはっきりしていないと意味が半減してしまうので、活用するタイミングは早くても要件定義終了時、慎重を期すなら基本設計終了時がお勧めです。むろん、早い段階で一括契約に移行できれば、その時点で費用の心配がなくなり気分的には楽ですが、あまりに早い段階で金額を決めてしまうと、発注側、受注側、双方にとってリスクとなります。

 

要件を決め込む「序盤」と、導入して機能・効果を試す「終盤」は準委任方式とし、一括請負契約にするのは「中盤」の構築段階にとどめるのが、よいシステムを適正な価格で導入するコツです。

 

要求をきちんと伝えるのが発注者の役割

 システム開発を依頼する際には、「各要件をどの程度実現できるのか」をSLA(サービス品質保証契約)として約束し、パフォーマンスがこれを下回った場合のペナルティ条項も明らかにしておきます。運用開始後にこのパフォーマンスを維持管理する活動をSLM(サービスレベル管理)と呼び、システム開発の目的・効果が実際に得られるよう、ベンダとの協力体制を維持します。

プロのSI事業者は、コンピュータシステムに何を求め、どのように使い、いくらまで出せるのか、ユーザーにしか決められないことを明確に教えてほしいと望んでいます。

「ユーザー部門同士の意見がまとまらず要件が固まらない」

「投資の目的がはっきりせず、いくらまで費用を掛けていいか、はっきりしない」──こうしたことが決まらないと、開発業務を行ううえで、労力、コストの両面で大きなリスクになってしまうからです。

 

⇩ ここまでの内容は下記サイトを参考にさせていただきました。

5分で絶対に分かるシステム開発 (1/6)-ITmediaエンタープライズ

 

システム関連の用語に関して

 

 

システムインテグレーションSI System Integration / SIサービス

 

SI事業 / SIビジネス

システムインテグレーションとは、企業の情報システムの企画、設計、開発、構築、導入、保守、運用などを一貫して請け負うサービス。これらの工程のうちのいくつかを請け負う場合もある。システムインテグレーションを行う企業をシステムインテグレータSIer:System Integrator)という。

まず顧客の要望の聞き取りや業務の分析、既存システムの調査などを行い、必要なシステムの企画や設計を行う。これに沿ってパッケージソフトで賄えない機能など必要なソフトウェアの開発などを行う。

その後、ハードウェアやパッケージソフトなどの調達を行い、独自開発のソフトウェアや既存のデータなどと組み合わせてシステムを構築、業務への導入を行う。システムの稼働開始後は保守・運用や利用者へのサポート、障害時の対応などを行う。

 

 

 

システムエンジニアリングサービスSES System Engineering Service

システムエンジニアリングサービスとは、システムやソフトウェアの開発・運用などで行われる委託契約の一種で、対象物の完成などを目的とせずに特定の業務への技術者の労働の提供を行う契約。提供元企業の従業員が客先のオフィスに常駐して技術的なサービスを提供するもの。

労働法規などでは業務請負の一種とみなされ、労務管理や指揮命令系統などが発注元企業から独立している必要があるが、具体的な成果物をはっきり定めず漠然と労働力を提供する委託形態のため、実態が派遣労働と変わらず偽装請負と見られる事例も多いと言われる。

 

 

 

要件定義requirements definition RD

要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。

要件定義では、利用者がそのシステムなどで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」設計・実装すべきかは後の工程で検討される。

要件定義に先立って、利用者が業務を進める際に、そのシステムなどを使って何がしたいのか、何ができなければ困るのかといった内容を聞き取ってまとめる作業を「要求定義」というが、要件定義と要求定義を同義とする立場もあり、その場合は、このような利用者からの要求をまとめる作業も要件定義に含まれる。

 

 

 

基本設計basic design BD / 概要設計 / outline design / FD 

基本設計とは、製品の基本的な設計。構成や仕様、機能などの概要をまとめたものを意味する場合と、中枢や基盤的な部分の設計を意味する場合がある。

汎用的な製品について言う場合には後者である場合が多く、「同じシリーズの製品は基本設計が共通している」というような用法となる。

情報システムやソフトウェアの受託開発などでは前者の意味である場合が多く、開発工程の中で要件定義詳細設計の間に位置する工程を意味する。

顧客が必要としている要件をまとめた要件定義を元に、どのようなシステムを開発すればそれを満たすことが出来るかを検討し、機器の構成や実装すべき機能、画面や帳票など操作や入出力に関する事項、生成・保管されるデータの概要など、システムの基礎的な仕様をまとめたものを基本設計という。

 

 

 

RFIRequest For Information 情報提供依頼書

RFIとは、情報システムの導入や業務委託を行うにあたり、発注先候補の業者に情報提供を依頼する文書。調達条件などを決定するために必要な情報を集めるために発行するもので、一般的にはこれを元にRFP(提案依頼書)を作成し、具体的な提案と発注先の選定に移る。

発注元の企業や行政はシステム開発事業者に比べて最新技術に精通しておらず、自社の必要とするシステムをどのように提示すればよいか必ずしも明確でない場合がある。また、初めて発注するタイプのシステムや、取引したことのない業者に発注する場合、システムの構成要件や調達条件を記述するための基礎的な情報が不足していることがある。

このようなときにRFIが作成され、業者から必要なシステムに関連する情報を提供してもらい、適切なRFP作成に役立てる。同時に、RFIの結果を比較してRFPを発行するに足る能力があるか業者選定を行う場合もある。

 

 

 

RFPRequest For Proposal 提案依頼書

RFPとは、情報システムの導入や業務委託を行うにあたり、発注先候補の業者に具体的な提案を依頼する文書。必要なシステムの概要や構成要件、調達条件が記述されている。

RFPには、必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証用件、契約事項などが記述されており、業者はこれをもとに提案書を作成する。発注元は業者の提案書を評価し、契約する業者を選定、ハードウェアやソフトウェア、サービスなどを調達する。

これまで情報システム業界では、口約束やあいまいな発注による開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに悩まされてきた。事前にRFPを通じて調達条件や契約内容を明らかにしておくことで、こうした混乱を未然に防ぐことの重要性が注目されつつある。

 

 

 

上流工程upper process 上流プロセス / 上流フェーズ

上流工程とは、ハードウェアやソフトウェア、システムなどの開発・設計における初期の段階のこと。おもに、対象物に求められる機能を抽出する「要件定義」や、実装される機能を定義する「機能定義」、設計物の構造を検討する「構成管理」、全工程のスケジュールを計画する「計画立案」などの工程を指す。

従来、上流工程は生産性が直接目に見えないために軽視される傾向もみられたが、対象物の機能がますます高度化・複雑化し、さらに市場の競争激化にも影響を受け、短期間での開発が必須となっている現在においては、上流工程での設計活動が設計物の品質及び短期開発の可否が左右されると言われている。

とりわけ、システムや装置の複雑な機能の大半がソフトウェアで実装されるようになってからは、その品質の低下、機能の欠陥が社会的に問題になり、上流工程での対策が注目され、重要視されるようになった。

設計物の生産性や品質の高さを客観的に評価し、改善する指標としては米カーネギーメロン大学ソフトウェア工学研究所で開発された、CMM/CMMIが有名。

 

 

 

下流工程lower process 下流プロセス / 下流フェーズ

下流工程とは、ソフトウェアの開発工程において、実装(コーディング)やテスト、導入など、具体的なソフトウェアの構築・配備に関する工程のこと。これに対し、分析や設計などは上流工程にあたる。

上流・下流という言葉は、古典的なソフトウェア開発工程のモデルであるウォーターフォールモデルに由来し、開発工程を分析・設計・実装・テスト・運用などの各段階に分け、あたかも水が流れ落ちるかのように工程を進め、前の工程へ戻らないような進め方をする。このモデルのイメージから、前半の工程である分析・設計などは上流、後半の工程である実装・テストなどは下流と呼ばれるようになった。

上流工程・下流工程という考え方に基いたソフトウェア開発では、基本的に、終了した工程の結果(要求仕様定義、設計)が正しいものとして開発を進めるため、実装やテストなどの、開発工程の終わり頃になって要求仕様定義や設計などの問題が発覚することがある。開発期間などが述び、開発コストが増加することが問題となっている。

また、大規模なソフトウェア開発においては、上流工程と下流工程を、異なる企業が担当することもあり、その際、単純に二つの工程に分かれるだけでなく、複数の企業が関わることが多い。しかし、上流から下流までの間に複数の企業が存在するため、下流工程において、上流工程の企業への、仕様の解釈の確認などで時間をとられることもある。

これらの問題は、ウォーターフォールモデルが、下流工程から上流工程へ戻る(仕様の修正など)を考慮していなかったことが原因であり、これらの解決を目指した開発モデルに、スパイラルモデルなどがある。

 

 

 

 

広告を非表示にする