#65 今改めて考える「仕様書の価値」

00:05

おはようございます。ゼロトピック第65回目です。

今日は、ちょっとさっき散歩してたんですけど、改めて、

使用書って何のため必要なんだっけみたいなのを考えてて、

それについて、改めて考える使用書について話したいなと思ってます。

僕はね、キャリア的にプロダクトマネジメントをしている期間が、

これもう5年くらいなのかな?

やっと5年選手です。

プロダクトマネージャーとして仕事をしている。

今は、それは一部しかしていない状態なんですけど、

それでも5年くらいのキャリアがある中で、

プロダクトマネージャーのアウトプットって最終的に何かというと、

もちろんプロダクトなんだけど、

プロダクトに至るプロセスの中で、

たくさんのドキュメントとか、あるいはFigmaみたいなUIのプロタイピングとか、

そういったものを作ることが自分はすごい多かったんですよね。

あるいはアルゴリズムでどういうロジックにしたいかとか、

そういうものをプロセスの中でアウトプットする機会がものすごい多くて、

そういうドキュメントが会社とかいろんな場所に積み上がっていってるっていうような状況でした。

ただ、自分は喫水のプログラマーとかソフトウェアエンジニアではないので、

最終的なコーディングをどういう形に落ち着けるべきかっていうのは、

僕の中では判断できないんですよね。

なので、そこについては一切の言及をしなくて、

当時から昔から信頼できるソフトウェアエンジニアに背中を預けて任せるっていうスタンスで、

その中で自分の役割どこかっていう点で考えたときの仕様書みたいなのを組み立てることが多かったです。

なので、僕の仕様書、確かに記事でもいくつか公開しているものがあるんですけど、

どういうことを特に強調しているかというと、

なぜこの機能が必要なのかとか、これによってどういったことを狙っているのか、

あるいは何が10Xなのかっていう、社名通りですね。

要は非連続性をどうやってユーザーにもたらすのかとか、

そういう観点からまず入って、

そういう背景があるから、

あとはその補強するデータとかをつけて、

例えばこういうKPIが今こういう繊維をしているとか、

訂正的なN1インタビューとかユーザビティテストするとこういう事実が分かってきたとか、

03:02

この事実の中にあるイシューを解決したいっていう、

そういう補強の材料をつけた上で、

あとはフォワットですね。

具体的にプロダクトにどういう状態、変更を加えたいというか、

差分をもたらしたいのかっていうことを書いています。

例えば、何だろう、分かりやすいの、分かりやすいの。

公開している仕様書の中に、

たべりっていうプロダクト、一つ目に10Xで作ったプロダクトの

グループ共有機能っていう機能の仕様書を公開したことがあるんですね。

その仕様書の中には、ちょっと今何て書いてあるか分からないですけど、

その時に狙っていたことっていうのは、

食って、我々のターゲットにしている、

世帯を持たれているユーザさんにとっては、

もちろん栄養摂取するためのものでもあるんだけど、

家族で一つの宅を囲むっていう機械になっているケースがすごい多い。

なので、今日のご飯を何を食べるのかっていうコミュニケーションって、

割と1日何回か頻繁に発生するようなコミュニケーションであるっていうのが、

僕らが知っていたファクトですと。

ただそのやり取りっていろんな場所で行われていて、

LINEでやってたり、コートでやってたり、

積み上がるものがないっていうので、

あとは気づかなかったりするっていう、見逃してたり、

そういうのを防ぐっていうのを一つの目的にして、

なので、そこを通じたコミュニケーションがアプリの中に内包できることによって、

ユーザーのエンゲージメントを高めたり、

必要性をもっと高めていくっていう、

そういうアプローチをしたいっていうのが、

確かホワイに書いてあったこと。

ホワットとしては、ユーザーAがB、C、Dを招待できる。

そうすると、AとBとCとDのコンダテっていうものが、

作ったコンダテ、アプリの中に生成したコンダテが完全に共有される。

誰かがコンダテを作ったりしたら、通知が飛ぶ。

通知が飛ぶことで、相手に知らせるっていうコミュニケーションを一つ省けるっていう。

あるいは、コンダテをシェア、

自分が作ったものをLINEとかで共有できる機能もあったりして、

