ドメイン駆動設計の探求 其の一 モデルと実装を協調させる、とはどういうことか

どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計(DDD)の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。

「それ、ソースコードに書いてないじゃん」

それは、DDDを前提においたコードレビューで飛び出した指摘でした。

コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。

一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。

それを話した時に、弊社増田の口から飛び出たのが、、、

「んで、それはソースコードの何処に書いてあるの?」

実装に構造を語らせるために

この時、僕は軽く衝撃を受けました。

「だって、ソースコード見てそのドメインの関心事が分からなければ、3年後見た時にわかると思う?」

…はい、分かりませんよね。そりゃあ。

そう、エヴァンスのDDD本に書いてあった、以下の一節は、そういうことを言っています。

ある種の意思決定をすることによって、モデルと実装の協調が保たれ、互いがもう一方の効果を高めるようになる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

モデルと実装が、協調している。モデル通りの実装になっているし、実装からモデルがわかる。そのモデルというのは、ただの設計構造ではなく、顧客の関心ごとを反映した「ドメイン」である、ということ。

ではどうすればいいのか?

「それに答えなんかないですよ。色々実験してみることです。例えば、感想が重要な関心事なら 主従関係をひっくり返して、感想を投稿の親にしてみては?」

確かに、ソースコードで物を語るには、クラスの所有関係を表すのが一番です。なんとなく、理屈で収まりがいいツリー構造を考えてしまいますが、勇気を持って構造を組み替えたりして、色々実験しなければなりません。

確かに、DDDではリポジトリという形で、永続化処理をドメインから分離しています。そうすることで、永続化層の理屈をドメインから分離し、ドメインの中で腹落ちするようなモデルを構築していくのですね。

ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

と、偉そうなことを書いていますが、私もまだまだ勉強中の身。これからも色々と実験を重ねていきたいと思います。

ギルドワークスでは、こうやってドメインのあるべき構造を追い求めてくれるような、ギルドメンバーを引き続き募集中です!興味を持たれた方は、こちらからどうぞ

エクストリームプログラミング 第二版 でXPに再入門しています。 #xpe2nd

どうも、ギルドワークス 前川です。

さて、皆さんはもうお読みになりましたよね!新訳版エクストリームプログラミング!非常の楽しい本なので、是非皆さんもチェックしていただければと思っています。

XPへの誤解

さて、このようにテンション高く始めてしまいましたが、私は実はXPの旧訳は読んだことがありませんでした。のみならず、XPをテーマにした本自体を、あまり読んでいませんでした。

実は私と同世代くらいの(昭和ギリギリ50年代くらい生まれくらいの)エンジニアには、結構同じ境遇の人、あんまりXPに関する書籍を読んでいない、という方が多いのではないかな?と思ったりしています。

なぜでしょう?それは、私がソフトウェアを本格的に勉強し始めたのと時を同じくして、XPの熱狂は去り、Scrumの波がやってきた、ように見えたのです。

その時、ソフトウェアの入門者を取り囲む空気には、少なからず偏見のようなものがあったと思っています。「XPは技術寄り」「Scrumの方がフレームワークとして定まっているので組織に入れやすい」「XPはスーパーエンジニア向けのもの」など、XPは効果的なんだろうけれど、とても導入が難しいエクストリームなものという言説は、同時いわれていたのではないでしょうか?

ギルドワークスにおけるXP

実はギルドワークスに入ってからも、少なからずこういったイメージを持ってしまっていたのですが、増田さんや市谷さんなど、ギルドワークスのメンバーから、XPの価値原則について、何度も熱く語ってもらいました。

XPといえばどうしても、全員同席テストファーストなどのプラクティスが強調され印象に残ってしまっていたので、XPの価値と原則について、改めて考えなければ、と思っていたのでした。

そんな時にちょうど出版されたのが、新訳版エクストリームプログラミングです。迷わず手を取り、読み始めました。

XPの価値と原則

