1 未知の未知を既知の未知へ Unknown unknowns to Known unknowns FUTURE TECH TALK #1 ボトムアップで考えるアーキテクト教育Lunchセッション会 2024.06.05（Wed）12:00–13:00

2 whoami Takeda Hiroki（X: @rhumie_） Future Architect, Inc. 2012/4 ~ #Software Architect #Tech Lead #Architecture Design #Go #TypeScript #Vue.js #AWS #Playwright ［入門］Webフロントエンド E2E テスト（共著） 2024年6月19日発売予定です！🎭🎭🎭 Real World HTTPの著者である渋川さんをはじめ, 社内のメンバで執筆しました。 E2Eテストの考え方から, Playwrightを使用した 実践まで, 学べる書籍になっています。

3 本日お話すること ソフトウェアアーキテクトを「育てる」ために 大切だと思っていること, これから取り組んでいこうとしていること

4 背景にある課題感 ⚫ アーキテクトは自然に大量発生しない ⚫ 作業を移譲してスケールさせるのが難しい ⚫ 次世代になかなかバトンタッチできず, 手離れが悪い

5 ソフトウェアアーキテクトとは フューチャーのアーキテクトに求められるものは「幅広い」が, 本日はその1歩目を踏み出す人を育てたいという話 プログラマ / システムエンジニア ソフトウェアアーキテクト 機能要件を意識した機能単位の設計・開発 モバイル / Web / バックエンドなど技術領域によってチーム が分かれることも 機能要件 + 非機能要件を意識した システム全体の構造設計 提案 グランド デザイン 要件定義 チーム マネジメント 顧客折衝/ プレゼン 教育・育成 … このあたりがターゲット

6 アーキテクトに求められるのは技術の幅 既知 （わかっていること） 既知の未知 （わかっていないとわかっていること） 未知の未知 （わかっていないとわかっていないこと） アーキテクトであれば、ある問題に対して5つのソリューションがあるとわかっているほうが、 そのうちの1つの専門家であることよりも有益だ Mark Richards, Neal Ford (著), 島田 浩二 (翻訳) ソフトウェアアーキテクチャの基礎 技術の幅 技術の 深さ 知識のピラミッド 例. データベースの選定を行っているAさん 以前RDBを採用したアプリケーション開発を行っており, データのモデリングやSQLを用いたデータ操作はお手の物 RDBではなくNoSQLデータベースと言われるものは 結果整合性という考え方に基づいてデータ処理をするらしい けどよくわからないなぁ 世の中には、RDBとNoSQLの特性を合わせ持つNewSQLもある Aさんがその存在を知るのは、もうちょっと先のお話 ・・・・・ ・・・・・ ・・・・・

7 教育で意識するのは「未知の未知」 既知 （わかっていること） 既知の未知 （わかっていないとわかっていること） 未知の未知 （わかっていないとわかっていないこと） 技術の幅 技術の 深さ 技術の「幅を広げる」とは「未知の未知」を「既知の未知」に変えることであ り,このプロセスをいかに上手に支援できるかがポイント 既知の未知 ⚫ 調べることができる = 既知への変換が容易 ⚫ 能動的な学習が重要（Pull型） ⚫ この領域が広い人は, やる気があれば勝手に育つ 未知の未知 ⚫ 調べることができない = 既知への変換が困難 ⚫ 有識者による情報提供が重要（Push型） ⚫ この領域が広い人は, やる気があっても伸び悩む 「未知の未知」を「既知の未知」へ 知識のピラミッド

8 教育のための2つの取り組み そもそも誰かの「未知の未知」を認識するのは難しいが,なるべく効果的に 「気付き」を与えたい アーキテクティング の実践演習 そもそもアーキテクティングとは, 何をどのようにやるのかを知る アーキテクティングを行う上で, 自分に足りてないスキルを知る アーキテクト・ロードマップ の整理

9 アーキテクティングの実践演習 お題（RFP）に対してアーキテクチャを考えるワークショップ Inspired by "Architectural Katas" ⚫ 人数: • 顧客役モデレータ: 1名 • アーキテクト : 3~4名程度 * 2~3チーム ⚫ 時間: 1時間半程度 ⚫ お題: • Architectural Katas • 社内事例 ⚫ 進め方: • 参加者募集 & チーム決め（事前） • お題発表 • 顧客役のモデレーターへの質問（要件の掘り下げ） • 解決策の発散と収束 • プレゼン & 質疑応答 • フィードバック 参加のハードルが上がらないよう, 開催時間や事 前準備は極力ライトにする（継続させる） 全チーム同じお題に取り組むことで, 他チームか らも学びを得る お題はいくつかのレベルを用意する • 既存アーキテクチャの課題改善 （要件明確系） • 新規アーキテクチャ （要件ふわっと系） HowよりもWhyを重視する アウトプットとしての成果物は縛りすぎない

10 Architectural Katas（参考） https://www.architecturalkatas.com/ 地元のコミュニティ・カレッジが新しい会計システムを求めている。 予想されるユーザー： 1000人以上のユーザー、教職員、ほとんどは地元のユーザー（ただし、全国または海外のユーザーもいる） 制約：ウェブアプリなし（学長はウェブが嫌い）、最小限のソフトウェア コスト要件：大学の会計ワークフローを強制しつつも、各部門のニーズに合わせてワークフローを変更できるようにする。 コンサートチケット販売サイトでは、チケット販売に弾力性のあるソリューションが必要 ユーザー: 1000人の同時ユーザー、チケット販売開始時には最大10,000人/秒のバースト 要件: チケットの同時購入を許可座席を複数回販売しない。 買い物客は残席の概要を見ることができる。 追加コンテキスト： スペースベースとマイクロサービスの両方のアーキテクチャスタイルでの実装を検討する。 各ソリューションのトレードオフを特定する。

11 アーキテクト・ロードマップの整備 ソフトウェアアーキテクトに必要なテクニカルスキルのロードマップ Inspired by "roadmap.sh" ソフトウェアアーキテクトに求められるスキル の全体像・キーワードをまずは知る 書籍・技術ブログ・学習コンテンツ等の紐づけ を行う 複数人でメンテナブルなものにし、 定期的にアップデートを行う テクニカルスキルと同じぐらいソフトスキルが 重要だったりする

12 おわりに ⚫ 教育というテーマで語ると頭でっかちになりがちですが、当時の自分「あっ たらいいな」と思ったことから、まずは始めています。 ⚫ アーキテクト教育の実施状況や結果は, 継続的にパブリックに発信していき たいと思います。 ⚫ フューチャーで一緒にアーキテクト教育を考えてくださる方、 募集しています。一緒にやりましょう！

13 Thank You!