SaaS企業1人目の日文テクニカルライターが1年半でやったこと

5.4K Views

February 16, 24

スライド概要

20240215_Technical Writing MeetUp Vol.30 登壇資料

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

SaaS企業1人目の 日文テクニカルライターが 1年半でやったこと 2023.02.15 primeNumber Inc. Shinya Sato

2.

AGENDA 01. セッションの概要 02. 自己紹介・会社概要 03. 1年半でやったこと 04. 今後の課題

3.

Session Outline And Target セッションの概要 誰に向けたセッションか。 3 ©primeNumber Inc.

4.

セッションの概要と対象 ―こんな方々に届くといいなァ ― テクニカルライターチームを作りたい人へ 受け入れ側 (エンジニア・PdM・CS)の方へ ● ヘルプドキュメントを充実させたい! テクニカルライター (とくに非IT系)の方へ ● でもどうやっていいか分からない! ● テクニカルライターを初めて採用する場合、 ターへの転職って実際どうなんだろう? ● どんな準備が必要なんだろう? ● どのくらいのタイムスケジュールで、 どういうことが達成されるのだろう? 4 SaaS(Webアプリケーション)のテクニカルライ ドメイン知識はどの程度必要なんだろう? そのキャッチアップは大変なのかな? ● 「1人目」だと、どういった苦労があったり、 日々どういう課題があるんだろう? ©primeNumber Inc.

5.

About Us 自己紹介・会社概要 5 1. 自己紹介 2. 会社概要とビジョン 3. プロダクト説明 ©primeNumber Inc.

6.

WHO AM I? Shinya Sato 株式会社primeNumber プロダクト開発本部 プロダクトマネジメントグループ テクニカルライティングチーム 6 1 ● 入社:2022/07 ● 作っていたもの:取扱説明書・カタログなど ● やってきたこと:日英ライティング・多言語展開など ● ITは(ほぼ)未経験 ©primeNumber Inc.

7.

COMPANY 会社概要 会社名 株式会社primeNumber 代表 代表取締役CEO 田邊 雄樹 創業 2015年11月 Office 東京都品川区上大崎3丁目1番1号 JR東急目黒ビル5F 7

8.

VISION あらゆるデータを、 ビジネスの力に変える。 primeNumberは、データテクノロジーカンパニー。 あらゆるデータが爆発的に増えていく時代に、 誰もがすばやく、簡単にデータを使える環境を構築し、 データ活⽀までのプロセスを最適化。 ⽀度なテクノロジーと独⽀のアイデアで、 世界中のビジネスを⽀援します。 8

9.

trocco®とは データ基盤の構築・運用を支援するSaaS 9 ©primeNumber Inc.

10.

trocco®導入企業例 様々な業種で導入されています! 10 ©primeNumber Inc.

11.

1年半でやったこと 3つの時系列に分けて紹介させてください。 11 1. 初期:入社直後〜3ヶ月 2. 中期:入社3ヶ月〜9ヶ月 3. 後期:入社9ヶ月〜18ヶ月 ©primeNumber Inc.

12.

辛い期 入社直後〜3ヶ月ごろ

13.

入社直後〜3ヶ月ごろ―心の声― ヤバい・・・なんもわからん・・・ 13 ©primeNumber Inc.

14.

入社直後〜3ヶ月ごろ―3大辛かったこと ― 仕様書がない ● 機能仕様が自然言語の形でまとまっていないことが多々ある ○ 必要に応じてコードを読みにいくことも 実機検証さえ難しい ● localhostってなんですか・・・Gitって?Dockerって・・・??? ○ このレベルだと、local環境を立ち上げることさえままならない ○ このあたりは気合で覚えるしかない 同僚からの認知が得にくい 14 ● エンジニアメンバーからすると、何をやる人かわかりにくい(かもしれない) ● UX/UIライターやコンテンツライターとしての期待値がある(かもしれない) ○ 使用説明の執筆と、画面UIの設計や訴求文の執筆に必要なスキルセットは異なる ○ どういうことが得意な人物かを認知してもらうことが大事 ©primeNumber Inc.

