Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
ユーザーとの協調を重視する時代における ドキュメント制作現場の取り組み 情報処理学会 ドキュメントコミュニケーション研究会 2019, 12月 仲田尚央(Naohiro Nakata) Cybozu 1
Slide 2
Slide 2 text
自己紹介 テクニカルライター、UXライター、Webディレクター ⚫ 所属 ⚫ テクニカルコミュニケーションチーム ⚫ 翻訳チーム ⚫ 主な仕事: ⚫ プロダクトのUIメッセージのライティング ⚫ マニュアル・ヘルプなどのライティング ⚫ コンテンツの多言語化 仲田 尚央 なかた なおひろ @naoh_nak
Slide 3
Slide 3 text
アジャイル開発において 製品マニュアルが持つ役割 の話をします 3
Slide 4
Slide 4 text
チームワークあふれる社会を作る
Slide 5
Slide 5 text
グループウェアの開発・販売、 チームワーク研修など 5 中小企業グループウェア 業務アプリ作成プラットフォーム 大企業向けグループウェア メール共有システム 60,000社以上 10,000社以上 5,000社以上 7,500社以上
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
話の流れ ⚫ アジャイル開発とは ⚫ アジャイル開発に対応していくために、ライティングチームがしたこと ⚫ アジャイル開発におけるマニュアルの役割 8
Slide 9
Slide 9 text
プロダクト開発プロセスの変化 9 ウォーターフォールからアジャイルへ
Slide 10
Slide 10 text
実装 設計 計画 テスト リリース ウォーターフォール開発 アジャイル開発 テスト リリース 計画 設計 実装 イテレーション 1 テスト リリース 計画 設計 実装 テスト リリース 計画 設計 実装 イテレーション 2 イテレーション 3
Slide 11
Slide 11 text
実装 設計 計画 テスト リリース ウォーターフォール開発 アジャイル開発 テスト リリース 計画 設計 実装 イテレーション 1 テスト リリース 計画 設計 実装 テスト リリース 計画 設計 実装 イテレーション 2 イテレーション 3 小さなリリースサイクルを繰り返す フィードバックを得ながら、仕様や開発計画を見直していく
Slide 12
Slide 12 text
特徴 12 ⚫ウォーターフォール開発 最初に開発計画と仕様を しっかり固めて、計画通りに 進める ⚫アジャイル開発 事業の状況や関係者からの フィードバックに応じて、計画や 仕様を柔軟に変える
Slide 13
Slide 13 text
アジャイル開発が導入されると... 13 第1週 第2週 第3週 第4週 ・・・ 要件A 要件B 要件C 要件D 開発中止 開発期間延長 開発期間短縮 要件変更 開発計画の変更に柔軟に対応する マニュアル制作が必要
Slide 14
Slide 14 text
以前のやりかた WYSIWYGなCMSによるマニュアル制作 14 書きやすいけれど、何のために どこをどう変えたのかわからない...
Slide 15
Slide 15 text
以前のやりかた ページをPDF化して、変更点や変更理由をコメント 15
Slide 16
Slide 16 text
アジャイル開発に対応していくために 16
Slide 17
Slide 17 text
ライターを開発チームと一体に 17 プロダクトA 開発チーム プロダクトB 開発チーム プロダクトC 開発チーム ライター 開発 (PG) 品質保証 (テスター) PM & デザイン ライティング & 翻訳 ⚫ 職能別の組織を廃止 ⚫ プロダクトごとの開発チームにライターが直属 ⚫ 開発チーム内のコミュニケーションを取りやすい体制に
Slide 18
Slide 18 text
マニュアルドキュメントをバージョン管理する 18 要件Aを反映したバージョン ページ構成を改善したバージョン 要件Bを反映したバージョン 要件Cを反映したバージョン 開発計画の変更に対応して いくために ドキュメントのバージョン管理が 必要
Slide 19
Slide 19 text
バージョン管理システム ⚫ ファイルの変更履歴を記録 ⚫ いつ、誰が、どのような目的で、どのように作成/ 変更/削除したかを記録 ⚫ 複数のファイルにまたがる編集をまとめて記録 ⚫ 履歴からファイルを過去の時点に戻すことも可 ⚫ 複数人が同じファイルを同時に編集してしまっ た場合の競合を解決する仕組みも 19 ①最新のデータを 取り込み ③変更を反映 ②編集 ④変更を 取り込み
Slide 20
Slide 20 text
バージョン管理システム ⚫ 履歴を分岐して管理できる ⚫ 分岐した各枝を「ブランチ」と呼ぶ ⚫ 分岐したブランチは他のブランチの 影響を受けない ⚫ 複数の変更を並行して進められる ⚫ 他の人による変更を気にせずに変更できる ⚫ ブランチ同士を合流(マージ)させ、 変更を他のブランチに反映することもできる 20 変更 変更 変更 変更 公開版の 履歴 要件Aを反映 する履歴 ページ構成変更 の履歴 マージ
Slide 21
Slide 21 text
ドキュメントのブランチ管理 21 公開用ブランチ 要件Aリリース 要件Aを反映するブランチ 要件Bを反映するブランチ 要件Cを反映するブランチ リリースされない機能の ブランチは破棄 要件Bリリース 要件リリースに 合わせてマージ
Slide 22
Slide 22 text
ドキュメントをバージョン管理システムで管理しやすくするために ⚫ ドキュメントをテキスト形式で作る ⚫ 軽量マークアップ言語で記述 ⚫ 記述の容易さと可読性を両立 ⚫ HTMLやXMLの可読性の低さを補う目的で作られる ⚫ 記述フォーマットの例: ⚫ Markdown(サイボウズで利用) ⚫ AsciiDoc ⚫ ReStructuredText ⚫ tx2x 22
Slide 23
Slide 23 text
Markdownとは マークアップ言語のひとつ シンプルな記法で構造化された 文書を制作できる 23 # Markdownとは? Markdownは、マークアップ言語のひとつです。シンプルな記法で 構造化された文書を手軽に制作できます。 ## Markdownで文書を作るメリット * シンプルな記法で「覚えやすい」 「書きやすい」 「読みやすい」 * ツールを選びません。テキストエディタがあれば書けます * HTMLやPDFなど各種フォーマットに変換できます ## Markdownで文書を作るには? 1. お手持ちのテキストエディタを開き、Markdown記法で内容 を書きます。 2. 「.md」の拡張子と付けてファイルを保存します。たったこれだけ
Slide 24
Slide 24 text
Markdownのメリット ⚫ シンプルな記法で「覚えやすい」 「書きやすい」 「読みやすい」 ⚫ 読みやすいため、Markdown形式のままでもレビューが容易 ⚫ ツールを選ばない。テキストエディタがあれば書ける ⚫ 普及している ⚫ 多くの人が記法に慣れている ⚫ HTMLやPDFなどへの変換ツールが豊富 ⚫ TradosやMemsourceなどのCATツール(翻訳支援ツール)が対応 ⚫ テキストファイルなのでGitなどでのバージョン管理が容易 ⚫ 文字の一括置換が容易 24
Slide 25
Slide 25 text
MarkdownからHTMLへの変換 Hugoを利用 ⚫ HTML変換が高速 数千ページのサイトも運用可能 ⚫ Markdownの拡張が可能 「注意」「ヒント」など多彩なスタイルを表現できる 25 https://www.staticgen.com/
Slide 26
Slide 26 text
制作システムの全体イメージ 26 GitHub 記事ファイル Memsource 翻訳メモリー 機械翻訳エンジン Circle CI Netlify ビルド ホスティング Markdown記法チェック ホスティング 文章チェック HTML化 md ①記事をPush ②チェック ②自動チェック ④翻訳元記事 を入力 学習 ⑤翻訳 ⑤翻訳 ⑥翻訳済み記事 を出力 ③&⑦ デプロイ md md md
Slide 27
Slide 27 text
マニュアル制作の流れ 27 ブランチ作成 原稿作成 GitHubに反映 Markdownで記事を作成 自動チェッカーがコメント ・ Markdownの記法をチェック ・ 文章表現の校正 要件Aを反映するための ブランチを作成
Slide 28
Slide 28 text
マニュアル制作の流れ 28 人間によるチェック 公開サイトに反映 要件Aのリリースに合わせて 公開サイトに反映 GitHub上で差分を見て 人間によるチェック
Slide 29
Slide 29 text
バージョン管理システム導入の効果 ⚫ 属人化が軽減されて、タスクを分担しやすくなった ⚫ 開発計画の変化に対応しやすくなった ⚫ 改善や修正が素早く進むようになった ⚫ 積極的に改善するようになった!手軽に編集できることは重要 29
Slide 30
Slide 30 text
アジャイル開発における マニュアルの役割 30
Slide 31
Slide 31 text
アジャイル開発の目的 31 ユーザー 開発チーム リリース フィードバック フィードバックを得ないと 短期開発を繰り返すだけになってしまう
Slide 32
Slide 32 text
アジャイル開発におけるマニュアルの役割 ユーザーの躓きポイントに先回りしてサポートしつつ ユーザーからフィードバックを得てプロダクトの改善に繋げていく 32
Slide 33
Slide 33 text
「うまくいかないとき」に備えたデザイン 33 ディフェンシブ・ウェブデザインの技術 (毎日コミュニケーションズ, 2005) あなたがどれだけ注意深くサイトをデザイン しようと、どれほど十分にテストしようと、 訪問者は必ず問題にぶちあたるものなのだ。
Slide 34
Slide 34 text
ユーザーの「躓きポイント」に先回りする 34
Slide 35
Slide 35 text
躓きポイントを知るために ⚫ ユーザー視点でプロダクトを見る ⚫ マニュアルを書いていると気付くことも多くある ⚫ ユーザビリティーテスト ⚫ 想像もつかないポイントでユーザーが躓くことも多くある ⚫ マニュアルで自己解決できるか確認するテストも ⚫ マニュアルのアクセスログ(後述) 35
Slide 36
Slide 36 text
フィードバックを得る場としてのマニュアル Webマニュアルの特長を活かす ⚫ 更新しやすい ⚫ データを得やすい ⚫ 困っているユーザーが集まる 36 36
Slide 37
Slide 37 text
マニュアルから得られるデータ ⚫ ページごとの閲覧数 どの機能の説明が多く参照されているか? ⚫ 検索キーワード ユーザーはどのようなことを疑問に思っているか? ⚫ アクセス元 プロダクトのどの画面からマニュアルを開いているか? ⚫ アンケート ユーザーはどのような不満/要望を持っているか? 37 マニュアルから得られるデータは プロダクト改善の貴重な根拠 になる
Slide 38
Slide 38 text
アンケートによるユーザーとのコミュニケーション 38 ユーザーが躓いた そのときに聞くことが重要
Slide 39
Slide 39 text
事例:ログインのトラブル ⚫ ログイン画面からマニュアルへの遷移 が多く見られる ⚫ ログインに関するお問い合わせは 少ない ⚫ 問い合わせまでするユーザーは想像 以上に少ない! ⚫ アンケートで原因を調査して改善に 繋げる 39
Slide 40
Slide 40 text
アジャイル開発において、マニュアルが持っていく役割 40 ユーザー 開発チーム リリース フィードバック 直感的でないUI、機能不足など ユーザーが躓くポイントをサポート アクセスログやアンケートデータ などからプロダクトの改善ポイ ントをフィードバック