00:07
こんにちは、readline.fmです。 readline.fmは、つん読画趣味の二人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、hash.readline.fmです。 Mixi2にreadline.fmのコミュニティがありますので、そちらでも感想やワイワイお待ちしております。
ホスト役はゲイエイさんと金城です。それではゲイエイさん、よろしくお願いします。
よろしくお願いします。
なんかゆっくり読んだら滑舌よくなるかなと思ったけど、全然そんなことないですね。
あの、readline.fmってね、結構言いにくいんですよね。
あれですからね、日本人はハイフェオが苦手だし、マミムメモはそもそも発音しづらいので。
そうですね。
fm外しますか。
まあね、どこまでが番組名なのかっていうのはね、よく、本当はreadlineなのでは?みたいな。
fmって放送の電波の話だからっていうこともあったりしますけど。
そうですね。まあまあ、なんちゃらなんちゃらあれいみたいな編集名みたいな感じですよ。
ソフトウェア要求・仕様の概要
というわけで、じゃあ今回も何かの本を読んで感想を話していく回ですね。
そうですね。
今日は何の本でしょうか。
今回は、ソフトウェア要求・投資を実践・原理・偏見の辞典という本ですね。
これサブタイかっこいいですよね。
そうですね。偏見なんだって思いながら。
現代オリジナルのタイトルそのままか、今回は。
偏見とかが、バイアスではなく、これいつも発音できないなと思うんですけど、高慢と偏見の偏見ですよね、みたいな。
確かに読んでみると、記述が難しいみたいな話じゃないですか。
正しく誤解なく伝わるっていうのは難しくて、それなんでかっていうと、思い込みがあるよねっていうところなんで偏見ですね。
ただ偏見の辞典って書かれると、ちょっと味わい方が変わるな。確かに偏見の辞典だったな。
でもどちらかというと注目すべきは要求と使用の方ですよね。
どっちが主題なんでっていう。
これはどんな本って言うといいんですかねっていうことを思いながら。
俺、エッセイ集ではないんですけど、あれか、プリンシーパルオブプログラミングでしたっけ、いろんな原理原作がバーって書かれてるやつ。
ありますね。
あれに近いのかな。
確かに確かに。
あれのソフトウェアの開発の中でよく出てくるようなトピックだったりとか、これが大事でしょうっていうような項目が、全部が全部そうではないんだけども。
全部が全部そうではない。
レストランっていう立候補されてる項目があったりもしましたけど、
でも大体はある種ソフトウェア開発の中でよく出てくるような難しさっていうのはどういうところにあるんだろうかというようなものが、著者が思ったことを、
エッセイというほどではないんだけどトピックについてちょっといろいろ書いてあるという感じですかね。
そうですね。すでにこれ書いたマイケルジャクソンさんっていう人なんですけど、どの界隈にも一人はいるマイケルジャクソンさんですね。
本の特性と構成
過去に自分が表してる論文とか書籍の、そこで取り扱ったキーワードとかテーマとかっていうのももちろん含まれてるし、
多分それがでも半分とかなのかな、わかんないですけど。し、そうじゃなくてより一般的な、論理学とかの話がめっちゃたくさんあったりするし、
あとマジでエッセイとかポエムみたいな、てかポエムっていう章もあるんだよね。
詩っていう章もあります。
そう、ありますあります。
っていう、バラエティに富んでますね。
だいぶバラエティに富んでましたね。
僕がさっきプリンシパルオブプログラミングであってますよね。
あってるはず。
ぽいなって言ったのは、一章一章が独立してて、総合参照みたいなつながりはあるんですけど、連続性みたいなものはあんまりない。あんまりというか、意図的にかもしれないし、ないんですよね。
そう、だからいわゆるパターンとかカタログ本みたいなことを言ったときって、特にパターンランゲージとかの本だと、これをやったら次に適用されるといいパターンはこれですみたいな。
そういう文脈性というか連続性みたいなものがすごい意識されてるんですけど、この本はそれがなくて、というか50音順に並べましたって前書きに書いてあるんだよな。
そうです。だから元の本だとアルファベット順に並べてあって、翻訳だと丁寧にちゃんとそれをアイデア順に並べ直すってことまでやってありました。
で、その代わり本文中で他の章を参照できるところは、物理本というか書籍なのでハイパーリンクは無理なんですけど、なんかちょっと括弧で囲ってあって、他の章に参照したらこのタームはわかるよっていうのがマークアップされてるような感じでしたね。
だから本当に、なんだ、手前から後ろまで順番に読む意味が本当にない。だし、そういう読み方が全然オススメされてなくて、辞書的に使いましょうねっていう言い方もされてるし、あとオススメコースみたいなのもいくつか書いてありましたもんね。
テーマに沿って読むみたいなことが書かれていて、いくつかそのテーマが書かれていて、例えば様々な記述方法とか、減少学とか問題の分析とか、いろんなテーマがあって、それを知りたい人はこういう順番でこれを読むといいよみたいな風に一応書いてはあるんですけど、
でも多分この順で読んだとってわかるのかなどうかなと思いながら、若干怪しいのではって思ったりもしてますけど。
本当にグルーピングがされてないので、こういう羅針盤はあるに越したことはないなという気がしましたね。
読者のモチベーション
そうですね。
書写としては一応こういう風に読んでもらえるといいかなということは作ってはいるっていうところですね。
そんな本でしたっていうところですかね。
そうですね。これなんで我々読もうってなったんでしたっけ。モチベーションとしてどこにこの本が面白そうだったかっていうと。
これはモチベーションは積んであったからでしかないみたいな。
そうですよね。自分は近所さんにこれどうですかって言われて、知らない本だったなと思って。
Amazon検索したらKindle Unlimitedにあったし、じゃあこれでいきましょうって言ったんですけど。
そうですよね。自分一人で読むのは骨が折れそうだから、ちょっと概要というかきっかけが欲しい。
で、いつも選んでるので、僕がこれ読みませんかって言ったときも、たまにめっちゃ発売されたばっかりで絶対話題になりそうだし、一生懸命してやろうかはあるんですけど。
そうだからトムデバルコしかり、ワインバーグしかり、あれ連続で、あそこまで連続して読むっていうのはあまり自分一人だとやらなそうだな、小説だったらやりますけど。
あまり技術書であんまりやらないかもなって思ったから、近くにいる便利な人を巻き込んでやってるし。
で、マイケルジャクソンの本は何冊か持ってるんですけど、あとこれとプロブレムフレームも置いてあって。
で、読んでみたいなとはずっと思ってて、読んでみたい、どっかで読んだ方がいい、読むべきなんだろうなっていうのはずっと思ってて。
ただプロブレムフレームの方になるとちょっと手強すぎる気がしたので。
って考えるとこのソフトウェア要求と仕様っていう本はページ数的にはかなり少ない、230ページちょいだし、一章一章はすごい、一章章でいいのかな。
項目?
そうだとして、項目、自体はすごい短いんですよね。
長くて大きめのダイアグラムとか入れてちょっとページ数が長めになってるところで、何ページ?7ページぐらい?
短いのだと本当に1ページ弱ぐらいとか。
それもあってあんまり読み疲れしないっていうほどではないんですけど、途中で心が折れても何とか最後まで走れそうみたいな感じもしたので。
それはお前動機なのかどうなのかっていうのは怪しいんですけど、一回触れておきたかったんですよ。
かつやっぱり直近に売れたワインバーグとかもですけど、やっぱり要求とか仕様っていうのはじっくり触れてみた。要求と仕様ってなんやねんっていうところはかねがねあったので。
本当それある。
この本買った理由はそこなんですよ。要求と仕様なんだろうとか。あと要件っていう言葉もあるような気がするよねとか。
ありますね。
そうするとこういうザ王道みたいなソフトウェア要求と仕様っていう冠の本読んでおけば何とか少し入門できるかもなって買ってありました。
なるほど。
自分もそれに乗っかって今回よし読むぞと思ったときにやっぱりピンときたのがソフトウェア要求と仕様って言われて、そうそう要求と仕様は違うんだよとかって言われて、そうですよね違いますよねとかって思いながら。
何がどう違うのかってあんまうまく言えねえけどなって内心ずっと思ってたんで、よしこれ読んだらわかるかなって結構期待して読んでましたっていう感じですね。
要求系の本に関しては別に他にも何冊もあるんですけど、つんどくの山を見ると。要求工学とかあるしね。
ありますね。
アジャイルソフトウェア要求と要求工学知識体系が今隣に並んでるなっていうのを眺めてて、でもその隣にこの本置いてあったんですよ、ソフトウェア要求と仕様が。
もう完全にその文脈ですね。
ただね、なんか知らないけどIU系の本やたらページ数分厚いので、ちょっと2週間で読み切ろうぜーわ。大変かもなーってちょっと日寄ってしまう。
あと大体ね、高いんだよなとか思ったりとかね。
まあまあ1回積んじゃえばもうただなんで。
まあそうですね、1回払えば本という実質その後ずっと無料で読めますからね。
買えばただなのにっていうね。
ね、もはや聞いてる人たちが何を言ってるんだこいつらはっていう気持ちになってきたと思うんですけど。
本の背景と歴史
で、ちょっとこの本のなんか付属情報というか、読み始める前に自分が調べてて面白いなと思ったところで、ちょっと触れときたいなーってあるんですけど、
この本どうやら金城さんが持ってるのは2014年に出版されたバージョンですかね。
西雲社から出てるやつかな。
ノーハズ福富館ですね、はい。
なのでこの本実は日本で初めて翻訳されたのが97年で、トッパンっていう今印刷の会社がありますけど、トッパンがどうやら出版部門を持ってたときに出したものが元々で、
その後2004年に復刊して、2014年にさらに福富館再度もう1回復刊したようで、
だからこれ意外とこんだけ復刊されて、読んでほしいとか読みたいという人がいるってことは結構大事な本じゃないかなっていうような気がしたんですけど、
あんまりなんかあちこちで話題になってるかっていうと、なんかそうでもないような気がしていて、
なんかこの辺の温墓館みたいなもの、昔どういうふうにみんなが読んでたのかなーってちょっと気になるなーと思ってました。
たしかにそうですね、ただ名前は聞き、名前というかこの人の名前、同じ名前の他の人も名前もちろんめっちゃ聞くんですけど、
言い方があれですけど有名な人ですもんね。
そうですね。
なんかいちらほらと見かけたりはするし、代表作ではないかもしれないですけど、マイケルジャクソン的なものがいろんな、エッセンシャルマイケルジャクソンだと思うんですよね、これ。
うんうん。
っていう意味で言うと、なんか読まれてはいそうだよなーって今聞きながら思いましたね。
でも自分はたぶんティーワダさんの発表がなんかで触れられていたような気が、マイケルジャクソンの名前が出てきたような気がしていて、なんかそれで覚えてたんだけども、
なんかそれ以外では、なんか自分の中ではあんまりこう、この本だったりこのマイケルジャクソンの名前、ソフトウェアのマイケルジャクソンの名前は、自分はあんまり触れてこなかったなーと思ってて。
まあもちろん人月の神話ほど有名かって言われたら、もちろんそうではないし。
まああれは敵が強すぎるみたいな話なんで、あれですけど。
けど、なんかこうちょっと、何ですかね、一歩踏み込まないとやっぱ出会わない本なのかなーとか思ったりして。
でもまあそういう、自分の感覚では結構そんな感じで思ってて、でもそういう本がこうやって復刊されてるってことは、やっぱりあるコミュニティだったりとか、あるクラスさんの中ではすごく大事として読まれてるのかなっていうのをちょっと想像しながら、今回の方に読んだっていうのはありますね。
今これ、げんえんさんがあんまり周りの人から名前聞いたことないかもなーっていう話をして、ふむふむそうかと思って、Xで自分のフォローしてるアカウントに絞ってソフトウェア用途としようって調べてみたんですけど、なんか一番上に独立ソフトウェア用途としようって自分のアイコンのポストが流れてきましたね。
だからえっと、2022年に1回読んでるはず、だからこんなにデジャブ感があったんだなって今すごい納得しました。
なるほど。
はい。なるほどな。2回目です、読んだの。
いろんな発見が出ますね。
なるほどなー。
じゃあ、じゃあきっと俺より金城さんの方が詳しいってことですね、これに関しては。
いやー、読み捨てるのがね、いかんせん得意な。
ただ2022年8月っていうとやっぱり僕の中で要求とかしようとかなんだろうっていうので探ってた時期な気がするな。
一人で読めていいんじゃねえかって思ってしまったな。
まあ、そういう時もあります。
まあまあまあ。でもそうですね、95年、97年、えっと、原著が95年の翻訳突販からの日本語での出版が97年ぐらいの時代性ですね。
だから、XPとかスクラムはちらほら出てきてるかなぐらいか。
そうですね、そうですね、それぐらいで、アジャイルソフトウェア宣言のちょい手前ぐらいなんで、そこに向かっていく途中ぐらいな感じですかね。
軽量プロセスみたいなもの大事なんじゃねっていうような風潮が出てき始めてるぐらいだと思います。
インターネットとかだからまだ全然って感じだと思いますよね。
そうか、ちょうどインターネットぐらいか。
日本の商用のインターネットが95年がスタートなんで、多分世界的に見ても同じぐらいだったと思うので。
考えると、きっとインターネットがこれから来るぞみたいな状態で、Windows 95が出てみたいな、ブラウザってものが今後大事になっていくなみたいな、インターネットエクスプローラーがどこが持つかみたいな話だったりとかっていうようなぐらいの時代感ですかね、パソコンとかで言うと。
一家に一台パソコンはまだないぞっていう話ですからね、これぐらいになると。
Windows 95より前ですからね、インターネットあったとしても定格通信のISDNがだってまだ。
ダイヤルアップで大学にいる人たちがインターネットをつなぎ放題で楽しいみたいな、多分そういう時代感ですね、日本はもう完全に。
大学の起動するだけで7分ぐらいかかるパソコンが。
っていうような時代なので、こういうふうに出てくるソフトウェア開発の話っていうのは、多分現代から見るともうちょっと古めかしいかもねっていう感じはありますね。
実際なんかそんな感じがしましたね。なんでなんでしょうね。これより前に書かれてる本を散々読んでるわけじゃないですか。
そうですね。
なんでなんだろうな。というかエンタープレイズ感がやっぱり強いんですかね。用途とか仕様とかっていうのにすごいしっかり触れてるんで。
だから作って捨てるみたいなことがめっちゃ難しいっていうことは一個あると思うんですよね。
プロトタイプしづらいというか、一人一台ギリパソコンがあったかもしれないけども、動かすメインのサーバーとかがそんなたくさんあるわけでもないし、
私多分物を作るってことに対してのタイムスパンが全然今と違うと思うんですよね。
一回作ったらもう捨てずにずっと使い続けないとこれはみたいな感じもあるだろうし。
あとあれですね、本の中で結構時代背景っていうのとちょっとずれるかもしれないんですけど、結構構造化分析ってこうだったよね的な話が多かったので、それも一時代二時代前ぐらいの感じが独語感としては出てくるのかなっていう。
ありますね、ありますね。
構造化分析をちゃんとやろうぜって話っていうよりかどっちかっていうと、なかなかそれも厳しいところあるよねっていうカウンター的な見方をもらったと思うんですけど。
そうですね、そうですね。だから実際たぶん構造化分析が、たぶん今の現代の我々は構造化分析にはたぶん本を書こうと思ったら触れないと思うんですけど。
データフローダイアグラム、2025。
確かにあの本では触れてるかもしれないけど、でも結局現代においてやっぱりオブジェクト思考で全てが解決してくれるわけじゃないよねっていう話はたぶん絶対触れるよねとか、関数型みたいなものの考え方が出てくるよねっていうような話があったりとかするように、やっぱりこの本の中でも構造化分析すれば絶対うまくいくんだっていうようなことではなかったよね。
何ならオブジェクト思考でやったとて同じような問題起きるかもねぐらいな感じのニュアンスみたいなところを自分は思ったりとかもして、結局この本って時代背景的なところでいろんな技術の話もあるんだけど、その技術だけじゃやっぱり難しくて要求とか仕様ってものを理解しないといいソフトウェア作れないよねっていうようなことを言ってるかなっていう気はちょっとしましたね。
それの伝え方、表現方法っていう感じのところですかね。
そうですね。いかに現実、適応領域、アプリケーション、ドメインというような言い方をしてたけど、世界ってものをどうやって記述して、曖昧さを減らしながら書いていくか記述していくかってことの大事さみたいなものをすごく考えているなっていうのはありましたね。
時代背景と技術の変遷
この長方形が何を意味しているのか的な表現をもう10回ぐらい見かけた気がする。その矢印は何だろうかとかね。
ダイアグラムにするとその認知負荷、認知負荷なのかな、なんか頭の中に入ってきやすい感じがするし、文章よりもしかしたらつかれないかもねっていうイメージを持たれやすいけど、
それって曖昧さを本当に削ぎ落としてるんだっけっていうと、かなり気をつけて使わないとだぜっていうようなのを、多分この本の中で一番言ってることの一つですかね。メインテーマみたいなのがないんだよな、あんまり。
そうですね、多分本当にとっていくつか気になるというか重要だと思うテーマを、例えば仮に10個持ってたらその10個に関連する話題をいっぱい書いて、辞書的に使ってくださいねと言わんばかり並べましたっていうような本なので、メインテーマでもあり、それだけではないっていうような本って感じ。
そうですね。
これどうやって本題に入っていくのかなって今思ってて。
探ってる。いつもなら一旦前の方から読んでっていう感じでやってるんですけど、いかんせんこの本前の方から読んで文字本順に並んでるだけなので。
そうそう、だから辞書を愛用順にじゃあから読んでいきますかって言っても何も面白くないよなっていう。
とりあえずアジョーまで読み終わりましたけど、ここまででどうでしたゲイさんみたいな、言われても。
そう言われても別にストーリーがあるわけじゃないしなっていう風になるんで、面白かったトピックとかなんかちょっとここから触れていきますかみたいなの適当に決めていきますか。
うん。
なんかちょっと自分が一番最初のところで触れたいなーって思ってた文があるんで、ちょっとそこから行こうかなと思うんですけど。
行きましょう。
顧客のニーズの理解
もう本当前書き終わってすぐぐらいのところの。
目次を見てたらページを戻された。
辞書にある中で、この本の中では大切なことは問題そのものを分析構造化することである。問題を解くためのシステムを分析の対象にするということではないっていうようなフレーズが結構一番最初の方に出てくるんですけど。
なんかこれすごくやっぱ大事だなと思ってて、なんかこれワインバーグのライトついてますか?って同じような話あったよなと思ってて。
やっぱり自分たちのシステムで作ろうとしているものを、そのシステムの方に目が行きがち。どうやって作るかとか、そのシステムがどう動くかとかっていうことに目が行きがちなんだけども。
顧客は別にそんなことをやってほしいというよりは、本当に解くべき作ってほしい要求だったりとか、抱えている問題そのものを解いておきたいのであって、システムが欲しいわけじゃない。
実はないんだよなっていうことに目が行かないと、レイルズでちょっぱいでこれが作れますみたいな風に言っちゃうんだけど、そっちを分析するんじゃなくて、ちゃんと顧客の方に目を向けないとダメなんだよって話をしていて。
これが結局ずっと構造化分析をすればうまくいくんだとか、オブジェクト思考で作れば大丈夫なんだとかっていうことのカウンターだったりするのかなみたいなことを思ってて。
これが結構最初の方に食われてるっていうことが、やっぱりこの本の立ち位置として、この本はこういうことを全体としてはテーマとしてとか、マイケル・ジャクソン自身がこういうふうに思ってるみたいなところが強く出てるのかなと思ったりとかして読んでましたね。
ここらへんとあれですね、構造化分析っていう手法を関連づけて話しているところで言うと、適用領域のところ、紙で言うと144ページで、適用領域の2ページ目なんですけど、後ろから半分ちょっと過ぎたぐらいか後ろから3分の1ぐらい。
で、デマルコとかがやってた初期の構造化分析手法ではまず第一歩として既存システムを解析するように教えていた。しかしこれは危険を伴っているっていう表現も出てきますね。
これ要するに既存システム、どういうふうにデータ流して、そこにどうやってヒューマン・イン・ザ・ループというか人間が関わってる、操作してるんだっけっていうところから分析していくと、それって問題の分析じゃない。今のアズリーズに引っ張られちゃうよね、的な話だと思ってるんですけど、それに近いですよね。
けっこう毒入ってたんだよな、ここ。既存システムを分析して、なるほどこういうふうに請求書とかやり取りされるんだねっていうような理解に基づいて、何かデザイン要求とか仕様なのかな、デザインしていくと。
中央支払いシステムっていうのを例に挙げて言ってるんですけど、本文書いてあるのをそのまま読み上げると、しかしその観点から構築されるシステムはもはや中央支払いシステムではない。それは自民支援システムであるっていうふうに書かれてて。
本当にコアドメインというか、本当に扱いたい概念、量だったりデータだったりっていうのをやり取りするんじゃなくて、作業効率、人間がやってる手続きを支援するためのシステム。概念を扱うというより人間の作業を自動化するみたいな。
それはそれで正解だなっていう気はするんですけど、ただやってることずれてるよねっていうのはすごい伝わる気がするなって。
本来それで本当にやらなくていい仕事だったはずなのに、そのためにシステムが作られてその仕事が続いて、結果的にお金を生み出さないとかっていうことが、実際起きてしまう可能性はあるんですよね。
システムとしては上手にできてるんだけど、問題は何も解消されてなくて、お金だけ支払われていくみたいな状態になったりすると、あれ結局これ何だったんだっけみたいな。
いうことは絶対起きてしまうので、よくできているけど、それは何のためにシステムが作られてるんだっけっていうふうになってしまうというか。
まだ絶対あるよねっていう気がしますね。
車を作れずにいい馬を考えてしまうみたいな構図だなっていう気がしますね。
確かに移動はできるからいいんだけど、思ったのと違うなみたいなことが多分出来上がるわけですよね。
