9/26のDDD Allianceにて発表しました

先日のDDD Allianceの勉強会にて、いま開発現場で取り組んでいるドメイン駆動設計の成果について発表させていただきました〜。

ddd-alliance.connpass.com

手前味噌。 発表資料。*1 他の登壇者の発表資料は上記イベントページのリンクからどうぞ!

www.slideshare.net

ためになる裏話とかは特にないのですが、せっかくなので感想など書いておこうかと思います。

DDDって注目されてるんだな〜という話

想像していたよりもずっと多くの方がドメイン駆動設計に興味を持っているのだと今回初めて知りました。(まずイベント公開からすぐにたくさんの申込があったので、当日までビビりながら資料作りしていました)
ディスカッションの場や懇親会でも、社外でDDDを実践している方々とお話しさせていただき、とても良い機会になりました。

イベント終了後、主催者・参加者の方々によるイベントレポート、感想ブログ等もたくさん書いていただきました。

dev.classmethod.jp togetter.com vermeer.hatenablog.jp hiroronn.hatenablog.jp

素直に、今回発表できてよかったな〜と思います。
資料作りは大変だったけど、それを十分に越える反響とフィードバックを貰えたのですごく満足しています。

改めまして、本当にありがとうございました。

バックグラウンドの話

イベント中ではさらっと流した部分でしたが、私は入社4年目、5年前から始まった弊社でのDDD開発が広まり出したころに参加しました。DDDネイティブ的な立場です。
新卒で入って研修を終えた6月頃、最初に書いたのがDDDのお題でした(イベントで最後に発表した奥野さんの資料の中で紹介されているお題です)。

javaを書いたことなくクラスの概念もわからない、そんな状態の1年目の私は、言われるがままにバリューオブジェクトを作りながら「javaってコードもファイルもたくさん作らなきゃいけなくて大変だなあ」と思っていました。

あれから約3年半の開発経験を経て、今回の発表。自分が理解できていなかった頃から続くこれまでのDDD実践の積み重ねから今のベストの実装に至るまでを振り返ることで、これまで自分が当たり前に使っていた仕組みのありがたみを実感することになりました。

DDDは面白い

私がDDD面白いなと思うようになったのは今年に入った頃で、結構最近の話です。ある案件をひとつメインで任されて、設計をじっくり考える時間をもらったのがきっかけでした。
ひたすらドメインモデルを考えて、実装してみて、うまくいかないところがあったら書き直し、サービス仕様がはっきりしてくる中で変えたいところがあったら書き直し、を繰り返す。 その中で(これはすごく感覚的な話なのですが)頭の中が開けるみたいにドメインがぱーっと理解できた瞬間がありました。これだー!という感覚。
ドメインがしっくりくるようになって、そのまま設計できて、その時にDDD面白いなもっと考えたいなと思うようになりました。

そういうわけでとても最近の話なのですが、今回の発表を経て、また考えてみたい事が増えました。まだまだ飽きることなく、これからも試行錯誤、取り組んでいけそうです。

最後に

お約束ですが! こんなかんじで取り組んでます弊社のDDD開発に興味が出てきませんでしょうかどうでしょうか。エンジニア超!募集中です〜!ぜひに!よろしくおねがいしまーす!!

*1:発表当日に上がっていた資料には隠しスライドが入ってしまっていたためアップし直しました。失礼しました…

図:外部設計で作るべきドキュメントを考える 二期作

以下の記事で作った図をさらに俯瞰して、ドキュメント同士の前後関係を書く。

eri-twin.hateblo.jp

緑が↑で挙げたドキュメントたち。ユースケース記述とロバストネス図はいったん「機能詳細設計」でまとめ直した。
ピンクはinput、自分たちで書かないやつ

f:id:eri-twin:20180910164335p:plain

矢印の手前のドキュメントをインプットにして、次のドキュメントを作っていくイメージ。(図だけに)

