Tweet
Tweet

Slide 1

Slide 1 text

1 技育祭2022 ソフトウェアアーキテクトって何やるの？ ～知っておくと役立つ考え方を共有します～ #公開用

Slide 2

Slide 2 text

Copyrigh © 2022 by Future Corporation About Me

Slide 3

Slide 3 text

Copyrigh © 2022 by Future Corporation 自己紹介 󰢧 真野隼記
 🤖 アーキテクト歴13年くらい
 🏢 フューチャー株式会社
 🚲 フィットネスサイクル漕いでます
 🏃オープン活動 実用Go言語（同僚と共著）
 フューチャー技術ブログ運営
 会社Connpass勉強会主催
 💡 お仕事 製造業、エネルギー業界、IoT全般
 キャリアの最初は共通ライブラリ、ミドルウェ ア、フレームワーク開発


Slide 4

Slide 4 text

Copyrigh © 2022 by Future Corporation Output 一番、長くやっている運営が会社技術ブログで、自らも寄稿しています 会社リポジトリ系に関わったOSSツール＋プロダクトを公開中！ AWSパートナーサミット

Slide 5

Slide 5 text

Copyrigh © 2022 by Future Corporation フューチャーについて #無いものは作る #あるなら一番良いものを使う

Slide 6

Slide 6 text

Copyrigh © 2022 by Future Corporation ソフトウェアアーキテクトって 何やるの？ ～知っておくと役立つ考え方を共有します～

Slide 7

Slide 7 text

Copyrigh © 2022 by Future Corporation アーキテクト、アーキテクチャって 何ってところから話します

Slide 8

Slide 8 text

Copyrigh © 2022 by Future Corporation おそらく、今日視聴している方の多くは、 SWエンジニアか近い仕事を考えている方 が少なくないんじゃないかと思います

Slide 9

Slide 9 text

Copyrigh © 2022 by Future Corporation アーキテクトは色々IT技術以外にも知る べきことが多く難しいです。（名乗ることはできますが） 一度チームでの開発経験と、リリースま でのライフサイクルを経験してから目指 すものかもしれません

Slide 10

Slide 10 text

Copyrigh © 2022 by Future Corporation 最初から少し先の未来に視点を向けること で、今の過ごし方が変わってくることも。 どういう視点で考えているか 知っておくとプラスだと思っています 今 アーキテクトの視点 研究者 リードエンジニア ちょっとでも、将来像の選択肢に 加えられたら、今の過ごし方も変わる

Slide 11

Slide 11 text

Copyrigh © 2022 by Future Corporation こう感じるのは、最近1~8年目の同僚か ら、よく次のことを聞かれたため

Slide 12

Slide 12 text

Copyrigh © 2022 by Future Corporation 「1からアーキテクチャを作ったことが無い ことにキャリア的な壁を感じる」 「何ができればアーキテクトロールができます と言えるのか分からない」 「アーキテクチャ設計する機会が今の 　タスクでは存在しない」

Slide 13

Slide 13 text

Copyrigh © 2022 by Future Corporation これらに答えるとともに、 そもそもアーキテクチャとは何かと いうところについて説明します ※アーキテクチャの幅は広いですが、対象は 　Webアプリケーションに絞らせてください

Slide 14

Slide 14 text

Copyrigh © 2022 by Future Corporation What is Architecture

Slide 15

Slide 15 text

Copyrigh © 2022 by Future Corporation アーキテクチャとは 多くの書籍、ネットで様々な説明がなされる ● 「あえて定義しない」 ● 「望まれる品質特性・その他性質を促進するためどういう構成するか、 "設計判断" の集合」 ● 「トレードオフのゲーム」 ● 「エンジニアリングの観点から問題を定義、システムを実装可能な塊に分解する」

Slide 16

Slide 16 text

Copyrigh © 2022 by Future Corporation アーキテクチャとは 多くの書籍、ネットで様々な説明がなされる ● 「あえて定義しない」 ● 「望まれる品質特性・その他性質を促進するためどういう構成するか、 "設計判断" の集合」 ● 「トレードオフのゲーム」 ● 「エンジニアリングの観点から問題を定義、システムを実装可能な塊に分解する」 「アプリ構成・開発方針・スタイルなどシステム全体へ影響度が大きな設計上の意思決定」 「複数の選択肢を取りうる中でトレードオフのバランスで選ばれるもの」 「その選択で、既存ないし今後のアプリ構成に影響を与えるもの」 本紙では次のようなものを想定しています

Slide 17

Slide 17 text

