OOC 2020 メディアドゥ スポンサーセッション/ooc_2020_mediado

Transcript

1. メディアドゥ スポンサーセッション OOC 2020

2. メディアドゥについて

3. 株式会社 メディアドゥ • 電子書籍の取次事業の シェア No1 • 東証一部上場 ◦ メディアドゥホールディングスが

   東証一部上場企業 • エンジニアは約70名

4. 株式会社 メディアドゥ 最先端のテクノロジーにより 電子書籍の流通事業を推進し、 電子書籍市場、ひいては 出版市場の拡大を目指しています。

5. 5 作 者 電 子 書 店 読 者 情報の集積

   出 版 社 電子書籍の取次事業

6. 自己紹介

7. 濱口賢人 • 2012年 メディアドゥ新卒入社 • 担当業務 ◦ 基幹システムの開発と保守 • 開発チーム(6人程)のリーダー

8. 濱口賢人 • 開発手法 ◦ スクラム ◦ Clean Architecture, DDD •

   技術スタック ◦ C, Java, PHP, Go, Python ◦ クラウド, 主にAWS ◦ オンプレミス運用, 監視など ◦ バックエンド、フロントエンド • 趣味 ◦ システム開発, ギター, ゲーム

9. 濱口賢人 組織・事業の拡大に伴い、 電子書店を運用するための 自社システム(Java, PHP)を AWSとGoを中心に改善中。

10. セッション内容について

11. プロット • オブジェクトの定義をしよう • システムそのものも オブジェクトである • 設計は仮説提唱、 コーディングは証明作業 •

    苦しまない開発を

12. オブジェクトって何？モデル？ • そもそもオブジェクトとは！？ ◦ 振る舞い か ◦ 構成 か ◦

    はたまた hogehoge か • 本セッションでは オブジェクト ≠ プログラム ※アラン・ケイ Smalltalk メッセージに対してどのように振る舞うかが重要

13. オブジェクトを使う目的

14. オブジェクトを使う目的 今回は • 唯一の振る舞いであり、それを支えるための洗練された構成を持つこと ◦ と定義をしてみる • 例えば・・・ ◦ 用途が同じ製品でも、よりユニークで使いやすいものが支持される

    ◦ 用途が同じ製品でも、低コストで広く波及できる製品が残る ◦ etc...

15. 各レイヤーのオブジェクト • 経営観点 • 組織観点 • プロダクト観点 • システム観点 •

    インフラ観点 • ソフトウェア観点 • etc...

16. 各レイヤーのオブジェクト • 経営観点 • 組織観点 • プロダクト観点 • システム観点 •

    インフラ観点 • ソフトウェア観点 • etc... 目的・達成定義が 伝わっているか 目的に合うように 作られているか

17. 各レイヤーのオブジェクト • 経営観点 • 組織観点 • プロダクト観点 • システム観点 •

    インフラ観点 • ソフトウェア観点 • etc... 各種レイヤーで考えられる 目的達成の手段・モデルは それぞれ個別の オブジェクトと考えられる

18. 各レイヤーのオブジェクト • 組織もオブジェクト ◦ メディアドゥという会社は電子書籍の取次事業をするオブジェクト • システムもオブジェクト ◦ 電子書籍の配信システムも一つのオブジェクト ◦

    書店運用のためのシステムも一つのオブジェクト • システムを支えるプログラムもオブジェクト ◦ データ入出力を取り扱うオブジェクト ◦ 操作の入出力を取り扱うオブジェクト ◦ ビジネスロジックを取り扱うオブジェクト

19. 各レイヤーのオブジェクト 経営 組織 プロダクト システム インフラ ソフトウェア より具体的な層の How Toは任せる

    達成に向けたアウトプット 社会への影響

20. オブジェクトを支える

21. オブジェクトを支える • 上位レイヤーのオブジェクトは下位レイヤーのオブジェクトへ仮説を提供 • 下位レイヤーのオブジェクトにより上位レイヤーの仮説を証明

22. オブジェクトを支える 経営 組織 プロダクト システム インフラ ソフトウェア 論理性が破綻していると 作れない・伝わらない 成果物が目的に成り立たず

    破綻する

23. オブジェクトを支える • 仮説 ◦ 目的への達成方法を、論理設計する ▪ ソフトウェア開発は論理的なコンピュータを扱う (勿論、物理の世界も論理である ) ▪

    故に論理的に成り立っているべきである • 証明 ◦ 仮説を結果へ導くように成果物を作成し、実証する ▪ 論理的・数学的に成り立つものであれば、実装できるべきである

24. オブジェクトを支える • 仮説 -> 実証 の流れをアジャイル・スクラムで回していくが・・・ ◦ コーディングに入った途端にわからなくなる ◦ ゴールを見失う

    • 振る舞いはなんとか担保できても、内部構造が破綻してしまう ◦ 継続的な改善ができない ◦ そもそも後から理解できない

