【ITエンジニアのための書類の書き方】ドキュメントの中で溺れてませんか?

書類

ITエンジニアの仕事は、プログラムを書いたり、テストを行ったりするだけではありません。

様々なドキュメントを書く、という仕事があります。

ほとんどの時間をドキュメントを作成する、ということに充てていることと思います。

ITエンジニアがどういうドキュメントを書くのか、どうやって書くのか、何を書くのか、

についてまとめてみました。

最低限の国語の知識

まずは、主語を書きましょう、などの最低限の知識です。

ITエンジニアになりたての方の多くは文章を書くのが不得意です。

あまり作文技術を学校で習っていないということもあるでしょう。

まずは下記で最低限のご作法を身につけてください。

>>> 【ITのドキュメントを書くための国語の知識】最低限の3つの作法

Wordのエキスパートになる

ITエンジニアは様々なドキュメントをWordで作成します。

Wordのエキスパートになっておくのは必須事項と思います。

>>> 【エンジニアのためのWord再入門講座】ITエンジニアの必読書

書類の見た目をよくする

書類の見た目は大事です。特に日本では絵をかけと言う人が多いので、分かりやすい絵をかける能力は重要です。

>>> ノンデザイナーズ・デザインブック 読みやすい、伝わる、分かりやすいデザインとレイアウト

要件トレーサビリティマトリクス

要件トレーサビリティマトリクス、名前が長いですが役に立ちます。

>>> 役に立たなさそうで役に立つ「要件トレーサビリティマトリクス」

仕様書に書くべきこと

仕様書で最も書かなければならないのは、ミッションステートメントと言えるような仕様です。

>>> ITエンジニアが仕様書に最も書かなければならない1つのこと

>>> 外部仕様書(製品仕様書、基本仕様書)の書き方 ミッションを中心に据えて [bogcard url=”https://it-engineer-business.tech/ex-spec-mission/”]

外部仕様書、内部仕様書に書いておくべきを把握しておきます。

>>> 【外部仕様書(製品仕様書、基本仕様書)で書くべきこと】

>>> 【内部仕様書(機能仕様書、詳細仕様書)で書くべきこと】

図をかくときは、UMLを使った方が良いと思います。UMLを覚えましょう。

>>> 【ITのお絵描きルールUML】UMLを使わない頑ななおじさんたち

完了報告書の書き方

工程が終わったときに「無事に終わりました」と報告する書類の書き方を説明します。

作文する技術というか、こういうことを書くというのを頭に入れておかないと、いつまでたっても質の良い完了報告書を書くことができません。

>>> 【完了報告書の書き方】工程完了報告書、テスト完了報告書、品質見解書

事故報告書

製品に不良はつきものです。エンジニアをやっていれば必ず社外で不良が発覚します。

そのときの報告書を書かなければなりません。

>>> 【ITエンジニアの事故報告書の書き方】ごめんなさいだけでは納得してもらえません

特許の書き方

忙しいのに「特許を書け」と言われて困っていませんか?

特許はハードのエンジニアだけのものではありません。

なぜか工程を進めている間に書けと言われる特許、そんな時間は確保されていないのに書かなければいけないのが、特許です。

うまくやれば将来のお小遣いになるので、短時間で書きあげましょう。

特許の書き方を紹介します。

>>> 【ITエンジニアのための特許入門】今日残業しないために

書類つくりのためのマインドマップ

上記の書類を作成するためにマインドマップを用いるというのが有用です。

>>> ITエンジニアの普段の業務の中のマインドマップ

まとめ

ドキュメントの書き方をまとめました。

少しでもドキュメントを作成するコツがあったとしたら幸いです。

コメント

スポンサーリンク
スポンサーリンク
スポンサーリンク
スポンサーリンク
スポンサーリンク
タイトルとURLをコピーしました