コラム・特集

4.3 システム・ライフ・サイクル管理構想

IEハンドブック
第12部 コンピュータと情報処理システム

第4章 情報処理システムの解析・設計テクニック

4.3 システム・ライフ・サイクル管理構想

1960年代におけるIPS失敗の多くは,経営者がIPS開発の経営管理をシステム専門家に委 ねたことに関連していた。経営者は,たいてい洗練されたコンピ ュータをIPSへ導入することによって ,この委任が必然的に正統化されると考えていたために ,ひとつの重要な問題を見過ごしていたということは明白である。すなわち,システム専門家は,無数の複雑な意思決定や組織の諸要求を,経営者ほどは精通していないという問題である。経営者だけでも ,また専門家だけでも,有効なIPSを開発し運用することはできないという認識にもとづいて,システム・ライフ・サイクル管理(図表12.4.2) が,このジレンマの有効な解決策として導入された(ここにはひとつのライフ・サイクル手法が示されているが, 関心のある読者は他の情報源のレビューをされたい)。システム・ライフ・サイクル管理は1970年代に開発され,次の点に関する問題の軽減を目的としている。

・管理と指揮に欠けること
・IPSの設計が貧弱なこと
・IPSに金がかかり不効率なこと
・システムの設計過程が構造化されていないこと

この節の焦点は,プロジェクトの組織化(プロジェクト管理者の任命とプロジェクト・チームの編成),システム開発,システムの保守という諸過程にある。

プロジェクト組織
プロジェクト組織は,プロジェクト管理者の任命とプロジェクト・チームの編成という2つの鍵となる活動から構成されている。

プロジェクト管理者
プロジェクト管理者は,典型的にはユーザー組織のひとりの成員であって(消費者指向のIPSについては,機能上の製品管理者でなければならない),与えられた組織の戦術立案者が,提案されたシステムを知覚した後に任命される。プロジェクト管理者は,あらかじめ設定されている作業計画,諸活動,コスト,予算,日程,そして品質管理の見地から,プロジェクト全体を立案する直接的な日々の責任がある。プロジェクト管理者はまたIPSの費用便役の関係を継続的に追跡する責任がある。

プロジェクト・チーム
IPSが基本的規準を満たすために,様々な技術を統合して適用する必要がある。種々の技術の統合を進めるために,マトリックス組織に基づいてプロジェクト管理チームが編成される。そのチームはプロジェクト管理者,システム解析者,組織設計の専門家,インダストリアル・エンジニア,人事の専門家から構成される。

ひとつのIPSプロジェクト・チーム内で,プロジェクト管理者とプロジェクト・チームの構成員との間の一組のインターフェイスが明確に定義されなければならない。そのチームの構成員には,特定のIPSをめぐる様々な開発努力の指導的役割を演じる責任がある。そうした努力の指導者は「機能上の管理者」と呼ばれる(たとえば,コンピュータ・ベースのIPSにおけるソフトウエア構造に責任があるプロジェクト・チーム構成員は,その機能上の管理者である)。このインターフェイスは Cleland and king が図解している(図表12.4.3を見よ)。

システム開発段階
1970年代初頭以来,構造的システム開発過程につづいて,プ ロジェクト・チームによる有効でかつ能率的なIPSが開発されてきた。そうした過程は一連の作業段階によって特徴づけられる。システム開発に関する文献で用いられている用語や段階数はしばしば異なっているが, 基本的作業活動とそれに関する順序は違っていない。システム開発活動に関するこの章の議論では,次に示されている段階が使われている。

1.提案と実現可能性
2.定義
3.設計
4.開発
5.評価
6.設置 システム開発の各段階は以下の区分になっている*

目 標  その段階で達成されるべきこと。
管理努カ プロジェクト・チームが行わなければならない決定事項の確認とその例示。
主な注意事項 プロジェクト管理者が注意を集中すべき問題点の確認 。

提案と実現可能性
目 標  より速く,より容易に,より上手に,より安く,より安全に,あるいはより少ない人員で行うためのシステムを構築すべきか否かを評価する。
管理努力 提案されたシステムに関するより詳細な情 報を,以下に示されている対象から収集する要員を割り当てる。

