エンジニアを目指す君たちはどう生きるか ～ソフトウェアアーキテクトのすゝめ～

技育祭2023秋 DAY1 HALL C 14:30 - 15:15 「エンジニアを目指す君たちはどう生きるか　～ソフトウェアアーキテクトのすゝめ～」 の登壇資料です。

https://talent.supporterz.jp/geeksai/2023autumn/information/#1021-1430-HallC

Transcript

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