技育祭2023秋 DAY1 HALL C 14:30 - 15:15 「エンジニアを目指す君たちはどう生きるか ～ソフトウェアアーキテクトのすゝめ～」 の登壇資料です。
https://talent.supporterz.jp/geeksai/2023autumn/information/#1021-1430-HallC
1エンジニアを目指す君たちはどう生きるか～ ソフトウェアアーキテクトのすゝめ ～技育祭 2023 秋10.21（土） HALL C 14:30 – 15:15
View Slide
2はじめに
3ここは HALL C ですよ
4ご視聴にあたってZoom Chat/SNS実況歓迎質問は適宜OK回答は最後資料公開ありHashtag: #技育祭 #ホールC
5whoamiTakeda HirokiCareer:- Hitotsubashi Univ. ~2012/3- Future Architect, Inc. 2012/4 ~Favorite Languages:- Go- TypeScriptHobbies:- Kitchen Drinking- ProgrammingAccounts:- Qiita : @rhumie- X : @rhumie_MBTI: Logician（INTP-A）
6IT consulting firm for the Geeks
7私はどう生きてきたかWeb API設計,開発リード（Java/SQL）バックエンドエンジニアマネージドサービスを活用したインフラ設計,構築AWSエンジニアSPA設計,開発リード（React/Vue.js）WEBフロントエンドエンジニアアーキテクチャ設計設計,開発リード（TypeScript/Golang）テックリードソフトウェアアーキテクトテスターテスト実施プログラマ個別機能設計,開発（Java/SQL）学生知識ゼロAndroid/iOSアプリ設計,開発リード（Flutter/Capacitor）モバイルエンジニア
8本日のゴール（1/2）Web API設計,開発リード（Java/SQL）バックエンドエンジニアマネージドサービスを活用したインフラ設計,構築AWSエンジニアSPA設計,開発リード（React/Vue.js）WEBフロントエンドエンジニアアーキテクチャ設計設計,開発リード（TypeScript/Golang）テックリードテスターテスト実施プログラマ個別機能設計,開発（Java/SQL）学生知識ゼロAndroid/iOSアプリ設計,開発リード（Flutter/Capacitor）モバイルエンジニアフルスタックに経験を積んだ先に行きついたソフトウェアアーキテクトという「生き方」を知る/学ぶそもそもアーキテクチャ/アーキテクトとは何なのか？実際にどのようなことをやるのか？どのようなスキルが求められるか？ソフトウェアアーキテクト
9ソフトウェアアーキテクト本日のゴール（2/2）Web API設計,開発リード（Java/SQL）バックエンドエンジニアマネージドサービスを活用したインフラ設計,構築AWSエンジニアSPA設計,開発リード（React/Vue.js）WEBフロントエンドエンジニアアーキテクチャ設計設計,開発リード（TypeScript/Golang）テックリードテスターテスト実施プログラマ個別機能設計,開発（Java/SQL）Android/iOSアプリ設計,開発リード（Flutter/Capacitor）モバイルエンジニアアーキテクト思考 + 学生視点で考えるこれからのエンジニアとしての「生き方」のヒントを得る学生知識ゼロどのような技術を身に付けるべきか？どのようなポジションを目指すべきか？どのような会社に入るべきか？
10ソフトウェアアーキテクトという「生き方」を知る/学ぶそもそもアーキテクチャ/アーキテクトとは何なのか？実際にどのようなことをやるのか？どのようなスキルが求められるか？
11アーキテクト/アーキテクチャとは？
12もともとは建築用語
13ソフトウェアアーキテクト/ソフトウェアアーキテクチャとは？
14一意的な定義は存在しない今までのところ「ソフトウェアアーキテクチャ」という用語に関して, 万人が合意した厳密な定義は存在しない。Wikipediaシステムのソフトウェアアーキテクチャとは, 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する, 重要な設計判断が集まったものだ。Michael Keeling (著), 島田 浩二 (翻訳) Design It!システムの構造, システムがサポートしなければならないアーキテクチャ特性, アーキテクチャ決定, そして設計指針の組み合わせで構成されるもの。Mark Richards, Neal Ford (著), 島田 浩二 (翻訳) ソフトウェアアーキテクチャの基礎アーキテクチャとは, コンポーネント, コンポーネント間および環境との関係, またその設計と進化の指針となる原理に体現されたシステムの基本構造である。IEEE 1471
15ソフトウェアアーキテクチャとはシステムに求められる重要な特性を満たすための,構造をはじめとするシステムの全体的な設計
16システムに求められる重要な特性を満たすための,構造をはじめとするシステムの全体的な設計「システムに求められる重要な特性」とは？
17「家づくり」で考えてみる具体的な機能/リクエスト• 3つの寝室, リビング, ダイニング,キッチン, バスルームがある• 各部屋にはコンセントとアンテナ端子がある• キッチンはアイランド型で, シンクはタッチレス水栓, コンロは3口で自動調理機能付き, 収納は立体構造で大容量で...家の品質/住み心地• 地震や火事に耐えられるためのつくりになっている• 将来子供が増えたときに, 部屋を拡張できるようなつくりになっている• プライバシーを保護するために, 防音性能が備わっている
18「システム」も同じ（1/2）機能要求• ユーザが140文字以内のメッセージを登録できる• ユーザが他のユーザをフォローすることができ, フォローしたユーザのメッセージをタイムラインとして一覧化して時系列で参照することができる• ユーザが他のユーザに直接メッセージを送信できるアーキテクチャ特性（＊1）• 数億人のアクティブユーザのリクエストを高速で処理することができる• 24時間365日利用可能で, 障害時のダウンタイムが極力少ない• ユーザのアカウントが適切に保護され, 不正アクセスや情報漏洩が発生しない＊1） 品質特性や非機能要件など様々な言い方があります
19「システム」も同じ（2/2）機能要求• ユーザが140文字以内のメッセージを登録できる• ユーザが他のユーザをフォローすることができ, フォローしたユーザのメッセージをタイムラインとして一覧化して時系列で参照することができる• ユーザが他のユーザに直接メッセージを送信できるアーキテクチャ特性（＊1）• 数億人のアクティブユーザのリクエストを高速で処理することができる• 24時間365日利用可能で, 障害時のダウンタイムが極力少ない• ユーザのアカウントが適切に保護され, 不正アクセスや情報漏洩が発生しない＊1） 品質特性や非機能要件など様々な言い方がありますソフトウェアアーキテクチャを考えるときはこちらをより意識
20アーキテクチャ特性（-ility）可用性（Availability）信頼性（Reliability）回復性（Recoverability）耐障害性（Fault Tolerance）障害回避（Fault Avoidance）災害復旧（Disaster Recovery）性能（Performance）性能拡張性（Scalability）機能拡張性（Extensibility）弾力性（Elasticity）アップグレード容易性（Upgradability）中立性（Neutrality）置換容易性（Replaceability）移行性（Migratability）セキュリティ（Security）合法性（Legality）ユーザビリティ（Usability）アクセシビリティ（Accessibility）運用性（Operability）可観測性（Observability）保守性（Maintainability）モジュール性（Modularity）再利用性（Reusability）解析性（Analyzability）修正性（Modifiability）テスト容易性（Testability）デプロイ容易性（Deployability）その他多数…
21（参考）JIS X 25010:2013システム/ソフトウェア製品品質機能適合性• 機能完全性• 機能正確性• 機能適切性性能効率性• 時間効率性• 資源効率性• 容量満足性互換性• 共存性• 相互運用性使用性• 適切度認識性• 習得性• 運用操作性• ユーザエラー防止性• ユーザインターフェース快美性• アクセシビリティ信頼性• 成熟性• 可用性• 障害許容性（耐故障性）• 回復性セキュリティ• 機密性• インテグリティ• 否認防止性• 責任追跡性• 真正性保守性• モジュール性• 再利用性• 解析性• 修正性• 試験性移植性• 適応性• 設置性• 置換性
22（参考）IPA 非機能要求グレード 2018非機能要求項目可用性• 継続性• 耐障害性（障害許容性）• 災害対策• 回復性性能・拡張性• 業務処理量• 性能目標値• リソース拡張性• 性能品質保証運用・保守性• 通常運用• 保守運用• 障害時運用• 運用環境• 運用・保守体制• 運用管理方針移行性• 移行時期• 移行方式• 移行対象（機器）• 移行対象（データ）• 移行計画セキュリティ• 前提条件・制約条件• セキュリティリスク対応• セキュリティ診断• セキュリティリスク管理• アクセス・利用制限• データの秘匿• 不正追跡・監視• ネットワーク対策• マルウェア対策• Web対策環境・エコロジー• システム制約/前提条件• システム特性• 適合企画• 機材設置環境条件• 環境マネージメント
23求められる重要な特性を明確し, 優先順位を付ける可用性（Availability）信頼性（Reliability）回復性（Recoverability）耐障害性（Fault Tolerance）障害回避（Fault Avoidance）性能拡張性（Scalability）機能拡張性（Extensibility）弾力性（Elasticity）アップグレード容易性（Upgradability）中立性（Neutrality）置換容易性（Replaceability）移行性（Migratability）セキュリティ（Security）合法性（Legality）ユーザビリティ（Usability）アクセシビリティ（Accessibility）運用性（Operability）可観測性（Observability）保守性（Maintainability）モジュール性（Modularity）再利用性（Reusability）解析性（Analyzability）修正性（Modifiability）その他多数…性能（Performance）災害復旧（Disaster Recovery）日本において大規模な災害が発生した場合でも, XX時間以内に災害発生前の状態に復旧し, サービスを提供し続けることテスト容易性（Testability）デプロイ容易性（Deployability）
24システムに求められる重要な特性を満たすための,構造をはじめとするシステムの全体的な設計「システムの全体的な設計」とは？
25実際にやっていること構造設計 技術選定処理方式設計
26実際にやっていること – 構造設計 –構造設計 技術選定処理方式設計
27構造設計システムの単位（提供する機能,保持するデータ）やシステム間の連携, 依存関係を明確化システムを構成する論理的なコンポーネントの役割やフロー（データの流れや制御の流れ）を明確化論理構成を元に, システムを構成する製品やサービスをマッピングシステム構成（論理）APIGWキューストアデータストアファイルストレージAPIStream機能配置/サービスカットユーザ管理機能（登録/更新/削除）ユーザ情報ブラウザユーザ管理システムメール配信システムメール配信機能配信履歴注文管理システム注文機能注文履歴〇〇システム制御の流れデータの流れシステム構成（物理）論理から物理へ/抽象から具体へ/概要から詳細へAWSAPI Gateway LambdaDynamoDBS3SQSLambda制御の流れデータの流れap-northeast-1
28実際にやっていること – 技術選定 –構造設計 技術選定処理方式設計
29技術選定（1/2）クラウドサービスプロバイダ AWS, GCP, Azure, OCI, etc...クラウドサービス Amazon EC2, Amazon S3, etc...ミドルウェア Web Server（Apache, Nginx）, etc...開発言語 Java, Golang, TypeScript, etc...アプリケーションフレームワーク Spring Boot, React, etc...ライブラリ / ツール O/R Mapper, Logging, Utility, etc...選定領域
30技術選定（2/2）フィジビリティスタディ調査要件を満たし得る技術の調査を行う。枯れている技術から最新の技術まで網羅的に調査を行うNon-Relational RelationalNoSQLNewSQLKVS DocumentColumn GraphOLTPOLAPas-a-ServiceOracle, PostgreSQL, MySQL,SQL Server, etc...CockroachDB, VoltDB, ...Redis,ElastiCacheMongoDB,DocumentDBCassandraAurora, RDS例. データストアの整理調査した技術の中から, 後続の評価/検証の対象となるいくつかの有力な選択肢に絞るAurora DynamoDBDocumentDB例. 選択肢を絞る検証/評価対象の技術を評価軸にもとづいて, 机上評価やPoCを行い, Pros&Consを整理する○ ○… … …○ ◎○○△ ○○制約・・・性能/拡張性コスト例. データストアを検証/評価選定網羅的な観点から評価/検証を行った結果, 現時点で最適と考えられる技術を選定する例. データストアを選定Architecture Decision Record（ADR）コンテキスト技術選定の背景：XXXXXXXXX評価・検証結果 ：XXXXXXXXX決定時系列データのデータストアに○○○を採用する。要件. ○○データを永続化する。データの読込みは秒間X回/秒, 書込みはY回/秒データ量は△△TB/日選定プロセス
31実際にやっていること – 処理方式設計 –構造設計 技術選定処理方式設計
32処理方式設計逐次/並行/並列同期/非同期リクエストに対して同期で処理するか, 非同期で処理するかの判断基準を明確化し, 実現方式を設計タスクを制御するための方式について, どのパターンを適用するかの判断基準を明確化し, パターン毎の実現方式を設計システム間連携システム間の連携方式について,どのパターンを適用するかの判断基準を明確化し, パターン毎の実現方式を設計システムA システムB{...} Web API（REST, gRPC, etc...）データベース共有メッセージングファイル転送注文受付 会計調理非同期（Async）注文受付 会計 調理同期（Sync）タスクA タスクB逐次（Sequential）並行（Concurrent）タスクB1 A2 B2タスクA1並列（Parallel）タスクAタスクB1
33その他いろいろ• アプリケーション構造設計（Layered Architecture, Clean Architecture, etc...）• 設計標準化• 画面設計, API設計, 帳票設計などにおけるパターン定義• 設計ガイドラインの策定• 開発標準化• 開発ガイドラインの策定• コーディング規約の策定• コードジェネレーターの整備• フレームワーク, 共通機能, 共通コンポーネントの開発• 設計レビュー, コードレビュー• 設計者, 開発者のコーチング etc...※ 一般的に, 設計/開発の推進はテックリードの役割かもしれません。会社や組織によりその役割は様々です。
34【再掲】ソフトウェアアーキテクチャとはシステムに求められる重要な特性を満たすための,= 機能要求 + アーキテクチャ特性構造をはじめとするシステムの全体的な設計構造設計, 技術選定, 処理方式設計 など
35アーキテクティングを行う上での心得は？
36分母と分子のクオリティの追求分母 = アーキテクチャ案質の高い複数のソリューションをいかに検討できるか分子 = 採用アーキテクチャなぜそのアーキテクチャか？をいかに語れるか✓ 多面的なトレードオフ分析✓ 論より動くもの✓ 目的と手段の再認識✓ 技術の幅✓ 原理原則の理解✓ トレンドの理解✓ ゼロベース思考アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ。Mark Richards, Neal Ford (著), 島田 浩二 (翻訳) ソフトウェアアーキテクチャの基礎
37ソフトウェアアーキテクトに必要なスキルは？
384つのスキル• 自ら具現化する力• 書けない/書かないアーキテクトはただの評論家• アーキテクティングとコーディングを「戦略的に」両立すること• 継続的に技術の幅を広げる力• レイヤ問わず様々な技術を知り, 経験すること• 最新の技術トレンドを楽しみながら学び続けること• 意思決定を行う力• 目的, 根拠を明確にしてアーキテクチャを「決断する」こと• アーキテクチャを「語り」ステークホルダを「納得させられる」こと• 継続的にアーキテクチャを「分析する」こと• 経営やビジネスの視点で考える力
39ソフトウェアアーキテクトの魅力は？
403つの魅力0からの全体設計• 全体像を見据えたディレクション• プロジェクトの成功/失敗に対する大きな影響力• 自らの「作品」を創る感覚テクノロジ最前線• 新しい技術による新しいチャレンジ• 技術でビジネスをドライブ• 自身のスキルや思想の継続的なアップデート最適解の探求• 正解が1つではない面白さ• 未来予測と答え合わせ• パズルを解くような創造性• 成功も失敗も全てが学びアーキテクティングしたものを,自ら具現化（構築）することが最大の醍醐味
41私にとってのソフトウェアアーキテクトとはアーキテクチャを設計し, 自ら具現化する
42ここまでのまとめ – 前編 –
43【再掲】 本日のゴール（1/2）Web API設計,開発リード（Java/SQL）バックエンドエンジニアマネージドサービスを活用したインフラ設計,構築AWSエンジニアSPA設計,開発リード（React/Vue.js）WEBフロントエンドエンジニアアーキテクチャ設計設計,開発リード（TypeScript/Golang）テックリードテスターテスト実施プログラマ個別機能設計,開発（Java/SQL）学生知識ゼロAndroid/iOSアプリ設計,開発リード（Flutter/Capacitor）モバイルエンジニアフルスタックに経験を積んだ先に行きついたソフトウェアアーキテクトという「生き方」を知る/学ぶそもそもアーキテクチャ/アーキテクトとは何なのか？実際にどのようなことをやるのか？どのようなスキルが求められるか？ソフトウェアアーキテクト
44これからのエンジニアとしての「生き方」のヒントを得るどのような技術を身に付けるべきか？どのようなポジションを目指すべきか？どのような会社に入るべきか？
45エンジニアのキャリアパスは何通りある？
46選択肢は無限大？企業 職種 技術• Web系• 内製系• 外製系 ...• SIer系• ユーザー系• メーカー系• 独立系 ...• コンサル系• 戦略系• IT系 ...• 通信・インフラ系• ハードウェア系• ソフトウェア系...• プログラマ• テスター• プロジェクトマネージャー• システムエンジニア• セールスエンジニア• データサイエンティスト• ソフトウェアアーキテクト• テックリード• ネットワークエンジニア• セキュリティエンジニア• データベースエンジニア• クラウドエンジニア• インフラエンジニア• CTO...• Language• C++• Java• Golang• Rust ...• Database• PostgreSQL• MySQL ...• Cloud• AWS• GCP• Azure• Oracle ...• AI...
473つの観点で考えてみる技術どのような技術/スキルを身に付けるべきか？役割どのような職種/役割を目指すべきか？環境どのような環境/会社で働くべきか？
483つの観点で考えてみる – 技術 –技術どのような技術/スキルを身に付けるべきか？役割どのような職種/役割を目指すべきか？環境どのような環境/会社で働くべきか？
49技術は変わりやすい？実行環境： VMs コンテナ, サーバレスアーキテクチャスタイル： モノリス マイクロサービスプロセス ウォーターフォール アジャイル, DevOpsWEB FrontendMPAJavaScriptCSR-SPA, SSR-SPAModern JavaScriptWEB API RPC, SOAP REST, GraphQL, gRPCデータベース RDBMS NoSQL, NewSQLインフラ構築 Mutable IaC Immutable IaC
50具体と抽象で全体を捉える（1/2）抽象具体変わりにくいトレンドがあるアプリケーション データベース …オブジェクト指向, 関数型, リアクティブ, etc...パラダイムSingleton, Observer,Pub-Sub, DI, etc...デザインパターンDRY, KISS, YAGNI,SOLID, etc...プログラミング原則Go, Java, JavaScript,Ruby, Swift, Kotlin,etc...開発言語Ruby on Rails, SpringBoot, React, Vue.js,Django, etc...アプリFW/ツールMySQL, PostgreSQL,MongoDB, TiDB, etc...DBプロダクトACID, BASE, CAP定理,etc...DB特性分散型システム, 集中型システム, etc...システムの原理ネットワークやセキュリティ,クラウドをはじめとし, 数多くの軸がある※ 図中の各要素はあくまで一例です。
51具体と抽象で全体を捉える（2/2）抽象具体変わりにくいトレンドがあるアプリケーション データベース …オブジェクト指向, 関数型, リアクティブ, etc...パラダイムSingleton, Observer,Pub-Sub, DI, etc...デザインパターンDRY, KISS, YAGNI,SOLID, etc...プログラミング原則Go, Java, JavaScript,Ruby, Swift, Kotlin,etc...開発言語Ruby on Rails, SpringBoot, React, Vue.js,Django, etc...アプリFW/ツールMySQL, PostgreSQL,MongoDB, TiDB, etc...DBプロダクトACID, BASE, CAP定理,etc...DB特性分散型システム, 集中型システム, etc...システムの原理ネットワークやセキュリティ,クラウドをはじめとし, 数多くの軸がある※ 図中の各要素はあくまで一例です。原理原則をはじめとし, 抽象度の高い領域を押さえることで変化対応力が付く
52実践のヒント抽象化 具体化古典的名著やいわゆるパターン本をはじめとし,書籍に学べることは多い原理原則やパターンを学ぶ色々な技術に触れる異なる技術や方法で同じモノを作ってみる（悩む前にやってみることも大事）歴史を学ぶその技術が生まれた背景や問題を知り,どう進化してきたのかを理解する
533つの観点で考えてみる – 役割 –技術どのような技術/スキルを身に付けるべきか？役割どのような職種/役割を目指すべきか？環境どのような環境/会社で働くべきか？
54当然, 正解はないし 状況によって変わる興味や情熱 スキル最終的なゴール市場や会社のニーズ会社やチームの文化や環境…目指すべき役割/ポジション
55技術だけでなくビジネスの流れを意識してみる関わりたい領域（幅と深さ）とステップをイメージしておくギャップが生じる例• 自社サービスの企画から開発までやりたかったが, 企画部署と開発部署が縦割りだった• 技術選定を担当したかったが, 決められたものを開発/テストすることがメインだった• 開発に携わりながらキャリアアップするパスが無かった未来を描く 計画に落とす 具現化する 価値を生み出す戦略立案 グランドデザイン 要件定義 設計 開発/テスト 運用/保守 …
563つの観点で考えてみる – 環境 –技術どのような技術/スキルを身に付けるべきか？役割どのような職種/役割を目指すべきか？環境どのような環境/会社で働くべきか？
57会社や組織の影響は大きいエンジニアとしての「成長速度」は環境によって加速も減速もする会社/組織あなた組織文化 メンターシッププロダクト/プロジェクトの規模や質教育リソース …同僚 部下上司
58会社に強くロックインされないという考え方市場会社溝市場の技術トレンドや思想に敏感であり, 社内でもそれらを適用した技術的な挑戦ができる勉強会の登壇/参加, 技術ブログや書籍の執筆, OSSコントリビュートなど, エンジニアが社外に発信できる市場と会社の溝が少ないほど「社内価値」と「市場価値」のギャップが生じにくい
59ここまでのまとめ – 後編 –
60ソフトウェアアーキテクト【再掲】本日のゴール（2/2）Web API設計,開発リード（Java/SQL）バックエンドエンジニアマネージドサービスを活用したインフラ設計,構築AWSエンジニアSPA設計,開発リード（React/Vue.js）WEBフロントエンドエンジニアアーキテクチャ設計設計,開発リード（TypeScript/Golang）テックリードテスターテスト実施プログラマ個別機能設計,開発（Java/SQL）Android/iOSアプリ設計,開発リード（Flutter/Capacitor）モバイルエンジニアアーキテクト思考 + 学生視点で考えるこれからのエンジニアとしての「生き方」のヒントを得る学生知識ゼロどのような技術を身に付けるべきか？どのようなポジションを目指すべきか？どのような会社に入るべきか？
61おわりに
62About Future未来報：https://note.future.co.jp/フューチャーのオウンドメディアです。人, カルチャー, 仕事などが知れる！Tech Cast：https://open.spotify.com/show/6ntaBQ28GSDaOztBphH6oi社員が有志で運営しているラジオ放送です。今話題になっていることから社員が語りたいことをひたすら語る会まで様々なラインナップがございます！テックブログ：https://future-architect.github.io/最新の技術トピックから初心者向けのおすすめ記事まで技術視点でFutureの魅力がわかる！
63Enjoy Tech!!!
rhumie
nttcom
orgachem
rakus_dev
masasuzu
taichinakamura
cmusudakeisuke
wakamatsu_takumu
niftycorp
neonankiti
yoshiitaka
ouchi2501
etaroid
reverentgeek
hatefulcrawdad
addyosmani
andyhume
destraynor
jakevdp
pedronauck
thekraken
denniskardys
chriscoyier
marcduiker