インターフェースとしての外部仕様情報

2003年11月10日

マニュアル制作の期間短縮とコストダウンを目的として、「仕様書などの内容をそのままマニュアルへ」ということを主張されるエンジニアの方が結構いらっしゃるようです。個別機能ベース（リファレンス系）のマニュアルであれば何とかごまかしはききそうですが、タスクベース（主に操作系）のマニュアルではちょっと無理そうな話です。現状でも日程とコストの両面でマニュアル制作現場にはかなりの負荷がかかっており、少しくらい制作プロセスをいじったところで、作業効率が劇的に向上するとはとても思えません。

このような状況で効率改善のポイントとなりそうなのは、やはり設計部門とマニュアル制作部門間のコミュニケーション・ロスの削減でしょう。つまり設計変更があることを所与条件とした上で、変更対応にかかる作業負荷を（エンドユーザー＝お客様へ負担転嫁することなく）効果的に削減できる、設計部門とマニュアル制作部門間のインターフェースのありかたをどう考えるのか？ということです。で、このインターフェースの大部分は「外部仕様情報のありかた＆運用のしかた」に集約されると思うのです。

ですが、最近の開発プロセスはこのインターフェースの部分を甘く見ているように思えてなりません。外部仕様情報のありかたについてはメーカー内で統一の動きもあるようですが、設計変更に伴う連絡や修正管理といった運用面に関しては、なかなか改善が見られないようです。これはおそらく、外部仕様情報を必要とする部門や、それぞれの部門がどのような情報を必要としているのかを正しく把握していないからでしょう。そのため、必要な情報を必要なタイミングで提供することが難しくなっているのではないかと考えられます。

で、ここをどうやって改善するかなんですが、なかなか難しそうです。まず、

1. 誰が外部仕様情報を必要とするのか？
2. 外部仕様情報はどのように使われるのか？
3. 外部仕様情報が使われる場面（操作性検討やマニュアルなど）では、他にどのような情報と組み合わされているのか？
4. 組み合わされている情報の出所はどこか？
5. 組み合わされている情報も、外部仕様情報としてまとめて扱うべきか？

といったあたりを検討することで、現状の問題の所在を明らかにすることが肝要かと思います。その上で、 インターフェースとしての外部仕様情報に必要とされる要件や、運用方法を再考するべきでしょう（でも結局face to faceの時間を増やすとかいうことにされてしまうと、それはちょっと違うんじゃないかなあとか思わないでもないです）。

最後に、外部仕様書については「Joel on Software | やさしい機能仕様」も参考になるかと思います。エンジニアの方には、特におすすめです。