00:00
国垣さん、何らかのプロダクトを作っているときに、例えば、フォームが空の状態でボタンを押したときの挙動を
PDMとかビジュエンショクの人に分からなかったので聞いたときに、なかなか返答が返ってこないだったりとかあるかなと思うんですけど、
そのときにですね、大体こうだろうみたいな、実装してみたら、全力でこう違うと言われて、直して、直したみたいな経験があったりするんですけど、
これって何が原因だと思いますかね。PDMの方とかに対するコミュニケーションの問題だったりするんですかね。
いいですね。それ実はコミュニケーションの問題じゃないんですよ。これ、仕様書の問題なんです。
私が特に最近のソフトウェア開発の現場で問題だなと思うのは仕様書なんですよね。
仕様書に書かれているべきことが書かれていないことが多いと思ってます。
でもちょっと一度立ち止まって、まず仕様って何なのかとかどうあるべきかから一歩ずつ考えてみて、
そこで皆さんと私たちの間で、仕様ってこうじゃなきゃいけないんだなっていうことをだんだんと理解していきたいなと思います。
実は世の中に仕様って呼ばれるものはたくさんありますね。
今まで昨日読んだ仕様書とか、あるOSSの仕様書とか、いろんな仕様書があると思うんですよ。
そういうふうにいろんな定義はあるんだけど、その中からなるべく有用なものを選んであげるっていうのが実は一番大事なことなんですね。
つまり仕様書って概念は一つじゃないんだけど、その中から一番私にとって得だというものを選びましょう。
それが大事ですよね。
一旦それを考えるために、まずはちょっと皆さんこれまで読んできた仕様書とかプロンプトとか、
プロンプトってAIに対して仕様指示してるみたいなものですよね。
これとりあえず忘れてください。真っさらな状態で考えてみましょう。
仕様書って誰が何のために使うんですかね。
仕様書誰が何のためにって聞かれると、
例えばエンジニア目線だとプロダクトを作るときにエンジニアがそれを見て、
どういう振る舞いが定義されているかだったりとか、
どういう振る舞いを期待されているのかみたいないうのが書かれてるんですかね。
そんなものを仕様書と定義してる気がしますね。
実はそれは本当におっしゃる通りだと思うけど、ほとんどの仕様って概念はこの振る舞いの定義にフォーカスしてるかなと思うんですけど、
ただ実は一番危ないなって思う部分がこの振る舞いって一体何なのかっていう部分なんですね。
振る舞いってこれ多分人によってかなり分かれるかなと思うんですけど、
異常系の動き、例えば先ほどの話だとフォーム空の状態でボタンを押したときの挙動って結構異常系に近い気がするんですよね。
これってどうすべきですか。仕様書に書くべきですか。
これは結構人によって意見が変わるんじゃないかなと思ってるんですけど、どうでしょう。
いや確かにそうだろうなと思います。そこまでケアするのみたいな。
そんなこと言い始めたらじゃあインターネットにつながってないときはどうするのかだったりとか、
JavaScriptが動いてないブラウザだったらどうするのかみたいなところまで仕様書に書かれるべきなのかみたいなところまで及んじゃうかなと思うので、
03:02
線引きが結構難しいなと思いますね。
そうですね。おっしゃる通りです。どこまで書けばいいのかって書いたらめっちゃ長大になっちゃって人間が読めなくなっちゃうんじゃないかって心配をみんな抱えてるんじゃないかなと思います。
はい、それは本当にその通りです。ただちょっと今まずは一旦誰がどう使うか。
今エンジニア目線でヘントコさんはお話ししてくれたと思うんですけど、実は仕様書を使う人は他にもいるかなと思っていて、ちょっとずつ話を広げていこうかなと思います。
まずエンジニア目線だと何をどう動くのか、実装したらいいのか、どういう実装が正解なのかってことを教えてくれるのが仕様書でした。
実は仕様書のもう一つ代表的なユーザーは検証者、テスターですね。テスターの人たちはテストケースとか作って、実際アプリとかいろんなものポチポチとかしたりとか、あるいはハードウェア作ってる人たちだったらオシロスコープとか持って検査したりするかもしれませんね。
そういうふうにテスターの人たちもこれ何が正解なのってことを知らないと、これは間違ってますとかってことはなかなか言えないってことがあるので、
実はテスターの人たちにとってもこの仕様書ってすごく大事。つまり今の時点で実装者と検証者、この2つはすごく代表的なユーザーであるってことが分かりますね。
あとは例えばCSの人とかも結構大事かなと思って、CSの人たちってお客さんから、これってこうなっちゃったんだけどどうしてって聞かれること多いと思うんですよ。
それが例えばある会社とかだと仕様ですみたいな答え方になっちゃうと思うんですけど、仕様ですとは一体何なのか、本当に仕様なのかっていうのが結構あると思うんですよね。
それを答えるために、つまりお客様、エンドユーザーからの質問とかから答えられるために正解のことを知っている必要があるっていうのもまた仕様の使い方の一つ。
なのでこれをまとめてみると結局ヘンテコさんが最初言った通り、どう振る舞うのか、何が正しいのかっていうその正しさの基準が仕様なんですね。
ここまでは皆さんで大雑把には合意できるところかなと思います。
今の話でいうと、どう振る舞っているのか、あとは振る舞いの列挙からどう使うのかですよね。
エンジニアだったらそれを実装していくし、テスターの人だったらそれを使って正しい振る舞いがされているかどうかを検証していくし、
CSの人だったらその振る舞いが仕様かどうか聞かれたときにその知識としてちゃんと答えられるようにしておくみたいなところが仕様書の使い方みたいなところなんです。
現時点においては。
そうですね。何事もそうなんですけど、何かのフォーマットとか仕様に何を書くかってことを考えるときにはどう使われるかってことを想像しないと、
ちゃんとそれに使われ方に耐えられるようなフォーマットになってないといけないわけですよ。
だからまずはどう使われるのかってことを想像します。
そうすると、いずれのケースにおいても正しい挙動っていうのがかなり細かくわかることが理想だというのがわかるかなと思います。
エンジニアにとってもさっき言ったようなフォームの体の状態でボタンを押したときの挙動を質問しなきゃいけなくなっちゃったのは、
仕様書に書いてなかったからですよね。それで適当に実装してみたら後で違うって言われたってことは正解あったじゃん、書いてないじゃんって話になって、
06:04
仕様書としてはダメだった。だから私は仕様書の問題だって言ったんですね。
なるほど。これは仕様書の問題じゃなくて、プロダクトだって同じかなと思うんですけど、
エンドユーザー、使う人のことを考えて、使う人がどうやって使うのかまで考えた上でまとめるというか、
簡便に使えるようにするっていうのが大事だよねっていうところなんですかね、仕様書に関しても。
実は仕様のフォーマットと同じように、ある仕様のフォーマットで書いたとしてもいろんな仕様って考えることができるわけですよね。
例えば皆さん日々ソフトウェア開発して仕様をアップデートしていきながらお客様にとって有用なサービスを届けていくってことをするわけですけど、
これ実は仕様を探索しているっていうことなんですね。どういうことかっていうと、今までの仕様でお客様が例えばこうしてほしいですとかって不満が出てくるわけですよ、仕様を使ってると。
フィードバック的な。
それをもらって、よしじゃあ直そうと思って仕様を変えて、実装し直して、検証し直して、またリリースするってやってるってこと。
これ実は何をしてるかっていうと、より良い仕様を見つけようとして、仕様がいっぱい置いてある空間をさまよってるっていうのがまさにサービス開発の苦労数の部分に当たるんですよね。
我々はあるフォーマットを決めて仕様を書くわけですけど、その仕様をいろいろ探している人たちなんですよ。
っていうのがすごく大事な一つです。
普遍的なものではないってことですよね。
変わっていくものを使用は絶対的にアップデートしていくものだよねっていう大前提があるってことですね。
この変わっていくものっていうのをどう書いたら一番いいのかっていうのがこの仕様書の革新なわけですよ。
つまりどういうフォーマットで書いたら今まで言っていた開発者だったりだとか実装者だったりCSの人たちだったりそういう人たちが満足できるものになるか。
っていうのが大事なわけですね。
私はこのフォーマットがすごく大事だと思っているって感じですね。
使いやすくありアップデートもしやすいっていうフォーマットが一番重要なんじゃないかっていうところ。
ただ今の世の中のフォーマットをいろいろ眺めてみるとよく最近使われているのはPRDとかよく使われてますよね。
聞いたことあります。
PRDってよく使われてるんですけどPRDはセクションぐらいしか定義されてなくて
なかなか書きやすくはあるんだけど読みたい内容が書かれないことが多い。
こういうセクションで書いていくといいよという性立てはあるけどその中身についてのフォーマットは結構自由だよねみたいな感じなんですねPRDが。
ここがすごく難しい部分なんですよね。
ちょっとまた少し落ち着いてみてエンジニアとして考えてみるとボタンがあったときにフォームがあったときに
フォームの空の状態ってあったってことは空じゃない状態もあるわけですよね。
そこに対してボタンを押すってことは何らか状態とUIのイベントみたいなものっていうのが今登場してきているのがわかります。
09:02
つまり使用書にはこの状態とイベントっていうのが登場しないとおかしいですね。
なので使用書には絶対この状態とイベントっていうのが書いてあるんです。
ただ状態って言われちゃうとそれ実装じゃんって思っちゃう人たちもいると思うんで
あくまでこう考えるっていいよっていうのは
イベントってある時にはこのイベント出せるんだけどある時にはイベント出せないってよくあるじゃないですか。
例えばフォームが空のときだけサブミットボタンがディセーブルになっちゃって
サブミットできないようにするとかってないじゃないですか。
つまり空の状態のときはサブミットイベントは発生できない。
だけど空じゃないときはサブミットイベントが発火できるっていう風になっていて
で どのイベントが今発火できる のかっていうふうなことを その
区別のためだけに仕様の状態を 持ってみたいなイメージを持って
もらうのが一番いいかなと思います これは実装の状態とは何ら関係
がなくて あくまで大事なのはイベント っていうのを どの状態のときに
起こせるのか これのときに起こ せなくなるのか あるいはどういう
順番で起こせるのか これが実は 仕様書の確信なんです
おだしょー なるほど 今聞いてる 感じだと 疑似コードみたいな感じ
のが出てきそうだなと思っちゃ ったんですけど 実装とは別の状態
管理というか 実装をこのままして ほしいわけじゃないけど 若干
ステートみたいなところも仕様 に盛り込まないといけないっていう
感じになると 何でしょうね フローチャート だったりとか あとは疑似コード
みたいないうところが出てきがち なのかなと思ったんですけど そう
ではないですか
おだしょー 鋭いですね 実はその通り なんですよ 実はちゃんとよく書かれた
仕様っていうのは ほとんど疑似 コードみたいな形になることが
多いです 疑似コードになって れば 正解 これ正解ですか これ正解
じゃないですかって 疑似コード 見れば分かるんですよ つまり 質問
が発生しないって意味で 先ほど 言った 質問発生しちゃって 正解
あったんかいみたいな話とかって あったじゃないですか それはもう
正解があったんかいみたいなのは 全部そこに書かれてる 誤解なく
書かれているわけなので 実は 仕様書としては 疑似コードみたいな
で書かれるとか 実は一番嬉しいん ですね
おだしょー それはエンジニア にとって 疑似コードとして書か
れてることのほうが嬉しいよね
おだしょー 嬉しい で もしテスター さんとかも 疑似コードを読む
スキルがもしあれば 疑似コード であるほうが テストケース作る
の楽なわけですよ あれ このケース ってどうなってるんだっけって
PDMに質問しなくていいわけです から 楽なわけです 今 エデデイム
あるじゃないですか エデデイム に疑似コード加わせて このとき
どうなりますかねって聞くと 教えてくれるわけですよね だから
ソフトウェアエンジニアじゃなくても 疑似コードみたいなものをみんな
が読み書きできるって世界が 今 もうここにあるわけですよ だから
それを活用すると 実は仕様書 って疑似コードみたいなやつが
一番いいんじゃないって結論に 私はなると思うんですね
おだしょー なるほど 結論なんて 言うんですかね プロダクトの
コードを書くわけじゃないんだ けども 一番書きやすい疑似的な
コードを 仕様書では書くべき っていうところなんですね
おだしょー そうです
おだしょー 結局のところ
12:00
おだしょー そう聞くと 皆さん 本当にこれ100パーセントを予想
できるんですけど 皆さんそう 言うと それ 仕様じゃなくて実装
じゃんって みんなから言われます なんだけど よくよくちょっと考えて
ほしいんですけど じゃあ 実装 と仕様の違いって何ですかって
逆に私は質問したかったんですね 寺田さん 実装と仕様の違いって
何だと思いますか
寺田 そうですよね 仕様書っていう フォーマットというか 何て言うん
でしょうね プログラムを書く 前のあらいら風みたいな感じで
現状 現時点では日本語だったり とか 自然言語で人間が読み書き
しやすいような形で書いてます けど ただ単にそれが実装に起こ
されたとき っていうか おそら くなんですけど 理想では仕様書
がプログラムになってればいい 話なので そもそも動けばいい話
なので そう考えると ほぼほぼ 同一というか 同一になっている
べきかもしれないなと思います
おだしょー なるほど 実は差があるん です ここは少しだけ気づきのポイント
としておきたいんですけど ほぼ コードみたいな仕様書をエンジニア
が渡されたときに まさかに思う のは 実装の自由度ないじゃんって
思いませんか
寺田 確かに そこまでガチガチに やられちゃった
おだしょー そう ガチガチにやられ ちゃったから このライブラリー
使えば もう今日のやつ これ1秒 でこのタスク終わるのに ライブラリー
が使えない ちょっとだけ違うから っていう理由で ってことは でも
実際 仕様書はほんとそれでも問題 ないことが多いわけですよ この
ライブラリー使おうが 使わない が 実は大丈夫だってことが多い
ってことは 実は実装の振る舞い っていうのは 一つ実際に動いて
こんなふうに振る舞うよって かなり 具体的なものが分かるんだけど
仕様っていうのは 実装の動きの ここら辺までだったら許すよ ここ
から ちょっとダメだねっていう ふうに範囲を支持するものなん
ですね
おだしょー やっぱり境界を示す ものってことですかね
おだしょー そうです 境界を示す OKかNGかの境界を示すものなんです
なので 実装と仕様はちょっと違うん ですね 実装は動いて 実際にその
状態遷移とかをしていって イベント を出してくれるものではあり 仕様
もイベントを出してくれるもの ではあるんだけど 仕様側のほう
が広いんです ほんとに範囲 これを 出さなくてもいいよ 出してもいい
よとかっていうことを言える のが仕様 実装は出してもいいよ
出さなくてもいいよなんてことは ないわけですよ どっちかどっち
かにしか決まらないことになる わけですね っていう意味で 仕様
は曖昧に書ける そして実装は 曖昧ではないっていう違いがあるん
ですね
おだしょー 確かに 仕様書にこの APIは500ミリセックで返してください
って書かれないってことですよね 500ミリセック以内で返してください
は書かれるけど
おだしょー そうそう でも500ミリセック それもちょっとなかなか議論を呼ぶ
ところではあるんですが そんな 感じです あとは 仕様書にはもう
一つちょっと重要な概念があって 例えばFizzBuzz関数って 私FizzBuzz
関数大好きなんで 何度でもFizzBuzz 関数をこするんですが FizzBuzz関数
15:02
って 1以上の数についてはどう振る まうか分かりますよね 皆さん分かる
わけです 123 123Fizz 34Buzzみたいな 感じで分かるわけですけど 0以下
の数に対してどう振るまうべきか って思います
おだしょー 書かれてないので分からない ですね
おだしょー そうなんですよね だから これが実はさっき言った
実装の曖昧さなんですね その書いてない 部分についてはどう振るまっても
いいよ あなたたちの自由だよって こと言ってるわけです この自由
って中に含まれてるのはいろいろな 話があって 無限ループして停止
しなくてもよし エラーになって もよし クラッシュしてもよし なんか
適当な数値返してもよし みたいな こんな感じで自由です
そういういろんな実装があるわけ ですよ いろんな分級入れて0以下
の時にいろんなことができるわけ なんですけど それをどうやっても
これはOKだよと言ってるっていう 意味で
おだしょー なるほど
おだしょー そう ここまでは正解 のラインがある こっからはどっち
でも正解だよみたいなラインが あるっていうふうに仕様の曖昧さ
っていうのは決めて組み立てて いくものなんですね
おだしょー なるほど じゃあ冒頭で 僕が言った 空の状態でボタン
を押した時の挙動って自由ですよ ね 書かれてないんだから
おだしょー そう 書かれてない から自由
おだしょー 自由にしていいから 何かいい感じに実装したんだけど
違うって言われて直したっていう のは何だかなってことですね つまり
おだしょー そういうことです だから仕様の問題だということ
ですね 本当は仕様がちゃんと決め られてなきゃいけなかったのに
決まってなかったね それを後出し でこういうのはずっとずるいよ
って話なわけですよ
おだしょー なるほど いや確かに そう考えたら 自由なかったじゃん
そこにみたいな感じですね
おだしょー そうです 実はプロ の仕様記述者ですごく意識する
のは この自由度っていうのを 上げすぎない 下げすぎない ちょうど
いいところに保つってことにすごく 力を使わなきゃいけないんですね
おだしょー めちゃくちゃ難しい ですよね それは
おだしょー 難しいですよ どっち 両極端
だめなんですよね 何でかっていう の ちょっとこれも試行実験なんで
仕様をどんなものなのかって考える ために考えてみましょう 仕様が
きつきつすぎるとだめだっていう のは 先ほど話したところですね
実装に自由度がなくなっちゃって 本当はこうやったほうがこうする
と激減できるのに いちいちちょっと 違うところのためだけに しかも
どうでもいい違いのためにライブラリー を使えなくなってしまったみたいな
そういうことが起きてしまうから 仕様をきつきつにすると良くない
じゃあ 仕様をガバーにすると何が 起こるんでしょうって話ですね
おだしょー もうぶっ壊れますよね ぶっ壊れてるっていうか 当初予定
していたプロダクトではないですよ ね
おだしょー そうですね じゃあ一番 緩い仕様って何なのかっていう
のをちょっと考えてみましょう 一番緩い仕様って何だと思います
か
おだしょー 仕様書ないパターン じゃないですかね あっさりすく
おだしょー そう あっさりすく 何でもいいってわけですね それが
一番仕様の自由度が高いバージョン になっていて ここから一番きつい
バージョン ほぼ実装みたいなところ の中の 中間ぐらいをうまいこと
選んだといけないんですね これ めちゃくちゃ難しいんですよ だって
今 PDMとかの人たちがよく仕様書 書いてますけど 実装のこと 彼ら
あんまりよく分かってないことが 多いと思うんですね だから狭
18:00
すぎちゃいけない きつきつすぎる と困るよってことを 彼らは知らないん
ですよ かといって これをガバガバ すぎるときに何が起こるかって
こともあんまり想像がついていない っていうところがあって 私はよく
こう思わざるを得ないんですね PDMに仕様書を書かせるのは間違
ってるんじゃないって
おだしょー エンジニアが仕様書を書くべき
である
おだしょー そうなんですよ だって 疑似コード エンジニアが書ける
じゃないですか 読み書きできる 今どきだったら テスターの人も
PDMの人も仕様書に対して質問を LLMを通して投げることができる
わけですから エンジニアが仕様 を書いて PDMやテスターの人たちは
エンジニアが書いた仕様書をもとに いろいろなことをする
おだしょー これは特にどっちか みたいなの
あったりするんですかね 新規で プロダクトをゼロから立ち上げる
ときの仕様書と あとは既存の システムがありきで その中から
新しい機能を追加ないしは 変更 するときの仕様書みたいなので
どっちが結構難しいっていうのは あったりします
おだしょー 圧倒的に後者が難しい ですね 大抵 どの組織でもそう
なんですけど 仕様書がちゃんと してないことが多いんですよ 正解
が分からないことが多い 私が見て きて正解が分からないには 代表
的なパターンが2つあります 一つ は 仕様がさっき言った曖昧すぎる
パターンですね 何が正解なのか 分からないみたいなのがあるっていう
パターン これは多くの組織で 共通してることなんですけど もう
一つ良くない傾向があって 仕様 が差分で書かれているっていう
のがあります
おだしょー 差分で書かれている
おだしょー これは 例えば 皆さん ジラとか チケットのトラッキング
システムを使って実装していく じゃないか このユーザーストーリー
実現するみたいな感じで
おだしょー タスク単位でとか
おだしょー そうですよね ユーザー ストーリー実現するって言ってる
んですけど ユーザーストーリー に関係ない部分は維持なわけですよ
ね ユーザーストーリーに関連 する部分だけ書いてるわけです
それで開発が1年ぐらい続きました じゃあ ユーザーストーリーが
100個実装されました 仕様は何ですか って聞かれたときに そこにはユーザー
ストーリーだけがあるんですけど それはどう振る舞うんだって 全く
分からないっていう
おだしょー 情報が分散されてる というか まとまったマスターで
マスター仕様書がないってこと ですね それは
そうなっちゃうんですよね そうなっちゃうと やっぱり困って
しまうっていうのがあって 特に 後者のパターン 既存のシステム
があるパターンは どっちかの 症状に苦しんでることが非常に
多いんですね こっから何とか立て直す ってなるのは やっぱりすごく
難しいっていうのが現実です
おだしょー すごい難しいなと思う 本当に既存のシステムがあるとき
に対して 既存のシステムの内容 今の設計だったりとか コードの
書き方というか あとは使ってる ライブラリー 細かいとこだったら
ライブラリーだったりとか書き方 だったりとか そういう諸々を知って
いたほうが 仕様書を作るときに 書くときに そういう知ってるエンジニア
と知らないPDMだったら 知ってる ほうが仕様書のレベル感というか
21:04
成果度合いっていったら エンジニア のほうがいいんじゃないかっていう
ような感じなんですかね
おだしょー ここでは実は 仕様書 の品質ってものになるんですね
エンジニア書くほうが 私は品質 が高くなるというふうに考えて
いて それ なぜかというと 仕様 っていうのは 実装を入れると
正解 いや ダメっていうのを判定 してくれるものだったわけですよ
ね これが よく分かんない どっち とも分からない 質問しないと
分かりませんになっちゃうと 品質 が低いってことなわけですよね
往々にして PDMの書くものっていう 書くものたちっていうのは やっぱり
どっちともつかない 分からない っていう答えが増えてしまう そういう
意味で やっぱり品質があんまり 良くないなって思うことが多いん
ですよね それに比べて エンジニア が書く場合には 過剰とも言うべき
か分からないですが 正解か不正解 かっていうのは 結構ちゃんと判定
してくれることが多いと思います なので 私はその意味で 仕様書
はエンジニアが書いたほうが品質 が高くなりやすいんじゃないかな
と思うんですね でも ちょっと ここでPDMの人たち 私 擁護したいん
ですよ これは私 PDMの人たちが 仕様書くロールだと勘違いされてる
のが良くないと思ってるんですよ
おだしょー そもそもそういうの じゃないよねっていう
おだしょー そう そう 彼らには 実はもっと大事な仕事があった
はずなんですよ 仕様書を書くっていう のは 割とサジだと思っていて 彼ら
はお客さまの代理人である必要 があるわけです ユーザーが これは
美味しいと言うと思うよ これは まずいと言うと思うよ その感性
を研ぎ澄ませることに 本当は全力 を尽くしてほしいわけですね エンジニア
は こういうふうな料理 作って みたんですけど 仕様の段階でまず
出すわけですよ 料理のスケッチ を書いて どうですかねって言って
これはダメですよ 美味しくない 美味しくないです お客さん 絶対
美味しくないって言うと思います これをPDMに言って あとダメかって
スケッチ書き直して これどうした ねって言って これだったら いいん
じゃん 美味しいって言ってくれる じゃんって言ったら よし じゃ
この料理作りますって作って持って くる こういうほうがうまくいく
と思いませんか
うまくいきそうですね 今の 話聞いてたらジブリを思い出しました
ね ジブリってプロデューサーと 監督が宮崎駿監督だったり分か
れてると思うんですけど プロデューサー とエンジニアである宮崎駿のやり取り
なのかなとか思いましたね 市場 の動向というか こういうのが受け
そうみたいな言うなのと あとは それとはちょっと切り離して 監督
がいいものを作っていくみたいな そうなんですよ なので 私はPDMは
本当に今のジブリの話で言うと 鈴木 プロデューサーだってほしい
わけですよ なので そのために何が必要かって
いったら 彼らは仕様を書いてる 時間があるんだったら お客さま
のとこに実際に向かってユーザー インタビューしたりだとか あるいは
Google Analyticsみたいなデータを年 から年中調べて 仮説を立てたり
だとか そういうことに時間を 使うほうが有益なんじゃないかな
と思ってるわけです そっからエンジニア は こんな感じの作ってよって
言われたらよりはスケッチを書いて そのスケッチの段階で見せて そこの
24:02
スケッチの段階でおおよそ実装 こんな感じのものがいいと思ったら
それを実装する そして検証する っていうほう サイクル早いですよ
ね
三沢 いや 絶対に そっちのほう がいいですね 確かに 区分けとして
はっきりしてるというか 分かり やすくあるなと思いますね BDM
がユーザーの代表 で エンジニア がものを作って ちゃんと提供して
いく代表みたいなところですね
おだしょー そうですね 実はこれ と話を聞いてると いや でもうち
アジャイルだしなとかっていう ふうに言う人たちも結構出てくる
かなと思って でも 使用書とか アジャイルとかだと別にねみたいな
こと言う人結構多いかなと思うん ですけど 実はそことも少し関連
があるので ちょっと話を広げて みようと思います アジャイルも
またこれもバズワードなんで いろいろな定義がある言葉ではあるん
ですけど アジャイルのマニフェスト までちょっと遡って話をしよう
かなと思います アジャイルって アジャイルマニフェストっていう
のをぶち上げた人たちがいて その 人たちの課題感は何だったかっていう
と ソフトウェア工学でいろいろな プロセスとかツールとか 使用書
効果系みたいなとかっていうの をめっちゃガチガチにしたら
いいもんできるんじゃねえかっていう ふうに思って作られてたわけです
当時 つまりソフトウェアはかなり 製造業だと思われていて 製造業
ってことは 品質を厳格に管理して その手順どおりにやれば うまく
いくものが量産されるに違いない と思われていた
おだしょー 工場精査みたいな味 でってことですね
おだしょー そう そう そう そう なんだけど 実際はうまくいかな
くて なんか形外化しちゃったとか 強上化しちゃったとか 原理主義
になっちゃったみたいなところ が結構あって このツール別に使う
必要ないのに なんでこれ使わされて るんだろうみたいなところが そういう
フラストプレッシャーがめっちゃ 溜まって そういう重厚なものは
俺たちにはいらない もっと軽量 である つまりアジャイルである
っていうものを俺たちはいくんだ っていったのがアジャイルマニフェスト
の人たちです 彼らは顧客の言ってる ことっていうのを 実はプルタクト
レビューとかのときに 実際に製品 を見て触ってもらって これは
いいね 悪いねとかっていうふう に言う だから使用性なんていらない
じゃんっていうふうに進化して いった派閥なんですよ でも やってる
ことはすごく似てると思いません か 私たちはエンジニアが使用を
持ってって これどうですかね いや おいしくないねって これプルタクト
レビューみたいなもんですよね
おだしょー それを実際のユーザー にぶつけに行くっていうような
ちょっと違いはあるけどってこと ですよね
三沢 ちょっと違いはあるけどっていう のがあって なので実はここの使用
を結構ちゃんとするっていう このウォーターフォール的なアプローチ
っていうのと このアジャイルの 部分にはかなり共通点があるんですよ
これは皆さん 実はアジャイルと ウォーターフォールって水と油
みたいに思う人たちがすごく多い かなと思うんですけど 実は面白
くて それぞれが進化していった 派閥って結構似てるんですよ どちら
も実際PDMだったり 実際のお客さん だったりっていうのが使用書を書く
の苦手だよねっていうことに結構 立脚しているんですよね 彼らは
使用書とかを書かない 実物触れば 分かるだろうっていうのがアジャイル
だし さっき言った使用書をPDM とやり取りするっていうのは 使用書
27:03
レベルだからちょっとペーパープロット みたいなもんなんだけど それ見
てたら分かるでしょって言ってる っていう 同じこと言ってるんですよ
ね 結局 これは要求を出せる人 そのドミニーのエキスパートの
人たちってやっぱり使用書くのが 苦手で その人たちに重厚なツール
とかプロセスに従わせると あんまり ろくなことにならないっていうこと
を学習していると私は思っています
おだしょー なるほど そのドミニー エキスパートの人 ユーザーの気持ち
を分かる人 ユーザー自身だったり とか ユーザーの気持ちを代弁
できるような人が使用書くっていう セキュリティまで追うのは かなり
酷だろうっていうようなところ ですね
おだしょー そうですね
おだしょー もちろんできる人はい ますよね とはいえ
おだしょー そういう人はめっちゃ 単価高いんで なかなか見かける
ことも少ないかなっていうには 思いますが
おだしょー そのドメインによって は いろいろな人がいるよねっていう
ようなところですね
おだしょー そうですね 今言った アジャイルとかの流れ
っていうのも ボータフォールから 流れっていうのも 結局 実際動か
してみて それがおいしいかどうか を確かめるっていうふうに言ってる
っていう意味で 実はここから一つ 重要な仕様の こうあるべきっていう
性質が一つ分かってくるんですね それは 実装と同じように ペーパープロット
もある程度動かないといけない ってことですね おいしいかおいしくない
とかが分かるぐらいには 動いて くれる仕様が嬉しい
おだしょー ペーパープロットの 時点で ユーザーが満足できるか
どうかっていうのが分からない といけない
おだしょー そういうことです 例えば Figma のMockとかって ボタン
を押すとこの画面に行ってとか っていうのができてくれるじゃない
ですか あれ 結構 およそ分かります よね ただ ちょっと分かりづらい
のは 例えばリストがあるんだけど リストが空のときにどう表示になる
かとかって なかなか分かりづらい っていうのはありますけど ただ
ペーパープロットって結構頑張 れば そこの空のときの表示までも
作って 最初空だよねっていう ところから始まって 次にエントリー
ボタンを押すと その次の画面に 行ってみたいな スナリオを作って
あげると 実は結構ちゃんと書く ことができて そういうふうにして
あげると 結構いいペーパープロット みたいな仕様ができる 細かい
ことまで分かる仕様ができるっていう 感じになるんですね なので これ
実は名前がついていて この仕様 が動くってことは 仕様アニメーション
っていう技術なんですよ
おだしょー 仕様アニメーション という言葉が
おだしょー 言葉があるんですね
おだしょー あるんですね
おだしょー そう なので 仕様 を書いたときに 日本語で書かれ
ちゃうと 仕様アニメーション はしにくいんですよ すごく だから
Figmaであるとか 例えば シーケンス とか状態線図みたいな 指差しながら
こういうこと起こっていくよね みたいなのが分かる 仕様アニメーション
をしやすい仕様っていうのが 実は いい仕様のフォーマットだったり
します
おだしょー 分かりやすくあり 伝 わりやすいっていう仕様ですね
おだしょー そう 味見しやすい っていうふうに言うと 伝わりやすい
かもしれないですね
おだしょー ペーパープロトタイプ にしろ ペーパープロトタイプで
30:00
作ったものの仕様とカウントして いいんですね ちょっとそこが分かって
なかったりする
おだしょー ただ ペーパープロット は 異常系とかよりもハッピーパス
を重視する傾向があるかなと思 ってるので そこにもうちょっと異常
系とかを足してあげると 結構 仕様として成立するのが 私の
経験ですね
おだしょー なるほど そういう 細かいところまで含めた ペーパープロトタイプ
フィグマとかで作るライブのもの を 仕様ショットしてもいいっていう
ようなところですね
おだしょー そういうことですね なので 最近の私の研究の一つは
フィグマをもうバリバリの仕様 技術エンジンとして使っちゃおう
っていうのが 最近の私の研究で この仕様をそこで作って 仕様が
バリバリフィグマに書かれてる と 嬉しいことが実は1個あるんですよ
何かっていうと エンドツインル テストは自動生成できるんです
おだしょー ああ そこから
おだしょー そうです 例えば フィグマ のこのボタンの ID はこれだとします
みたいなことをすると このボタン を押したとき 次 この画面行って
次 このボタンを押せてって 全部 分かりますよね さっき言った
この順番でこのイベントが起こ ってってことは 全部分かるわけ
ですよ
おだしょー 確かに もう列挙されて ますよね フィグマ上のデータで
おだしょー 列挙されて この後は これが起こせるみたいな グラフ
構造みたいなのが分かるわけですね なので そこからエンドツインル
テストっていうのが自動生成できて プレライトとかで自動で起こせる
わけですね
おだしょー そんな機能あるんですね フィグマに
おだしょー これはみんな今だと プレライトMCPとか使って頑張って
やろうとしてますけど 実際はフィグマ とかにIDとかを入れてあげて ここ
に遷移するよみたいなものまで 入れてあげると 実際はそれをグラフ
ベースでたどっていく 勝手に行 ってくれるみたいなの作ることが
できれば 実はテストケースの シナリオを考えなくてよくなる
わけですね 今 私たちはテストケース を考えるとき 必ずシナリオを考え
るわけですね エンドツインル テスト実装するとき考えてみる
といいと思うんですけど まず ログインします URLのこの画面
に行きます 画面に行って この画面 が表示されました ボタンを探します
ボタンがありました ボタンを押します とかってやっていく イベントの
列のわけですよね このイベント の列っていうのが 実はエンドツインル
テストなんですけど フィグマから このイベントの列を取り出せる
わけですよ そうなってしまえば プレイラーとMCPみたいなすごい
機関銃みたいなゴツいの出さない って もうルールベースでやる
ことができる
おだしょー できそう
おだしょー めっちゃ安価にできる ってことですね
おだしょー 確かに
おだしょー 私はそれがすごくうまく いくんじゃないかなと思って ヒグマ
ベストプラクティスっていう名前 で そういうのをちょっと研究して
いる最中です
おだしょー 今 やってるんですね 実際に
おだしょー そうですね
おだしょー ちょっと試行錯誤中 っていう感じなんですね ちょっと
話が似てくるかなと思うんですけ ど 今 全部の話聞いていく中で
やっぱり1個思うところがあって 途中 出てきた仕様書はできる限り
擬似コードで書かれてたほうが エンジニアとか他の人にも嬉しいん
じゃないかっていうところなんです けど 擬似コードの最たる例が も
しかしてテストなんじゃないって 思ったんですけど
おだしょー いい質問ですね それは とってもいい質問で おっしゃる
とおりです よくテストが仕様書 だとかドキュメントだって言われる
33:00
のは それが正解を決めてるから ですよね 正解を決めるものっていう
のが仕様なんだと私は言ったと思 うんですけど テストってまさに
正解か不正解かを決めてくれる わけで 仕様書なんですよ なんだけど
すっごくスカスカの仕様書だって ことは すごく自覚しておかなきゃ
いけないっていうのがあって テスト って 例えばFizzbuzz関数のテスト
って書くときに ヘントコさんだったら 何を試しますか テストケース
おだしょー テストケース どうだろうな でも
無限にはいけないだろうから 100までとか
おだしょー そう 100までとかやります よね 100でもかなりテストしたほう
ですよね 多分 じゃあ100以降はって 言われちゃうと このテストは正解
は答えられなくなっちゃうわけ ですよ
おだしょー ですね 確かに 現実 的に実行できる範囲ってこと
ですね テストは
おだしょー そうです なので テスト コードっていう 動かせるもの
として捉えると 正解不正解を はっきり決めることができる意味
で使用なんだけど 記述されている 入力っていうのがすごく限定的
なんですね
おだしょー 確かに
おだしょー はい これは実は緩和 することができるって話はちょっと
後でしようかなと思うんですけど 普通の典型的なテストっていう
のは やっぱりテーブルドリブン であるにせよ 普通の1個ずつ手書き
するにせよ やっぱりどうしても スカスカな使用になってしまう
っていうのがあって このときの やつはどうなんだってことは結局
質問しちゃうことが多いので それ だけだと不十分だっていうのが
私からの見解ですね
おだしょー だとしても 近しい ところではあるっていうところ
おだしょー 近しいところではあります
おだしょー テストに関しては じゃあ より発展させて 疑似コード
は疑似コードでも テストの疑似 コードを書けばいいんですかね
おだしょー いいですね 実はそれに 名前がついてるんですよ 実はこれは
プロパティベースドテスティング って呼ばれていて テストケース
って 例えばひずばずとかだと 何らかの基準で これはオッケー
これはダメみたいなことを人間 が解釈してコードに起こしてる
わけですよね つまりひずばずの 場合って仕様を考えてみると 1
のときは文字列で1が返ってくる 2のときは文字列で2が返ってくる
3のときはひずが返ってくるって いうふうになってて つまり入力
の自然数が3で割り切れるとき かつ 5で割り切れるときはひずばず
3で割り切れるときはひず 5で割り 切れるときはばずみたいな そんな
感じで仕様が詰まってるわけですね なので 仕様に テスト側にこれの
ルールをエンコードしちゃって 入力はもうランダムでやたらめ
ったらやるっていうことをやる と それ 疑似コードをテストしてる
のと同じですよね つまりプロパティ ベースドテストの中に仕様のコード
が書かれている それがやたらめ ったらの入力でいっぱいテスト
されて 大体典型的に100個とか プロパティ ベースドテスト勝手に
入力選んでやってくれるんですけど テストしてくれるんで そこには
どう振る舞うべきかってことが ほぼ完璧に示されているっていう
のがあって これはほぼ完璧な仕様 と言えると思います
おだしょー 確かに もうほぼ実装 だろみたいな感じ ひずばずだったら
そうなっちゃうかもしれないですけど
おだしょー ひずばずはあんま距離 が出ないんですよ 実装と仕様
の これ 仕様と実装の間に距離 が出るいい例があるので 相当を
考えてみましょう 相当っていっぱい アルゴリズムありますよね 実装
36:03
もいっぱいあるということですね だけど 仕様はすごく単純で 何らか
配列の中に順序を比較できる要素 がいっぱい入ってると これを順
に隣を見ていったときに 前の やつよりも後のやつのほうが等しい
か大きいってことを 全部の要素 に対してやると 相当してるって
ことになりますよね つまり これが 仕様なんです 仕様っていうのは
並べたときに前の要素より後の 要素のほうが等しいか大きい それ
だけ これが仕様なんです そういう プロパティベースのテスティング
はあっという間に一瞬で書けます ね 前の要素
おだしょー それは確かに
おだしょー だけど クイックソート とかにしても マージソートとか
にしても ソートアルゴリズム自体 は結構難しいじゃないですか バブル
ソート自体も結構難しいなって 私は個人的に思ってるんですけど
なので これは結構距離が出る 例
おだしょー 確かに 実装と擬似 コードというかテストコードで
全然違いますよね やってること は
おだしょー はい 大抵は仕様の ほうが書くの楽なんですよ なんで
プロパティベースのテスティング はやる価値があると思うんですね
おだしょー なるほど じゃあその プロパティベースのテストみたいな
ものを仕様書で書けたら もしか したらいいかもしれないし Figman
みたいなビジュアルベースのテスト エンドツエンドテストの自動生成
みたいなところも もしかしたら より 今 実験中だけども どんどん
よくなっていくかもしれない その どっちを選ぶっていうのはあれ
ですかね プロジェクトによるみたいな ところなんですかね
おだしょー どっちもプロパティ ベースのテスティングなんですね
なんでかというと Figmanのやつって 例えば分岐してることとかある
わけですよ ボタンが2つあるとき って どっちを押してもいいわけ
じゃないですか でも 実際 テスト 実行するときには どっちか選んで
実行しなきゃいけないわけですよ つまり 入力で起こすイベントを
やたらめったら選んでるわけですね そこで実際のグラフ構造と見比べ
て この遷移はしてよかった遷移 なの したらだめだったのとかっていう
のを調べているので これもプロパティ ベースのテスティングなんです
おだしょー なるほど じゃあプロパティ ベースのテストなんですね 書く
べき仕様というものは
おだしょー ただ 実際 プロパティ ベースのテストまで書かなくても
十分なことも結構あって 実際に プロパティ ベースのテスト書く
と合格か不合格かっていうのは すぐ分かっちゃうじゃないですか
そうじゃなくて 実装入れないと 分かんなくなっちゃうんですけど
そうじゃなくて 大雑把にこういう ふうなこと このイベントの次には
このイベントが起こせて この次 のイベントにはこれが起こせて
みたいな そういうふうなものが 状態遷移で書かれてるだけでも
全然大丈夫ですね
おだしょー じゃあ重要なのは グラフ構造というか 状態が閉じ
てることなんですかね グラフって 循環するかなと思うんですけど
ぐるぐる回ったりとか それがこの フローチャートでもそうだと思います
けど 分岐の先がちゃんと定義されてる ことなんですかね
おだしょー そうですね 閉じてる と強すぎるんですが 分岐の先が
39:05
定義されてるっていうのはおっしゃ るとおりです 閉じてるだと強すぎる
の例を出してみようと思うんですけど カウンターアップするカウンター
があるじゃないですか カウンター アップボタンを押すと表示される
数字が上がってるみたいな これって 閉じてないですよね カチカチカチ
ってやると無限に上に行けるんで
おだしょー 閉じてるというか 1個だけを行き来してるなのかもしれない
ですけど 状態として アップして もう1回ボタンが押せる状態に戻
ってみたいな
おだしょー そうですね ただ 表示 されてる文字列とか変わってる
わけですよ
おだしょー 確かに
おだしょー だから別の状態なん ですよね これって
おだしょー 確かに
おだしょー そう考えるとこれは 閉じてはいない状態なんで こういう
ものでも仕様を書くことができる ので 閉じてるは強すぎるんですけど
分岐が全部ちゃんと書かれている っていうのは正しいと思います
おだしょー 確かにカウントアップ して 1.3のときに何か表示してとか
だったら確かに閉じてないですね それだけだったら
おだしょー そうですね
おだしょー はい
おだしょー なるほど じゃあ今から 仕様書書いてって言われたとして
どういうアプローチしたらいい ですか すごい
おだしょー そうですね
おだしょー こういうのをやったら いいよみたいなのがあったら
おだしょー ありますあります 私は最近よくやってるんですけど
これ実は生成AIとのやりとりでも 言うことができて 私すごく冒頭
の部分でプロンプトって仕様みたいな もんですよねってちょろっと言った
と思うんですけど まさにそうなんですよ プロンプトって何かこういうの
実装してほしいんだよねっていう ときに われわれは正解を指示してる
わけですよ なので正解を指示して それに対するAIの回答を使っている
っていうふうな形なので これ実は 仕様なんですね 私はこの仕様を
プラントUMLっていう UMLの記述する テキストで記述する図にするような
やつがあって このプラントUMLの サブセットを使って指示してます
なので まずAIとやりとりするときに プラントUMLの状態センスを書こう
って 状態センスを書くわけですよ 書きまくるわけですよ 状態センス
書いて 私はそれを見て 最初から 指でなぞりながら 仕様アニメーション
をするわけです これあってこれあって 今ちょうど作ってるのはVSコード
の拡張を作ってるんですけど まず VSコードの拡張ってことは まず
エディザーでその拡張が読み込 まれたイベントがあるよね そしたら
ユーザーが何かを押したイベント があって 保存ボタンとか押すかもしれない
ねって 保存は失敗するかもしれない からとかってことを考えて これ
指差ししながらこれを見てくるん ですよ これだめだなって思ったら
そのUML直すんです プラントUML 直して 満足いく仕様になったら
仕様アニメーション完了 おいしい 仕様だと思いますってなって じゃあ
実装してくださいっていうふうに 言うと 私 これで失敗したことが
ないぐらい
すごい いいですね 先に計量に失敗 できるというか 確認できる方法
で プラントUMLを使って確認しやす くした上で ここちょっと間違ってる
よねみたいないうのを叩いた上で 実装していく 実装に入るなんですね
やり方として かなり良さそうな やり方だなと思って 今 自分が
やってるちっちゃいツールとか 作ってるんですけど それでは一番
42:04
最初はエンドツーエンドテスト を書いてもらうみたいなことを
やってるんですよ シナリオを作って もらって エンドツーエンドのシナリオ
作って そのシナリオが意図してる ものかなみたいなのをちゃんと
確認した後 じゃあこれを満たす ように実装してくださいみたいな
感じで今やってるんですけど それも 結構いいなとは思ってるんですけど
確かにプラントUMLのほうがもう ちょっと手軽というか 確認もし
やすいし ビジュアルで見やすい しっていうのがあるかもしれない
ですね
そうですね 見やすいし網羅的ですね 網羅的であることは使用すごく
大事なので このエラーのときどう なるのってこと エンドツーエンド
テスト一時期書くのめんどくさい じゃないですか だけどプラント
UMLだったら矢印一本引くだけなんで 楽だなって
確かに エラーを表示するみたいな いうところに行くみたいな
いや かなりいいなと思いました ありがとうございます 結構いい
時間になったので 最後に仕様に関して 最後一言あれば
おさらいなんですけど まとめる と 仕様は正解か不正解かを判断
するものであって なるべくどっち とも分からんねっていうのが少ない
のがいい仕様だっていう そして なるべくおいしさを判断できる
仕様になってると嬉しいですね われわれはサービスをグロウ
させるために仕様を探してるわけ ですよ それでいい仕様をなるべく
早く見つけるためにはPDMの人 とかに これ おいしいですかね
とかって 動いて確かめてもらえる ような仕様であることが望ましい
この2点っていうのが 私は仕様 についてすごく大事だと思って
ます ぜひそれを意識して仕様を 書いてみてください
おだしょー ありがとうございます ということで 今回はここまで
にしたいと思います もっと詳しく 教えてください ラジオおりゃく
しクワラジーでは スーパーエンジニア である国明さんに 一般エンジニア
であるヘントコが技術的な質問 をしていく番組になってます
今後もいろいろなことを聞いて いきたいなと思っております
ので お聞きのプラットフォーム で高評価やフォローのほうをお願いします
また こんなことを国明さんに聞 いてほしいっていうのがありました
らコメントいただけると非常に 嬉しいのでよろしくお願いします
Xなどでハッシュタグクワラジで つぶやいてもらっても大丈夫
ですので 観察のほうをよろしくお願いします それでは今回もありがとうございました
ありがとうございました