15.

入社直後〜3ヶ月ごろ―やったこと0― 各種勉強 データエンジニアリングに関する知識 クラウド(AWSやGCP)に関する知識 SQLの知識 APIの知識 開発環境やLinuxの知識 Railsの知識 ・・・ とにかく勉強の日々 15 ©primeNumber Inc.

16.

入社直後〜3ヶ月ごろ―やったこと1― 重要機能のヘルプドキュメントの 執筆 2大有償オプション機能である 「データカタログ」「チーム機能」 のヘルプドキュメントを、ゼロから執筆。 いずれも仕様的にも難解で、非常に苦労した。 【良かったこと】 ただ、このタスクのおかげで 「どういうことを得意とする人物」かを、 周りのメンバーに認知してもらえた。 (気がする) 16 ©primeNumber Inc.

17.

入社直後〜3ヶ月ごろ―やったこと2― リリースノートの執筆 週次・月次リリースノートの執筆を引き継ぐ。 ほぼ毎日デプロイがあるため、大変。 【良かったこと】 毎日リリースされる機能を自分で触ってみることで、 プロダクト理解が深まる。 【難しいこと】 新しい機能を使ってみたいと思わせる訴求的な文章は、 一般的なテクニカルライターは苦手としているかも。 (個人の感想です) 17 ©primeNumber Inc.

18.

入社直後〜3ヶ月ごろ―教訓― 今にして思えばの話 受け入れ側 (エンジニア・PdM・CS)の方へ ● Issue/PRはテンプレート化し、 テクニカルライター (とくに非IT系)の方へ ● なるべく仕様情報の集約させる ● まずはリリースノートの執筆を振ってみる ● 誰がどの機能に詳しいかを教えてあげる(大事) 執筆のために必要な情報が得やすい環境かは 事前に確認すると良さそう ○ 情報が得にくい環境の場合は 相当の覚悟が必要かもしれない... ● 何を任せられる人間なのかを 周りに認知してもらうことが大事 ● リリースノートを書くと 自然とプロダクトのキャッチアップが進む 18 ©primeNumber Inc.

19.

ようやくスタート期 入社後3ヶ月〜9ヶ月ごろ

20.

入社直後から感じていた課題 前置き:以下は入社以前に当然想定していたことなので辛くはない 文体揺れ・表記揺れが多い ● それまで色々な人(エンジニア・PdM・CS)が書いていたので、 ドキュメント全体を通じたConsistencyに欠けている ドキュメントの制作フローが決まってない ● 専属の担当がいなかったので、これも致し方ない ドキュメントが更新されていない 20 ● 基本的に最新仕様に追従されていない ● 制作フローが決まってなければ当然こうなるので、致し方ない ©primeNumber Inc.

21.

入社後3ヶ月〜9ヶ月ごろ―やったこと1― 制作プロセスの言語化 ライターチームの業務スコープとタスクの依存関係を 明確化しつつ、各タスクでやることを言語化。 タスクの依頼はGitHubProject上で管理し、 執筆が必要になったらIssueを作成してもらうように。 レビュワーにはエンジニア(またはPdM)と カスタマーサクセスの2名をアサインするルールを設定。 【良かったこと】 ● 手戻りが少なくなった ● ドキュメントの更新漏れが(ほぼ)なくなった ● 仕様的正しさとユーザビリティの両面から 品質を担保する仕組みが整った 21 ©primeNumber Inc.

22.

入社後3ヶ月〜9ヶ月ごろ―やったこと2― ドキュメントのGit管理移行& 自動デプロイの構築 CMSに埋まっていたドキュメントを一括抽出して、 Gitリポジトリによる管理に移行。 加えて、CMS側のAPIとGitHubActionsを活用することで、 releaseブランチにPull Requestがマージされたら CMS側に自動デプロイされるように。 【良かったこと】 ● 22 統合開発環境上での執筆が可能になった ○ 記事間をまたぐ編集が容易に ○ textlintやtyposも使えるように ● レビューもGitHubで完結するように ● 温かみのある記事公開(手オペ)が不要となった ©primeNumber Inc.

