トーク

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

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

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

SwiftやC#を始め、最近の多くのオブジェクト指向言語を支えているclassとstruct。彼らは同じように抽象化に使え、同じようにプロパティーやメソッドの定義ができます。そんな同じような機能を持つclassとstruct、実際コードを書く時どっちを選ぶべきか？

このトークはSwiftを用いて、classとstructの根本的な違いである「参照型」か「値型」かを切り口に、classとstructの使いわけを話していきます。

※このトークは基本的にSwiftの話をしますが、Swiftと同じようなclassとstructを持つ言語にも通用する…はずです。

オブジェクト指向（以下OOP）は偉大です。我々はクラスの継承を使って共通の処理を切り出し、コードの再利用性を高め、しかも人間がより読みやすい抽象度の高いプログラムが書けるようになりました。

しかし同時にOOPは問題点もあります。親を継承した子供は親について把握せずにメソッドをオーバーライドするのはバグの温床にもなるし、そして何も考えずにとりあえず共通しそうな処理を親に詰め込むと気がつけばゴッドクラスを生み出してしまいがちです。

これらの問題点を解決すべく、Objective-Cに代わるアップルの新しい公式開発言語Swiftに、今までのOOPが残されつつも、アップルは新たに「プロトコル指向（以下POP）」という概念を導入しました。クラスを継承するOOPとは違い、POPはありとあらゆる型がプロトコルに適合するアプローチをとることによって、共通処理のコード再利用と、継承による暗黙な動作共有の解消を両立させました。

では、POPは一体どのようなものですか？POPのProtocolはこれまでのProtocolや他言語のInterfaceとは何が違うのか？POPは一体我々にどんな恩恵をもたらすのか？POPは銀の弾丸になるのか？

このトークは、これまでのOOPやObjective-Cの歴史を振り返りながら、SwiftのPOPについての技術的な話と、ちょっとエモい話をしていきます。

今回、（12月時点の）現在進行系で開発が進んでいる案件でLaravelを採用し、
更にドメイン駆動設計の概念を埋め込むような開発手法を取り込んでいます。

しかし「オブジェクト指向」という名前は知っているが内容までは知らず、
かつ古き時代のPHPと現行のPHP7.xの理解が混ざる混沌の中、治水するために奔走した話です。

【概要】

1. PHPとオブジェクト指向：オブジェクト指向の認識を定める
2. ドメイン駆動設計：ドメイン領域を伝え広める（途中経過）
3. ドメイン駆動設計：インフラストラクチャー層、どこまで裁定するか
4. ドメイン駆動設計：形（画面）から入るのを止めさせたかった（失敗談）
5. まとめ：治水、結果は……？

プロダクトのオブジェクト指向が曖昧だったり、
チーム内でドメイン駆動設計を広めようと奮迅されている方への一つの指針としてお伝えできればと存じます。

※若干PHPに傾きよりですが、主題から逸れない内容になっています。

JavaScriptやGo、PHP、Rubyなど、毛色の違う様々な言語でオブジェクト指向と闘ってきました。

そんな中、最近ではTypeScriptを使い、関数型の考え方でプログラミングをしています。いわゆるclassを使うことは(ほとんど)なくなり、純粋関数を組み合わせて、宣言的にコードを書いています。では、オブジェクト指向を忘れてしまったのか？いえ、そうではありません。関数型であるからこそ、オブジェクト指向のエッセンスが随所ににじみ出る、そのような思いをひしひしと感じています。

オブジェクト指向の真髄は、「コンポーネント化」であり、小さいまとまりでソフトウェアをつくりあげることです。関数型であることとオブジェクト指向で書くことは矛盾しません。昔ながらのコアな設計を柱としながら、開発効率の高い関数型で開発する。そのあたりを、他の言語などと比較しつつ、詳しく話したいと考えています。

OOPの良さは書籍からの情報収集だけではなかなか分かりません。
弊社が過去にオブジェクト指向設計の読書会を実施したところ「現実のプロダクトのどこにどう当てはめればいいのか分からない」といった感想が挙げられました。

そこで一部の有志で「理論と実践をつなげる」という目的を掲げて、読書よりも実践とディスカッションを重視した勉強会を開始しました。
Robert C. Martinの書籍で扱われている給与システムの例を題材に、OOPの知識を活用しながら、実際に動くシステムをモブプログラミングで作り上げています。
またOOPだけでは語ることのできない現実のシステム開発を、CleanArchitecture・DDDなどの知識を駆使し、参加者それぞれの学習のサイクルを回すようにしながら進めています。