・潜在的ユーザー,すなわち,入力,操作,保守, あるいはそのシステムやそのアウトプットの利用に関連する人なら誰でも。
・システムあるいはその技術に関連する領域の専門家

主要な注意事項 以下の領域について分析しなければならない。通常はさらに実現可能性報告書として文章化する 。

・システムが行わなければならないこと(システムの目標)。
・システムが行うことのできないこと (システムの制約)。
・システムロ標を満たすための可能な設計法 (たとえばモジュール性―詳細については「IPSの解析・設計法」という題の節を参照せよ)。
・システム開発に必要とされる人間の数と特性の推定値。
・費用便役の推定値 (すなわち,期待される節約ないしは収益と,システム開発に必要とされる時間および資金との対比)。

定 義
目 標 システムをさらに明確化するために,潜在的なユーザーと関連領域の専門家から詳細な情報を収集する。 管理努力当該システムが大規模であったり複雑ならばサブシステムに分割する。主要な注意事項以下の領域について分析しなければならない (システムについてもサブシステムについても)。通常はさらに明確化報告書として文書化される。

・システムロ標の練り直し。
・日標を満たすのに必要とされる投入と産出 (投入 産出分析の結果として一―詳細は「IPSの解析・設計法」という題の節を見よ)。
・制約の練り直しと性能の要件,たとえば,2時間以内の投入で産出が得られなければならないなど。
・投入を産出に変換するのに必要な機能。
・諸機能と諸サブシステムの間の関係。
・目標を満足すると思われる1つ以上の設計法(Wasserman)。
・システム開発に必要な人数推定値の練り直し。
・費用便役推定値の見直し。

設 計
目 標 設計上の制約の範囲内で,システム目標を満たし,費用便役を最大にする設計を確認するトレー ドオフの決定を下す。

管理努力 数学モデルやコンピュータ・シミュレーション,実物模型,集団討議などを用いて種々の設計技法を分析する。 ハードウエア,ソフトウエアに関する潜在的な問題点について専門家の鑑定を受ける (「IPSの解析・設計法」という題の節のソフトウエア設計用具を見よ )。人事の専門家に意見を求めることによって,雇用者の業績を低下させる可能性がある設計上の特質を 明らかにする。何をユーザーに割り当て,何をソフトウェアが受け持つか決めるためにシステムの諸機能を解析する。さらに,人間と機械の能力,時間と費用要因,潜在的誤り率などにもとづいてトレードオフの決定を下す。

主要な注意事項 ユーザーのための,そしてソフトウエアのための詳細な設計活動が連続して,また並列して開始される (通常は,人的業績の専門家とソフトウエアの専門家から構成される個々の部分に分かれた設計者集団が確立される)。ユーザー機能とソフトウェア機能の相互作用を分析することによって,インターフェイスの設計要件が展開される。たとえば,不必要で出費のかさむ訓練や潜在的な誤りを避けるために,シ ステムのアウトプットを雇用者が容易に理解できる表現に変換しなければならないかもしれない。

設計がより詳細な水準に達するのにつれて,ユーザー仕様とソフトウエア仕様の両者が練り直され,修正される。通常,一方の仕様の変更は他方に影響する。したがって,諸設計者集団の間の断え間のない情報伝達がプロジェクト管理者によって調整され,確実なものにされなければならない。

開 発
目 標 ユーザーのハードウエアおよびソフトウエア 構成要素のための試作品(初版)を 開発する(ソ フ トウエア試作品は「ソフトウエア青写真Jと、呼ばれる ).

管理努力 緊急な程度,論理的関連性,資源などにもとづいて,サブシステム,ユーザーの職務設計,ハードウエアおよびソフトウエア構成要素の優先順位をつける。開発期間推定値と優先順位にもとづいて,職務活 動の日程を展開する。 試作品の開発にもとづいて,ソフトウエアおよびユーザーの仕様(たとえば,職務設計要員の技能と知識の要件,ス タッフ推定人員など)を練り直す。