Copyrigh © 2022 by Future Corporation カジュアルに言うアーキテクチャ ● めっちゃ重要な設計判断 ● うまく設計できれば開発・テスト・リリースしや すく品質も上がる ● 間違えると手戻りが大きく、致命的 ● とはいえ、全ての判断はトレードオフなので、正 解・間違えのどちらになるかは状況による

Slide 18

Slide 18 text

Copyrigh © 2022 by Future Corporation 開発立ち上げ時の大きそうなものの例をあげます ● サービスカット、機能配置 ● それぞれの依存関係、責務分け ● Push, Pull, イベント駆動, バッチ駆動, それぞれのリカバリポイント ● 同期、非同期のポイント ● 素直なデータモデルででてくる懸念とその対応方針 ● データ種別、連携先が増えてきたときの対応方針 ● 利用するAWSサービス、DB選定 ● 開発規約、パッケージ構成、言語、フレームワーク ● いつまでに何を設計、開発するかから逆算した準備物 どれも開発中盤以降での変更は致命的 どういったことが重要な設計判断なのか

Slide 19

Slide 19 text

Copyrigh © 2022 by Future Corporation 研究におけるアーキテクチャ？ ● 学習データ・モデル・評価結果をどのように管理するか ○ どのツールを使うか。後で変えると大変なもの ○ 正直、1人しか使わず後で変えても何とかなるならあ まり考えなくても良い ● 研究本筋より、自動化側の方が近いかも ○ 研究資材の物品管理とか

Slide 20

Slide 20 text

Copyrigh © 2022 by Future Corporation 今の生活では、 アーキテクチャをイチから 設計 する機会がないな.. と思った方も多いのでは？

Slide 21

Slide 21 text

Copyrigh © 2022 by Future Corporation アーキテクチャ設計判断に大小は関係ない ● チームでのプロダクト開発以外にもアーキテクチャ設計するポイン トは常にある ● イチからで無くても、全てのアーキテクチャの設計フローは類似し ている（例え、大きいものであってもちいさいものでもやるべきこ とは同じである） ● 小さいものと思っても、むしろイチから考えるものより重要かつ、 難しいケースがある と思っています

Slide 22

Slide 22 text

Copyrigh © 2022 by Future Corporation 【Exercise1】 例で学ぶアーキテク ティングの流れ

Slide 23

Slide 23 text

Copyrigh © 2022 by Future Corporation 普段の開発でアーキテクチャを意識すること できること 例としてよくあるIoTデバイスから収集したデータを、監視・可視化し、異常時の判定 や自動化のためのシステムがあるとする 1. 初期からPJに参画していない開発者 2. システムの1stリリースは終わったが、まだまだやりたいことは色々ある状態。 追加の要望もちょいちょいくる 3. チームで採用している技術要素にもある程度、慣れてきている アーキテクチャを意識するステージにありそうな開発者の想定レベル

Slide 24

Slide 24 text

Copyrigh © 2022 by Future Corporation 普段の開発でアーキテクチャを意識すること できること 要求事項 ● 新製品の登場でIoT系のシステムで連携するデバイス種が増えることが決まった ● 概ね同じ機能を有し、データ種別も大体は似ているが、微妙に異なるのでそのままでは 取り込めない ● どのように機能拡張を行うべきか 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 NEW！ ※そのままでは動かない 🚨 notifiy

Slide 25

Slide 25 text

Copyrigh © 2022 by Future Corporation 普段の開発でアーキテクチャを意識すること できること 対応案１ ● ナイーブな対応案では、streamと呼ばれるコードに分岐を入れる ● if 分を追加してテストして終了。簡単である 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 NEW！ ↑ここに分岐を入れる 🚨 notifiy

Slide 26

Slide 26 text

Copyrigh © 2022 by Future Corporation めでたしめでたし？ ● 本当にこれでいくのか一歩踏みとどまって考える ● 懸念がないのか、机上でシミュレーションする ● シミュレーションとはいくつかのシナリオが発生するときにどうするか 自問自答すること 1. もともとの設計ポリシーとして、データ種別追加が考慮されていたか 　　　・その方針に則った対応になっているか 2. 今後もデバイスが増えることは予想されるが、同様に if分岐で対応可能か 3. リソースを相乗りすることによる懸念がないか 4. 性能的に問題がないか 5. 障害切り分けやトレース時に困らないか？ 自問自答例

Slide 27

Slide 27 text

