トーク

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

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

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

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

オブジェクト指向の設計において「関心の分離」「責務」が重要と語られている。さらに昔からモジュール設計においては「凝集度」と「結合度」が大事だと言われてきた。一方エリックエバンスのDDDでは、ユビキタス言語としてのドメインモデルを使って、ドメインエキスパートとコミュニケーションを図ることが大事だとしいる。つまり、「関心の分離」は要件から仕様化・設計・実装・テスト、さらにアーキテクチャ構築までの一連の活動に関わっている。
今回は「関心とは何か？」「責務との違いは？」など「分ける」ことについて、オブジェクト指向と関数型のマルチパラダイムの視点を加味して、簡単な思考実験を行いながら、物事の捉え方を体感します。
さあ、この無謀とも思える思考実験。「吉」と出るか「凶」と出るか。
モデルベースの用件定義手法であるRDRAをまとめていく時に使った「境界を引く」考え方を説明しながらトライします。

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

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

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

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

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

GoF（Gang of Four）のデザインパターンは、我々が日々行う設計行為において基礎的な要素を占めています。ですが、一方で「デザインパターンをなんとなく知っている」状態から「デザインパターンを正しく使う」状態へ向かうには、大きな壁があると感じています。
その壁をどうよじ登れるかを考える上で、デザインパターンが何に影響を受けたのかを理解することは大きなヒントになるはずです。それは、建築家アレグザンダーの「パタン・ランゲージ」という概念です。「パタン・ランゲージは何を解決しようとしたのか」・「デザインパターンとパタン・ランゲージの差異は何か」といった点を理解することで、デザインパターンのより深い理解に繋がります。
そこから、デザインパターンにおいて「理解すればいい点」と「実践値から磨くべき点」がそれぞれどこなのかを抑える、使い方の言語化を試みます。

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

