NPO法人MASP は日本のものづくりの長所(多品種少量生産)を活かす情報技術整備を支援します!

メインメニュー
ログイン
会員登録済みの方は
ここからログインを
ユーザー名:

パスワード:


パスワード紛失
Forum会員新規登録
最新ニュース
トップ  >  1 情報システム工学  >  1 情報システム工学

1 情報システム工学

 ここで解説する情報システム工学は、ビジネスのためにITを使う考え方や方法を見直して、ビジネス組織をIT活用に関して世界に通用する構造に改革することを目指して、技術データ管理支援協会が提供する一連の方法です。大手IT業者(例えばGAFA)が世界のIT業界を支配するようになる前、1970年代から1990年代にかけてISOがまとめてきた標準的な考え方に準拠しています。ただし、当時から様々な異質の標準が提案されており、噛み合わず矛盾する標準もあります。日本のビジネス組織のために、その中の矛盾のないワンセットをまとめたつもりです。古いけれど、今後数十年にわたって役立つと確信しています。

 

情報システム工学の体系

 現在、用意している教育コースは以下の5コースです。これは情報システム工学の骨格部分です。今後必要に応じて各項の内容を肉付けし、分岐する可能性があります。

1-1 情報システム・アーキテクチャ基礎

情報システムとは何か、理解していただきます。

1-2 概念データモデル設計法

続いて情報システムの構造を捉え設計するための考え方を身に着けて下さい。

 

1-3 聞き方話し方訓練

ITをビジネスに役立つようにするためには、ビジネスの現場で働く方々と話し合う能力が必須です。沢山の知識よりも、話し合う技能を身に着けて下さい。

1-4 情報システムのためのソフトウエア工学

ITを活用するには、ビジネスに関与する方々が持つ知恵をソフトウエアとして、コンピュータが理解できる形式で記述する必要があります。ソフトウエア工学に関して、日本多くの技術者は軌道修正と役割変更が必要です。新しい役割「カイゼン(Kaizen)」パートナーとして身に着けるべき技術を紹介します。

 

1-5 プログラム・マネジメント

情報システム構築(開発だけでなく、保守《変更・拡張・縮小・復元など》を含む)に関して、ITの利用者が主体性を持って取り組む必要があります。利用部門の方々が情報システム構築活動を主導するための管理技術として「プログラム・マネジメント技術」をビジネス組織に導入していただきたく思います。情報技術者の皆さんの新しい役割が見えて来るでしょう。

 

1-1 情報システム・アーキテクチャ基礎

 このセミナーでは、技術データ管理支援協会が提供する情報システム工学に関する教育サービスの前提となる、ビジネス情報システムに関する基礎技術を解説します。概念データモデル設計法など、他のコースに参加される場合、このコースを受講していることが受講資格となります。

 日本の多くの情報システムはアーキテクチャを考慮しないで構築されたものが少なくありません。むしろ、学会を含めて「アーキテクチャとは何か」その意味さえも理解していない人が大多数を占めます。

 分かり易く言うと、アーキテクチャは人工物を作るために役立つ技術を使い分ける技術(技術に関する技術=メタ技術)です。多くの人たちがソフトウエア・アーキテクチャと情報システム・アーキテクチャを取り違えています。日本のビジネス組織の進化を可能にし、支えるために、ビジネス情報システム・アーキテクチャを理解していただきたく思います。

 

a)情報システムとは何か

b)目指す情報システム

c)情報システムの構造

d)情報システム構築アプローチの改革

 

a)情報システムとは何か

情報システムとは何か、その概念が狂っている企業が多数あります。機能要求を満たすソフトウエアを集め、組み立てても、情報システムにはなりません。情報システムは「ハコモノ」ではありません。ISOのデータベース・スキーマ記述言語に関する作業グループが出した1985年の報告書によると、情報システムの使命はビジネスに関与する人々の「意思疎通を支援すること」だそうです。

 

b)目指す情報システム

2010年代末のいま、ITは発達し、情報システムはビジネス組織が持つ「知識と知恵を活用するための仕組み」に変化しています。その中核であるはずの基幹系システムが構造悪化し、多くのビジネス組織が世界の流れから落ちこぼれ始めています。進化するビジネス組織を支えるために、情報システムも進化し続けなければなりません。

 

c)情報システムの構造

