前回は以下のように書きました。
チェックの不備によって発生した手戻り、遅延、予算オーバーなどが「レビュー担当者がレビュー結果に責任を持たなかったがために発生した。」ということがあると参加者全員に理解してもらう必要があります。
もちろんマニュアル制作者が対応をすべき点も多くありますが、このあたりはかなり力関係がものをいう世界です。
開発技術者よりも営業の人など、遅れると困る人を仲間につけて、必要性を理解してもらうのがよいでしょう。
開発が役割を理解し分担する。ごく当たり前の話です。
しかしこれを実現するのはなかなか容易ではありません。
◆共通化モジュールの罠
手戻りなどがない場合でも、非常に複雑なソフトウェアであったり、類似した画面がいくつも出てきてかつ機能的にも似ている、さらに予算がないといった状況で、似たような機能だから共通化したページを作ってしまうということがあります。
これをプログラムの開発としてみるとどうでしょうか。
そうです。一見似たような機能を共通モジュールとして、あらゆる機能を盛り込んだてんこ盛りのサブモジュールを作ることと同じです。
結果はどうなるか。
デバッグ不可能。
どこがどうなってるのかわからない。
普通の場合こうならないように、いくつかの共通部分はマクロ化したり、共通ライブラリを使ったりしますが、別々に部品を作ります。
マニュアルの場合でも同じことをしなければなりません。
うかつな共通化は、後で手直しができないという大変な問題を引き起こす可能性が高いです。
さて、今回で効率化の話はいったんここまでとします。
次回からはマニュアルの形についてやろうと思っています。