Let's write β

プログラミング中にできたことか、思ったこととか

要求分析の時にやってる事・意識してる事棚おろし

なに?

自分が要求分析というタスクをしている時に意識している事をとりあえず棚おろししておく

論理的な部分

ステップ

  1. 対象となる要求のおおまかな概要を把握(この時はタイトルや概要程度でよい)
  2. 対象領域でヒアリングが必要なメンバーの選定
  3. ヒアリング前にあるていど見立てが立つ場合はアジェンダをまとめる or まったくわからない場合はキックオフとしてショートにあらましを聞く会を開く
  4. アジェンダを事前共有(できれば24時間以上前)
  5. 議事録にまとめる
  6. 議事録を元に要求仕様書のベースを書く
  7. デザイナーにUI/UXにデザインをしてもらう必要がある時は仕様書を元に共有
  8. デザインができあがったら、それを要求仕様書にも貼る

最終成果物の例

アジェンダの構造

背景、ゴールはかならずつける

  • 会の目的を明確にする事で、ズレた認識や優先度の低い話題に時間をつかってしまう事を避ける
  • 後の意思決定時に、当時の決定のコンテキストを明確にする
  • 背景の形式例:
    • 対立する構造がある場合: <現在の状況>があるが<構造1>と<構造2>で対立しているので認識統一したい
    • 選択可能な手法が複数ある場合: <解決したい課題>があるが<手法1>,<手法2>など様々な手法があるので、どの手法を採用するか決定したい
    • ヒアリング: <解決したい課題>があるが<部門or人>と<部門or人>で状況の認識を統一したい
  • ゴール
    • 会の終了時に何が明確になっていれば良いかわかる
      • 例: 選択する手法、トレードオフの中でどちらを選択したか、ネクストアクション(内容、期日、担当者のトリプル)

現状整理のセクション

  • 事前に各部門収集した情報や、想定している手法についてまとめる
  • 手法の選択の場合
    • 各手法について整理し、Pro,Conを整理する
    • 可能であれば、自分としての「これがベストだとおもう、なぜならば~」というところ「現状整理」としてのセクションとして纏めて確認してもらうだけのMTGとして進める

議事録

  • 要旨を整理はするが、棄却された内容についても内容と棄却理由について明確にする
    • 「なにが選ばれたか」だけではなく「なぜ他の手法ではないのか」を残しておく必要がある

要求仕様書の構造

目次はかならずつける

  • 理由: 大きな仕様書をメンバーが簡単に引けるように

構造

  • 背景
    • その要求仕様ができているざっくりとした事業や技術的な背景を書く
      • 理由
        • あとから見なおしてその意思決定の背景をおおまかに理解したりするときに役にたつ
        • メンバーへの説明責任
  • 議事録
    • 要求仕様ができあがる前にMTG等をしていたら、その議事録へのリンクを貼る
      • 理由
        • あとから見なおした時に意思決定の背景を把握する、議論の仮定でどんな意見がでて、なぜ棄却されたのか、どのメンバーの中で議論された事なのか記録として残しておく
        • メンバーへの説明責任
  • 要求仕様
    • 各要求をユーザーストーリーの単位で書く
      • <誰>として<なに>が<どうなる>
        • 例:
          • 配達パートナーとして、指名されているリクエストに時間帯指定がある時に、マッチ前に時間帯が把握できる
        • 理由
          • ユーザーストーリーの単位で書く事で、なにが実現したいのか抽象的で明確になりやすい
          • ユーザーへの価値提供目線で記載する事で、メンバーから追加や補足、改善案をもらいやすい
      • デザイナーにデザインしてもらったFigmaへのリンク (UIにかかわる場合)
        • 理由
          • 文字だけではなく視覚的にも共有する事で最終成果物にたいする認識齟齬を減らす
          • モバイルやフロントエンドではどのようなUIになるかによって実装の制約や方針が大きくかかわるため明確にする
      • 理由 (その機能がある理由を明確にする)
          • 時間帯が指定されている事を理解した上でマッチングしてもらう事で、時間帯指定をより意識してもらい、時間帯への遅延を抑制したい
        • 理由
          • 一つ一つの価値提供についてなぜその価値を今回のリリースで含める必要があるのかを明確にする事で機能の取捨選択をしやすくし、MVPとしてリリースする事を意識する
          • メンバーへの説明責任
      • 仕様
          • [ ] リクエストに時間帯指定がある場合は開始時間、終了時間が表示される
            • [ ] 集荷時間帯
            • [ ] 配達時間帯
        • 理由
          • 具体的な機能の挙動について明記する事で、最終的な成果物のイメージの認識を揃える
          • エンジニアが、実際に実装するにあたっての機能の認識を明確にする
          • テストの指針にする

非論理的な部分

要求を出している人との間で、医者と患者の関係になる