Copyrigh © 2022 by Future Corporation ある案を採用したとして 懸念がないか整理・観察・分析する 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 NEW 修正予定 🚨 リカバリ用に バックアップをとっていた スキーマが異なるため トピック階層が異なる トピックごとに キューのマッピングを 管理したくない 処理のフックがあるなど 少し複雑である 🔥着火条件あり 例えば、整理していくと、「データスキーマが異なるのでMQTTのトピック の階層は分けたい」や「キューのバックアップもスキーマ単位が望ましい」 という意見がでたとする notifiy

Slide 28

Slide 28 text

Copyrigh © 2022 by Future Corporation もし考慮事項がでてきた場合 ● 最もシンプルであるナイーブな改修で懸念があるということは、 トレードオフを考慮し設計判断を下す必要がある 具体的には.. ● 複数案を出して観点ごとに比較すること

Slide 29

Slide 29 text

Copyrigh © 2022 by Future Corporation 設計案を洗い出す とりうる案は、できる限り全て洗い出すことから始めます 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 🚨 案１： スキーマが異なっても、MQTTトピックを同一階層にしてもらう 　　　元のナイーブな改修案を成立させるための前提 修正予定 notifiy

Slide 30

Slide 30 text

Copyrigh © 2022 by Future Corporation 設計案を洗い出す 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 🚨 MQTT bridge 修正予定 notifiy 案2: MQTTトピックは分け、Streamで分岐 追加

Slide 31

Slide 31 text

Copyrigh © 2022 by Future Corporation 設計案を洗い出す 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 🚨 MQTT bridge 修正予定 キュー notifiy 追加 案3: キューイングまで分離

Slide 32

Slide 32 text

Copyrigh © 2022 by Future Corporation 設計案を洗い出す 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 🚨 MQTT bridge 修正予定 キュー stream notifiy 追加 案4: Streamまで分離

Slide 33

Slide 33 text

Copyrigh © 2022 by Future Corporation 評価軸を出して比較 No Item Pros Cons 1 トピックそのまま 改修がナイーブで済む MQTTトピックの設計ポリシー違反 で、できれば歪めたくない 2 キュー相乗り トピックは分離できる ・キューのバックアップポリシー違反 で、できれば分離したい ・リカバリ手順が変更になる 3 キュー分離 既存のバックアップポリシーに 乗っ取れる ナイーブな改修ができる ・複数データ種別相乗りで動くため、 調査などが煩雑 ・最後だけ相乗りなので一貫性が気 になる 4 Streamまで分離 インフラ構成上はシンプル コードが冗長になる API呼び出しのパスが複数で揺れる ※説明のため簡略化しています

Slide 34

Slide 34 text

Copyrigh © 2022 by Future Corporation 評価からさらに案を洗練させる ● インフラ構成上の一貫性 ● コードのガバナンス ● 今後データ種別が増える頻度による対応工数 ● リカバリ手順をシンプル化したい といった要素で、Pros/Consから列を増やし、マトリクス化する No Item インフラ ガバナンス 将来拡張 リカバリ手順 理解しやすさ 1 トピックそのまま … … … … … 2 キュー相乗り … … … … … 3 キュー分離 … … … … … 4 Streamまで分離 … … … … … 観点はどんどん 成長していく！

Slide 35

Slide 35 text

Copyrigh © 2022 by Future Corporation 評価軸をもって意思決定する ● 評価軸を設けるのは、「決める」ため。収束のための手順 ● この評価軸に、様々なステークホルダー（有識者）の観点を追 加できるかが鍵 ● たたき台を作って、レビューで観点漏れがないかを潰すことが オススメ ○ 慣れたアーキテクトでも必ず行っている ○ 観点が漏れること自体は恐れず、現時点で手に入る情報を 整理し、複数案を出すといった枠組みを作ることが大事

Slide 36

Slide 36 text

Copyrigh © 2022 by Future Corporation 意思決定をくだす ● 評価軸をもとにフラットに調査します。✅△❌などレベル分けしたり、スコア リングしても良いかもしれません ● ある観点でNG（ノックアウト）という場合でも後々振り返りすることができる ように残しておくことがオススメ No Item インフラ ガバナンス 将来拡張 リカバリ手順 理解しやすさ 1 トピックそのまま … ❌ … … … 2 キュー相乗り … … … … … 3 キュー分離 △ ✅ ✅ ✅ △ 4 Streamまで分離 … … … … …

Slide 37

Slide 37 text

Copyrigh © 2022 by Future Corporation 注意事項 ● まずは最初は20分、メリット・デメリットをまとめるところ から始めましょう ● 最初のたたき台作成から、みんなで行うは禁止ワード ○ 我慢して1人で思考することが重要 ○ 筆が止まったらすぐ相談するくらいが良い ● 前提条件の整理などヒアリングすることはOK ○ というかむしろ推奨

