本書の背景と印象
こんにちは、readline.fmです。readline.fmは、つんどくが趣味の2人が何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、hash.readline.fmです。ポスト役は、きんじょうさんとげんえいです。よろしくお願いします。
よろしくお願いします。
はい、今回がトムデマルコシリーズ、とうとう最後の本ですね。
すごい、ついに。
ついに。なんか気づいたらエクストラステージが追加されてましたけど、それでもやっと来ましたね、最後まで。
はい。
で、今回読むのが、構造化分析とシステム仕様という、まあタイトル化するとすげえ硬そうな本ですね。
うん、いかにもって感じですよね。サブタイトルというか、なんかタグラインじゃないか、ついているのが、目指すシステムを明確にするモデル化技法って書いてあって。
いいですよね。昔ながらのシンプルな教科書みたいな表紙に、いかついサブタイコピーみたいなのがついてて、タイトルもいかつくて、ページ数もそこそこあるみたいな、なんかザって感じですよね。
そうですね。改めて今、一応全部読んできて、今表紙を見て本の内容をもう一回思い出すと、まあなんか大学の授業の教科書みたいだなって気持ちになりますね、これ。
そうですね、そうですね、はい。
大学の授業とかでモデル化みたいなコマがあったら、こういう手順に従ってこうやってモデル化をやりますみたいなことが言われてもおかしくなさそうって感じはすごいしますね。
本当にそういう感じですよね、雰囲気というか。
今回のこの本はどうですか?全体的な読んでみてのまず感想というか。
全体的な感想でいうと、そうですね、意外と読みやすかったっていうとやや語弊がありそうなんですけど、結構骨のあるというかね、理解はなかなか大変だなみたいな感じはあったんですけど、
何だろうな、読みやすかったなって感じたのは一章一章が結構短いコンパクトめにまとまってたりだりとか、
あとなんかめちゃくちゃわかりづらい単語とか漢字が7文字ぐらい連なってるいかつい用語みたいなのもそんななかったですし、
一文一文がそんなにダラダラ長くないから仕事述語がちゃんとパッと見抜けるみたいなっていうですね、
昔から使われてますみたいな教科書のようないやらしさはそんなになくて、
っていう意味で読む前の印象としてはこれめっちゃお堅い本やろ、さぞ難しいんだろうなみたいな印象があったっていうので、
まあそのザップというか意外と真面目に読んでみようと思ったら文章自体は読みやすかったなみたいな印象でした。
なんか全然内容に関する感想じゃないですけど。
いやまあでもその受け止め方というか、本読む上でいきなりもう挫折して何もわかりませんでしたっていうよりは、
みんな読んでくれるんじゃないかなっていう気もするし、まあ読むのかな。
翻訳者が頑張っているのか、原著がそもそも扱っている内容を踏まえるとそこそこ平易な文章になっているのか、
みたいなのはちょっと原著読んでないんでわかんないんですけど、
出丸子がちゃんと読者に読ませようとしているなみたいなそういう気概みたいなものを感じたところはありますね。
著作の時代背景
確かに今回のこの本ってモデル化技法っていうサブタイトルの中にも入ってるし、
エッセイってよりはやっぱり工学というかエンジニアリングっぽいというか、
誰がやっても同じように本当にならないと困るしみたいなところとかを考えると、
なんかちょっとウィットに飛んだ表現だったりとか、
なんかちょっといい言い回しみたいなこうするっていうことが一切なく普通に平易な言葉でしゃべってるから。
ふざけられないみたいな。
そうそうそう。確かにそういう意味ではすごい読みやすいですよね。
さっき文章が短くて平易な言葉で書かれていてっていうのもそうだし、
自分も読んでてあんまり話のジャンプがないなって思いながら、
1個ずつちゃんと進んでいくみたいな感じがあって、
なんで突然ここからこの話になったの?みたいなとか、
それこそ出丸子多いに語るのを前回読んで俺らが全然わかんねえみたいな、
ああいうことは本当に前から読んでいけばちゃんと前の話をちゃんと抑えて、
次に進んでいけば理解ができるような、そんな作りになってる本ですよね。
そうですね。出丸子の著作がわりとエッセイだったり、
小説も、我々が読んだ中だと1個だけ小説もありましたけど、
みたいな感じで結構3文なんですよね。
そこに対してちゃんと工学領域の教科書みたいな書き方をしているので、
だいぶ読みやすいというか、ちょっと言い方変えると大人しいなみたいなところもあるかもしれないですね。
一応2本で出た順ではこれが多分一番最初の本だと思うんですけど、
幻聴もそうなんですかね、幻聴っていうか他に彼は出してたのかな。
この本の最後にある著者紹介見てるんですけど、
Structured Analysis and System Specificationっていうこの本のオリジナルが1979年ですね。
だから本当に最初に出した本っぽい気がしますよね。
そうすると硬いというか、硬派な感じの人が気づいたらピープルウェアを出したりとか、
その後に熊戸ワルツオとかになっていくと全然ちゃうやんけみたいなこんな感じの人じゃないし、
なんか一切こういうモデル化技法とかやっぱり技術に着目みたいなところよりも、
人の方に着目していくっていうのはRCの転換点みたいなのがあったのかなみたいなことをちょっと想像したりしますね。
そうですね。正しく中途で入ってきて最初はすごい真面目でもの静かな人だったけど、
合宿行ってみたらめちゃくちゃ面白いじゃねえかみたいな。覚醒しました?みたいな人とかもね。
そんな感じでピープルウェア書いてみたらめちゃくちゃ受けが良かったから、あれこっちもありちゃうかみたいな話もあったのかもしれないですね。
めちゃくちゃ失礼なことを適当に言ってるんですけど。
まあでも、後世からの評価としては、たぶんピープルウェアの人ってことになっていくと思うんですよね。今後。
そうですね。
ある種、今、我々は現代から時代を遡っていくような方向に結構読んでたんですけど、
やっぱりそこにどっかにトムデマルコの気持ち的なところで、このままいってもあんまり未来がないなって感じたのであれば、
なんかそういうところとかをどっかで読めたら楽しいなってちょっと思ったりしましたね。
心が折れたシーンが。
いや単純にこっちが売れたんでこっちの方に行きましただけとかの可能性も全然ありますけど。
でもそうですね、我々が読書をする順番として昔に戻っていきながらみたいな話が今出ましたけど、
この本を読んだ時の感想として難しく感じた部分っていうのがやっぱりその時代背景とか、
これが出版された、執筆された当時のソフトウェア業界の一般的な働き方とかっていうのがやっぱり想像がつきづらいので、
現代への応用
なのでそこらへんは少し難しさは感じたかなっていうのがありますね。
一応これの本が出たのが、原著が1978年で、日本語版が出たのが1986年。
その後に真相版として出たのが1994年なので、もともとで言うと1978年の当時の話がこの中に入ってるという感じですね。
わかんないですね。
そもそもとして今の自分の働き方、今までのチャリアを通じて分析フェーズみたいなものが存在しなかったりとか、
あとアナリストっていうロールがなかったりしてる中で、このアナリストがどういう風に分析をやっていけばいいかみたいな本ではあるので、
今何て言ったの?×今何て言ったの?みたいな、わからん、アンノンアンノンすぎるみたいな感じがあって。
そうですね。
そこらへんは難しかったですね、やっぱり。
じゃあこの本が全く役に立たないとか、ここで考えてることが今通じないかって言ったら、そんなことない部分も多分結構あったと思うんですけど、
この本自体は業務をどうやってモデル化しますか、システムに合わせてモデル化しますかって本として自分は割と読んだんですけど、
じゃあ現代においてそれってどうやってるのかとか、現代でやってる方法と本の差分みたいなところを×時代の移り変わりみたいな、
例えばコンピューターのスペックが良くなっていったとか、リモートワークみたいなものが出てきたとか、そもそも働き方が変わったりとか、
働く集団、多分当時はまだコンピューターで仕事をするってよりもデスクの上には一人一台パソコンがないみたいな時代だと思うんで、
そういうところが全部変わっていったとかいうところを掛け合わせながら差分読んでいくと結構面白いのかなっていうふうにちょっと全体的なところでは思ったりしましたね。
あと分かりやすいドキュメントを作るというか、要するにこれが作りたいんですとか、こういうふうにモデルって言い方しちゃいますけど、
こういうふうなものを組み立てれば多分欲しいものが手に入るんじゃないかっていうためのものを表現して伝えるための手段、手法っていうのを語ってる本ではあるので、
そこの部分って今も全然あるじゃないですか。
例えばUML使ってラフなスケッチしてシーケンス図でどういうふうなインタラクションとか流れとかあるかみたいな表現したりとか、
プロトタイプ作って触ってみてフィードバックもらいましょうみたいな、
表現方法の部分は変わってきてるというか、これからもどんどん変わっていくと思うんですけど、
なんかでもそれにしたって、要するにどういうものが作りたいんだっけっていうのを作る前の段階、もしくは作り始めたのと同時ぐらいの段階で、
なるべく正確にというか的確に共有したいよね、擦り合わせたいよねっていう問題は今の時代も全然残ってるはず。
で、そこに関してじゃあこういう方法を使いましょうよとか、まずここのことから考え始めるのがいいよねみたいな話をしてるのがこの構造化分析って言われてるパッケージにまとめられてるので、
なんかやっぱりそこの中に含まれている要素要素はちょっと今も使えるんじゃないかとか、この着眼点とても素敵だなぁみたいな風に感じるところは個人的にはありましたね、ちらほだと。
そうですよね、結局システムを作ってるっていうことは変わってなくて、じゃあなんで作るかって言ったら、その業務が困らないためにとか、もっと生産性を上げるためにとか、
っていうことで欲しいものがあって、それを欲しいからシステムとしてどうやってそれを表現しますかっていうところは何も変わってないっちゃ変わってないので、そこに対する期待値だったりとか、
まさにHowの部分だったりとか、そういうところはきっと変わってきてはいるんだろうけど、その辺とかはもう変わってないんだから、今読んでも結構得るもの、ヒントがあったりとかするなーっていうのはまさにって感じですね。
そんなところで内容の方に入っていきますか。
そうですね、最初にあれですよね、そもそもここで言う構造化分析ってどんなものなのみたいなところを投入してから入ると。
そうですね。
そこがないとずっとこの人たち何言ってるんだろうっていう状態になっちゃうと思うんで、そこから入りたいなみたいな気持ちがあり、
構造化分析の重要性
じゃあ僕の方からサクッとうまくまとまるかわからないですけど、しゃべると構造化分析、さっき言ったようなソフトウェア開発の分析フェーズのところを中心に使うようなパッケージ、考え方やり方みたいなところなんですけど、
前提として行動ソフトウェア、実際のソフトウェアの分析って複雑で曖昧で難しいよねみたいなところがあって、構造化分析何するんですかっていうと、
端的に言うと構造化仕様書を作成することである、そういうツールっていうのは便利なアプリケーションとかそういう話じゃなくて、
ドキュメントの種類みたいなものが定義されていて、5つか、データフローダイアグラム、データディクショナリ、構造化言語、デシジョンテーブル、デシジョンツリーっていうものを使えますよみたいな話をしていて、
だからそれって結局どういうものなんですかっていうのが構造化分析の特徴をつける全てのことだと思うんですけど、
これが何かっていうといい感じに図を使ってますとか、全体像っていうのと要素に分解して、本当に分解不可能な最小単位まで分解分析して、それを綺麗に繋げましょうみたいな、綺麗に繋げる話は多分後で触れると思うんですけど、
そういうやつです、綺麗にバトを渡しますのは。
そうですね、結局作りたいものとか作る対象のものを分析して、最終的にどういうアウトプットでまとめると、多分後にちゃんと作れるかとか、あと実際使うユーザーだったり、発注している側だったりとか、どうやってコミュニケーションしますかみたいなところでデータフローダイアグラムだったり、ディクショナリみたいなの整備したりしながら、
こういうデータが業務上において、ちゃんとこういう業務の流れとそのデータの流れが合ってるよねみたいなところとか、そういうコミュニケーションできるものを作っていきましょうっていうような話ですね。
そうですね、分かりづらい自然言語でダラダラ書いた分厚い仕様書とか言ってねえで図をうまく使えとか、まずはデータが何に入ってくるか定義しろとかそういうことを言ってます。
でも確かにデッドラインって前読んだ本の中でもインプットとアウトプットが明確になってないドキュメントってのはクソだみたいな話をしてたはずなんで、そんなものに価値はないみたいな。
ある種そこのアイディアというか話っていうのはここから来てるのかなってちょっと思ったりはしましたね。
そうですね、そうですね。DD、エリック・エヴァンス的な時代ほどまだ時が進んでないので、やっぱりこのアナリストとユーザー、小作と開発者っていうのの分断は前提にはあるとは思うんですけど、
それでもさっきゲイさんが言ったようにユーザーからフィードバックをもらいましょうとか、それぞれのロールの人が同じドキュメントを読んで、完全に同じとこまで行かなくてもある程度それぞれがちゃんと何が出てくるのかが想像できるように、そのぐらいわかりやすいものにしましょうとか、そういうところには意識が向いてる感じありますよね。
たぶんこれは我々は時代背景がつかめないから難しいですけど、こういうものが大事だよねって話してるってことは、つまりその裏返しでシステムってそもそもどうやって作っていいのかわかんない、システムの仕様を記述するフォーマットだったりとか、
どういう風に表現すると抜け漏れなく作れるかとか、ユーザーとの期待するものが事前に合意できるかみたいなところっていうのが、うまくいかなかったっていうのがずっと課題としてあったのかなみたいなのはなんとなくありますよね。
プロジェクトが失敗するっていうところがそもそもありますよね、たぶんこの時代背景というか、何が問題かっていうと、あんながっつり重厚な仕様書を作ったのに出来上がってくるものがゴミカスじゃねーか、なんだこれはみたいな、いきどり不満がめちゃくちゃ積もりに積もってるところにもっといいコミュニケーションがあるはずだって言ってたぶんこれを考えてる感じがしますね。
前回読んだ本とかでもあれでしたよね、プロジェクトが200%予算が超過しますとかは普通ですみたいなことを書いてあったりとか、そもそも10何%はプロジェクトがまず開始されないみたいなこととかあって、とにかくうまくいかねー、現代においても全然うまくいってないと思いますけど、全然うまくいかないっていうのが当時の課題感としてもやっぱあったはずっていうところですよね。
図による理解の促進
そうですね。
なんかこの中でその構造化分析と対比されて古典的分析って言い方をされていて。
我々はめちゃくちゃ古典だなって思いながら読んでたら20ページ30ページぐらいで古典的分析っていう単語が出てきて、おじいちゃんのおじいちゃんぐらいの感じの話がありますね。
その中に図を使いましょうみたいな話があって、システムの全体像みたいなのをさっき金城さんが自然言語で捉えられないみたいな、誰々が書かれてもわかんないみたいなところっていうのがやっぱずっと課題としてあるんだろうなーみたいなとか。
ドキュメントの用意性がその結果多分ドキュメントのメンテナンスがうまくできなかったりとか、どういうふうに分割したらこの複雑さがもうちょっと認識できるようになる。
複雑さに耐えられるようになるのかみたいなところがずっと課題としてあったって考えると結構これはやっぱ発明なのではっていう気持ちになりながら読んでましたね。
そうですね。分析上の諸問題っていう説、第1章第2説にそういう見出しがついてるところがあるんですけど、当時のアナリストとかそれを取り巻く人たちがやってる分析、こういう問題があるよねとかこういう結果を引き起こしてるよねみたいな話があって、
それの1番目にコミュニケーションの問題っていうふうに挙げてるんで、6番目に政治的な配慮っていうまた山中はずっと政治の話してくれるなーみたいな気がするんですけど、コミュニケーションの問題のところで100分は一見にしかずっていう言葉があるのにそんなに単語を長く並べないでくださいよみたいな話をしてますね。
一目でわかる図の方が有名であるみたいな。
これも現代を考えると、ドキュメントを書くけど、もうちょっと図を書いてみたいなコミュニケーションって多分チーム内とか会社の中でもするだろうし、これとちょっと違うんだけども、現代において我々どういう仕様書、ドキュメント、ここで言うドキュメントはコンフリにいっぱい字が書いてあるっていうよりはもうちょっと幅広く取られてもらえたらいいんですけど、
ユーザーストーリーマッピングだったりとかカスタマージャーニーとか多分いろんなハウのとか表現方法の部分は現代においてはいっぱい出てきていて、だいたいそれで全部図だよなって思うんですよね。
ストーリーテイング的なやつだと物語はリテラルに書くかもしれないですけど。
でもまぁだいたいなんか図だよねって思った時に、やっぱ人間が一目で全体感みたいなことを把握するって言った時には、そういう図の方がやっぱ認識しやすいんだなみたいなこととかをちょっと思ったりとかもしましたね。
そうですね、図の話で言うと、これ時代的なUMLとかが出てくる前なので、UML自体がオブジェクト思考とかが流行り始めてから出てきた時代性の話だったと思うんで、それよりもだいぶ前ですもんね。
なんかでもやっぱり図がない仕様書とか、ダイアグラムを使わないで要求とか要件、仕様をまとめてましたっていう時代ってどういうことしてたんだろうっていうのがやっぱり想像がつきづらい感じがしますよね。
そうですね、まぁでも一方で自分のチームではジラを使ってるんですけど、ジラのストーリーチケットとかには結構文章で書いてるなって今思いながら、それはなんかそのサイズに字を読んだらわかるぐらいのサイズにチケットが小さくなってるからっていうのはもちろん一個あるんですけど、
でもじゃあこの入力フォームの実装をしましょうみたいなって入力できる場所が3つあって、これは依存関係がありますみたいな時に絶対パターン表欲しくなるよなって思ったりとか、
けどなんか割と、それ表にしてよみたいなこと言うんですけど、自分はわかんなくなるから、ここが入力でこっちが入力済みの時にエラーを出しましょうとかが仮にあったら、じゃあこっちが入っててこっちが入ってない時はとかその組み合わせが絶対出てくるはずなんで表にしてよって、
てか表にしないと抜けもれあるかどうかわかんなくないみたいな話はするんですけど、まあ書手とかだとどうしてもやっぱり文章で書いて、今自分が考えてることをアップロードするみたいな、いうことはなんか多いなーって思ったりとかしますね。
そうですね。
図を書くコストとか表を作るコストがまだまだ高いのかな、多分当時はめちゃくちゃ高いと感じていて、だから高いかもしれないけどそれは有効なんだからもっとやっていこうよみたいなところから現代までずっときて、今だったら見ろとか、いくらでもフリーハンドで書けるようなツールが出てきたりとかするんで、
もっと図を書いた方がいいんだよなっていうのを思いながらでも割と図を結構書くのを自分はサボっちゃうなって思ったりとかもしてますね。
何ですかね、まあなんか義務教育の時代から文章とか言葉を書くことは練習させられてるけど、あんまり図で表現しましょうみたいなやってこなかったんで、なんかそれの影響もあるのかもしれないですね。言語優位だなーみたいな。
テーブル設計とか自分がしてる時はね、もうこのテーブルとこのテーブルが繋がってとか、これ一対一でとかって思うんですけど、人のレビューする時ってテーブル定義だけ変わるともうちょっと辛いなみたいなことってめちゃくちゃあって、やっぱ図ないとダメだよなって思いながらPHPストームで図を作ったりとかしてますね。
若干話ずれますけど、図の話で言うと結構僕好きというか、良かったなーっていう本があって、エンジニアのための図解思考再留文講座っていう本があってですね。
これ今ディスコのチャットにあったんですけど、これですね、もっと有名になっていいって思ってます。
もっと評価されるべき。
もっと評価されるべき。というか、この本自体が評価されてもいいし、このトピックについてもっといろんな人が光って書いて本出せば日の利ってめっちゃ思いますね。
教育を受けてないからかもなーみたいな話をちらって今出しましたけど、なんかビジュアルでイメージしたときに、自分自身がそういうどういう図形形象にして表せばいいかっていうのがうまくパッと迅速に出てこないっていうのもすごいでかいハードルとしてあると思うんですけど、
同じ図を見てどういうふうに解釈されるかが結構違うっていう経験を今までにしてきてないかみたいな感じがあって、要するに図で書いてもうまく伝わらないから結局言葉で補足するやんみたいな。
共通言語になってないそのビジュアル言語がみたいな状態だとやっぱりあまり図を書こうっていうのが嬉しい体験じゃないんですよね。
めんどくさくなりそうだなーみたいに嫌な予感がするのってなっちゃうんで、だからそういうときにチームの中でこういう本一冊輪読会とかして共通認識育んでおくと、なんかめちゃくちゃコミュニケーションコストというか摩擦が減るんじゃないかなみたいな気はしてるし、
ドキュメント作成の重要性
当然言語でも考えられてその図解思考ビジュアルでも考えられてっていう方がいろんな問題に対応しやすくなるはずなんで、単純にね仕事もしやすくなるはずみたいな感じがあって、
その中でこの本は非常に高度すぎないレベルが高すぎない十分に簡潔であるし、確かにこれ分かりやすいっていう納得感もあるって感じがしたんで、デマルコの本よりかはだいぶ新しいのに読みやすいはずですね。
それで言うと、まあ現在手に入る方はだいたい新しい方になってしまうけど、まあでもちょっとそれいいですね。確かにドキュメントの書き方ってこうなんかもっと勉強しようよとか、うまく伝わる文章を書くようにトレーニングするって結構いろんな本が出てたりとか勧められたりとか、
今多分後ろ振り返ると本棚に、うちにはなんか文章書き方の本だけで多分5冊10冊ぐらいあるんですけど、全部は読んでないですけど、でも確かにあんだけこう買ったり読んだりしてるのに、いざ分かりやすい図の作り方とかって言うと、
なんかプレゼンテーションの本とかは読んだりとかしたことあるんですけど、確かに言われて図の本って全然ないなって思ったんで、ちょっとこれ買って読みます。
もうカートに入れるとこまで来たんで、あと合わせ買いする本を決めるだけです。
そういうことか。マッチング待ちですって。
エンジニアのためのって書いてあるんで、我々が普段やってるような仕事、現場っぽい話、話題になってるはずなんで、そういう意味でも入ってきやすいかなって思います。
話をね、だいぶ横道に行ったんで戻ってきて、なんかこのドキュメント作るあたりとかで、あれがないなとか、これを作るんだとか、これって今で言うとこれかなとか、そういうのを思ったりしたこととかあります?
この本ないし、大阪分析のターゲットドキュメントとして書かれている。
それで言うと、さっき言った5つドキュメント作りましょう、ツールとして紹介されてましたけど、全部生き残ってるとか、確かに自分はやってなかったけど、この観点で何か情報集約する手段、ツールあった方がはかどるかもなみたいな、それぞれ5つとも感じましたね、僕は。
そうですね、自分も頭の中では考えてるけど、別にドキュメントには起こしてないなっていうこととか思いながら、一番多分この本の最初に出てくるというか、ある種肝なのかなと思ってるデータフローダイアグラムっていって、データがどこから来てどういう風に流れていくか。
ある種それって業務フローっちゃ業務フローに近いと思うんですよね。このデータの流れのために、データを中心として見たときにこのデータが流れるために、実際業務の人は受け取ったものを目を通して印鑑をして次に回すだとか、分類してバリデーションというかチェックして、
ダメなものは突き返すし、オッケーなものは他の部署に回して生産するとか、多分いろいろあると思うんですけど、そういうところって頭の中ではすごく考えて、これがどういうシーンで使われてとか、じゃあこのデータはこういう風に溜めとかないととか、ライフサイクルってこうだよねとか、
そういうところのヒントとしては絶対頭の中で考えてるなーとか思ったりとかちょっとしたりしてて、あとはなんとか読んでて、やっぱりそのユーザーとのコミュニケーションみたいなところが出てきたときに、ある種システム用のドキュメント、さっき現代人と我々で書いているものでいうと仕様書みたいなものって、ユーザーが読んでも多分わかんないんですよね、システムに詳しくないと。
で、そこってなんというか、だから失敗するのかもなっていうのも、なんとなくちょっとこれを読みながら突きつけられたなって思いながら。
アレグザンダーっぽい世界観。
そうそうそう、つまり結局顧客と対話するためにドキュメントがない、エンジニアとディレクターなのかPOなのかわかんない、PDFなのかわかんないですけど、コミュニケーションのためとして、それはもちろん機能してるんだけど、顧客と対話するための資料にはなってないから、顧客の話が抜けちゃうのかなと思ったりとかして、
で、じゃあ顧客と対話するためにドキュメントを作ってたのって、あ、それってパターンランゲージってやつがあったねとかってことをちょっと思い出しながら読んでて、確かにこの後にアドレナリンジャッキーとかでもパターンランゲージへの言及があったりするから、
まあそういうところはなんというか、トム・デ・マルコを考えてたことが建築の世界にもあるんだなみたいなところで見つけてきたのかなって思ったりとかしながら読んでました。
まあね、データフロー大学だね。
