$30 off During Our Annual Pro Sale. View Details »

ソフトウェアアーキテクトって何やるの? ~知っておくと役立つ考え方を共有します~ | 技育祭2022秋

Junki Mano
October 14, 2022

ソフトウェアアーキテクトって何やるの? ~知っておくと役立つ考え方を共有します~ | 技育祭2022秋

技育祭2022 DAY1 勉強会 "ソフトウェアアーキテクトって何やるの? ~知っておくと役立つ考え方を共有します~" の登壇資料です。

ソフトウェアアーキテクトとは、聞いたことがあっても具体的な仕事のイメージが湧きにくい役割の一つではないかと感じています。 どういう設計検討をしているか実例を交えて紹介します。 ITエンジニアを志望されている方にも、キャリアパスの一つとして知っておくと役立つと思います。
https://talent.supporterz.jp/geeksai/2022autumn/information/#1014-1330-Studies

Junki Mano

October 14, 2022
Tweet

More Decks by Junki Mano

Other Decks in Technology

Transcript

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

    View Slide

  2. Copyrigh © 2022 by Future Corporation
    About Me

    View Slide

  3. Copyrigh © 2022 by Future Corporation
    自己紹介
    󰢧 真野隼記

    🤖 アーキテクト歴13年くらい

    🏢 フューチャー株式会社

    🚲 フィットネスサイクル漕いでます

    🏃オープン活動
    実用Go言語(同僚と共著)

    フューチャー技術ブログ運営

    会社Connpass勉強会主催

    💡 お仕事
    製造業、エネルギー業界、IoT全般

    キャリアの最初は共通ライブラリ、ミドルウェ
    ア、フレームワーク開発


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. Copyrigh © 2022 by Future Corporation
    最初から少し先の未来に視点を向けること
    で、今の過ごし方が変わってくることも。
    どういう視点で考えているか
    知っておくとプラスだと思っています

    アーキテクトの視点
    研究者
    リードエンジニア
    ちょっとでも、将来像の選択肢に
    加えられたら、今の過ごし方も変わる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. Copyrigh © 2022 by Future Corporation
    What is Architecture

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  61. Copyrigh © 2022 by Future Corporation
    これを応用してみるといったアイデアも浮かぶ
    例えば、ストリームのパイプラインを多段にするといったアイデアです
    󰠁
    デバイス
    🐯
    MQTT
    bridge
    キュー stream API API
    デバイス
    🐉
    🚨
    MQTT
    bridge
    修正予定
    キュー
    stream
    🐯→🐉変

    notifiy
    追加
    メリットはAPIやnotifyを呼ぶパスが1本化される(こういうのやっても良いんだ..って自信も持てる)
    原理的に同じデータ表現を持つべきデバイスであれば同じ構成を今後も取れる
    デメリットは、多段にした分だけデータ取り込みまでのレイテンシが下がる、クラウド費用コストが上る
    可能性がある、などでしょうか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  80. Copyrigh © 2022 by Future Corporation
    さいごに

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide