天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

アジャイルとは何なのか DDDとはどうつながるのかに参加してきた

ddd-community-jp.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

アジャイル」とはなんなのか、迷子になっている人は多いのではないでしょうか。 今回は、アジャイルとは何なのか、その目的や全体像を解説し、 さらにDDDとの繋がりがどうなっているのかということについて解説します。  

会の様子

アジャイル開発とは?

アジャイルソフトウェア開発宣言の説明からスタートし、アジャイルはあくまでも思想であることや、スクラムやXPといったアジャイルの思想に沿った開発手法が存在することの説明がありました。

DDDも、このアジャイルの思想に沿った開発手法の一つだということです。*1

アジャイルの本質

マーティン・ファウラーが、アジャイルの本質として2つの要素を挙げているというお話があり、この要素について説明がありました。

予測的ではなく適応的

予測通りに進んだことではなく、プロダクトが価値を生み出したことを「成功」とアジャイルでは定義しているという話がありました。*2

プロセス指向ではなく人指向である

属人性をなるべく排除して、誰しもが同じアウトプットを出そうとする手法に限界を感じ、人を最重要視することが、アジャイル開発だというお話がありました。

DDDとアジャイル

Evans本にて、「DDDはアジャイルの思想に則った開発手法の一つである」という記載がある点と、DDDの前提がアジャイルを想定しているものであると考えられる*3点から、アジャイルの開発手法の一つとして捉えているというお話がありました。

Q&A

従業員を全員クビにすることがシステムの一つのゴールだが、DDDはどう解釈しているのか?

システムのゴールの定義が誤っている可能性が高いという話でした。
コスト最適化の話はありつつも、全員クビにしようという発想はDDDやアジャイルで持ち合わせておらず、あくまでもプロダクトが価値を出すことにフォーカスしているというお話です。

組み込みソフトウェア開発にDDDは有効か?

組み込み開発の経験がないという前提を起きつつ、DDDが大切にしている人指向やモデリングはどんな分野でも有用だと考えられるため、有効だと言えるのではないか?というお話でした。

アジャイル開発ができないとDDDはできていないのか?

アジャイル開発ができている」という定義が曖昧で、あくまでも今よりアジャイルな状態を目指すのが重要なので、そのようなことはないというお話でした。

最初のモデリングはいつ実施するのか?(スクラム前提)

もちろん「もっと早くやっておけばよかった」という話が出ることはあるものの、いつからやっても間に合うものなので、モデリングの必要性を感じた時が最適な実施タイミングだというお話でした。

ユーザーストーリーマッピングインセプションデッキといったアジャイルラクティスはDDDのモデリングに必要となるものであり、やるべきか?

必要だと思うならやるものであり、DDDだからやる、みたいな話はないのではないかということでした。(プロセス指向な考え方になってはいないか?という指摘も出ていました。)

10年ものの保守システムにアジャイルは向いているか?

人を重視することや適応的に仕事を進めるメリットは享受できるので、導入して悪いことはないのではないか?というお話が出ていました。

意欲的な人がいないのならアジャイル開発をやらない方がいいか?

上の質問と同様に、人を重視することや適応的に仕事を進めるメリットは享受できるので、やらない方が良い場面というのは存在しないのではないか?ということでした。

ペアプロを実践するとコードに愛着が持てなくなる。。

手触り感がなくなる気持ちはわかるので、一部だけソロで実践するといった工夫をすると良いのではないか?ということでした。

アジャイル開発を始めた時のトラブルは?

アジャイル開発を始めた時っていうのがいつか分からないので質問には答えられないが、スクラムを始めた時は多数のトラブルに巻き込んだということです。

アジャイル開発を実践しているが、やる気のない後輩がいてうまく進まない

アジャイル開発のスコープ外の問題になっていないか?(具体的にいうと、採用や育成、評価制度のスコープではないか?)というお話が出ていました。

何でもかんでもアジャイルにすることで解決する、という風にアジャイル銀の弾丸にしないように、注意してほしいということです。

どんな立場で松岡さんはアジャイルに関わっているのか?

スクラムを導入しつつ、モデリング開発プロセスについては、チームを跨いで横断的に改善に取り組んでいるということです。

全体を通した感想

全てをアジャイルで解決しようとしない、うまくいかない理由を全てアジャイルに押し付けない、というお話は非常に共感できました。

Q&Aセッションでは、アジャイル開発をめぐって色々と悩まれている方は多いんだなあ。。ということを改めて感じました。

*1:アジャイルソフトウェア開発宣言の思想を受け継いでいるものであれば、アジャイル開発といってもいいだろうというお話でした

*2:予測通りにスケジュール遅延なく進んだけどプロダクトをユーザがまるで使っていないプロジェクトAと、予測からは大幅に遅延して炎上したけどプロダクトをユーザが使っているプロジェクトBがあった場合、プロジェクトBが成功だと考えるということです

*3:開発がイテレーティブであり、開発者とドメインエキスパートが密接に関連している