アーキテクトに求められるマインドとは / mindset for an architect

Transcript

1. アーキテクトに求められる マインドとは 2022-07-14 株式会社野村総合研究所 新井雅也 おすすめの技術書LT会 – vol.4
2. 新井 雅也 M a s a y a A R A I msy78 金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。 UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な守備範囲を持ちつつ、 クラウドを活用した全体のアーキテクチャ設計・開発が得意。 テックリード / エキスパートアーキテクト
3. u 便宜上、本発表では、ソフトウェアアーキテクチャや ソフトウェアアーキテクトのことを、 単にアーキテクチャ、アーキテクトとして表現しています。 u 「オライリー・ジャパン ソフトウェアアーキテクチャの基礎」にて 得られる知見をもとに、発表内容をまとめています。 発表の前提 https://www.oreilly.co.jp/books/9784873119823/
4. アーキテクトに求められるマインドとは
5. アーキテクトに求められるマインドとは そもそも、アーキテクトとは
6. （明確な定義やキャリアパスはないと言われているが） アーキテクトとは、適切な設計を選択し、 技術標準の枠組みを作る役割の担い手のこと
7. 🙋 「新米 ソフトウェア アーキテクト X氏」
8. 🙋 今の時代、クラウド使って マイクロサービスアーキテクチャで作るのが、 とりあえず最適だと思うのよね〜〜JK 「新米 ソフトウェア アーキテクト X氏」
9. 🙋 今の時代、クラウド使って マイクロサービスアーキテクチャで作るのが、 とりあえず最適だと思うのよね〜〜JK 「新米 ソフトウェア アーキテクト X氏」
10. 🙋 今の時代、クラウド使って マイクロサービスアーキテクチャで作るのが、 とりあえず最適だと思うのよね〜〜JK 「新米 ソフトウェア アーキテクト X氏」 なんて安直な思考に、 皆さんは陥っていないですよね ?????
11. そもそも、アーキテクチャとは、求められる or 達成したい ビジネス要件の文脈があって、初めて成立するもの u マイクロサービスアーキテクチャのメリットとデメリットは理解していますか？ u モノリス構成を含む、他のアーキテクチャは検討しましたか？ u マイクロサービスアーキテクチャが、ビジネス上のどのような課題を解決するのですか？ u 実際にコードを書くエンジニアやその他ステークホルダーと事前に共有しましたか？
12. 「Jastrow, J. (1899) “Fact and Fable in Psychology” https://commons.wikimedia.org/wiki/File:Duck-Rabbit_illusion.jpg」より引用 ものの見え方は、人の経験や状況によって左右されることと同じように、 アーキテクチャも解決したい課題によって左右される ウサギとアヒルの図形
13. つまり、アーキテクチャはすべてがトレードオフの世界である u「どうやって」よりも、「なぜ」のほうが本質 u「アーキテクチャとは、Googleで答えを見つけられないものだ 」 ※「オライリー・ジャパン ソフトウェアアーキテクチャの基礎」より引用
14. そもそも、アーキテクトとは
15. そもそも、アーキテクトとは アーキテクチャが持つトレードオフを理解しつつ、 自分たちのビジネス要件と照らし合わせて、 適切な設計を選択し、技術標準の枠組みを作る担い手
16. アーキテクトに求められるマインドとは そもそも、アーキテクトとは
17. アーキテクト アーキテクトに必要なマインドとは
18. アーキテクト 技術トレードオフを理解 ビジネス要件の理解 技術標準の枠組み アーキテクトに必要なマインドとは
19. アーキテクト 技術トレードオフを理解 ビジネス要件の理解 技術標準の枠組み → 多様な選択肢と洞察 → 要件は日々変化 → チームへの普及と理解 アーキテクトに必要なマインドとは
20. アーキテクト 技術トレードオフを理解 ビジネス要件の理解 技術標準の枠組み → 多様な選択肢と洞察 → 要件は日々変化 → チームへの普及と理解 変化への追随 技術的な リーダーシップ 学びの幅を広げる そのために・・・ そのために・・・ そのために・・・ アーキテクトに必要なマインドとは
21. 優れたアーキテクチャや技術を幅広くおさえる uアーキテクトでは、「技術的な深さ ＜ 技術的な幅」が重視される傾向 u トレードオフに対する感性が磨かれる u選択するために「知らないことについて知らない」ことを減らす u 単一の技術やプラットフォームに集中すると、そこが安全な避難場所になってしまう u 最新のトレンドを把握し続ける u 古い情報がまだ最先端であるという誤った感覚から脱出する
22. 優れたアーキテクチャや技術を幅広くおさえる アーキテクチャ特性を軸にメリデメを理解する 各アーキテクチャの代表例を知る u レイヤード u パイプライン u マイクロカーネル u サービスベース u イベント駆動 u スペースベース u オーケストレーション駆動 u マイクロサービス u 運用特性 e.g. 可用性、パフォーマンス、 スケーラビリティ、デプロイ容易性 u 構造特性 e.g. 拡張性、可搬性、メンテナンス性 アップグレード容易性 u 横断特性 e.g. 学習容易性、セキュリティ
23. 変化に追随するためにイテレーティブに取り組む uビジネス特性を理解し、決して最善のアーキテクチャを追求しない u あらゆるビジネス上の問題を解決しようとすると、 汎用的なソリューションになり、単に労力・コストを要する u少なくとも、最悪ではないアーキテクチャを狙う u ソフトウェアアーキテクチャは動的な性質を持つもの u 変更が容易であれば、最初から望ましいアーキテクチャを 正確に設計しなければならない、というプレッシャーも少なくなる The Only Complete Swiss Army Knife https://www.hammacher.com/product/ only-complete-swiss-army-knife
24. 技術的なリーダーシップを発揮する uビジネスと技術の両面の変化を捉え、翻訳し、チームをリードする Simon Brown氏： 私の場合、ソフトウェアアーキテクチャの役割はソフトウェアチームに技術的なリーダーシップ をもたらすことです。私はどんなソフトウェアプロジェクトにも、ある程度は事前の設計が必要 だと固く信じています。コツは「過不足なく」やることです。つまり、初期のハイレベルな構造 を作り、主要なリスクに対処し、チーム全員がともに取り組むべきビジョンを作ることです。 https://www.infoq.com/jp/news/2012/04/frustrated-architect/より⼀部引⽤
25. u開発チームが技術を選定できるように「ガイド」する uアーキテクチャの決定や設計指針の遵守を徹底する u ルールを逸脱すると、いずれ技術的負債へと変化する u「確証バイアス」に注意を払う u e.g. 「そのアーキテクチャの採用が、間違いなく正しいに違いない」と思い込み、 都合の良い情報のみを集めてしまう。 技術的なリーダーシップを発揮する
26. まとめ
27. アーキテクト 技術トレードオフを理解 ビジネス要件の理解 技術標準の枠組み → 多様な選択肢と洞察 → 要件は日々変化 → チームへの普及と理解 変化への追随 技術的な リーダーシップ 学びの幅を広げる そのために・・・ そのために・・・ そのために・・・ アーキテクトに必要なマインドとは
28. ビジネスの文脈がない アーキテクチャの選択は、 「マッチ棒で家を建てる」のと同じ
29. 🙋 ご清聴いただき、ありがとうございました。