トーク

優れたシステムは直面している課題を的確に解決し、その課題の要因へ繋がるさらなる課題提起へ導きます。ビジネス、システム、コードなど、いくつかのレイヤーをオブジェクト指向でとらえ、高い価値を提供するためのアプローチについて話します。

優れたアイデアからは連鎖的に、新たなアイデアが創造されます。
いまやオブジェクト指向は大きな広がりを見せ、世の中にはオブジェクト指向に端を発したアイデアが次々と生み出されています。

人に個性があるように、それらのアイデアにはそれぞれ個性があります。
それらをすべてまとめあげ、ひとつのオブジェクト指向として扱うのは難しいことでしょう。

本トークは「オブジェクト指向の多様性との対峙の仕方」をテーマにします。
オブジェクト指向が多様性をどのように取り扱っているかをヒントに、
オブジェクト指向自体の多様性とどのように付き合っていく術についてお話いたします。

オブジェクト指向に関わらず、あるアイデアから多様な価値が生まれ、それらが同じ文脈で語られることで混乱をきたすような場面を多く見かけます。
本トークはそういったものとの対峙法のひとつとして活用できるでしょう。

オブジェクト指向の豆蔵と言われはや 20 年。これまで
CORBA, EJB, SOA, プロダクトライン, アジャイル, DDD
と様々な技術トレンドが駆け巡ってきました。その中で
豆蔵は一貫してソフトウェアエンジニアリングの重要性を
訴え、顧客のニーズとソフトウェアのあるべきアーキ
テクチャの橋渡しを行って参りました。
結局ソフトウェアエンジニアリング・オブジェクト指向・
モデリングでしょ。
いくつかの事例を元に意味のあるソフトウェアを正しく
作るためのヒントをお話しいたします。

VOYAGE GROUPでは複数のサービスを提供していますが、ほとんどのプロダクトが自社開発です。VOYAGE GROUPのエンジニアはサービス全般に責任を持っているため、ドメインエキスパートであり、開発者であり、サービス運営者でもあります。
幅広くビジネスに対して責任を求められる中、弊社のエンジニアはどのように考えてシステムを設計しているのか、どのような取り組みを行っているのかなど、ビジネスを成長させるためにVOYAGE GROUPが行っている仕掛けをいくつか例を上げて紹介いたします。

READYFORは、2011年に日本初のクラウドファンディングとして始まったサービスです。我々は「誰もがやりたいことを実現できる世の中をつくる」というビジョンのもと「想いの乗ったお金の流れを増やす」ためのプロダクト開発を日々行なっています。そのような新規開発をスピーディーに推し進める上でも、9年間積み重ねてきたレガシーとしっかりと向き合い、戦っていく必要があり、そのための武器の一つがDDDだと考えています。本セッションでは、READYFORにおけるドメインや既存システムの複雑さを解説し、DDDを用いてどのようにして境界づけられたコンテクストやユビキタス言語を構築し、理想のシステム像を設計した上でリファクタリングを推し進めていこうとしているかをお話しします。

2011年3月にリリースされたChatworkも今年で9年目となり、その間、何度もリファクタリングとリアーキテクティングを繰り返してきました。
長く運用されているシステムらしく様々なレガシーと呼べる要因を抱えており、リライトを視野に入れた取り組みに挑戦しています。
その挑戦の過程において、Chatworkのドメインをモデリングすることに取り組みましてので、どのように実施したのか手順や使ったツール、観点などをご紹介できればと思います

既存システムに対して、大きめの新機能を追加するという割とありがちなプロジェクトでどのようにDDDを導入し、モデリングを進めたのか。
採用したアーキテクチャ、モジュールの切り方、既存システムとの付き合い方などプロジェクトで遭遇するリアルに対してどう対応してモデリングをしたか、そのポイントや考え方を実例を交えて紹介します。

現在、UMLなどで作図できるモデリングツールとして、さまざまな
ツールが利用されています。しかし、ツールベンダーから見ると
「モデリングツール」と、PlantUMLやVisioのような「作図するためのツール」との
区別がなく、どちらも同じような位置づけのツールと考えている人が
少なくないと感じられます。

この背景として、「モデリング」とはどのようなものか、という認識が
人によって異なることがあるように思います。

このセッションでは、「モデリング」には、大きく分けると2種類の位置づけが
あることを、まずお伝えしたいと思います。
そして、「作図ツールとモデリングツールはどのように違うのか」および
「モデリングツールにはどのような価値があるのか」について、
実際のデモを通して伝えたいです。

デモの題材として、UMLおよび、神崎善司氏によるモデルベースの
用件定義手法であるRDRA2.0を利用します。

「作図ツールとは違うのだよ、作図ツールとは！」