主な注意事項 設計段階にある間は開発諸集団間の断え間のない連絡が必要である。試作品の開発期間に,ユーザーおよびソフトウエア試作品の両者に影響する変更が確認される。組織環境においてシステム統合化を容易にするために,設置の指針が展開される。その指針は,システムとサブシステムの概観とそれらの機能,人間と機械のインターフェイス,職務の流れ,要員選定規準,スタッフの要件,成果のデータ,そして,この段階以前の領域の決定に影響を及ぼす,検討中に得られたあらゆる情報を含んでいる。

評 価
目 標 要員に対する技能および知識要件を満足する参加者を用いて実地試験を行う。

管理努力 行われる試験の水準と開発日程にもとづいて,試験の日程を立てる。以下の規準のいくつかにもとづいて,行うべき試験の水準を決定する。

1.試験が最終的な運転環境をより正確にシミュレ ート するほど以下の可能性が高くなる。 a.設置以前に問題が認識され訂正される。b 成果とスタッフ人員データが設置計画のための正確な推定値を与える。

2.システムのすべての構成要素を統合して試験す るシステム試験を組み立てるために,様々な試験水準が用いられる. 試験されるサブシステムないしはシステムの目的 にもとづいて試験計画がたてられる。試験結果と参加者のフィードバックを分析する.システムの修正の優先度をつけるトレードオフの決定を行う. システム修正の優先度の高いものを設計し,開発し,再試験する.このサイクルを必要なだけ繰り返す。

主要な注意事項 サブシステムあるいはシステムはその目的に適合していたか。適合していない場合には,どのソフトウエアと要員サブシステムの設計を変更しなければならないのか。

目的はどの程度満たされたか.パフォーマンス・データは,パフォーマンス仕様,要員の技能,知識要件,スタッフ人員推定値,職務の流れなどを修正する必要性を示しているか。 どのような設計上の不整合,誤りあるいは手抜かりが認識されたか。その問題を訂正するためにどのような修正が可能か. インターフェイス上のどのような問題が認識されたかどのような変更を行うべきか。

設 置
目 的 ユーザー組織において新システムに切り換える。

管理努カ システム設計者とユーザー要員によって構 成される切換えチームは以下の事項を計画し実施するために設置指針を利用する。

・ネットワークの要件を満たすための,(管理的および非管理的)職務と方法の修正 。
・職務上の修正に伴う組織構造の変更。
・総労働者数の調整。
・管理者対雇用者比率の展開。
・業績尺度の開発。
・事務,技術および管理要員の選定。
・作業空間の確保と配置の設計。
・手順,指針,表示装置,書式,訓練,業務資料などの修正。
・要員の訓練。
・システムの切り換え。
・切り換えの評価。

主要な注意事項 切り換え初期の経験にもとづいて,ユーザー要員はシステム設計スタッフに情報をフィードバックする。この情報は,(1)必要とされるシステムの修正事項と,(2)システム設計過程における変更あるいは改善すべき領域を認識するために使われる.修正を延期すべき部分は文書化され,そうした問題のある領域については潜在的なシステム・ユー ザーに知らされる設置のための暫定的解決策がプロジェクト・チームによって完成される。

システムの保守
システム保守は3つの主要な保守活動からなる。
1.改 訂 システムの誤動作や不調を直すために行わなければならない修正。

2.予防 システム動作の低下を避けるために,あらかじめ設定されたリスケジュールされた計画に基づいて行われる日常の活動。

3.再整理 改訂されたユーザーや環境上の要件に適合させるために必要な修正 システム保守はシステム有効性の年次的な審査と評価を含んでいる。それはまたシステムの除去,取り換え , 再開発に関係する意思決定を容易にする。この責任は典型的には情報システム設計スタッフの構成員に割り当てられる。

 本コラムは絶版となっている「IEハンドブック(サルベンティ編・日本能率協会訳・1986)」をアーカイブとして掲載するものです。このハンドブックの各章は多くの事例と理論を通して生産性向上に対するアイデアを提供するべく専門家によって執筆されています。基盤をなしているIEの考え方・原則はインダストリアル・エンジニアリングにかかわるすべてのひとに有用でしょう。

関連記事一覧

2019ものづくり公開セミナーガイド

B2Bデジタルマーケティングセミナー

ものづくり人材育成ソリューション

マーケティング分野オンラインセミナー