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