共有するっていう、どうしてもLINEでやったほうが便利なケースとかあるんで、

そのLINEのコミュニケーションの上に、

タビリの中で生成されたコンテンツをスムーズに載せるっていう、

そういったことをホワットとして掲げてたと思うんですけど、

これをどうやって実装するかとか、どういうデザインにすべきかっていうのは、

この時点では僕はプロダクトマネージャーとしては一切言及しないんです。

ハウの領域については圧倒的に現場のプロに任せるべきっていう考えが昔からあったし、

あとは僕はソースコードをすべて読んでるわけではないので、

現状のソースコードから受ける制約とか、

あるいは自由な領域ってどこなのかっていうのは、

06:01

自分が判断するのは無理というか、精度がめちゃめちゃ低いと思っていて、

それこそ任せたほうがいいというふうに考えてるんですよね。

あとはその実装の戦略っていう、

ユーザーストーリーから見たストラテジーはもちろん大事なんだけど、

プロダクトを長期的にどうしていくかっていうプロダクトのストラテジー、

実装のストラテジー、テックのストラテジー、

そういったストラテジーの中で、

そこの実装をどうすべきかっていう、

要はソースコードをどう設計すべきかとか、

あるいはやりたいことはこうなんだけど、

実際にはその機能を作らずに考えながら、

やりたいことはこうなんだけど、

実際にはその機能を作らずに完了できるケースもあるわけだったりするんですよね。

それはそのほうが絶対ベストで、

ベストだったり、もしくはできるだけライトな形で収めて、

実験的に始めることがベストだったりっていう、

いくつかのストーリーというかストラテジーのラインの高点に、

ちゃんといいものを作るっていう意味では、

それはそれで、

包括性というか、

プロに情報集約させて判断させるっていう、

判断してもらうっていう、

そういうプロセスが絶対必要だなというふうに思っています。

なので僕は口を出さないというか、

もちろん議論だったり、

壁打ちだったり、

よりユーザーベースでの解像度が必要なときに、

できるだけコメントをするんだけど、

それをどうやって実現するかっていうことについては、

かなり背中を預けて任せてるっていうスタイルでした。

という形なので、

僕の仕様書ってホワイトかホワットをとにかく、

ちゃんと書くっていう形で、

最近は仕様書は作ってないですよね。

仕様書というか、

GitHub Issuesで開発タスクを管理してるんですけど、

その中に Issuesを立てて、

ホワイト、ホワットをしっかり書く。

ハウはその先、エンジニアとかが結構自由に設計して作ってくれて、

ホワイトかホワットを擦り合ってるんで、

出てくるものの違和感がゼロ。

クオリティもすごい高いっていう状態が、

創業してから3年ぐらいずっと続いてるかなと思っています。

っていうのが今までやってきたことで、

ちょっとこれ振り返って思うに、

結構ベストな状態だなっていうふうに思ってて、

なぜかというと、

いわゆる受託開発とかSIが、

SI屋さんが作ってるような仕様書って、

現状ガチガチに全部日本語で記載した、

この状況から1ミリもブレはありませんっていうものを、

作って収めるっていうのが、

受託開発、受注と発注の関係の中では、

往々にしてあったんですよね。

すごい複雑なシステムだったりを作っていく中で、

そこに不確実性をできるだけゼロにしようっていうアプローチですね。

システムの不確実性とか、

暗黙値をゼロにして、

09:01

我々はちゃんとこういうものを作って納品したんです、

っていう証明書として、

あるいは合意形成のためのツールとして、

仕様書を活用してきたっていう背景があったりするんですけど、

これと僕らのアプローチは全然違いますよね。

僕らは逆で、

不確実性は絶対に残り続けるというか、

むしろ増え続ける。

外部だったり、

ユーザーが置かれてる環境とか、

いろんなものが変わってくるので、

不確実性が絶対にあるっていう中で、

開発のアジリティを絶対に落とさないっていうことが、

開発のプロセスにおいてすごい重要なこと。

プロダクトを作っていくとか、

検証していくっていうことにおいて、

アジティティがすごい重要。

スター

メッセージを送信

Yamoto Masatake

スター

コメント

こちらもおすすめ