まず、びっくりしたのは、最初の一文です。

エクストリームプログラミング(XP)とはソーシャルチェンジである。

帯にも書いてあるこの言葉は、本文の最初に出てくる言葉です。

ソーシャルチェンジってなによ?となりますが、あとがきで簡単に触れられています。

XPは必ずしも「社会」を変えるための活動ではない。隣の席にいるプログラマとうまくコミュニケーションしたり、顧客と密接にやりとりしたり、ユーザーが安心して使えるソフトウェアを届けたりする。そうした「人間関係」を扱う活動こそが、エクストリームプログラミングである。

そう、XPのというとバリバリの技術に尖った手法、というイメージを持ってしまっていたのですが、違います。人間関係を、仕事をしやすいよう変えていくのが、XPなのです。

なので、XPの価値には“コミュニケーション”“勇気”といった、人間関係を透明でわかりやすく、話しやすくする仕組みが埋め込まれていますし、原則にも”人間性“や”多様性”など、人間関係を豊かにする活動が詰め込まれています。

プラクティス以前に語られる、こういった価値と原則は、実はギルドワークスの「正しいものを正しくつくる」「越境」といった言葉に非常に密接にリンクしている、ということに遅まきながら気づいたのでした。

私も、皆さんと一緒に、自分の周りを Social Change していきたいと思います!

※アイキャッチの写真 https://flic.kr/p/3p69ZX

リモートiOS開発成功の処方箋、早期のCI導入

どうも、ギルドワークス 前川です。京都からリモート作業を行っていますが、この二週間は、祇園祭でとんでもない人出となっております。

リモートでの開発に必要なもの

ギルドワークスでは、Webサービスだけでなく、iOSやAndroidの開発もリモートで行ってきています。その中で、最近一つのパターンとなっているのが「可能な限り初期に継続的ビルド(CI)を導入する」ことです。

もちろんCIは手段でしかありません。その目的は、「全員が同じものを見て確認する」ためです。対象がWebサービスならば、例えばHerokuにデプロイされたものを正として扱ってやれば、事は済みます。

しかしiOS開発では、そうはいきません。全員が「同じもの」を見ることが非常に重要ですが、それにはCIされた成果物を共通の場所においておき、それを参照する、これしかありません。

ここは結構厳格にやらなければいけない、と私は思ってます。例えばレビュー指摘をしても「ここは自分の環境では動いてますんで」などと言われると、そこで会話が止まってしまい、フィードバックが割と根本から絶たれてしまうのです。

「masterにpushされたものが唯一にして絶対の正」これを守るのは、簡単で、そしてもとても即効性のある、リモートiOS開発改善の処方箋なのです。

ギルドワークスが利用しているサービス:Circle CI

iOSのビルドはまだまだローカルJenkinsが主流だとは思いますが、リモートワークを掲げる当社としては、やはりCIを行ってくれるWebサービスを使用したいところです。

というわけで、ギルドワークスが利用しているサービスがCircle CIとなります。

Circle CIは”Experimental Setting(実験的な設定)”ながらもiOSのビルドを行うことができます。しかも、ビルド速度に制限はかかってしまうものの、Private レポジトリを含めて無料 でCIサービスを利用できます。

詳しい設定は、以下の公式ドキュメント(英語)をご覧ください。

iOSビルドの便利ツール、Schenzen

CircleCIでは、基本的にコマンドラインでビルドを実行していきます。

一応Xcodeにもxcodebuildというビルドツールが付属しているのですが、設定項目が結構多く、なかなか使いこなすのは大変です。また、iOSのファイル配布型式であるIPAファイルを作るのには、別のコマンドを色々叩く必要があり、大変です。

そんな時便利なのが、schenzenというコマンドラインツールです。

このツールを使えば、環境変数さえ適切に設定していれば、以下のように非常にシンプルなスクリプトで、ipaのビルドから、DeployGateなどのベータ配布サービスへの配信までやってくれます。

ipa build
ipa distribute