「オブジェクト指向など知ったこっちゃない」と言わんばかりに、何も設計せずただただswitch文を書き連ねて行った先の地獄を、実体験を踏まえ、面白おかしく皮肉った動画です。
(参考：クソコード動画「共通化の罠」 https://twitter.com/minodriven/status/1127539251761909760 )

動画の中で何がマズかったのか、設計やチームワーク等の観点で解説致します。
そしてこの動画を他山の石として、実際のチーム開発での活用ポイントについても説明します。

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

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

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

ビジネスとしても技術としても合意できる、ビジネス対して十分な拡張性を持ったシステムアーキテクチャがほしい。
これを実現するために設計手法をつくってみました。数理的システム設計と呼んでいます。
自分が作りやすい、自分がマネジメントしやすい「やりやすい設計」を避けるための手法となります。
これは既存手法とは異なり、システムレベルでのよい設計をめざすものです。

この実現のために、パタンランゲージの始祖であるクリストファーアレグザンダー氏の理論をソフトウェアシステム設計に取り入れました。
まずシステムレベルでの分析と設計においては、15の幾何学的特性(美しい設計の根源には15の幾何学的な特性があるとアレグザンダーがみいだしたもの)を活用します。
全体性を重んじ、全体と部分をいったりきたりしながら、設計をすすめていきます。そして、その後にパタンランゲージを適用していきます。

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

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

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

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

オブジェクト指向の設計・実装方法を利用してフロントエンドを開発する方法を考えます。

Webフロントエンドの「設計」について、多くの場合はUIやコンポーネントといった「画面設計」の方法が語られます。一方、画面の背後に潜む条件や状態といった複雑さをどのように取り扱うかという問題は、それら「画面設計」の方法論にとっては関心の外にあり、これといった解答は与えてくれません。
現代のWebフロントエンドは「表示して終わり」といえるほど単純ではなく、そのアプリケーションとしての複雑さの解決には、「画面設計」とは別の方法が必要です。

この発表では、Webフロントエンドの画面よりも、その背後にあるアプリケーションとその複雑さに注目します。
Webフロントエンドが画面の後ろに抱える複雑さを解決するための方法として、いわゆる「オブジェクト指向設計」が変わらず有効であること、そしてそうした方法論の必要性について、考察した内容をお話します。

発表概要
・現代のWebフロントエンドの難しさ
・Webフロントエンドと「ドメイン」
・Webフロントエンドを「設計」することについて
・Webフロントエンドアーキテクチャ考察

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

オブジェクト指向を操るとき、私たちは当然のように新しい世界を構築しています。

「鳥（オブジェクト）」が「飛ぶ（メソッド）」

この簡単な例からも色々考えることができます。
・鳥オブジェクトを継承したツバメ・スズメも飛べるのか
・それだと同じく継承したペンギン・ダチョウも飛べてしまうのか
・ペンギンは飛ぶではなく水中では泳ぐなのか
・宇宙空間でも飛ぶといえるのか

しかし、
「鳥が飛ぶ」が成り立つと世界では余計な考えが不要となります。
ペンギン・ダチョウは存在せず、水中・宇宙空間でも無いのです。

つまり、オブジェクト指向は“現実の単語”を足掛りに、現実とは異なる世界を構築していると言えます。
私たちはこの行為を「モデリング」と呼んでいます。

「鳥が飛ぶ」とひとつ語るだけでモデリングされた世界の多数の一面を示すことができます。
では普段モデリングされた世界を私たちはどうやって、語ることによって示しているのでしょうか。
そして、どこまでが語りうることの限界なのか、示せれる限界はどこにあるのか。
時間が許す限り「語る」と「示す」の気づきを発表したいと思います。

【概要】
本セッションでは、Go本体のソースコードを紹介しながら、オブジェクト指向プログラミングを解説します。

【背景】
いまやメジャー言語の仲間入りを果たしたGo言語。Go自体のソースコードはGitHubに公開されており、Russ Coxをはじめとする超一流のプログラマが実装に携わっています。そんなGoは構文自体がC言語に近いため、いわゆるオブジェクト指向とは一線を画すと思われがちです。しかし、ソースコードの随所にはオブジェクト指向のプラクティスが幾つか散りばめられています。「Goらしさ」と「オブジェクト指向」が共存したプログラミングの一例をご紹介します。

【こんな方におすすめ】
・ソースコードを見ながらオブジェクト指向を理解したい
・実用（言語処理系）の実装においてオブジェクト指向の使用例を知りたい
※ Goが未経験の方でも解説しながら進行するため、問題ありません

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

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

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

モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングの手法を提案します。
アジャイル開発では、動くコード（そして自動化テスト）が重要な成果物として扱われます。では、設計はどこに行ったのでしょう？モデリングはもういらない？UMLは死んだ？ぼくはそう思いません。

"The code is the truth, but it is not the whole truth." -- Grady Booch

このセッションでは、アジャイル時代に相応しいモデリングの役割について探ってみたいと思います。合わせて、海外で話題の軽量モデリング手法、 C4 Model の概要もお話します。

オブジェクト指向は現代のシステム開発においてスタンダードな方法論の一つですが、「オブジェクト指向とはなんですか？」と問われると明確に答えられる方はわずかではないでしょうか？
理由は「オブジェクト指向」が指す意味が広すぎるからです。
正解がいくつもあるゆえに正解が見つからない、といった状態だと思います。

本セッションでは「概念投影指向」というものを提案したいと思います。
いわゆるオブジェクト指向（の一つ）ですがあえて別名称で紹介します。

システムは人間の代わりに処理等引き受けてくれるものです。
ですが、システムは人間の事を知りません。セマンティックギャップが常に存在します。
システムに人間の事を知ってもらう為に我々プログラマー存在すると言えるでしょう。

その為には、まず我々プログラマーが人間の事を知る必要がありそうです。

例えば、目の前にフレームがついた2枚組のガラスがあったとします。
ほとんどの人はこれを「メガネ」だと認識するでしょう。
でも、例えば今日初めて地球にきた人はそれをメガネとは思いません。
それはなぜでしょうか？
答えは簡単で我々人間がメガネという「概念」を知っているからです。
つまり、存在の前提には概念理解という暗黙の大前提があります。

システムも同じです。メガネ、ユーザーの名前、予約情報、全てオブジェクトとして存在させるには、まずは人間界にある「概念」を知ってもらう（投影する）必要があります。
概念投影指向とはこのような考え方に基づきます。

セッションにて概念投影指向とは何か？そのメリットは？具体的には？（PHPでのサンプルコードとなる予定です）といった部分にフォーカスをあて、あいまいだったオブジェクト指向設計の中でも明確な設計方針を示す事が狙いとなります。