情報システムの構造改革が多くのビジネス組織にとって必要です。知識や知恵を蓄積し、活用し、さらに進化する、そのような可能性を持つよう、情報システム構造を見直しましょう。

 

d)情報システム構築アプローチの改革

進化、それがこれからの情報システムの要件です。適切な構造化アプローチにより出来上がった情報システムを進化させることだけではありません。構造が悪化し、肥大して品質が悪くなったレガシー・システムを良い構造に進化させることが重要です。巨大なプロジェクトを発足させると、その間の進化に対処できなくなり、経営危機を招きかねません。急ぐ重要なことを素早く実現する、進化型アプローチを強くお勧めします。進化を重視すると、情報技術者の役割やスタンスが変わります。情報技術者も進化しなければなりません。

 

 

1-2 概念データモデル設計法

 概念データモデル設計法は、「情報システムのビジネス整合」を図るための情報体系を設計する方法(a method)です。概念データモデルを描くと、ビジネス様式(ビジネス・アーキテクチャ)が姿を現します。

 ビジネス組織が関心を持つ「もの」や「こと」の事実を捉えるデータを設計し、その採取・蓄積・更新する情報処理機能を一体化(カプセル化)しますと、必要最小限の複雑性を持つ簡素な情報システム構想が出来上がります。業務担当者から見て理解しやすい簡素な情報システムであれば、ビジネスの進化に応じて素早く、少ない労力で進化させる(変更・拡張・縮小・復元)ことができるでしょう。

 この方法を用いてKDDIやJFEスチールは既存の肥大したシステムを簡素な構造に進化させ、システム統合に成功しました。その後も進化し続けています。千葉県の小企業の中に経営者が概念データモデルを設計し、自社のビジネス・アーキテクチャに適合するソフトウエアを選んで、ビジネスの進化に取り組んでいるケースがあります。「ビジネスに合うソフトウエア・パッケージを選び、改良する」ことが成功の鍵となります。

 概念データモデル設計法を構成するモデルは5通りあります。

 

a)事業領域と事業使命モデル

b)静的モデル(表記法として「実体関連図:Entity Relationship Diagram」を用いる)

c)動的モデル(表記法として、MASP独自の「実体状態変化過程図:Entity Lifecycle History Diagram」を用いる)

d)組織間連携モデル(静的モデルと動的モデルを「情報品質保証体制」の視点で統合分散配置する)

e)機能モデル(表記法として、「データフロー・ダイアグラム:Data Flow Diagram」を用いる。

これらの方法を状況に応じて組み立て、使い分けて下さい。

 概念データモデルを描くと、基幹系情報システムは小さな構成要素に分解されます。ビジネス上急ぐ重要な構成要素を素早く実装すれば、情報システムを段階的に構築あるいは進化させることができます。

 

a)事業領域と事業使命モデル

 これはデータモデルには含まれません。概念データモデルを描く前に、ビジネスの対象世界を確認するためのモデルです。ITを利用する前に、どのようなビジネスを営んでいるか、そのビジネスがどのような方向に変わって行くか、あるいは変えようとするか、確認したい場合に「事業領域と事業使命モデル」を描いて下さい。

 小規模の事業体では日常の業務に追われて、事業の環境変化やビジネス改革の必要性に気付かないかもしれません。知識不足や対応不足のために経営が難しくなり、IT活用の必要性に気付いていないかもしれません。

 そのようなとき、「事業領域と事業使命モデル」が役立ちます。このモデルでは様々な経営戦略論を「一般システム論」により解釈できます。例えば、「強み・弱み分析(SWOT:Strength Weakness Opportunity Threat)」や、「価値連鎖(Value Chain)」の意味を理解し、自力で戦略を策定していただけるでしょう。

 概念データモデルを描いた後で、もう一度「事業領域と事業使命モデル」を描くことをお勧めします。ビジネスの事実をあるがままに捉える情報システム構想が出来上がっていますので、ITベースの斬新な経営戦略が出て来る傾向があります。

 

b)静的モデル(実体関連図とその文章表現)

 「情報システムのビジネス整合」がこれからの情報システムの要件です。トヨタ生産方式では「現地・現物」を捉えることが肝要と主張します。ビジネス組織は「もの」(人、物、組織など)に働きかけ、目的達成を目指します。