ST仕様書だけは一応書いたんだけど、テスト向けのドキュメントについてはまだ考えられてないのでここでは掘り下げない。
まずは外部設計を開発用ドキュメントの一旦のゴールとして、それに向けてどういうものが必要かのまとめ図。

設計段階のいろいろを勉強したので、新しい案件やりたいな〜

システム設計の基礎:外部設計で作るべきドキュメントを考える

システム設計の基礎を学ぶ研修に会社のお金で行かせてもらったので、成果を書きます。

今回のテーマ

外部設計で作るべきドキュメントとはなにか?

研修の内容を受けて、外部設計段階で作成する一般的なドキュメントをまとめました。
それに対し、自分の開発チームがいま作っている資料を一般的なドキュメントの内容と比較・対応させて、外部設計にどんな資料が必要なのか考えました。

設計の前に:要件定義の確認

要件定義のアウトプットとして作成されるドキュメントは以下のようなものがある。

  • データフロー図(DFD)
  • 業務フロー図

うちだと、要件を文章や図で書いたものと業務フロー図がサービス仕様書に表現されているはず。このサービス仕様書を最初のインプットとして外部設計を作成し、業務設計担当者との認識を合わせていく。

まずは要件定義の確認、サービス仕様書を読む。チームで読み合わせとかすると良い。足りていない部分があれば要件定義した人に聞いてみる。

特に非機能要件、性能やSLAは設計に影響するので注意。
要件に書ききれていない非機能要件を聞き出せるのが良いエンジニアとのこと。

外部設計資料の一覧(一般)

世の中にはいろんなドキュメントがある
研修で習った各ドキュメントの名称と、表現したいことを簡単にまとめる。

コンテキスト図
  • 開発領域、スコープ
  • 関連システムの洗い出し
システム階層図
用語(ドメイン)一覧
  • 用語の標準化
  • 用語の定義
論理データモデル
  • データ項目
  • データの関連性
システムフロー図
  • データと機能の関係
  • 機能の処理順序
機能仕様書
  • 機能の詳細(Input, Process, Output)
  • 人とシステムの区別
機能/エンティティマトリックス
  • 機能に対する各エンティティのCRUD
エンティティ仕様書
  • データ項目の属性、桁数、制約(NOT NULLとかUNIQUEとか)
非機能要求仕様書
  • 非機能要件の詳細

(うちのチーム的に)必要な外部設計資料とは

ここからがサビ
自分たちが作っているドキュメントと、研修で習ったドキュメントとを繋ぐ。

システム階層図 -> API・バッチ一覧

単純に実装する機能の一覧。
資料として明示的に作らない場合でも、チケット管理ツールのエピック等で表現されてるイメージ。

用語一覧 + 論理データモデル(+ ちょっとコンテキスト図) -> ドメインモデル

ドメイン名は見ればわかる名前、そのものの本質を表す名前をつけるようにしている。そのため、用語の意味はドメイン名によって表現される。
通常ドメイン名はなるべくサービス仕様書に記述されている言葉を用いるので、その場合はサービス仕様書内で意味も定義されているはず。
システム的な都合で作成されたドメインの場合など、業務に現れないドメインの場合は、外部設計仕様書に別途記載する必要がありそう。

データの関連性は、モデル中の多重度、依存関係で表現される。

関連するサブシステムとの結合もドメインモデル中に表現している。
これらを書くことで、開発領域も可視化できる。

システムフロー図 + 機能仕様書 -> ユースケース記述・ロバストネス図

要求の機能をより具体的に落とし込んだドキュメントとして同じ位置だと考えた。 ユースケース記述は、文章でユースケース単位のInput, Process, Outputを表現できる。(≒ 機能仕様書)

ユースケース記述はロバストネス図のインプットになる。図にすることで、

  • 人(アクタ)とシステム(エンティティ・コントローラ)の区別
  • データ(エンティティ)と機能(コントローラ)の関係
  • 処理順序