今回の発表では読書会・実践による勉強会それぞれを経験した立場から、弊社流のOOPに対する学習アプローチについて皆様が持ち帰れるようになるべく一般化して発表させていただこうと思っております。

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

10年前 iPhone が誕生し, スマートフォンの時代になった今, 我々が望むものは, 実はモバイルアプリではないでしょうか？

現代のフロントエンド, もっと言うと JavaScript の開発では, コンポーネント指向による開発がほぼデファクトスタンダードになりました. それは, Facebook 社が生み出した JavaScript フレームワーク「React」の誕生を皮切りに, 一気に全世界的にコンポーネント指向が普及し, 現在に至ったと思っています. web ページの各要素・パーツをコンポーネントという単位に区切り, そこで JS や CSS のスコープを閉じることで, 再利用性も高めつつ責務を分ける, そして開発者は各コンポーネントを配置していく作業にシフトしていきました.

一方でモバイルアプリの開発を見ると, やることは大きく以下の２つだと思います.

・buttonなどのパーツの配置　※スタイリングも含む
・イベントハンドラの設定

これは今我々フロントエンドエンジニアがやっている開発と, 酷似していると思いませんか？また, web の大きな流れとして, はじめは web だったのが, モバイルが誕生しモバイルファースト（レスポンシブ対応も含む）と言われる時代になり, それにより PWA や AMP という技術も産まれました.

このことから, web の進化はモバイルアプリの開発に寄っていると思えます. これ以外にも, パフォーマンス改善・UXUI の設計・アクセシビリティ・push 通知など色んな要素を考えないといけませんが, それはモバイルアプリケーション開発でも同様です.

以上を加味し, 一度 JavaScript フレームワークの歴史を振り返りつつ, 今後のフロントエンドの設計や開発に思いを語ってみたいと思います.

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

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

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

発表概要（予定）
・現代のWebフロントエンド模様
・Webフロントエンドの責務分担考察
・Webフロントエンドアーキテクチャ考察

※ロングセッションの短縮版を予定しています。

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

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

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

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

昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。

オブジェクトとは一体何でしょうか？

モデリングパラダイムとしてはオブジェクトの他にもデータモデルの設計によく使われるERモデルやリレーショナルモデル、または関数型言語のベースになっているラムダ計算などがあります。

それぞれのモデリングパラダイムには得意な表現/苦手な表現があり、本来は解決したい問題領域によってそれらを選択することが好ましいのですが、実際には多くの開発者が、クラスや関数、RDBのテーブルなどといった具体実装や言語機能/ミドルウェア機能に着目しやすく、モデルそのものの表現力について議論されることが少ないように感じています。

温故知新と言われるように、進化し続ける現代のソフトウェア技術の中にいる我々にとっても古くからあるこれらのモデリングパラダイムやそれを切り開いてきた先人たちの思想は学ぶ価値のあるものであり、その上でハードウェアが進化した現代においてそれらのモデルをどのように活用していくかが我々に求められている課題だと考えています。

本発表では、先人たちの思想をなぞりながら、オブジェクトが目指したものは何だったのか今一度再考し、その他のモデリングパラダイムとの共通点・相違点について述べていきます。また、異なるモデリングパラダイムの間に生じてしまうインピーダンスミスマッチをどのように最小化していくかについても一緒に考えていきたいと思います。

以下のような先人たちの名前にピンと来る人はぜひ聞きに来てください。（注: とりあげる人物は予告なく変更になる可能性があります）
アラン・ケイ、ストラウストラップ、バートランド・メイヤー、エドガー・F・コッド、クリス・デイト、ピーター・チェン
※ また、上述したようなモデリングパラダイムの直接の提唱者ではありませんが、ジェームス・コプリエンやリッチ・ヒッキーらの考えについてもとりあげます。

近年AltJS界隈で興隆を見せる関数型プログラミング言語であるElm。このトークでは、弊社で7万行の規模で採用されているElmのシンプルかつ必要十分な型システムが、いかにしてフロントエンドのビジネスルールを型で守り、そして型で表現しているかをご紹介いたします。単なる型アノテーションではない、真の静的型付言語がフロントエンドというドメインでどのように価値を発揮するかをご理解いただける内容です。

サーバーサイドと比較して、どのような観点から型レベルでドメインや状態網羅を守る必要があるのか。フロントエンドのドメインをどのように考え、どのように型で表現するべきか、などのトピックを簡単なコードとともにご紹介いたします。

※トークの内容はElmの文法知識などについての言及を少なめにし、Elmを知らない方でもご理解いただける内容にする予定です。