静的モデルでは「もの」(Entity:実体)の状態を捉えるデータおよび、実体間の機能的な関連を表すで^データを設計します。ただし、詳細な属性(データ項目)の設計は後回しにして、どのような種類の「もの」に関心が有るか、および個々の「もの」どのような視点で識別するか(「もの」の管理精度)考え「識別子」を定めます。

 「ものデータ」はデータベースあるいは帳簿に記載されます。識別子は帳簿の索引に相当します。「もの」たちの間の「関連」に沿ってデータを素早く検索できるデータベースあるいは帳簿体系が姿を現します。「もの」の数とデータ件数は一致します。

 「もの」を目的語とし、「機能的関連」を動詞として文章表現しますと、業務機能体系を表す文章ができあがります。この文章を見て、静的モデルの妥当性を判定し、問題があれば、文章を改定し、モデルも改定します。

 つまり、ビジネス組織が持つ「データベースの構造」あるいは「帳簿体系」は業務機能体系と一致することが肝要です。

 

c)動的モデル(実体状態変化過程図)

 ビジネスの関心対象世界に「もの」が出現し、状態変化し、消滅するまでのビジネス活動の順序規則を「動的モデル」として表現します。それはビジネス活動の進行過程に応じて、「もの」データベースあるいは帳簿にデータを登録、更新、削除する順序規則を設けることにほかなりません。

 もしも、ビジネス活動の順序規則違反があれば、データベース(あるいは帳簿)のモジュールが「順序規則違反です」と警告を発するよう、ソフトウエアを作ることができます。例えば、あるお客様に予約した商品を他のお客様に売ろうとすると、「この商品は予約済みです、売ってはいけません」と警告させましょう。業務規則違反をその場で取り押さえるデータベース(あるいは帳簿)管理の仕組みを設計することができます。

 「もの」は自然法則、技術規則、ビジネス規則に則って状態変化します。物がある状態に達したとき、何らかのビジネス活動を起動する必要がある場合、警告を発するか、自動的に起動させる仕組みも動的モデルで表現できます。例えば、予約した商品をお客様が引き取りに来ないまま、一定期間が過ぎたとき、お客様に警告するとか、予約を取り消すなどです。

 IOTの仕組みの概要もこのモデルを応用して記述できます。ソフトウエア発注の時、役立つでしょう。ある大手製造業では塗装工場の自動制御の仕組みを設計しました。

 動的モデルでは「もの」の状態を変化させる「こと」の事実を表す属性(データ項目)も設計します。その事実をデータベースに登録・記載します。つまり、データベースのデータ項目は動的モデルにより設計されます。

 

d)組織間連携モデル(「情報品質保証体制」の視点で統合分散情報システム構想を描く)

 基幹系情報システムでは採取し、取り扱う情報の品質保証が極めて重要です。操作ミスの類はソフトウエア技術者に任せて検出してもらえます。業務規則違反に関しては動的モデルによって検出できるでしょう。データのエラーを素早く修正し、正しいデータのみを基幹系システムが扱えるよう、情報品質保証体制を設計しましょう。

 「もの」の管理責任を持つ部署が「ものデータ」の、「こと」の管理責任を持つ部署が「ことデータ」の管理責任を持つよう、静的モデルと動的モデルを部署に分散配置しましょう。例えば、国民の管理責任は政府が持ち、住民の管理責任は市町村が持つといった具合です。

 組織間連携モデルは、実装に用いるコンピュータ(クラウドを含む)の統合分散を定めるための論理上の基準となります。適切に分散させることにより、トラブル発生時の影響範囲を最小限に絞り込むことができます。

 少し難しい話ですが、ビジネスの実世界は一般システム論で言う「相互作用系」です。現在のサービス指向アーキテクチャは相互作用を支援するためのアーキテクチャです。

e)機能モデル(価値連鎖付き「データフロー・ダイアグラム」)

 動的モデルや組織間連携モデルに描かれた「こと」(ビジネス活動)の内容を詳しく描く必要がある場合に、データフロー・ダイアグラムあるいは、価値機能連鎖図を描きます。

 

 概念データモデルにはビジネス組織が関心を持つ世界(Universe of Discourse)の「現実」を捉えるデータ構造が描かれます。概念データモデルを記述する過程で多くの方はビジネスや現有システムの「現状」が「ビジネスの現実」と一致しないことに気付くでしょう。それをメモしておいてください。

 モデル記述の後、「現状」を「ビジネスの現実」に近づけるための、あるいは「好ましい近未来を招き寄せる」ための業務改革、情報システム構造改革、ビジネス改革などの活動を始めましょう。その取り組み方については後で説明します。

 

 

