第8回 やってはいけない、「製造工程」の丸投げ：キーワードでわかるシステム開発の流れ（1/3 ページ）

[高田淳志，株式会社オープントーン]

　開発ベンダ 若井さんの強力なサポートを受けながら、着実に開発が進行していきます。前回「設計作業の成果は完成品質を左右する」では、設計工程での作業に関する一般的な話と、設計作業を進める上で発注担当者としてのかかわり方について話を進めました。今回は、多くの場合「設計」工程の次工程とされる「製造」工程について、前回同様、「一般的な話（知識）」と「発注担当者としてのかかわり方」のそれぞれの面から説明を加えていこうと思います。

発注担当者の「製造」工程へのかかわり

　「プログラミング知識が一朝一夕で身に付くはずがない！」というのはもっともな話。「発注担当者なのだから責任を持って詳細まで理解しておきたい！」と思っても、システム開発のプロたち（システムエンジニア、プログラマなど）の技術レベルに追い付くことはそう簡単ではありません。

---

［注］　今回の話での「発注担当者」とは、システム利用者・システム管理担当者・窓口担当者などの役割にかかわらず、発注側企業でシステム開発や利用にかかわる利害関係者全般というニュアンスで使用します。

---

　確かに、詳細までを理解・検証する必要がある情報システム担当者のような立場の方もいらっしゃいますが、今シリーズの主役である青木室長や赤井君にはそこまで踏み込む必要性はないでしょう。それでは、どういうふうに製造工程へかかわっていけばよいのでしょうか？

図1 どういう風に製造工程へかかわっていけばいいのか

　答えはこうです……「得意な部分を引き受けてください」。「得意な部分」という表現は漠然としていますが、つまり、システム開発の技術だけでは解決し切れない部分を引き受けてみてはどうかということです。具体的には、例えば次のような項目が挙げられます。

1. 画面単位／機能単位など細かい粒度でのレビュー

2. 関係部門間での仕様の迅速な調整・決定

3. プロジェクト費用・納期の迅速な調整・決定

　「そんなのは当たり前だよ、やってるよ」という声が多く聞こえてきそうです。それでは前の例から1つ「1.画面単位／機能単位など細かい粒度でのレビュー」を取り上げてみましょう。ここにはあえて「細かい粒度」という表現を含めてみました。開発の進め方やシステムの規模にもよりますが、多くの開発プロジェクトでは、機能や画面など開発物が一通り出揃ったところ（製造工程の最終局面）での関係者全員参加による一括レビューの実施は取り入れているようです。このタイミングまで進んでからのレビューは、いわゆる最終的な「出荷検査」に近いものです。設計工程で、すべての実現事項・方法が漏れなく仕様書に記述され、また、仕様書作成以降、何ら追加・変更が明示的にも黙示的にも発生していない……ということであれば、そのような形でのレビューを実施するだけで十分なのかもしれません。

　しかし、実際には、画面操作性や操作所要時間に関する課題の発生や業務・仕様間の不整合の発生など、実際に実物（の機能や画面）を利用してみてようやく気付く点や改善を望む点が挙がります。ちょっとした変更でも製造終盤まで進んでからの対応（仕様変更）は、コスト（費用・期間）のみならず、品質に対する影響も大きなものとなります。

ここまでのキーワード

【仕様変更】　文字通り、一度策定した「仕様」を何らかの事情により「変更」や「追加」すること。ただし、どちらかというと発注側の何らかの事情により変更の必要性が発生した場合を指して使われることが多いように感じる。その場合、「仕様変更の発生」＝「発注側が対応コストを負担する」的な一方的な発想をする開発担当者もいるようだから注意が必要。

　

　何をもって「仕様変更」と定義するか。プロジェクトごとにあらかじめ決めておくことをお勧めする。確かに、何かしらの手段（文書、メール、口頭など）で確実に合意をし、それが後からくつがえる場合は間違いなく「変更」なのだが、仕様書で決められていない、あるいはあいまいな記述であったために、後からその必要性が顕在化した場合などまで「（顧客都合と同じ分類の）仕様変更」とされるのはたまったものではない（ただし、「どこにも書いてないじゃないか」とまくし立てる開発担当者もいるので要注意）。

　

　仕様書を読んでみて「説明がクドいな」と思えるくらいがちょうどいい。「これぐらいは常識」という部分を省いた仕様書を読むには「行間を読む（書かれていないことを推測する）」技術が必要になるが、暗黙的な知識や理解のすべてを他人間で共有するのは通常困難で、こうした仕様書をベースにすると仕様変更の多発につながる可能性が高い。