Konboi Note

ふわっとした仕様を合意をまとめて固める 技術

· Konboi

はじめに

先日会社のイベントで表題について話をしました。せっかくなので一部修正してブログで公開します。

ふわっとした仕様とは？

ふわっとした仕様というのにもいくつかフェーズがあると思います。

  • そもそもの課題を考える状態
  • 解決したい課題がはあるが具体的な案はまだない状態
  • やる施策は決まっているが実装の詳細が詰まっていない

今回は 解決したい課題がはあるが具体的な案はまだない状態,やる施策は決まっているが実装の詳細が詰まっていない に関して自分がどう合意をまとめて固めているのかを紹介します。

見えている景色が違う

紹介の前に、ロールやポジションによって見えている景色や感じている課題感が違うというこを意識しましょう。
優先順位やスケジュール感。何からやるのか、どう進めるか。など考えていることは違います。

なので違っている認識を合わせること、目線を合わせる事がふわっとした仕様を固めていく上で最も重要になります。

なぜ最初に目線を揃える事が大事になのか

ではなぜ最初に認識を揃えることが大事なのでしょう。
結論から言うと、修正のコストを最小限に抑えるため だと自分は考えます。

少し強引かもしれませんが、山登りをイメージして見てください。

”頂上の写真を撮ってきて”となった時に登り初めに「右の山? 左の山？？」と確認してから山頂までの工程を軌道修正するのと、頂上付近で「この山で合ってるよね? もしかしてあっちの山だった??」と確認してから軌道修正するのでは修正のコストが段違いになるのがイメージできると思います。

ふわっとした仕様の状態というのは、どちらの山を登るのか、どういうコースで登るのかが決まっていない状態をイメージするとわかりやすいかもしれません。

実際の開発の場合には

  • 解決しようとしている課題に至るまでの仮説自体が間違っている。
  • 解決しようとしている課題は正しいがそこまで重要で無い。
  • 課題に対する温度感、どれくらい重要なのかが伝わっていない。

ということがあるので、間違ったまま進まないためにも認識を合わせる必要があります。

これが 仕様 → 設計 → 実装 → テスト と後のフェーズになればなるほど戻って修正するためのコストが大きくなるのは安易に想像できるかと思います。

登る山の間違いに気付くのは登る前に気付くのが一番いい。(ですよね
際の開発でも早い段階で、進む方向、進み方の共通の認識を持てるのが理想です。

どうやって目線を揃えるか

これは細かいテクニックはあるかもしれませんが、泥臭くやりとりするしか無いと思っています。

参考までに、自分がどうやっているか/何を意識しているかを紹介したいと思います。

誰に書くか/何を書くか / どう書くか

自分の場合は書く目的/相手によって重きをおくポイントを変えています。

誰に書くか

ステークホルダーは誰なのかをはっきりさせる。誰の合意を撮ったらいいのかをはっきりさせましょう

仕様の方向性を詰める場合 (to PM向)

この場合はWhy/Whatを厚く書くように意識します。この時点では

  • なぜXをやるのか
  • 課題はなんなのか
  • 何を解決したいのか
  • どういう対応が必要なのか

の認識を合わせることを意識します。

必要であればイメージしやすいように、シーケンス図や完成した場合のラフなREADME.mdなども添えます。

ポイントとしてはこの時点ではHowをあまり書きすぎない/詰めすぎないということです。
そもそもの課題設定が間違っている可能性や、検討の結果実装をしないという決定になる可能性もあるので、やる前からHowにあまり時間をかけすぎないのがポイントです。

設計や実装の方針を詰める場合 (to Engineer向け)

仕様の方向性や認識が取れた時点で、より具体的にHowを詰めていきます。

Confluenceページに書く場合もあれば、サンプルコードを書いて議論方針を議論するなど

設計/実装するサイズによって適した方法を取るのが良いでしょう。

ここでのポイントは同じく、作りすぎないこと。 設計のレベルまで遡って修正する大変さはみなさん分かると思います。

共通して

それぞれ何を書くか/どう書くかを紹介しましたが、この他にもいくつか共通して意識していることがあるので紹介します。

1点目は、採用しなかった方法も理由も書くこと。ケースによっては実現方法が複数パターン存在すると思います。
そんな時は「なぜ Z という方法を取らなかったのか」ということを併記することです。そうすることでレビュアーに別の方法も検討したことを伝えられ、議論の発散を抑えられるからです。

2点目は、課題の設定が間違っていたり議論を重ねて最初の方向性と変わってきたら改めて書き直すことです。
ページを更新してしまうと議論の形跡がなくなってしまい、なぜそのような結論に至ったかというコンテキストが失われてしまいます。あとは単純に後からきた人が追いにくい。
なので、発散してきた場合や方向性が変わった場合はその時点の内容を改めてまとめ、なぜやるのか、どうやるのか を整理するのをお勧めします。

3点目は、議論が平行線を辿っている場合は直接話してしまうのが良いです。
温度感だったり認識のずれだったりがあるのでどうしてもの時は直接話してしまいましょう。
その際、話の内容と結論を書いておくとどうしてその結論に至ったが他の人にもシェアできるのでお勧めです。

具体例

(社内向けドキュメントなのでSkip)

まとめ

色々と書いてきましたが、ふわっとした仕様を合意をまとめて固めるためには

  • 課題や手法に対するお互いの認識を揃える
  • 節目節目で目線を合わせることで修正のコストを抑える
  • フェーズによって書くポイントを変える

と言うことを意識してやっています
という紹介でした。参考にしてみてください。

矛盾することを言うかもですが、毎回毎回やっていたらコストがかかりすぎます。
課題の大きさ、重要性、関係する人数によってバランスを見ながらやることをお勧めします。