今やテストのないプロダクトは大きなリスクを抱えて当然な世情であり、
テストを整備しながら開発を進めることは普通に意識してなければならないと思います。
開発速度をなるべく落とすことなくこれを推進するには工夫が間違いなく必要ではないでしょうか。

自分が現在所属している開発プロジェクトでの実装過程で、UnitTestの量産を支援する、
かつテストデータのコードによる整備を必要最小限に抑えるちょっとした仕組みを編み出しました。

オブジェクト指向プログラミングの特徴の１つである継承を大いに利用したこの仕組みについて、
ご紹介させていただければと思います。

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

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

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

趣旨：
なんとなくオブジェクト指向を使ってて、結局オブジェクトって何なんだ？と思う事はありませんか
という人向けのセッションです
20年程前に、僕がオブジェクトを体得した経験を基にお話します

内容：
3つのパートに分けてお話します
1) オブジェクトって何なのか？
2) オブジェクトとクラスとインスタンスの違い
3) こうすればオブジェクト指向になる、スモールステップ

継承や多態性等については、触れるかもしれませんが深堀はしません

詳細：
自作スライド資料を使って話していく

1) オブジェクトって何なのか？
・「オブジェクト＝物」
・オブジェクト指向は現実（リアル）を表現するための考え方
の辺りの基本的な話を中心に、プログラム初学者時代の僕が、オブジェクトをどう捉えたか、オブジェクトを使ってプログラムでどう幸せになったか、を話す

2) オブジェクトとクラスとインスタンスの違い
オブジェクト、クラス、インスタンスという言葉は良く出てくるが、違いを分かっていない人は多いらしい
僕自身も感覚で分けていた時期がある
この違いを大判焼きを例に挙げてしっかりと伝える

3) こうすればオブジェクト指向になる、スモールステップ
7つのルールはちょっとまだハードルが高い
・フィールド
・getter/setter or プロパティ
・メソッド
・イベント
これらの要素を変数や関数との違いについて説明する
脱Staticオジサン！！

最後に、僕がオブジェクト指向の勉強に役立ったと感じたC/C++の書籍の紹介と、継承や多態性、DDD等の先の世界がある事を紹介して締めたい

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

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

フロントエンドで各タイミングで抱える課題をいくつかリストアップし、項目毎に効果的であろうアプローチを現代エコシステムと合わせて駆け足で紹介しようと思います。

リミア株式会社でLIMIAというメディアサービスを開発しています。
サービス開始前、ドメイン設計して、PHPでJavaのように何でもオブジェクトとして実装しました。
すると、レスポンスタイムが30秒程度かかりました。
原因を調べると、オブジェクトの生成に大半の時間がかかっていることが分かりました。

本発表では、初めに上記事例を使って問題定義します。
次に各プログラミング言語におけるオブジェクトの生成コストを比較します。
最後に解決した事例を説明します。

PHPは学習コストが低いため採用が容易で、標準機能が豊富なため開発速度が速いという特徴があります。
しかし、想定外の動きをすることがあります。
この事例を発表することにより、適切な開発言語選択するための情報を提供します。
それでもPHPが好きなんだぁぁぁ！

Mathematicaは、項書き換え型言語と呼ばれますが、オブジェクト指向言語であるとはされていません。しかし、実は、基本的な関数の組み合わせだけで、一切のスクリプトを用いることなく、OOPを実現することができます。その核心部分がMathematicaで記述された関数の二重呼び出しです。
実現されたクラスそして内部に置かれるメソッドは関数型で表現されるゆえに、コンストラクションはクラス関数の呼び出しとして表され、結果としてインスタンスも関数型で表現されます。
関数型として表現されるゆえに、コンストラクションには連想配列（辞書型）を極めて容易に導入でき、メモリの許す限りの多数の初期化されたインスタンスを生成することができます。
このトークで、たとえMathematicaを知らなくとも、OOPがどのように構成されているかを知ることができます。なぜならば、Mathematicaの関数によりOOPを構成していく過程を見ることで、クラスとメソッドはどのような関係にあるかを知り、どうしてカプセル化が実現されるのかを知り、クラス関数の実行でコンストラクションとインスタンスの関係を知り、複数のクラスの関係から継承とは何かを知り、関数呼び出しの形式からポリモルフィズムを知ることができるからです。ラムダ計算を通じて、クロージャがOOPに包含される様子も目にすることができるでしょう。
そして、OOP環境が関数型として表現されるゆえに、強力なMathematicaのソルバーやグラフィックスと容易に組み合わせることができて、さらには、インスタンスをマルチコアにデプロイすることで並列計算への扉が開かれることを、実例でお示ししましょう。