00:06
きんじょうひでき
じゃあ、PART2行ってみますか。第2部。
げんえい
行きますか。
システムモデルと測定値
きんじょうひでき
第2部が、システムのモデルとシステムの測定値っていう話になってるんですけど、
これは設計っぽい話になってくるのが。
げんえい
そうですね。ここで、まさに最初のシステムモデルの話とか、後ろの方だと要求仕様の定義をしましょうね、みたいな話が出てきたりとか、
あと、設計の解決策のモデル化みたいな設計の話が出てきたりとかしてますね。
きんじょうひでき
そうですね。だから多分肝になるのが、モデルって言う言葉1個、肝になるかなっていう気はするんで、
ここで言ってるモデルって、じゃあどんなものなのっていうのは軽く触れておきたいんですけど、
なんかあれですよね、模型みたいなやつですよね。
げんえい
そうですね。
きんじょうひでき
実物をちっちゃい版で必要な特徴を唱えて作ったものみたいな感じだから、
なんだろう、UMLで書くようなクラス図とか設計書かもしれないし、
あんな感じで、そこから生まれるものが何であるかっていうのを十分に語れるものとしてモデルっていうふうに使ってると思うんですけど、
じゃあまずモデル化していって、モデル化さえうまくいっちゃえば、
予測、先ほど費用とか難しさみたいなところとかっていうのがわかってくるはずだから、
まずモデル化頑張ろうよ、じゃあモデル化ろうやんのみたいな話になっていって、
この辺が第6章に書かれてるんですけど。
げんえい
じゃあ何のモデルを作ったらいいんですかねっていう話ですよね。
建築であれば建築物を縮尺を小さくして作ればいいんだけど、
ソフトウェアってじゃない作ればいいの?みたいなところで、
この本でいうと3種類のモデルの話があって、
プロジェクトモデルと要求仕様モデルと設計モデル、
この3つのモデルを作るといいよっていう話をしてくれてますね。
きんじょうひでき
だから分析フェーズの成果物が何ですかって言われたら、
この3つの文章を揃えましょうみたいな、そんなイメージですよね。
そうですね。
一応少なくとも3つって言い方をしてるか。
げんえい
そうですね。
きんじょうひでき
でもこの3つしか出てこないと思うんで。
げんえい
プロジェクトモデルは実際プロジェクトがどういう風に進んでいくのかということと、
きんじょうひでき
スケジュールとか人員計画とか、予算とか。
げんえい
次が要求仕様モデルは目標システムの仕様書の一部分なので、
作り出すべきものの何作ればいいんだっけっていう部分ですよね、この辺とかは。
フォワット的なところですよね。
プロジェクトモデルの重要性
げんえい
この後ろの方に詳細とか書いてあって、
どういう機能ですかとか、どういうデータを保有してますかとか、
どういう風に状態遷移していきますかとか、
そういうようなものをモデル化して作っておくといいよみたいな話が載ってたりしますね。
最後は設計モデルで、
ここはまさにどうやって作るのみたいな部分の頃ですね。
きんじょうひでき
これがちゃんと作れて、数値で測定できると、きっと見積もりができるようになるってことですよね。
完璧なものを準備できれば完璧な数字が出てくるはず、みたいな言い方してますね。
げんえい
そうですね。
それって完全に要求が洗い出しできて、何を作ればいいか自明で、
そこから一切の変更はしません、みたいな世界観ですよね。
きんじょうひでき
まさにこの本の後ろの方で、
保守フェーズで追加で発生する費用、保守に関するコストは、
分析設計のところの失敗というものであるみたいな話で、
その失敗の一つとして要求を正確に引き出していなかった、みたいな話が書かれてたりして、
最近の感覚で言うと、なかなかしんどいこと言うな、みたいな気がしますよね。
げんえい
まあ、ウォッターフォールの問題点というのは結局それだったわけですよね。
後工程に行くと分かることっていうのがたくさんあって、
モデル化と実行のパラダイム
げんえい
それがちゃんと前工程で明らかになってないから、
ずっと後ろの方で長尻で合わせようとするから大変なことになっていくっていう。
これは厳密なウォッターフォールとは、本来のウォッターフォールの出点とは多分違うと思うんですけど、
よく言われる世の中で言うウォッターフォールの問題点。
きんじょうひでき
リーンソフトウェア開発とかで言うところの、
一番最初が一番手持ちの情報が少ないみたいな話だから、
なるべく意思決定を遅らせましょう、みたいな話とは楽になっちゃいますよね。
最初の情報が少ない時点で、
いやいや情報収集頑張って完璧なものを作らないと後できついでしょ、みたいな話をしてますね。
げんえい
やっぱり読んでいくと辛いなって思っちゃうな、この本っていう気持ちになりますね。
きんじょうひでき
本当にここら辺は、書いてあることが間違ってるじゃんとか、いけてないなっていう単純な話じゃなくて、
本当に時代の違い、積み重ねてきたものの上に、今我々って立ってるんだなっていうのを本当に感じるというか、
アップフロントでちゃんと計画立てて、分析設計やって、それが出揃ってから開発して、
手戻りなんて許されないし、設計者、アーキテクトと開発者って完全に分離されてるよね、みたいなのが、
支配的なパラダイムだった時代の上手いやり方、極めたらこんな感じになる、みたいな話だと。
今や我々はクロスファンクショナルなチーム作って、設計も自分たちで書きながら、テストも自分たちでやるし、
5着との対話も自分たちでやるぞ、みたいな感じなんで、時代の違いは感じます。
げんえい
時代の違いと、お手本にしていたものが、実は全然性質の違うものをお手本にしちゃったんだな、みたいなこととかもあるのかなっていう気がしていて、
多分この話って、ある種工場的な、ファクトリーの工場ですね。工場とかだと、その場でオンデマンドにラインを組み替えるとかって結構難しいんだろうなって勝手に思ってるんですよ。
もしかしたら改善を上手いことやってるような工場とかできるのかもしれないけど、
大体こんなふわっとしたものは作りたいんで、これを作るために工場のラインを貸してくれとか、発注をしてお願い食ってくれっていうのはまだできないはずなんで、
何作りたいかっていう要求をすごい引き出して、本当にこれでいいんだよね、みたいな。
これで試しづりして、試しに作ってみて、それを触ってみて、もうちょっと微調整したいぐらいのレベル感まで作りたいものの要求をガーッと落とし込めないといけないんだろうなっていうことを思ったりすると、
これをお手本にやっぱりソフトウェア作ってたっていうのは、なんかちょっと間違ってたんだなっていうのが後にわかったというか、
逆に言うとソフトウェア、さっきみたいに話したようにソフトウェアのお手本とするものは実はあんまりないのかもしれないなっていう気もしますけどね。
きんじょうひでき
取り違えたみたいな話で言うと、さっきモデル化、さっきっていうかこの本がモデル化頑張るっていう本なんですけど、
そこで言ってるモデルっていうのがやっぱりドキュメントなんですよね、仕様書だったり設計書だったり。
今の我々ぐらいの開発生産性になってくると、モデルって要するにちっちゃく動くプロトタイプっていうのができるわけじゃないですか。
だからやってることはちっちゃく実験して、なるべくエンドユーザーから見て想像がちゃんとできるもの。
さっき言ったように、受け手のマインドセットによって取り違いが、捉え方が全然異なるみたいな解釈の余地とかブレっていうのを、
なるべくなくして同じものを見ながら進めるために、やっぱりモデル化とか認識の共有必要だよねって言った時に、
動くソフトウェア作っちゃうか、ソフトウェア作るコストが高いからドキュメントでやろうよって言ってるかっていうところの違い。
だから抽象的にはやっぱり最初にモデル化して、手触りを試してみて、で、ゴーってなったらやってみようっていうところは変わってない気はするんですけど、
みたいなことをちらっと今思ったりしましたね。
建築とかのパラダイムっていうよりかは、本当に料理して味見してみないとわからないよねって言ってるのに近いかもしれないですね。
げんえい
そうですね。とりあえず1年前作ってみんなでちょっと食べて、これちょっと塩足したほうがいいねとか、
これジャガイモ多すぎるからこのカレーからジャガイモ減らそうねとか、
だんだんそれで1回作ってみて量がわかったら、じゃあこれでいきましょう、これをマーケットに出してみんなで食べてもらって反応もらいましょうみたいな、
なった時には多分大量に作らないといけないから、ジャガイモが何等必要ですみたいな、いう世界が見積もれるというか、
きんじょうひでき
近所のスーパーでジャガイモを買ってきてっていうレベルじゃ済まなくなるから、ちゃんと工場と契約してみたいな話とか。
それを文章で書かれたレシピだけでやれるかっていうと、なかなかもしかしたら専門家同士の会話だったらできるかもしれないんですけど、
やっぱり発注者、クライアントと開発者側でリテラシーが違うみたいな話があるんで、
ドキュメントとかワイヤーフレームとかだけ見てもなかなかちょっと想像できるものが違うみたいな、
でもそう考えるとあれですね、アレグザンダーのパターナ技術すごいなって感じ。
利用者と実験者が共通の語彙を持つみたいな世界観がすごいですね。
げんえい
彼も結局そこの難しさ、毎回建築が失敗しちゃうというか、うまくいかないっていうところ。
きんじょうひでき
作ったところで喜ばれないみたいな、なんか座り心地の悪い椅子付きの図書館になっちゃったなみたいなやつが嫌だぜって話でしたもんね。
げんえい
ある種その利用者と設計者みたいな、この境界をみんなどうなくしていくかみたいなのはずっとテーマになるんですかね。
知識的な非対称性があったりとかする中で、どうやったらこの高いを滑らかにしていくというか。
それに生きることによって、期待値のズレがどんどん低くなっていったりとか、もっとより良いものを共に作ることができるようになっていくとかっていう方向に行くのかなっていう気がしますよね。
きんじょうひでき
医療の現場とかでインフォームドコンセントとかってあるのも、結構最近、最近って言っても10年20年ぐらいのスパンだと思うんですけど。
なんか昔はね、お医者先生が言ったものに従いなさいとか、説明してもわかんないやろ的な感じだったんじゃないかなって思うと、
なんか増界とか領域に関わらず、そういうふうにどうにか伝える、伝わるようにするっていう努力をした上で、
本当に最終利用者が望むものを届けなきゃ、なかなか価値の低調につながらないみたいなものの見方が支配的になってくるのかなっていう気は、ちょっと今話聞きながら。
げんえい
めっちゃモデルから離れてるけど、いい話だなと思いました。
きんじょうひでき
これ、そうか、本の話に戻りますか。なんかでもそう本当に言ってるのがあれなんですよね。
いいモデルができればちゃんと測定ができるだろうって言っていて、ここで言ってるいいモデルっていうのが具体的にどのくらいの精度を求めてるかっていうと、
オブジェクト指向の現状
きんじょうひでき
設計者の話で言うと本当にこれオブジェクト思考の時代じゃないよなっていうのを読んでる途中に思ったんですけど、
我々が慣れ親しんでる表現で言うと、例えばクラスが何個あって、インターフェースですね、API、メソッドが何個生えててみたいなところをざわって洗い出して、
そのメソッドとかのサブルーチンの中に条件分岐がどのくらいになってるか、要するにプログラムの複雑度みたいなものが出てくると、
分岐が何個あるからコストがいくらだね、みたいなところまで見えてくるでしょみたいな話を聞いて、
なるほど、なかなかしんどいみたいな気持ちになったりはしたんですけど、
したんですけど、これちょっと試行実験的にげんえさんどう思いますって聞いてみたかったのが、
本当にジュニア、OJTすんだかなぐらいのジュニアをプロジェクトチームに配属するときに、このぐらいまで親切に格好つけてモデル化してあげて、
じゃああなたはこれ今日作ってみましょうっていう風にやったら、作業時間、見積もり、実装コストでコントロールできるかもしれませんか、できるかもしれませんかっていうのがおかしい。
できるかもな、どうだろうなって思ったんですけど、どう思います?
げんえい
そうですね。
僕だったら、まあペアプロやるかって言うんですけど、一旦それを置いておいて。
だからそこまでやっていけば、あとは作業者として、もうコードを書いてねって言ったら、じゃあ今日の午前中には終わるかな、
今日の夕方には終わってるかなみたいな見通しは結構つきそうな気がしますね。
きんじょうひでき
出れなくなりますよね。
げんえい
そうですね。
きんじょうひでき
二次コードを書いたんで、あとは翻訳してくださいって言っているのに近い気もするんですけど、
なんかでもそういう世界観だなって思ったら、確かにこれは見積もりっていう意気を出して、予測の世界になってくるなっていうのはちょっとイメージつくかもなって、
僕これ読みながら思ったりしたし、じゃあそれのためにどのくらいコストかけるんだっけな、やっぱり頭痛いなって思いながら。
げんえい
でもこの当時で考えると、みんなの手元にコンピューターがあるわけでもなく、
その場ですぐ動かして結果フィードバックを得られる状態じゃないときに、
二次コードまで書いて、あとはこれをコードに落とし込んでねっていう仕事を、
ある短期集中なのかわかんないですけど、やってねっていうのは、確かにありえるかもなみたいな世界観はちょっと今思い浮かびましたね。
きんじょうひでき
そもそもアレか、自動カテッドとかないのか。
げんえい
ないんじゃないですかね。ちょっとしたそういうツールを作ってるとかはあるかもしれないですけど。
きんじょうひでき
スモールトークとかですよね、いい感じにユニットテストやり始めたのが。
げんえい
ぐらいだと思いますね。で、今この中で出てきた本の中に出てきたやつをコボルとかフォートランで書きましょうみたいな、
なんかそんな世界観でしたね。
きんじょうひでき
そっか、だから我々が気軽にテストって言ってるのは、この時代だと本当にあれですかね、
テストケースっていうのが自然文に書かれたなんか、エクセルも多分この時代まだないと思うんですけど。
ジュニアへのOJT
きんじょうひでき
テストケース。
げんえい
紙に書いてあるじゃないですかね、テストケースが。
きんじょうひでき
確かに、確かに。で、それをテスターの人が全部最初から実行して直して通った通ってないみたいな話ですかね。
げんえい
じゃないですかね。
きんじょうひでき
それは確かにフィードバックコストが重すぎるから、そうか、そういう世界観だと確かに設計頑張ろうってなるか、詳細な設計まで頑張ろうってなりますね。
げんえい
まあちょっとこれは本当にそうなのか、ちょっと時代背景が全然わかんないけど、けどまあでも少なくともそういう時代はあったわけですよね。
一人一台じゃなくて、どっかのサーバーが一個あって、それをこうみんなで人間が管理してタイムシェアリングするというか、
その一台のデカいコンピューターを実行できるのはこの人で、その間は他の人は紙に書いて機場でデバッグをするみたいな。
だから多分機場でプログラムを書いてみるみたいな話がこの本の後ろの方にあったような気がするんで、
まあ多分だからやっぱりそういう時代なのかなみたいな。
あれってヒューじゃないのか。本当にか。
っていうような世界観じゃないかなって思うと、まあ確かにさっき金城さんが試行実験として、
これぐらいの疑似構造だったりとかのレベルで説明をしてくれたら、
じゃあこの人が実際その文章を、ある種日本語で書かれたドキュメントを見ながらコボルに書き換える。
コボルで動くように書くっていう時間をどれぐらいとするかみたいなことを考えると、
まあ現代風に言うとコーダーとかになるのかわかんないですけど、
考えるとまあ確かになみたいな気持ちにはなりますね。
きんじょうひでき
なるほどな。話が若干飛ぶかもしれないですけど、
大学の時にどの学部でも受けられる授業っていうのは結構充実した学校だったんで、
そこの中でちょっとソフトウェア開発、結構上流寄りのやつをやった授業があって、
なんかユースケース記述とかっていうのをそこで触れてるんですけど、
まあ事前条件、事後条件、メインフロー、大体フローとか例外フローとか、
なんかあれ大学のそういうパソコン触りながら頑張って書いて、
そこから今社会人になってやってみると、
あそこまで厳密な日本語を書くんだったらコードを書きたいなーっていう要求が
僕は今抑えられないなって思っちゃったんですけど、
なんかでもそうですね、当時の本当にどうやってフィードバックループ回すかみたいなのが
だいぶコスト高い背景があると、なんかこういうのが、
ユースケース記述自体はすごい有効だし、うまく使えばめちゃくちゃいいのはと思うんですけど、
なんかね、より時代的な背景が加わってくると、
その擬似コードでまず書いてみましょうとか、
仕様を本当にギチギチに明確にしましょうとか、
そういうことの重大性、重要度って上がってくるんだなーっていうのを今ちょっと想像しながら思い出して、
思い出しながらめちゃくちゃ遅かった学校のWindows XPにちょっとイライラついてました。
げんえい
まあ、仕事始めた当初とか、エクリプスを立ち上げるのに、
なんか10分、15分みたいな世界だったなって、今そういうのを思い出しましたね。
とりあえず出社してパソコンの電源を入れてエクリプスを立ち上げて、
その後コンビニに朝ごはんを買いに行くとかやってましたからね。
きんじょうひでき
そうですよね。学校のメディアルームみたいなところで電源入れてから、
上列とかで来てたんで、満喫代わりに使うやつが行ったせいで夜来れたりしたんですけど、
寝カフェ代わりに。で、自分の晩が来て、駅を確保して電源入れて、
で、その後確かにコンビニに行ってたなみたいな気がした。
げんえい
だからもう、やっぱり今が早すぎるというか。
きんじょうひでき
そうですね。だから本当にフェイルファストというか、
一旦作ってみて失敗して、そこから取り返した方が早いっていう、
高速化された時代になってくるとやっぱり、
この本で語られている世界観っていうのはだいぶ、
言うて30年ぐらいしか経ってないっちゃ経ってないんですけど、
だいぶ違うなーっていう気はしてきますよね。
そうですね。
でもとはいえ、どのくらい時間がかかるかなっていうところのコントロールに
重きを置くんだったら、確かにこの第2部で言われているようなモネル化と、
青本がないので、予測っていうよりか見積もりの世界で
ピチャピチャ遊んでるに過ぎないかもしれないんですけど、
本当に分解して分解して分解して、そこにある程度の係数かけて、
どのくらいの時間で収まるでしょう、さすがにいけるやろみたいなところまで
追い込んでいくっていうのは、今の時代でもそこまでやる必要がある、
そこまでコントロールする必要があるんだったら、たぶんやるんだろうなーって思ったのが、
さっき言ったOJT上がりのジュニアをどうやって受け入れていくかってのを考えたときに、
一個なんか要なんだろうな、妄想レベルですけど、
思考過程とリファイメント
きんじょうひでき
ちょっと考えてみる、遊んでみると面白いのかもなって思った感じでした。
僕はやらないんですけどね、さっき言ったように。
でもちょっとさっきの話を聞きながら、
げんえい
実際に手を動かす、行動を描く場面じゃないところでは、
でもたぶん我々結構裏側というか、
物を見たときにこれどうやって作るかって考えるときって、
それができないと結構しんどいじゃないですか。
例えばリファイメントをしましょうってなったときに、
これどれぐらいでできそうか、ポイント作業を見積もりましょう。
時間でもいいんですけどね。
パッと見積もれって言われたときに、
これどうやって実現するかわかんないなとか、
実現する方法がわかんなかったら聞けばいいんですけど、
でもどういう思考をしながら、
例えばどういうインプットがきて、どういうアウトプットがきて、
どういう分岐経路がありそうかとか、
どうでもいいって言い方をするとあれだな。
だから本質的に必要な分岐と、
作っていく上でどうしてもしょうがなく出てくる分岐の場合は、
本質的な分岐だけ考えておけばいいよねとか、
そういうことを考えながら、
どうやって実現するかわかんないなとか、
そういう風に考えながら、
そういうことをなんとなく推論する能力というか、
みたいなのはやっぱ必要で、
それをどうやって身につくかって言ったら、
人の思考過程みたいなのをトレースするみたいなことは、
どっかで必要なのかなとか思ったりして、
そう考えるとさっきのOJTの話って実は割と大事だったりするのかな、
みたいなことはちょっと思ったりしましたね。
きんじょうひでき
僕真逆のことをさっき話しながら思ったのが、
一番大事な考える部分を完全に巻き取ってるなっていう気がしたんですよね。
なので本当に、いわゆる上流と下流のコーダーの分離、
埋まらない溝みたいなのができてくるんだろうなみたいな。
げんえい
そうですよね。
なので自分は割と最初にとりあえず穴埋めで、
やらないけど穴埋めでコードを書いてもらって、
だんだんその穴を大きくしていくというか、
いうことでも一個やり方としてはあるかなっていう。
それやるより横につけて、
ほら容器はこうだろって言って一緒に、
つまりこれってこういう風に分解できるやろ、
つまりコードここでまず分解するやろって言って、
品質と生産性の関係
げんえい
やってた方が早いとはもちろん思うんですけど、
横につけて一緒に作業ができない状態だったりとか、
スケールさせるためにとか、分かんないですよ。
きんじょうひでき
そうですね。
予測、3時間ぐらいで終わるかな、
半日ぐらいで終わるかなっていう精度を上げるよりは、
俺が隣にいてやれば2時間で終わるしなの方が、
げんえい
早くできるじゃんみたいなところですよね。
きんじょうひでき
だからそれもさっき言ったコストの予測っていうところも、
相対的な重要性が落ちてきてるなっていうのは、
げんえい
そういう話もありそうだなみたいな。
結構この中に出てる設計の話の中で、
要求仕様とか機能としてどういうものが必要とか、
その時にどういうデータを保有してるんだっけとか、
どういう状態遷移があるのかとかって、
この辺は今でもみんな考えないといけないしとか、
それを考えないから状態遷移がぐちゃぐちゃになったりとか、
同一の状態のことを、別々の状態のものを同じ言葉を当てて
喋っちゃってるせいで、
きんじょうひでき
遠距離インズミユーザーとか。
げんえい
そうそう。
とかってことが多分いっぱい起きてるんだろうなと思って、
この本に書いてあることは全て無駄ではなく、
現代においても全然同じことやってるんだけど、
表現方法だったりとか、どれぐらいの流度でそれが必要かとか、
いうところは全然違うんだよねっていう風に読みながら思ってましたね。
きんじょうひでき
そうなんですね。
本当に玉ねぎとかタベツみたいに皮を剥いて剥いて剥いていくと、
げんえい
やりたいことって結構だいぶ似通ってる部分があるというか。
きんじょうひでき
たださっき言った開発の楽さとか、
使ってる言語とかパラダイムによる柔軟性、
それこそオブジェクト思考だとフワフワと書いて、
なんちゃら中小クラスで誤魔化しなくなって詰められるのを、
手つぶき型だと結構誤魔化しようがないぞみたいな、
そういう硬直性というか縛りのきつさみたいなものがあったりはすると、
やっぱり作ろうとしているものがソフトウェアだし、
動かそうとしているものがソフトウェア開発者なんで、
本当に似てる部分はすごいあるんですよね。
僕のげんさんが今言ってたような状態遷移とか、
そこら辺の3つをまずまとめましょうっていうのはすごい、
めちゃくちゃ明確に語ってくれてるのはそうだよなって思いながら、
ちょっと読んでましたね。
げんえい
機能モデル、保有データモデル、状態遷移モデル。
これ今すっ飛ばすと、状態遷移モデルとか、
その状態に応じてちゃんとデータ取っとかんと死ぬのみたいなことってあるんだけど、
しかしデータベース上のアップデートをかけて状態が消えましたね。
なんかね、ありますからね。
きんじょうひでき
面白いな。
げんえい
あと結構この本の中でモデル化の1個大事なことで、
インターフェースの話が出てきて、
これはプログラムのインターフェースとはちょっと似てるようで違うかなと思いながら読んでたんですけど、
物を分離していくときにインターフェースの接合、
依存って言い方をしていいと思うんですけど、
依存ができるだけ少なくなるように切りましょうねみたいな話がこの本出てきていて、
モデル化の指針としてインターフェースの数を最小にするように切り分けようっていう指針として1個、
そういうものがあって、
この辺とかってどう切り分けたらいいかなとかって悩む人にとっては、
こういう指針が1個あるとすごくいいんだろうなって思ったりしましたね。
きんじょうひでき
そうですね。
げんえい
それこそクリーンアーキテクチャ的な世界観とかにも通ずるはずですしね。
あとは例えばマイクロサービスとかもそうだと思うんですよね。
結局依存がめちゃくちゃあるのに、
それでここだって依存がめちゃくちゃでかいマイクロサービスを作っちゃったら、
それ失敗するわけじゃないですか、やっぱり。
きんじょうひでき
いや、一緒に暮らした方が幸せになるよみたいな。
なんで別調してるの?みたいな。
げんえい
なのでこの辺って30年40年経っても、
やっぱり本質は変わってないんだなみたいな気持ちになりますよね。
きんじょうひでき
そうですね。
げんえい
そこら辺を考えていくと複雑度とか、
きんじょうひでき
全体的に何が組み上がっていくのかっていうコストが見えるっていうのを
くっつけて考えてるのが本当に面白いなっていう気はしますよね。
なので結構パート2は分量的にも、
この本の中だと重め。
第2部ですね、パート2って。
分量的にも重めなんですけど、
なかなか学び得るものが非常に多い気がしますね。
モデル化の指針
きんじょうひでき
まあでも結構話してる。
げんえい
次進みますか。
進みますか。
きんじょうひでき
パート3ダイソムが仕様予測なんですけど。
