| アーカイブ |
日経BP社の雑誌「日経コンピュータ」に、「社長の疑問に答えるIT専門家の対話術」という連載があります。ここに3月以降、技術データ管理支援協会の技術・手法や考え方に言及しながらビジネスと情報システムについて論じた記事が載っています。当協会の手島歩三理事への取材をもとに、日経BP総研上席研究員の谷島宣之氏が執筆されました。テーマは多岐にわたりますが、どの回も手島理事が説明した概念データモデル設計法や統合工程部品表などの技術に踏み込みながら、情報システムを利用したビジネス改革について述べています。
以下に、掲載号、タイトル、記事のごく一部の引用・抄録を挙げておきます。詳しくは原典を参照ください。
2018年3月15日号
ビジネスと担い手を共に進化させる 未来のために情報システムを使う
ビジネスを担う組織と人のあるべき姿、そこにおける情報システムの役割、その役割を果たせる情報システムの設計方法について技術データ管理支援協会の考え方を紹介する。
企業は、組織と人の知識や知恵を蓄積・活用し、ビジネスを進化させるように情報システムを使うべきである。そのために、ビジネスに携わり知識と知恵を持っている現場の人が、情報の構造をとらえ情報システムを設計しなければならない。ビジネスにおける「もの」と「こと」を情報の構造として図示する概念データモデル設計法という方法がある。業務に詳しい担当者なら、少し支援を受ければ情報の構造と情報システムを自ら設計できる。
2018年3月29日号
「十分な要件定義」は可能なのか 業務部門はとにかく「分からない」
要件定義が不十分で、システム開発プロジェクトが失敗する例は非常に多い。しかし情報システム開発の初期段階で業務部門に要件定義をしてもらうことは難しい。この長年の問題の打開策を説明する。
まず、業務部門の担当者が業務と情報の構造を整理することから始める。この整理の際に概念データモデル設計法を利用する。これで業務と情報の構造の全体像が頭に入ると改革の構想が浮かび、業務改革案とシステム要件を話し合えるようになる。さらに、プロトタイプ・システムを用意すると詳細な要件が次々に出てくるので、それをくみ取りながら情報システムを仕上げていけばよい。
2018年4月12日号
顧客の多様な要求に対処する カギはデータとソフトの構造
市場の成長にしたがって製品の多様性が増していく。製品を作る企業はどのように対応していけばよいかを紹介する。
ポイントは、製品の構成と製造方法を統合表現した統合工程部品表というやり方に沿って、自社の製品を表すことにある。統合工程部品表で業務の骨格となるデータ構造を表す。製品仕様が増えても、変化した工程や部品のみを追加すればよい。作業時間や生産設備などを入力しておけば、スケジューリングを行いながら生産計画を立てることもできる。納期回答や調達手配、緊急対応などがやりやすくなる。先行きを見通せることで担当者が現場で工夫を凝らし生き生きと働けるようになる。
2018年4月26日号
今でもある「在庫を増やすERP」 業務とデータ構造が不一致
「社長がコンサルタントから言われるまま、ERPパッケージの導入を決めた。利用を始めると在庫が増え、現場が混乱した」。ERPが日本に上陸した20数年前によく見聞きした事例だが、現在も同じような失敗が後を絶たない。その原因と対策を解説する。
原因としてよくあるのは、パッケージが想定している業務と自社の業務が合わないことである。ERPパッケージのMRP（資材所要量計算）がよく使われるが、MRPは規格品の大量生産に向いた仕組みである。受注生産ないし多品種少量生産を手がける企業で利用すると混乱する。対策として、生産現場で必要なデータ（情報）の構造を統合工程部品表で表現し、現場に合った生産管理を行えば、リードタイム短縮やコスト削減が容易になる。
2018年5月10日号
レガシー刷新を急ぐな まず遺産相続の計画を
維持に金がかかる既存の情報システム（レガシー・システム）を一気に刷新しようという動きがある。しかし、過去から蓄積してきた大事なデータを引き継ごうとして従来と同じ開発アプローチを続ければ、次第にソフト保守の手間が膨大になっていき、別の悪しきレガシーを抱え込むだけという懸念もある。そうならない対策を紹介する。
まず、ビジネスの仕組みや働き方、すなわちビジネスを支えるデータの仕様を定める。次に、仕様通りのデータを集め、蓄積し、加工して結果を配布する業務アプリケーションを決める。カギとなるのは、ビジネスの仕組みや働き方の中で使われる事実を表すデータを概念データモデル設計法などで整理することである。そのうえで一貫性がある計画を立てて業務と情報システムを少しずつ変えていけばよい。
2018年5月24日号
終わりなきソフトウエア保守 データモデルから見直しを
ソフトウエアの保守・修正になぜ金と時間がかかるのか、納得できない経営者は多い。企業とそれを支える情報システムは共に生き物であり環境や業務の変化に即応できる体制が必要である。
そのためには、データとソフトウエアの構造が、ビジネスの進化に即応しやすく、かつテストがやりやすいようになっていなければならない。ビジネス上の「もの」や「こと」（活動）の事実を把握するデータを設計し、データモデルとして表現する。オブジェクト指向技術を採用し、「もの」データに対して、データ項目と識別子を定め、データの生成・更新・削除・参照、処理順序の制約チェックといったメソッドを組み合わせたソフトウエアモジュール（カプセルと呼ぶ）を用意する。このようなデータモデルに即したソフトの構造化が有効だ。データモデルの整備という前提抜きでソフトウエア保守問題に取り組んでも成果は期待できない。
2018年6月7日号
データモデルを描こう ITは知らなくてもよい
概念データモデルを使うと、様々な業種で業務連携の仕組みを設計でき、業務改善や情報システムの構築を進めやすくなる。多品種少量生産、ERPパッケージ導入の可否判定、レガシーシステムの見直し、プロジェクトの成功率向上、ソフトウエア保守の効率改善が可能になる。その概念データモデルをどう設計すべきだろうか。
まず、業務を熟知し改善意欲を持つ現場のキーパーソンを見つけ出す。特定部門に絞ってモデルを作成し、少しずつ改革の実績をつくる。業務を見直すうちに他の部門に助けてもらう事柄が色々あると気付くので、対象部門を広げていくとよい。モデルやITの知識は不要で、業務に精通していれば表記方法への抵抗はほとんど出てこない。概念データモデル設計を通して情報システムが簡素になり、IT担当者はシステムの改善・改良・拡張・進化を推進しやすくなる。
2018年6月21日号
基幹系が駄目ならAI、RPA、IoTも駄目
経営者の多くは、人工知能（AI）、RPA（ロボティック・プロセス・オートメーション）、ビッグデータを作り出すIoT（インターネット・オブ・シングス）など“革新的”と称されるITに高い関心を寄せている。しかし新技術に飛びついた経営者は、無駄な投資を繰り返すだけでなく、既存の情報システムを否定し蓄積されていた貴重なデータを片隅に追いやってしまうこともある。
新しいITを有効に使うためには、基幹系システムがビジネス活動の事実をリアルタイムに把握できることが不可欠だ。例えば、IoT側で集めたデータを基幹系システムに直ちに反映できるなら、ビジネス活動の事実を即時に把握し、現場のものが今どうなっているかをデータベースを介して他のものに伝えられ、両者の同期をとって動かせる。
また、良いデータを提供できればAIを速く進化させられる。データが悪ければ、あるいは足りなければAIの進化は遅い。つまりAIを利用する組織の知性がAIに反映される。
2018年7月5日号
経営者は見える化が好き そのために業務の地図を描く
経営者は事業を見える化したい。その手段の一つとして情報システムに期待をかける。ところが現状の情報システム群を見渡すと、分断されて見える化に貢献できない場合が多い。急がば回れという。見える化の要請にいきなり取り組み、最新IT製品を買い込むのではなく、組織がどうなれば物事が見えるようになるのか、目指す姿を考えてみる必要がある。
まず大前提として、経営者、事業部門の幹部や担当者、情報システム担当者が事業や業務で使う用語について同じ理解をしていなければならない。例えば、「顧客」や「製品」といった言葉のとらえ方が部門ごとに違う場合がよくある。事業や業務で使う言葉とその関連が分かる業務の地図のような何かが必要になる。誰でも読め、自分で描け、システムに利用できる地図が不可欠だ。
業務の地図の例として、事業の中にある「もの」と、ものを変化させる「こと」を表記し、双方の関連を図にまとめた「概念データモデル」がある。これは業務用語で記述するためITの知識は無くてもよい。
2018年7月19日号
事業や組織の変革を支えよう システム部門の役割は不変
経営者は、市場の変化に合わせて企業が俊敏に変わらなければならないと考える。情報システム部門の役割は、情報システムを利用して変革を可能にする情報を組織と人に提供し、変革を進める手法を組織に伝え変革プロジェクトの事務局を務めることである。
「概念データモデル設計法」を整備・提供している技術データ管理支援協会の手島歩三理事は、以下のように主張する。
・事業とそれを担う組織と人、両方が進化し続けなければならない。
・そのために事業で扱う計数、知識や知恵を記録、分析、利用する情報のシステムが必要。
・情報を複数の事業部門で共有すれば、ある程度まで先を読んで行動し、予想外の事態にも素早く対応できる。
・事業における「もの」（製品や設備など）の情報と、「こと」（活動）の情報の関連（構造）を記述し、事業の担当者が頭に入れ、変革の構想を練る。
・情報の構造にそってアプリケーションを用意し、変化させやすい情報システムを構築する。
同協会の高橋哲理事は、事業の要となる「もの」と「こと」から記述する、あるべき姿（To Be）を描く必要はない、全体を一気に構築しない、新旧データベースの連携ないし統合の計画を立てておく、といったポイントを指摘、概念データモデル設計法を使って変更や拡張がやりやすいアプリケーションを段階的に作ることを勧める。
■出所
日経コンピュータおよび下記サイトに掲載された記事（有料会員が閲覧可能）を抄録しました。
ビジネスと担い手を共に進化させる 未来のために情報システムを使う
http://tech.nikkeibp.co.jp/it/atcl/ncd/14/527117/030500098/
「十分な要件定義」は可能なのか 業務部門はとにかく「分からない」
http://tech.nikkeibp.co.jp/it/atcl/ncd/14/527117/031600099/
顧客の多様な要求に対処するカギはデータとソフトの構造
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/020900001/
今でもある「在庫を増やすERP」 業務とデータ構造が不一致
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/041100002/
レガシー刷新を急ぐな まず遺産「相続」の計画を
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/042300003/
終わりなきソフトウエア保守 データモデルから見直しを
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/051100004/
データモデルを描こう ITは知らなくてもよい
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/052400005/
基幹系が駄目ならAI、RPA、IoTも駄目
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/060800006/
経営者は見える化が好き そのために業務の地図を描く
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/062200007/
事業や組織の変革を支えよう システム部門の役割は不変
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/070400008/
以下に、掲載号、タイトル、記事のごく一部の引用・抄録を挙げておきます。詳しくは原典を参照ください。
2018年3月15日号
ビジネスと担い手を共に進化させる 未来のために情報システムを使う
ビジネスを担う組織と人のあるべき姿、そこにおける情報システムの役割、その役割を果たせる情報システムの設計方法について技術データ管理支援協会の考え方を紹介する。
企業は、組織と人の知識や知恵を蓄積・活用し、ビジネスを進化させるように情報システムを使うべきである。そのために、ビジネスに携わり知識と知恵を持っている現場の人が、情報の構造をとらえ情報システムを設計しなければならない。ビジネスにおける「もの」と「こと」を情報の構造として図示する概念データモデル設計法という方法がある。業務に詳しい担当者なら、少し支援を受ければ情報の構造と情報システムを自ら設計できる。
2018年3月29日号
「十分な要件定義」は可能なのか 業務部門はとにかく「分からない」
要件定義が不十分で、システム開発プロジェクトが失敗する例は非常に多い。しかし情報システム開発の初期段階で業務部門に要件定義をしてもらうことは難しい。この長年の問題の打開策を説明する。
まず、業務部門の担当者が業務と情報の構造を整理することから始める。この整理の際に概念データモデル設計法を利用する。これで業務と情報の構造の全体像が頭に入ると改革の構想が浮かび、業務改革案とシステム要件を話し合えるようになる。さらに、プロトタイプ・システムを用意すると詳細な要件が次々に出てくるので、それをくみ取りながら情報システムを仕上げていけばよい。
2018年4月12日号
顧客の多様な要求に対処する カギはデータとソフトの構造
市場の成長にしたがって製品の多様性が増していく。製品を作る企業はどのように対応していけばよいかを紹介する。
ポイントは、製品の構成と製造方法を統合表現した統合工程部品表というやり方に沿って、自社の製品を表すことにある。統合工程部品表で業務の骨格となるデータ構造を表す。製品仕様が増えても、変化した工程や部品のみを追加すればよい。作業時間や生産設備などを入力しておけば、スケジューリングを行いながら生産計画を立てることもできる。納期回答や調達手配、緊急対応などがやりやすくなる。先行きを見通せることで担当者が現場で工夫を凝らし生き生きと働けるようになる。
2018年4月26日号
今でもある「在庫を増やすERP」 業務とデータ構造が不一致
「社長がコンサルタントから言われるまま、ERPパッケージの導入を決めた。利用を始めると在庫が増え、現場が混乱した」。ERPが日本に上陸した20数年前によく見聞きした事例だが、現在も同じような失敗が後を絶たない。その原因と対策を解説する。
原因としてよくあるのは、パッケージが想定している業務と自社の業務が合わないことである。ERPパッケージのMRP（資材所要量計算）がよく使われるが、MRPは規格品の大量生産に向いた仕組みである。受注生産ないし多品種少量生産を手がける企業で利用すると混乱する。対策として、生産現場で必要なデータ（情報）の構造を統合工程部品表で表現し、現場に合った生産管理を行えば、リードタイム短縮やコスト削減が容易になる。
2018年5月10日号
レガシー刷新を急ぐな まず遺産相続の計画を
維持に金がかかる既存の情報システム（レガシー・システム）を一気に刷新しようという動きがある。しかし、過去から蓄積してきた大事なデータを引き継ごうとして従来と同じ開発アプローチを続ければ、次第にソフト保守の手間が膨大になっていき、別の悪しきレガシーを抱え込むだけという懸念もある。そうならない対策を紹介する。
まず、ビジネスの仕組みや働き方、すなわちビジネスを支えるデータの仕様を定める。次に、仕様通りのデータを集め、蓄積し、加工して結果を配布する業務アプリケーションを決める。カギとなるのは、ビジネスの仕組みや働き方の中で使われる事実を表すデータを概念データモデル設計法などで整理することである。そのうえで一貫性がある計画を立てて業務と情報システムを少しずつ変えていけばよい。
2018年5月24日号
終わりなきソフトウエア保守 データモデルから見直しを
ソフトウエアの保守・修正になぜ金と時間がかかるのか、納得できない経営者は多い。企業とそれを支える情報システムは共に生き物であり環境や業務の変化に即応できる体制が必要である。
そのためには、データとソフトウエアの構造が、ビジネスの進化に即応しやすく、かつテストがやりやすいようになっていなければならない。ビジネス上の「もの」や「こと」（活動）の事実を把握するデータを設計し、データモデルとして表現する。オブジェクト指向技術を採用し、「もの」データに対して、データ項目と識別子を定め、データの生成・更新・削除・参照、処理順序の制約チェックといったメソッドを組み合わせたソフトウエアモジュール（カプセルと呼ぶ）を用意する。このようなデータモデルに即したソフトの構造化が有効だ。データモデルの整備という前提抜きでソフトウエア保守問題に取り組んでも成果は期待できない。
2018年6月7日号
データモデルを描こう ITは知らなくてもよい
概念データモデルを使うと、様々な業種で業務連携の仕組みを設計でき、業務改善や情報システムの構築を進めやすくなる。多品種少量生産、ERPパッケージ導入の可否判定、レガシーシステムの見直し、プロジェクトの成功率向上、ソフトウエア保守の効率改善が可能になる。その概念データモデルをどう設計すべきだろうか。
まず、業務を熟知し改善意欲を持つ現場のキーパーソンを見つけ出す。特定部門に絞ってモデルを作成し、少しずつ改革の実績をつくる。業務を見直すうちに他の部門に助けてもらう事柄が色々あると気付くので、対象部門を広げていくとよい。モデルやITの知識は不要で、業務に精通していれば表記方法への抵抗はほとんど出てこない。概念データモデル設計を通して情報システムが簡素になり、IT担当者はシステムの改善・改良・拡張・進化を推進しやすくなる。
2018年6月21日号
基幹系が駄目ならAI、RPA、IoTも駄目
経営者の多くは、人工知能（AI）、RPA（ロボティック・プロセス・オートメーション）、ビッグデータを作り出すIoT（インターネット・オブ・シングス）など“革新的”と称されるITに高い関心を寄せている。しかし新技術に飛びついた経営者は、無駄な投資を繰り返すだけでなく、既存の情報システムを否定し蓄積されていた貴重なデータを片隅に追いやってしまうこともある。
新しいITを有効に使うためには、基幹系システムがビジネス活動の事実をリアルタイムに把握できることが不可欠だ。例えば、IoT側で集めたデータを基幹系システムに直ちに反映できるなら、ビジネス活動の事実を即時に把握し、現場のものが今どうなっているかをデータベースを介して他のものに伝えられ、両者の同期をとって動かせる。
また、良いデータを提供できればAIを速く進化させられる。データが悪ければ、あるいは足りなければAIの進化は遅い。つまりAIを利用する組織の知性がAIに反映される。
2018年7月5日号
経営者は見える化が好き そのために業務の地図を描く
経営者は事業を見える化したい。その手段の一つとして情報システムに期待をかける。ところが現状の情報システム群を見渡すと、分断されて見える化に貢献できない場合が多い。急がば回れという。見える化の要請にいきなり取り組み、最新IT製品を買い込むのではなく、組織がどうなれば物事が見えるようになるのか、目指す姿を考えてみる必要がある。
まず大前提として、経営者、事業部門の幹部や担当者、情報システム担当者が事業や業務で使う用語について同じ理解をしていなければならない。例えば、「顧客」や「製品」といった言葉のとらえ方が部門ごとに違う場合がよくある。事業や業務で使う言葉とその関連が分かる業務の地図のような何かが必要になる。誰でも読め、自分で描け、システムに利用できる地図が不可欠だ。
業務の地図の例として、事業の中にある「もの」と、ものを変化させる「こと」を表記し、双方の関連を図にまとめた「概念データモデル」がある。これは業務用語で記述するためITの知識は無くてもよい。
2018年7月19日号
事業や組織の変革を支えよう システム部門の役割は不変
経営者は、市場の変化に合わせて企業が俊敏に変わらなければならないと考える。情報システム部門の役割は、情報システムを利用して変革を可能にする情報を組織と人に提供し、変革を進める手法を組織に伝え変革プロジェクトの事務局を務めることである。
「概念データモデル設計法」を整備・提供している技術データ管理支援協会の手島歩三理事は、以下のように主張する。
・事業とそれを担う組織と人、両方が進化し続けなければならない。
・そのために事業で扱う計数、知識や知恵を記録、分析、利用する情報のシステムが必要。
・情報を複数の事業部門で共有すれば、ある程度まで先を読んで行動し、予想外の事態にも素早く対応できる。
・事業における「もの」（製品や設備など）の情報と、「こと」（活動）の情報の関連（構造）を記述し、事業の担当者が頭に入れ、変革の構想を練る。
・情報の構造にそってアプリケーションを用意し、変化させやすい情報システムを構築する。
同協会の高橋哲理事は、事業の要となる「もの」と「こと」から記述する、あるべき姿（To Be）を描く必要はない、全体を一気に構築しない、新旧データベースの連携ないし統合の計画を立てておく、といったポイントを指摘、概念データモデル設計法を使って変更や拡張がやりやすいアプリケーションを段階的に作ることを勧める。
■出所
日経コンピュータおよび下記サイトに掲載された記事（有料会員が閲覧可能）を抄録しました。
ビジネスと担い手を共に進化させる 未来のために情報システムを使う
http://tech.nikkeibp.co.jp/it/atcl/ncd/14/527117/030500098/
「十分な要件定義」は可能なのか 業務部門はとにかく「分からない」
http://tech.nikkeibp.co.jp/it/atcl/ncd/14/527117/031600099/
顧客の多様な要求に対処するカギはデータとソフトの構造
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/020900001/
今でもある「在庫を増やすERP」 業務とデータ構造が不一致
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/041100002/
レガシー刷新を急ぐな まず遺産「相続」の計画を
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/042300003/
終わりなきソフトウエア保守 データモデルから見直しを
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/051100004/
データモデルを描こう ITは知らなくてもよい
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/052400005/
基幹系が駄目ならAI、RPA、IoTも駄目
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/060800006/
経営者は見える化が好き そのために業務の地図を描く
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/062200007/
事業や組織の変革を支えよう システム部門の役割は不変
http://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020900021/070400008/
技術通信記事を創刊号から５号まで、メインメニュー技術解説に掲載しました。
各記事について、コメント欄を設け、質疑回答が出来るようにしました。
各記事について、コメント欄を設け、質疑回答が出来るようにしました。