1-3 聞き方話し方訓練

 情報システムは「ビジネス組織が持つ知識と知恵を活用するための仕組み」です。知識と知恵をIT特にコンピュータに広義のソフトウエア(「データ」と「データ仕様」および「コンピュータ・プログラム」)として教え込む必要があります。それは生まれたばかりの赤子に言葉を教え、働き方を教えることと同様な工夫と時間が掛かる作業です。途中で間違えると、想定外の問題が起き、改定・改修に手間と時間が掛かります。

 ビジネスの実務を担当する方々が持つ知識や知恵を、できるだけ誤解の余地が少ない言葉遣いでソフトウエア技術者に伝える方法を「聞き方話し方訓練」として提供します。単に、ソフトウエア開発のためだけでなく、日常の業務遂行や、問題解決活動にも役立つでしょう。

 この方法は筆者らが若い頃所属していた日本ユニバック社(現日本ユニシス)のNUPS法の改良版です。NUPS法の開発に取り組んだ筆者らがその意味を見直し、改良しました。

 

a)素問題の把握

b)システミック表現

c)真意の模索・追及

d)為すべき事柄の確認と関連付け

などの方法を提供します。

 ただし、これは「技能教育・訓練」です。技術だけ学んでも行動できません。数日の演習を通して、技能を身に着けていただきます。

 

a)素問題の把握

 ビジネスの実務に関与している方々、従業員だけでなく、お客様や取引先も含めて(クライアント:client)、の感じている「素問題」すなわち問題点や、要望など、を知ることが肝要です。そのためにその方々と対話を始めましょう。

 ビジネスマンにとって「聞く能力」が一番重要です。話し手が安心して話せる状況を作り、反論や批判を一切しないで、ただ聞くことに徹して下さい。

 

b)システミック表現

 素問題を受け止めたとき、話し手にその意味を確認しましょう。

現状分析や原因追究では厳禁です。話し手が危険性を感じ、口をつぐむでしょう。

素朴に、意味を確認するための言葉遣い「システミック表現」を身に着けて下さい。この言葉遣いを大東文化大学の内山賢一教授は身に着け、南アフリカのマンデラ大統領が取り組んだ民族融合を支援して来たそうです。

 

c)真意の模索・追及

 ビジネスの問題は複雑で、原因を追究しても反発を招き、しばしば問題をこじらせます。人は不完全で、移り気です。

 前向きに、素問題の話し手が何を求めているのか、問題解決像を探りましょう。「システミック表現」を使いながら話し合うと、明るい未来が見えて来ます。

 

d)為すべき事柄の確認と関連付け

 為すべき事柄を、一般システム論を応用して、モデル化しましょう。それほど難しいことではありません。物の流れや情報の流れとして繋いでみると、問題解決像(複数)の繋がりと全体像が見えて来ます。

 

 従来、日本の教育は知識教育に重点を置いてきました。IT分野では技術の進歩が速く、個人がすべてを学ぶことは至難です。新技術を学んでも、その活かし方を身につけることはさらに困難です。困ったことに「新技術」と称するものの中には、偽物が混じっています。

 技術の側からでなく、人間の側からITを使いこなす技能がいま必要です。沢山のことを学ぶよりも、鍵となる能力を体得していただきたく思います。この方法は1970年代に花王のコンピュータ学校、富士フィルム小田原、味の素など数十の企業で使われ、評価を得ています。

 

1-4 情報システムのためのソフトウエア工学

 狭義のソフトウエアは「データ仕様」と算法を記述した「プログラム(computer program)」です。

 データ作成はユーザの責任です。できるデータ仕様であることが必要不可欠です。ソフトウエア選択の基準は第一義としてデータ仕様です。

 概念データモデル設計法ではそのデータ仕様を設計します。

 データ処理の算法を考えるとき、データ構造に沿ってプログラム構造を導き出すことが基本技です。ビジネス組織が関心を持つ物事の事実を適正に表現するデータ構造であれば、プログラムの内容をユーザが理解できるでしょう。

 ソフトウエアの受入検査・検収はユーザの責任です。テストし易いように、プログラムを構造化することが肝要です。また、発見したエラーを素早く的確に変更できるよう構造化することも肝要です。

 そのような構造であれば、業務改革やユーザの進化に知奈ウソフトウエア保守にも短期間で対処できます。

 ビジネスの現場で働く方々は工夫し、知識や知恵を進化させます。その知識や知恵の進化に応じてソフトウエアも進化させる必要があります。

 そのような情報システム構築のためのソフトウエア工学について説明します。

 KDDIではこのような手法を用いてシステム統合を短期間かつ想定以下の費用で済ませることができました。大企業でなくても、このような方法は大いに役立つでしょう。

 

