目的は画面レイアウトもmarkdown記法で記述することではなく、その他の項目定義などの差分管理とAIへのインプットとするためだよね。 なので画面レイアウトは他で作ったものの画像を貼っておけばよい。 excel設計書は滅
Excel管理の苦行から逃げたいエンジニアの叫び。非エンジニアとの合意形成が最大の壁だけど、Gitで差分管理できるメリットはもっと啓蒙されるべき
設計書が合意形成のエビデンスである以上、Markdownでは情報が足りない。コーダーへの指示書としては適切だと思う
前提で出してる問題点は本当にそうなんだけどね
AIとの相性が良いから自分もMarkdownで書いてますね。ただ、役割ごとにファイルを分割してリンクを貼る感じかな。複雑な画面は単一ファイルだと肥大化するし、顧客には不要な情報も多いので
markdownうんぬんではなく、入出力設計と見た目としてのデザインを分離させたいという話な気がする。入出力設計はテキストで管理できるしそうしたほうがいいというのもわかる。
Markdownは図に矢印描き込めないのが辛い(SVGで頑張る?)
例に挙げられてるようなごくシンプルな画面ならそれでいいけど業務システムだと項目数も書くべき内容もはるかに多いから難しいと思う。というかWordもExcelも差分やGitでの管理できるのになんでできないことにするのか？
svgをもっとシンプルにした記法があれば。
内容は完全同意。mermaid記法が出てきて表現力の問題もだいぶ解決した。しかし、mermaid記法で書くとテンプレートっぽい図が出力され、技術者以外からは単なる手抜き・劣化と見られがち。
AI 設計書
そこでPlantUMLのSaltですよ…ってのをプライベートプロジェクトではやってる。
テーブルだけがめんどくさい
デザインの入らない画面設計はmarkdownの見出しと箇条書きで十分ですね。AIとの親和性も高いし、最近はそうしてます
AIに書かせるのはそれになるけど、Obsidianに積んでいっても、読み直さないんよね。AI用の文書フォルダになってしまっている。
excelをテキスト変換してdiffをとる事もできるよ
結局PlantUMLに落ち着く
こっちの方向ならPlantUMLだよね。 /原本の管理は差分管理したいけど、議論や回覧の資料にはやっぱりExcelとかPPTは残っちゃうからなあ
オブション＞アドイン＞管理：COMアドインで"Inquire"を有効化。オプション＞情報＞バージョン履歴で比較対象ファイルを開き、ファイルとして保存。検査タブで"ファイルを比較"。これでExcel差分比較できます。
いい言葉を教えてあげよう『適材適所』技術が目的になっちゃうのはエンジニア特有の悪い癖だよ
(今後/これから)重要なのはAgentが解釈出来る書類か?だとおもっていてコードと同一リポジトリにmarkdownで画面仕様とか画面遷移、画面一覧,etc.. を突っ込んでます
画面の情報設計には十分だけどチームが大きいとどっかで齟齬が起こりそうだな。画面設計だけで語らない方がいいのか。
「Gitで差分管理できる」に対する反論が変換すればdiff見れるから…ってのはなんか違う
この人の言う通りにするとWordで書いて創英角ポップ体のItalic多用する人に貧弱なWindowsメモ帳を開かせ、非エンジニアにgit教育、取引先にも認めさせる地獄が発生。で履歴追うならExcelにv01とか最終版つければと言う悪魔が
肝心の画面レイアウトがガッタガタ。25年前のアスキーアートよりも退化している
asciidoctor
わかりみ。でも画面設計書は馴染まないのでは。ピクセル単位でデザインの合意が求められる場合が多いので。詳細設計書やAPI仕様書には好適。
これでは「見た目」の情報が不足するのでmarkdownとは別に「見た目」の何かを作らなければならなくてその手間を考えたうえでメリデメ再考が必要な気がする。個人的には「excelで文書」くらいナンセンスかと。
むしろ今なら「AI使って差分が追えるツール」を作るほうが良さそうな気する
エンジニア以外が見たり編集したり顧客への納品が関わる場合そこからどうやってルール化したり納品物に変換してそこの合意取れるかって感じだなー
差分とかどうでも良くてAIに向いてないからExcelの設計書を使いたくない。けど、Markdownがこの用途に向いているかと言われると微妙。
Excel→javaDoc/UML→Excel→sphinx→Excel→MD...のこの流れよ……
ASCII はエクストリームだな。そこまでやるなら画像でいいと思う。draw.io とかでちゃちゃっと書けばいい。あと設計書とコードは別のリポジトリの方がいい。言うて関心が別なので混ざった履歴は読みづらい。
ファイルサイズが十分小さければAIにdiffツール書かせればいいとはいえ/図は図で drawio なりを使いたい。
Excelの差分はどう確認するのが読みやすいのかな。カラムの幅みたいな内容と関係ないような変化省けたりすると嬉しい
うーん。やっぱ「Markdown自体のビジュアル表現力が低い」は決定的な。（外部ツールへのリンクは差分管理の放棄でもあるので。個人的には各要素箇条書きだけどこれはこれで厳しい。「簡易スケッチhtml」的な記法つくる?
Markdown で書きたいのはわかるけど「ASCII ベースの簡易レイアウト」はこの例ぐらいシンプルな画面じゃないと無理では
このへんの問題についてはAI時代に対応した新しいソリューションが近々出てくる気がする。
こだわりすぎると画面情報をHTMLで記述するようになって本末転倒になりそう
画面レイアウト部分は、別ファイルとしてAIを使ってhtmlでもありじゃないかな。線だけの抽象的な表現をhtml化しておけば認識合わせに使えるでしょう。
文化じゃなくてルールだと思うんよ
AI時代を考えると再考の余地あるよね。とくにレビューと修正のプロセスはテキストが圧倒的にはやい
「Markdown で画面レイアウトをどう表現するか」一生これが厳しい。表を書くのもメンテするのも地獄（ここは超便利な拡張機能とかあるのかな！？）。いっそ方眼紙ExcelがMarkdownになれ！
複雑な画面どうすんの問題
excelは内部はXMLだろうからそれでいいのでは
現実の意思決定プロセスを自己都合で捨象するのはやめよう。画面に紐づくデザインとデータ設計は不可分なのだから、FigmaJSONを情報基点とし開発向けには仕様書パーサを書くのが無駄な手作業が妥当に少なくなるのでは
画面設計書というよりは画面設計書を作成するAIに渡すワイヤーフレームとしてmdで管理するのはありという気がしている。marmaidでワイヤーフレーム作って項目管理や画面遷移図を管理するのには使えそう。
わざわざMarkdownでこねくり回さなくてもいいと思う
なんでも言語化、構造化しておけばAIがどうにかしてくれるからな。
Mermaid で書きながら Figma も併用できたりしないかなあ
画面設計書≒基本(概要)設計書まではMarkdown単体では辛いものがある。
ビジュアルシンカー(絵で考える)とバーバルシンカー(言葉で考える)、という話があるが、人間は互いにリンクしてるが、今の生成AIは単独で成り立ってる印象。バーバル強めのAIで見た目が重要な画面を考えるのしんどい
入出力項目定義をmarkdownで残して、レイアウトなんかはfigmaなんかで作ってURL貼り付けなんかな／Pencilってどうなんだっけ
画面設計書なんかＡＩにHTMLで書いてもらえばええねん
Excelで差分管理する方法は標準機能含めて山ほどあって、にもかかわらずできてないのはニーズがないか文化の問題。ツールだけ変えてもニーズが生まれたり文革が発生したりはしなさそう
仕様調整フェーズまでのワイヤーフレームは自分としての最適解は結局のところExcelなんだよなー異論あるしなんか悔しいけど。見てもらって加筆修正しやすいフォーマット大正義なのよね。
Excel画面設計書からの移行としてはFigma / デザインツールへのリンクを埋め込むかな。それよりもMarkdownへの移行をどう考えているのかわからないことがうちのチームの課題。
Markdownを強制させることで、図等に頼らず指示をテキスト化してそちらを正としてもらえるのが本質（本音）に感じた。それを徹底してくれる相手なら「変更点は赤字にして」で同様の効果を担保できる気もする。
この話はもう数十年単位で繰り返されている気がするが、markdown 形式が普及しないのは、面倒くさいから。だと思う。
AI時代になると、コンセプトと背景・注意すること以外はドキュメントで管理したくなくなってきた
すでに画面遷移図はマークダウン、mermaid
Gitを使うことが目的化しとるな。
MermaidってGitHubでそのまま使えるのがメリットだけど、全然見やすくはない。テキスト記述するにしても、D2のが全然いい
反論は解るんですが、じゃあExcelベースの画面設計書を筋肉以外でどう差分管理しているのか是非教えてほしい。変更履歴の記載とチェックしんどい。
これはmdで書いていると言えるのか…？具体例みたらプレーンテキストに回帰しとるだけやんとしか
弊社は準委任契約で最初から実物を作るというアプローチで設計書を基本的に廃止した。設計書ではピンと来ない顧客もこれを望んでる。
開発側が楽できるような画面設計が客に売れるならそれでいいんじゃね
mdは表作成がしんどすぎる／取引先から提供されたExcel方眼紙の設計書に淡々と貼り付けるスクリプトをAIに作ってもらったり
画面設計自体はテキストでやると辛いので、Draw.ioを使ってdraw.ioのファイルもいっしょにGitに保存すると良いのではないかな。
「浸透させたい」という割に交渉ごとは人任せにしたいと "ここは上層部にぜひとも頑張っていただきたいです"
いずれは適切な変換もできそうなのでそうなるかもしれないがそうなると誰が作るものなのかの整理は必要
pencilつかおう（本文読んでないけど）
画面設計書を Markdown で書く文化を浸透させたい
目的は画面レイアウトもmarkdown記法で記述することではなく、その他の項目定義などの差分管理とAIへのインプットとするためだよね。 なので画面レイアウトは他で作ったものの画像を貼っておけばよい。 excel設計書は滅
Excel管理の苦行から逃げたいエンジニアの叫び。非エンジニアとの合意形成が最大の壁だけど、Gitで差分管理できるメリットはもっと啓蒙されるべき
設計書が合意形成のエビデンスである以上、Markdownでは情報が足りない。コーダーへの指示書としては適切だと思う
前提で出してる問題点は本当にそうなんだけどね
AIとの相性が良いから自分もMarkdownで書いてますね。ただ、役割ごとにファイルを分割してリンクを貼る感じかな。複雑な画面は単一ファイルだと肥大化するし、顧客には不要な情報も多いので
markdownうんぬんではなく、入出力設計と見た目としてのデザインを分離させたいという話な気がする。入出力設計はテキストで管理できるしそうしたほうがいいというのもわかる。
Markdownは図に矢印描き込めないのが辛い(SVGで頑張る?)
例に挙げられてるようなごくシンプルな画面ならそれでいいけど業務システムだと項目数も書くべき内容もはるかに多いから難しいと思う。というかWordもExcelも差分やGitでの管理できるのになんでできないことにするのか？
svgをもっとシンプルにした記法があれば。
内容は完全同意。mermaid記法が出てきて表現力の問題もだいぶ解決した。しかし、mermaid記法で書くとテンプレートっぽい図が出力され、技術者以外からは単なる手抜き・劣化と見られがち。
AI 設計書
そこでPlantUMLのSaltですよ…ってのをプライベートプロジェクトではやってる。
テーブルだけがめんどくさい
デザインの入らない画面設計はmarkdownの見出しと箇条書きで十分ですね。AIとの親和性も高いし、最近はそうしてます
AIに書かせるのはそれになるけど、Obsidianに積んでいっても、読み直さないんよね。AI用の文書フォルダになってしまっている。
excelをテキスト変換してdiffをとる事もできるよ
結局PlantUMLに落ち着く
こっちの方向ならPlantUMLだよね。 /原本の管理は差分管理したいけど、議論や回覧の資料にはやっぱりExcelとかPPTは残っちゃうからなあ
オブション＞アドイン＞管理：COMアドインで"Inquire"を有効化。オプション＞情報＞バージョン履歴で比較対象ファイルを開き、ファイルとして保存。検査タブで"ファイルを比較"。これでExcel差分比較できます。
いい言葉を教えてあげよう『適材適所』技術が目的になっちゃうのはエンジニア特有の悪い癖だよ
(今後/これから)重要なのはAgentが解釈出来る書類か?だとおもっていてコードと同一リポジトリにmarkdownで画面仕様とか画面遷移、画面一覧,etc.. を突っ込んでます
画面の情報設計には十分だけどチームが大きいとどっかで齟齬が起こりそうだな。画面設計だけで語らない方がいいのか。
「Gitで差分管理できる」に対する反論が変換すればdiff見れるから…ってのはなんか違う
この人の言う通りにするとWordで書いて創英角ポップ体のItalic多用する人に貧弱なWindowsメモ帳を開かせ、非エンジニアにgit教育、取引先にも認めさせる地獄が発生。で履歴追うならExcelにv01とか最終版つければと言う悪魔が
肝心の画面レイアウトがガッタガタ。25年前のアスキーアートよりも退化している
asciidoctor
わかりみ。でも画面設計書は馴染まないのでは。ピクセル単位でデザインの合意が求められる場合が多いので。詳細設計書やAPI仕様書には好適。
これでは「見た目」の情報が不足するのでmarkdownとは別に「見た目」の何かを作らなければならなくてその手間を考えたうえでメリデメ再考が必要な気がする。個人的には「excelで文書」くらいナンセンスかと。
むしろ今なら「AI使って差分が追えるツール」を作るほうが良さそうな気する
エンジニア以外が見たり編集したり顧客への納品が関わる場合そこからどうやってルール化したり納品物に変換してそこの合意取れるかって感じだなー
差分とかどうでも良くてAIに向いてないからExcelの設計書を使いたくない。けど、Markdownがこの用途に向いているかと言われると微妙。
Excel→javaDoc/UML→Excel→sphinx→Excel→MD...のこの流れよ……
ASCII はエクストリームだな。そこまでやるなら画像でいいと思う。draw.io とかでちゃちゃっと書けばいい。あと設計書とコードは別のリポジトリの方がいい。言うて関心が別なので混ざった履歴は読みづらい。
ファイルサイズが十分小さければAIにdiffツール書かせればいいとはいえ/図は図で drawio なりを使いたい。
Excelの差分はどう確認するのが読みやすいのかな。カラムの幅みたいな内容と関係ないような変化省けたりすると嬉しい
うーん。やっぱ「Markdown自体のビジュアル表現力が低い」は決定的な。（外部ツールへのリンクは差分管理の放棄でもあるので。個人的には各要素箇条書きだけどこれはこれで厳しい。「簡易スケッチhtml」的な記法つくる?
Markdown で書きたいのはわかるけど「ASCII ベースの簡易レイアウト」はこの例ぐらいシンプルな画面じゃないと無理では
このへんの問題についてはAI時代に対応した新しいソリューションが近々出てくる気がする。
こだわりすぎると画面情報をHTMLで記述するようになって本末転倒になりそう
画面レイアウト部分は、別ファイルとしてAIを使ってhtmlでもありじゃないかな。線だけの抽象的な表現をhtml化しておけば認識合わせに使えるでしょう。
文化じゃなくてルールだと思うんよ
AI時代を考えると再考の余地あるよね。とくにレビューと修正のプロセスはテキストが圧倒的にはやい
「Markdown で画面レイアウトをどう表現するか」一生これが厳しい。表を書くのもメンテするのも地獄（ここは超便利な拡張機能とかあるのかな！？）。いっそ方眼紙ExcelがMarkdownになれ！
複雑な画面どうすんの問題
excelは内部はXMLだろうからそれでいいのでは
現実の意思決定プロセスを自己都合で捨象するのはやめよう。画面に紐づくデザインとデータ設計は不可分なのだから、FigmaJSONを情報基点とし開発向けには仕様書パーサを書くのが無駄な手作業が妥当に少なくなるのでは
画面設計書というよりは画面設計書を作成するAIに渡すワイヤーフレームとしてmdで管理するのはありという気がしている。marmaidでワイヤーフレーム作って項目管理や画面遷移図を管理するのには使えそう。
わざわざMarkdownでこねくり回さなくてもいいと思う
なんでも言語化、構造化しておけばAIがどうにかしてくれるからな。
Mermaid で書きながら Figma も併用できたりしないかなあ
画面設計書≒基本(概要)設計書まではMarkdown単体では辛いものがある。
ビジュアルシンカー(絵で考える)とバーバルシンカー(言葉で考える)、という話があるが、人間は互いにリンクしてるが、今の生成AIは単独で成り立ってる印象。バーバル強めのAIで見た目が重要な画面を考えるのしんどい
入出力項目定義をmarkdownで残して、レイアウトなんかはfigmaなんかで作ってURL貼り付けなんかな／Pencilってどうなんだっけ
画面設計書なんかＡＩにHTMLで書いてもらえばええねん
Excelで差分管理する方法は標準機能含めて山ほどあって、にもかかわらずできてないのはニーズがないか文化の問題。ツールだけ変えてもニーズが生まれたり文革が発生したりはしなさそう
仕様調整フェーズまでのワイヤーフレームは自分としての最適解は結局のところExcelなんだよなー異論あるしなんか悔しいけど。見てもらって加筆修正しやすいフォーマット大正義なのよね。
Excel画面設計書からの移行としてはFigma / デザインツールへのリンクを埋め込むかな。それよりもMarkdownへの移行をどう考えているのかわからないことがうちのチームの課題。
Markdownを強制させることで、図等に頼らず指示をテキスト化してそちらを正としてもらえるのが本質（本音）に感じた。それを徹底してくれる相手なら「変更点は赤字にして」で同様の効果を担保できる気もする。
この話はもう数十年単位で繰り返されている気がするが、markdown 形式が普及しないのは、面倒くさいから。だと思う。
AI時代になると、コンセプトと背景・注意すること以外はドキュメントで管理したくなくなってきた
すでに画面遷移図はマークダウン、mermaid
Gitを使うことが目的化しとるな。
MermaidってGitHubでそのまま使えるのがメリットだけど、全然見やすくはない。テキスト記述するにしても、D2のが全然いい
反論は解るんですが、じゃあExcelベースの画面設計書を筋肉以外でどう差分管理しているのか是非教えてほしい。変更履歴の記載とチェックしんどい。
これはmdで書いていると言えるのか…？具体例みたらプレーンテキストに回帰しとるだけやんとしか
弊社は準委任契約で最初から実物を作るというアプローチで設計書を基本的に廃止した。設計書ではピンと来ない顧客もこれを望んでる。
開発側が楽できるような画面設計が客に売れるならそれでいいんじゃね
mdは表作成がしんどすぎる／取引先から提供されたExcel方眼紙の設計書に淡々と貼り付けるスクリプトをAIに作ってもらったり
画面設計自体はテキストでやると辛いので、Draw.ioを使ってdraw.ioのファイルもいっしょにGitに保存すると良いのではないかな。
「浸透させたい」という割に交渉ごとは人任せにしたいと "ここは上層部にぜひとも頑張っていただきたいです"
いずれは適切な変換もできそうなのでそうなるかもしれないがそうなると誰が作るものなのかの整理は必要
pencilつかおう（本文読んでないけど）