Upgrade to Pro — share decks privately, control downloads, hide ads and more …

未知の未知を既知の未知へ / Unknown unknowns to Known unknowns

未知の未知を既知の未知へ / Unknown unknowns to Known unknowns

https://future.connpass.com/event/318520/
FUTURE TECH TALK #1
ボトムアップで考えるアーキテクト教育Lunchセッション会
2024.06.05(Wed)12:00–13:00

Hiroki Takeda

June 05, 2024
Tweet

More Decks by Hiroki Takeda

Other Decks in Technology

Transcript

  1. 1 未知の未知を既知の未知へ Unknown unknowns to Known unknowns FUTURE TECH TALK

    #1 ボトムアップで考えるアーキテクト教育Lunchセッション会 2024.06.05(Wed)12:00–13:00
  2. 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. 5 ソフトウェアアーキテクトとは フューチャーのアーキテクトに求められるものは「幅広い」が, 本日はその1歩目を踏み出す人を育てたいという話 プログラマ / システムエンジニア ソフトウェアアーキテクト 機能要件を意識した機能単位の設計・開発 モバイル

    / Web / バックエンドなど技術領域によってチーム が分かれることも 機能要件 + 非機能要件を意識した システム全体の構造設計 提案 グランド デザイン 要件定義 チーム マネジメント 顧客折衝/ プレゼン 教育・育成 … このあたりがターゲット
  4. 6 アーキテクトに求められるのは技術の幅 既知 (わかっていること) 既知の未知 (わかっていないとわかっていること) 未知の未知 (わかっていないとわかっていないこと) アーキテクトであれば、ある問題に対して5つのソリューションがあるとわかっているほうが、 そのうちの1つの専門家であることよりも有益だ

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

    深さ 技術の「幅を広げる」とは「未知の未知」を「既知の未知」に変えることであ り,このプロセスをいかに上手に支援できるかがポイント 既知の未知 ⚫ 調べることができる = 既知への変換が容易 ⚫ 能動的な学習が重要(Pull型) ⚫ この領域が広い人は, やる気があれば勝手に育つ 未知の未知 ⚫ 調べることができない = 既知への変換が困難 ⚫ 有識者による情報提供が重要(Push型) ⚫ この領域が広い人は, やる気があっても伸び悩む 「未知の未知」を「既知の未知」へ 知識のピラミッド
  6. 9 アーキテクティングの実践演習 お題(RFP)に対してアーキテクチャを考えるワークショップ Inspired by "Architectural Katas" ⚫ 人数: •

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