1-5 プログラム・マネジメント

 ビジネス改革・業務改革はビジネス組織の進化の重要な一環です。現実を踏まえて、急ぐ重要なことから素早く実現・実行しましょう。ビジネスを支える情報システムの構築・保守(拡張、改良など)もその一環です。

 従来のシステム開発では大規模プロジェクトを発足させ、開発が終わるまで長い期間と費用が掛かりました。その間に情勢が変化し、要求が変わると納期がさらに遅くなり、経営危機を招きかねません。

 情報システムの構成要素を小さな、短期間で実現できる単位に分解しましょう。その上で急ぐ重要なテーマに情報システム構成要素のどれが対応するか考え、素早く実現しましょう。KDDIのシステム統合では、一つのプロジェクトの所要期間は平均2週間、長くても3ヶ月の規模にしました。プロジェクトの要員数は最大6名とし、設計からプログラミング、テストまで一貫して全員に責任を持って取り組んでいただきました。小さなプロジェクトチームであれば、会議や打ち合わせは極めて少なくなり、引継ぎが発生しないので、プロジェクト・マネジメントの負担が極めて少なくなります。

 このようなアプローチを採用すると、プロジェクト・マネジメントはソフトウエア技術者に任せて、ユーザ側はビジネス改革活動のマネジメント、すなわち「ビジネス改革のプログラム・マネジメント」に専念することができます。ビジネス改革活動の一環として小さな情報システム・プロジェクトを手順よく編成・発足させましょう。

 情報システム構築活動を経営の一環としてコントロールする「プログラム・マネジメント技術」を取り入れていただきたく思います。

 

a)業務改革案の評価(assessment)

b)業務改革・情報システム構築課題の優先順位付け

c)ビジネス改革シナリオ策定

d)ビジネス改革・情報システム構造改革フェーズプラン策定

などの方法を解説します。

 

 ここでは業務改革課題の評価について紹介します。他の部分は教育セミナーで説明します。

 ビジネスの現場で働いている方々から業務改革のアイディアや、情報システムあるいはソフトウエアの変更要求が出て来るでしょう。また、概念データモデル設計の過程でも同様なアイディアが出てきます。

 そのアイディアが情報システム構成要素の何に対応するか、まず、全体の中で位置づけましょう。

 続いて、現在の仕組みはどうなっているか、客観的に調べましょう。

 その上で、変えると、どのような効果が得られるか、直接効果から始めて、間接効果まで順を追って考察しましょう。そうすると、投資効果が見えて来ます。

 そこで止まってはいけません。多くの仕組みには副作用があり、弱い部分があります。後で後悔しないよう、どのような問題が新たに起きるか、考察しましょう。ソフトウエア開発・保守に掛かる費用や時間も問題の一部分です。

 最後に、新たな問題に対する対策を考えましょう。

 以上を総合して、業務改革のアイディアを採用するかどうか、判定しましょう。

 

 プログラム・マネジメントは業績に責任を負う経営者・管理者が取り組むべき業務です。その方々を助けるために「プログラム・マネジメント組織(PMO:Program Management Office)」を編成して下さい。従来の情報システム部門の代表者や、経営企画部門員、ITの専門家が知恵を合わせて経営層によるプログラム・マネジメントを支援して下さい。情報システム部門は役割が変わり、働き方が変わるでしょう。

プリンタ用画面
カテゴリートップ
1 情報システム工学

ホーム|MASPについて|MASPの活動用語解説最新ニュースアーカイブイベント入会案内個人情報保護方針お問い合わせ
NPO法人技術データ管理支援協会(MASP) | 日本のものづくりの長所(多品種少量生産)を活かす情報技術整備を支援します
Copyright(c) by MASP Association. All rights reserved.