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

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

View Slide

Copyrigh © 2022 by Future Corporation
About Me

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

アーキテクト、アーキテクチャって
何ってところから話します

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

What is Architecture

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

【Exercise1】
例で学ぶアーキテク
ティングの流れ

View Slide

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

View Slide

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

View Slide

できること
対応案１
● ナイーブな対応案では、streamと呼ばれるコードに分岐を入れる
● if 分を追加してテストして終了。簡単である
󰠁
デバイス
🐯
デバイス
🐉
NEW！ ↑ここに分岐を入れる
🚨
notiﬁy

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

󰠁
デバイス
🐯
MQTT
bridge
キュー stream API API
デバイス
🐉
🚨
MQTT bridge
修正予定
notiﬁy
案2: MQTTトピックは分け、Streamで分岐
追加

View Slide

󰠁
デバイス
🐯
MQTT
bridge
デバイス
🐉
🚨
MQTT
bridge
修正予定
キュー
notiﬁy
追加
案3: キューイングまで分離

View Slide

󰠁
デバイス
🐯
MQTT
bridge
デバイス
🐉
🚨
MQTT
bridge
修正予定
キュー stream
notiﬁy
追加
案4: Streamまで分離

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

【Exercise2】
みんなならどうする？
アーキテクチャ編

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

アーキテクティング
行うタイミング

View Slide

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

View Slide

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

View Slide

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

View Slide

発散のための技法

View Slide

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

View Slide

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

View Slide

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

View Slide

CSの原理原則はずっと役立つ
https://www.slideshare.net/nakano_lab/cs-metatechniques

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

収束のための技法

View Slide

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

View Slide

アーキテクチャの
意思決定ができた後

View Slide

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

View Slide

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

View Slide

アーキテクトの
アンチパターン

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

全員がアーキテクトな
チームは強い

View Slide

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

View Slide

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

View Slide

さいごに

View Slide

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

View Slide

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

View Slide

ご清聴、ありがとうございました！
Enjoy Architecting!

View Slide

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

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

Junki Mano

More Decks by Junki Mano

Other Decks in Technology

Featured

Transcript

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

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

Junki Mano

More Decks by Junki Mano

Other Decks in Technology

Featured

Transcript

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

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