RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

【まとめ前編】楽楽精算PdMが資料を作るときに考えていること

皆さん、こんにちは!もしくはこんばんは! 楽楽精算プロダクトマネージャーの@wekkyyyyです。

前回は「楽楽精算のPRD(製品要求仕様書) Agenda」というテーマで記事をかかせていただきました。

tech-blog.rakus.co.jp

今回は趣向を変えて、「資料を作るときに考えていること」
いわゆるドキュメンテーションスキルについて書いていこうと思います。

目次は以下となります。

対象読者

ドキュメントを作成し、人に説明義務が発生する方

特に以下のドキュメントを作成する方

  • 課題解決において
    • 誰かを説得するための資料
    • 何かを合意するための資料

筆者がどんな人物か

以下の通りPjMをやり始めてからドキュメンテーションの重要性を知ることになり、
ゴリゴリに鍛えてもらいました。
(当時の同僚・先輩・上司に感謝です)

  • インフラエンジニア(ネットワーク) 6年
    • このころはゴリゴリのエンジニア
  • PjM/Director 4年
    • ここから業務の仕組み化に着手しだす
    • 元コンサルの同僚/上司にドキュメンテーションについてしごかれまくる
    • 毎週役員の時間を15分だけもらい、その時間で説明・質疑応答・合意できなければいけなくなる
  • PdM 4年
    • ドキュメンテーション能力がないとまったく成り立たない役割になる
      (会社によって異なりますが筆者はその環境でした)

なぜこれを書いたのか

弊社のshibaが書いた記事 楽楽精算PdMのオンボーディングと実践したこと にて以下の記載がありました。

「お、これは俺のことだな。んならいっちょ私の知識をちょっと共有したろ。」

という完全に上から目線ムーブをかますためです。

嘘です。本当に勉強になって成長に寄与できるなら共有しようと思っただけです。
(もう何も言っても無駄な気がしてきました)

ブログにしたのは、「楽楽精算のPdMは、こんなこと考えて仕事してます!こんな人がいます!」

ということを未来の同僚に対してもお伝えしたかったからです。
(これはプラスにもマイナスにもなり得るのでビクビクしてます)

注意点

本内容は、万物のドキュメントにあてはまるものではないと考えています。

「今自分が取り掛かっているものにハマるか?」は、ご自身でご確認をお願いいたします m( )m

資料を作るときに考えていること

【まずやる】仕事と作業を分けて優先度をつける

基本的は、「仕事」になるものを優先度をあげて行っています。

時間がかかるものですし、作業は仕事の合間にこなすことができると考えるためです。

※仕事・作業の中でも優先順位は、プロダクトインパクトだったり、上司からの緊急だったりと様々あると思うので、ご自身で操作してください。

- 仕事:その結果によって誰かに価値を届けるための活動

→めっちゃ頭使う。

- 作業:事前に定められた手続きとゴールに向けて行う活動

→ある程度は、脳死でできる。

【いざ開始】1つのアウトプットを3ステップで分けて作業する

以下の4ステップに分けて考えています。
それぞれの段階でレビューにかけます。

1. 15点版(全体の流れこんな感じ状態)
2. 30点版(一旦作りました状態)
3. 60点版(見直して熟成します状態)
4. 90点版(これで提出します状態)

※100点は、最終合意状態を指すので割愛します。

【15点版】1に達成状態・2に達成状態・3、4がなくて5に達成状態

ここから各点数版での細かい話に移ります。

とにもかくにもまずは、達成状態を決めます。

誰が・どのような状態になっていれば、この仕事は完遂されるのか?

自分の言葉でまとめられない限り、後続は進めなくていいと考えているくらいです。

【15点版】Agendaとざっくり内容でストーリーをつくる

決めた達成状態に対して、以下を検討し全体のストーリーを作成します。

「どんなことを説明・証明する必要があるか?」
「どんな流れで説明するとわかりやすいか?」

ここで完璧なもの作ろうとはしてないです。
なるべく完璧にできるといいですが、ドキュメントを作りながら変えることも多いです。

「ん〜こんなことは説明しないと伝わらないよな〜。」くらいの気持ちで大丈夫と言い聞かせてます。

筆者がよく使うストーリーとしては、以下です。
この流れで上記のことを考えて、書くことを箇条書きにしておきます。

ものによって細かく分けたりしますが、考え方として参考にしてください。

1. 現状把握
    a. 現状を解像度高くわかるようにする
2. 創案
    a. いわゆる解決案を出す
3. 評価
    a. 解決案を評価する
4. 選択
    a. 解決案を絞る

【30点版】納得感をどうやって実現させるか考える

上記の現状把握創案評価選択に当てはめて記載します。 それぞれのフェーズでの要素を記載していきます。

こちらも筆者のよく考える思考を書いているだけなので、
対応する課題内容、すでに把握している情報、社内状況によって変動しますので一例とさせてください。

現状把握

  1. 定性・定量セットで状況を把握する(Factが重要!!)
    1. 定量データ
      1. システムログ
      2. DB
      3. アンケート結果など
    2. 定性データ
      1. インタビュー結果
      2. VoCなど
  2. 定性的なデータを可視化した上で、定量情報を付与する
    1. ユーザーストーリーマッピング・カスタマージャーニーマップを利用することが多い
      1. 誰の目線なのか?を意識する(MECE意識※)
      2. 「なぜ?」「それでどうなる?」を繰り返すことでマップがつながる(MECE意識※)
      3. 数値の変化もあるか意識する(傾向が見えるか)
  3. 1.2.の結果から課題点を可視化・言語化する

MECEにするためのテクニックは、以下創案部分をご参照ください。
 (あくまでテクニックの一部なので、他にも調べてみるとよいと思います。)

創案

  1. 現状把握で可視化・言語化した課題に対して取れ得る策を洗い出す
    1. What/Howをロジックツリーで洗い出す
      1. WhatとHowのロジックツリーを分ける(MECE意識)
        1. まず当たり前の答えを考える
        2. 当たり前の対極を考える
        3. それとそれ以外を考える
        4. ペアになるものを考える
        5. 因数分解した結果を考える
        6. 分裂したものが、「AND」なのか「OR」なのか明確にする

評価

  1. 漏れのない評価項目をまず作る(MECE意識)
  2. 評価項目にウェイトをつけるルール(条件)を考える(条件設定法とも言う)
    1. 必要ない評価項目は後で消すかもしれないので、どれが重要なのか明示できるようにする
  3. 評価項目内の優劣の基準を明確にする
    1. めざす方向性に対しての基準を取るようにする
    2. 筆者がよく使うのは5 or 10段階のポイント制
    3. どの状態がどのポイントなのかを明確にする(絶対重なり合うような状態にしない)

選択

  1. 複数案出すようにする
    1. この時点では、同じ点数になることも多いと思います。
      (その場合評価項目が足りていないのだと思います)
      ですが、そのまま関係者含め選択し、後学として選択した際の判断基準を確認するようにしましょう。
    2. 仮に同じ点数じゃないとしても、XXを重要視するならこれ等 迷う部分はあると思います。
      (これも評価項目が足りてないと思われる)
      ですが、まだ30点版なので、思い切って出しましょう。後で削ればいいと思ってます。

続きは後編へ...

書き出したら長くなってしまいました。。。 続きは次回の後編に記載します。

Copyright © RAKUS Co., Ltd. All rights reserved.