ソフトウェアJITによる情報システム構築プログラム・マネジメント支援サービス
小プロジェクトの継続的編成支援
概念データモデル設計法による情報システム構築企画を受け止めて、小プロジェクトを機動的にスタートさせるPMO(プログラム・マネジメント・オフィス)の活動をブレーンとして支援します。
1~6ヶ月の支援を通して、PMOスタッフが独立すると終了します。
1名の情報システムコンサルタントが担当します。
ここにメッセージを入れることができます。
第8回 第3部 ITをビジネスに活用する技術 3.4 IT以前の課題「働く人の心を繋ぐ」
第8回 第3部 ITをビジネスに活用する技術 3.4 IT以前の課題「働く人の心を繋ぐ」 「かんばん」は「ものづくり」の現場で働く人々の同期連携を図る方策の一つだ。しかし、独り歩きする幼児に似ている...
第9回 第4部 事例 生産情報システムの簡素化 4.1 異なる職場で働く人々のビジネス連携を図る
第9回 第4部 事例 生産情報システムの簡素化 4.1 異なる職場で働く人々のビジネス連携を図る 「かんばん」は「ものづくり」の現場で働く人々の同期連携を図る方策の一つだ。しかし、独り歩きする幼児に...
第10回 第4部 事例 生産情報システムの簡素化 4.2 働く人々の同期連携を計画する
第10回 第4部 事例 生産情報システムの簡素化 4.2 働く人々の同期連携を計画する 製造ビジネスでは「ものづくり」のための設備・機械や技術・技能者が必須だ。エネルギーや工業用水、副資材などの供給も...
第11回 第4部 事例 生産情報システムの簡素化 4.3 日本固有の生産方式「Seiban」
第11回 第4部 事例 生産情報システムの簡素化 4.3 日本固有の生産方式「Seiban」 個別受注生産と規格品大量生産の狭間で「もの」(加工対象物)の確保が欠かせない。現在の工業製品高度化し、複雑化して...
第12回 第4部 事例 4.4 顧客志向のものづくりを可能にする技術チェーンを捉える
第12回 第4部 事例 4.4 顧客志向のものづくりを可能にする技術チェーンを捉える 高技術化が進む現在、製造ビジネスの兵站線は延び続けている。その兵站線を捉え る仕組みが必要だ。 従来型の部品表は部品構成...
手島塾 概要
NPO法人技術データ管理支援協会(MASP)の重鎮であられる手島歩三氏が永年にわたる 情報システムのSE活動のなかで培ってきた技術ノウハウの集大成を広く伝授するた めに特別講座を用意しました。手島氏は日ごろか...
貸借対照表開示(過去5年間)
第1回 いまなぜ概念データモデル設計か
第1回 いまなぜ概念データモデル設計か IT(情報技術)は急速に発達しており、新しいプレーヤが、従来研究された「大切な事柄」を学ばないで、 「新技術」を開発し、「売らんがため」に過大な効用主張している...
第2回 静的モデルの描き方と心得
第2回 静的モデルの描き方と心得 ビジネスの関心対象世界の構成要素、それらの間の関連を捉えます。一般に言うデータベースの構造と、 実世界の構造を対応&整合させます。 構成要素の事実を表現するデータを...
第3回 動的モデル(実体状態変化過程図の描き方)
第3回 動的モデル(実体状態変化過程図の描き方) 日本では、データモデルを「ソフトウエア開発の過程で作るドキュメントの一種」と考える人が多いようです。 ところが、世界は、「情報」(ディジタルデータ)の...
第4回 組織間連携モデルの描き方と情報品質保証
第4回 組織間連携モデルの描き方と情報品質保証 組織構成部門の役割と業務連携の仕組を捉える 組織が管理責任を持つべき「もの」と「ビジネス活動」を明らかにする。動的モデルにあらわれるビジネス活動の 連携と...
第5回 機能モデル(事業領域と事業使命モデルを含む)
第5回 機能モデル(事業領域と事業使命モデルを含む) 組織が行う活動のパターンを「機能」という。その機能に何に働きかけてどのような結果を得るべきか、 「もの」や「情報」の事前状態(Input)と事後状態(O...
小プロジェクトの継続的編成支援
概念データモデル設計法による情報システム構築企画を受け止めて、小プロジェクトを機動的にスタートさせるPMO(プログラム・マネジメント・オフィス)の活動をブレーンとして支援します。
1~6ヶ月の支援を通して、PMOスタッフが独立すると終了します。
1名の情報システムコンサルタントが担当します。
利用者要求の段階的詳細化
ソフトウエアを開発する前に要求を完全にかつ正しく述べるよう利用者に求めることは妥当でしょうか?
凡人である我が身を振り返りますと見たことがない「柔らかもの」に対して要求を持つことさえも困難です。
何から順番に話せばよいか、専門家であれば要求の整理の仕方や述べ方をまず教えて欲しいものです。
ソフトウエア開発の専門家の立場からいいますと、後でどうでもなる細かなことをいいろいろ述べて、肝心なことを決めない利用者は苦労の種です。
データ要求とデータ処理要求に絞り込む
コンピュータ・プログラムはデータを処理する算法をプログラミング言語で記述したものです。
したがって、インプットデータとアウトプットデータの対応関係を明らかにし、その中で行うべき処理の内容を処理要求として述べれば十分です。ソフトウエア開発段階で経営方針や業務管理方法を聞き出すのはナンセンスです。
データ要求は、ビジネスの事実を適正に表現していなければなりません。
永続し、進化するビジネス組織を支える情報システムの構成要素であるコンピュータ・プログラ ムは変更・拡張・先祖帰りが容易でなければなりません。プログラムの開発段階で、変更・拡張・先祖返りが容易な構造に、プログラムの内部構造を設計する必要があります。その構造は、開発を担当するプログラマでなく、情報システムの運用段 階で変更の必要性に気づく利用者(実務担当者)を含む第三者に理解できるものでなければな らなりません。
主観的な機能構造でなく、客観的な「データ構造に基づいてプログラムを構造化すべきである」と、正統的なソフトウエア工学では勧告しています。データがビジネスの事実を表現するものであるなら、プログラムに実世界の構造が反映されます。そうであれば、利用者にも理解しやす いでしょう。
詳細要求を聞き出す前に、データ構造に沿ってプログラムの骨格部の構造を描き、プログラミングしてその妥当性を確認するほうが、課題の焦点を早く絞り込むことができます。それが妥当であれば、詳細部の計算内容を利用者から聞き出し、処理モジュールを作成して単体テストします。できあがったモジュールを骨格部に組み付けるとプログラムができあがります。その出来映えを利用者に見ていただきながら、プログラムを完成させることができます。最初に完全なプログラム要求を述べなくても、データ設計ができているとプログラミングに着手でき、あとで詳細要求を正確に決めることをお奨めします。
2024年度開催された定期講演会、セミナー等