Twitter | Search | |
This is the legacy version of twitter.com. We will be shutting it down on 15 December 2020. Please switch to a supported browser or device. You can see a list of supported browsers in our Help Center.
神崎 善司
要件定義を中心としたコンサルやセミナーを仕事としています。 「要件定義から実装までをつなげて考える」がモットー プログラミングと家庭菜園が趣味
2,410
Tweets
363
Following
1,054
Followers
Tweets
神崎 善司 Nov 26
Replying to @zenzengood
ちなみに目の前にあるものを見える(聞こえる)ようになるために、松下幸之助さんが「素直になりなはれ」と言っていた 最近それが実感出来るようにようやくなってきた
Reply Retweet Like
神崎 善司 Nov 26
Replying to @zenzengood
ここで重要なのは価値→仕事→要求の順番で整理することである 価値→要求 は時間がかかるし十分な落とし込みが出来ない どこまでいっても具体的な議論が出来ない限り実行に結びつかない この議論をすっ飛ばしてフワッとした要求でシステム化するから、納期遅延、予算超過で使えない物になる
Reply Retweet Like
神崎 善司 Nov 26
Replying to @zenzengood
対象を大きな単位に分類し、さらに仕事の単位を明らかにする つまり成立しているビジネスの可視化である その上で「ここをXXする」 指さしながら具体的な議論を行い 合意したことを要求として整理する その要求を並べ優先順位付けする この優先度と仕事の切りのよさでMVPを決める
Reply Retweet Like
神崎 善司 Nov 26
成立しているビジネスを魅力的にするために新たな価値を創造する という文脈において 価値は案外目の前にある  見えていない  聞こえていない だけである 各種キャンバスで何が必要なのか、有効なのかを探ったとしても、具体的な落とし込み方法がわからなければ、上滑りした議論に終止する
Reply Retweet Like
神崎 善司 Nov 25
Replying to @zenzengood
この本は抽象的な内容なので、読みやすくも分かりやすくもないが、自分事として読み砕くと得られることが多い 最近この手の本が少ないので、この先何十年も役に立つ考え方を得たい人にはいい本である
Reply Retweet Like
神崎 善司 Nov 25
Replying to @zenzengood
対象を正しく知る 対象を正確に表現することではなく、認知している(したい)ことを表現するなど、大変示唆にとんでいる 「CATWOE」も忘れていたが改めてみるとそうだよなー とうなずくことが多い
Reply Retweet Like
神崎 善司 Nov 25
Replying to @zenzengood
大きな絵を描くためには対象を引いてみることが大事である 私の場合はその視点をシステム思考から得ている 最近復刻されたSSMの本を30年ぶりに読んでいるが今でも役に立つ
Reply Retweet Like
神崎 善司 Nov 25
Replying to @zenzengood
普段細かい作業に追われていると大きな絵を描くのが難しくなる そういう現場では現実的な作業は見えているのでブレークダウンは得意である 大きな絵を描き方向性の種をまけば議論が回り出す 大きな絵をRDRAを使ってブレークダウンし、システムにつなげ、そこに時間軸をおけば最初の一歩が見えてくる
Reply Retweet Like
神崎 善司 Nov 25
DXの文脈で要求がちらかり、要件がまとめられない現場をよく目にするようになった 要因の一つが方向性を示せないことにある。 方向性を示すための道具の一つがビックピクチャである 将来に向けた好循環の因果関係モデルも有効である
Reply Retweet Like
神崎 善司 Nov 22
面白い映画 これ今のアメリカの民主党と大手メディアが行っていることと同じ構図では?
Reply Retweet Like
神崎 善司 retweeted
増田 亨. Nov 21
ある程度複雑なビジネスルールがRDRAで洗い出せていなかったら、それは要件定義の改善課題。 開発対象の複雑さを発見して共有できていなかったということ。 受託開発方式だと、ここは致命的。(見積差異が大きすぎる) 継続的なプロダクト開発だと、RDRAの要件モデルにフィードバックすればよい。
Reply Retweet Like
神崎 善司 Nov 22
Replying to @zenzengood
そしてシステム開発に大きな予算をかけられるのは、そのビジネスが成立しているからである そういうシステムに対して「要件は開発しながら決めましょう」というのはピントがボケている 開発しながら決めるのは「仕様」である だからRDRAの要件定義は「仕様化の土台を作ること」としている
Reply Retweet Like
神崎 善司 Nov 22
Replying to @zenzengood
もう一つの誤解は RDRAはAsIsのシステムを表現するものと思われていること RDRAは成立しているビジネスを対象としているものに向いている 後者のシステム化は一定基準を満たさないとリリースできない そのために全体俯瞰が必要になる
Reply Retweet Like
神崎 善司 Nov 22
Replying to @zenzengood
逆に詳細が多くて全体が見えないものが苦手であり、詳細はコードで表現すればいいだろうと考えている ダイアグラムを横断して対象を考えられるようになるとRDRAのモデリングが面白くなるだろうし、規模の大きなものでも表現できるようになる
Reply Retweet Like
神崎 善司 Nov 22
RDRAはつながりをモデリングしているから、ダイアグラム単位で理解したい人には向いていない手法だと今更ながら気づいた 私は全体を俯瞰しながら組み立てたり、読み解いたりする そもそも書かれていることに関心があるのではなく、つながりに関心があるのでダイアグラムの数は気にならない
Reply Retweet Like
神崎 善司 Nov 21
システムは入力から出力への変換として定義できる 何かを作り出す人の仕事は「入力+ノウハウ→出力」になる セミナーなどで、この入力ではこの出力ができないと機械的に思考する人がいる どんな方法論を使ったところでこのノウハウ部分を埋めきれない セミナーで悩むのはいつもここ
Reply Retweet Like
神崎 善司 Nov 21
Replying to @zenzengood
今は分析が足りてないんだな
Reply Retweet Like
神崎 善司 Nov 21
昔開発している時は、分析、設計という言い方をしていたけど、言わなくなったな 確かにシステム化対象を分析してたんだよな 結局その当時は  何を作ればいいかを分析し!  どう作るか設計してた! 一気通貫でシステムを開発してたからこれで十分だった SSMを読み返してたらふと思った
Reply Retweet Like
神崎 善司 retweeted
コッペパン@WEIN隊0期生 Nov 20
RDRAやDDD的な観点から改めてソースコードや設計書を読んでみると、ビジネス都合のロジックとシステム都合のロジックが区別なく書かれていることが分かる。
Reply Retweet Like
神崎 善司 Nov 20
船頭多くして船山に上る 手を動かす人 < 周りでいろいろ言う人 実際は山にも上らずその場で右往左往して時間がたつほど影響範囲が大きくなっているだけかな
Reply Retweet Like