手順書の作成はシステムエンジニアの知識を上書きする機会を作る

仕事とか仕事以外でちょびっととテキストを作るワークを抱えています。テキストなのでワタシが作って受講者に聴いて学んでいただくことが目的です。

この「テキストと作る」というタスクを改めて考えると、なんと俺特というか、次から次とアドレナリンが分泌されるんですねぇ。

この「テキストを作る」という行為がシステムエンジニアも経験できると思うんですよね。例えば、手順書を作りますね。導入手順書や操作手順書、構築手順書もありますね。そうそう、運用手順書もあります。一番読まれるのはどの手順書でしょうか。

普段あまり関心を持たずに作っている手順書に対するアプローチを変えることで、自分の持っている知識を深く広くしたり書くプロセスを経て表現する言葉を増やすことが出来るんですね。

システムエンジニアには読み手のいる書き物を出来る機会があって、その機会もシステムエンジニアとしての経験の多少に関係なくチャンスが回ってくると思うんですがどう思いますか。どっちかと言うと、手順書の類は、若手に回ってくることの方が多いのでは、と思うんですよ。これはチャンスですね、若者には。

「テキスト」と言う時点で、受講者がいて、その受講者が受講する目的である知識や経験の習得の手助けをすることが、「テキスト」の存在価値となるわけです。

受講者に知ってもらうこと、つまり、知識は受講者が習得して使うようになると、テキストから学んだことが正の情報となります。いわゆる、ヒヨコに刷り込みするわけですね。なので、テキストを作成する側が思い込みや感情だけで表現するのは適切かどうか、そのテキストの主旨により違ってきます。

業務上の知識を学ぶ機会の提供であれば、テキストを執筆するライターは自分自身で書くコンテンツを調査して、整理することで裏付けを取ってから書くことが必要だと思うのです。当たり前だよ、なんて言われそうですが。

コンテンツの裏付けを取るということは、そのテキストを学び、外に出て使う受講者が少なくともテキストを起因とした間違った解釈や使い方をしないために行うことなのだと思います。恥をかかせないため、というか。

そのコンテンツもテキストに編成する際には、章立てなどを含めてライター側の主観や好みのバイアスが入ります。これは執筆する側の創意工夫や主義主張を表す場ともいえます。だから、ただコンテンツを並べるのではなく、章立てに学んでほしいことを念頭にストーリーを組み立てる想像するスキルが求められると思うのです。

このプロセスがとてもいいんです。ワタシがテキストを書くとき、書きたいことを並べ、裏をとるという行為は、一見面倒に見えますが、ワタシ自身による知識の上書きをするんですね。これがとってもいい勉強になるんです。

そのつぎには、テキストの限られた紙面に収めなければならないので、エッセンスを抽出したり、言葉を選んだりするんですね。そうしたプロセスの中にいままで気づかなかったことや見落としていたことを知るきっかけとなるんです。

これって、知識の再投入による知識の拡大って感じですね。ここがいいんです。ここを通過するためにやるようなものです。テキストを作る作業の数%かもしれないんですけどね。その数%を得るために残りの90数%は自分の気持ちと根競べかもしれません。その根競べの中にもまた気づきや学びの要素を見つけることが醍醐味なんですけど。