トーク

複雑なシステムの設計を行う際には、そのシステムを様々な観点（ビュー）を通して観ることで、そのシステムを構成するコンポーネントを把握することが重要です。それらの各コンポーネントがどのような責務を担い、周囲のコンポーネントとの間でどのような相互作用を期待するかを整理することが堅牢なシステムの実現に繋がります。コンポーネントが責務を持ちそれらの相互作用で大きな価値を提供する構造は、まさにオブジェクト指向の世界観と重なります。

本セッションでは、Webアプリケーションを１つのシステムとみなして、それを構成する複数のコンポーネントをどのように分割し、どのような関係性に整理するのがよいか考える過程をお話する予定です。具体的にはアプリケーションを支える基盤的な横断的関心事を題材に、モデリングを通じて責務を整理していく予定です。

本セッションを通じて、オブジェクト指向をプログラミング以外の場面でも活用できるイメージを持ち帰って頂けると嬉しいです。

オブジェクト指向の分析手順から導き出した、勘と経験に頼らないデータベース設計の手法を紹介します。リレーショナルデータベースを使う場合、テーブルやフィールドとその関連づけなど、スキーマを構築しなければなりません。ある程度経験があって反射的に設計ができる方々もたくさんいらっしゃいますが、その一方で問題のあるスキーマで構築してしまうような事例も時折見られます。要求をそのままスキーマにしてしまったり、求められるがままに設計をしてしまったりして、後からうまくできないことが見つかってしまったという経験を持つ方も多いと思います。レイヤーアーキテクチャの原則だと、最下層に相当する部分の設計がスキーマであり、そこは安定していて変化がないことを前提としています。しかし、どうしてもうまく動かないとなると、スキーマの変更と上位レイヤーの調整という大変な作業になってしまうような改変をしなければなりません。そこでそうならないように、システム構築の最初にきちんとスキーマを作りましょうということになるのですが、その「きちんと」行う方法は、オブジェクト指向の方法論を応用できます。課題をオブジェクト指向分析法で分析をし、そこからスキーマを定義する方法を紹介します。何がフィールドになるのかという基準や、なぜ中間テーブルが必要になるのかということの説明を試みます。言い換えれば、データベースのスキーマを作る前提でのオブジェクト指向分析法です。「常識」や「慣習」といった不確かな基準でなく、スキーマの1つ1つを定義する理由を考え、納得の行く設計をしたいと考えている皆さんには、ヒントになる手法でしょう。データベース設計にこれから取り組む方や、一歩踏み込んだスキーマを目指す方に、聞いていただきたい内容です。

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

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

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

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

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

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

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

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

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

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

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

オブジェクト指向の設計において「関心の分離」「責務」が重要と語られている。さらに昔からモジュール設計においては「凝集度」と「結合度」が大事だと言われてきた。一方エリックエバンスの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フロントエンドアーキテクチャ考察

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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