プロダクト開発におけるテクニカルライターの活動の変化

Cybozu Advent Calendar 2021の12日目の記事です。

年末ということで最近の活動を振り返っていて、プロダクト開発の現場でのテクニカルライターの活動が、ここ数年で大きく変わったなぁと感じた。単純に言えば、面白くなってきている。もう少し具体的には、次のような変化があった。

• プロダクトマネージャー、デザイナー、エンジニアとの協働が増えた

• プロダクトの方針や重要課題をライターが意識するようになった

変化の背景としては、アジャイル/スクラム開発へのシフトが大きいだろうと考えている。

テクニカルライターに求められる仕事は企業/プロダクトによって違うので、話の前提としてサイボウズでの役割を書いておくと、どのプロダクトでも概ね次のような仕事だ。複数言語に対応しているプロダクトでは、下記のほかに、翻訳会社/翻訳者と協力して翻訳も担う。

• プロダクトのUI文言を決める

• プロダクトのドキュメント（ヘルプページ、リリースノートなど）を作る

以前は、いわゆる「ウォーターフォール」と呼ばれるプロセスに沿った開発をしていた。数ヶ月、あるいは1年という長いスパンで、

仕様決定 → デザイン決定 → 実装 → テスト → リリース

という流れを辿る。我々テクニカルライターが動くのは、このうち「実装」と「リリース」のフェーズだった。

「実装」フェーズで、UI文言を決める。それより前の工程で、プロダクトマネージャー、デザイナーやプログラマーによってUIに仮の文言が当てられる。文言を管理するデータベース上で、テクニカルライターはそれらが適当かどうかチェックする。文法に間違いがあれば直し、よりわかりやすい表現に書き換えたり、必要に応じて情報を足したり、除いたりする。

「リリース」のフェーズで、ヘルプページを制作/更新する。仕様書を読み込んだり、開発途中のプロダクトを触ったりして動作の詳細を把握し、ユーザーに伝えなければならない情報を洗い出す。得られた情報からヘルプページを作り、ライターチーム内のレビュー、QA（テスター）によるチェックを経て、プロダクトと一緒にリリースする。ヘルプページの制作/更新には時間がかかるので、実際には「リリース」のフェーズからではなく、「実装」のフェーズあたりから作業を始めることが多かったが、基本的にはヘルプページの仕事はプロダクトのリリース作業としての位置付けだった。

UI文言に関しての問題は、テクニカルライターとして手を加えられる範囲が低いことだった。前工程で当てられた仮の文言を多少手直しする程度で、それをまったく違う内容に書き換えたり、あるいはUIに新たな文言を書き加えたり、プロダクトの動作やインタラクションから変えなければならないような文言の変更だったりは難しかった。UIをわかりやすくするために、UIにメッセージだったりヘルプページへのリンクだったりを加えたいと思っても、それはできない。ウォーターフォール開発では、前工程に戻すような変更は基本的に許されない。

それが、開発手法がアジャイル/スクラムになったことを機に、テクニカルライターは開発工程の上流から入るようになってきた。プロダクトマネージャー、デザイナー、テクニカルライターが組んでプロダクトのバックログ（開発要求）を決めているチームもある。プロダクトの動作やインタラクションを、文言と合わせて考えられるようになった。

プロダクトとヘルプページの連携も取りやすくなった。プロダクトのUI文言を決めつつ、UI上では伝えきれない情報があれば、ツールチップやヘルプページへのリンクを入れておき、あとの工程でヘルプページを用意する。

ヘルプページのコンテンツも変わってきた。先に書いたとおり、以前は仕様書を読み込んだり、開発途中のプロダクトを触ってみたりして情報を得て、ヘルプページを書き起こしていた。今は、「ヘルプページはプロダクトの一部」と見なし、プロダクトが注力する目標に沿ってコンテンツを作っていくようになった。今は、オンボーディング（プロダクトの使い方に慣れてもらうための立ち上がり支援）や、特定の機能の活用度を増やすことが課題になっているので、その方針に沿って動画コンテンツなど拡充させている。これはウォーターフォール開発でもできるはずのことで、開発がアジャイル/スクラム化したこととは直接は無関係かもしれないが、開発チームのコミュニケーションが増えたことによる副次的な効果だと思う。

デメリットもある。スクラム開発では、基本的にテクニカルライターを含めた開発チームは一丸となって常に張り付いて動くので、情報の取得にかかる時間は明らかに増えている。コミュニケーションによる情報共有は、ドキュメントによるそれと比べて、効率面では悪い。開発チーム内で毎日行うデイリーミーティングなど、ミーティングが多く、複数のプロダクトの兼務は難しくなった。ウォーターフォール開発の頃は、プロダクトの開発プロセスの中でテクニカルライターが動く期間は一部に限られていたので、その期間を分散させることで、いくつものプロダクトを掛け持ちできていた。今はそれが難しい。
なので、以前と比べて必要な人数が増えている。ウォーターフォール開発と比べて、中長期的な業務量の見積もりも難しくなっている。マネージャーの立場としては、そのあたりは悩みどころ。

また、ヘルプページもプロダクトの一部とみなされるようになったことで、ヘルプページの制作に関する方針決定のためのステークホルダーが増えて、議論を難しくしているようにも感じている。責任の所在（テクニカルライターなのか、プロダクトマネージャーなのか）も曖昧になり、最終的な意思決定を誰がするのかが不明瞭になる。このあたりは、今後整理が必要と思っている。でも、議論がUXライター内に閉じるより良いと、前向きに受け止めている。（もしかしたら、テクニカルライターの経験を持った人がプロダクトマネージャーの中に必要なのかもしれない。そういえば、freeeさんがプロダクトマネージャーの枠でテクニカルライターを募集しているのを見て、面白いなと思ったことを思い出した。）

これらのデメリットはあるものの、開発チームと方針を合わせて、プロダクトマネージャーやデザイナーなどと協働できるようになったことは、ユーザー価値への貢献という意味で確実な前進だと感じている。他の職能の人と、お互いに強みを活かしあって協力して動くことは、単純に楽しい。