あたりが自然に表現できそう。
ユースケース記述とロバストネス図だと切り口がユースケースという視点になるけれど、 機能とデータと人、それぞれどう関係しているかを表す分には十分かなと思う。

もうちょいシンプルに機能とデータの関係を表した図をいつも書いていたけど、あれが何図なのかわからない (ずっとコンポ図と呼んでいたけど、ちゃんと調べたらなんか違う気がする…)。

機能・エンティティマトリックス -> 状態遷移表
  • 特定のイベントが起きた場合のエンティティの状態

研修中はこれが似たような位置だと思ったけど、社内で聞いてみたら設計思想によって使い分けた方が良さそうという話になった。

弊社はイベントドリブンで作ってることが多いので状態遷移表をよく書いてるけど、 CRUDは外部のサブシステムの機能から呼ばれた場合とかも書ける。
なにかのイベントが起きたことを検知して自分の状態が変わるのが前者、 このエンティティはこの状態になれ!っていうのが後者の考え方。 たぶん。

ほか、普段あんまり作ってないもの

  • 非機能要求一覧
  • コーディング規約

非機能要件の確認は冒頭に書いた上に、最近はデザインレビューの項目でもあるので、設計の初期段階で明確に検討するべきなのだと感じた。抜けがち。

コーディング規約はうちのチームは放棄…わりと察する系(つらい)。

  • エンティティ仕様書 -> テーブル設計(内部設計)

エンティティ仕様書は桁数とか制約も書くので、うち的にはテーブル設計だと思うんだけど、 このあたりまで外部設計の段階で書くものだとは思ってなかったので意外。
研修中でも物理データモデル設計は内部設計側にあるので合ってるんだけど、たとえばユニーク制約とか貼ったら、このデータはユーザごとに一意なんですとか、 そういうレベルの話は要求者側に認識してもらっても良いのかもな〜と思った。

まとめ:外部設計ではどんなドキュメントが必要なのか?

結論、これを作れば設計はばっちりのはずだ!

さいごに

この研修を受けた目的は、標準を知らない自分が、社外で標準的な開発プロセスを学んできた人と話せるようになることでした。

で、研修で世間の標準を学んでみてよかったことがあって、
「自分の中に標準があることの安心感、自信」
を感じられるようになったこと。

これまで外部設計も見よう見まねでこれがほしいあれがいるかもと付け足したり消したりしながら迷走していた状態だったのですが、
たとえば、これは外部設計で書くべきなんですか (開発チーム内部で共有できていれば十分な内容なのでは?)という問いに対して、前は答えられなかったけれど、研修を受けてからは 「これは自分が勝手に言っているだけのものではない」「要求元に確認したほうが良い内容だ」「こういう内容が必要だ」 という裏付けがある状態になったので、多少自信を持って話せるようになった。

ある程度の現場経験を積んでから理論を学ぶと、ここで言われてることって今までやってきたあれなんだ! というような気づきを得られるようになり、最近は読書もすごく楽しくなっているのですが、研修もとても良いインプットになりました。めちゃくちゃ忙しくて死ぬかと思ったけど本当に行ってよかった。

あと余談ですが最近ユースケース駆動開発実践ガイドを読んでるのでもろ影響されてる(ロバストネス図のくだりとか)。

以上、ここまでお読みいただきありがとうございました。
この内容に対する見解がありましたらぜひ教えてください。

社外研修にいこう

会社に行きたくなくなった日、反対方向の電車に揺られて向かうための海の用意がありますか?わたしはあります。どこかは秘密です。

昨日から明日まで3日間、社外の研修に行っています。システム設計の基本を学びに行っています。内容はまた研修が終わったら機会を改めてアウトプットをしたいと思います。
しかしなんというか世の中には色んな人がいるんだなあと思いました。そういう話をします。

