YoRの日記: マニュアルを書けといわれてもなあ 5
日記 by
YoR
想定されるユーザーが何をするものなのかが伝わってないのにどう書けと。
こっちに伝わってるのは動作仕様書だけ。
当然、書けることは仕様書の簡易版。
ユーザーがこういうことをしたいときにはこう操作すればいいですよ、という風に書きたいのに、
こういう機能があります、こう操作すればこう動きます、としか書けないわけで。
これでは取扱説明書じゃなくて操作リファレンスだ。
その辺りを把握しているはずの人(他に居ます)が書けばいいのに実装者に丸投げってどうよ。
せめて「こういう場面で使います」くらい知らせてくれないとどうしようもない。
マニュアルって言い方が良くないよね (スコア:0)
索引となっている書類の事を指してしまうんだけど、そうではないはずなんですね。
ここで必要とされている意味のマニュアルは。
実装者が現状のシステムを既成事実として、ユーザーと同意を得た事にするものになる、
と考えると丸投げされた理由も少しは納得できるのではないでしょうか。
・システムの操作するデータの役割、重要性
・このシステムを利用する想定役職
(セキュリティ的な問題が起きた時の保険)
・全体的な画面構成、オブジェクトの名称
・出来る事、出来ないこと、既知のバグリスト
(いくつかの画面を跨って操作する手順をいくつか
チュートリアルとして用意することで体裁が整う)
・例外が起きた時の対処手順
(悪意か偶然か、不正なデータが流し込まれた時の削除、
修復手段の提示など)
・業務用語集、システムの用語集
・動作に必要とする環境
(環境変更を勝手に行われた時の保険)
・システムエラー、データベースなど、システム不具合が
起きた場合の連絡先
等を、本当の意味でのマニュアルを作るためのリファレンスを用意すること、
という感じで割り切るしかないと思います。
少なくとも、最初に提出するのはそういうもので、それ以上のものを要求された場合、
そこから反応を伺うしかない、たたき台と考えたほうがいいですね。
納品物としてのマニュアルは、そういう立派なノウハウ集でなく、
まさに要求書~仕様書までの貫通版という内容でOK出るべきもの。
そうした標準指標、指定を明確にして丸投げしてないのが問題であって、
投げた先が実装者だからとか、ユーザの利用場面が解らないというのは、
さほど重要でないか二次的副次的要因でしか無いと思う。
というわけで、今日は徹夜でマニュアル作成と、発表資料を作るよ(笑)
Re:マニュアルって言い方が良くないよね (スコア:0)
Re:マニュアルって言い方が良くないよね (スコア:1)
よう急→要求
Re:マニュアルって言い方が良くないよね (スコア:0)
#下に部下がいて、複数人で作るものを指揮しろという話だったらすいません。
実装者に振られるマニュアル仕事って、割りきりが必要ですよと言いたかった。
そして、製品の実装と一緒でプロトタイプを見せないと納得されない事が多い。
だから、使い回しのできるデータ面から揃えていったほうがいいかなと。
それでユーザーが不満を上げてきたら、リサーチの時間をとる必要がある相手で、
リサーチを行うまたはそれを知っている人間に投げるべきと言えばいい。
#一発勝負でやり直
Re:マニュアルって言い方が良くないよね (スコア:1)
業務用の組み込みだと、こういう発注者がよく居ます。
その人が書いてきたラフのような要求書からこっちが仕様を起こして、それで要求を満たしているかお伺いを立てて、大丈夫と返事をもらったけど、検収のその場で「実はここはこうなってるんで変更してください」とか言うような非常にいい加減な…
その人、こちらがマニュアルを書けるほどの理解があると勝手に思ってるかもしれません。
まあ、書けるだけの物を書いたので、それを送るだけですが。