わかりやすいシステム構成図の書き方 - Qiita

わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

[turanukimaru]

制御してるのかデータを書いてるのか読んでるのかが大事なのでこの記事の言いたいことはとてもよくわかる。矢印が引いてあるだけのシステム構成図が役に立ったことはない。

[rrringress]

こういう絵、目的に合わせた最低限の粒度で終わらせたいよね

[kabuquery]

あと社内の独自用語を使わないとか

[lackofxx]

同内容はそのとおりだなと。クラウドのマネージドサービスとかが増えた結果、製品名羅列するだけの図って増えたよねーと思う。

[enomo10]

全員がクラウドサービス内容を全て知ってる訳ではないし、重要。

[motchang]

言いたいことはわかるけどこ内容なら自明だろ。って一瞬思ってしまったけど誰向けのドキュメントかに寄るか〜！？そうか〜！？

[p_tan]

UMLにデータフロー図がないのが現代のソフトウェア設計図としては手落ちだな、とずっと思ってる。

[nowa_s]

➡が↪になるだけで確かに分かりやすい。／別にスタイリッシュじゃなくても、データと処理という異なるものを形で区別し、製品名や部署名の機能や役割を明記し、流れの整理を心掛ければ、明快な良い図が作れそう。

[gcyn]

前例と違うと嫌がられて怒られて嫌味を言われるよ！！！ （やですね〜。そういうの蹴飛ばしていってくださいね〜。）

[sgo2]

このdata pullの描き方は参考になる。

[pavlocat]

再ブクマ

[tinsep19]

AWSやAzureでサービスやリソースを並べてしまって、なりがちではある。システム設計やアーキテクチャ設計でUMLのコンポーネント図やデプロイ図がわりと重要なのはそこにコンテキストやロールと一緒に書き込むからと思う

[cowai5]

“製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない”

[burabura117]

システム構成図ってなんだろうね…。

[lanius]

コンポーネントの名称ではなく役割を書く。データの流れと制御の流れをわけて書く。

[surume000]

とても納得

[J138]

（コンテキストってか説明する/される人のスキルセットによるだろうけど）Cloud Pub/Subに分散キューって書いてて嬉しいか？って言われたらいらん。

[kootaro]

ドキュメントは、誰に向けて・何を伝える資料なのかを意識して書くようにと昔から教育している。それが出来ない人は説明下手な印象。これがシステム構成図の正解の場合だけでないから要注意。

[kzm1760]

役割とサービスそれぞれを書くと、初見の人には諸々インストールがスムーズそう。逆にサービス分からない人にはサービス名は不要そう。資料を展開する対象者に応じて作るが正しいのかな。

[koroharo]

個人的には「データの流れと制御の流れを異なる線で書き分ける」これ。

[GEROMAX]

アイコン配置しただけのポンチ絵で、『資料用意しました！』とかやられると萎えるよね。

[diffie]

ちょっと複雑なフローだとどうしようもないんだよね。cronjobでDB更新して、常駐バッチが定期的にDB見て何か処理するとか、処理A/Bいずれか完了で処理C動くとか。結局コメントで補うことになる。よい方法求む。

[bobbyjam99]

“ポイント1. 製品名称ではなく「役割」を書く ポイント2. データと処理を形で書き分ける ポイント3. データの流れと制御の流れで線を書き分ける”

[htbman]

パワポの円筒形って文字がほんと使いづらいんだよなぁ

[dekasasaki]

“ポイントは矢印の起点を処理にすることです” ここはあえてDFDとは変えてるのか。ただこれ結局、処理の流れがデータの流れに合流してることにならんのかな。ちなみにUMLにはデータフローを扱う図はなくて困るんよね

[riverplus]

製品アイコンを矢印で結ぶ書き方って、なんかクールで通な人っぽく見えるんだよね。ドキュメントとは、自分ではなく相手のためのもの。

[Makots]

わかる

[ch1248]

良い資料だ。

[tomoyarn]

一瞬よくなっていると思わせつつ、後者も全然わかりやすくない件。「自明だろ」っていう人が書くとこんな感じになるという例だな。そもそも自明なら図いらねえだろ。

[sharaku3eyes]

わかりやすい

[masatotoro]

“データの流れは実線で、制御の流れは破線”

[taruhachi]

ほう。わかりやすい。製品名やサービスの内容を知っているだろうという読む人のリテラシーに甘えてたんだな。確かに知らないサービスだと全然違うな。

[tpircs]

2つ目程度の内容を求められているときに1つ目が出てきたらちょっと悲しくはなる。

[circled]

娘ちゃん「でも、このサービス、システム構成図のコンポーネント数よりもアクティブユーザ数が少ないのに悲しくならないの？」　ワイ「せやな」

[z1h4784]

むしろ製品名は必要ないよね。そういうのを知りたい人が顧客にいるのでない限り書いてない

[kiyo_hiko]

いい

[xll]

“データの流れを書く場合は、処理を起点としてデータに対して矢印を書きます。ポイントは矢印の起点を処理にすることです。これにより、処理が能動的にデータにアクセスしにいっている様子がひと目でわかります。”

[findup]

クラウドサービスのアイコンしか書いてない図は、クラウド使ってるってドヤりたいだけなんじゃないかとすら思ってる。

[tana_bata]

うむ。わかる。