プロダクト開発に活かそう！言語化・ドキュメント化のすヽめ

POLプロダクト Advent Calendar 2020の9日目の記事です。

株式会社POLが提供する、研究内容をもとに優秀な理系学生をスカウトできる新卒採用サービス「LabBase」のtoB向けのUI/UXデザインを担当している@banyanfreeです。

今日は、プロダクトで必要とされるドキュメントを作る時に、少し意識を変えて取り組むと...

• プロダクトの設計・仕様、品質のチェックツールとして使えたり
• 制作を通じて、スキルアップにも繋がったりするかも？

と言う話をしたいと思います。

プロダクトに関する身近なドキュメント

さて「プロダクトに関するドキュメント」と言ったら、みなさんは何を思い浮かべるでしょうか？ 思いつきで雑にリストアップすると、以下のようなものがあるかと思います。

• プレスリリース：広報
• SPツール（パンフ, 営業資料, LP etc.）：営業, マーケ
• 要求・要件定義書：PdM
• 機能仕様書：エンジニア
• デザインルール：デザイナー
• UIラベル・メッセージ：デザイナー, テクニカルライター
• テスト仕様：QA
• リリースノート： エンジニア
• マニュアル：テクニカルライター

いずれも専任者が制作を担うことが多いため、馴染みがないものもあるかもしれません。

ドキュメント制作に関わる利点

ドキュメントを書くことに対しては、好き嫌いが分かれるところかと思います。普段の業務からは縁遠いドキュメントを作る場合、苦手！嫌い！面倒！な方にとっては尚更敬遠したくなる話かもしれません。

ただ、さまざまなタイプのドキュメントの制作に関わってみると、制作過程で次のような状況に遭遇することになり、結果として青字で記したメリットを得る機会に繋がるのも事実。

• 成果物の制作者の視点をもって取り組むことになる

  => 物事を考察・判断するための観点を増やせる

• 同じプロダクトの話でも成果物によってターゲットや伝え方が変わる。効果的に伝えるためには、製品、ターゲット、業務、ビジネスの知識や理解が必要に
なる
  => 視野が広がる。視座が上がる

• 読者がプロダクトのことを一切何も知らない前提でマニュアルを書き、それに合わせて実操作してみると、
機能の不具合や影響範囲の考慮漏れを発見したり...
  => 製品テストや提供価値の検証になる
  => 結果、プロダクトの品質が上がる。これを学びに変えれば設計力の向上に繋がる

次に、ドキュメントのフォーマットや制作時の観点をプロダクト開発に活用した例をいくつか紹介したいと思います。

プロダクト開発への活用例

仮想プレスリリース

プレスリリースの活用例として有名なのはAmazonの「仮想プレスリリース」でしょうか。

cf. シリコンバレー101(391) 製品開発より先にプレスリリースを書いてみるのがAmazon流

これは実際にメディア発表のために書くのではなく、製品開発の設計や顧客にとっての価値検証を目的に作成しているようです。また、FAQやマニュアルなどのドキュメントも製品開発のプロセスに組み込まれて、有効活用されているようです。

仮想プレスリリースと類似のものとしては、ユーザー視点でサービスのアイデアを共有、検証、提案することが目的とした「仮想カタログ」や、インセプションデッキの「パッケージデザイン」や「エレベーターピッチ」が該当するかと思います。

このように実装に入る前に顧客や第三者への説明用のドキュメント制作することで、顧客に対して価値提供できているか、無駄な開発をしようとしていないか、検証ツールとして活用することができます。

要求仕様書

動作確認やデザインチェックのために実装された機能を操作した際、要求のスコープにある利用の1シーン1画面にフォーカスしすぎて影響範囲への対応漏れや他のシナリオへの考慮もれなどを見かける時があります。

このような資料を見つけました。

cf. 「要求には無いが想定しておくべき条件」に着目した設計着手前レビューの提案
- 要求仕様の抜け漏れを防ぎ開発の前提条件のちゃぶ台返しによる大幅な手戻りを防止-

エンジニアの方々は、普段から要求・要件定義書を書く機会が多いと思いますが、そこに一工夫、例えば要求・要件定義書のテンプレートに「要求には無いが想定しておくべき条件」を観点に加えることで、仕様の抜け漏れや手戻りを防ぎ、プロダクトの開発やテストの工数を短縮できるかもしれません。

マニュアル

最近、機能のマニュアルやヘルプを書く機会があったのですが、その制作過程では次のような作業も行いました。

• 利用方法の説明や機能メリットを書くために仕様書を熟読
  = 仕様レビュー

• どのように実装されたか実際に操作して確認
  = 機能テスト, アドホックテスト

• 「ユーザーが知りたいと思うこと」を想像するために、
初めて使う人になりきって実操作

  = 簡易ユーザビリティテスト

• 実利用の状態に近しいスクリーンショット撮るために、ユースケース検討
  = シナリオテスト

ソフトウェアテストの種類に当てはめると、テスト範囲の広さや深さはないものの、ユーザーが遭遇しやすいレベルのテストをカバーできると言う点で、プロダクトの品質保証に活かせるのではないかと思います。

まとめ

言語化・ドキュメント化することを「追加作業」として捉えると面倒くささが先に立ちますが、ちょっと意識を変えて取り組むだけで、同じ工数で+αの効果が得られるかもしれません。

- 物事を考察したり、判断したりするための観点が増えるよ！
- 視野広がったり、視座高くなったりするよ！
- 検証にも使えるよ！
- プロダクトの品質や設計力もあがるよ！

と、言うことで、「言語化・ドキュメント化」を開発プロセスに積極的に取り入れてみてはいかがでしょうか？
💭 個人的には「プログラマーの三大美徳」にも通じる話だと思っています！頑張りましょう！

明日は、4日目に登場したゲバさん（@guevara-net）の第2回目です！お楽しみに！