文書

データシートとアプリケーションノートの違い(初心者向け)

CPUなどの資料を取りにメーカーのサイトに行くと、文書がたくさん並んでいます。

・データシート

・エラッタ

・アプリケーションノート

・ユーザーガイド

etc

 

一体何が違うんだ、どれを見ればいいんだ、となると思うので、ざっくり説明したいと思います。

 

データシート

対象:ハードウェア開発者

データシートは基本となる文書ですが、そのデバイスの全容を網羅的に書いています。

・電気的特性

・中身の構成

・ピンの並び順

etc

一部ソフトウェア開発者が見る部分がないこともないですが、ほとんどハードウェア的なことを書いてあります。

これを読むことで、ハードウェアの概要がわかります。

 

 

エラッタ

対象:ハードウェア開発者&ソフトウェア開発者

半導体製品にもソフトウェアと同じようにバグが有ります。

そのバグを説明する資料です。

 

 

アプリケーションノート

対象:ハードウェア開発者&ソフトウェア開発者

データシートは淡々と特性や中身の説明している文書ですが、

「私はこのCPUを使ってUSB通信をしたいのですが実際にどうやればいいんでしょう」

みたいなことには答えてくれません。

そこで「こういう機能はこうやって使ってね」「こういう設計するといいよ」みたいな手引書がアプリケーションノートです。

自分が実現したい構成に近いアプリケーションノートがあればラッキーです。

アプリケーションノートは、ソフトウェアとハードウェアの両方について書いて有ることが多いです。

役に立つアプリケーションノートがない場合、手引無しで作ることになるので苦労します。

 

ユーザーガイド

対象:ソフトウェア開発者

アプリケーションノートは機能別に手引をしてくれますが、ユーザーガイドはさらに噛み砕いた文書です。

「開発環境のインストール方法」「デモボードの使い方」みたいなことを説明しています。

極端な話、ユーザーガイドで書かれていることは専門家でもなくてもできます。

(手順通りにやればいいだけで、ほとんど知識がいらないので)

 

 

と、こんな位置づけになっています。

 

デバイスを選定するときには、データシートで判断して選んで、

実際に回路設計するときはアプリケーションノートとデータシートを交互に見て、

基板ができてソフトウェア開発するときには、ソフトウェア開発者がユーザーガイドを見ながら開発環境をセットアップする……というような流れです。

 

以上、小田切でした。

紙の上で考え、画面の上で作れ!

今日もまたライフハックと言うかTIPS的な事。

でも、地味なようですごく重要な考えです。

これがないと自分の仕事の効率がガタ落ちです。

 

やり方は簡単。

じっくり考えないけないといけないことや、チェックのときは全て印刷しろということです。

頭をフル回転する時にあれこれファイルを開いたりスクロールしていると、実は相当脳みそのパワーを無駄にしています。

一度全部紙に印刷して机の上いっぱいに広げましょう。

そうするとこれがやりやすいのなんの!!(検索が早い。全部がまとめて頭に入ってくる)

心理的疲労が少なく作業が進みます。

画面でPDFを見ているのと違って、資料全てに0.5秒で文字を書けるので滅茶苦茶作業が早いです。(チェックポイントの発見&マーク付が早い)

 

それから、理屈で説明できませんが、なぜか画面を見ているときより紙を見ているときのほうが脳みそが回転します。

紙上でいろいろチェックすることになれると、画面上でチェックしているときにすごいストレスを感じます。

 

ただし、紙上で文章を書く作業をしてはいけません。

「ここにこの回路を置く」とか「ここにこの章を置く」みたいな大まかな作業や、誤字のチェックはOKですが、

紙の上で長文を書き出すと駄目です。

ペンで文字を書くよりキーボードで書いたほうが早いですし、修正も楽です。

 

ということで、紙と画面を使い分けてサクサク仕事を終わらせましょう。

 

以上、小田切でした。

 

 

 

 

 

仕事やいろいろなことを通して、達して考えです。

文書を書く時に「誰に向けて書くのか」に気をつけよう

テンプレートがあってそれを埋めるだけなら簡単ですが、設計書など自分で自由テキストをたくさんかかないといけないことは結構あると思います。

そんなときに、「何を書けば良いのか」と固まってしまう人が結構居ます。

 

頭のなかにはいろいろな情報がこんがらかって詰まっています。

でもそれをどうやって整理すればいい?

どうやって表現すればいい?

どこまで書けばいい?

コレがわからなくて固まるのです。

 

ポイントは「誰に向けて書くか」ということです。

その製品について詳しい人にむけて書くのか、それとも何も知らない人に向けて書くのか。

これを決めると道筋がすっとあきらかになります。

 

例えば設計書では、

「その製品について知らないけれども、電気の基礎知識程度はわかる人」

を想定して書きます。

 

→どこまで書けばいい?

・その製品がどういうものか説明する必要があります

・電気の基礎知識まで書く必要はありません

・どの部品を使うのかといったことや、その部品がどういうものかを説明する必要があります

 

→どうやって表現すればいい?

・電気の基礎知識がある人なので、電圧や電流をそのまま書けばいいです。

 

→どうやって整理すればいい?

「電気の基礎知識がある人にどうやって説明すればいいか?」と考えて、試しに口でエア説明してみます。

馬鹿らしく見えるかもしれないけど、実は有効だと最近気が付きした。

すると、こうなります。

・製品の概要説明

・その実現方法

・難しい点や問題点

・その対応として取った手段

・製品の基本的仕様

・実際に使用している部品

・その部品の仕様

こんな感じに口で説明する順番で並べていくとわかりやすい文書になります。

 

以上、小田切でした。

書類の用語の統一について

回路設計から離れますが、実際の業務で超大事な文書について少し。

 

設計書でも仕様書でもなんでも、とにかくいろいろな用語が出てきます。

 

製品名

例えば製品名Aがあって、それが後で改名されてA’になったとします。

その時、書類の中にAとA’が混在すると、後の時代の人は最終的なA’という名前しか知らないので、「Aってなに?」となるわけです。

へたすれば「A仕様書」なんて書類があっても「関係ない製品の書類だな」と無視されてしまうことだってあるわけです。

ですから、プロジェクトが終了する時に、古い名前は全部新しい名前に改名してから終了しないといけません。

 

類義語

ハードウェアで上手い例が出ないので、ソフト的な例を出しますが、何かの発送管理のシステムが合ったとします。

そのなかである部分では「送り主」と書かれていて、ある部分では「贈り主」と書いてあるとします。

これ、同じものを指しているかそうでないかわかりますか?

分かるわけがありません。

システムを作った人が意図して違う名前にしたのか、それともただの変換ミスなのかわかりません。

こういうものはいらぬ誤解を生みます。

実際、人間は意識せずに類義語を使っているので、こういう事例は多いです。

面倒ですが、類義語は直して一つの言葉に統一していく必要があります。

 

以上、小田切でした。