ITエンジニアのための~ポイントをおさえたテクニカルライティング

10

Click here to load reader

Upload: hajime-fujita

Post on 01-Jul-2015

312 views

Category:

Technology


1 download

DESCRIPTION

優れたテクニカル資料は、優れた技術(テクニック)の母です。 「テクニカル資料を書く」というプロセスは、いわゆる「PDCAサイクル」における「C(点検・評価・振り返り)」に相当するものですから、「いまの方向性で開発の最終目的は達成されるか」を開発の過程で随時チェックでき、長期的な視点に立って軌道修正を図るきっかけを得ることができるためです。 このスライドでは、ポイントを明確にしたテクニカル資料を書いて優れた技術を開発するためのハウツーを解説します。

TRANSCRIPT

Page 1: ITエンジニアのための~ポイントをおさえたテクニカルライティング

ポイントを押さえたテクニカルライティング

藤田 肇

ITエンジニアのための

© 2014 Hajime Fujita

Page 2: ITエンジニアのための~ポイントをおさえたテクニカルライティング

自己紹介

• 藤田 肇(ふじたはじめ)

• 弁理士(登録番号:17653)• 吹奏楽オタク

機械学習分野のアカデミック研究者を志して博士課程に進学

弁理士になる「自分に研究者は向いていない」と悟る

特許明細書(テクニカル資料)の書き方をマスターする

かつて書いた論文・技術資料は「ダメ資料」だったことに気づく

テクニカルライティングに関するノウハウを持っていたら研究成果を上げることができたかもしれない… もう遅いけど

@fujitahajime

fujita.hajime

[email protected]

全然センスない…

http://fujitahajime.jp/

© 2014 Hajime Fujita

Page 3: ITエンジニアのための~ポイントをおさえたテクニカルライティング

テクニカル資料とは

技術の

何が新しいのか(オリジナリティ)

何がすばらしいのか(新しい価値)

を他人に説明するための資料を広く指す

テクニック

開発に携わっている本人が技術を一番よく分かっている はず…

ダメ資料

90%以上

一読しても意味不明な資料がほとんど

約10%

優れた資料テクニカル資料の現実

© 2014 Hajime Fujita

Page 4: ITエンジニアのための~ポイントをおさえたテクニカルライティング

テクニカル資料の重要性

優れたテクニカル資料は、優れた技術の母である

優れた技術を開発したから、優れたテクニカル資料を書けた

優れたテクニカル資料を書くことを意識して開発に取り組んだから、

優れた技術を開発できた

「テクニカル資料を書く」は、C(点検・評価)に相当するため

開発の方向性は正しいか?

最終目的は本当に達成できるか?

他にもっと良い方法はないか? etc...

テクニック

なぜなら

PDCAサイクル

© 2014 Hajime Fujita

Page 5: ITエンジニアのための~ポイントをおさえたテクニカルライティング

優れたテクニカル資料の2つの条件

従来技術

新しい技術

オリジナリティ

条件1

従来技術からの差分(オリジナリティ)

が明確であること~ができなかった

~ができるようになった

条件2

オリジナリティによって従来の課題が解決できる

(新しい価値を生む)ことが明確であること

© 2014 Hajime Fujita

Page 6: ITエンジニアのための~ポイントをおさえたテクニカルライティング

優れたテクニカル資料の具体例

従来技術(自転車)

新しい技術(ラジオ付き自転車)

ラジオを搭載した

ラジオを聴けなかった

ラジオを聴ける

差分(オリジナリティ)

課題解決(新しい価値)

<条件1>

<条件2> たったこれだけ!

© 2014 Hajime Fujita

Page 7: ITエンジニアのための~ポイントをおさえたテクニカルライティング

なぜ「ダメ資料」になってしまうのか?

IT分野のテクニカル資料は、ダメ資料になりやすい

物の構造に関する技術の場合

工夫が一目で分かる効果もわかりやすい

コンピュータを利用した技術の場合

ラジオ!

なんとなく処理を実行入力 出力

とりあえず、処理の内容を箇条書きにしてみるか…

意識しなくても2つの条件を満たしてそれなりの資料に

「なんとなく」、「とりあえず」でダメ資料のできあがり!!

© 2014 Hajime Fujita

Page 8: ITエンジニアのための~ポイントをおさえたテクニカルライティング

ダメ資料の4つの典型例

過大評価それのどこが新しいの?

内容発散結局なにが言いたいんだ

設計的仕様細かい話はもういい

単なる願望具体的な話を詰めろ

各パターンの比率は個人的感触です

いずれも<条件1>

and/or<条件2>を満たしていない

症状: 従来技術の一部を自分の手柄にしている原因: オリジナリティの認識不足

症状: 関係のないことまで書いている原因: オリジナリティにフォーカスできていない

症状: 自分のやったことを全部書いている原因: オリジナリティの位置づけの無理解

症状: あんなこといいな、できたらいいな原因: 研究開発の途上

© 2014 Hajime Fujita

Page 9: ITエンジニアのための~ポイントをおさえたテクニカルライティング

テクニカル資料の関係性マトリクス

① 従来技術 ② 未解決の問題

③ 新規技術 ④ 効果

乗ってる間はラジオが聴けない…

乗りながらラジオが聴ける!

差分(オリジナリティ)を明確にする

効果によって価値(問題解決)を生む

なぜ?(理由)放送受信の仕組みが無い

なぜ?(理由)放送受信の仕組みを搭載

ラジオ!

関係性マトリクスを意識すれば、条件1・2を満たしやすい

<条件1> <条件2>

© 2014 Hajime Fujita

Page 10: ITエンジニアのための~ポイントをおさえたテクニカルライティング

まとめ

ご意見・ご質問はお気軽にどうぞ

弁理士 藤田 肇

研究・開発を進める上で、技術の

何が新しいのか(オリジナリティ)

何がすばらしいのか(新しい価値)

を他人に説明するテクニカル資料は重要

テクニック

PDCAサイクル

関係性マトリクスを意識して、優れたテクニカル資料づくりを!

@fujitahajime

fujita.hajime

[email protected]

http://fujitahajime.jp/© 2014 Hajime Fujita

そして、優れた技術開発を!