00:06
データフローダイアグラムという話が出てきましたけど、要するにフローチャート的なもので書けばいいじゃん、みたいな話っていうのは一応言及されつつなんですけど、
データフローダイアグラム、僕すごいなーって思ったのが、本当にデータの流れなんですよね。
ネットワーク図的に円、楕円じゃないか、正円、丸と丸を矢印でつないで矢印にちょっとラベルつけましょうとか、丸の中に名前書きましょうみたいな、そういうシンプルな図なんですけど、
これプロセスじゃなくてデータのフローを表しましょう。まずそこに注目しましょうっていうふうに説明していて、革新的でクリティカルなツールだっていう風に言ってるんですけど、
何が違うかっていうと、ツールだったらどういうインプット受け取って、どういう作業、どういう変換をして、どういう出力をするか、みたいなのが矢印と丸で表されると思うんですけど、
データフローは本当に受け取っているデータと出力されるデータにだけ注目してくださいっていう話していて、
それやると物理的な観点から切り離されてデータの流れだけに注目できますみたいな、それが大事だって話をしてるんですけど、
普通のワークフローと何が違うかっていうと、〇〇さんが、〇〇部署が受け取って次の部署に渡しますみたいな、部署とか登場人物とか、作業の内容みたいなものがデータフローダイアグラムには現れてこないんですよね。
草庫に格納してそこで検品して出荷しましょうみたいな話だと、倉庫って物理の世界だよねとか、検品担当者みたいな話をしたら、それはデータ以外のノイズが入ってるよねぐらいの感じで聞き詰めてて、
こんなに純粋にデータっていうところに着目して、概念作ってみるところからやるんだなーっていうのがちょっと目当たらしかったですね。ここは僕やったことないなっていう気がして。
そうですね。やったことはないですよね。この辺とかってデータの流れを示しましょうと言って、コントロールを示すものではないですよっていうような言い方をしてるんですけど、コントロール絶対書いちゃうよなって思いながら。
結局どういう風に業務の中に物事のデータが流れているかっていうのは、たぶん現場にいる人はなんとなく自分の周囲はわかるけど、システムを作る上では全体がわかんないとできなくて、
全体を見るときにはそれぐらいの抽象度というかレベル感、レベルっていうのは抽象度が高くないと、把握が結構難しいのかなっていう制約からこういうのが来てるのかなっていうのは一瞬ちょっと思ったりしましたね。
03:14
なんかね、そこまで突き詰めていくと、強力なツーに綺麗な抽象化ができるというか、一番本質的なところにだけちょっと目視して、逆にこの本質じゃない些細なことっていうのが入り込んできたときに、
実装の開発のフェーズというか開発者の柔軟性が失われて、少しずつ少しずつ歪になっていって、組み合わさらなくなっていって、最終的にすごい破綻が招かれるみたいな、そこから悪い意味じゃなくていい意味でちゃんと逃げようというか決別しようみたいな挑戦をちょっと感じたりとかしましたね。
ある種データの流れこそが正義であり、なんていうか変わらないっていうことなのかなっていうふうに思っていて、業務フローみたいなものはもしかしたら変わるのかもしれないけど、インプットとアウトプットは絶対一緒でしょと、そのインプットとアウトプットの取扱いの中身の順番、プロセスだったりとかそのコントロールが、今まではなんとかさんがチェックしてたけど、いやそれより前にあの人がチェックした方が良くないみたいなとか、そこは変わっちゃうかもしれないけども、
結局最終的に国にこう提出するものはこれだよねとか、入ってくるものはこれだよねって変わらないから、そこに着目をするとうまくいくのかなっていう着眼点でこういうものを作ったのかなみたいな、そんなことをちょっと思ったりしますね。
そうですね、データフローダイアグラムの作り方というかコツみたいなところで、注意すべきポイントとして挙げられてて一個、なるほどって思ったのが、これあれだな、言葉で言ってもなんか当たり前じゃないっていう感じになっちゃうんですけど、インプットとして与えられてないものが出力に含まれていないかチェックしなさいって書いてあって、
原価みたいなものをインプットとして受け取って、出力に税込み価格みたいなものが書いてあったら、いや税率はどこから来たんですかみたいな、そういうところが漏れてないかっていうのをちゃんとチェックする必要があるよね、的な話がね書いてあって。
そうですね、いやーこれ、でもいざ作れって言われると結構スルッと書ける気はなんとなく自分はしないなと思ったんですけど、どうでしたか。
全体的にそうですね、この本。
いやなんか遊びでやるんだったらめっちゃ便利だなって思うんですけど、ガチでやろうとすると、いやちょっともうちょい軽量でいいですみたいな感じがしつつですけど、
ただこの本の立場からしてみると、全てが揃ってないと魅力半減するよぐらいの雰囲気もあるはある。
そうですね。
なんかね、スクラムじゃないけど、スクラムバット的な、一個かけたら全体が成り立たないぞみたいな。
06:01
そうそう、ここだけちょっと自分たちに合いそうだから取ってきても、まあなんかしょうがないというか。
そうですね、そういう感じもありつつなんですけど、だからガチでやるのが難しいから常日頃からこれをやるのは大変そうだなと思ったんですけど、
何かがうまくいってないなみたいな時に、ちょっとじゃあこの手法を使ってみるか、で問題を整理してみるかとかはすごい有用なんじゃないかなっていう気がしてますね。
まあわかんないけど、チームでレトロスペクティブやって、なんかコンスプはちょっと認識のそごとかバックログ決まってたけど、
それをやり始めてからPDMに確認することが多かったねみたいな、なった時に、それってもしかしたら、なんかちょっと観点変えてデータの一緒を追ってみようか、データフロダイアグラも書いてみようかみたいな感じでやると、
まあそれが本当にうまくいくか全然わかんないんですけど、今まで見えてなかった部分、視覚だった部分っていうのを炙り出すぐらいの、もしかしたらそういう効果はあるかもなーって思ったりと。
まあでも、現代において誰もやってないって言うと本当かどうかわかんないけど、まあ少なくとも周りではやってるって話は聞かないので、
なんでこれが現代に残ってないのかなみたいなところとかちょっと思ったりしながら、まあ難しいからかなっていうのが一番シンプルに思ったんですけど。
分析フェーズみたいなところの重要性は多分下がってきてるでしょうね。
なんか1年間じっくり考えて物を作るってよりは、早く作って失敗を繰り返してそこから学び終えましょうっていう方が現代っぽいですよね。
もちろん分析してないとは言わないですけども、でもその分析にかける時間と実際物を作ってユーザーに使ってもらうまでの時間みたいなところとかの配分みたいなものは結構変わってるよなっていうのはちょっと読みながらすごく思いましたね。
そうですね。だからなんかもしかしたら現代でもこのデータフローダイアグラムっていうのを一番のメインウェポンにして開発進めていったらめちゃくちゃ物事が超はかどる、なんか大パーツ拾いましたみたいな感じになるかもしれないし、
それよりもなんか別の形に生まれ変わって流通している可能性がありますよね。
そうですね。
そっちの方が可能性高いかなと思いつつ、じゃあこの世界観とか信念を受け継いで今どんな姿をしているのかっていうのはちょっと僕パッと思い浮かばなかったので、どこ行ったのかなーっていう気持ちにはなってます。
まあそうですね。見ないなーっていう気持ちもすごく思いながら。
09:01
やってみてくださいよ、ゲイさんのチームで。
言うぜねー。いやー今の状態だと、いや、なんかそんなんいいから早くリリースしようぜみたいな。作って、作ってユーザーに触ってもらって確認。
2週間に1回ユーザーに会いに行ってさ、こう作ったものを見てもらってフィードバックもらおうぜとか、まあチームの勢いとしては強いっていうか、まあそれを推し進めてるのは俺なんだけどみたいな感じなので。
コタクとも話す、データ不老大悪でもぶつかるみたいな。
でもなんか本当にリリーフじゃねーや、ティンポイントでさらさらっとこの図式を使って、ちょっとやりたいこととか必要なこと整理してみるっていうのはありえそうな気するんだけどなー。
なんか使ったら結構効くんじゃねみたいなのは思いながら、逆に何が難しいと自分はこれを読んで思ったのかなみたいなところをちょっと言語化してみると、やっぱりこの丸の単位とかそのフローの単位とか、
書き方のコツの中にというか、細かいエラーは一旦無視するみたいなことが書いてあったりとかして、まあなんかその曖昧さだったりとか、どういう抽象度で整理するか。
このデータ不老ダイアグラムのその1個のデータ不老、まあ変換の話の中にも多分結構抽象度高く書いて、
実際もっと細かい話言って、このサブを作ってみようとかみたいなところもあったりとかして、そこの抽象度をどう設定するとうまくパッと見のわかりやすいドキュメントになるかとか、その統一感を持ったドキュメント。
なんかこっちはすごく詳細まで書かれていて、こっちはすごく漠然としたことしか書いてないみたいなことが結構起きたりとかしそうだなと思って、
それをチームで抽象度を揃えながらドキュメントを作っていくって結構難しいなと思って、だからこそルールとしては割とシンプルなんだけども、
人間が頑張って書くような部分の中で簡単に誰がやっても結構近いものが出てくるっていうところが難しさがあって、
結果こんな難しいことやってるより、別にこれ作らなくてもものは作れるんだからいいじゃんって言って使われなかったのかなみたいなところはちょっと思ったりしてましたね。
そうですね、完璧にやろうとするとやっぱりすごい難そうというか、そもそもアナリストっていうのが専門職というか専門的な上級職だと思うので、
その人たちが切り札として使うツールみたいな感じはあるんで、難しいんだろうなって思いつつ、じゃあなんか雑にやればいいかっていうと、
面白そうだなって本読んでて思ったポイントでもあるんですけど、このデータフローダイアグラムっていうのを書いて丸と丸をたくさん書いて名前つけて、
矢印でつなげてみてみたいな風にして、データの入力とか出力っていうのを矢印で示していくっていう手法なんですけど、
12:06
矢印の数が一番少なくなるように全体のフローを整理してみよう、そうするとすごいしなやかなというか変更に強くて柔軟なシステム全体が成立していくぞみたいな話が書いてあったりだとか、
どういう風に分割するかっていうのが図にして表してみることで見えてくるはずだみたいな話が書いてあって、
なんかそれできたらめちゃくちゃ良さそうだなーとか思ったんですけど、ただその恩恵を受けるには、矢印さんが言ってた通りマジでちゃんとやらないといけないと思うので、それは大変そうだなーみたいな。
このデータフローダイアグラムでやらなくてもいいかもしれないけど、何かしらででもそれはやっとかないと、結局マイクロサービスが三つ結合しましたとか、
システムの君と君は本来一緒のとこにいるべきじゃないはずなんだが、みたいなものが起きたりとかっていうのが多分して、さっきの繋がる線が少ない方がいいっていうのは、つまり結合度が素結合にうまくシステムができる、依存が少ないってことだと思うんで、
でも割となんか図を使わないから多分我々は気づいたら全然そんなことをある種すっ飛ばして作っちゃって、後で取り返しがつかないことになってたりするので、まあそうですね、どっちがどっちがいいんだろうなっていう気持ちもしながら。
でもそうですね、データアローダイアグラム自体は要求分析とかビジネスの分析みたいな話なんで、ちょっと実装とかソフトウェア設計って話とはちょっと違うよって話がこの後半でも出てきたんですけど、っていうエクスチューズを聞きつつ、今のげんえさんの話聞いてて思ったのが、思い出したのが、
今年のペチパー会議のパンフレットに僕なんかリファクタリングしてみようみたいな記事を寄稿してるんですけど、それやってた時にクラスとかプロパティ単位で依存関係、どのメソッドからどのメソッドが呼ばれてますねとか、このプロパティが参照されてますねみたいなものを全部手書きで、手書きって言ってもメロとか使って一回全部つなげてみて、
最初にそのまま既存のコードをそういう図に表してみると、すごいぐちゃぐちゃした見かけになると思うので、これをいい感じに並び替えたりとかしてみると、リファクタリングすべき箇所っていうのが透けて見えてくるかもよみたいな話を実験はしてましたね。
果たして本当に説得力あるんだろうかって思ったのと、単純にページ数が足りなかったんで、多分外に出したいんですけど、図にしてみて複雑というかこんがらがってる状況っていうのを可視化してみるパワーってすごいなっていう気はしますね。
今ちょうど偶然にも手元にページパー会議の冊子があったんで、今パラパラめくってます。
15:08
でも結局、ソフトウェアがうまくくれないコードを書いていて、なんかぐちゃぐちゃになっちゃうって経験って多分誰しもやったことあるはずで、なんかこっちから振り直したらあれ壊れるみたいなこととかって。
本来それって起き得ないはずなんだけども、起きちゃってる時って、コードが悪いっていうのは、まあその表層化されている問題点としてはそうなんだけど、真相の部分っていうのは多分本当は依存関係がないところに依存があるとか、レースっていうクラスを継承したが故にすべてがこう爆発するみたいなとか。
共通化だって言って共通化してみたら、いやこれとこれは共通じゃなかったんだよなみたいなところがうっかり混ざり込んでしまって、最後爆発して終わるみたいな。
そうですね、なんかめちゃくちゃ責任感の強いユーティルクラスができたみたいな。
そうそうそうそう。だからまあそういうところをやっぱ整理するのをソフトウェア開発者は多分コードから見ながら言ってるんだけど、本当はなんかもうちょっと別の視点を手に入れることによって整理の仕方みたいなとか方法だったりとかが得られるんじゃないかっていうのは結構ありそうだなって思いますね。
だからこう理解がしやすいコードを書いたりだとか、ベテランの力のあるベテランの人たちってそこら辺を半分無意識に頭の中でやってるというかそういう見え方してるのかなみたいな気がしますよね。
ということはやっぱみんなにこの図を書いてもらうしかないのかな。一回体験してもらうと見え方が変わる可能性がみたいな。
そうですね。プリント3日目までは分析フェーズだからって言って。パソコンは使わなくていいんで。紙とペンたくさんあるから。
オフラインに集まって線をいっぱい貼ってもらいながらホワイトボードに線を引きながら繋げていきましょうみたいな。
面白いね。ミニウォーターフォールをガチでやるの面白いですよね。
最近一緒に働いてる若者とか見ながら思うのは、そういうことをやるタイミングが全然なかったんだなっていうのもあって。
そういうことをやらせるのも大事かなって一瞬ちょっと思ったりとかしていて。
それどういうことかっていうと、じっくり時間をかけて設計して、もうちょっと対極的にものを見て判断していくみたいなことをやらないと、もっと細かい設計がうまくできないのかなとか思ったりして。
1週間とかのスプリントだとやっぱり目先のゴールのために、これも大事は大事なんだけど、目先のゴールのためにどうやって設計してどうやってものを作っていくかみたいなところが考える能力がつくかもしれないし、
一旦これで行こうみたいな思い切りみたいなものはできるかもしれないけど、もうちょっと先にあるものを考えながら今どうしたらいいんだっけとかどうやったら柔軟さが手に入るんだっけみたいなところってやっぱり追い立てられてなかなか考える暇がないなって思ったりとかもちょっとして。
18:11
そこの辺って結構あるし、自分はどっちも経験している。半年とか1年のプロジェクトでじっくり考えてExcelに頑張って図を書いてやってたりっていうこともやったし、1週間のスプリントで一旦設計してこの先作っていくみたいな両方経験はしてるんだけど、
新卒で入ってきていきなりスクラムのチームに入って1週間スプリントとかになると、そういう経験なくて、それはそれで結構大変かもなってちょっと思ったりしたんですよね。
そうですよね、なんかボカロとかDTMが簡単にできるようになったから音楽理論知りませんみたいな。
僕も全然そういうのやったことないので、じゃあゲインさんから見たら僕も最近の若者ってことかって聞いてたんですけど、どっかのタイミングで自分で求めていくというか、
ちょっと何かが足りないなっていう反応をまず示して感じて、そのためには何をすればいいんだろうかっていうところで、別に構造化分析として進む仕様にいきなりいかなくていいと思うんですけど、
ちょっとじゃあ設計っていうのをこじ据えて座学的に勉強してみるとか、知識をつけながらちょっと手を動かしてみるっていうのは動く行動を書くことじゃなくて、一回我慢しながら紙の上で机上の設計をやってみるみたいなところっていうのが必要だな。
ちょっとめんどくさい大変そうだけどでも頑張ってやるかないかっていうところまで一人でに、世界中の全若者にそこまで勝手にやらないと生きていけないよっていうのはなかなか辛そうですもんね。
そうですね。
どっかで腰を据えて、しかもある種こういうことは1年後のリリースですみたいなので、じゃあまず設計フェーズで3ヶ月とかってやると、いろいろ話を聞いたりとかできるチャンスもあるし、教えてもらえるチャンスもあるし、そういうところは良かったのかもなーってちょっと思ったりしましたね。
そうですよね。他人が作った設計に従って行動を書くみたいな経験すら多分してないので、自分を振り返ってみるとわかんないですよね。
21:00
そうね。究極的にはフレームワークがそっちゃそうというか他人が設計したもの。
確かにな。僕のアーキテクトはずっとケーキPHPだったから。
やっぱそのケーキの気持ちを考えながらこう書くんだよな、おさほはみたいなとか、レールから外れない方が今後のためにいいみたいな。
そうですね。
それがある種現場レベルでいくと、現場現場で特殊なフレームワークを作ってたりとか、設計思想みたいな治安を守るためにはこういう風に考えますみたいなのがあったりすると思うんで。
実装レベルの仕様とか設計ならそうなんですけど、やっぱりさっき言ってたね、データフローダイアグラムとかそういう話だと全く別ですしね。
なんでこうなってんだろうって言ったら、いやこれは過去の経緯でみたいなのがいっぱい出てきたりとか、原稿踏襲ですって言われて、なるほど原稿踏襲なんだな、で原稿は一体どうやってるんですかって言ったら、
いやあそこの動きの通りですみたいな、触ってるそのシステムの通りですって言われて、なるほどみたいなこととかね、いっぱいありますからね。
そうですね。
だいぶ止めどなく本の流れを無視しつつ話してますけど、なんかデータフローダイアグラム、構造化分析のターゲットドキュメントって言われてる成果物みたいなところの一つ目であるデータフローダイアグラムの話を今してますけど、
データフローダイアグラム的なところで他に触れておきたいことありますか?
いや難しいんだよな、どこまで細かい話をするかみたいな話はめちゃくちゃある。
なんかちょっと自分はこれを触れたらもういいかなって思いながら見てたのは、発祥がケーススタディになっているので、ある架空のプロジェクトがあってそのプロジェクトのためにデータフローダイアグラムを書きました。
データフローダイアグラムっていうのはそのデータの流れから、これを見ながら顧客と対話するっていうことを言ってるので、
じゃあ我々がこれを見たら、顧客ではないんだけども、それなりにシステムのことは理解できるようになるかどうかっていうところが、
実際このデータフローダイアグラムの威力というか、みたいなものが感じられるかなと思ったんで、
113ページに実際このポッドキャストなんで図を説明するのはすごく難しいんですけど、
百聞はいけにしかずっていう話をまさにしましたからね。
そうです。
なんでこれは読んでどうでしたかっていうのと、聞いてる人向けにどういうものを作ろうとして図を書いたかっていう説明をしておくと、
1960年代のイギリスで偉大なるシステム志向家と在会のリーダーたちが集まって一つの会社を作りましたと。
設立目的は英国の競馬卿たちから金を巻き上げることになった。なので競馬のシステムなんですよね。
24:00
レースの結果を占ってくれるサービスっていうものを作りましたよと。
それを一応分析して図を書きましたっていうのが113ページにあります。
金城さんはこれを読んでみて、なるほどこのシステムはこんな感じなんだっていうのがどうですか、分かりましたみたいなことはちょっと聞いてみたかった。
そうですね。関係する登場人物みたいなのは分かりますよね。
説明むずいな。
お前興味なさそういうバカみたいなこと言ったなみたいな思われてるかもしれないんですけど、
なんだろうな、データの出どころとかデータの向け先、渡す相手っていうのが網羅されているのってすごい大事だなと思ってて、
全然話それますけど、アジャイル侍のインセプションデッキでお隣さんを探せって言ってステークホルダー全部並べるやつあるじゃないですか。
ありますね。
あれと似た感じで、中心に自分たちのシステムっていう円があって、それを取り囲むように小作とか競馬場とかクレジット会社とかセールスマンとかっていうのが書いてあるんですよね。
銀行とは預金のやり取りするし、セールスマンに対しては売り上げ手数料というか報酬みたいなものが出力されるというか出ていくよねとか、競馬場からはレースの結果を受け取る必要があるよねとか。
これ関連システムっていうのは、システムじゃないですけどより一覧概念的なレベルの話なんで、これは普通に欲しいなって思いました。
そうですね。
社内の持っている情報とか社内から生み出す情報と社外なんだ、存在する社外から取ってきたりとか社外に渡す情報っていうのって意識できるとだいぶ楽になるはずなんですよ。
これのパワーは測り知れないなみたいな気はしてるし、外部システムと連携してないものって、ましてやこのウェブ系のシステムだとほぼないと思うんで。
特に僕、たまたま物流とかEC関わる会社が何社か続いてるんで、ECとか在庫管理めっちゃ大変じゃないですか。
大変ですね。
複雑にならざるを得ないんで。
そういう時にね、請求書ってどこに渡せばいいんだって分かるととても楽なので、だからこのズー40は僕はなんか良さそうだなって思いながら見てました。
やっぱこれが多分今では文章で書かれたりとか分かりにくい。
結局誰と何をやり取りしてるんだっけみたいなのがまとまってなかったりとかした。
もちろんね、ただにこの図だけはあったかもしれないけど、これの詳細度みたいなところ、その先にまだ詳細なデータフローみたいなものもあると思うんですけど、そういうところとかは多分なかったりとかして。
27:01
そういうところを考えるとやっぱ図で表現するっていうことの威力というかありますよね。
そうですね。今話題に挙げてるこれズー40なんですけど、ズー40はコンテキストダイアグラムとかレベルゼロとか言われてるところの図で、それがレベルゼロじゃないか、ゼロより上か。
さっきちらとげんさんも言ってましたけど、回想化して、要するに抽象度とか詳細度とかっていうのを揃えたレベルの立体的にというか回想化されたダイアグラムをいくつか用意しましょうっていうふうに説明されていて、
今言ってたこのシステムと小作がいて競馬場がいてクレジットカード会社があってみたいなのは、自分たちのシステムっていうのをブラックボックスとして見たときに社外、システム外の人たちとどういうふうに関係してるかなっていう一番抽象度が高いレベルで示しているコンテキストダイアグラムって言ってるやつですね。
僕はこのレベルからあるとすげえ欲しいなっていう話をしました。
これできっと聞いてる人にはこの本は役に立つんだっていうことが伝わるかなって思った人が。
売り込んでますね。
ここから矢印とかを掘り下げていったちょっと詳細よりのレベル、どっち低いレベルになるのか詳細より低レベルでいいのかな。
いいと思います。
例えばうちのシステムと銀行っていうのが預金、お金でやり取りするよねっていうふうなフローが書いてあるけど、それはもう少し具体的に言うとどういう情報のやり取りなんですかっていうのがまた出てくるわけですよね。
そうですね。で、ここの中で全部表しきるっていうのは多分難しいので、例えばお金のやり取りって現金なんですかカードなんですかとか小切手ですかとか多分いろいろ種類があったりとかするんで、
そういうところのちょっと細かいところとかっていうのは次の出てくるようなデータディクショナリーとかで明らかにしていきましょうみたいな感じになってますね。
そうですねそうですね。じゃあデータディクショナリーの話に行きますか。
行きますか。
ああでもあれか、この大発祥をゲインさんが取り上げてくれたついでに乗っかるというか、あれなんですけど、ちょっと僕らが知ってるトムデマルコっぽいなと思ったのは、
発祥の締めが競馬でどれに賭けるかを予測したい人のために補修代のデータを売りますよっていうわけわかんないサービスがケーススタリーなんですけど、
後日談としてこのビジネスはうまくいかなかったんで同社は倒産してしまったっていうふうに言われていて、
なんかついにこのユーマはぶっこんでくるのはデマルコっぽいなみたいな。
30:04
そうですね。
まああれですよね、結局うまくシステム作ってもビジネスがうまくいかなかったら元も子もないみたいな、そういう皮肉しかあるのかなみたいな。
そう、ほんとそうだと思います。
プロジェクトがうまくいかないし、プロジェクトがうまくいくコツを知っててもビジネスはうまくいかないしみたいな。
そう、いやほんとその通りだと思います。
上手にシステムが作れることと儲かるかどうかはまた別だよってことを案に入ってるんだろうなって思いながら読みました、この最後のところは。
そうですね。
補修棚絵はレース結果をうまく予測できなかったのであるみたいなことが書いてあって、こいつ何を言ってるんだみたいな。
それはそうだろうみたいな。
じゃあ次のツールであるところのデータディクショナリーいきますか。
そうですね。
いつも通り時間がおかしいですね。
そうですね。いや今回はなんか喋るとこ絞ったし、もうちょっとそんな喋んないんじゃないかなとかって思ってたんですけど、思ったよりいっぱい喋ってますね。
データディクショナリーが第3部ですね。
そうですね。
第2部がデータフローダイアグラムで、第3部がデータディクショナリーで、データディクショナリーはどんなものですか、どんなドキュメントを作れって言ってるんですかね。
データディクショナリー、登場してくるものの定義を明らかにしておかないと、例えばじゃあ何がいいかな、パッと例が出てこないけど。
その登場するものの定義っていうものをちゃんと決めておかないといけないですよと、そういうものを辞書としてまずまとめましょうというような話ですね。
じゃあその定義する項目の種類っていうのはどういうものがありますかっていうところで、データフローとファイルとプロセスとデータの要素みたいなものがあって、
データフローとかファイルとかプロセスってのはさっきのデータフローダイアグラムの中にはもうすでに登場済みなので、ちょっとここではぶかれてたりするんですけど、
データの要素みたいなところがありますよと。データの要素っていうのは、じゃあこのデータっていうのは何から成り立っているのかみたいなところを明らかにしていって、一個一個分解していくみたいなところですね。
そういうものをまとめたものがデータディクショナリーっていうものですね。
そうですね。ファイルだけちょっと独特だなっていう気がしますけど、多分後で出てくるでしょうファイルは。
そうですね。
データディクショナリーはなかなか単純に言うとデータフローダイアグラムの中で出てくるいろんな名詞とかそういうものにちゃんと定義しましょうみたいな話なので、
これはね、分かりやすいっていうか、要はバランスなんですけど、これは普通に社内のウィキにバッてまとまっているとめちゃくちゃ助かりそう。
そうですね。
誰がまとめるんですかっていう時に、ちょっと私は外してくださいっていう感じになっちゃうんですけど、大変そうなんですよね、全部ですから。
33:06
うん。
この本に書いてあることはやろうとすると大変そうだけど、あると便利そうだなって感じですね、全部。
そう。完璧を目指すとマジで時間が足りんみたいな感じになるし。
専門家が必要ですね。
手抜いていいかって言われると、いやでも手抜かれるとそれは困るんだよねみたいな気持ちもなるし、じゃあ完璧にやるんですかって言われると、いやでも時間は有限なのでみたいな言ったり来たりしながら、はっきりしてくれよっていう風になるなみたいなことを思ったりとかしながら。
そうですね。定義っていうのをどのくらいしっかり管理するおつもりなんですかみたいな話で言うと、例えば定着名簿っていう名詞、概念があった時に定着名簿とはっていう項目というかページを一個作って、
定着名っていうさらにサブ概念があって、定着名の反復に等しいっていう風に独自の用語、記述方式を使ってデータディクショナーに管理していきましょうみたいな話なんですけど、
反復っていうのはプログラミング的に言うとループ文、要するにリストですね、イテレーション、コレクションみたいな話なので定着名簿とは複数の定着名から成り立つものであるみたいな話をデータディクショナリーっていうところにぶち込んでいって、
お前らがシステムの話をする時に出てくる用語を基本的には全部ここにぶち込んでおいてくださいみたいな、そうするといろんなドキュメントを読んでも、これは何だろうっていう素語が全部無くなるから最高ですよみたいな話をしてますが、まあねって感じ。
そうですね、まあなんか登場するものすべてを記述すればすべて絶対人間は理解できるでしょうみたいなのはまあそれはそうみたいな気持ちになりながら、できるのかいみたいな気持ちにもなりますね。
どのくらいコストをかけてこれを管理するんだ、メンテするんだみたいな話もありますよね。
しかも例えば乗客名、乗客名はそれ以上分割することはないかもしれないけど、乗客名っていうのは乗った人の名前、これから乗る人の名前かもしれないですけど、ある種自明なものまでいっぱいあって、自明だと思ってたものが自明じゃなかったから大体バグは起きるんですけど、難しいですよね。
難しいですね。どの時点で乗客名とみなすんですか、買った時点なのか乗った時点なのか、注文をしようとした時点でユーザーイコール乗客名みたいな感じでいくのかとか出てくるはずですからね。
そんなことをいちいち全て記述していたら大変なので、でももうちょっとこれを読みながら思ったところって近いかなって思ったのは、例えば消費税の計算ルールとかってこれに近いのかなみたいな思っていて、
36:09
一律10%っていうのが今だとそうだと思うんですけど、でも軽減税率ってやつもあってたなみたいなのがあって、そういうことが記述されて集まってたりするのかなって思ったりもちょっとしてましたね。
ある種ちょっとビジネスロジック、ビジネスロジックイズなんだっていう話も諸説ありって感じがしますけど、ビジネスロジックに近いものが集まってるのかなっていうふうにちょっと読みながら思ってました。
DDDの世界観ですよね、ドメイン知識ですよね、ここら辺が。
そうそう、自分だと今人的資本の情報開示みたいな、あまり聞いたこと聞き慣れないようなものがあって、その中に例えば会社はこういう指標を出しなさいよみたいなことが書いてあって、その指標ってどういうことなんですかっていうのが計算式が書いてあって、
その計算式の中にある、例えば女性管理職比率とかがあったときに、じゃあ文房は何になって分子は何になるのか、管理職っていうのは何なのかみたいなことを肝解いて分解していって、分解できるとこまで書いておくと、
たぶん後からプロジェクトに入ってきた人とかがパッと見たときに、じゃあこれって、この概念ってのはこういうことなんだろうねっていうのがちゃんとディクションありとしてまとまっていると、キャッチアップしやすかったり検索して出てくれば自力で解決ができるよねって思ったりとかして、こういうのはちゃんと整備されてるっていうのは大事だよねってことはすごくわかるみたいな。
大事ですね。それこそ本の中で言うと、例字がもちろんいくつかあるんですけど、164ページで電話番号っていうのが定義されてて、この会社での電話の扱い方だよみたいなダビルはつきつつなんですけど、
9プラス外線番号と8プラス市街特番みたいな番号プラスなんちゃらなんちゃらみたいなだいぶ細かく定義されていて、これぐらいの細かい定義になると電話番号のバリデータは書けるじゃないですか。
何から始まる筋で何桁の塊がまずあって、その次にこういう塊があってみたいな。仕様とか概念が明確になってくる。本来は本当にそういうことなんだろうなと思ってて。バグらないですよね。電話番号を扱うっていうことは要するにこのバリレーテッドなデータが来るはず。
っていうのが誰が見てもデータディクショナリーに書いてある通り、それ以上で見えかれまないみたいな話なんで、そういう世界観だよなって思いながら。逆に言うとそのぐらいの解像度のことをシステムの中でシステムとかビジネスで出てくるすべての概念に対して一貫して高いクオリティ高い水準で管理しよう、更新し続けようって言ってるんでちょっと待ってねっていう感じ。
39:10
そうですね。それはアナリストっていう職業というか、やる人が必要だわっていう感じになりますよね。ある意味では現状あるものに対してはそういうふうなアプローチはできるけど、じゃあ今後やっていくもの、まだないものに名前をつけていくとか、まだ分類されてない解像度が荒く世の中でみんなが捉えているものを実際サービスとして扱っていったら、あれこれって実はこういうこれとこれに分かれるんだよねとか。
分かれるルールはこうでみたいなのが後からどんどんどんどんルールが出てくるし、なんならこういうふうにルールを作っていくと分かりやすいんじゃないみたいなとか、自分たちで発明していくみたいなところとかもあったりするから。
事前に分かっていればいいんだけど、分からないから後でだいたいここは1対1だと思ってたら1対Nだったねみたいなことが起きて、つらいみたいなことがいっぱい起きていくんだよなっていうのも同時にあるわけですよね。あと崩壊性があるとかね。
それこそさっきの消費税の話はそうですもんね。
そうですね。
本的にそれ変わる?そんなことある?みたいな。
まあなんか難しいですよね。一律10%で取っていいけど、納めるときは店内で食べた場合は、持ち帰りの場合は10%8%とか、なんかそういうのとか、その表面で見えてるものと実態が違うところもあるし、いまだに軽減税率わかんないなみたいなことありますからね。
意識してないですけども、言われたらガンガン払うしかない。だって別にガチョン払うしかないんだから。あんまり意識しないですけど。
数万円変わるわけでもないしなみたいな。
事業者は納める税金は変わってくるんで、意識しないといけないと思うんですけど、消費者としてあんまり変わらないからなって思いながら。
これね、データリクショナリーに含めるものとして、今構成要素の話を。構成要素ですか?今話してたの。
そうですね。
他にもね、データリクショナリーには属性があるよみたいな話がありますね。触れますか?その辺り。
触れると時間が全然足りなくなりそうな気がするなって思いながら。
進みますか。
進みますか。
個人的にはデータフローとデータリクショナリーっていうのが一番力入れて読むといいのかなっていう感じで読んでましたね。
そうですね。実際この本の肝みたいなところはこの2つだと思いますね。
ページ数的にはもう半分超えてますしね。
そうですね。自分もそういうふうに結構読んでて、逆に言うと後ろに来るとだんだんこっちはおまけなのかなみたいなことを思いながらちょっと読んでましたね。
42:06
じゃあ次、一応順番通りに行くとプロセス仕様の方ですね。
そうですね。
