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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide