Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 20201023 Builders Box 2nd Enterprise Architect
Similaire à 20201023 Builders Box 2nd Enterprise Architect (20)
Plus de kounan13
Dernier
Dernier (11)
20201023 Builders Box 2nd Enterprise Architect
- 1. 2020/10/23 NTT DATA Yuji Shono / 正野 勇嗣 Builders Box #2 エンタープライズアーキテクト ビジネスに貢献する技術目利きのための、アーキテクトとしての姿勢 1
- 2. About Me 技術畑中心だが、振れ幅の大きなキャリアを持つ技術目利き屋（アーキテクト） 2 ※6月まではR&Dと現場技術支援(アーキテクト)の業務に従事 R＆D 開発生産性向上のための開発フレームワークやツール開発 新規R＆Dの企画・技術目利き 現場 支援 大規模更改(金融系基幹系/官公庁系) トラブルシューティング Output 技術評論社さん/マイナビさん/大学非常勤 Likes MSA/MLOps/Kubernetes 正野 勇嗣 NTTデータ 戦略統括本部 グローバル戦略室
- 3. 背景1（ボトムアップ） 組織を動かす時のアーキテクトの悩み • こういう新しいテクノロジーを入れないといけないじゃないか • 理解されない。 • いつもアンテナ技術的なアンテナをはっている • 一歩前へ進むためには？ • 制約 • 技術制約はほぼない • 事業的な制約をエンジニアとして理解していないと、、 • 例えば「ケーパビリティ」 • 向上させない戦略なのかもしれない • （単なる不満になっているケースが多い） • 必要であれば、自ら提案して実施すれば良い 3 上司 あなた クラウドに組織として対応しないと 他社に遅れをとります それってどうやって 良さを証明するの？実績は？ セキュリティは？ （この手の話は大抵失敗するんだよ なぁ。オープン化の時も大変だった し） （新技術なんだから実績なんて当然 ないでしょ。証明はもっと無理）
- 4. 背景2（トップダウン） 組織を動かすCTOの悩み • あなたがCTOだったとして。 • CTOはおそらく強烈な成功体験を持った人。自らが担当者だった時に様々 提案して成し遂げてきた人。 • 成し遂げてきたことが、ボトムで同時多発的に起ってほしい。それを促す 手段は？ • 提案してこない、諦め・不満が先行 4
- 5. 今日のゴール ビジネス貢献のための「技術」の提案をできるようになる • 提案：組織を動かす • 上位と会話し、組織を動かしていく(2つ3つ上の目線） • 主任なら、、、：課長/部長 • 課長なら、、、：事業部長/役員 • 「エンタープライズアーキテクト」というHowを通じて、単 なるテッキーな人財ではなく、一歩先ゆくアーキテクトの ToBe像をお伝えできたら 5 役員 事業部長 部長 課長 課長代理 主任 勤務 目線
- 6. 目次 • アーキテクトが求められる時代 • アーキテクトに求められる要素 • 技術目利きの姿勢 6
- 9. 技術の変遷と複雑さの増大 フィージビリティとケーパビリティの確保（技術目利き）が求められる 9 Category Lv.1 Lv.2 Lv.3 Lv.4 Mode Legacy - - Digital Server MF Open Cloud Multi Cloud Client 静的 動的 アプリ Edge/IoT Process WF - Agile Scaled Agile Lang COBOL C Java Better Java Architecture Monolith - - MSA Monitor 中央集権的 - - 分散 Logic Algorithm - ML Deep Learning Ops 手動 CI CI/CD Chaos Engineering Sizing in advance - - auto scaling Reliability Operation - - auto healing Skill Set 業務屋/基盤屋 - - Full Stack & Business
- 10. 新旧様々な要素を適切に組み合わせる 現行システム、組織ケーパビリティと急激な変化、キャズム...etc 10 Category Lv.1 Lv.2 Lv.3 Lv.4 Mode Legacy - - Digital Server MF Open Cloud Multi Cloud Client 静的 動的 アプリ Edge/IoT Process WF - Agile Scaled Agile Lang COBOL C Java Better Java Architecture Monolith - - MSA Monitor 中央集権的 - - 分散 Logic Algorithm - ML Deep Learning Ops 手動 CI CI/CD Chaos Engineering Sizing in advance - - auto scaling Reliability Operation - - auto healing Skill Set 業務屋/基盤屋 - - Full Stack & Business クラウド ネイティブ レガシー オープン レガシー
- 13. つまり
- 14. アーキテクトの需要が高まっている
- 15. 3つの定義
- 16. EAの定義 エンタープライズアーキテクチャの4つの階層 • 企業全体を見渡してビジネス〜ITシステムを総合的に捉え 全体最適を志向するもの 16 TA(Technology Architecture) AA(Application Architecture) DA(Data Architecture) BA(Business Architecture) Dataモデル Business要件 Application機能 Technology基盤 Technologyは 要素の一つ
- 17. IPAの定義 ITアーキテクトのスキル領域(IPA ITスキル標準V3) 17 個別 アプリケーション アーキテクチャ 機能要件の定義、機能アーキテクチャ設計、機能アーキテクチャ実現可能性の 評価 インテグレーション アーキテクチャ 統合要件の定義、統合アーキテクチャ設計、統合アーキテクチャ実現可能性の 評価 インフラストラクチャ アーキテクチャ インフラストラクチャ要件(主に非機能要件)の定義、インフラストラクチャア ーキテクチャ設計、インフラストラクチャアーキテクチャ実現可能性の評価 共通 ●アーキテクチャ設計 ●設計技法 ●標準化と再利用 ●コンサルティング技法の 活用 ●知的資産管理活用●テクノロジ ●インダストリ(ビジネス) ●プロジェクト マネジメント ●リーダーシップ ●コミュニケーション ●ネゴシエーション https://www.ipa.go.jp/files/000024929.pdfIPA ITスキル標準V3：
- 20. つまり
- 22. そこで
- 24. 技術目利きの姿勢
- 25. ビジネス貢献のためのスタンス
- 26. 26 組織 市場やお客様からの要望が変動していく中、 新たなケーパビリティを獲得していく 戦略 どういう技術に着目するか いつから取り入れるか 仕組み R＆D、PoC、実戦投入のバランスと見極め
- 31. 基本スタンス アウトプット • 基本はアウトプットベース • どんなこまりごとにも真摯に対応する。 • 臨界点を超えると、いつしか、情報が集まってくるようになる • 基本動作にアウトプットは入っているか？ • 一般的に言われている「アンテナの高い」エンジニアはインプットは出来ている。 • 一方でアウトプットはどうか？ • コミュニティでの発表、技術記事、など＋αの活動はあるか 31
- 32. 基本スタンス 技術習得機会の意図的な創出 • 足りないスキルの部分を人に任せていないか？ • → できるようになったことは任せても良い、できないことは率先して経験する • 若手に機会を与えられているか？ • → 一番詳しいのは自分。みたいなことが常態化していないか？ • 近視眼的になっていないか？ • → 今ある技術、出来る技術のみで日々の業務を過ごしていないか？ • → 1プロジェクトで1チャレンジは入れる（一方で攻めすぎない） 32
- 33. 基本スタンス スキルポートフォリオを戦略的に • どんな価値を作りたいか（出口戦略） • 事業の将来像を踏まえ、キャリアのToBeやマイル ストンを描けているか • そのために得ておくべきスキルや経験は？ • 右記の活動を通して技術習得 33
- 34. 終わりに • アーキテクトに求められる知識やスキルはかなり幅広い（IPAなど） • デジタルの時代に間違いなく求められる • 技術の目利きという視点で上位に対する提案を日常的に考えていく • 画一的なスタイルはない • これをやればOKという銀の弾丸もない 34
- 35. For more... • https://japan.zdnet.com/article/35159174/ • 日本の“IT巨人”NTTデータはどう変わる？ • 枯れた技術や尖った技術の調和を生み出す「技術の目利き」の信念 35
- 36. ご清聴ありがとうございました
- 37. 事例からの気づき
- 38. 案件A 非機能（性能チューニング）：1億件データへの挑戦 • 1000万件の壁（ハードウェア性能による「ごまかし」が効かず、性能リスクが高まる経験的な閾値） • パーティションでの絞り込み（パーティションプルーニング）が効かないと、SQLが長時間化 • システムテスト工程でパーティションキーを変更 38 Partition A 1-1000 Partition B 1001-2000 Partition C 2001-3000
- 39. 案件B 自動化（ビルド）：アーリーアダプタ • 周囲の理解 • CI？何それ美味しいの？ • という時代にMavenを採用 • 安定性 • Mavenプラグインが多くのバグがあった時代 • 開発期間中に最新版を何度も適用したり、ワークアラウンド職人的な設定 39
- 42. 案件E 超大規模（MF・金融機関系）：全体システム構成の俯瞰 • 1000+人 • 100+億円 • 10+サブシステム、100+機能、1000+処理 42 全体を俯瞰するのは不可能？ 処理方式パターン化による俯瞰 • トラブルシューティング • テスト計画（品質保証ストーリー） • システム俯瞰図（静的）の補足
- 43. 参考：処理方式パターン • 処理ルート＋実行方式： 43 サーバA サーバB サーバC非同期 同期 処理方式の例： 処理ルート 実行方式
- 44. 案件F 短納期と不確実性：AgilityとVelocity • プロジェクトマネジメント手法の昇華 • Agilityの確保 • テストを書き、ビルド・リリースを自動化 • GitHubFlow / ChatOps / テキストベース設計 • 継続的なリファクタリング • Velocityを計測 • 業務仕様を固めていくフェーズ（いわゆるパイロット・PoC） • 類似性の高い業務のVelocityを把握、再利用・ラーニングカーブ等による生産性向上 44
- 45. 提案のジャンル
- 47. 技術的制約 • 制約やできないことばかり話をしていないか • 変えるための提案できるか • なぜそこまで高めないと行けないのか、説明できるか 47
- 48. EAの定義や歴史
- 49. 技術か技術以外か エンタープライズアーキテクト 1. ビジネスケイパビリティを最適化せよ 2. 顧客の痛点から価値を考えよ 3. オープンイノベーションを進めよ 4. 経営戦略を検証せよ など 49 https://xtech.nikkei.com/atcl/nxt/mag/nc/18/020900021/06030003
- 50. EAの歴史 シンボリックな書籍の存在 • 1987年にJohn A. Bachman氏が提唱 （通称ザックマンフレームワーク） • 2000年代に注目を浴びる • 2005/4/21出版 マーティンファウラー氏の 「Pattern of Enterprise Application Architecture」 50https://www.amazon.co.jp/エンタープライズ-アプリケーションアーキテクチャパターン-Object-Oriented-SELECTION/dp/47
- 51. 基本スタンス 小さなことを続ける（最低3年、できれば10年） • 臨界点を超えるまでやる • 日々のタスク • 小さな事を続ける • どんなこまりごとにも真摯に対応する。 • →プロジェクトでの信頼を得る • 長期的な付き合いに → 新たなプロジェクトで呼んでもらえる • 文字を書く。（アウトプット） • →書籍、講演、CDOからの相談 51
- 52. QCD • Q • 性能問題が発生し、SQLの全数再検証 • 某ソフトウェアのバグを踏み全機能が動作しない • C • コモディディ化した技術に対するIT投資の圧縮 • D • 短納期の中で生産性との戦い 52