Re: 画面設計とか外部設計とか、もうやめようよ
はてなブックマーク - 画面設計とか外部設計とか、もうやめようよ - masayangの日記（ピスト通勤他
ブコメでは、発注者の担当が業務をわかってないせいみたいに書いて、その理由をIT部門の不遇と結びつけてたわけだけど、事情が異なるらしい。
画面設計とか外部設計とか、もうやめようよ - masayangの日記（ピスト通勤他
補足しておきますと、このプロジェクトは発注側にも受注側にも「未踏」分野なんです。なので、発注側も受注側も「よくわかってない」状態です。そういう状態で、最初に画面をきっちり決めるのは相当リスクがでかいのではないかと。
納得です。
Agileとかそのへんいったん忘れて、なにかのシステムを作ろうとする際、
- 現物理モデル
- 現論理モデル
- 新論理モデル
- 新物理モデル
という順番で実装に落とし込んでいくやり方が考えられます。
(何だか情報処理技術者試験の解説書みたいな書き方になってますけど)
正しいAgileでは、いちいちこんなステップは踏まないかもしれないですが、まったくの「無」からアイデアが具体化されるというのは非常に希であって、どっかにやはり元になる物(『現物理モデル』)があるのが普通と思われます。※創作和食料理とか、無国籍料理とかいうキャッチコピーを思い浮かべてください。
要件定義の段階で、なんとなく画面を作り込んでしまったのは、『(テンポラリーな)現物理モデル』が必要だったから。
「よくわかってない」からこそ、『(テンポラリーな)現物理モデル』が必要だったと推測されるわけです。
他の方が言ってる「画面がないと作業がイメージできない」というのは、画面≒『現物理モデル』と考えれば、私個人はそこで合点がいくわけです。
以下、個人的メモ。
「最初に画面をきっちり決める」のがリスキーな理由は、実装の邪魔になるからと思われる。
理由は簡単。『設計書』みたいに部長のハンコが必要な成果物はリファクタリングできないから。
Agileな人はすぐ「設計書とか時間の無駄」とか言い出すから、そこでコミュニケーション不全になっちゃう。
追記
続報
はてなブックマーク - 要件定義とか設計とか真面目に考えてみよう - masayangの日記（ピスト通勤他
要件定義とか設計とか真面目に考えてみよう - masayangの日記（ピスト通勤他
- 「業務をわかっている人がいない」とか「技術をわかっている人がいない」とかいう言い訳をよく聞く。
- じゃあ「わかっている人が揃っていたら問題ないの？」と問い詰めたい。
- また何か別の理由を持ってきて「○○が足らない」とか言い出すだけなんじゃないの？
私のコメント(を含め)への反論？
はてなブックマーク - 画面設計とか外部設計とか、もうやめようよ - masayangの日記（ピスト通勤他
発注側が自分たちの仕事をよく判ってないせい。業務フローは説明できないけど、EXCELで帳票の様式は作れる、みたいな人がプロジェクトを仕切るからそうなる。
そもそも業務フローがない(≒わからない)から、一から『(テンポラリの)現物理モデル』を拵えなければならない。
だから紙に書くかユースケース図にするかして、今後は『(テンポラリの)現論理モデル』に変換しなければならない。
それは所詮テンポラリだから、そのまま実装には落とし込めない。
その次に、『新論理モデル』を拵えるために、業務フローを最適化する。
最後に、『新物理モデル』を考える。これが設計書になる、って流れがまっとうだと思うわけだが。
現物理モデルというのは、本来はシステム化する以前に実際にユーザーが使用しているモデル。
一般的には、発注側担当者が業務を理解してない(=誰が何をやってるかわかってない)と、誰も業務フローはわからない。受注側が業務フローを知らないのは当たり前だし。
ここで、業務フローを理解していない発注側担当者が一般に何をしているかと言うと、妄想する。
リアルな『現行物理モデル(A)』とは似て非なる、あるいは似ても似つかない『現行(じゃない)物理モデル(B)』を作るためである。
WFだと、開発の後工程にならないと『現行(じゃない)物理モデル(B)』の問題点はだれも指摘できない。だって、それは発注側担当者の妄想の中にしか存在しないから。
その意味では、プロジェクトに業務フローの図面を持ってくるのは発注側担当者の責任。彼らしか、プロジェクトに業務フローの図面を持ってくることが出来ないから。
そもそもAgileで、受発注メンバーが雁首並べてプロジェクトやってるのに、発注側担当者が業務フローの図面も作らず何をするのか？元ユーザー系でデー子に買収されたところみたいに、受注側PMの下で「協力社員」でもやるのかと。
問題があるとすれば、ファイル名に「設計書」と書いてあるせいで部長がハンコ押してしまっていること。
だからリファクタリングもできないし、使い捨てにも出来ない。それって全然Agileじゃない。
関連エントリー
入力と出力に注目して設計するのは王道だと思う 某氏のたわごと
人間は、ビジュアルでないと物事を抽象化しにくいと思われるので、一般の人にもわかる画面設計を抽象化の手段として使うのは正しいと思える。
いきなり抽象化して考えちゃうのは天才脳。
だから画面設計の手間を一つ挟んで、一般人でも対処できるようにする、と言うことか。
Agileについて学ぶ - しょうたろー日記
先に画面をきっちり作っちゃってるから、修正がごっつ億劫になる。
最後に当てはまればええやんと、毎回感じてしまう。
まあ管理するものとして、早くより実物を見たいからだろうか。
以前いたプロジェクトでは、PGの協力さんですら画面を早く見たいからデザインくれという始末。
で、途中で修正が入るとあーだこーだいう。
画面に修正が入って文句が出るのはある意味当たり前。
なぜなら、それは設計者にたいする不信感の表明だから。
Agileだったら修正するのは当然じゃん？と思うかもしれない。
でも、本当のところはそのPGがAgileに適応できてないだけのような気がする。
(クリップ)画面設計とか外部設計とか、もうやめようよ - masayangの日記（ピスト通勤他 ノウハウ [okyuu.com]
(関連記事)はてなブックマーク - イメージに訴えて、要件定義を効率化すべし ? ＠IT情報マネジメント