これらのサービスを活用して、ギルドワークスでは、以下の様なデプロイメントパイプラインを、手軽に組むことができています。

スクリーンショット 2015-07-14 18.45.01

これからのCIのトレンド

こういったギルドワークスでの取り組みを踏まえて、先日大阪の「CI勉強会」という勉強会で発表をしてきました。

タイトルは、「ポストJenkins時代のビルド戦略」

Jenkins一択時代から、色々なサービスを組み合わせる時代へ。今、結構大きな転換点が来ていると思っています。新しいツールやサービスとしっかり向き合って、自分たちの組織に最適な解を導きたいですよね。

もし、このようなCI周りの技術的悩みがおありなら、ギルドワークスにお気軽にお問い合わせください!

リモートワーク隆盛のいまこそ、パートナーに会いに行く

どうも、ギルドワークス前川です。

先日、市谷と私がそれぞれ島根でお話をしてきたのを、ご報告させていただきました。

さて、島根にはもちろんAgile Shimane の皆さんにお会いする、という目的もあったのですが、もう一つギルドワークスとして重要な目的が有りました。

実は今、ある開発をギルドメンバーとして一緒に進めているエンジニアの方が、島根は出雲に本拠を置いていらっしゃるのです。

もちろんこれまでもSlackやSkype、そしてGithubなどを通して十分なコミュニケーションは取っていました。仕様を伝えて、見積もりを伝えて、コードをコミットし合い、進捗を確認して、LGTMして、などなど。

でも、これらのやりとりは、ともするとビジネスライクで「表面的」な関係になってしまいます。ギルドワークスは、お客さんだけでなく、ギルドメンバーともお互いに越境したい。仕様について「これでいいの?」「コンセプトからするとこうあるべきなのでは?」と語り合ったり、設計について「こうすればもっとお客さんのドメインを表現できる」と深く探求したり、など、もっとお互い踏み込んだコミュニケーションをしたい、と考えています。

それには、やはり文字や音声だけのやりとりだけでは、圧倒的に情報が足りません。どんな環境で仕事をされているのか。お昼はどんな場所で食べておられるのか。仕事を終えた後はどんなところで飲んでおられるのか。飲みながら、どんな思いで開発について語っておられるのか・・・

今回の島根訪問では、ギルドメンバーのこういった熱い思いを、しっかりと聞くことができました。出雲蕎麦を食べながら会社を設立された熱い思いを伺い、終電ギリギリまで駅前のバーで技術話で盛り上がり、なんとも楽しい時間でした!

リモートでほぼ仕事ができる環境が整っているからこそ、敢えて直接話しをしに行く。そこで意気投合した気持ちを軸に、もっと深い話をSlackやSkypeで発信していく。

まさに、今そういう開発ができているように思います。

これからも、全国に散らばる仲間たちと、語らいに出かけようと思っています。

そして、私達と組んで熱く語り合い、「正しいものを正しく作る」仲間も募集しています。是非お声かけ下さいませ。

アイキャッチ画像: https://flic.kr/p/c1iJvo

ギルドワークスの「現場」コーチ

先日市谷の投稿にもありましたが、Agile Shimane(松江)にお招き頂き、お話してきました。

私自身、ギルドワークスの一員として、ギルドワークスの仲間と一緒に喋る、というのは初めての経験でしたので、結構緊張しました。 私の話は、ギルドワークスの「現場」コーチとは何か、というものでした。

そう、今回の発表で伝えたかったのは、ギルドワークスは「現場」コーチだということです。アジャイルコーチでもなければ、開発コーチでもない。現場を良くするためなら手段を問わない、越境していく、そんな姿勢でコーチという役割に向き合っています。

そんなギルドワークスの現場コーチに興味がある方は、こちらからお気軽にお問い合わせください。

すでに市谷の資料は上がっておりますが、Kent BeckのXP本 に二人共ふれていたりと、当日の二人の発表は、違う内容を話しつつ同じような発想へと最終的には至っているように私は感じました。