23.

入社後3ヶ月〜9ヶ月ごろ―やったこと3― チュートリアルの充実 2023年02月にフリープランが追加。 これまでのユーザーペルソナ(データエンジニア)とは 異なる流入が見込まれたため、 わかりやすさを最重要視する形でチュートリアル コンテンツを刷新。 【良かったこと】 ● 非データエンジニアのユーザーにも、 最低限trocco®を体験してもらうための 下地を整えることができた 23 ©primeNumber Inc.

24.

閑話休題―テクニカルライターと他ロールの親和性 ― 仕様理解が深まってくると いろんなことに首を突っ込みたくなる... QAとの親和性 PdMとの親和性 IAとの親和性 執筆時の調査や検証は プロダクトをくまなく触ることで、 テクニカルライターは一般的に、 事実上のQAテストになりがち。 仕様間の依存関係などは、一番詳し ある情報の構造(粒度・順序・集合 たまに動作確認チェックシートを くなるかも。 関係など)を正しく捉えることにこ 作ったりもする。 そのうち仕様策定にも絡み始める。 だわりがあるのでは。 すると、画面仕様も作り始める。 いろんな仕事に携われるのはいいこと! 24 ©primeNumber Inc.

25.

入社後3ヶ月〜9ヶ月ごろ―反省― ただし タスクを持ちすぎるのも良くない 25 ©primeNumber Inc.

26.

入社後3ヶ月〜9ヶ月ごろ―教訓― 今にして思えばの話 ● 採用は早めに動いた方がいい ● チームとしてのパフォーマンスをスケールさせる 仕組みを整えた方がいい ○ job descriptionの策定 ○ オンボーディング準備 ○ 制作ガイドラインの策定などによる ドキュメント品質の均質化 ● 26 その上で適切に権限委譲を進めた方がいい ©primeNumber Inc.

27.

ローカライズどうにかする期 入社後9ヶ月〜18ヶ月ごろ

28.

入社後9ヶ月〜18ヶ月ごろ―課題― 海外展開本格化 28 ©primeNumber Inc.

29.

入社後9ヶ月〜18ヶ月ごろ―課題― 29 ©primeNumber Inc.

30.

入社後9ヶ月〜18ヶ月ごろ―課題― でも… ローカライゼーションに 携わったことのある人がいない 30 ©primeNumber Inc.

31.

入社後9ヶ月〜18ヶ月ごろ―やったこと1― 機械翻訳PRの自動生成 i18n対応されたソースコードにおいて、ja.ymlの変更箇所を 機械翻訳し、自動でPull Requestを生成するように。 【良かったこと】 ● 最低限、他ロケールで日本語が表示される といった事象は解消できた 31 ©primeNumber Inc.

32.

入社後9ヶ月〜18ヶ月ごろ―やってること2― TMSの導入(未完) (以下は未完です) Glossary・Translation Memoryベースでの機械翻訳により、 最小工数で当たり前品質を満たすローカライゼーション プロセスを検討中。 Gitリポジトリのreleaseブランチの差分を自動検知し、 PhraseTMSにて機械翻訳(追っかけで人手翻訳)を行い、 自動的にPull Requestを作ってマージする一連のプロセスを 自動化したい。 ただし、諸々技術的制約が多く、進んでいない。 なお、部分的にPhraseTMSを活用した、ヘルプドキュメン トの多言語化対応は2024年03月にリリース予定。 32 ©primeNumber Inc.

33.

Future 今後の課題 「低い学習コスト」を支える 33 ©primeNumber Inc.

34.

trocco®のプロダクトビジョン 34 ©primeNumber Inc.

35.

