Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか? デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
最初のポイントは、アップデートを捨てること。ここは、ふりかえりをしながら気づいた内なる声だった。二項対立が足を引っ張っているのは、自明。ならば、代わりとなる概念は何なのか? まず思い至ったのは、組織変革2.0、事業開発2.0 = DXといった概念こそ、ダメなんじゃないかということだった。アップデートの「正義感」は、この手の仕事をしていれば、暗黙的な了解になっていると思う。このアップデートこそ、2項対立をより深くするのではないか。 アップデートではなく、「こんにちわ、がんばってともにやっていき」からやりなおす関係。それはアライアンスのイメージと言える。 アップデートからアライアンスへ。二項対立から...。上手く言葉を見つけることができなかった。1ヶ月くらい考えていた。動的平衡という言葉に出会って、心が揺らいだが「平衡」では少々バランスを取りすぎる語感がある(語感だけの話)。ここで扱いたいのは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く