こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

締切り済みの質問

SEの顧客向け説明文章の練習

システムエンジニアをしており、ある企業の基幹システムの保守開発をしています。
システムを変更する際に『システムをこんな風に変えるから、これからはこういう運用をしてください』といった資料を作って先方の管理者に説明するのですが、この資料作成が苦手です。
資料を作って、上司に見てもらって、書き直し、を何度も何度も繰り返すので、ものすごく時間がかかります。

よく指摘されること
・システムちっくな言葉を使っているので、先方が理解できない
・前置きがなく、いきなり本文が始まる(ような構成になっている)
・(私自身が)当たり前と思ってわざわざ書かなかったが、先方にとっては重要なことが説明不足

何とかして文章力をつけたいのですが、何をしたらいいでしょうか。

投稿日時 - 2016-03-10 01:35:54

QNo.9140757

暇なときに回答ください

このQ&Aは役に立ちましたか?

0人が「このQ&Aが役に立った」と投票しています

回答(5)

ANo.5

 SEであるなら資料作成も仕事の内と思っております。
 数年後には、管理職やPMを任されるかもしれません。その時、経費やら売上の管理、契約書等重要書類の作成等するわけですから、ひとつの勉強と思って対応していけばいいのではないでしょうか?。

 「システムちっくな言葉を使っているので、先方が理解できない」とありますが、これユーザ側の能力不足ですね。私はベンダ経験後、ユーザSEとして従事してますが、ユーザ側のシステム部門といっても、ベンダに比べて格段に能力不足の方がいる会社は多くあると感じてます。言っている私も昨今のスキルには疎くなってしまってますが。
 同じ職種でも、ベンダとユーザでは異なると思った方がいいです。そもそも会社の考え方として、情シス部員だからといって、手を動かしてプログラミングやら保守している人とは限りませんから。
 でも、その点は、ユーザと話をしていて自ずとわかるはずです。それが、最後の「先方にとっては重要なことが説明不足」にもかかってきます。
 どれだけユーザと話されてますか?。常に何が重要かを把握してますか?。
 「前置きがなく~」に関しては、説明前にそれとなく話しておけば、あるいは説明冒頭での会話で、相手に伝わることも可能です。資料は資料なのですから、どう使うかです。但し、ユーザにおいては、ITベンダと仕組みが異なる企業は多く、その資料を更に上の方に通す事はよくあります。お役所仕事みたいなものです。ですので、当事者がわかっていても、他者が不明だと、あれこれ説明しなければならず面倒というユーザもいるわけで(しかも、ユーザは、プログラミングや保守のみが仕事というわけでない方もおります。時間ないのです)、直してくれというケースはあります。この点は、誰がキーマンか?といった認識能力を問われることでもあり、今後PMとなった場合、重要な能力でもあります(受注してほしいのに、下っ端や、役職だけで判断して、せっせと説明していても判はもらえませんよね)。
 他の方も言われている通り、他社員の仕様書は良い勉強材料にもなります。それ以前に、会社として、あるいはユーザ提示での、各書類の書き方というかフォーマットはないのですか?。あれば、それに即して書けばある程度は対応できるはずですが。

投稿日時 - 2016-03-13 20:38:04

自分もSEですが、作成する際に心がけていることがあります。

運転免許取得の時に習ったかもしれませんが、「かもしれない」で資料は作成するようにしています。
その書き方ではわからないかもしれないと思って作成しています。
ユーザーがわからないかもしれない、後から引き継ぐ人がわからないかもしれないと。

要は相手のレベルに合わせが必要ということです。

後は、自分の色をだすことでしょうか。上司の指示に従うのばかりではなく、自分がこういう意図があってそれを記載したいと思ったら、書いてみることです。それで上司に指摘されても納得ができる説明ができれば、問題はないです。

後はいろんな人が書いたドキュメントを見ることです。ドキュメントを見て、どういう意図でどいうことを説明しようとかかれているかをそこから読みとけるかを勉強します。もし、読みとけないとしたら、自分ならどいいう書き方をするかを考えます。

投稿日時 - 2016-03-10 23:15:36

ANo.3

保守・運用の方に向けた資料を作成する場合、操作方法の変更点を箇条書きにして簡素化する必要があります。
保守・運用の方は特に設計に詳しいわけではないので、仕様の変更点に関する知識を求めていません。
保守・運用する側の立場に立ち、どんな情報が必要かを考えてください。
・運用・保守の作業手順の変更点
・何かあったときの対処法
のほうを重要視しているのでは?

技術文章は長々とした文章は必要ありません。
相手が必要と思う部分を強調し、レビューを重ね不足した部分を完結にまとめるだけです。

・設計部門
・プログラマ
・保守・運用
で必要となる情報は異なります。

投稿日時 - 2016-03-10 08:18:02

ANo.2

 自分は営業職ですが、逆にSE技術者向けの技術資料を作れと言われても無理です。同様に技術者の方が素人向けの資料を作成するのは難しいのでしょうね。

 過去に作成し、最終的に先方に提出された資料があると思うのですが、それをひな形に利用されるのはいかがでしょうか?説明資料がどのような構成になっているのか不明ですけど、例えば、
変更の目的(バグ修正、使い勝手改良など)、それに伴う運用変更について
具体的な操作方法について
運用上の注意点
なんて感じでしょうか。

 おそらく、ひな形を確定されれば内容だけ、業界違いの友だちがわかるような内容で書かれれば良いかと思います。

投稿日時 - 2016-03-10 05:21:35

ANo.1

同じプロジェクトの先輩が書いた同様のドキュメントの納品版(完成版)をまずは読み漁ってください。あなたに要求されているレベルの資料のサンプルがそこに大量にあるわけなので。

投稿日時 - 2016-03-10 01:47:41

あなたにオススメの質問