今後の課題1―ユーザー目線に基づく改善 ― ユーザーからのフィードバックを取り入れる ● 現在は、CSからのフィードバックを又聞きしている状態 ○ ユーザーの課題を直接的に拾い上げて改善させる仕組みを構築したい ユーザーの閲覧状況を分析する ● ドキュメントページのアクセスログを分析することで、改善に役立てられないか? ○ どの機能で詰まっているのか、どのドキュメントがわかりにくいと感じているのかを可視化したい アクセシビリティを改善する ● ドキュメントが肥大化し、知りたい情報にアクセスしにくい状態になっている ○ ● ■ フロントエンドから呼び出しやすいようにドキュメントを構造化させる? ■ その場合、UI側とドキュメント側で掲載する情報の定義が必要? そもそもプロダクトの全機能を使うユーザーはまれ ○ 35 プロダクト上にドキュメントを出すことで導線を簡略化させる? トピックライティング的な思想で、ユーザーごとにカスタマイズしたドキュメントを作り出せないか? ©primeNumber Inc.

36.

今後の課題2―ローカライゼーション ― どの言語でも使いやすいプロダクトへ UI・ドキュメントともに、当たり前品質を満たすことを目指す。 36 ● 可能な限り人の手を介さず ● 均質的かつ当たり前品質を満たす形で ● 日本語の変更追加削除が発生した同日中に、日本語以外の言語に同期してデプロイする ©primeNumber Inc.

37.

今後の課題3―採用・チームビルディング ― プロフェッショナル集団の形成 ● テクニカルライティングをコアのスキルセットに据えつつ、それぞれが専門性を持った集団へ ○ ドメイン知識(データエンジニアリング・SaaS) ○ ローカライゼーション ○ アクセシビリティ ○ 自然言語処理・AI ドキュメント品質の均質化 37 ● textlintやPrettierの設定ファイルをカスタマイズし、実用に耐えるものに ● ドキュメントテンプレートを作成し、アウトプットを規格化 ● テクニカルライター以外でもドキュメントが書ける環境へ ©primeNumber Inc.

38.

ご清聴ありがとうございました 38 ©primeNumber Inc.

39.

プロダクト開発本部 体制図 職能別内訳 ● ソフトウェアエンジニア: 社員12名、業務委託数名 ● SRE: 社員2名、業務委託数名 ● PdM: 社員3名 ● デザイナー: 社員1名、業務委託数名 ● テクニカルライター: 社員2名 チーム構成 ○ プロダクト開発 ■ コネクター開発チーム: データ連携のコネクターの開発 ■ コア機能開発チーム: データマネージメント全般の大規模機能開発 (ワークフロー機能、dbt連携、データマート、Git連携) ■ 遊撃チーム: 顧客要望開発、技術改善、セキュリティ系対応、CS向け改善、落ち葉拾い ■ イネーブリングチーム: 技術負債の解消、中長期のアーキテクチャ選定 39 ○ SRE: 素早く安全な基盤の構築 ○ デザイン: デザインを通したUX向上、プロトタイピングでの価値検証など ○ テクニカルライター: ヘルプドキュメントやUI文言を通したUX向上 ○ QA ©primeNumber Inc.

40.

時間が余ったとき用 ―雑談テーマ― ● 生成AIの話 ○ PRからドキュメントを自動生成するプロンプトを試しているものの 渡すべき情報が多すぎて難しい ● ○ まともにすべての情報を渡しているとトークンが枯渇してしまう ○ コンフィデンシャルを渡さないような工夫も必要そう 採用の話 ○ エンジニアリングとライティングの両方のスキルセットを持つ人材を見つけるのは難しい ○ 少なくともそういったスキルセットを持つ人材に訴求できる何かは必要 ■ ● ドキュメント駆動開発の夢 ○ 40 テクニカルライターを介した、中長期的なスキルセットを示す? ドキュメントを先に書いて、それを元に実装できたら早いのではないか ■ でも難しそう ■ 要件は後で変わるし、詳細仕様は既存コードを見ないことには定まらないため ©primeNumber Inc.