Slide 38

Slide 38 text

Copyrigh © 2022 by Future Corporation 【まとめ】 アーキテクトの第一歩を踏むには ● 日々の設計上の判断も、本当にそれで良いのか、もっと良い手法が無い か踏みとどまって考えてみる ● 複数案考えてみてPros/Cons出して、選択する 積み重ねることでどんどん経験が増す →決定した意思決定を実装、保守するのはだいたい自分 自信をもって判断できる領域が増える😄 後輩に研究を引き継ぐ時にも、選んだ理由・選ばなかった理由を整 理できるとかっこいい

Slide 39

Slide 39 text

Copyrigh © 2022 by Future Corporation 【Exercise2】 みんなならどうする？ アーキテクチャ編

Slide 40

Slide 40 text

Copyrigh © 2022 by Future Corporation 研究室(部活/サークル）の物品管理アプリ ● 共有の道具をみんなで使うが、だれが今使っているか管理したい ● ユーザー数は10名とする ● 借りにいって無かったら時間の無駄だし、Webで見たい ● だれがいつまでに返すか知りたい 󰠁 🧪🧪💉💉🧫 󰠁 󰠁 レンタル しばしば不足する

Slide 41

Slide 41 text

Copyrigh © 2022 by Future Corporation このままの要件で突き進むとします。 案出しが最初の第一歩 No Item 説明 1 台帳（紙）で管理 借りる人が、だれが、何を、いつまで使うか記入する 2 Google Form 借りる人が、だれが、何を、いつまで使うかフォームに記入する 3 LINEグループで投稿 借りる人が、だれが、何を、いつまで使うか研究室 LINEグループに投稿する 4 スクラッチで作る そういうアプリを作る

Slide 42

Slide 42 text

Copyrigh © 2022 by Future Corporation メリット・デメリットを洗い出す No Item メリット デメリット 1 台帳（紙）で管理 アナログ最強 スマホの電池が切れても問題ない 現地に行かないとわからない 2 Google Form 記入が楽 一応、Webで見れる 記入ミスの修正が面倒 あくまでスプレッドシートなので確認が手間 3 LINEグループで投稿 投稿は楽 管理対象が増えるとノイジー LINE使わない人がイル 研究室メンバーにLINE IDを教えたくない 4 スクラッチで作る 要件を満たせる。 開発の手間 作り込みすぎると引き継ぎが難しい

Slide 43

Slide 43 text

Copyrigh © 2022 by Future Corporation 選択肢がそもそも正しいのか調べる ● 色々広げてみる No Item メリット デメリット 1 台帳（紙）で管理 アナログ最強 スマホの電池が切れても問題ない 現地に行かないとわからない 2 Google Form 記入が楽 一応、Webで見れる 記入ミスの修正が面倒 あくまでスプレッドシートなので確認が手間 3 LINEグループで投稿 投稿は楽 管理対象が増えるとノイジー LINE使わない人がイル 研究室メンバーにLINE IDを教えたくない 4 スクラッチで作る 要件を満たせる。 開発の手間 作り込みすぎると引き継ぎが難しい 5 Googleカレンダーに記入 使いたい 数が増えると大変 6 直接スプレッドシートに記入 紙を電子化するだけなのでシンプル 入力の手間がある 7 …. 思いつく限り洗い出す

Slide 44

Slide 44 text

Copyrigh © 2022 by Future Corporation 要件について これくらいふわっとした話だと決めきれないですが... ● Webから確認できるという要件が必達でなければ、紙でも何でも良い ○ そもそも、「消耗品の管理って必要なのか？」というところで、高価かつ台数が限られ るもののみ管理対象とするという割り切りができないか ● 全員が記入可能なのか？ ○ 全て、面倒くさがりで記入をサボる人がいると崩壊する ○ 研究室では性善説で良さそうだが、サークルだと高確率で崩壊しそう ■ QRコード読み取りルールにする？ ● 守る所、攻める所、捨てるところを整理して現実的なラインに落とし込む

Slide 45

Slide 45 text

Copyrigh © 2022 by Future Corporation 大方針が決まったとする 仮に性善説で、シンプルにスプレッドシート管理する 懸念点を洗い出す ・マスタデータを消された詰む 　・バックアップ、履歴管理 ・必須入力が漏れる人がいる ・入力が手間なのでプルダウン選択にしたい ・結局、一々確認するのが手間なので通知したい

Slide 46

Slide 46 text

Copyrigh © 2022 by Future Corporation それぞれの構成案と懸念への対策、考えを洗い出す ・入力規則で回避可能（必須化と選択） ・人の出入りが激しいときのメンテが懸念 　→無視する？ or なにか対策を取る？ BOTスクリ プト 全て埋まっていたら通知 する。欲しい人が自分で 作る？

Slide 47

Slide 47 text

Copyrigh © 2022 by Future Corporation 再び評価に立ち返り、繰り返す スプレッドシート案で運用が耐えられるか、許容する市内の判断 ユーザー教育に載せられるならOKかもしれないし、そうじゃないなら別のアプローチを再検討 例）入力が手間なら、そこだけQRコード読み取りのアプリを作るなど 🤵 📲 追加要素

Slide 48

Slide 48 text

Copyrigh © 2022 by Future Corporation 選択した理由をドキュメントに残る 検討経緯こそがアーキテクト、アーキテクチャにとって最重要。 後年、別の人がなぜこれになったか悩まないように。 ● スプレッドシートを採用した理由 ○ 単体で履歴管理が可能 ○ 同時編集もでき、Web参照OK ○ 利用者のITリテラシーが高く、限定されたユーザー利用のため ● 通知について ○ AppScriptを利用。BOTは各自が開発、管理する。追加時は～に追記する ○ 全体で管理しない理由は～である ● 独自アプリ開発を採用しなかった理由 ○ 作り込みすぎると、引き継ぎ時の負債になる

Slide 49

Slide 49 text

Copyrigh © 2022 by Future Corporation 例えば以下のような区別ができます ● MUST要件：必ず守る必要がある ● WANT要件：できればあると嬉しいもの 何も前提を置かないと、限りなくユーザーが自由度高く作るしかなくなり、途方もな い時間が必要（往々にして、高望みしすぎて途中で良さがん尽きる / 心が折れる） 作業工数を意識しながら、前提をうまく抑える勘所が必要 （アーキテクトには開発経験が求められる理由の一つ） 【補足】要件について

Slide 50

Slide 50 text

Copyrigh © 2022 by Future Corporation ● そうともいえます ● ただ、要件からトレードオフを理解して選定するプロセスはアーキ テクトに近いかなと思います ● 構造と、BOTアプリの管理規約などを揃えていくと、より現場開発 なアーキテクトのような仕事に近づくかもしれません 【補足】これって技術選定では？

Slide 51

Slide 51 text

Copyrigh © 2022 by Future Corporation アーキテクティング 行うタイミング

Slide 52

Slide 52 text

Copyrigh © 2022 by Future Corporation アーキテクティングをするタイミング ● 影響度が大きい設計事項に対して、トレードオフを意識しなが ら意思決定することがアーキテクトには必要 ● 常に検討する時間はないので、必要なトリガーを持っておく 1. 新しいデータパターン、処理パターンが登場したとき a. 接続先が増えた b. 連携頻度、タイミングが異なる c. 大量にデータを処理する必要がある 2. 要求に対して、複数の実装”箇所” が思いついたとき 3. 開発標準に無いことをするとき 4. 類似の処理をするコードが無いとき 5. 今回決めた方針が今後出てくる類似の要望にも適用されそうと感じたとき 6. 実装がやたら複雑で、考慮事項が多く、難易度”S”になったとき

Slide 53

Slide 53 text

Copyrigh © 2022 by Future Corporation 「Exercise 例で学ぶアーキテクティングの流れ」 のようなレベルすら無いんだけど..と言うとき ● 新しい処理パターンが無いフェーズにいることも多々ある ● こういった場合、既存のアーキテクチャそのものに対して研究する 1. 今のアーキテクチャ（の一部）がなんでこうなっているか？考える a. 有識者に背景を確認する b. わかる人がでてくるまで遡る 2. 自分ならどうするか考える a. あるべき姿（To Be）を描く 3. 現状（As Is）とのFit & Gapを描き、今後の一部の機能（運用ツールな ど）でそのあるべき姿に寄せて作れないか検討 ● 1を”考える” て “周囲に聞く” だけで周囲の評価は変わることが多い

Slide 54

Slide 54 text

Copyrigh © 2022 by Future Corporation 既存の煮詰まっていない部分は確実にある ● As Isの調査の中で、方針がそもそも存在していない・方針に 添って設計されていない箇所が見つかることも多々ある ● そういった場面で、チームの未来のために開発方針などを追 加したり、直せる範囲で修正するなどのアクションは取れる はず ○ あくまでできる範囲で、敵を作らないように！ ● どんなに些細でもアーキテクチャを育てられたら、それは アーキテクトだと思います

Slide 55

Slide 55 text

Copyrigh © 2022 by Future Corporation 発散のための技法

Slide 56

Slide 56 text

Copyrigh © 2022 by Future Corporation 良いアーキテクチャを作るためには 発散フェーズが大事 ● まず複数の案を上げることが大事 整理 再検討 収束 発散 検討 開始 要求事項 現状の アーキ ここで出し切れるかで精度が変わる

Slide 57

Slide 57 text

Copyrigh © 2022 by Future Corporation ● 設計は探索的で、一意なアルゴリズムがあるわけはない ○ アートの世界でも（多分）同じ ● 発散→収束の流れといったプラクティスはある ○ 例: ブレインストーミングなど ● 設計技法としては色々なテクニックがあるし、知っておくと 良いパターン・原理原則などもある デザイン思考（デザインシンキング）

Slide 58

Slide 58 text

Copyrigh © 2022 by Future Corporation 原理原則 よくある原則系、アーキテクチャパターンは知っておくと発想が広がる ● Publish/Subscribe ● ストリーム/バッチ ● サービス指向アーキテクチャ/データ志向 ● 密結合/疎結合 ● レイヤー ● パイプ＆フィルター ● Shared Data ● Single Source of Truth ● イミュータブル、ミュータブル ● 使っているプラットフォームのベストプラクティス

Slide 59

Slide 59 text

Copyrigh © 2022 by Future Corporation CSの原理原則はずっと役立つ https://www.slideshare.net/nakano_lab/cs-metatechniques

Slide 60

Slide 60 text

Copyrigh © 2022 by Future Corporation Enterprise Integration Pattern ● ベストプラクティスや他社事例は非常に参考になる ● IoTの例でストリーム処理をする場合は、Enterprise Integration Patternも抑えておく視点が 広がる（古典かつ、日本語訳が無いですがWebからも見れます） ● サービス間の連携パターンが一覧になっています https://www.enterpriseintegrationpatterns.com/PipesAndFilters.html

Slide 61

Slide 61 text

Copyrigh © 2022 by Future Corporation これを応用してみるといったアイデアも浮かぶ 例えば、ストリームのパイプラインを多段にするといったアイデアです 󰠁 デバイス 🐯 MQTT bridge キュー stream API API デバイス 🐉 🚨 MQTT bridge 修正予定 キュー stream 🐯→🐉変 換 notifiy 追加 メリットはAPIやnotifyを呼ぶパスが1本化される（こういうのやっても良いんだ..って自信も持てる） 原理的に同じデータ表現を持つべきデバイスであれば同じ構成を今後も取れる デメリットは、多段にした分だけデータ取り込みまでのレイテンシが下がる、クラウド費用コストが上る 可能性がある、などでしょうか

Slide 62

Slide 62 text

Copyrigh © 2022 by Future Corporation オズボーンのチェックリスト No Item Description アーキテクティングでのアイデア 1 転用 改変・改良すれば（またはそのままで）、他に用途はないか ? 設計案を別の用途で利用できないか 2 適合・応用 他にこのようなものがあるか ? 過去に匹敵したものは何か ? 既存のサービスに今回の設計を相乗りできないか。機能を流用できないか 3 変更 色・形・音・匂い・意味・動きなど、新しいアングルはないか？ 部分的に別設計案に変えてみると意外とよかったりしないか 4 拡大 大きさ・時間・頻度・高さ・長さ・強さを拡大できるか？ アクセス数が増えるとどうなるか。連携先、開発者が増えた時に耐えられるか 5 縮小 より小さくできるか？携帯化できるか？短くできるか？省略できるか？軽くできるか？ もっとシンプルにできないか。既存の制約を外せないか。その制約や前提条件を緩和で きないか 6 代用 他の材料・他の過程・他の場所・他のアプローチ・他の声の調子・他の誰か・異なった成 分など、他の何かに代用できないか？ 既存のサービスにその機能を追加させることはできないか。 上流から断てないか 7 再配置 要素・成分・部品・パターン・配列・レイアウト・位置・ペース・スケジュールなどを変えられ ないか？原因と結果を替えられないか？ 処理する順番を入れ替えられないか。 8 逆転 逆（正反対）にできないか ? 後方（前方）に移動できないか ? 役割を逆にできないか？ター ンできないか？反対側を向けられないか？マイナスをプラスにできないか？ 処理の駆動を変えられないか。処理の起点を入れ替えられないか 9 結合 組合わせられないか？目的や考えを結合できないか ?一単位を複数にできないか？ 汎用的に作れないか。サービスを細かくするのではなく統合できないか ● アイデア発想のためのヒント集としてオズボーンのチェックリストがあります

Slide 63

Slide 63 text

Copyrigh © 2022 by Future Corporation 捨て案も残しておく ● どう見ても使え無さそうな設計案も列挙しておく ○ ノックアウトで消せば良いだけなので ● 亜種がいっぱいでてきた場合、一番その特徴を捉えたシンプルな例を残 せばOK ● 重要なのは数を出すこと ○ 出した案が多ければ多いほど、最後に選ばれた設計案に自信を持てる

Slide 64

Slide 64 text

Copyrigh © 2022 by Future Corporation アーキテクティングは時間がかかる ● 発散と収束を繰り返す ○ 案出しと、適切な評価軸をもって選定することは パワーも使うし、時間もかかる ● ただ、手を抜くと中々決めきれないということにもつなが るので、がんばるしか無い ○ なれるとスピードは上がってくると思います

Slide 65

Slide 65 text

Copyrigh © 2022 by Future Corporation トレンドを知る ● 特に物品管理のような領域だと、既存の優れたSaaSサービスが多く ある ● あるいは、直接物品管理のカテゴリーでないツールの利用も考えら れる（例Notionで管理など） ● なるべく広くアンテナを張り、情報収集する必要がある ○ 類似の事例（隣、近所の研究室のやり方を教えてもらう） ○ 勉強会の参加 ○ ネットで調べる（企業ブログ、Twitter、GitHub Treands）

Slide 66

Slide 66 text

Copyrigh © 2022 by Future Corporation 収束のための技法

Slide 67

Slide 67 text

Copyrigh © 2022 by Future Corporation 最初から評価軸に完璧を求めない ● 最初から評価軸を出すのは大変 ● まずは Pros/Cons を書くだけで良い ○ おそらく、完璧を求めると筆が止まります ● いったんPros/Consででてきた要素を軸に切り出す ● さらにブラッシュアップ ○ 有識者レビュー（抜けた観点） ○ IPA非機能要件シート ■ テスト性、移行性、リカバリ性 ● このへんまでいければ、アーキテクトとしてレールに乗った状態

Slide 68

Slide 68 text

Copyrigh © 2022 by Future Corporation アーキテクチャの 意思決定ができた後

Slide 69

Slide 69 text

Copyrigh © 2022 by Future Corporation 設計ドキュメントを書く ● なぜその検討結果になったのか、経緯を設計ドキュメントに残す ○ 例えば、GitHubのREADMEや、チームのWikiに追記する ● 経緯はかなり重要 ○ 特にその機能に閉じて見たときに、直感的でないかつ不効率な決定事項の場合は、決 まったアーキテクチャが納得できない未来の新規参画者にとって戸惑いのもと ■ 品質が下がる ■ 最悪、アーキルールを守らず秩序が崩壊することも！ ○ 後で追えるようにしておくことが、アーキテクトにとって必須の振る舞い ● アーキテクチャディシジョンレコード（ADR） ○ タイトル(Title)　コンテキスト(Context)　決定(Decision)　ステータス(Status)　結 果(Consequences)といった標準的なフォーマットはある ■ 私は経験上使いこなせていないのですが、興味があれば見ておくとよい

Slide 70

Slide 70 text

Copyrigh © 2022 by Future Corporation アーキテクチャ設計の フィードバックを得る ● 決めたアーキテクチャが実装、テスト、リリースしやすいか肌で感じる ○ アーキテクチャ決定のフィードバックは非常に重要 ○ 実は、大規模なアーキテクチャ決定だとフィードバックサイクルが長い ○ 小さなものは比較的早くフィードバックを得られるので学び速度が早い ● 考慮漏れしていた事項を覚えておく ○ 最初はかならず、「こうしておけばよかった」がでてくる ○ なによりの成長ポイントなので、振り返りは非常に大事 ○ 意外とあるのは、「前提、背景」の情報を正しく集めきれなかったこと

Slide 71

Slide 71 text

Copyrigh © 2022 by Future Corporation アーキテクトの アンチパターン

Slide 72

Slide 72 text

Copyrigh © 2022 by Future Corporation 象牙のアーキテクト ● 机上のアーキテクチャを組んでしまう ○ 机上とは実装しないということ ● 実装イメージがわかないと、コンポーネントの依存関係・結合性だけで アーキテクチャを組みがちで、オーバースペックになりがち ○ 結果的に生産性・品質が下がってしまう ● チームメンバーに理解できない、遵守できないアーキテクチャに価値は ない ○ やるなら教育・育成もセットでやる

Slide 73

Slide 73 text

Copyrigh © 2022 by Future Corporation 新しい技術を入れちゃいがち ● 新米アーキテクトは攻めた技術選定をやっちゃいがち ○ 例えば、AWSの新しめのサービスなど ● 悪くはないが、既存設計との一貫性を考える ○ （例）すでにバッチでAWS ECSを使っているのに、App Runnerを採用 しようとする ● 今後出てきたときの使い分けはどうするか？監視障害検知リカバリの手順が 増えるが許容できるか？今後さらに新しいサービスがでてきたときに乗り換 えるのか？ ○ ガバナンスがゆるくなりがち ○ 本当に全体最適でやるべきか検討する ■ （とは言え、どこかでアップデートする必要があるのも事実だが）

Slide 74

Slide 74 text

Copyrigh © 2022 by Future Corporation 個性出しちゃうパターン ● プロダクト史上初とか、社内初とか、世界初といったワー ドがでてくると危険性が高い ● たいてい、何か詳細部分を見過ごしている可能性がある ● やれていない何かしらの理由が存在するので、詳細まで見 てから、チャレンジしましょう ○ メンバーが付いてこれるか.. ● 個人的には、アーキが個性をだしたら終わりだと思ってい ます

Slide 75

Slide 75 text

Copyrigh © 2022 by Future Corporation グラウンドホッグデーアンチパターン ● 決まったようで決まらないパターン（エンドレスパターン） ● 決めた理由が曖昧であると発生する ● 「このパターンのときどうする？」の回答に詰まるとよくひっくり 返る ● 対策 ○ 根拠を残す ○ 考慮漏れを無くすべく観点洗い出しに力を入れる

Slide 76

Slide 76 text

Copyrigh © 2022 by Future Corporation 前提条件の調査を怠っちゃったパターン ● 前提となる条件や、As Isの現在の状態が、「〇〇だと思 う」、「〇〇だと考えている」など推測が多いケース ● Fact（事実）を集めるのもアーキテクトになるためには 重要な役割なので、手を抜かず裏取りしましょう ● できれば既存のシステム構成図きちんと作りましょう ○ きっちり≒登場人物が全て洗い出せ、依存関係も表現 できていること

Slide 77

Slide 77 text

Copyrigh © 2022 by Future Corporation 全員がアーキテクトな チームは強い

Slide 78

Slide 78 text

Copyrigh © 2022 by Future Corporation みんながアーキテクトになると幸せ ● アーキテクチャを理解しないと、ルール（開発上の制約）だけが残る ● それは開発者にとってやらされている感を与える ● プロダクトを自分ごとと思えず、オーナーシップの欠如となる ○ 共同所有の意識が薄くなり、ルールを破り勝ちになる ● また、設計判断の観点は一人で洗い出すのは困難 ○ 壁打ちできるメンバーは多ければ多いほうが良い

Slide 79

Slide 79 text

Copyrigh © 2022 by Future Corporation アーキテクトは権威主義にならない ● アーキを決める人が偉いわけではない ● むしろ全体最適からくるアプリ開発上の制約をみんなと相 談し、納得し、ともに成長させるべき ● どちらかと言えば、コーチング的な役割を目指すこと ● 少なくても、ディスカッションパートナーとして相手を尊 重すること ● そして、相手を次の新米アーキテクトに導くこと

Slide 80

Slide 80 text

Copyrigh © 2022 by Future Corporation さいごに

Slide 81

Slide 81 text

Copyrigh © 2022 by Future Corporation さいごに アーキテクトを目指す方に、どういった流れでアーキテクティング を行うかを紹介しました イチから全てアーキテクチャを描くといったことではなく、複数の 実装方法を取りうるとき、発散→集約して経験を積むことを例を通 して話しました 良いアーキテクチャは、良いチームを育て、そしてそれらは良いプ ロダクト開発に必須だと思います

Slide 82

Slide 82 text

Copyrigh © 2022 by Future Corporation メッセージ ● アーキテクチャ、アーキテクトはトレードオフを言語化し、バランスを取る ● みんなが使う構成を意思決定していく必要 ● 技術に詳しいということに加え、交渉力も必要になってくる ● 技術も好きだ。それ以外のヒューマンスキルも嫌いじゃない！って方。アーキテ クチャ設計ができるという武器をぜひ手に入れると、人生楽しくなると思いま す！

Slide 83

Slide 83 text

Copyrigh © 2022 by Future Corporation ご清聴、ありがとうございました！ Enjoy Architecting!