「自社サービスの成長に伴いシステムのリニューアルを繰り返してきました。
実装プログラマーの増加、サービス利用ユーザー数増加に伴い都度システムの再設計を行ってきた経験を共有します。
サービスリリース当初、エンジニアは私ひとりでした。
何よりもサービスを早くリリースすることを優先し、後から見返すと共通化できる処理がコピペで複数存在しているとてもカオスなプログラムソースでした。ControllerやModelは肥大化しまくりですが、サービスを止めることはできません。

プロダクトに関わる人が増えるにつれ技術的負債にフタをすることに限界がきます。
サービス利用ユーザー数が1万人を超えたあたりから本格的にリニューアルを行い、システムも再設計しました。
2万人を超えたあたりからノウハウも溜まり、満を持してリリースした新サービスではクリーンアーキテクチャを意識した設計、新しい技術挑戦を行なっています。

時系列形式で考察した過程、経験から得たメリット・デメリットを赤裸々に紹介します。
スタートアップ向け、新規事業開発向けのセッションになります。」

[キーワード]
スタートアップ、新規事業、MVC、ADR、ADM、DDD、クリーンアーキテクチャ、SPA、CakePHP、Laravel、vue.js、Nuxt、aws

• パネリスト
  Chatwork株式会社 加藤 潤一
  株式会社バリューソース 神崎 善司
  弁護士ドットコム株式会社 天重 誠二
  株式会社オージス総研 原田 巌
• モデレータ
  株式会社チェンジビジョン 平鍋 健児

オブジェクト指向の論者をパネリストに迎えて、IPPON グランプリ風にパネリストの考えをお聞きします。ネタではありません！

・なぜオブジェクト指向ってなんだろう？
・UML は生きている？
・オブジェクト指向はGUI か？
・DDDってオブジェクト指向?
・ユビキタス言語の築き方、気を付けていること

などなど、議論したいと思います。

「良い設計」は「良いアプリケーション」をつくるための重要な要素であり，オブジェクト指向はそれを実現するための道具の1つです。
継承，カプセル化，多態性の三大要素を活用して，保守性や再利用性などを高めることに注力します。

しかし，我々が普段扱うOSやミドルウェアの多くは実装にC言語を使用しています。
C言語はオブジェクト指向を実現することを想定した仕組みを持っていません。
それでも，低レイヤのコードにもオブジェクト指向の考え方に基づいた設計と実装が確かに存在します。
これは，「ある機能を実現するための設計が結果としてオブジェクト指向になったもの」と捉えることができます。
このような設計や実装に注目することで，「手段」としてオブジェクト指向を用いる際の本質が見えてくるのではないでしょうか。

本セッションでは，一般に使われているOSSのコードを例に，C言語を用いたオブジェクト指向設計の実装を紹介し，設計の意図やユースケースに合わせた妥協点を探ります。
普段とは少し異なる視点からオブジェクト指向を眺める機会をつくり，低レイヤ領域に興味を持つきっかけになれば幸いです。

※C言語や周辺知識の複雑な部分は都度解説するため，コアな知識は不要です。

【このセッションでお話すること】
・設計と実装，手段と目的の再確認
・C言語でオブジェクト指向を実現する基本戦略
・一般的なOSSの設計と実装の紹介
・まとめ 他の言語に生かすために

昨年から抜本的に組織設計と方針、チームの定義、評価制度、メンバーの権限などを見直し、制度も大体的に再設計した弊社ゆめみの社内構造は、OSS の進め方や
GitHub の運用にインスパイアされています。

社内で行われている「プロリク」、「助言プロセス」をベースにしたチーム設計、「自律」に基づいた働き方や「有給取り放題制度」、メンバーの学習を促進する「勉強し放題制度」など、色んな角度から組織設計・制度を見直し、作ってきました。

今回は世界的にもデファクトスタンダードなオブジェクト指向設計の観点からゆめみという組織を見て分析し、組織設計の考え方の例をお話できればと思います。

Object-Relational-Mappingフレームワークは、文字通りオブジェクト指向プログラミング言語とRDBMSの架け橋となるはずの基本ツールです。しかしその使い方を間違えれば、待っているのは技術的負債との気が遠くなるほど長い戦いです。JVM系言語におけるO/RマッパーのObjectとRelationalの間にあるべき設計思想は？MVCフレームワークとの適切な境界線は？境界線を優しく自動制御する方法は？転職サイトの開発現場から、生の声をお届けします。

DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。
新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、
それはソフトウェアにとっては非常に高い要求をしていることになります。
そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。
このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。

貴方は秘密めいた書籍を拾う、
そのとき、辺り一帯は眩い光りに包まれた。

