わかりやすいシステム構成図の書き方 - Qiita
2022/06/12 12:48
Tmr1984
手間が倍かかるやつだ(倍じゃ終わらないかも)
2022/06/12 13:35
nilab
わかりやすいシステム構成図の書き方 - Qiita
2022/06/12 13:35
rrringress
こういう絵、目的に合わせた最低限の粒度で終わらせたいよね
2022/06/12 13:36
turanukimaru
制御してるのかデータを書いてるのか読んでるのかが大事なのでこの記事の言いたいことはとてもよくわかる。矢印が引いてあるだけのシステム構成図が役に立ったことはない。
2022/06/12 13:49
sgo2
このdata pullの描き方は参考になる。
2022/06/12 13:54
motchang
言いたいことはわかるけどこ内容なら自明だろ。って一瞬思ってしまったけど誰向けのドキュメントかに寄るか〜!?そうか〜!?
2022/06/12 14:01
ardarim
システム構成図ってネットワーク構成図のこともあるしモジュール構成図のこともあるしデータフロー図のこともあるし、要するに曖昧。大事なのは図の目的が明確になっていること。なんとなく矢印で結んだだけは無意味
2022/06/12 14:12
aox
どんな時でもTMKポスター特厚と透明水彩です
2022/06/12 14:24
shag
大して変わらなくないか?
2022/06/12 14:28
nowa_s
➡が↪になるだけで確かに分かりやすい。/別にスタイリッシュじゃなくても、データと処理という異なるものを形で区別し、製品名や部署名の機能や役割を明記し、流れの整理を心掛ければ、明快な良い図が作れそう。
2022/06/12 14:31
baronhorse
わかりやすい?
2022/06/12 14:59
lackofxx
同内容はそのとおりだなと。クラウドのマネージドサービスとかが増えた結果、製品名羅列するだけの図って増えたよねーと思う。
2022/06/12 15:14
kabuquery
あと社内の独自用語を使わないとか
2022/06/12 15:29
kako-jun
UMLのDeployment Diagramの霊圧が消えた……!?
2022/06/12 15:35
yarumato
“わかりにくい点:製品名は書いてあるが「役割」が書いていない。データと処理が区別できない。 製品名称ではなく役割を書け。データと処理を区別する”
2022/06/12 15:49
yukisno
設計の絵を書くのか、実装の絵を書くのかでも書かないといけないことは違いそう。可視化は共通の文脈が必要だよね
2022/06/12 15:54
gcyn
前例と違うと嫌がられて怒られて嫌味を言われるよ!!! (やですね〜。そういうの蹴飛ばしていってくださいね〜。)
2022/06/12 16:40
Sephy
えーと、UML使えって言えば済むんじゃないかな? UMLダイアグラムは対応してるmarkdownエディタでも書けるからドキュメント管理するのも楽だよ。GithubもMermaidに対応したしConfluenceもプラグインがある
2022/06/12 16:52
xojan0120
1個目も2個目もわからんわい
2022/06/12 17:05
messzylinder
とてもわかる。パワポで行って帰ってくる細矢印作るの面倒なんよね。
2022/06/12 17:22
manaten
構成図見てわからないときはそもそもアプリケーションの前提知識が十分に共有されてないときな気がする
2022/06/12 17:27
iwasiman
分かる...かも。一つの矢印でデータの流れと処理の流れの両方が表されちゃうケースありますよね。
2022/06/12 17:44
prjpn
見やすい構成図の書き方知りたい
2022/06/12 17:48
estragon
そらそうだと思うけども、描画ツールが色々使えるようになったからか、SaaSサービスを組み合わせるようになったからか、最初に挙げられてるプロダクト説明ライクなやつを見る機会が増えた気もする
2022/06/12 17:49
oshishosan
前職「そんなもの作るヒマあったら手ぇ動かせ」
2022/06/12 18:49
enomo10
全員がクラウドサービス内容を全て知ってる訳ではないし、重要。
2022/06/12 18:52
remonoil
こないだサービス名すら書いてないのあったわ。AWSのアイコン知ってる前提とかもうね
2022/06/12 19:13
otherworld
配色やデザイン4原則、機能の凝集性をなるべく意識してみることで同じ内容の図でも認知負荷が下がるからおすすめ。
2022/06/12 19:20
k-wacky76
まぁ最後の「UML使えよ」が全て。オレオレ書式使い続けるとそのうちあちこちで矛盾起こして破綻する。
2022/06/12 20:08
kamayan1980
凡例書きなさいよおじさん『凡例書きなさいよ』
2022/06/12 20:41
snsn9pan
わかりやすい
2022/06/12 22:08
odakaho
2つ目分かりやすくはないな。自社システムの知識はあるけどGCPを全く知らない人に見せるための図?用途がわからない。
2022/06/12 22:12
valhara3
ダイアグラム使えはわかるし、サービス名だとわからんから役割書けもわかる。 問題は役割を表すアイコンというかシンボルがダサすぎるんだよなぁ。マテリアル・デザインみたいにスタイリッシュにならないかなぁ
2022/06/12 23:07
tana_bata
うむ。わかる。
2022/06/12 23:39
findup
クラウドサービスのアイコンしか書いてない図は、クラウド使ってるってドヤりたいだけなんじゃないかとすら思ってる。
2022/06/12 23:55
xll
“データの流れを書く場合は、処理を起点としてデータに対して矢印を書きます。ポイントは矢印の起点を処理にすることです。これにより、処理が能動的にデータにアクセスしにいっている様子がひと目でわかります。”
2022/06/13 01:12
kiyo_hiko
いい
2022/06/13 02:20
z1h4784
むしろ製品名は必要ないよね。そういうのを知りたい人が顧客にいるのでない限り書いてない
2022/06/13 05:58
circled
娘ちゃん「でも、このサービス、システム構成図のコンポーネント数よりもアクティブユーザ数が少ないのに悲しくならないの?」 ワイ「せやな」
2022/06/13 06:22
tpircs
2つ目程度の内容を求められているときに1つ目が出てきたらちょっと悲しくはなる。
2022/06/13 06:41
taruhachi
ほう。わかりやすい。製品名やサービスの内容を知っているだろうという読む人のリテラシーに甘えてたんだな。確かに知らないサービスだと全然違うな。
2022/06/13 07:21
masatotoro
“データの流れは実線で、制御の流れは破線”
2022/06/13 07:33
sharaku3eyes
わかりやすい
2022/06/13 08:01
tomoyarn
一瞬よくなっていると思わせつつ、後者も全然わかりやすくない件。「自明だろ」っていう人が書くとこんな感じになるという例だな。そもそも自明なら図いらねえだろ。
2022/06/13 08:05
p_tan
UMLにデータフロー図がないのが現代のソフトウェア設計図としては手落ちだな、とずっと思ってる。
2022/06/13 08:11
ch1248
良い資料だ。
2022/06/13 09:01
Makots
わかる
2022/06/13 09:05
yincha
用途によるとしか。
2022/06/13 09:26
riverplus
製品アイコンを矢印で結ぶ書き方って、なんかクールで通な人っぽく見えるんだよね。ドキュメントとは、自分ではなく相手のためのもの。
2022/06/13 09:38
dekasasaki
“ポイントは矢印の起点を処理にすることです” ここはあえてDFDとは変えてるのか。ただこれ結局、処理の流れがデータの流れに合流してることにならんのかな。ちなみにUMLにはデータフローを扱う図はなくて困るんよね
2022/06/13 09:40
htbman
パワポの円筒形って文字がほんと使いづらいんだよなぁ
2022/06/13 09:48
bobbyjam99
“ポイント1. 製品名称ではなく「役割」を書く ポイント2. データと処理を形で書き分ける ポイント3. データの流れと制御の流れで線を書き分ける”
2022/06/13 09:56
diffie
ちょっと複雑なフローだとどうしようもないんだよね。cronjobでDB更新して、常駐バッチが定期的にDB見て何か処理するとか、処理A/Bいずれか完了で処理C動くとか。結局コメントで補うことになる。よい方法求む。
2022/06/13 11:50
GEROMAX
アイコン配置しただけのポンチ絵で、『資料用意しました!』とかやられると萎えるよね。
2022/06/13 13:13
koroharo
個人的には「データの流れと制御の流れを異なる線で書き分ける」これ。
2022/06/13 13:18
kzm1760
役割とサービスそれぞれを書くと、初見の人には諸々インストールがスムーズそう。逆にサービス分からない人にはサービス名は不要そう。資料を展開する対象者に応じて作るが正しいのかな。
2022/06/13 14:52
kootaro
ドキュメントは、誰に向けて・何を伝える資料なのかを意識して書くようにと昔から教育している。それが出来ない人は説明下手な印象。これがシステム構成図の正解の場合だけでないから要注意。
2022/06/13 17:06
J138
(コンテキストってか説明する/される人のスキルセットによるだろうけど)Cloud Pub/Subに分散キューって書いてて嬉しいか?って言われたらいらん。
2022/06/14 10:01
surume000
とても納得