1. readline.fm
  2. EP034『構造化分析とシステム..
2024-09-09 31:15

EP034『構造化分析とシステム仕様』PART3

spotify apple_podcasts

今回も『構造化分析とシステム仕様 ~目指すシステムを明確にするモデル化技法~』を読んだ感想を話しました。


## 取り上げた本

⁠『構造化分析とシステム仕様 ~目指すシステムを明確にするモデル化技法~』⁠トム・デマルコ 日経BP 1994年


## shownote

https://gennei.notion.site/EP034-PART3-50dc1c5c4324452691367678b3270025?pvs=4

サマリー

構造化分析とシステム仕様におけるプロセス仕様の重要性とその実践について探求しています。デマルコの古典的な仕様書の問題点を指摘し、プログラミングと言語の関連性を示しながら、構造化された記述の利点と課題について議論しています。構造化分析とシステム仕様に関する議論が中心であり、特にプロセスの仕様やデータフローダイアグラムの重要性、また効果的なドキュメント作成についての視点が紹介されています。このエピソードではデマルコの視点が強調され、分析と運用の関係が探求されています。システムを長期的に運用することの重要性と、そのための準備についても語られています。

プロセス仕様の概要
スピーカー 2
次、一応順番通りにいくとプロセス 仕様のとこですね。プロセス仕様は
これは、仕様書の話ですね。仕様書の話ですし、ここまでやってるのが
データフローとかデータディキューショナリーっていうのは、データっていうのを主軸に置いてたんで、結構静的な動き、
スタティックな観点かなっていうところに対して、プロセスはいきなりじゃないか。結構ここからダイナミックになってきますよね。
スピーカー 1
そうですね。
スピーカー 2
データフローって言ってたんで、動きは多少あったとは思うんですけども、あれはどっちかっていうと、繋がり方、スタティックなリンクの仕方みたいな秘密が結構強いかなと思うんで。
ここからは本当にプロセスっていう名前の通りで、データをどのように加工しますかっていう話になってきて、ゲイさんのことばかり言うと、仕様書やんけっていう。
スピーカー 1
そうですね。
スピーカー 2
手続きになってきますよね。
スピーカー 1
そうですね。この辺の話を読んでると、仕様書でもあり、その16章のあたりとかは構造化言語っていう話が出てきて、まさにプログラミングを自然言語で記述するみたいに近いようなことが発生していて、
こういうドキュメントを作るよりは、プログラムを書きたくなるなっていうふうに思ったりしましたね。
スピーカー 2
これでも15章、16章あたりでちょいちょいデマルコが毒吐いてるの気づきました?
スピーカー 1
全然そこ気づいてなかったかも。
スピーカー 2
古典的な仕様書、構造化分析っていうのを今提唱してるデマルコの立場から見て、今主流な仕様書とか分析の話っていうのを指して古典的なって言ってますけど、
古典的な仕様書の記述法っていうのが208ページの15-2のところにあって、そこに結構よく読んでみると、すごい辛辣なこと書いてあるなって僕思ったのは、日常使われる言語は仕様書の記述に使うには正確性に欠け、
まあここはいいんですけど、この後が苦毒情緒で願蓄や暗示に満ちているみたいな、だからこそ日常言語は深みと正気、まあエネルギーですよね、にあふれ、詩や小説が成り立つのだが、これらは仕様書には邪魔なだけであるみたいな書いてあって、
デマルコから見たら世の中の仕様書は全部ポエムに見えるのかなぐらいの感じがあったりだとか、あと16章212ページ開いて16-1に書いてみると、仕様書を書く上でもっともアナリストを悩ませる次のような要素は意識的に取り除いてあるっていうので、
まあすごいまともなこと言うのかなと思ったら6つ列挙してあるんですけど、箇条書きで、1番目がつまらない修飾語を外してますみたいな、形容詞と文字がいりませんみたいなこと書いてあって、なんかすげーフラストレーション溜まってんなーって思いながら読んでました
スピーカー 1
まあ確かにね、でも確かに仕様書を書くときに、もちろん感情的にここは大事だよって伝える部分はADRとか書いてて、なんでこれを書いてるかみたいなパッションみたいなところはあるかもしれないけど、実際そこにメッチャとかすごくとか書かれても困るなっていうのはまあそれそうよねって気持ちはありますね
コードコメントとかにもね、たまにありますよね、お気持ち表明されたり、よくわかんない、てんてんてんてんてんてんてんてんみたいな、どんだけ余裕を残すのみたいな
スピーカー 2
でも多分ここで言いたかったのはまあパッと見その自然言語、我々で言うと日本語で構成されてるから、日本語書ったらいいじゃんっていう気持ちじゃなくて、まあね形式的言語に近いような構造化された言語
でその税肉みたいなつまらない就職語とかそういうのを取り除いて、で文と文のつながりが明示的である接続詞とかっていう曖昧なものに頼るんじゃなくて、ネストされた構造化されたもので示しましょうとか、なんかそういうふうにアテンション語を引いてるのかなみたいな感じですかね
スピーカー 1
実際ね我々日本語で仕様書を書いたりとかして、じゃあそれが本当に1位に定まって、それを読めばもう実装できるよねみたいなことってなかなかないですよね、この時どうなりますかみたいなとか、俺はこう読み取ったんだけどこれで合ってるみたいな確認するとかってしょっちゅうありますよね
でゲインさんがさっきコード書きたくなっちゃって言ってたのと近いんですけど、なんかこれ日本語だけどスイッチ文で書きたいなみたいなとかめちゃくちゃありますかね
わかる
スピーカー 2
そこら辺をやってるのが本当にこのプロセス仕様の中の1個のアイテム要素である構造化言語っていうのはそこら辺ですね
スピーカー 1
文章で書いてその横にフローチャートみたいなのが書かれてたりとかして、この文章はこういう構造になるよみたいなことが表されたりとかして、そうですね、それぐらいやんないと伝わらないでしょって思ってるってことなのかなってちょっと思ったりとかもしましたね
スピーカー 2
自然文で書かれたやつっていうのを例示して、じゃあ実際これをデータフローとか構造化言語に書き起こしてみたらどうなるかっていうちょっと演習みたいなの、演習っていうか読者に解かせるんじゃなくて、実際にやってみましたみたいなエクザンプル的な説明的なものもあったりして
こういうのを見るとなんかそのサンプルとして書かれてる、我々はね翻訳された本読んでるんで日本語で書かれてますけど、いや読む気しないですね、文章代を解く集中力ないなみたいな
スピーカー 1
そうですね、プログラムに慣れてるからっていうのもあるかもしれない、日本語で書いてあるから読む気なんねえのかな
記述方法とエクザンプル
スピーカー 2
これがね、分かりやすくというかそごなく伝わるとか読解に無料なコストをかけなくても十分である表現、ドキュメンテーションしていきましょうよっていうのが構造化分析の目指す世界観だと思うので
なんかすごい当たり前っちゃ当たり前だけど大事だなあっていう気持ちになりますよね
スピーカー 1
そうですね、構造化言語の長所短所みたいなところの話でもやっぱり書式を自動化できるとか書いてあって、確かにそれは書くのに迷わないという意味ではいいし、ルールが統一されてるのはいいよなと思いながら
慣れるまでやや時間がかかるっていう短所が書いてあって、そうよね、これ書けるんだったらだんだんプログラムを書けるんじゃねみたいなことを思ったりとか
スピーカー 2
ロジカルシンキングできてるねみたいになりますけど、あとこの構造化言語の短所247ページのところで、ユーザーが警戒心を抱くことがあるっていうふうに書いてあって
これは我々が理解してこういうモデルだと思ってますけど、ご宅の人から見てそごないですかあってますかみたいな共通の語彙としてコミュニケーションできるツールとして使いたいよねっていう世界観狙いはあるので
ユーザーにとっても一緒に見てもらいたいツールではあるけど、この構造化文書みたいなところをやるとちょっとユーザーが引くかもねみたいなことが短所として書かれていて
僕これ見て思ったのが、プログラマーがやたら過剰書きとかネストするの好きみたいな話があるのをちょっと思いましたね
スピーカー 1
確かに、長く書いても伝わらんやろうと思って過剰書きするんですけど
スピーカー 2
ネストレベル4ぐらいまで使ってくる人とかいるじゃないですか
深い深い
スピーカー 1
いますね
あとはまだちょっとさっきのこれが書けるようになったらこの構造化文書書けるようになったらプログラム書けるやろうって思ったのは
ちょっとどこで書いてあったか忘れちゃったんですけど
構造化の表すときに順次実行と分岐と繰り返しで全部表現しますって書いてあって
それってまさにプログラムの本質というかこれで全てが実現できますってやつの話から来てると思うんで
それができるんだったらもうコード書けるよねってちょっと思っちゃったりしましたね
そうですねあとは平成に代入さえできれば一通り
本当にって思うんですけどね最初はそれで本当にできるのって
それでyoutube作れるんですかみたいな順次実行と繰り返しと
スピーカー 2
youtubeは無理だけど動画載せるサイトぐらいならできるかもみたいな
スピーカー 1
youtubeは無理ですみたいな
でもまあ掘っていくと実はそういうことではあるもののそれだけ知っていればできるではないんですけど厳密には
スピーカー 2
そうですね
スピーカー 1
あとはちょっと自分がプログラム書きたくなるなーっていう話と関連して後ろの方にこの
Q&Aが結構この本各部ごとに載ってたりするんですけど
スピーカー 2
そうあれですよね勝手にきそうな質問を考えてQ&Aときましたみたいなことが前書き当たりで書いてます
スピーカー 1
そこでもやっぱ構造化言語とプログラム言語って一体したようになってるようだがそれに間違いはないですかとか
話が書いてあったりとか構造化言語による記述はプログラマーの領域を侵食してるのではないかみたいな話があったりとか書いてあって
こぼれにそのままうまいことを起こせないですかみたいなこともあったりとかして
みんなそう考えるのかみたいな同じようなこと考えるのかなみたいなことを思ってて
スピーカー 2
ビジュアルプログラミングとかはねそういう世界観ですね
スピーカー 1
そうですね確かに
スピーカー 2
これでもこれ想定質問というか架空の質問者とのQ&Aですみたいな
なんか263ページというかこの部のQ&Aの最後ひどくないですか質問の趣旨がよくわかりません
スピーカー 1
そうですね
スピーカー 2
面白いですね
スピーカー 1
言われたんですかね実は
スピーカー 2
でもそっかプロセスの話で言うと構造化文章構造化言語とあとディシジョンテーブルディシジョンツリーがここにあるやつですね
スピーカー 1
そうですね
スピーカー 2
ディシジョンテーブルとかまあなんかソフトウェアテストとかの勉強をすると本当に書いてみようぜって出てきますよね
スピーカー 1
そうですねこの辺テーブルとかツリーみたいなのは全然現代でも生き残ってて使ってますね
絶対漏れがないかなって不安になるときはまずテーブル作ってインプットインシアを列挙して合ってるっけみたいなことは全然ありますね今でも
結構ねまあ見つかりますからねこの組み合わせ想定してないじゃんとか
スピーカー 2
組み合わせが複雑なところがバグが生まれるというか虫が入ってくるところですからね
スピーカー 1
そうそう割と文章の中にはねやっぱこのそのパターン想定してないですとか
ありえないときはありえないって書いておいて欲しいなって思ったりしますし
なんかありえないのもありえない理由がちゃんと記述されてないといけないしそういうのを見つけるためにも結構必要で
なんかちょっとさっきチケットストーリーチケットの中に今でも文章で書いてること多いよねみたいな話をちょっとしたんですけど
プロセスの仕様とテスト手法
スピーカー 1
そこでなんとなく思ってるのはやっぱディシジョンテーブルとかちょっと入力が複雑なときには表を作っておいて
こういうケースのときどうなるかみたいなのが列挙されてると安心してその実装に入れるなみたいなところは思ったりしてますね
スピーカー 2
そうですねこのままパラメタライズテストとかに落とせるかもやってみてなんか違ぇか読みずれぇかだったりとかしたりもしつつ
スピーカー 1
そこに明らかになってたらテスト手法はいろいろあると思うんですけど少なくともユニットテストとかインディグレーションテスト書くときにそれを参考にしながら
これ満たしてるってことを自信持って言えるようになったりとかもするんで一見それをPOとかチケットを書く人に求めるのは大変かもしれないんで
やっぱチームで協力してQAだったりとかエンジニアだったりとかは書いていくと後の自分が楽になるっていうのはあると思うんで
そういうのってどんどん使える技法だったりとかっていうのは使っていくといいよなって思ったりしてますね
スピーカー 2
そうですね少なくともなんかドキュメントとして書いておいたんでそこがないか誤差集くださいみたいな投げっぱなしのコミュニケーションする必要もなくて
ちょっとドキュメントをまとめたんで少し解説しながら読み合わせしましょうみたいなコミュニケーションを
この本で言うところのユーザー発注者とやっていけば多分理解するための足場としてはかなり使い勝手がいいものになりそうだなとか
本当にね構造化分析でわざわざこの明瞭なコミュニケーションを取るためにドキュメントを作りましょうみたいな話してる中で
これが書かれてるっていうのは本当にプログラミングの知識がない人とプログラミングやる人どちらから読んでも同じものが見えてくる同じ解釈ができる
だから作りたいもの要求とか仕様が明確化できるよねみたいなポテンシャルがあるからここに載ってるんだろうなみたいな感じですもんね
スピーカー 1
そうですねあと最近だとこれ表作るの結構めんどくさいなとかあるんですけど最近だと多分GeForceとかいろいろツールがあると思うんで
そういうので自動で列挙して応募してくれるのもあるんでそういうのを使うともっと楽にできたりもするはずなんで
ちゃんとGPTにやらせるとこもあるだろうし
そうですよねこの本が書かれてる時代たぶんExcelがギリギリあるか
いやないんじゃないかな
ないかなWindows3.2とか完全に脱速なんでどうでもいいんですけど
Lotus 1,2,3とか
手で書いてたんだと思うんですよね表とかは全然ドキュメントとかって
スピーカー 2
マイクロソフトExcelイニシャルリリース1987年らしいです
スピーカー 1
87年で現聴が78年だからないですね
スピーカー 2
ないですね
全然ないですね
スピーカー 1
逆でした7と8が逆だった
みたいなところですかね
スピーカー 2
そうなんですよねソフトウェア開発プロジェクトで分析フェーズっていうのがあって
いかにして構造化分析っていう手法を取り入れていくかっていうのは
冒頭で述べた通りなかなかちょっと想像がつきづらいなっていう部分はあるんですけど
ここのプロセス仕様の話とかは構造化言語ディシジョンテーブルでディシジョンツリーの話は
スピーカー 1
妙にピンときますよねそれ便利でわかりやすいよねみたいな
現代にちゃんと生き残っているものだからこそっていう感じですよね
スピーカー 2
そうですねそんなところですかねプロセスの話は
システムのモデル化
スピーカー 1
残りがあと2つでシステムのモデル化とプロジェクト後半における構造化分析の話っていう感じですね
スピーカー 2
そうですねここまでで必要なツールの紹介は一通り終わって
あとはこれをどうやって使っていくかみたいな実践編的な話になってきますかね
スピーカー 1
そうですねで次がシステムのモデル化ですね
スピーカー 2
第5部第6部まとめてでもいいかもしれないですけど
どこらへんか印象に残った部分がありました
スピーカー 1
そうですねもう前半で結構読んでて力尽きたっていう感じは
自分は結構あってなんかあんまり後ろの方はこうだんだんだんだん
読む気にはならなくなってきたっていうのがちょっと若干あったんですけど
スピーカー 2
でもあれなんですよね第4部までが考え方とか通常の紹介っていうある意味その要素
エッセンスみたいなところだったからっていうのはあるんですけど
第5部第6部になってくる実践編活用編みたいな話になってくると
いよいよ現代とは違うかもなっていうズレが大きくなってきたりもして
スピーカー 1
そうですねでもちょっと読んでて発見というかそうだよねみたいなところで
なんていうかこれはいいなっていうかあんまり考えたことなかった
考えたことなかったわけじゃないけど発見的にいろんなもの見つかるかもなみたいなところがあって
18章19章とかでシステムのモデルの利用っていうところで
データフローダイアグラムとかをどんどんどんどん使っていきましょうねっていうところで
論理設計物理設計の話だったりとか論理モデルの構築の話をしていったときに
どういう順番で物事が手続きが行われているかみたいな話の中で
273ページに一応図でこうどういう順番でデータフローを表すかみたいなことをやってるんですけど
それを見てるとなんかこの順序に必然性がなくてたまたま今そうなってるんですよみたいなことが
分かったみたいなことが書かれていて確かにユーザーインタビューとかで業務フローみたいな話を聞いていると
こういう順番で業務フローがあるってこういうふうにやっていくんだなみたいなことって分かるんだけども
そこに必然性みたいなものってなかなか見つけにくいなとかちょっと思ったりとかして
ユーザーはこう言ってるからこれが正しいんだってある種思っちゃうことが多々あるなと思っていて
この必然性みたいなところの整理みたいなところってこういうようなことを考えない
こういうようなことっていうのはこの本で書いてあるようなデータフローだったりとかのことを考えないと
見つけられないかもなっていうのをちょっと思ったりしましたね
スピーカー 2
なんかでもそこら辺の視点って本当にコード書くときプログラミングの設計でもなんか
スピーカー 1
この動詞を考えるときにこの順番で書かれてるけど実はこれ理解可能だとか一緒にいるにはないやんけみたいな
スピーカー 2
本来は必要がないもしくは取り除くことが可能であるなんですけど
なんちゃら動詞みたいなのが発生してるなっていうのに気づく視点みたいなのもあると思って
そこら辺とも繋がりそうですよね
スピーカー 1
そういうのがある種俯瞰してみれて発見できるっていうのはこういうものの大きいメリットなのかなって思って
ドキュメントの価値とメンテナンス
スピーカー 1
1回のリクエストでデータ全部取ってるけどこれ実は分離できるじゃんとかって
もうちょっとコードに寄せて話すと多分そういうことだと思ったりするんですけど
スピーカー 2
そこら辺を気づくことができたらどういうふうに使いたいとかあります?
スピーカー 1
混在してるものをまず整理整頓できるっていうのは1個と
あとそのある種業務のワークフローみたいなところ
これが終わって次これをやってあれをやってってやるとそこに制約が生まれるわけじゃないですか
例えばデータの処理を次のフローが始まるまでにデータを加工しておかないといけないとか
バッチ処理でこういう順番で処理しないと困るみたいなこととかがあるんだけども
そこの前提が崩れるということは自分たちが問題解決をするときの引き出しの中身が増えるというか
取れる手段の自由度が広がっていくと思うんで
困った時にもうちょっと別の視点から考えて
これって別にこういう順番で処理されてるけど本当はそこに必然性がないから
もっと早めにデータ加工して作っておけるじゃんとか
次の日の朝までにあればいいからじゃあやかんにやってしまおうとか
そういうふうなことが見えてくるかなっていうのはちょっと思ったりしましたね
スピーカー 2
縛りがなくなってきますよね
スピーカー 1
柔軟な本当にやりたいこと無理やり作るっていう苦しさが確かに減っていく感じはありますね
自由にするってことは逆に言うとちゃんと考えておかないと破綻するぞってことでもあるんで
スピーカー 2
難しさはあるんだけど
どういうふうに考えてその結論を出したのみたいな時にやっぱりいい感じダイアグラムがあると
なるほどこれがコントになってるか
こういう見え方してたのねじゃあ今はちょっと状況変わってるかもねっていうリフが取りやすかったりとか
助かりますよね
スピーカー 1
あとは業務フローとかが変わった時とかにどこに影響があるか分かるっていうのは便利ですよね
じゃあここから先ごそっとなくなるのでみたいなことがもう分かりやすいですよね
スピーカー 2
いやだからそうだよな結構永久保存版なドキュメントとして残しましょうっていう圧はかかりますよね
開発を始めるために認識揃えのために必要なちょっと暫定的というか切なな文章を作るんじゃなくて
スピーカー 1
5年後の見知らぬプログラマーが路頭に迷わないように作れるダイアグラムを書きましょうってなると
スピーカー 2
やるべきなんですけどちょっと耳が痛いなって気持ち
スピーカー 1
でも5年後のためにって言ってもさっきの競馬の補修占いシステムは会社が倒産しましたんで
1年かけた分析は5年後には会社がないので使えませんみたいな悲しいオチが待ってるみたいな可能性はありますよね
スピーカー 2
動くものを作らないとしょうがないしょうがない
スピーカー 1
あとでも今その話をしてちょっと脱線しちゃうんですけど
このドキュメントの試算価値みたいなのって計上されるんですかね
スピーカー 2
管理会計的な意味ですか
スピーカー 1
管理会計的な意味ですね
スピーカー 2
でも試算じゃないですかね
スピーカー 1
これを例えば似たようなことをやりたい会社に売ることができるのかとかドキュメント
スピーカー 2
価格をつけられるかみたいな話です
例えばこれがアートソーシングした時に納品物として含めることっていうふうに小取引できるっていうのはあると思うので売り物にもなるだろうし
あと理屈から言ってもやっぱり補修メンテナンス費用を改善する軽減するために役に立つんですみたいな
デマルコの視点と分析
スピーカー 2
この食品を食べておけば風邪が引きにくくなるから医療費が削れますみたいな話として
ドキュメントを作って1000ドル稼げたみたいな話はできるんじゃないかなって思いましたけど僕はわからないです
含めても監査法人には怒られなさそうだなっていう気がしますけど
含めたり含めなかったり管理会見は社内である程度スキンできると思うんで
スピーカー 1
倒産しちゃうまあ売れるものがあるんだったらいいなとか
スピーカー 2
売り的な意味で売れ残りドキュメントセールですみたいな
スピーカー 1
とかちょっと思ったりしましたけど
動くものもなくてとか儲からなくて価値が本当にマジでゼロですみたいな
失敗した授業のドキュメントを買いたいかって言われたらあんま欲しいと思わないだろうけど
スピーカー 2
そうですね
ほっとくに埋めておくといいかもしれないですけど
スピーカー 1
未来の人が掘り起こして見つけてくれるかもしれない
スピーカー 2
これね第5部第6部
語られてる内容について何か面白いなすごいなっていう話とはちょっとずれるんですけど
この本ずっとアナリストとか分析フェーズの話をしていて
作られた構造化仕様書っていうのが分析フェーズ以後
上流工程が終わった時に
なんかそれはどうなっていきますかとかどうしていくべきですか
どう役に立ちますかみたいなところまで触れられていたりとか
23章がまさにプロジェクト後半に向けてっていうタイトルの章があるぐらいだったりとか
あと24章が構造化仕様書のメンテナンスみたいな話がされていたりとかで
そこら辺の手厚さというか本当に必要なことを
なんかしっかり得りすぐっているこのデマルコの視点って多分すごいんだろうなみたいな
勝手に想像をしてましたね
作られて終わりだったら多分なんかデマルコがやりたかった意味のある価値の高い
何ですかね分析の成果物
ドキュメンテーションの活動っていうのからは多分ほど遠くなってしまうんだろうなみたいな
そんなちょっとメタなところの感想でそういうのを思いました
長期運用の重要性
スピーカー 1
自分は逆にシステムの運用というか後ろのプロジェクトの後半の話が
本全体からするとちょっとしかないわけじゃないですか
ターゲットがそこじゃないからっていうのももちろんあるんですけど
多分長期にシステムを運用するということがまだ分からないというか
当時の感覚としてどうだったか厳密なことは分からないけども
システムを長期で動かしていくとどういうことが起きるのかが
まだなかなか分からない状態なのかな
だからこそもっと前に分析を頑張りましょうとか
後で苦しくならないように先にまず全体を考えましょうみたいな
ことがまずあって運用の話はまだ知見が溜まってない状態なのかな
っていうのを本の割合だったり拡張の割合だったり
みたいなところから自分は印象として受け取ったりもしましたね
スピーカー 2
なるほどねスカシペぐらいの量しか書いてないじゃないかみたいな
スピーカー 1
でも例えばそれが現代においてはシステムを作ることは別にできるんだけど
いかに長期的に運用していくかとかアップデートを考えるかとか
DevとOpsを分けるんじゃなくて一緒にしていこうねとか
作ったら終わりじゃないんだよとこれを徐々に育てていくというか
システムを良くしていくってことの方がより大事なんだよみたいな話で
今では当たり前にされるけども多分当時はまだそういう感覚じゃないよね
っていうのを思ったりしてましたね
スピーカー 2
そうですね最近だと詳しい人は辞め何も知らない新人が入ってくる人は入れ替わるみたいな話とか
じゃあその中で授業を止めるわけにいかないからどうしていくんだっけみたいな話とか
あったりとかしますからね
スピーカー 1
そうですね式年戦グーディシステムを入れ替えてその時にリセットしましょうみたいな話もあるし
毎週毎週アップデートしていきましょうみたいな話もあるし
世の中いろんな手段を取りながらやってきてますね
これなんか受け入れテストの話とかフレームとか大丈夫?
スピーカー 2
そうですねあとは
31:15

コメント

スクロール