Joinしてから二ヶ月、ギルドワークスの一員として馴染んで行けているのかなぁ、、、と勝手に感慨にふけったりもしています。

定冠詞”the”の重要性を、アジャイルマニフェストから学ぶ。

ギルドワークス 前川です。

自信を持って言えるほどではありませんが、英語はちょっとは読み書きできます。そもそも英語の強さは、二種類あると思います。

一つは、語彙力。じつはこれ、僕はあんまりありません。なので結構英辞郎やロングマンの英英辞典を引っ張ってくることは多いです。

もう一つが、文法力。というか、英語のルールを知っておくこと、ですね。こっちのほうが僕は少し得意です。

文法と聞くと、あんまりいい顔する人はいないでしょうが、本来英文法ってのは英語の考え方を知るためのツールなんです。なので、幾つか知っておくだけで格段に英語の見方が変わりますよ。

そんなわけで、恐らく最も簡単な英単語の一つ、にして、多くの人が重要性を意識せず使っている”the”についてお話します。

定冠詞 “the”

“the”は文法上の分類で「定冠詞」と呼ばれます。「定冠詞」があれば「不定冠詞」はあるのか?というと、あります。”a”です。どちらも英語を勉強してごくごく初期にでてくるものですね。

この2つの違いは何でしょうか?実はもう名前の時点で答えが出てるんですが、定まったもの=文脈上一意に特定できる/するものを定冠詞で表します。バカみたいな例で恐縮ですが。

This is a pen.

は単独で意味が通りますが、

This is the pen.

は文単独では意味不明です。“the pen”ってどれなの!?となります。なので、例えば。

I found a pen yesterday. This is the pen.

みたいに文脈を付けないと意味がわかりません。

このように、”the”にはそれが指すものが一意に特定できている、という暗黙的な意味があるのです。逆に”the”を付けなかったり、”a”を使う場合には、これはふわっとした一般論を指しているという意味合いがつきます。

アジャイルマニフェストと原則における”the”の扱い

では、具体例としてアジャイルマニフェストアジャイル原則の原文を見てみましょう。

まずは、あまりにも有名なマニフェストの4つのセンテンスを引用します。

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

いかがでしょうか?そうです。Theは欠片もでてきません。マニフェスト中でTheがでてくるのは

That is, while there is value in the items on the right, we value the items on the left more.

このように、上に書かれている4センテンスで既に挙げられているものの、左のほうなのか右のほうなのか、を指定している部分だけなのです。

では、アジャイルの12の原則ではどうでしょうか?一つ目からいきなり、こうです。

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

the customer“なんです。特定できて、目の前にいる、そのお客さんなんです。

公式日本語訳は、こうなっています。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

もちろん意味は正しいし、日本語としても綺麗です。でも、この訳だと原文は”a customer”や”customers”でもいいんです。

「顧客満足を再優先する」だけでは、あまりにも元の英文が持つ鋭い意味合いから乖離してしまっている。

だって現場には目の前に製品を届けるお客さんがいるはずなんですから。「現場のお客様を」とか「目の前のお客様を」とかの方が良い表現に思えます(語調は汚くなりますが)。

他の原則はどうでしょうか?例えば、三番目のセンテンス。

Business people and developers must work together daily throughout the project.

“the customer”だけでなく、”the project“です。プロジェクトも、メンバーがちゃんと全員”the project”と言える状態に、メンバー全員が自分ごととして認識して「そのプロジェクト」で通じる状態になっている、という前提なんです。

このように、アジャイルマニフェストとアジャイル原則は、定冠詞という観点から見ると大きく印象が異なるものです。言ってしまえば、アジャイルマニフェストは一般論としてのふわっとした言葉です。

対して定冠詞が非常に多く登場し、対象が明確化されるアジャイル原則は、より開発現場に近いところで利用する実践的な言葉、といえます。

