4/9 DevLOVE行ってきました

今日も楽しいDevLOVEに行ってきました。今回は「DevLOVE Beautiful Development」-ソフトウェアの核心にある複雑さに立ち向かう-と題された、DDDカンファレンスでした。

「Domain-Driven Design」の邦訳本「エリック・エヴァンスのドメイン駆動設計」が出版され、4/12にはQcon Tokyoに原著者「エリック・エヴァンス」さんが来日されるとあり、DDDクラスタな方とDevLOVEクラスタの方が約100名集まり、熱気ムンムンなカンファレンスでした。

さて、今回もカンファレンスのまとめ、ツイートのまとめなどは、皆様におまかせしてw、私は感想文を書きたいと思います。w（※まとめをしてくださっているみなさんありがとうございます。）

では、早速参加経緯から。今回は申し込み時と参加直前で若干モチベーションが変わりました。一貫したモチベーションは相変わらず
・DevLOVEだからまた行きたい！
です！！これは、今回も参加させていただき大変有意義でした。

変化したモチベーションですが、実は申し込んだときはDDDは「Domain-Driven Development」だと思ってました。お恥ずかしい話ですがビジネスやモデルにフィーチャーした開発手法のことだと思っており、TDD、TiDD、BDDなどに代表されるDDシリーズの仲間かと思い興味本位で申し込みました。申し込み後から主にWebでDDD関連のサイトやブログを徘徊し、今日に向けた下勉強をしました。その結果、モチベーションは、
・顧客との合意形成の質を高める点について聞きたい
・業務を設計に落とし込む方法論が聞きたい
に変わりました。

【モチベーションの背景】
私の会社はWeb系を中心に受託開発をしています。優秀なエンジニアもたくさんいますがw、Web系案件に多く見られる「製品品質よりビジネス品質を優先する」ことが多く、合意済みとは言え、言い訳かも知れませんが「潜在要件の引き出し不足による設計漏れ」「短納期に起因する設計不足」などが発生します。当社は顧客には恵まれており開発中にかなり濃密に顧客が関与してくれます。またエンジニアも実装論や手法よりビジネス品質や業務要件を重視してくれます。それでも上記の様な問題は発生し、製品品質の低さに起因するビジネス品質の低下を招く場合があります。今回はこの改善のために上位レイヤーでなく、下位レイヤー（設計、製造）の手法について特に興味を持ち、DDDの思想や概念だけでなく、方法論や体系について聞いて、社内に持ち帰ることができればと思っておりました。

【我々の失敗は何だったか】
「ユビキタス言語」
普段実践を心掛けていることが、体系立てられ、定義されるとこんなに響き方が違うんですね。私も含め開発者は顧客から対価（お金や感謝、敬意）を頂く以上、プロフェッショナリズムを提供しようとします。それは時として本当のプロフェッショナルとは違う、開発者の妄想や幻想から作り出された似非プロフェッショナルを演じることになります。その結果、難しい言葉で語り、業務には関係ないアルゴリズムを振りかざし、「勘違いしたした技術」の素晴らしさをひけらかし始めます。

「戦略的設計」
ドメインレイヤー。はたしてこの概念をもって設計されていたか？もちろんYesな部分もありますが、Noが大半です。Web系の場合、特に顧客も開発側もエンドユーザー視点に立ちたがります。コンシューマーにサービスを提供するのだから当然ですが、例えばECなどの場合、コンシューマー向けサービスはC/Sや競合との優位性確保のために当然重要ですが、サービスのバックボーンが貧弱ではどんなにデザインが優れ、感動的なUXを提供できたとしても、結果的に意味がありません。陳列したい商品が適切な価格で即座に提供できる、承った注文を承った通りお届けできる、戦略的なサービスを展開するために正しい分析結果がでる、コンシューマーからの問い合わせやクレームに即明確な応対ができるなど、商売には本質があるはずです。この観点でドメインレイヤーの抽出やモデリングが行われないと、ユーザーインターフェイスレイヤーとアプリケーションレイヤにほぼすべてが登場する頭でっかちな（尻でっかち？）ソフトウェアが完成します。

