アジャイルなプロジェクトでテクニカルライターとして働いて良かったこと

テクニカルライターの頃にアジャイルなプロジェクトでマニュアルを制作する機会がありました。製品（ソフトウェア）開発視点でのアジャイルに関する情報はよく目にするのですが、マニュアルに関する情報は見当たらないなと思ったので、書ける範囲で自分の思ったことを書いてみたいと思います。

下流工程と認識されるマニュアル制作

一般的に、テクニカルライターは製品の仕様書を参照したり、製品のプロトタイプを操作したりして、マニュアルを制作していきます。製品の仕様が固まってきてから制作を開始することが多いため、マニュアル制作を下流工程と認識されている方は多いかもしれません。

その場合、マニュアルを制作する中で製品の改善点に気づいたとしても、製品の開発はもう収束に向かっているため、変更する時間や人的リソースがないことが多々あります。クリティカルな事象であれば、マニュアルに免責事項を記載することで対処することもあります。そのため、いつの間にかマニュアルが免責事項だらけになっていた…という話に共感いただけるテクニカルライターの方もいらっしゃるのではないでしょうか。

テクニカルライターの役割を考え直すきっかけになったアジャイル

アジャイルなプロジェクトで、下流工程ではなく、製品の実装と同じタイミングでマニュアルを制作する機会に恵まれました。当時の日本では、今ほどアジャイルは普及しておらず、振り返ってみると、かなり先進的で貴重な経験をさせてもらったと思います。

とにかく目の前のことに必死に取り組む！と余裕のない状況も多かったですが、この頃の経験が「業務をマニュアル制作に限定しない」という意識につながりました。その意識に関しては下記にまとめましたので、良かったら覗いてもらえると嬉しいです。

アジャイルなプロジェクトを経験して良かったこと

当時の経験を基に良かった点をご紹介します。

- 上流から情報をキャッチアップすることで理解が深まる

ユースケース検討、要件定義といった開発の上流で行われる打ち合わせに出席していました。ターゲットユーザーのニーズ、なぜこの仕様にすべきなのかの根拠や決定の経緯など、製品の開発者と同じタイミングで情報を得ることができ、非常に有意義でした。ドキュメントには必ずしも記載されないような検討の経緯をその場で把握でき、疑問点をすぐに質問して解消できるからです。

というのも、従来のマニュアル制作では、これらの情報を製品の開発が収束に向かう頃に仕様書などのドキュメントから拾うケースが多いです。ただし、ドキュメントに記載されるかどうかは開発の担当者次第という属人的な面も否めず、ドキュメントだけですべてを理解することには限界があると感じています。また、開発の担当者に問い合わせる頃には、その担当者は別の検討をしていて多忙になっているなど、疑問点の解消に時間が掛かることも少なくありません。

さらに、テクニカルライターが開発の背景や方針を深く理解することは、開発者の意図を汲んだマニュアルの制作につながります。開発者にとって期待どおりの記載内容であることで、マニュアルレビューの負荷軽減につながっていました。

- 製品の品質向上に貢献できる

製品の実装段階では、マニュアルを制作しているからこそ気づける改善点を開発者に伝えたり、製品で表示されるエラーメッセージやUIの文言をレビューしたりしていました。従来のマニュアル制作では「もっとこうしたらユーザーが使いやすいのに」と改善点に気づく頃には開発が収束しているなど、変えたくても変えられないという、もどかしい思いをすることも多いのではないでしょうか。

製品の開発者と同じタイミングでマニュアル制作を進められると、製品全体の品質向上に貢献できる機会が増えると実感しています。開発者にとっても早い段階で改善点を吸収できることは手戻りがなく良いですし、さらに使いやすくなることは製品の価値を高めることにつながります。

- 自然と情報が集まり、仕事の幅が広がる

製品理解を深め、品質向上のための取り組みを積み上げていくと、開発者から「マニュアルの人も、製品全体の品質向上を考えているんだなー」と認識してもらえるようになりました。

その結果、「マニュアルにこの情報いるよね？」、「仕様変更するけど、マニュアルに影響ある？」と連絡を受けることが増え、自然と情報が集まってくるようになりました。既述したとおり、一般的にマニュアル制作は下流工程が多く、「仕様を変えたけどマニュアルチームにインプットしていなかった！」と関係者に悪気なく存在を忘れられることも少なくありません…。

さらに、「マニュアルの人が居ると新しい気づきがあるから、仕様レビューに呼ぼう」、「このUI、ちょっとマニュアルの人に意見を聞いてみよう」と、開発者からマニュアル以外のことで声が掛かることもありました。マニュアルの範囲に限定せずに、日頃から製品全体の品質向上のために貢献しようと努めることで、相談してもらえる範囲が広がっていったと実感しています。

最後に

当時はわからないこともあって恥ずかしい思いもたくさんしましたが、開発に関わる様々な立場の人と一緒に仕事できたことは純粋に楽しかったです。考えたこと、発言したこと、手を動かしたことが決して無駄にならない状況では、「もっと何か良くできるんじゃないか？」という気になり、さらに良い状態を目指すモチベーションにつながります。どんなときもマニュアル制作に限定せずに製品全体の品質向上を考えていくことが、私の基本的な姿勢となっています。