----------------------------------------------------------------------

　H社生産計画システム開発における仕様変更対策

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1. システムの概要と仕様決定を困難にさせた要因
----------------------------------------------------------------------
　 H社は主に電線の材料となるコイルを製造している材
料メーカーである． H社は国内にいくつか生産拠点を持
っている．その中でも伸銅品と呼ばれる，銅を原材料と
した中間製品を生産・出荷している事業所について，生
産計画システムの導入を行うこととなった．

　伸銅品はその生産の形態から「管」，「条」と大きく
二つに分かれる．そのため，事業所内でも「管」生産部
門と「条」生産部門に分け，受注処理，出荷処理を行っ
ている．また，生産のために使用する機械も異なる．そ
のため生産計画システムも「管」，「条」の各々の部門
向けに開発することになった．

　この生産計画システムを請け負ったのは T社である．
私は T社のアプリケーションエンジニアとしてこのプロ
ジェクトに参画し，主に「条」部門向け生産計画システ
ムの機能設計から開発及び現地環境でのテスト，システ
ムの立ち上げまで担当した．

　「条」部門向け生産計画システムにおいて，仕様決定
を困難にさせた要因について次に述べる． H社では受注
毎に工程設計の内容を変え，どのような受注にも応じら
れる様にしていた．ここでいう工程設計とは，条の場合，
工程ごとの材料を鈍す温度，ローラーで延ばした結果の
厚み，切断した後の幅の設定等を指す．受注毎に工程設
計の内容を変える事は，顧客の要望に容易に応じられる
反面，段取作業の多発，工程間歩留の増大という問題を
抱えていた． H社ではこれらの問題を解決するために
「合併」と呼ばれる，同時に生産できる受注内容は同時
に生産してしまう処理を行っていた．しかし，「合併」
する受注の組合せの仕方は特に明確なルールが決まって
いるわけではなく，属人的なノウハウに基づいているた
め，明確な仕様をまとめることが困難であった．

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.仕様決定のために講じた施策
----------------------------------------------------------------------
　1で述べた様にH社伸銅品事業所条部門では「合併」処
理をどの様にシステムに取り入れるかが課題となった．
通常，生産計画システムでは所要量計算が核となるMRP
システムや，どの設備でどの作業をいつ行うか決定する
スケジューリングシステムが大きい比重を占めることが
多い．しかし前述したように H社では受注によって工程
設計を変える．また，合併によって同時に生産できるも
のの量が変化するため原材料の重量も影響を受ける．以
上の理由により「合併」処理を効率良く，正確に行うこ
とが求められた．

　私は以上の要求に応じるために次の様な施策を講じた．
以下，それらについて述べる．

ア）合併処理の標準ルールの策定
　現状，どの受注とどの受注を合併するかという点につ
いては明確なルールはなく，担当者の属人的なノウハウ
に拠っている．そこでH社側のシステム担当者を交えて，
担当者にヒアリングを行い，「大体はこの様な基準で合
併する受注の組合せを決めている」というルールを提示
してもらった．「大体は」というのはさまざまな例外ケ
ース（納期の関係で実際には合併できない，またはあえ
て納期の離れたものでも，材料の歩留まりを良くするた
めに合併してしまうなど）が存在するためである．しか
し，ひとまず例外ケースについては目をつむり，ヒアリ
ングした結果を基に標準的なルールをシステム化できる
形に整理し， H社側に提示した．並行して例外ケースに
対してどの様に対応するか検討し，提示することにした．

イ）例外ケースへの対応方法の提示
　合併のための標準ルールに基づくことで合併処理自体
はプログラムである程度自動処理できる．しかし様々な
例外ケースに対しては自動処理を行うプログラムだけで
は不足であり，人間系の判断が必要になる．そこで合併
された受注同士の組合せを画面上に表示し，必要に応じ
て組合せを編集できるプログラムを別途提供するという
対応方法を提示した．

　以上の時点まで作業を進めたときに H社側より以下の
点を問題点として挙げられた．

(1) 標準ルールによって合併処理を行った場合，どの程
度例外ケースとなるものに対し対処することになるのか，
実際の受注データを処理してみるまで判断がつかない．

(2) 画面上の操作性について仕様書レベルでは評価しに
くい．また，本当に必要な画面が揃っているのかも評価
しにくい．

以上のように挙げられた問題に対応するため，私は次の
様な施策をさら取った．

i)  自動合併処理と画面を完全に別なプログラムとして
提供する．これにより，標準ルールが，評価作業を通じ，
変更された場合や，操作性に対する評価に伴うプログラ
ムの変更作業の影響範囲を抑えることができると考えた．

ii) 画面プログラムについてはデモ用データを用いて早
い段階から評価作業を行うこととした．これは，単にデ
ータを読み込み，画面に項目を表示する，というレベル
より行うことにした．これは前述した様に属人的なノウ
ハウにより業務を行っている現状では，どの情報を見て
作業を行っているのか，担当者しかわかりえないという
部分も大きいためである．

iii)自動合併処理については，一通り動くプログラムが
出来上がってくるまでの時間がどうしてもかかることが
予想された．そこで，機能仕様書レベルでプルグラムの
内部処理が容易に理解できるように処理例を豊富に掲載
するなどのような記述の仕方について工夫を行った．ま
た，どの処理でどの様にデータが加工されたか追跡でき
るようにトレースログファイルをある程度詳細に出力す
ることにした．

iv) ii)，iii)の施策の効果を高めるためにH社側より画
面やトレースログの内容の評価やそれに伴う，標準ルー
ルなどの再検討を T社のプロジェクトチームとともに行
うための人員を派遣してもらうよう， T社のプロジェク
トマネージャを通じ H社に要請を行った．これはXPと呼
ばれる開発手法に含まれる，「オンサイト顧客」と呼ば
れるものを取り入れるためである． H社伸銅品事業所条
部門向け生産計画システム開発では，今まで属人的なノ
ウハウに拠っていたものをシステム化し，かつ紙に書い
た仕様だけでは評価しにくい部分について H社側の要求
と実際のシステムのずれを埋める必要があった．そのた
めこの様な施策を行った．なお，要請の趣旨は H社側に
も理解してもらい，評価担当者が少なくとも1名はT社の
開発ルームに在籍してもらうこととなった．

　以上の施策を講じることで， H社より挙げられた 2つ
の問題に対応することにした．

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
3. 施策に対する私自身の評価
----------------------------------------------------------------------
　 H社伸銅品事業所条部門向け生産計画システム開発は
予定通りにカットオーバーし，現在本番稼動中である．

　今回，合併に関する自動処理プログラムと画面プログ
ラムを別にした．このことで，開発中に H社から寄せら
れた評価内容のプログラム上の反映作業を互いのプログ
ラムに影響を与えることなく行うことができた．また，
 T社の開発ルームに H社側の評価担当者を在席させるこ
とで自動処理の結果や，画面の操作性について使用する
側の立場による評価を早めに行ってもらうことにより，
開発終了後の変更要求の数を減らすことができた．また，
評価に伴う変更作業も結果的にその全体量を抑えること
ができた．

　今回，XPを全面的に採用するのではなく，一部の方法
を導入している．今後，ほかのプロジェクトに参画する
際に開発担当者と勉強会を開くなどし，仕様変更に応じ
やすくかつ開発工数を抑えられる開発体制を整えていき
たい．