あなたと組織がモダンアプリケーション開発を実践できるようになるまでの全過程

MAD事業部で実践しているモダンアプリケーション開発、ビジネスアジリティの面で非常に優れた手法であることはMAD事業部誰もが実感しているのですが、その習得と実践には、今までのアプリケーション開発の知識だけでは不十分です。 このセッションでは、あなたと組織がモダンアプリケーション開発を実践できることをゴールとした時に、どのようなラーニングバスが必要か？どのような学習が効率が良いのか？を、弊社メンバーの経験則を元に皆さんにお届けします。

Transcript

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