このような視点で、一度アジャイルの原典であるこの2つの文章、英語で味わってみるのはいかがでしょうか。

ユーザーストーリーの”INVEST”とどう付き合うか

ギルドワークス 前川です。

ギルドワークスで開発を行うときは、ユーザーストーリーを使ってタスクを管理することが多いです。その際に気をつけていることをまとめてみたいと思います。

ユーザーストーリーの”INVEST”

ユーザーストーリーをつくるときに意識するのは、おなじみ”INVEST”と呼ばれる、優れたユーザーストーリーが満たすべき特性です。

ちょっと復習してみましょうか。

Independent 独立している。先行するストーリーが完了してないと始められない、など他の影響を受けない。
Negotiable 交渉可能である。ストーリーが具体的なタスクに落ちすぎておらず、プロダクトオーナーと実現方法について交渉することができる。
Valuable 価値がある。ストーリー単独で顧客にとっての価値があること。
Estimable 見積もり可能である。ストーリーを実現するのにかかる時間が(他ストーリーとの相対時間として)見積もれるだけ、十分な情報があること。
Sized Right (Small) 適切な大きさである(小さい)。チームが開発を回していくにあたって、ストーリーを実現するのに要する時間が長すぎない程度に、適切なサイズに分割されていること。
Testable テスト可能である。そのストーリーが完了したかどうかをテストできること。受け入れ条件が明確になっていること。

このINVESTをしっかり意識したストーリーを作れば、うまくユーザーストーリーで開発を回すことができます!・・・って果たしてそうなんでしょうか?実は、”INVEST”全てを同時に満たすことは、かなり難しい、もっというとすべてを同時に満たすことにあまり意味が無いものなのです。

“INV”と”ES”の違い

例えば、「交渉可能」にしたストーリーって、やり方についてまだまだ交渉の余地を残しているということです。それって、「見積もり可能」 なほど固まっていない、とも言えます。

あるいは、ストーリー単独で「価値を出し」たり、他のストーリーに依存しない「独立した」ストーリーをつくろうと思うと、どうしても「適切な大きさ」から離れていってしまう、なんてことも有ります。

そう、前半3つの”INV”と続く”ES”は、実はコンフリクトするのです。なぜなら“INV”と”ES”は異なる要請から導かれているものだからです。

“INV”は、乱暴に言ってしまえば上流工程寄りのストーリーの捉え方です。システムに必要な機能を洗い出す際に抜け漏れをなくすため、実装時に柔軟な対応を確保しておくため、など要件定義やプロジェクトマネジメント的な観点からストーリーに求める要件なのです。

一方、”ES”は下流工程、つまりいざ手を動かして実装していく時に重要になってくる事柄です。開発チーム内で不幸なコミュニケーション事故がおこらないためにも、「見積もり可能」で「適切な大きさ」になっていなければいけません。

スクラム的なイテレーティブなプロセスを取るならば、まずは”INV”を重視したストーリーを作っておき、いざ実装が近づいてきたストーリーについて、”ES”の観点から見直し、必要に応じて書き換えたりバラしていく、という流れが必要になります。

圧倒的に大切な”T”

しかし、この中で”T”だけは別格です。”Testable”すなわち“受け入れ条件”だけは、ストーリーが生まれた時から死ぬまで明確にしておかないといけません。”受け入れい条件”がブレないからこそ、”INV”から”ES”に振ったとしても、そのストーリーが実現する物事についてブレなく矛盾なく保つことができます。たとえストーリーが分割されて小さくされたり、実現方法が決まって見積もり可能になったとしても、そのストーリーが達成された結果として実現されることは変わりません。

ユーザーストーリーのライフサイクル

このように、”T”をストーリーのかすがいにしつつ、上流寄りの”INV”なストーリーから下流寄りの”ES”なストーリーに変えていく、そんなライフサイクルを意識すれば、よりスムーズにユーザーストーリーを使って開発を行うことができるでしょう。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。

アイキャッチ画像