見出し画像

#4 要件段階|なぜ仕様書が書かれない?合意形成が進まない?犯人は人事評価基準か?

シリーズの続き。

#1 記事↓

今回は「要件の切り分けをちゃんとする」の続き
結局、人事評価の問題にまで話が広がった。


仕様書が書かれなくなってしまう

課題

自社で仕様書が用意されておらず、エンジニアが発狂することがある(発狂は言い過ぎかも)Figmaで引いたデザインにコメントで仕様を書き込んでいたが、要件が膨らみすぎて、コメントが100件を越えたあたりから悲鳴が上がった。

原因は本にもある通り、「実際の製品を反映していない」ことが原因にある。実装の過程で物事が変化するためだ。

仕様書なんて書いても無駄だ、とあきらめるのは間違っている。仕様の定義が製品開発と別のプロジェクトになってしまわぬよう、使用の定義プロセスを軽量化するのである。つまり、文書で問題は解決しないが、定義は解決する。

p.63


仕様書の理想

NG例
- 詳細な仕様を全て網羅する→更新できなくなる
- 製品の理想的な今後の状態を含める
- 仕様が具体的でない

OK例
- 明確さと正確さを重視する
- 開発プロセスでの混乱を防ぐ最低限の情報を記載する
- ポジティブであること(〜できない、ではなく、もし〜なら〜する など)
- 主観的な表現を避ける(要求が満たされていない場合、それを証明できる必要があるため)
- コンテンツの場合、更新頻度をはっきりさせておく必要がある


現実を振り返る

個人的に異論がある「製品の理想的な今後の状態を含めなくて良い」「仕様は具体的にした方が良い」というのは、自分達には合わない気がする。今後の運用も考えて設計することもあるため。

・・・と思ったが・・・

自分たちが普段「仕様書」と読んでいるのは機能要求であって、ここで語られている「仕様」ではない!

現状、施策の担当者から、デザイナーやエンジニアに資料が渡されるとき、「これが仕様です」と言って渡されるが、機能要求が明記されておらず、よく分からない謎の仕様だけを渡されることがある。

そこで、色々聞いた結果、機能要求が判明することがほとんどなので、「もう、仕様書にやりたいことだけ書いて、仕様は書かなくていいよ!こっちで考えた方が早い」という、意味不明なやりとりが交わされていた。そういえば・・・

それで、デザイナーやエンジニアが考えた仕様を「あとは、まとめといて!」と言って任せている。・・・それで仕様書を書けと言われても、書けないよな・・・


今後は、仕様書ではなく「機能要求を書いて」と言って、要求に従って都度設計や実装を進め、仕様はデザインファイルやテストケースに書いて、ドキュメントの整理を徹底することで、把握できるように・・・

?いや?って、コメントが100件越えて発狂するって話だった・・・

そう、だから・・・結局、チームのリソースに対して、リリース単位がデカいことが課題だった!!

ノンスタイルのコントみたいにしまった・・・



機能要求に優先順位をつける[現場]


機能要求の評価[戦略]

  • 出てきた機能要求を、戦略(製品目標とユーザー要求の仮説の両方)を満たすか評価する
    ※戦略と機能要求が、1対1で関係するとは限らない

>仕様を詰める前に、プロジェクト外のメンバーに客観的に評価してもらうと良いのかも。ディスカッションをしながら描いたスケッチなどをもとに、同僚や、顧客対応をしているメンバーなどに聞きに行こう。

>同僚に、狙いを説明せず、想定しているユーザーの状態だけを共有して、機能についての感想を聞く、というのもアリかもしれない。客観視というのは想像の何倍も難しいから。


機能要求の評価[実現可能性]

  • 実現可能か評価する。

    • 実装可能か

    • 納期とリソースは現実的か(役員に設定されている場合など)

>エンジニアにも相談する。できるorできないの2択ではなく、5段階くらいで所感を聞こう。あのプロジェクトと比較してどうか、既存の開発環境で実現できそうか、など、大まかな所感で良い。これは確約された納期の解答ではないということを、関係者全員で認識を揃えておきたい。それを判断するには、まだラフすぎる。




機能要求に優先順位をつける[ステークホルダー]

やるべきこと

現実的に、企業の政治の問題になることが多い。
この交渉プロセスを管理するのは難しい。ステークホルダー間の対立を解決する最良の方法は、定義された戦略に訴えことだ。
戦略目標を達成するために提案された手段ではなく、戦略目標にファーカスする。

p.71

ステークホルダーが支持する機能要件ではなく、ステークホルダーのニーズに共感すべき。

>せやな!!これが、難しいんよ・・・どうすれば良いんだ・・・


合意形成の問題の深ぼり

まず、そもそもこの段階でデザインチームに話が降りてきていないこともある。後から訳の分からないプロジェクトに巻き込まれる事もしばしば・・・

デザインチームを、この段階で入れようと思ってもらう必要がある。
普段から、この記事の内容のような、ナレッジをSlackで流して、「相談に乗ってもらえそう」という雰囲気を醸し出しておこう。

それから、話の文脈を断ち切るタイプのマネージャーの対策も考える必要がある。これは戦略段階の話が足りていないか、忘れられている状態で話を進めてしまっているせいだと思う。戦略段階の話を明文化して、いつでも何度でも共有できるようにしておこう。

合意形成に行く前に、仕様を一生懸命に詰めている人には作業を中断させて、戦略段階の話の明文化に注力してもらおう。デザイナーも戦略段階の話をもっと深く理解して、話を整理できるように努める必要がある。

それができれば、機能要件の優先順位が見えてくるはず・・・


評価した結果、戦略が間違っていたことに気づく場合もある。その場合は要求定義に進むのが早すぎたのかもしれない。そしたら、黙ってやり直そう。まだ、引き返せるうちに引き返そう。

ここで、メンバーの評価を「プロジェクトの完遂」に設定しているケースがある。すると、この段階で戻れない。メンバーの評価基準を見直してもらう必要もありそうだ。ああ・・・また他部署のマネージャーと、交渉しなくてはならないかもしれない・・・

それは、やっぱりUX改善の成功達成基準が明確になっていないので、プロジェクトの完遂が目標になってしまっている気がする。



デザインチームのタスク一覧

  • プロジェクトリーダーになる事業側のメンバーの人事評価基準を、プロジェクトの完遂ではなく、UX改善の成功測定基準を元にした内容にシフトしてもらう → 面倒臭い話だけど、これができないと下記の動きを取るのが難しそう・・・!

  • 起案者に、詳細な仕様ではなく、機能要件をまとめてもらう

  • 機能要求の優先度付け

    • デザインチームに話を持ってきてもらえるように努力する

    • 顧客と近くで接しているメンバーに所感を聞いて回る

    • エンジニアにも相談する(二元論にしない、納期の確約はしない)

    • ステークホルダーと話す前に、仕様ではなく戦略を整理しておく

    • 機能要求ではなく、戦略の優先度で会話する

  • 優先度を元に、リリース単位を分ける

  • 更新可能な必要最低限の仕様をまとめる

  • デザインファイルやテストケースに、詳細な仕様は記載する(リリース単位が小さい前提)

  • 仕様を更新する

    • デザインファイルやテストケースへアクセスできるように、リンクを張っておく


次回:要件に対し誤った構造設計を仕様書に書いてくる人に、フィードバックをする





この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!