研修の参加者は発注側と開発者のどちらもいます。混合でグループワークをしているので他の参加者の方々ともお話しするのですが、発注側のとある人がパンチ効きすぎていてすごい。もうこの人はすごいのでおじさんと呼びます。 研修中のわたしたちはもろもろ仕様書などを書いており、今日は状態遷移の線を一本引き忘れた仕様書を作成し隣のチームからのレビューでボコボコにされる楽しい演習でした。めちゃくちゃバグってるじゃんと笑っているところで、おじさんは言いました。
「これ書いたの誰?」

チームの成果物はチームの責任で作ったものなので、これは全員の責任ですからね!と反射的に大きな声が出て自分で焦りました。当たり前すぎて忘れていましたが世の中チームで働くという経験をしている人は少ないのですよね。いやまあそうですよね。冷静になればそうです。そんなこと言ってくるプロマネとかまじで嫌だなあとか絶対一緒に仕事したくないなとか思いましたが世の中そういうものなのかなと考えさせられました。
しかしおじさんは容赦なく畳み掛けてきます。「大きな指摘はなかったの?」「いや、今言いましたけどこの遷移がひとつ抜けていたんですよ」ここでおじさんは再び攻撃を繰り出してきます。
「なんだ。じゃあひとつ忘れただけ?」

いや結構ですよ、結構なバグですよ、その遷移をひとつ抜かしたせいで我らの設計したシステムは5000品目の商品を扱う発注システムで1品目ずつしか注文できないというすてきな仕様になっています。他のメンバーはちゃんとこの致命的バグを認識しているのに?このまま発注したら大惨事だけどその認識で本当にシステム開発を依頼する仕事をなさるのでしょうか?絶対一緒に仕事したくないなとか思いましたが世の中そういうものなのかなと考えさせられました。
社外を知るという目的は達成されたと感じています。文字通り知見が広がりました。世の中色んな人がいるんだ。べんきょうになるなあ。研修にいってよかったなあ。研修の後会社に帰ってきたら会話がつつがなく進んでいく環境に感動を覚えました。弊社はすごい!研修カリキュラムはまだあと1日残っていますが既にすごいおじさんと遭遇できているのでたいへん貴重な経験ができました!みんな社外研修に行こう!絶対に許すな!

良いチームは良いふりかえりから

今日は前向きに、ふりかえりについて書きます。

良いチームは良いふりかえりから

毎スプリントの終わりにやっている、ふりかえり。
その中で最近やってよかったことを紹介します。
(社内の開発チーム向けLTで発表した内容です)

agenda

ふりかえりは以下の流れでやります。

  1. Tryのふりかえり、エターナルキープ
  2. 今週の自分コーナー
  3. KPT(いつもの)
  4. Tryを朝会で毎日確認

1. Tryのふりかえり&エターナルキープ

KPTしても、せっかく出したTryするする詐欺になることがある。それはもったいないので、Tryをやりっぱなしにしないために、必ずTryのふりかえりをします。

  • 先週出したTryはTryできたか?
  • TryしたならProblemは解決したか?

をみんなで話し合います。

  • よくなかったらやめる
  • よかったら継続する(キープ)
  • 意識しなくてもできるくらい身についたら、エターナルキープ(EK)へ移動

エターナルキープとは文字通り永遠のキープです。
そしてエターナルキープの数はチームが挑戦してきたことの数、チームが積み重ねてきた軌跡そのものです。
たまにまとめて見返すと、達成感でしみじみします。

2. 今週の自分コーナー

ただのKPTでは飽きてきたのでなにか新鮮味を、という時に出てきたTryのひとつ。
ふせんに「今週の自分」を絵で描いてひとりずつ発表します。
とてももりあがります。アイスブレーク的な立ち位置です。

ここで書くのはなんでもあり。人物画から抽象画まで個性が際立つ。内容もプライベートなこともOKとしているので、個人のことをよく知れてコミュニケーションのネタにもなったり。
基本的にワイワイ楽しくやります!

3. KPT(いつもの)