貴方はオブジェクト概念が無い平行世界に転送されました。
全てのコードにオブジェクトの概念が無いのです、何もかもがコピペされている、そのような世界です。
そんな世界でも最初は何とか生きてこれたが、次第にオブジェクト概念が無いことに苦痛を感じ始めます。
何とかしなきゃ！何とかしなきゃ！
貴方は今まで生きてきたエンジニアの知識を駆使して、このオブジェクトが無い世界に、オブジェクトの概念を広めていこう！

補足:オブジェクトが無い言語が、どうやってオブジェクト構造を構築していくか、それをストーリー仕立てで話していきます。

過去に失敗した代表例から今ならどう設計するか、という観点でお話します。中心になる戦術面のトピックは以下です

• 軽量DDDの功罪
• ドメインモデル貧血症対策
• 集約の境界定義の善し悪し

例外を無視してはいけないと言われるけど、例外処理に何をすればよいのかわからない。

オブジェクト指向プログラミングを始めた頃にこのような疑問を持ったことがある人は多いのではないかと思います。このセッションでは例外の定義・例外処理の原則を振り返ることによって、初心者・初級者が抱く例外処理にまつわる10の疑問に答えていきます。例外処理がよくわからない初級者の方だけでなく、例外処理を雰囲気でやってしまっていたため初学者に質問されてもなんとなく経験と勘でしか答えられない中級・ベテランの方も納得いただける(かもしれない)セッションです。

オブジェクト指向に基づく設計において、メンタルモデルを適切にオブジェクトで表現するために、
オブジェクトの関心や責務を日々意識されているかと思います。

現在私の関わるプロジェクトでは、設計の初期からオブジェクトの責務に対する解像度を上げるため、
要件定義の段階でユースケースを記述する開発プロセスを採用しています。

ユースケースを記述することで、システムが満たすべき振る舞いが明らかになり、オブジェクトの責務に対する理解が深まります。
また、ドメインエキスパートと仕様を議論するツールとしても実用性があります。

対象のオブジェクトが複雑である場合はユースケース記述に加えて、CRCという手法を実施してモデリングをしています。

本発表では、ユースケース記述やCRCを使ったモデリングによるオブジェクト指向の開発プロセスと、
それらを実践している現場のプラクティスをご紹介します。

主なトピック

• ユースケース記述から始める要件定義
• ユースケースを使ったドメインエキスパートとのコミュニケーション
• CRC（クラス、責務、コラボレータ）を使ったモデリング
• DDDに取り入れた事例紹介

オブジェクト指向プログラミングの古典的な教科書として、バートランド・メイヤー氏の『オブジェクト指向入門』があります。
この書籍の『原則・コンセプト』編では、OOPを実践する上で重要な考え方である「契約による設計」について詳細に解説されています。
契約による設計は、現代のプログラミング言語においては「アサーション機能」として実装されています。
ではこのアサーション機能、いったいどのような考えの元で利用すれば、本来の用途に即した効果を発揮するのでしょうか？
簡単に導入できて非常に強力なツールであるアサーションを用いて、信頼性の高いソフトウェアを作る方法をご紹介したいと思います。

1990年代以降オブジェクト指向プログラミングの普及により、クラス設計、インターフェース設計、GoFのデザインパターンなどが提唱され、近年ではMVC系、DDD、Clean Architectureなどのアーキテクチャの議論が盛んに行われています。

これらももちろん大切ですが言語やアーキテクチャに依存せず、多くのプログラマが必ず検討をする設計として「関数分割」が存在しています。
関数分割の基準については、上記のデザインパターンやアーキテクチャでは議論されていません。

関数の実装は世のプログラマの全員が毎日行うことであり、欠かせない設計であると言っても過言ではありません。

しかし「テスタビリティが高い関数にする」のような基準に留まり、明確に言語化されていることが少ないです。

そこで本セッションではこの関数分割の良し悪しを測る指標として提唱されている凝集度と結合度を紹介します。
これらは構造化プログラミングをベースとした近代の多くの言語すべてに適用できる概念です。

本セッションにでは、以下を理解することができます。

• 7つの凝集度と7つの結合度について
• 関数分割の基準
• レビュー時のレビュアーとレビュイーの納得感
• 凝集度、結合度を理解することで、気がつくことができる見過ごされがちな問題
• 新しく提案されたアーキテクチャが、凝集度や結合度の観点で改善されているということ(近年ではReact Hooksが該当します)

また現実の世界では、論理的凝集と時間的凝集が現場で見過ごされて採用されてしまうケースが多いです。関数にフラグを渡して処理を分岐していませんか？
実際に発生するケースとその問題点を詳細に紹介することで、理論だけではなくより具体的に日常の開発で役立てていただければと思います。