#4 要件段階｜なぜ仕様書が書かれない？合意形成が進まない？犯人は人事評価基準か？
シリーズの続き。
#1 記事↓
今回は「要件の切り分けをちゃんとする」の続き
結局、人事評価の問題にまで話が広がった。
仕様書が書かれなくなってしまう
課題
自社で仕様書が用意されておらず、エンジニアが発狂することがある（発狂は言い過ぎかも）Figmaで引いたデザインにコメントで仕様を書き込んでいたが、要件が膨らみすぎて、コメントが100件を越えたあたりから悲鳴が上がった。
原因は本にもある通り、「実際の製品を反映していない」ことが原因にある。実装の過程で物事が変化するためだ。
仕様書なんて書いても無駄だ、とあきらめるのは間違っている。仕様の定義が製品開発と別のプロジェクトになってしまわぬよう、使用の定義プロセスを軽量化するのである。つまり、文書で問題は解決しないが、定義は解決する。
仕様書の理想
NG例
- 詳細な仕様を全て網羅する→更新できなくなる
- 製品の理想的な今後の状態を含める
- 仕様が具体的でない
OK例
- 明確さと正確さを重視する
- 開発プロセスでの混乱を防ぐ最低限の情報を記載する
- ポジティブであること（〜できない、ではなく、もし〜なら〜する など）
- 主観的な表現を避ける（要求が満たされていない場合、それを証明できる必要があるため）
- コンテンツの場合、更新頻度をはっきりさせておく必要がある
現実を振り返る
個人的に異論がある「製品の理想的な今後の状態を含めなくて良い」「仕様は具体的にした方が良い」というのは、自分達には合わない気がする。今後の運用も考えて設計することもあるため。
・・・と思ったが・・・
自分たちが普段「仕様書」と読んでいるのは機能要求であって、ここで語られている「仕様」ではない！
現状、施策の担当者から、デザイナーやエンジニアに資料が渡されるとき、「これが仕様です」と言って渡されるが、機能要求が明記されておらず、よく分からない謎の仕様だけを渡されることがある。
そこで、色々聞いた結果、機能要求が判明することがほとんどなので、「もう、仕様書にやりたいことだけ書いて、仕様は書かなくていいよ！こっちで考えた方が早い」という、意味不明なやりとりが交わされていた。そういえば・・・
それで、デザイナーやエンジニアが考えた仕様を「あとは、まとめといて！」と言って任せている。・・・それで仕様書を書けと言われても、書けないよな・・・
今後は、仕様書ではなく「機能要求を書いて」と言って、要求に従って都度設計や実装を進め、仕様はデザインファイルやテストケースに書いて、ドキュメントの整理を徹底することで、把握できるように・・・
？いや？って、コメントが100件越えて発狂するって話だった・・・
そう、だから・・・結局、チームのリソースに対して、リリース単位がデカいことが課題だった！！
ノンスタイルのコントみたいにしまった・・・
機能要求に優先順位をつける[現場]
機能要求の評価[戦略]
出てきた機能要求を、戦略（製品目標とユーザー要求の仮説の両方）を満たすか評価する
※戦略と機能要求が、1対1で関係するとは限らない
＞仕様を詰める前に、プロジェクト外のメンバーに客観的に評価してもらうと良いのかも。ディスカッションをしながら描いたスケッチなどをもとに、同僚や、顧客対応をしているメンバーなどに聞きに行こう。
＞同僚に、狙いを説明せず、想定しているユーザーの状態だけを共有して、機能についての感想を聞く、というのもアリかもしれない。客観視というのは想像の何倍も難しいから。
機能要求の評価[実現可能性]
実現可能か評価する。
実装可能か
納期とリソースは現実的か（役員に設定されている場合など）
＞エンジニアにも相談する。できるorできないの2択ではなく、5段階くらいで所感を聞こう。あのプロジェクトと比較してどうか、既存の開発環境で実現できそうか、など、大まかな所感で良い。これは確約された納期の解答ではないということを、関係者全員で認識を揃えておきたい。それを判断するには、まだラフすぎる。
機能要求に優先順位をつける[ステークホルダー]
やるべきこと
現実的に、企業の政治の問題になることが多い。
この交渉プロセスを管理するのは難しい。ステークホルダー間の対立を解決する最良の方法は、定義された戦略に訴えことだ。
戦略目標を達成するために提案された手段ではなく、戦略目標にファーカスする。
ステークホルダーが支持する機能要件ではなく、ステークホルダーのニーズに共感すべき。
＞せやな！！これが、難しいんよ・・・どうすれば良いんだ・・・
合意形成の問題の深ぼり
まず、そもそもこの段階でデザインチームに話が降りてきていないこともある。後から訳の分からないプロジェクトに巻き込まれる事もしばしば・・・
デザインチームを、この段階で入れようと思ってもらう必要がある。
普段から、この記事の内容のような、ナレッジをSlackで流して、「相談に乗ってもらえそう」という雰囲気を醸し出しておこう。
それから、話の文脈を断ち切るタイプのマネージャーの対策も考える必要がある。これは戦略段階の話が足りていないか、忘れられている状態で話を進めてしまっているせいだと思う。戦略段階の話を明文化して、いつでも何度でも共有できるようにしておこう。
合意形成に行く前に、仕様を一生懸命に詰めている人には作業を中断させて、戦略段階の話の明文化に注力してもらおう。デザイナーも戦略段階の話をもっと深く理解して、話を整理できるように努める必要がある。
それができれば、機能要件の優先順位が見えてくるはず・・・
評価した結果、戦略が間違っていたことに気づく場合もある。その場合は要求定義に進むのが早すぎたのかもしれない。そしたら、黙ってやり直そう。まだ、引き返せるうちに引き返そう。
ここで、メンバーの評価を「プロジェクトの完遂」に設定しているケースがある。すると、この段階で戻れない。メンバーの評価基準を見直してもらう必要もありそうだ。ああ・・・また他部署のマネージャーと、交渉しなくてはならないかもしれない・・・
それは、やっぱりUX改善の成功達成基準が明確になっていないので、プロジェクトの完遂が目標になってしまっている気がする。
デザインチームのタスク一覧
プロジェクトリーダーになる事業側のメンバーの人事評価基準を、プロジェクトの完遂ではなく、UX改善の成功測定基準を元にした内容にシフトしてもらう → 面倒臭い話だけど、これができないと下記の動きを取るのが難しそう・・・！
起案者に、詳細な仕様ではなく、機能要件をまとめてもらう
機能要求の優先度付け
デザインチームに話を持ってきてもらえるように努力する
顧客と近くで接しているメンバーに所感を聞いて回る
エンジニアにも相談する（二元論にしない、納期の確約はしない）
ステークホルダーと話す前に、仕様ではなく戦略を整理しておく
機能要求ではなく、戦略の優先度で会話する
優先度を元に、リリース単位を分ける
更新可能な必要最低限の仕様をまとめる
デザインファイルやテストケースに、詳細な仕様は記載する（リリース単位が小さい前提）
仕様を更新する
デザインファイルやテストケースへアクセスできるように、リンクを張っておく
次回：要件に対し誤った構造設計を仕様書に書いてくる人に、フィードバックをする
気軽にクリエイターの支援と、記事のオススメができます！