ここからいつものKPT。ですが良いチームのふりかえりはここが違う。

  • Keep:みんなで喜ぶ
  • Problem:みんなで反省する
  • Try:チームで改善したいものをひとつ以上決める
    • やる。で終わらないやつ
    • みんなでやれるやつ
    • やる気のあるやつ

良いチームではK/Pどちらもたくさん出てきます。特にK。その週にチームで起きたことをみんながわかってるから、他の誰かが出したKもPも自然に自分事になる。

そして最大のポイントはチームで改善したいものをひとつ以上決めることです。特に、誰かがやるのではなくチームとしてやることというのが大切です。

たとえば超具体的な例ですが、

  • P:残業が多い。つらい→T:朝のうちに今日やることのゴールを決めておく。ここまで終わったら帰ろうの流れをつくる
  • P:ベロシティを上げたい。モブプロ全員でやるのはちょっと無駄が多いのではないか→T:4人チームなので2人ずつのペアに分かれて作業してみよう

のような取り組みをしました。これももちろん前述のように、スプリントの最後にふりかえりして成果が出ているかどうかを確認します。

4. Tryを朝会で毎日確認

Tryするする詐欺になりがちなもうひとつの要因として、Tryを忘れる、一旦ふりかえりが終わったら次のふりかえりまで見直さない…というのがあると思います。それを改善します。

  • 朝会チートシートに「Tryの確認」を入れる
  • Tryできてるか、毎朝みんなで確認

できてると「おっTryできてるじゃん〜」て元気になれます。
毎日確認されるので、忘れてると思い出します。
最終的に次のふりかえりでまた確認されるので、これはやったほうがいい!と各々が思ったことは自然に取り組むようになったと思います。

まとめ

ふりかえり、ちゃんとやってますか?惰性になってませんか? この中で自分のチームでも取り入れられそうな要素があったら、ぜひ取り入れてみてください。ふりかえりが面倒になってきたとき、なにかひとつ新しいことをやってみる、それだけでもチームの空気が変わるきっかけになると思います。

良いチームは良いふりかえりから!!!
良いチームを作っていきましょう!!!

心の余裕を持ちたい話

先週のHUGっと!プリキュア23話で「30過ぎた大人には仲間なんていない」と発言する敵キャラが現れて物議をかもしていましたが、心の余裕がないとこうなってしまうのかなあなんてそこにある程度の実感を伴ってしまうあたりがつらい年頃です。

忙しいと余裕がなくなる。 余裕がなくなって良くないことのひとつに、「自分はこんなにがんばってるのに」という意識で苛立ちが他責の方向に行ってしまうことがあると思う。 同じ案件に関わる人たちのはずなのに、自分の周りとそれ以外で線を引いてしまう。自分の内側、その線より向こう側が外側。
だんだんと外側の人や作業に対して「わざわざ時間取って○○したのに」みたいな意識が出てくる。

「自分の案件は忙しいのに」
「自分のチームは忙しいのに」
「自分は忙しいのに」
自分の内側にある範囲がどんどん狭くなっていって、関連するチームやチームメンバー、一緒にやっているはずの人たちのことまで外側においてしまう。

仕事が果てしなくうまくいっていないとき社会人歴2年先輩の友人に「自分以外の人が全員自分をバカにしているような気がしている」と相談したら2年前に通った道だと言われたことがあるので、大抵だれしもみんなこういうことがあるんだろうなと思う。
とにもかくにも、進捗に安心感があるかないかだけでこのへんの心の余裕は全然違ってくるので見積もりとリリースプランニングをやりましょう。考えて見える化しておけば不安もやわらぐ。見えないものが不安になる。見えるものは怖くない。

もういい大人なんだから感情的にならずに仕事したいと思うしなるべく笑っていたいと思うけど、どうしても余裕がない時は苛立ったりしてしまう。というか結構感情が出る方なので落ち着きたい。空気を悪くして良いことなんてひとつもないと頭ではわかっているつもりだけれども全然ままならない。