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

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

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

iselegant

July 14, 2022
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

  1. アーキテクトに求められる
    マインドとは
    2022-07-14
    株式会社野村総合研究所
    新井雅也
    おすすめの技術書LT会 – vol.4

    View Slide

  2. 新井 雅也
    M a s a y a A R A I
    msy78
    金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。
    UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な守備範囲を持ちつつ、
    クラウドを活用した全体のアーキテクチャ設計・開発が得意。
    テックリード / エキスパートアーキテクト

    View Slide

  3. u 便宜上、本発表では、ソフトウェアアーキテクチャや
    ソフトウェアアーキテクトのことを、
    単にアーキテクチャ、アーキテクトとして表現しています。
    u 「オライリー・ジャパン ソフトウェアアーキテクチャの基礎」にて
    得られる知見をもとに、発表内容をまとめています。
    発表の前提
    https://www.oreilly.co.jp/books/9784873119823/

    View Slide

  4. アーキテクトに求められるマインドとは

    View Slide

  5. アーキテクトに求められるマインドとは
    そもそも、アーキテクトとは

    View Slide

  6. (明確な定義やキャリアパスはないと言われているが)
    アーキテクトとは、適切な設計を選択し、
    技術標準の枠組みを作る役割の担い手のこと

    View Slide

  7. 🙋
    「新米 ソフトウェア
    アーキテクト X氏」

    View Slide

  8. 🙋 今の時代、クラウド使って
    マイクロサービスアーキテクチャで作るのが、
    とりあえず最適だと思うのよね〜〜JK
    「新米 ソフトウェア
    アーキテクト X氏」

    View Slide

  9. 🙋 今の時代、クラウド使って
    マイクロサービスアーキテクチャで作るのが、
    とりあえず最適だと思うのよね〜〜JK
    「新米 ソフトウェア
    アーキテクト X氏」

    View Slide

  10. 🙋 今の時代、クラウド使って
    マイクロサービスアーキテクチャで作るのが、
    とりあえず最適だと思うのよね〜〜JK
    「新米 ソフトウェア
    アーキテクト X氏」
    なんて安直な思考に、
    皆さんは陥っていないですよね ?????

    View Slide

  11. そもそも、アーキテクチャとは、求められる or 達成したい
    ビジネス要件の文脈があって、初めて成立するもの
    u マイクロサービスアーキテクチャのメリットとデメリットは理解していますか?
    u モノリス構成を含む、他のアーキテクチャは検討しましたか?
    u マイクロサービスアーキテクチャが、ビジネス上のどのような課題を解決するのですか?
    u 実際にコードを書くエンジニアやその他ステークホルダーと事前に共有しましたか?

    View Slide

  12. 「Jastrow, J. (1899) “Fact and Fable in Psychology” https://commons.wikimedia.org/wiki/File:Duck-Rabbit_illusion.jpg」より引用
    ものの見え方は、人の経験や状況によって左右されることと同じように、
    アーキテクチャも解決したい課題によって左右される
    ウサギとアヒルの図形

    View Slide

  13. つまり、アーキテクチャはすべてがトレードオフの世界である
    u「どうやって」よりも、「なぜ」のほうが本質
    u「アーキテクチャとは、Googleで答えを見つけられないものだ 」
    ※「オライリー・ジャパン ソフトウェアアーキテクチャの基礎」より引用

    View Slide

  14. そもそも、アーキテクトとは

    View Slide

  15. そもそも、アーキテクトとは
    アーキテクチャが持つトレードオフを理解しつつ、
    自分たちのビジネス要件と照らし合わせて、
    適切な設計を選択し、技術標準の枠組みを作る担い手

    View Slide

  16. アーキテクトに求められるマインドとは
    そもそも、アーキテクトとは

    View Slide

  17. アーキテクト
    アーキテクトに必要なマインドとは

    View Slide

  18. アーキテクト
    技術トレードオフを理解
    ビジネス要件の理解
    技術標準の枠組み
    アーキテクトに必要なマインドとは

    View Slide

  19. アーキテクト
    技術トレードオフを理解
    ビジネス要件の理解
    技術標準の枠組み
    → 多様な選択肢と洞察
    → 要件は日々変化
    → チームへの普及と理解
    アーキテクトに必要なマインドとは

    View Slide

  20. アーキテクト
    技術トレードオフを理解
    ビジネス要件の理解
    技術標準の枠組み
    → 多様な選択肢と洞察
    → 要件は日々変化
    → チームへの普及と理解
    変化への追随
    技術的な
    リーダーシップ
    学びの幅を広げる
    そのために・・・
    そのために・・・
    そのために・・・
    アーキテクトに必要なマインドとは

    View Slide

  21. 優れたアーキテクチャや技術を幅広くおさえる
    uアーキテクトでは、「技術的な深さ < 技術的な幅」が重視される傾向
    u トレードオフに対する感性が磨かれる
    u選択するために「知らないことについて知らない」ことを減らす
    u 単一の技術やプラットフォームに集中すると、そこが安全な避難場所になってしまう
    u 最新のトレンドを把握し続ける
    u 古い情報がまだ最先端であるという誤った感覚から脱出する

    View Slide

  22. 優れたアーキテクチャや技術を幅広くおさえる
    アーキテクチャ特性を軸にメリデメを理解する
    各アーキテクチャの代表例を知る
    u レイヤード
    u パイプライン
    u マイクロカーネル
    u サービスベース
    u イベント駆動
    u スペースベース
    u オーケストレーション駆動
    u マイクロサービス
    u 運用特性
    e.g. 可用性、パフォーマンス、
    スケーラビリティ、デプロイ容易性
    u 構造特性
    e.g. 拡張性、可搬性、メンテナンス性
    アップグレード容易性
    u 横断特性
    e.g. 学習容易性、セキュリティ

    View Slide

  23. 変化に追随するためにイテレーティブに取り組む
    uビジネス特性を理解し、決して最善のアーキテクチャを追求しない
    u あらゆるビジネス上の問題を解決しようとすると、
    汎用的なソリューションになり、単に労力・コストを要する
    u少なくとも、最悪ではないアーキテクチャを狙う
    u ソフトウェアアーキテクチャは動的な性質を持つもの
    u 変更が容易であれば、最初から望ましいアーキテクチャを
    正確に設計しなければならない、というプレッシャーも少なくなる
    The Only Complete Swiss Army Knife
    https://www.hammacher.com/product/
    only-complete-swiss-army-knife

    View Slide

  24. 技術的なリーダーシップを発揮する
    uビジネスと技術の両面の変化を捉え、翻訳し、チームをリードする
    Simon Brown氏:
    私の場合、ソフトウェアアーキテクチャの役割はソフトウェアチームに技術的なリーダーシップ
    をもたらすことです。私はどんなソフトウェアプロジェクトにも、ある程度は事前の設計が必要
    だと固く信じています。コツは「過不足なく」やることです。つまり、初期のハイレベルな構造
    を作り、主要なリスクに対処し、チーム全員がともに取り組むべきビジョンを作ることです。
    https://www.infoq.com/jp/news/2012/04/frustrated-architect/より⼀部引⽤

    View Slide

  25. u開発チームが技術を選定できるように「ガイド」する
    uアーキテクチャの決定や設計指針の遵守を徹底する
    u ルールを逸脱すると、いずれ技術的負債へと変化する
    u「確証バイアス」に注意を払う
    u e.g. 「そのアーキテクチャの採用が、間違いなく正しいに違いない」と思い込み、
    都合の良い情報のみを集めてしまう。
    技術的なリーダーシップを発揮する

    View Slide

  26. まとめ

    View Slide

  27. アーキテクト
    技術トレードオフを理解
    ビジネス要件の理解
    技術標準の枠組み
    → 多様な選択肢と洞察
    → 要件は日々変化
    → チームへの普及と理解
    変化への追随
    技術的な
    リーダーシップ
    学びの幅を広げる
    そのために・・・
    そのために・・・
    そのために・・・
    アーキテクトに必要なマインドとは

    View Slide

  28. ビジネスの文脈がない
    アーキテクチャの選択は、
    「マッチ棒で家を建てる」のと同じ

    View Slide

  29. 🙋 ご清聴いただき、ありがとうございました。

    View Slide