One kind of relationship many of us have that does break this anti-pattern when it goes well is the one we have with our doctor. Try showing up at your doctor’s office and giving her your “requirements.” Tell her the prescriptions you’d like written and the operations you’d like scheduled. If she’s nice, she’ll smile and say, “That’s interesting; tell me where it hurts.” In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner’s.

Patton, Jeff; Economy, Peter. User Story Mapping (p.226). O'Reilly Media. Kindle 版.

相手に言われた事をそのまま要求として書きくだすのではなく、解決してほしい内容を把握して、適切なソリューションに落とすことを心がける

徹底した傾聴に注力する

要求を分析するにおいては「徹底した傾聴」のスタンスでのぞむ

  • 相手の部門・個人に限定された合理性が出てくる場面
  • 「苦労する事はやりたがらず、楽な事はやりたい」という気持ちへの配慮が必要な場面
  • 言語化されないが、なんとなく伝わっていない・伝わってこない場面
  • 言葉の定義が曖昧な事、言葉の用法が自分と相手で違う場面
  • 相手の説明が散漫で時系列や構造的に整理されていない

など様々な場面があるが、目的は「最終的に相手の部門やユーザーに価値提供するための良い要求仕様を得る」事なので、 批判やフィードバック等を実施せず、相手から引きだして仕様を整理する事を目的とする

傾聴のスタンスを崩しつづけてしまうと、相手から「その場かぎりの偽の了解(や逆に、心情的な反発による偽の反論)」を得てしまったり、 意見や反論をあげる心理的なハードルがあがってしまいより良い仕様に到達できない可能性が高まる

想定ケースと、解決策の例

相手の部門に限定された合理性

  • 解決案策
    1. 「なるほどOOとしてはXXしたいんですね、一方で△△にとっては□□のようなので、@@とするのはどうでしょう」と情報を共有して「目標の衝突vs私たち」という形にする
    2. その場で結論がでない場合は、競合する部門の人に説明して、両方の立場の人をそろえて議論を再度実施する
      1. 代理戦争的な空中戦をせずに当事者同士を呼ぶほうが解決がはやい
  • アンチパターン
    • 「それは全体最適ではない意見ですね、個人最適な意見を出さないでください」等、批判orフィードバックしてしまう

非常に煩雑な作業になってしまう、手間が増える作業が相手に発生する

  • 解決策
    • 「その場合、XX,YY,ZZという順で作業をするとおもいますが、作業の負荷として問題がないでしょうか」と確認する
      • 「たしかに困難ですね」となった場合、代替案を探すべきか、困難だが実施し、段階的に補助的な機能を検討するのか等を相手と認識を揃える
  • アンチパターン
    • 「これは手間そうだが、相手の責任だからやるだろ」と心の中でおもい、相手に確認しない
      • 理由
      • 「この作業はこうなって手間だがどうか」という確認がとられるまで「作業の内容や結果が正しいか」のみに相手の頭が向いている可能性があり、いざ現場では実行困難になる可能性がある
      • 最終的に実行されなければユーザーに価値は届かない

相手が言語化がうまくできない要求や感覚を抱えている

  • 解決策
    • 具体的なケースを話してもらい、抽象化する
      • 「OOな時XXになってしまって、それはなんか違う」「他にも△△の時は□□になってしまうので、それもいまいち」→ 「つまり、XXがZZという事でしょうか」
    • 言葉だけではなく、図や具体的な作業を見せてもらう
    • 単語をケースに分解しより細かい単語に分解する
  • アンチパターン
    • 「言語化してくれないとわかりません」と批判する

相手にうまくつたわっていない雰囲気がある

  • 解決策
    • 言葉だけでなく、図や具体例をあげてみる
    • 伝わっていないのではなく、その作業が相手にとって手間である可能性を考える
      • 手間であると感じられている場合は、代替案が必要かもしくは作業をするだけの価値が相手につたわっていない
    • 「一度試しにやってみて、改善していくのはどうでしょう」と確定ではなく改善を想定したファーストリリースという事を認識してもらう
  • アンチパターン
    • 伝わっていない雰囲気のまま話が終った事にする

言葉の定義が自分と相手とで違う

  • 解決策「『この場では』OOである事をXX、△△を□□と呼んでみませんか?」と提案する
  • アンチパターン「あなたがいっているのは□□で、XXではありません」とその場でフィードバックをする

説明が順序立っていない、整理されていない

  • 解決案策
    • 相手の話をさえぎらずに、メモをとりながら最後まで聴く
    • その後「私の認識があっているか確認したいため、XXという事で間違っていませんか」と整理した結果を復唱し認識の齟齬がないか確認する
  • アンチパターン
    • 「まとめてから話してください」「端的に言ってください」等の批判orフィードバックをしてしまう

参考文献