25. オブジェクトを支える • トップダウンでゴールや方法を決めてもNG ◦ 内部構造がそれに見合う形になっていなければ、揮発的なプロダクトとして終わる ◦ もしくは続く運用・改善に大きな打撃が訪れる • ボトムアップで成果物ベースで流動的になるのもNG ◦

    今ある成果物が表現できるものは、プロダクトを求めている側が望む一部だけとなりうる ◦ 一度限りの開発で完了するソフトウェアは限られ、改善・拡張はつきもの

26. オブジェクトを支える 人が使うものを、人が作り、人が運用する。 ソフトウェア開発はコンピュータを道具として扱う。 それがどのような恩恵を与えるのかは人が判断する。 提供者にしても利用者にしても、 それぞれが感じた結果がソフトウェアの価値を決定する。

27. 事実に基づく

28. 事実に基づく • 仮説はどの程度の信憑性があるのか ◦ 定量的な数値に基づいているのか ◦ 論理性はあるのか ◦ 事実の一部だけを切り取っていないか

29. 事実に基づく • 仮説はどの程度の信憑性があるのか ◦ 定量的な数値に基づいているのか ◦ 論理性はあるのか ◦ 事実の一部だけを切り取っていないか

30. 事実に基づく • 同じテーマ、同じ言葉を使っていても、全く認識が異なるパターン ◦ DDDのユビキタス言語の策定の際にハードルとなりうる ◦ ヒンドゥー教の象の話 • 組織間・チーム間のコミュニケーションロス ◦

    仮説の認識がずれる ◦ ゴールがずれる ◦ 成果物が正しく作られない ◦ 手戻りが出る ◦ デスマーチが始まる

31. ヒンドゥー教の象の話

32. これは象？

33. これは象？

34. これは象？

35. 確かに象の一部だが、全てが揃ってやっと象

36. 事実に基づく • オブジェクト指向は現実をモデリングして、設計/コードへ・・・ ◦ とよく言われたりするのは、全体を捉えないと一部だけでは成り立たないと取れると言える • 事実に基づいた信憑性のある仮設を立て、合意すること • 実際の成果物による結果に対しても、現実を直視すること オブジェクトの振る舞い・構成が正しさは、

    結果として現実で正しいと証明された時に分かる

37. 事実に基づく オブジェクトが達成するゴールを決めずに コードベース、ソフトウェアベースで発信すると その結果の妥当性がわからないままとなる。 仮設を立てた中から、事実に基づき正しいふるまいのオブジェクトを蒸留する。 蒸留したオブジェクトの構成を最適化する。

38. 反面、直感を大事にする

39. 直感を大事にする • いくら現実に基づいて仮設を立てても、最終的には机上の空論でしかない • 直感を検証なしにこねて、大きい仮説へ持っていくと失敗に繋がる 故に、直感はすぐに検証し、それが事実か確かめること。

40. 直感を大事にする • X であれば、 Y である、という仮説が出た時点で、その単位で実証する ◦ 複合的な条件・結果は結果の要因分析を曇らせる • 真と証明された結果のみを組み合わせて、複合的なオブジェクトへ昇華する

    ◦ 元から複雑なものを作ろうとすると、取り回しが難しく失敗しやすくなる

41. ここまでの話を開発に落とし込む

42. 開発への落とし込み • オブジェクトを使う目的 ◦ 個人にしても組織にしても、社会に対して何を提供し恩恵を出すのかが源泉 ◦ 最終的には人が価値を判断する、そのレベルにオブジェクトのバランスが保たれるべき ▪ 関心事の分離、ドメイン、コンテキスト •

    オブジェクトを支える ◦ オブジェクトが期待される振る舞いを続けられる構造を保つ ◦ ゴールに沿った論理設計を行い、コードはそれを素直に表現できること ▪ ソフトウェアアーキテクチャや実装パターンが役立つ

43. 開発への落とし込み • 事実に基づく ◦ 有益なコードのみを残し、不要なコードは排除する ▪ 継続的なリファクタリングとテスト ◦ コンポーネントは小さく保つ ▪

    参照透過性、パッケージ粒度 (凝集度)

44. 開発への落とし込み 組織やソフトウェア(広義には”物作り”)は課題解決のために作られる。 課題は大抵複雑であり、小さく作られても時を経て肥大化しがち。 常にシンプルに保つには、組織ゴールから設計への落とし込みが徹底的に必要。 論理性があり、実現可能性が見えている状態から、コードを書き始めるべき。 しかし、直感からコードベースで細かく実証実験することを怠らない。

45. 開発への落とし込み 開発者は常に、いかなる設計・コードが正しいかを迷う。 その答えは本でもレビューでもなく、実際に使われることが近道かもしれない。 クラスの定義や、インターフェース・継承で詰まったら、 上位レイヤーのオブジェクトのことを考えてみると、納得できるかもしれない。

46. オブジェクト指向で 豊かなシステムを創ろう！

47. メディアドゥの紹介

48. MISSION 著作物の健全なる創造サイクルの実現 VISION ひとつでも多くのコンテンツを、ひとりでも多くの人へ

49. 情報発信 Twitter https://twitter.com/mediado_dev エンジニアブログ https://techdo.mediado.jp/

50. We’re Hiring ! • Engineer • Engineering Manager • Product

    Owner https://www.mediado.jp/mediado/recruit/
51. None