00:06
次の記事という回数に行きますか。 何があったっけな、第一部。
優しい機能仕様パート1からパート4まであるんで、ここらへんちょっと触れてみますか。 そうですね。
5章から8章が優しい機能仕様ですね。 仕様書っていうものについて、ひたすら書いているって感じですね。
5章何ページだっけ。40ページくらいか。 51ページ。
当時の仕様書っていうものは一体何を書いてたんだろうなーって。 まずは色々そんなことをちょっと思ったりをしながら。
仕様書ってでもあれじゃないですか。今でもそうだけど、プログラミングと違って自然言語で書いて、
かっちりとしたリンターがあるわけでもないし、漏れがあるとか、考えが足りてないよみたいなところとか教えてくれるわけでもないし、
書く価値ってあるのかなーって当時思ってたのかなーっていうのを、なんとなく自分は読みながら思ってて、
パート1がなぜわざわざ書く必要があるのかっていうタイトルだったりするんで、そもそもやっぱり仕様書書いてなかったんだろうなっていうのをちょっと思いましたね。
そうですね、第5章でいうと、書いた方がコミュニケーションにかかる時間を節約できるんだよっていう話とかが書いてますね。述べられてますね。
実際に実装してね、色々やるとめっちゃ時間かかっちゃうから、そういうことを節約しましょうねっていう話もありますね。
だから当たり前ですけど、コミュニケーションツールとして使おうみたいなことですもんね、まずは。
そうですね。プログラムで書いて、分かればいいけど、みんながみんなプログラマーじゃないしね、関わってる人たちは。
プログラマー同士ですら読むの大変だっていうこともありますからね。
そうなんですよね。プログラマー同士なら話が通じるでしょって言うんだったら、じゃあなんでいろんな行動がこんなに生まれてくるんですかって話になってきちゃうので。
でも57ページで書いたら、使用書が書かれない理由はそれほど多くの人々が書くのが嫌いなためなのだと思うっていうのは、これは割と本質だなっていう気はしますよね。
文章として表現する自然言語に落とすっていうコストもあるんですけど、何て言うんですかね、何もない状態から何かを生み出すのって大変じゃないですか。
03:10
プログラマーにソースコードを書くっていうのと使用書を書くっていうのを両方やっちゃうと、その苦しみを2回味わってる感はあり、1回で十分じゃんみたいな。
しかも動くものでやっぱりフィードバックくれるんですよね、ログだったり例外だったりっていう意味で。プログラマーはうかつにそういうのをフィードバックがもらいやすいみたいな表現しがちですけど、
01で無から何かを生み出すっていうコストとそれを書いたことによって何かが楽できるとかより良いものが手に入るっていうのが、しっかり新体制としてインストールされてないのかなみたいな。
使用書書いたところで、さっきのみんなが読める読めないみたいな話に繋がりますけど、みんなあるフィードバックくれるんだっけとか。使用書書いたんでレビューしてくださいって言ってもあんまりちゃんとツッコミが入らず。
ツッコミが入ったからそれを受けて一生懸命書き上げてよしじゃあコードを書いてみるかって言ってコードを書いても結局何か思ってたのと違うねって言われたら何か辛いねっていう所な気するんだよな。
さっきのエンジニアだとフィードバックがコードを書いた場合はフィードバックが来てみたいなのがあるって話があったけど、作りながら考えるみたいなことに慣れちゃうと最初に頭の中のものを出し切ってから実装するみたいなのがすごいやりにくいなっていうのは昔はすごくそう思ってて。
なのでいきなり書けって言われると書いても書けって言われてもなーって言ってとりあえず動くものを作ってから作ったものをむしろドキュメントに落とした方が早いんだよなーみたいな気持ちになってましたね。
チャーハン作ろうって言った時に最初に塩コショウどれくらい必要かなって考えるよりかは適当に米炒めながらちょっと味薄いかもって言って塩足した方が早いし美味しい気がしたじゃないですか。
それはもう作れる側なので作れるし、一旦作ってからいじっていいんだよねっていうのを知ってるのでそうしちゃいたいよなーって。
あとは使用書っていうものが更新されていかないんだよなっていうことを見に行ってみてるというか、だいたい古いってなった時にこれは当てにならない。じゃあソースコードを読もうってなると、
06:10
使用書を書く時間に労力を割くよりもソースコードがよりわかりやすいようにコメント書いてあげるとか、処理を切り分けてあげるとか、そっちに労力使った方がいいんじゃないかなーって思うことも多々ありました。
完全にコードを書くための言い訳として使用書を悪いやつだという立場で話してますよね。使用書があった方が開発が早いことなんていくらでもあるんだから。
そうなんですよね。あとはここ最近使用書ってやつのいいところというか、いいなって思い始めたのは、ある程度の抽象度で物事が考えられる人同士が会話するにはすごくいいなって思ってて、
具体の話をすごく書いてしまうと、やっぱり陳腐化してしまうし、究極的に言うと日本語でプログラムを書いて、あとはそれをコードに落とすみたいな感じになっちゃうんですよね。具体のことをずっと書いちゃうと。
それはあんまり価値がないから、そのいい塩梅の抽象度でテキストが書かれて、それを汲み取って実装が書けるみたいな人同士だと、使用書みたいなものがあるとうまくいくんだろうなっていうふうに思ったりしましたね。
この本でもね、使用って言った時に2例あって、機能的な使用と開発、実装的な使用があって、ここで言ってるのは前者だよみたいな話が6章か入ってきますね。だから要求になるんですかね、その機能、使用、技術、使用って分けた場合に。
そうですね。要求よりというか、ユーザーの方から見ての話ですもんね。
現代でも言ってないか。ファンクショナルスペシフィケーションって言ってんだな。
本当だ。6章のタイトルの上ところか。
そこを見るとシナリオ、例えばこんな人が使うよねってユーザーストーリーっぽい話が書いてあるんですよね。シナリオ1マイク、シナリオ2シンディーって書いてある。この見出しを見てもわからん気はするけど。
09:01
そうなんですよね。
マイクさんは多忙な経営者である。彼は大企業の社長であるみたいなところから、ちゃんとそのドキュメントの中に書いてあったりとか。シンディーは高校に通えてヒエイジャーだとか書いてあったりとか。
っていうか、何作ろうとしてるんだこれっていう感じなんですけどね、プロダクトとしては。時間がわかるウェブサービス。
What time is it comeっていう。どんなサービスやねんって思いながら。
シナリオ、良い機能使用書がどんなものかイメージをつかめるようにっていうふうに書かれていて。さっきのマイクとかシンディーとかの話もここなんですけど。
アウトラインとした概要とシナリオ。こういう人がこういうコンテキストで使います。シナリオとスコープ外っていう話。
あとフローツアート、画面遷移みたいな状態遷移。フローツアートと画面ごとの仕様と、あとスプラッシュ画面、ホームページ、ログインフォームっていう各画面についてのこういうゴールを目指しますっていう話が書かれてますね。
その技術的なところに踏み込むときにはテクニカルノートっていう書き方でちょっと注意書きみたいな感じで、例えばここはパスワードタイプのインプットフォームを使う想定ですとか書かれてると。
技術的な話とそうじゃないもの、ユーザー目線でどういうものを届ける、実現すべきですかっていうのが明確に限られて書かれてたりとか。
してますね。
確かにこれがあると実装はすごく助かりそうだなっていう感じは読んでるとしますね、やっぱり。
どこまで考えていて考慮してないことはこういうことですよって書いてあると、それだけで結構ちゃんと考えてるんだなっていう気がしてくる。
これをやってくださいって言ってこういうタイプのドキュメントが渡されて、開発者とか開発チームの中のリーダーとしてこれを受け取ったときにどう使うかですよね。
どういうコミュニケーションにつながるかとかどういうツッコミを入れる叩き台になるかみたいな話ですよね。
そうですね。
そこまで書いてるなら作っちゃって、なんかあったら聞いていいって言っちゃいたいよな。
こんだけあれば今だったらもうパッと作れるな。とりあえずパッと作っちゃうなって思いますね。
題材が時間を表示するだけのサービスだから。
12:02
そうそう。
これね、多分現実はもっと辛くて画面数もいっぱいあるし、後広報互換性を考えないといけないですみたいな話がいっぱいあったりとか。
ワリレーションの話とか載ってないのかな。
そうですね。
テキストブックの文字数制限とかパスワードはちゃんとマスクしましょうねっていうの書いてあるけど、それ以外のことを書いてないもんな。
使われてるEメール入れられたらどうするとか。
そうね。そういうことを突っ込んでいくのか、作って足りないところをその後どんどん追加で開発していくかみたいなのとか、やりようが多分いっぱいあるだろうね。
そうですよね。なんかそれで言うと、現代っぽい開発の仕方なのか、我々がそういう環境にいるからなのかわかんないですけど、
なんかクリティカルじゃないものって後から実際できたものを触ってみてブラッシュアップしていけばいいやっていう感じはしちゃいますもんね。
それからワリレーションのルール1個追加しましょうとかって別に大したことじゃないので。
そうそう。
それやるためにはなんかノーウェイシチュエルもう1個ぐらい必要っすよみたいな話にはならんじゃないですか。
うん。ならない。
API全部作り直しやとかならんので。
てかAPI全部作り直しですだったら作り方の筋がだいぶ悪いっていう可能性が高そう。
自分が一番最初に気にするのはデータモデルなのかな。
だからデータベースの設計は変えにくいんで、そこをなんかこれが壊れない前提であればソースコードは全部最悪捨ててもう1回書き直すとか、
そういうことは結構考えますね。
でもそういうふうに作ると多分データベースの仕様に引っ張られたりとかRDBでしかできない扱えない範囲のことしか考えないようになったりとかするんで、
良くも悪くもありみたいなところは多分あるんだろうなっていうのは結構最近は自覚的になろうってしてますけど。
我々は基本的にAPIとデータベース目線にやっぱりなるんだなって思って今聞いてました。裏側の後ろのデータベース接着剤ばかりなんで。
そう、フロントエンドの話をしない。
なんかそこら辺ですね、仕様書っていうのを叩き台にしてどんなコミュニケーションを取りたいですかっていうとなんか割とそこら辺かもしれないなって今話しながらちょっと思いました。
手戻りを避けるために後から追加はいいけど書いたものがそうじゃなかったからやり直しっていうのを避けられればいいかなっていうぐらいで、
15:00
劣相のリスクを洗い出すための叩き台として仕様が入ってくればドキュメント化されていて、明治的なコミュニケーションが取れればいいのかもなっていう感じがしました。
なんか完璧なものを作るための、本当に完成された文言、完成されたドキュメントがあってそれを上から読んでしっかり実装していけば100点取れますっていうのを目指してはいないなっていう感じがしますね。
そうですね。それは本当にそうですね。どうせ変わるしとか作りながらこれやっぱ使いにくいじゃんって思うっていうのはもう当たり前だよなって思い込んでますね。
思い込んでますね。で、なんかそれやるためにはやっぱり仕様書あったほうがいいんじゃないですか。
今話しながら、じゃあ俺ってどうやって開発してるんだろう。どうやってそのコミュニケーションがドリブンしてるんだろうと思った時に、やっぱりPRDが書かれて要求、こういうことをユーザーに体験させたい、こういうふうな業務を解決したいみたいなものが出てきて、
じゃあそれを今度ある程度みんな読んで、ここってこういうことですかみたいな質問は多少はするものの、やっぱりそれが画面に落とし込まれて、画面を見ながらユーザーがこれでその課題が解決できそうかとかいうことを話しながら、
頭の中で、これは1対1の関係性だよね、これは1対2の関係だよねとか、これがある時はこうなるよねとか、このデータが入力されている時にはこのボタンが活性になるよね、非活性になるよねとかいう風になってるから、仕様書っていうか画面イメージでなんか話を擦り合わせやってるなーっていうのをちょっと思いましたね。
画面イメージ、バッチとか作る時どうしてます、そうすると。
バッチか、バッチになるとあれですね。
僕は状態遷移図みたいなのが好きっちゃ好き。
そうですね、状態遷移図だったり、バッチ、あんま難しいものをそんな作ってないっていうのもあるけども、今だとそうですね、いつキックされてとか、これはこうこうこれぐらいのデータ量扱ってとか、リトライができるのかどうか、できるように作りましょうだと思うんだけど。
基本はね、けどやっぱどうしても分割されて実行されると難しいとか多分いろいろあったりするんで。
まあなんかそっちはそうですね、どれぐらいの期間内に終わらないといけないんだっけとかいうような、バッチになるとやっぱ技術的な要件みたいなところを洗い出していくっていうことを考えてることが多いかな。
18:00
そうですね、バッチオムライン処理はまたこういうログとか監視入れたいよねとか、こういう手順とかリトライできるようにしたいよねとかっていう方のリスクを洗うか。
そんな、そんな風にやってることが多いかな自分は。
あとはなんか大体バッチになると登場人物が増えるじゃないですか。
まるまる決済APIとか。
そうそう、外部のAPIとかAWSとかみたいなクラウドのものを組み合わせてやりますよとかってなるんで。
あの人たちが呼んでるCSVの形式で、それが標準化された何かとか一般的な何かわからないけど、あいつらの言うCSVの作成とアップロードが必要ですとかね。
そうそうそうそう。なのでそういう登場人物をちゃんと整理した図を描くみたいな、いうことになる気がしますね。
で、大体そういうものがちゃんと残ってると後ですごい救われるし、ないとまずそれを描くところから始まるっていう感じですね。
そうですね、そうですね。
まあだから優しい機能使用、今のところ割とこれを丸ごと受け入れるかっていうのはさておき。
そんなに読んでて違和感ない感じがしますね、5章6章は。必要な気がするな。
そうですね。
7章8章ってありますけど、7章がだけどどうやって書くのとか、8章がヒントってなってますね。
ここら辺は何か触れておきたい話ありましたか。
自分は8章のテンプレートの話があって、そこが気になって、これはヒントとして、テンプレートは有害ですよっていう話をしてるんですよね。
してますね。
確かに機能使用のテンプレートみたいなのとか、今だったらもしかしてADRとか、何でもドキュメントの概要となるようなテンプレートをここ埋めてほしいみたいなのがあったりするんですけど、
テンプレートが有害であるという話は何となくわかる、確かにみたいな、全部同じような感じだしわかりにくくなっていくよねとか、
テンプレートがあるとテンプレート以上のものが出てこないって確かにあるよなとか思ってて、
でもテンプレートなしでみたいなのは、実際どうなんですかね、書けるのかなみたいな、結局何書いていいかわからないって言われて何も出てきませんとか、
欲しい、こういう観点を書いてほしかったんだけどなみたいなのが、結局出てこないみたいなことが起きそうだなと思ってて、
21:01
この辺はちょっと反対意見かもなって思いましたね。
テンプレート、膨大になりすぎるテンプレートとかオプションが多すぎるテンプレートやめろみたいな話なのかなっていうふうに思ってました。
参考文献リストとかテンプレートにあったら誰が毎回それ入れるのやみたいな話が本の中で書いてあったりするんで、
用語集とか参考文献リスト本当にいるみたいな、なんかでも受け入れ条件っていうか、これをやることによって最終どんな状態にしたいか得られる価値とか、
逆に今回扱わないこと、スコープ外としたいこととかは欲しいじゃないですか。
なんかそういう、ここら辺はこういうところから考えてねーとか最低限ここら辺は書いてねーっていうテンプレートはありじゃないかなって源井さんの話聞いてて思ったけど、
そうですね、こういうテンプレートならOKみたいな話をこの本の中でジョエルがしてないから、じゃあこのルール5テンプレート有害であるに対して反対を唱えなきゃいけないか。
そう、たぶん盛り盛りになるよねっていう話はあるかもしれないけど、俺はないよりはそっちの方がまだベターなんじゃないみたいなことを思ってますね。
なぜかというと、埋めなくていいところ、オプショナルのところはスキップしてくれたらいいよと、最悪それを見て何も考えませんでしたっていうことが起きるかもしれないけども、
でも目に入ると、なんかこれ書かなきゃいけないんだっけとかっていうことをちょっと頭にある状態になってくれれば、なんかこれ考えてなかったなとかいう風になるから、
テンプレートは有害であるよりもいいことの方が多いんじゃないかなっていうのを思いながら、でもたぶんこれはあれなんだろうな、
理想的なテンプレートっていうものが世の中に存在するっていうことを信じているとか、そういうものがあればそれは何でも解決するでしょみたいな話に近づいていきそうだなっていう気持ちも、ちょっと今話し上がりしてました。
なんかゲインさんの今の話聞いてるとあれですね、なぜあなたはチェックリストを使わないのかみたいな本に書いてあったのはまさに、
一旦考えさせるための項目を作りましょうっていうのに近いかなっていう気はしたので、っていうのとあれですね、どっかから拾ってきたテンプレートとか他の部署から輸入してきたテンプレートとか、
全社標準化みたいなことをされなければ価値を出しやすいのかな、自分たちで考えたテンプレートっていうのをやっていく必要がありそうだなみたいな気がしますよね。
24:08
そうですね、なんかテンプレートは作ったら終わりじゃなくて、議論してる中でこれが足りないねってなった時に、じゃあそれをテンプレートに追加しましょうっていう風になってくれるときっといいんだろうなみたいな気がしますね。
そうですね。 っていうのが、なんか自分は一番テンプレート、自分も反対的なポジションを取る時もあるんですけど、なんかテンプレートさえ満たせば全部オッケーでしょって言われると、うーんみたいな気持ちになることがあるんで、反対のポジションを取ることが多いんだけども、ただ真っさらな状態よりはいいかなぐらいなことを思ってますね。
うん。最低限ここら辺書いてあると、まあレビューする側とか手を動かす側としても飲み込みやすくなるよねってポイントというか都合はありますからね確実に。
そうそう。委員長さんはどうですか?この7、8章あたりでこれ触れときたいなみたいな。
結構8章の本間かって思ったのがルール1、おかしくすることって書いてあった。これ、想像力を掻き立てるというか具体性を帯びて読み解かれるストーリーを書きなさいっていう話だとは思うんですけど。
何かな?情緒なんだよな例がなぁと思って。
どう?
ユーザーはコントロールNをタイプして新しいエンプロイテーブルを作成し、ジロイの名前を入力するみたいな書き方をする代わりに、
右上は彼女の○○した小さな指が太すぎて個々のキーが押せなかったので、アイライナーの絵を使ってキーボードをつき、コントロールNとタイプして新しいボーイフレンドテーブルを作成し、レコードを1件だけ入力したのように書いてみようって書いてあって。
だるっと思う。
今だったらAIに絶対なんか脚色してってお願いして書かせるなぁって思っちゃうなこれ。
AIにこれを簡潔にしてって言うなと思って。
逆もしかりだね。
でもこれ、そうだよな。ユーマーのセンスがないやつの問題を解いてやろうとするなって言われたからな。
確かにな。
これで本質は何なんだっていう話ですけど、さっき言ったテンプレートばっかりになって、あれもこれもどの使用書も似たようなものに見えちゃうっていうのはもったいないよねって話と根本は同じなんですよね。
使用書って人はあんまり読まないでしょっていうのをどうにかする必要があるっていう立場でジョエル書いてる気はするので、どうやったら人に読んでもらえるかっていうと目を引く必要がある。
27:02
そのためにちょっとユーマーを盛り込んだりとかおかしくしましょうよっていう話なのかな。
まあそうかな。
だとしてもよって。
いやーこれ絶対こういうことやってるとなんかその良くない言葉を使ったりとかして、あとでそれが表にテストでそれを使ってとかっていうことが起きるから、これはやっぱりちょっとって思っちゃうな。
でも読んでもらえる文章というか表現になってるか、読むのが苦痛になってないかっていうのを考えてみてはいかがっていうのはちょっとあるのかもなーとかは思いましたね。
まああとはなんかこの2000年とかその当時だと難しいかもしれなかったけど、今だと別に文章で書く必要はないかもしれないなと思ってて、動画だったりとか絵だったりとかいうことで、
どういうことをやりたいのかっていうのを、どういうことを実現したいのかっていうことが伝わればいいというだけであれば、動画だったりとかなんとかのサービスのあれみたいな感じで、みたいなことで伝わるんだったらもしかしたらそれでいいかもしれないし。
なんかこういう目的のためにこれをやりたいと思っていて、それはこの操作感っていうのはなんかその、あのサービスのあの感じでみたいな、例えばコントロールNを押して新しいメールが、メール文章を書くところが立ち上がるとか、
ノーションの新しいページが出るのと同じような感じでここはそういうことをやりたいんだよとかっていうことが、まあ映像だったり画面収録したものでも全然いいから伝わるんだったらまあそういうやり方もあるかなっていうような気がしましたね。
そうですね。なんかいかんせん2000年当初に比べるとストレージ代が安くなってきてるからカプチャーとか貼りまくり放題ですもんね。
まあただ検索できないっていう問題はあるんですけど。
検索はできないけども。
でもそうだな、読まれるって言うとちょっと語弊があるかもしれないんですけど、しっかり読もうかなーとかここは流していっかって思わさせすぎないようなドキュメントの書き方、使用書どうしたら読んでくれるかなーは、
大事かもな。使用書っていうかプロリクルのディスクリプションとかはね、気にすべきだと思うんですよね。
そうですね。
って考えると、やってるけど面白おかしいディスクリプション書いてないな。
30:01
あと文章だけで全部やると大変なので、やっぱ表とか通過欲しくなるよねーとかはありますね。
なんかダラダラとこの時はこうで、こういう時はこうだって、こういう時はこうしてくださいみたいなこと言われるよりも、ケース1、2、3って並んでてテーブルで1、何とかの時はこういう状態になる。
2は×はこういう時はこうなるみたいな。
網羅性があるよねとかっていうのがわかるようにとか、そういうのが欲しくなりますね。
そうですね。だから情報の構造化というかメリハリを欲しいですよね。
確かに全部文章で書かれてて、解読もされずずっとダラダラ書かれてたら、まあ人は読まんなっていうのは。
それは読まない。
それはそうだよっていう感じになる。
なんでそのミニファイスターみたいなものを書いてきたって。
そうですね。何読化させるんじゃないみたいな。
でも7、8章そんなところですかね。あります?他大丈夫ですか?
大丈夫です。
じゃあまた別の記事いきますか。
