□------------------------------------------------------------------□
□　Ｂ社ステンレス鋼鈑工場操業計画システムにおける設計レビュー
□------------------------------------------------------------------□

---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
1.プロジェクトの概要
----
1.1.操業計画システムの構築
----
　私はシステムインテグレータであるＥ社に勤務してお
り、Ｂ社の依頼を受け、ステンレス鋼鈑工場操業計画シ
ステムの構築を行った。
　Ｂ社はステンレスコイルの製造を行う鉄鋼メーカーで
あり、納期短縮・設備稼働率の向上等を目的に、計画シ
ステムの見直しを企画した。計画対象となる財源は、コ
イル・工程数で１０万を超えており、計画担当者が机上
でシミュレーションを行う事は不可能なボリュームで
あった。事実、システム構築以前の操業計画はマクロ的
な指示に止まっており、コイル単位に見た場合の作業順
序は現場任せという状況であった。
　プロジェクトの方針としては、１０万の財源を対象に
計算機が最適解を導出する事は不可能であると判断し、
計画担当者が計算機に向かい、一つ一つの計画を組み上
げ、工程間のシミュレーションを行う対話的方式を採用
する事とした。このＢ社ステンレス鋼鈑工場の操業をリ
アルタイムにシミュレーションし、対話的に計画を作成
する環境として、ＵＮＩＸワークステーションとウィン
ドウシステムを採用した。
----
1.2.レビューにおける評価項目
----
　前述の様に計画対象の財源は１０万を超えており、こ
れらを個別に計画する事はまず不可能である。従って、
システムには、同時期に作業可能なコイルをグループ化
し、コイル群として財源を提示・計画する機能が必要と
なる。この財源の提示方法が、人の思考を中断しない、
直感的に認識可能なものである事が、レビュー時の最も
重要な評価項目であった。
---------------------------------------------------------------------
 （設問イ）
---------------------------------------------------------------------
2.評価基準とレビューの方法
----
2.1.評価基準
----
　計画対象となる財源を人が認識し、判断するためには、
最低でも以下の情報が必要になる。
　a.何時：工程への到着予定時間。
　b.何が：工程での作業内容。材料の情報（幅・厚等）。
　c.どの位：工程での作業時間。
　またこれらの項目が財源をグループ化する条件であり、
条件の粒度が財源の粒度に直結する。
　レビューのポイントは、上記３項目が直感的に認識可
能である事にあった。ユーザニーズを満たす具体的な条
件としては、マウス・キーボード等の操作によらず、画
面を開いた時点で全ての財源に関し、上記項目が認識可
能でなければならなかった。
----
2.2.レビューの方法
----
　当時はＰＣも普及しておらず、ホスト計算機による
キャラクタインタフェースしか使用経験が無かった計画
担当者にとって、グラフィカルインタフェース
（以下ＧＵＩ）のシステムには非常にとまどいがあった。
打ち合わせにおいても、机上のラフスケッチでは思うよ
うに話が進まず、実画面を用いたレビューを求められた。
　しかしながら、ボタン・リスト等の基本的な部品から
構成されるＧＵＩ構築ツールでは、グラフィックを駆使
する工程シミュレータの様な複雑な画面を作成する事は
出来無い。画面を作成するためには直接プログラミング
を行う事が唯一の方法であった。しかし、方向性が決ま
らない時点でプログラミングを行う事は、必要となる工
数から考えて、デザイン・アイデアの選択肢を狭める危
険があり、私の判断でラフスケッチでのレビューを押し
進める事とした。以上、ぎりぎりまで机上での打ち合わ
せを繰り返し、最終の画面イメージが固まった時点でプ
ロトタイプを作成し、レビューに挑んだ。
　また、レビューの参加メンバーとしては、システムの
利用者は当然の事、その上司にも参加を依頼した。これ
は、計画担当者が２０代半ばであり業務経験も５年以内
と浅いため、ベテランの意見を求める事を目的としたも
のである。
---------------------------------------------------------------------
3.設計上の問題点
---
　財源のグループ化は、計画担当者とのヒヤリングから、
工程での作業内容を条件に考えていた。しかしながらレ
ビューの結果、計画担当の上司から以下の指摘があった。
　バブルが崩壊しつつあった当時では、財源が乏しく設
備稼働率を再優先に計画を作成するため、グループ化の
条件は作業内容が優先される。しかし、財源が潤沢にあ
る場合には納期を優先に計画を作成する場合もある。つ
まり、グループ化の条件は必要に応じて利用者が決定で
きる仕組みにしておくべきであり、財源の粒度はシステ
ムではなく利用者に決定権を与えておかなければならな
い。
　延いては、その様な設計思想がシステムを長く使う事
にも繋がるとの重要なアドバイスを頂いた。
---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
4.評価と今後の課題
----
4.1.レビューの有効性
----
　プロトタイプを作成し、実データによるレビューを
行った事は、システムに対する実感を掴んで頂く上で非
常に有効であった。事実、その後の詳細設計以降にも仕
様変更の発生は無かった。また、運用開始した後もバブ
ルの崩壊によりコイルの生産量が激減するなどの様々な
環境変化が起きたが、計画システムへの大きなメンテナ
ンスは発生していない。
　これは、レビュー時の指摘を着実に取り入れた結果で
あり、プロトタイプによるレビューが功を奏したと判断
している。
----
4.2.レビューの効率性
----
　一方レビューの効率性についても、ユーザの求めるま
まにプロトタイプの作成に着手せず、机上のラフスケッ
チでの打ち合わせを重ねた事は、以下の点から効率性を
評価する事ができる。
　a.複雑なＧＵＩを伴う画面では、プロトタイピングに
　掛かる工数は多く、机上のラフスケッチを用いた方が
　より多くのデザインとアイデアを利用者に確認して貰
　う事が出来る。
　b.最終的に作成したプロトタイプには２人月を要して
　おり、途中ラフスケッチで作成した多くのデザインに
　ついてプロトタイプを作成していたならば、大幅な工
　数の超過になっていた事が予測される。
----
4.3.今後の課題
----
　これ迄に述べてきた様に、プロトタイプを作成するこ
とは、設計レビューにおいて非常に有効である。一方で、
今回は、操作性のレビューに重きを置くがあまり、プロ
ジェクトの初期段階、つまりデータ設計が完了していな
い時点でプロトタイプを作成してしまい、実際のシステ
ムを構築する際には３０％程度のプログラムしか再利用
出来なかった。
　プロトタイピングについては、その目的と行うべきタ
イミングを見極める事が重要であると反省している。ス
パイラル型開発の初期モデルとなるものなのか、レビュ
ー用に作成する使い捨てのものなのか、目的と用途を
はっきりさせた上で着手しなければならない。
　以上、プロトタイプの目的をアプリケーションエンジ
ニアに確実に伝え、それに見合った工数でプロトタイプ
を完成させ、効果的なレビューを進めるようプロジェク
トを運営する事が私の役割であると認識している。