MAD事業部で実践しているモダンアプリケーション開発、ビジネスアジリティの面で非常に優れた手法であることはMAD事業部誰もが実感しているのですが、その習得と実践には、今までのアプリケーション開発の知識だけでは不十分です。 このセッションでは、あなたと組織がモダンアプリケーション開発を実践できることをゴールとした時に、どのようなラーニングバスが必要か？どのような学習が効率が良いのか？を、弊社メンバーの経験則を元に皆さんにお届けします。
あなたと組織がモダンアプリケーション開発を実践できるようになるまでの全過程2021/10/7CX事業本部 MAD事業部濱⽥孝治（ハマコー）
View Slide
2最初に質問
3「モダンアプリケーション開発を実践できるようになる」って⼀体どういうことでしょう︖
4こんなイメージでしょうか︖クラウドネィティブでコンテナがイベントドリブンでサーバーレスなマイクロサービスが疎結合で良い感じに分散処理しつつインフラが家畜でアプリケーションがおもむろにスケールしてみんなノリノリで働いている状態40代 男性 都内在住 AB型 ⼄⼥座
5こんなイメージでしょうか︖クラウドネィティブでコンテナがイベントドリブンでサーバーレスなマイクロサービスが疎結合で良い感じに分散処理しつつインフラが家畜でアプリケーションがおもむろにスケールしてみんなノリノリで働いている状態40代 男性 都内在住 AB型 ⼄⼥座良いと思います︕︕
6現場は千差万別みなさんなりの理想像を思い浮かべていただきながらこのあとの話を聞いてもらえれば幸いです
7⾃⼰紹介濱⽥孝治（ハマコー）• CX事業本部 MAD事業部⻑• Japan APN Ambassador 2020• JAWS-UG コンテナ⽀部運営• 好きなサービス︓ECS, EKS, CloudFormation• 好きな⾔葉「わっしょい」• @hamako9999
8アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて不可⽋なもの• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
9アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて不可⽋なもの• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
10本⽇のゴールの共有
11今⽇のタイトルあなたと組織がモダンアプリケーション開発を実践できるようになるまでの全過程
12分解して考えてみるあなたと組織がモダンアプリケーション開発を実践できるようになるまでの全過程
13分解して考えてみるあなたと組織エンジニアのスキルだけではなく組織としてのありかたも関係する
14分解して考えてみるモダンアプリケーション開発パブリッククラウドをベースとしたIT技術を使いビジネスに最⼤限の俊敏性と安定性をもたらし事業の差別化をもたらすことコンテナやサーバーレスは今の⼿段の⼀つにすぎない
15分解して考えてみる実践できるようになる⼀度技術的なキャッチアップをするだけではなく技術⼒の改善、ビジネス環境への変化に将来に渡って対応し続ける
16本⽇の趣旨、そして弊社がお伝えできることサーバーレス／コンテナと⼀⼝に⾔ってもその技術領域は膨⼤、かつ情報⾃体も溢れているクラスメソッドのMAD事業部で、実際に様々な顧客のご⽀援をするなかで感じた体験を元に、組織としてこれら技術領域に取り組む際の勘所をご紹介します。そのなかから、皆さんなりの実践やチャレンジを是⾮感じ取ってもらいたいと思っています。
17アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて不可⽋なもの• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
18MAD事業部とは
19MAD事業部の経緯• クラスメソッド株式会社 CX事業本部• 2020年7⽉• MADチームとして開始• ⼈員は12名• 2021年7⽉• MAD事業部に変更• ⼈員は12名 → 30名に• MAD領域を専⾨とするエンジニアと内製化⽀援チーム（別途ご紹介）がジョイン
20
21MAD（Modern Application Development）
22MAD（Modern Application Development）AWSサービス︓AmazonDynamoDB、Amazon APIGateway、AWS IoT、AWSStep Functions、AWSAmplify、AWS AppSync、AWS Glue、Amazon Kinesis、Amazon AthenaGoogle Cloudサービス︓Cloud Firestore、Cloud SQL、Cloud Pub/SubInfrastructure as Code︓AWS CDK、AWSCloudFormation、AWS SAM、Serverless Framework、TerraformCI/CD︓Codeシリーズ、CircleCI、GitHub Actions
23MAD（Modern Application Development）
24MAD（Modern Application Development）・迅速な開発・素早いフィードバック・コントローラブル
25実際やろうとすると悩みは深い
26MAD事業部の存在意義MAD事業部の存在意義︓特定の技術領域に特化し、多数のお客様を⽀援している中で得られた経験値と感触を組織として蓄積していること• 「このお客様にはこれがハマった」• 「あの技術はイマイチかなぁ」• 「これよさそうだけど、まだまだ安定性が疑問で本番導⼊はあかんな」
27強い組織になるまでモダンな開発技術をビジネス価値に直結できるゴールネットの情報・ウェビナー・ブログ・公式ページスタート多数の顧客を⽀援した実績と知⾒を是⾮活⽤いただきたい
28アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
29ビジネスゴールに向けて
30ビジネスゴールに向けて不可⽋なものビジネスゴール
31ビジネスゴールに向けて不可⽋なものビジネスゴールモダンアプリ開発の技術⼒
32ビジネスゴールに向けて不可⽋なものビジネスゴール良いエンジニア組織モダンアプリ開発の技術⼒
33ビジネスゴールに向けて不可⽋なものビジネスゴール良いエンジニア組織モダンアプリ開発の技術⼒
34良くないパターンビジネスゴール良くないエンジニア組織モダンアプリ開発の技術⼒
35良くないパターンビジネスゴール良くないエンジニア組織別の⾏き先遅延検討のみモダンアプリ開発の技術⼒
36たとえ個々のエンジニアの技術⼒が⼗分であったとしてもそれを組織として束ねてゴール向かうための組織⼒は必ず必要
37アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
38技術要素として重要なこと
39技術要素の趣旨技術要素は時代によって移り変わる前提で今のMAD事業部のスキルセットを中⼼に紹介します
40技術要素としてお話できること• MAD事業部エンジニアへのインタビュー• Kさん• Aさん• MAD事業部エンジニアに聞いた⾎⾁になったもの⼀覧• 各技術領域におけるMAD事業部としての所感
41インタビューエンジニアKさんの場合
42エンジニアKさんの場合• 前提• クラスメソッドのAWSインフラエンジニア、ソリューションアーキテクト、プリセールス• Cognito周辺を⼀部経験• コーディング経験は⼀切なし• 2019年7⽉• PythonでLambdaのコードを書き始める• 当初はPythonの⽂法をググりながら、周囲のエンジニアの助けを経てスキルアップ• 合わせてテストを書き始める• 主な関⼼事• Pythonを思い通りに書けるか• テストを書けるか• プロジェクトで採⽤されているライブラリを使えるか• SAMの利⽤（CloudFormationには慣れていたので、そこまで苦労はしなかった）
43エンジニアKさんの場合• 2020年2⽉• CDK• 案件前からプライベートで書いていた• このとき初めてTypeScriptを触る• サーバーサイドコーディング• TypeScriptでLambdaを書く• 設計全般• ⼀気にSW設計に⽬覚める（Clean Architecutere、ドメイン駆動設計）• DynamoDBの設計に⽬覚める（RDB経験は皆無）• Amazon DynamoDB deep dive:Advanced design patterns• いろんな⽂献を参考にしつつ、実際に⼿をかけて⾝体になじませていき理解していった
44エンジニアKさんの場合• 2020年4⽉• フロントエンド• Reactに⼿を染める• Appolo Client, Reactfor, Material UIなどを⾃分で検証して選定• StoryBookも体験• Auth0との連携も試してブログ化• TypeScriptでLambdaを書く• 学習• 公式ドキュメントは全部読んで、チュートリアルをやった• まずは全部読んだ。全部• サーバーサイドはGraphQL• GraphQLからAppSyncに⼿を出す• Amplifyコンソールを触りだしたのもこの頃• 2021年4⽉• gRPC, Go, Neptune• マイクロサービスの設計を強く意識しはじめる• マイクロサービスパターン• マイクロサービスアーキテクチャ
45エンジニアKさんが今を振り返って技術⼒を伸ばすときに意識していること• 簡単なサンプルアプリを、都度その時の⾃分の思想や試したい技術で実装して感触を確かめる• 本を読んで案件やってサンプルアプリを作って、というサイクルを回している
46エンジニアKさんが今を振り返ってやってよかったこと• ⼀回ぐらいOSSコントリビュートすると、達成感も出て気持ちも捗ると思う• 本を読む• ⼀つのプロジェクトで全員が全員設計するわけではない• 原理原則を1から学ぶには、本を読んでそれをインプットすると、既存のプロジェクトのコートの⾒え⽅が変わってくる。その疑問点を同僚とディスカッションすることで理解が深められる• そこまでくると、同僚と話すだけで知識がどんどんはいってくる• ベースの知識が無いと理解を積み上げるのが難しい
47インタビューエンジニアOさんの場合
48エンジニアOさんの場合• 前提• クラスメソッド機械学習チームへの配属• ひたすらSageMakerを試してブログを書いていた• API GW+Lambda（Python）、DynamoDB• Step Functions、Lambda（Python）、Glue → Fargate• S3 + Athena + Redash• 2020年4⽉ CX事業本部異動• アプリケーション実装⼒をがっつり伸ばしたかった• APIとバッチ処理の開発• ECS（EC2）、Spte Functions、Python、Autora（PostgreSQL）• 動かない単体テストがあり、それを参考に動かしつつ機能追加をしていった
49エンジニアOさんの場合• 2020年7⽉〜• ⼤きめの受託開発案件に要件定義から参画• 要件定義が何たるかを知った• 開発チームを牽引（バックエンドを中⼼に）• Pythonで書く想定だったが、引き継ぐ想定でクライアントと同じTypeScriptを利⽤• CDKはやりたかったから採⽤（YAMLを書きたくなかった）• TypeORMを採⽤• かなりむちゃだったが夜な夜な調べながら対応• 実装⼒アップのために競プロをはじめる（AtCoder）• ここでかなり⾃⼒がついた
50エンジニアOさんが今を振り返って資格をとる• AWSとGoogle Cloudの資格を全部とった• もともと知識がなかったので、薄く広く知るためには最強のツールだった• 本はあんまり読まなかった案件をゼロベースで担当する• ⾃分が考えて作っていくので、改めて深く考えるのと、顧客調整しながらやっていくので、責任感と相まってガッツリ成⻑できた
51MAD事業部エンジニアに聞いた⾎⾁になったもの⼀覧
52⾎⾁になったもの⼀覧⾎⾁になったもの 業務でどのように役⽴ったかClean Architecture 設計原則の⼀つとして押さえておくことが重要ドメイン駆動設計⼊⾨ 設計原則の⼀つとして押さえておくことが重要初めてのGraphQL GraphQLを始めるとき、何はなくとも⼀度やってみるWeb API The Good Parts REST APIの設計原則を学ぶのに最適リーダブルコード 読みやすいコードをどのように書けばよいか具体的なTipsを学べます。CPUの創りかたアジャイルサムライ アジャイル・スクラムの基礎知識が得られるITエンジニアのための機械学習理論⼊⾨機械学習の理論について体系⽴てて説明しており、かつ、同じテーマについて複数の⼿法を適⽤していてその違いを理解しやすいです。NOSQLの基礎知識若⼲古いですが、NOSQLについて俯瞰的な知識をサクッとつかめるのでおすすめです。NOSQLについて触れる際に最初に読んでおくとよいと考えます。データ指向アプリケーションデザイン最近読んでますけど、15年前にこの書籍があればよかったと読書会で毎回⾔ってるぐらい良い本ですｗ
53⾎⾁になったもの⼀覧⾎⾁になったもの 業務でどのように役⽴ったか強い先輩若い時に体系的に⾝に着けるべきものを絶妙なタイミングで教えてくれる。杉井が3年⽬までに教えてもらったこと・デザインパターンなどの「ベストプラクティス」という概念・UML（設計ドキュメントの正しい書き⽅）・JavaやってるんだったらJavaのコードを読め・データベースの基本的な仕組み（テーブル設計とかチューニングの基礎になった）・エンジニアは怠惰であれロジカル・シンキング (Bestsolution) ドキュメントの書き⽅とかコミュニケーションの取り⽅について学びました。Effective Java 読んだのは2版ですけど、⾮常によかったです。実装パターン薄いですけど、ほんとよくまとまっててよかったです。先⽇メルカリで7000円ぐらいで売れましたｗUNIXという考え⽅ 名著LPICレベル2 Linuxが触れるようになったプログラマが知るべき97のこと バージョン管理ツールの存在を知ったIPAの試験元々iTunesの使い⽅ぐらいしか知らずにIT業界に⼊ったが、XXスペシャリストを全部制覇する頃には⾊々トラブルシューティングとかまでできる⼒がついていた3Minutes NetWorking ネットワーク関連の基礎知識を学びました。
54⾎⾁になったもの⼀覧⾎⾁になったもの 業務でどのように役⽴ったかAWS公式ドキュメント まずはここを調べます。テスト駆動開発 友⼈と⼀緒にペアプロしながらやったのもあって勉強になった。エクストリームプログラミング 読んでないけど今では当たり前な(?)プラクティスが⾊々紹介されているAWS サービス別資料 知らないサービスを把握する際にまず⽬を通します。リファクタリング 読んでないけどリファクタリングについてサンプルコードを元に学べる計算機プログラムの構造と解釈 関数型の考え⽅について理解が深まった気がします。Qiita 検索するとよく引っかかります。Stack Overflow 同じく英語で検索するとよく引っかかります。達⼈プログラマー僕が読んだのは第1版で新社会⼈の頃でした。それまで感覚でやっていたことを体系的に⽰してもらったという印象でした。［Web開発者のための］⼤規模サービス技術⼊⾨AWSでシステムを構築する場合でも、結局負荷とは何なのかという感覚をつかんでいることは引き続き重要なのかなと思います。これは本当にオンプレでゲーム会社のサイトとか設計するときに読んでました。コミュニティ勉強会への参加知識が増えるだけじゃなく、技術の話ができる仲間が増え、その影響でまたイベント参加することが増えたり、、、と良い循環が回った気がする。楽しそうに仕事をしている⼈たちが存在することを知れた
55⾎⾁になったもの⼀覧⾎⾁になったもの 業務でどのように役⽴ったかアプレンティスシップ・パターンキャリアとかについて悩んでたときに読みます。ソフトウェアエンジニアの⾔語化できないモヤモヤに対するヒントになることが書いてありますオブジェクト指向でなぜ作るのか オブジェクト指向、UML、モデリングなどの基礎的な知識が学べましたAIエンジニアのための機械学習システムデザインパターンMLOps 開発における様々な practice が全体的に備えています。また、理論と実践が良いバランスで混ざっているのですぐ⼿元で試してみるのもできます。プログラミングの⼼理学20年くらい前に読んだ本で、その当時発刊後20以上経っていたような古い本ですが、パンチカードなどが使われていた時期にすでにアジャイルのようなスタイルの開発をしていた集団がいたというような話が書いてあって、プログラマーの⼼構え的なものを学べました。後に発刊された達⼈プログラマーでやっとこの本で⾒た内容が地に⾜がついた感じになったので、実践というより「読み物」かもしれませんが。エキスパートCプログラミング―知られざるCの深層内容もさることながら、コラムもマニアックで楽しくて、技術の無駄遣い全開なノリでプログラミングがいっそう楽しくなりました。C⾔語の理解がかなり深まるいい本でしたが、C⾔語を仕事で使ってなくても楽しめる技術の無駄遣い本です。技術で遊ぶことがさらに楽しくなりました。
56各技術領域の最近の所感
577⽉時点の情報はこちらにまとまっていますhttps://dev.classmethod.jp/articles/about-mad/
58コンピューティング環境• LambdaとFargateが半分半分ぐらい• コンテナに関しては、ECS on EC2はなし• EKSはEKS on EC2• LambdaでAuroraも複数有り（RDS Proxy）• がっつりどちらが良いとはきめきれないので、案件特性、ビジネス要件に応じて都度判断している
59⾔語• TypeScriptの採⽤が確実に増加傾向• フロントエンド（React）、サーバーサイド（Node.js）、インフラ（CDK）で⼀気通貫しての実装案件もあり• EKSはEKS on EC2• LambdaでAuroraも複数有り（RDS Proxy）• Pythonも現役• コンテナ周辺でGoも多い
60Infrastructure as Code• CDKが確実に増えている• CDKを使う場合は、必ずTypeScript• その他は群雄割拠• CloudFormation• Terraform• ServerlessFramework• ServerlessApplication Model
61CI/CD• GitHub Actionsが強い• ISSUE管理、リポジトリ管理、プルリクエストレビューなどと⼀貫した環境で作業できるのが⾮常に強い• AWSとの親和性も最強。このアップデートは衝撃（GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利⽤できるようになったようです）• GitLabもよく使われている• Codeシリーズはあんまり…• 開発フローを回すのに⾟い場合が多い
62アジェンダ• 本⽇のゴールの共有• MAD事業部とは• ビジネスゴールに向けて• 技術要素として重要な事• 組織として重要な事（アンチパターン集）
63組織として重要なこと
64はじまりますここから主観丸出しでございます
65アンチパターン集①ビジネス上のクリティカルな問題に新⼿法を使おうとする②全てを計画⽴ててそのとおりに進めようとする③ロールの違いを過剰に意識する④技術パートナーに丸投げする
66アンチパターン①ビジネス上のクリティカルな問題に新⼿法を使おうとする
67アンチパターン①サービス要件が⾮常に厳しいアプリケーションに慣れてない⼿法を適⽤しようとする• 社運をかけたプロジェクト• 1秒たりとも落とせないサービス• 新⼿法を取り⼊れるメリットを最⼤限活かすため
68アンチパターン①サービス要件が⾮常に厳しいアプリケーションに慣れてない⼿法を適⽤しようとする• 社運をかけたプロジェクト• 1秒たりとも落とせないサービス• 新⼿法を取り⼊れるメリットを最⼤限活かすため失敗できないが故にスピードが遅くなる• 計画段階で複数プロダクトのプロコンを作成• ⾮機能要件の全ケースと異常ケースを洗い上げ• 想定する全ての機能、⾮機能の検討が終わらない限り開発に着⼿できない
69アンチパターン①の解決策⼩さくてコケても問題ないものを対象にする
70アンチパターン①の解決策SLA、SLOが低いもので試してみる• 社内のちょっとした情報共有ツールやブログなど• 半⽇ぐらい落ちても影響ないものあたりを選定
71アンチパターン①の解決策SLA、SLOが低いもので試してみる• 社内のちょっとした情報共有ツールやブログなど• 半⽇ぐらい落ちても影響ないものあたりを選定運⽤することでノウハウの蓄積速度が早い• 設計だけでなく、実際に⼿を動かして開発、そして運⽤することで得られる知⾒はものすごく⼤きい• 特にトラブル発⽣時に得られる知⾒は貴重• たとえkubernetesの採⽤がオーバーエンジニアリングだとしても、あえてやってみる価値はある
72アンチパターン②すべてを計画だててそのとおりに進めようとする
73すべてを計画⽴ててそのとおりに進めようとする予算とスケジュールありきでプロジェクトを組む• 投⼊するエンジニアの⼈数と期間が決定済み• キャッシュアウトする部分の予算化のため計画ありきでスケジュールが組まれている• リスクを抑えたいがため事例クレクレおじさんが発⽣
74すべてを計画⽴ててそのとおりに進めようとする予算とスケジュールありきでプロジェクトを組む• 投⼊するエンジニアの⼈数と期間が決定済み• キャッシュアウトする部分の予算化のため計画ありきでスケジュールが組まれている• リスクを抑えたいがため事例クレクレおじさんが発⽣スケジュールが必達なため正常な意思決定ができない• 適切でない意思決定をしがち（リスクは低いがやたら⼿間はかかる運⽤ができあがる）• 特に運⽤しないとわからないものが多い
75アンチパターン②の解決策スコープを可能な限り⼩さくする
76スコープを可能な限り⼩さくするMVPの完成をゴールとする• 開発だけではなく、運⽤も評価できるようMVP（Minimum Viable Product）を設定• 期間は2週間〜最⻑1ヶ⽉程度• 実際に⼿を動かして評価することで、精度の⾼い意思決定が可能
77アンチパターン③ロールの違いを過剰に意識する
78ロールの違いを過剰に意識する最初にロールを作って、それに当てはまる作業を振り分けようとする• 「Dev」 vs 「Ops」• 「アプリ」 vs 「インフラ」• 「YAMLは誰が書くの︖」
79ロールの違いを過剰に意識する最初にロールを作って、それに当てはまる作業を振り分けようとする• 「Dev」 vs 「Ops」• 「アプリ」 vs 「インフラ」• 「YAMLは誰が書くの︖」モダンアプリケーションの開発や運⽤における考慮事項は多い• アプリケーション開発、構成管理、開発フロー整備、アプリケーションデプロイ、テスト、監視、トレーシング、セキュリティ、ロギング、ライブラリアップデート
80ロールの違いを過剰に意識するセクショナリズムが発⽣してチームパフォーマンスがでない• 「これあんたがやるのでは︖」• 「え、忙しいよ、そっちでしょ︖」• 「そもそもこんな作業想定してないし」
81アンチパターン③の解決策ゴールだけを⾒て役割分担する
82ゴールだけを⾒て役割分担するビジネスゴールクラウドネイティブ良いエンジニア組織実装や運⽤が必要な機能を都度考える
83従来のロールイメージApp1統⼀インフラ基盤HW保守アプリケーションエンジニアインフラエンジニアApp2 App3 App4
84モダンアプリケーション開発のロールイメージクラウドアプリよりエンジニアApp2 App3 App4App1インフラよりエンジニア
85ゴールだけを⾒て役割分担するやるべきことを都度ロールに分類することは無理• 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分類することは無意味
86ゴールだけを⾒て役割分担するやるべきことを都度ロールに分類することは無理• 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分類することは無意味マインドとして「落ちてるボールは拾いまくる」意識が重要• エンジニアリングとして成⻑できる機会、経験する機会をのがさない• 全ての問題が⾃分ごとに思えてくるぐらいが理想
87アンチパターン④技術パートナーへの丸投げ
88技術パートナーへの丸投げモダンアプリ開発のノウハウが⾜りない状態で全てを⾃分たちでやるのに時間がかかりすぎる場合、技術パートナーに頼るのは有⼒な選択肢ただ、その場合に注意しておく点が⼀つ
89技術パートナーへの丸投げモダンアプリ開発のノウハウが⾜りない状態で全てを⾃分たちでやるのに時間がかかりすぎる場合、技術パートナーに頼るのは有⼒な選択肢ただ、その場合に注意しておく点が⼀つ請負契約で当初決めたスコープをまるっと納品してもらうのは基本やめましょう
90技術パートナーへの丸投げ請負契約も⽬的に叶うのであればもちろん有効な⼿段しかし「モダンアプリケーション開発を実践する組織になる」「ビジネスに俊敏性をもたらす」「実装しながら最適解を探す」という⽬的には⾜かせになり、相性が⾮常に悪い
91アンチパターン④の解決策委任契約にしてスコープに柔軟性をもたせノウハウを最⼤限蓄積できるパートナーとタッグを組む
92タッグを組むという意識「お⾦の対価でシステムができあがる」よりは「お⾦の対価でノウハウを得る」関係性が理想• 可能であれば技術パートナーと1チームでスクラムなどで同じ⽬線と呼吸で開発をしながら、実践的なノウハウを得ていく進め⽅が良い• よい関係性を気づくことができれば、いろんなノウハウを惜しみなく吸収することができるチャンス︕
93MAD事業部のポリシーモダンな開発技術をビジネス価値に直結できるゴールネットの情報・ウェビナー・ブログ・公式ページスタート多数の顧客を⽀援した実績と知⾒を是⾮活⽤いただきたいノウハウの出し惜しみは⼀切しません
94組織観点ではこちらも是⾮ご検討をhttps://classmethod.jp/services/insource/
95まとめ
96まとめモダンアプリケーション開発のキモはビジネスアジリティ技術は時代によって変わっていく前提で常に学び続ける必要ありエンジニアの技術⼒は必要だが組織としてアンチパターンを踏み抜かないこと技術⼒はあっても組織の意思決定が良くないとゴールに向かうことが難しくなるうまく技術パートナーを頼ろう丸投げにせずノウハウを最⼤限吸収するつもりでウマが合うパートナーを探しましょう
97最後にみなさんの組織がビジネスアジリティを追求できるようになることを願っています
セッション後は、チャット欄のURL、または下記QRコードよりアンケートへのご協力をお願いいたします。SNS投稿にはこちらをお使いください：#devio2021https://forms.gle/8uD36XqYT42xbfEU816:20-16:50「あなたと組織がモダンアプリケーション開発を実践できるようになるまでの全過程」Q&A Q&A
hamadakoji
hakubishin3
nagapad
asei
microcms
skrb
hatahata021
miyake
cafenero_777
sakiengineer
y_iwai
globis_gdp
okada_fuutass
panda_program
paulrobertlloyd
quramy
lemiorhan
sonatard
bryan
tammielis
morganepeng
schacon
chrislema
wjessup
sachag