nwc technical writing 2023
#nwc_technical_writing
mochikoAsTech(セッションオーナー)
テクニカルライター
keroyama
UXライター
hebiko
UXライター、テクニカルライター
yazakimakoto
テクニカルライター
テクニカルライター:製品の説明、プロダクトのUIテキスト
UXライターとは何が違うか
専門的な知識を持ってない人に説明する仕事はテクニカルライター
非専門的な人向けに書く
UXライターはUXの文脈
ユーザーにとって魅力的なことを書く
画面上でしか見えないものをユーザーに伝えていく
各社違うものをテクニカルライター、UXライターと呼んでいる
APIライターというのも海外にはある
テクニカルライター、正規のルートはない説
当時のテクニカルライター
マニュアル制作系
家電の説明書を書いたりしていた
ソフトウェアの仕事をしたかった
IT系のに徐々に移動してやっていった
メーカーからのテクニカルライター
複合機、プロ仕様の印刷機
IT系に踏み込んできたきっかけは?
Webマニュアルをやりたかった
紙は差分管理が大変だった
Gitという素晴らしいものがあるのを知った
受託だったのでハード、ソフトいろいろある
UXデザインを知って興味が湧く
受託でやるのは厳しい、自社だといいな
すごいわかりにくいものをわかりやすくする
元のプロダクトをよくしたらいいんじゃないかなと思うように
開発との距離感はどう?
近いには近いんだけど
うまく混ざれてない
参加するにも後半になっている
はじめから呼んでくれないか
まだ工程の中にテクニカルライティングが頭に入ってない
こんな問題を解決してるんだよね、から入りたい
エンドユーザー向けと社内向け(Web APIのドキュメント)をやっている
製品による
どうしても後工程になっていた
アジャイルを取り入れてるのでリファインメントに参加
POの提案でどういう仕様にするかみたいなフィードバックを得る
本当は早めに情報が知りたい
新しいJSONのキー名どうですか?というのを聞いてきてくれた
ライターがいっぱい集まって提案してくれた
文言相談系のSlackワークフローがある
頼む側の困ってること
何を渡したら書いてくれるのか
何も書かないのもつらい
書かれすぎても申し訳ない
雑に声かけてくれ
ヘルプページを書く時にテンプレートを教えてあげた
テクニカルライターがやっているから合ってるんでしょ的な雰囲気
Webは変更が効くけど
紙などのことは変更が効かない
伝えたいことのフィードバック、POの考えていることを汲む
それはテクニカルライターの仕事じゃないやつ
広告宣伝は違う
マーケティングが明確に別れていると依頼が来ない
丁重におことわりする
15文字を70文字になると言ったりしている
職責がしっかりしている
新しくプロパティが増えたことに対して何が嬉しいのかは汲んで書きたい
APIドキュメント
新しいのが出た時にAPIはどうやって使うんですか?ってなる
どうやって伝えるのがいいのかわかりづらい
迷うならリファレンスにすべて書くでいいんじゃない?
迷ってもあまり意味がない
ユーザーに向けて書いてない
自分宛てのメモ
人に聞かれたら自分で答えられるように書く
POに納得するように書いている
ドキュメントどこに置くのか問題
人数多いとこまっちゃうね
どれくらいテクニカルライターいる?
製品ごとに3人くらい居る
それぞれ作業分担してる
できるだけ近いドメインで皆で広くみていこうとなってる
周辺知識、業界知識がないと仕様の情報がわからん
表面だけで書けてしまうのはよくないのでドメインエキスパートに聞いてる・資格試験とかした
そうすると見えてくるものが変わってくる
直したら良いことへの心当たりがでてくる
知らないことを聞くことができるのが良い
エンジニアにすぐ聞く
ライティングに必要な知識
ブラウザの仕組みとかは自分で勉強する
製品特有の知識
エンジニアに聞くのが楽しい(ノリノリ)
「ライターはジャーナリストたれ」
Amazon | The Product is Docs: Writing technical documentation in a product development group | Gales, Christopher, Splunk Documentation Team | Technical
テクニカルライター嬉しいはずだけどなんで募集がないのだろう
雇う金がない(ドキュメント書くため)
社外向けならわからなくはないが、それを数値化するのが難しい
日本語だったら書けると思っている
国際展開する場合には日本語が元になるのでそこが整備されててほしい
サポートチームが隙間で書いてたのをドキュメント書き直していった
「問い合わせが難しくなった」
簡単なものより難しい話になっている
大変だけどちゃんと使ってくれたので嬉しいことです
ドキュメントを残さない派閥もいると困る
外に見せるもんじゃないし動いてるのでいいじゃん
ドキュメントと実際の挙動のどっちが正しいんや
違うとコミュニケーションができる
何が正しいのかを議論できるからドキュメントはあるべき
サポートにくる質問をドキュメントに書いてという依頼がどれぐらいくるか
削除したら確認するだけで完全に削除してしまうことで取り返しがつかなかった
これはよくないので文言を変えてあげる
ドキュメントを最初から最後まで呼んで違和感があったのをリストに上げてくれる
なんでそれやったの?
ドキュメントって大事じゃん
でもちゃんと呼んでないよねという提言
なので読み合わせした
代わりにIssueはめっちゃ溜まった
ヘルプに送られたコメントを見てみる会
これは修正すべきかどうかを比較してプライオリティを決める
これはヘルプページじゃなくてプロダクトにフィードバックすべきでは?
ドキュメントに関心を持ってほしい
ドキュメントの話が出てくると拾いに行く
260〜330くらいある
スプリントでは必要なものを30だけ取り組むようにやっていってる
のこりの300は見てない
間違ったことを書いてしまった場合
気づいたら治せばいいや精神
修正シール貼ってないからいいや
レビューしてもらって失敗の責任を分散させる
altの書き方は正解がわからない
図って自分でつくってる?
プロダクトの構造を伝えたいなって時がある
そういうときは画像が必要
テクニカルイラストレーターがいい感じで書いてくれる
Powerpointで書いてるのをスクリーンショットにしている
ボタンを囲む枠の色はどうする?
色覚特性の配慮で赤はよくない
危険を伝える色なのでこれでいいのか
注意書き増えがち問題
infoとwarningがいっぱいになる
増やしたら消せをやっている
お掃除職人
注意は乱発すると意味がなくなる
補足は最後に置く
免責みたいなヘルプを書きたくない
テクニカルライターが悩むのはよくない仕様なんだなっていうPMの気づき