「設計と実装の乖離」
これは設計した通りに実装されていないという根本の話では当然ありませんww。本日のカンファレンスに参加しても言葉にするのは難しいのですが、要件定義＞基本設計＞詳細設計＞実装と落ちてくるにつれ、要求や要件が持っていた有機成分が徐々に失われ無機的になる。もしくは不要な有機成分が集まり始めて混沌となる。ニュアンスの問題で表現がうまくできませんが、「ドメインエキスパートの知識が厳格に組織され、選択的に抽象化されたもの」が「開発者（設計者）の力量が独善的に表現され、選択的に具現化したもの」となってしまいます。

【これから取り組みたいこと】
「ユビキタス言語の意識」と「コンテキスト境界の意識」。この2つを実践するだけでも開発の成功率や、同期間で提供できる品質は大幅に向上できるのではないかと考えます。私の会社は専門用語ではなく顧客に分かる言葉で会話することは意識できていると思います。ただしこれは「ユビキタス言語」の概念には及ばず「ただの噛み砕き」であり、設計や実装には反映されません。たとえば「ユビキタス言語」を意識した基本設計書（外部設計書）ができただけでも顧客との合意形成は深まるものと思います。また「ユビキタス言語の意識」は開発者だけでなく、アーキテクト、インフラエンジニア、デザイナー、営業などチーム全体で取り組め、思想共有できることからチーム結束力も高まるものと思います。DDDだけが正解とは思いませんが、実践し、良いところを吸収し、スクラム×TDD×DDDが実践できたら、もっともっと多くの人を幸せにできるのではないかと夢が膨らみます。

今日は「ハッ」とさせられることが多かったのですが、2つだけリマインドを兼ねて紹介します。

【その１】
@masuda220さんの講演から「実装=必要　設計=重要」。おっしゃる通りです。こういう事を言葉にできてしまうって感動します。

【その２】
@digitalsoul0124さんの講演、キーノートでは「旅行手配」を題材にDDD実践していただきました。この中で「旅行の最終目的地は自宅」と言った言葉がでました。キーノートが始まってからノートを開いて自分なりにモデリングをしながらお話を聞いていたのですが、モデル図を描き、業務要件を前提項目として書き出していました。すっかりお仕事を受注した気分で設計をしていたのですが、自分なりに旅行手配をする立場に立ったり、旅行者の立場に立ったりしながら前提条件を書き出していたつもりですが、「最終目的地が自宅」この一言には愕然としました。旅行者の立場に立っても、滞在地をめぐること、その楽しい風景しかイマジネーションできませんでした。しかし、旅行手配する側からすれば恐らく最重要要件、まさに業務の本質であり、旅行者の立場に立っても口に出さないまでも絶対条件であるはずのことが、頭をよぎりもしませんでした。「ドメインエキスパートの知識を抽象化」できていればきっとたどり着いたであろうと思わせてくれたこのセッションは聞いて本当に良かったです。

さて、今回も厚かましい私は、上記のお二人とそれぞれビアバッシュでお話しさせていただきました。ありがとうございます。

カンファレンスの最後に1000人帆立てビデオ作成のために、私も帆立て宣言しました。
「DevLOVEを通して学んだことで一人でも多くの社員を幸せにする！」
頑張ります！！

最後に、今回もDevLOVE運営チームの皆様、登壇された皆様、LTされた皆様、参加者の皆様、本当にありがとうございました。

最後の最後に、えーーー、反省しきりですが、あくまでもDDDに照らしての話です。我々は日々進化しながらも、常に最善を尽くして開発をしています。お客様各位におかれましては、このエントリを見て不安にならないでください。ww

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)