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

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

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

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

濱田孝治

October 07, 2021
Tweet

More Decks by 濱田孝治

Other Decks in Technology

Transcript

  1. あなたと組織が
    モダンアプリケーション開発を
    実践できるようになるまでの全過程
    2021/10/7
    CX事業本部 MAD事業部
    濱⽥孝治(ハマコー)

    View full-size slide

  2. 2
    最初に質問

    View full-size slide

  3. 3
    「モダンアプリケーション開発を
    実践できるようになる」って
    ⼀体どういうことでしょう︖

    View full-size slide

  4. 4
    こんなイメージでしょうか︖
    クラウドネィティブでコンテナがイベントド
    リブンでサーバーレスなマイクロサービスが
    疎結合で良い感じに分散処理しつつインフラ
    が家畜でアプリケーションがおもむろにス
    ケールしてみんなノリノリで働いている状態
    40代 男性 都内在住 AB型 ⼄⼥座

    View full-size slide

  5. 5
    こんなイメージでしょうか︖
    クラウドネィティブでコンテナがイベントド
    リブンでサーバーレスなマイクロサービスが
    疎結合で良い感じに分散処理しつつインフラ
    が家畜でアプリケーションがおもむろにス
    ケールしてみんなノリノリで働いている状態
    40代 男性 都内在住 AB型 ⼄⼥座
    良いと思います︕︕

    View full-size slide

  6. 6
    現場は千差万別
    みなさんなりの理想像を
    思い浮かべていただきながら
    このあとの話を聞いてもらえれば幸いです

    View full-size slide

  7. 7
    ⾃⼰紹介
    濱⽥孝治(ハマコー)
    • CX事業本部 MAD事業部⻑
    • Japan APN Ambassador 2020
    • JAWS-UG コンテナ⽀部運営
    • 好きなサービス︓ECS, EKS, CloudFormation
    • 好きな⾔葉「わっしょい」
    • @hamako9999

    View full-size slide

  8. 8
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて不可⽋なもの
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  9. 9
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて不可⽋なもの
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  10. 10
    本⽇のゴールの共有

    View full-size slide

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

    View full-size slide

  12. 12
    分解して考えてみる
    あなたと組織が
    モダンアプリケーション開発を
    実践できるようになるまでの
    全過程

    View full-size slide

  13. 13
    分解して考えてみる
    あなたと組織
    エンジニアのスキルだけではなく
    組織としてのありかたも関係する

    View full-size slide

  14. 14
    分解して考えてみる
    モダンアプリケーション開発
    パブリッククラウドをベースとしたIT技術を使い
    ビジネスに最⼤限の俊敏性と安定性をもたらし
    事業の差別化をもたらすこと
    コンテナやサーバーレスは今の⼿段の⼀つにすぎない

    View full-size slide

  15. 15
    分解して考えてみる
    実践できるようになる
    ⼀度技術的なキャッチアップをするだけではなく
    技術⼒の改善、ビジネス環境への変化に
    将来に渡って対応し続ける

    View full-size slide

  16. 16
    本⽇の趣旨、そして弊社がお伝えできること
    サーバーレス/コンテナと⼀⼝に⾔ってもその技術領域
    は膨⼤、かつ情報⾃体も溢れている
    クラスメソッドのMAD事業部で、実際に様々な顧客の
    ご⽀援をするなかで感じた体験を元に、組織としてこれ
    ら技術領域に取り組む際の勘所をご紹介します。
    そのなかから、皆さんなりの実践やチャレンジを是⾮感
    じ取ってもらいたいと思っています。

    View full-size slide

  17. 17
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて不可⽋なもの
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  18. 18
    MAD事業部とは

    View full-size slide

  19. 19
    MAD事業部の経緯
    • クラスメソッド株式会社 CX事業本部
    • 2020年7⽉
    • MADチームとして開始
    • ⼈員は12名
    • 2021年7⽉
    • MAD事業部に変更
    • ⼈員は12名 → 30名に
    • MAD領域を専⾨とするエンジニアと内製化⽀援チーム
    (別途ご紹介)がジョイン

    View full-size slide

  20. 21
    MAD(Modern Application Development)

    View full-size slide

  21. 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

    View full-size slide

  22. 23
    MAD(Modern Application Development)

    View full-size slide

  23. 24
    MAD(Modern Application Development)
    ・迅速な開発
    ・素早いフィードバック
    ・コントローラブル

    View full-size slide

  24. 25
    実際やろうとすると悩みは深い

    View full-size slide

  25. 26
    MAD事業部の存在意義
    MAD事業部の存在意義︓特定の技術領域に特化し、多数のお
    客様を⽀援している中で得られた経験値と感触を組織として蓄
    積していること
    • 「このお客様にはこれがハマった」
    • 「あの技術はイマイチかなぁ」
    • 「これよさそうだけど、まだまだ安定性が疑問で本番導⼊は
    あかんな」

    View full-size slide

  26. 27
    強い組織になるまで
    モダンな開発技術
    をビジネス価値に
    直結できる
    ゴール
    ネットの情報
    ・ウェビナー
    ・ブログ
    ・公式ページ
    スタート
    多数の顧客を⽀援した実績と
    知⾒を是⾮活⽤いただきたい

    View full-size slide

  27. 28
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  28. 29
    ビジネスゴールに向けて

    View full-size slide

  29. 30
    ビジネスゴールに向けて不可⽋なもの
    ビジネスゴール

    View full-size slide

  30. 31
    ビジネスゴールに向けて不可⽋なもの
    ビジネスゴール
    モダンアプリ
    開発の技術⼒

    View full-size slide

  31. 32
    ビジネスゴールに向けて不可⽋なもの
    ビジネスゴール
    良いエンジニア組織
    モダンアプリ
    開発の技術⼒

    View full-size slide

  32. 33
    ビジネスゴールに向けて不可⽋なもの
    ビジネスゴール
    良いエンジニア組織
    モダンアプリ
    開発の技術⼒

    View full-size slide

  33. 34
    良くないパターン
    ビジネスゴール
    良くない
    エンジニア組織
    モダンアプリ
    開発の技術⼒

    View full-size slide

  34. 35
    良くないパターン
    ビジネスゴール
    良くない
    エンジニア組織
    別の
    ⾏き先
    遅延
    検討のみ
    モダンアプリ
    開発の技術⼒

    View full-size slide

  35. 36
    たとえ個々のエンジニアの技術⼒が
    ⼗分であったとしても
    それを組織として束ねて
    ゴール向かうための組織⼒は必ず必要

    View full-size slide

  36. 37
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  37. 38
    技術要素として
    重要なこと

    View full-size slide

  38. 39
    技術要素の趣旨
    技術要素は時代によって移り変わる前提で
    今のMAD事業部の
    スキルセットを中⼼に紹介します

    View full-size slide

  39. 40
    技術要素としてお話できること
    • MAD事業部エンジニアへのインタビュー
    • Kさん
    • Aさん
    • MAD事業部エンジニアに聞いた⾎⾁になったもの⼀

    • 各技術領域におけるMAD事業部としての所感

    View full-size slide

  40. 41
    インタビュー
    エンジニアKさんの場合

    View full-size slide

  41. 42
    エンジニアKさんの場合
    • 前提
    • クラスメソッドのAWSインフラエンジニア、ソリューションアーキテクト、プリセールス
    • Cognito周辺を⼀部経験
    • コーディング経験は⼀切なし
    • 2019年7⽉
    • PythonでLambdaのコードを書き始める
    • 当初はPythonの⽂法をググりながら、周囲のエンジニアの助けを経てスキルアップ
    • 合わせてテストを書き始める
    • 主な関⼼事
    • Pythonを思い通りに書けるか
    • テストを書けるか
    • プロジェクトで採⽤されているライブラリを使えるか
    • SAMの利⽤(CloudFormationには慣れていたので、そこまで苦労はしなかった)

    View full-size slide

  42. 43
    エンジニアKさんの場合
    • 2020年2⽉
    • CDK
    • 案件前からプライベートで書いていた
    • このとき初めてTypeScriptを触る
    • サーバーサイドコーディング
    • TypeScriptでLambdaを書く
    • 設計全般
    • ⼀気にSW設計に⽬覚める(Clean Architecutere、ドメイン駆動設計)
    • DynamoDBの設計に⽬覚める(RDB経験は皆無)
    • Amazon DynamoDB deep dive:Advanced design patterns
    • いろんな⽂献を参考にしつつ、実際に⼿をかけて⾝体になじませていき理解していった

    View full-size slide

  43. 44
    エンジニアKさんの場合
    • 2020年4⽉
    • フロントエンド
    • Reactに⼿を染める
    • Appolo Client, Reactfor, Material UIなどを⾃分で検証して選定
    • StoryBookも体験
    • Auth0との連携も試してブログ化
    • TypeScriptでLambdaを書く
    • 学習
    • 公式ドキュメントは全部読んで、チュートリアルをやった
    • まずは全部読んだ。全部
    • サーバーサイドはGraphQL
    • GraphQLからAppSyncに⼿を出す
    • Amplifyコンソールを触りだしたのもこの頃
    • 2021年4⽉
    • gRPC, Go, Neptune
    • マイクロサービスの設計を強く意識しはじめる
    • マイクロサービスパターン
    • マイクロサービスアーキテクチャ

    View full-size slide

  44. 45
    エンジニアKさんが今を振り返って
    技術⼒を伸ばすときに意識していること
    • 簡単なサンプルアプリを、都度その時の⾃分の思想や試し
    たい技術で実装して感触を確かめる
    • 本を読んで案件やってサンプルアプリを作って、というサ
    イクルを回している

    View full-size slide

  45. 46
    エンジニアKさんが今を振り返って
    やってよかったこと
    • ⼀回ぐらいOSSコントリビュートすると、達成感も出て気
    持ちも捗ると思う
    • 本を読む
    • ⼀つのプロジェクトで全員が全員設計するわけではない
    • 原理原則を1から学ぶには、本を読んでそれをインプットすると、
    既存のプロジェクトのコートの⾒え⽅が変わってくる。その疑
    問点を同僚とディスカッションすることで理解が深められる
    • そこまでくると、同僚と話すだけで知識がどんどんはいってく

    • ベースの知識が無いと理解を積み上げるのが難しい

    View full-size slide

  46. 47
    インタビュー
    エンジニアOさんの場合

    View full-size slide

  47. 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)
    • 動かない単体テストがあり、それを参考に動かしつつ機能追加をしていった

    View full-size slide

  48. 49
    エンジニアOさんの場合
    • 2020年7⽉〜
    • ⼤きめの受託開発案件に要件定義から参画
    • 要件定義が何たるかを知った
    • 開発チームを牽引(バックエンドを中⼼に)
    • Pythonで書く想定だったが、引き継ぐ想定でクライアントと同じTypeScriptを利⽤
    • CDKはやりたかったから採⽤(YAMLを書きたくなかった)
    • TypeORMを採⽤
    • かなりむちゃだったが夜な夜な調べながら対応
    • 実装⼒アップのために競プロをはじめる(AtCoder)
    • ここでかなり⾃⼒がついた

    View full-size slide

  49. 50
    エンジニアOさんが今を振り返って
    資格をとる
    • AWSとGoogle Cloudの資格を全部とった
    • もともと知識がなかったので、薄く広く知るためには最強
    のツールだった
    • 本はあんまり読まなかった
    案件をゼロベースで担当する
    • ⾃分が考えて作っていくので、改めて深く考えるのと、顧
    客調整しながらやっていくので、責任感と相まってガッツ
    リ成⻑できた

    View full-size slide

  50. 51
    MAD事業部エンジニアに聞いた
    ⾎⾁になったもの⼀覧

    View full-size slide

  51. 52
    ⾎⾁になったもの⼀覧
    ⾎⾁になったもの 業務でどのように役⽴ったか
    Clean Architecture 設計原則の⼀つとして押さえておくことが重要
    ドメイン駆動設計⼊⾨ 設計原則の⼀つとして押さえておくことが重要
    初めてのGraphQL GraphQLを始めるとき、何はなくとも⼀度やってみる
    Web API The Good Parts REST APIの設計原則を学ぶのに最適
    リーダブルコード 読みやすいコードをどのように書けばよいか具体的なTipsを学べます。
    CPUの創りかた
    アジャイルサムライ アジャイル・スクラムの基礎知識が得られる
    ITエンジニアのための機械
    学習理論⼊⾨
    機械学習の理論について体系⽴てて説明しており、かつ、同じテーマについて複数
    の⼿法を適⽤していてその違いを理解しやすいです。
    NOSQLの基礎知識
    若⼲古いですが、NOSQLについて俯瞰的な知識をサクッとつかめるのでおすすめで
    す。NOSQLについて触れる際に最初に読んでおくとよいと考えます。
    データ指向アプリケーショ
    ンデザイン
    最近読んでますけど、15年前にこの書籍があればよかったと読書会で毎回⾔ってる
    ぐらい良い本ですw

    View full-size slide

  52. 53
    ⾎⾁になったもの⼀覧
    ⾎⾁になったもの 業務でどのように役⽴ったか
    強い先輩
    若い時に体系的に⾝に着けるべきものを絶妙なタイミングで教えてくれる。
    杉井が3年⽬までに教えてもらったこと
    ・デザインパターンなどの「ベストプラクティス」という概念
    ・UML(設計ドキュメントの正しい書き⽅)
    ・JavaやってるんだったらJavaのコードを読め
    ・データベースの基本的な仕組み(テーブル設計とかチューニングの基礎になった)
    ・エンジニアは怠惰であれ
    ロジカル・シンキング (Best
    solution) ドキュメントの書き⽅とかコミュニケーションの取り⽅について学びました。
    Effective Java 読んだのは2版ですけど、⾮常によかったです。
    実装パターン
    薄いですけど、ほんとよくまとまっててよかったです。先⽇メルカリで7000円ぐらい
    で売れましたw
    UNIXという考え⽅ 名著
    LPICレベル2 Linuxが触れるようになった
    プログラマが知るべき97の
    こと バージョン管理ツールの存在を知った
    IPAの試験
    元々iTunesの使い⽅ぐらいしか知らずにIT業界に⼊ったが、XXスペシャリストを全部制
    覇する頃には⾊々トラブルシューティングとかまでできる⼒がついていた
    3Minutes NetWorking ネットワーク関連の基礎知識を学びました。

    View full-size slide

  53. 54
    ⾎⾁になったもの⼀覧
    ⾎⾁になったもの 業務でどのように役⽴ったか
    AWS公式ドキュメント まずはここを調べます。
    テスト駆動開発 友⼈と⼀緒にペアプロしながらやったのもあって勉強になった。
    エクストリームプログラミ
    ング 読んでないけど今では当たり前な(?)プラクティスが⾊々紹介されている
    AWS サービス別資料 知らないサービスを把握する際にまず⽬を通します。
    リファクタリング 読んでないけどリファクタリングについてサンプルコードを元に学べる
    計算機プログラムの構造と
    解釈 関数型の考え⽅について理解が深まった気がします。
    Qiita 検索するとよく引っかかります。
    Stack Overflow 同じく英語で検索するとよく引っかかります。
    達⼈プログラマー
    僕が読んだのは第1版で新社会⼈の頃でした。それまで感覚でやっていたことを体系
    的に⽰してもらったという印象でした。
    [Web開発者のための]⼤
    規模サービス技術⼊⾨
    AWSでシステムを構築する場合でも、結局負荷とは何なのかという感覚をつかんで
    いることは引き続き重要なのかなと思います。これは本当にオンプレでゲーム会社
    のサイトとか設計するときに読んでました。
    コミュニティ勉強会への参

    知識が増えるだけじゃなく、技術の話ができる仲間が増え、その影響でまたイベン
    ト参加することが増えたり、、、と良い循環が回った気がする。楽しそうに仕事を
    している⼈たちが存在することを知れた

    View full-size slide

  54. 55
    ⾎⾁になったもの⼀覧
    ⾎⾁になったもの 業務でどのように役⽴ったか
    アプレンティスシップ・パ
    ターン
    キャリアとかについて悩んでたときに読みます。ソフトウェアエンジニアの⾔語化
    できないモヤモヤに対するヒントになることが書いてあります
    オブジェクト指向でなぜ作
    るのか オブジェクト指向、UML、モデリングなどの基礎的な知識が学べました
    AIエンジニアのための機械
    学習システムデザインパ
    ターン
    MLOps 開発における様々な practice が全体的に備えています。また、理論と実践が
    良いバランスで混ざっているのですぐ⼿元で試してみるのもできます。
    プログラミングの⼼理学
    20年くらい前に読んだ本で、その当時発刊後20以上経っていたような古い本ですが、
    パンチカードなどが使われていた時期にすでにアジャイルのようなスタイルの開発
    をしていた集団がいたというような話が書いてあって、プログラマーの⼼構え的な
    ものを学べました。後に発刊された達⼈プログラマーでやっとこの本で⾒た内容が
    地に⾜がついた感じになったので、実践というより「読み物」かもしれませんが。
    エキスパートCプログラミン
    グ―知られざるCの深層
    内容もさることながら、コラムもマニアックで楽しくて、技術の無駄遣い全開なノ
    リでプログラミングがいっそう楽しくなりました。C⾔語の理解がかなり深まるいい
    本でしたが、C⾔語を仕事で使ってなくても楽しめる技術の無駄遣い本です。技術で
    遊ぶことがさらに楽しくなりました。

    View full-size slide

  55. 56
    各技術領域の最近の所感

    View full-size slide

  56. 57
    7⽉時点の情報はこちらにまとまっています
    https://dev.classmethod.jp/articles/about-mad/

    View full-size slide

  57. 58
    コンピューティング環境
    • LambdaとFargateが半分半分ぐらい
    • コンテナに関しては、ECS on EC2はなし
    • EKSはEKS on EC2
    • LambdaでAuroraも複数有り(RDS Proxy)
    • がっつりどちらが良いとはきめきれないので、案件特性、
    ビジネス要件に応じて都度判断している

    View full-size slide

  58. 59
    ⾔語
    • TypeScriptの採⽤が確実に増加傾向
    • フロントエンド(React)、サーバーサイド(Node.js)、イン
    フラ(CDK)で⼀気通貫しての実装案件もあり
    • EKSはEKS on EC2
    • LambdaでAuroraも複数有り(RDS Proxy)
    • Pythonも現役
    • コンテナ周辺でGoも多い

    View full-size slide

  59. 60
    Infrastructure as Code
    • CDKが確実に増えている
    • CDKを使う場合は、必ずTypeScript
    • その他は群雄割拠
    • CloudFormation
    • Terraform
    • ServerlessFramework
    • ServerlessApplication Model

    View full-size slide

  60. 61
    CI/CD
    • GitHub Actionsが強い
    • ISSUE管理、リポジトリ管理、プルリクエストレビューなどと⼀
    貫した環境で作業できるのが⾮常に強い
    • AWSとの親和性も最強。このアップデートは衝撃
    (GitHub ActionsでAWSの永続的なクレデンシャルを渡
    すことなくIAM Roleが利⽤できるようになったようで
    す)
    • GitLabもよく使われている
    • Codeシリーズはあんまり…
    • 開発フローを回すのに⾟い場合が多い

    View full-size slide

  61. 62
    アジェンダ
    • 本⽇のゴールの共有
    • MAD事業部とは
    • ビジネスゴールに向けて
    • 技術要素として重要な事
    • 組織として重要な事(アンチパターン集)

    View full-size slide

  62. 63
    組織として
    重要なこと

    View full-size slide

  63. 64
    はじまります
    ここから主観丸出しで
    ございます

    View full-size slide

  64. 65
    アンチパターン集
    ①ビジネス上のクリティカルな問題に新⼿法を使おうと
    する
    ②全てを計画⽴ててそのとおりに進めようとする
    ③ロールの違いを過剰に意識する
    ④技術パートナーに丸投げする

    View full-size slide

  65. 66
    アンチパターン①
    ビジネス上のクリティカルな
    問題に新⼿法を使おうとする

    View full-size slide

  66. 67
    アンチパターン①
    サービス要件が⾮常に厳しいアプリケーションに慣れて
    ない⼿法を適⽤しようとする
    • 社運をかけたプロジェクト
    • 1秒たりとも落とせないサービス
    • 新⼿法を取り⼊れるメリットを最⼤限活かすため

    View full-size slide

  67. 68
    アンチパターン①
    サービス要件が⾮常に厳しいアプリケーションに慣れて
    ない⼿法を適⽤しようとする
    • 社運をかけたプロジェクト
    • 1秒たりとも落とせないサービス
    • 新⼿法を取り⼊れるメリットを最⼤限活かすため
    失敗できないが故にスピードが遅くなる
    • 計画段階で複数プロダクトのプロコンを作成
    • ⾮機能要件の全ケースと異常ケースを洗い上げ
    • 想定する全ての機能、⾮機能の検討が終わらない限り開発
    に着⼿できない

    View full-size slide

  68. 69
    アンチパターン①の解決策
    ⼩さくてコケても
    問題ないものを対象にする

    View full-size slide

  69. 70
    アンチパターン①の解決策
    SLA、SLOが低いもので試してみる
    • 社内のちょっとした情報共有ツールやブログなど
    • 半⽇ぐらい落ちても影響ないものあたりを選定

    View full-size slide

  70. 71
    アンチパターン①の解決策
    SLA、SLOが低いもので試してみる
    • 社内のちょっとした情報共有ツールやブログなど
    • 半⽇ぐらい落ちても影響ないものあたりを選定
    運⽤することでノウハウの蓄積速度が早い
    • 設計だけでなく、実際に⼿を動かして開発、そして運⽤す
    ることで得られる知⾒はものすごく⼤きい
    • 特にトラブル発⽣時に得られる知⾒は貴重
    • たとえkubernetesの採⽤がオーバーエンジニアリングだ
    としても、あえてやってみる価値はある

    View full-size slide

  71. 72
    アンチパターン②
    すべてを計画だてて
    そのとおりに進めようとする

    View full-size slide

  72. 73
    すべてを計画⽴ててそのとおりに進めようとする
    予算とスケジュールありきでプロジェクトを組む
    • 投⼊するエンジニアの⼈数と期間が決定済み
    • キャッシュアウトする部分の予算化のため計画ありきでス
    ケジュールが組まれている
    • リスクを抑えたいがため事例クレクレおじさんが発⽣

    View full-size slide

  73. 74
    すべてを計画⽴ててそのとおりに進めようとする
    予算とスケジュールありきでプロジェクトを組む
    • 投⼊するエンジニアの⼈数と期間が決定済み
    • キャッシュアウトする部分の予算化のため計画ありきでス
    ケジュールが組まれている
    • リスクを抑えたいがため事例クレクレおじさんが発⽣
    スケジュールが必達なため正常な意思決定ができない
    • 適切でない意思決定をしがち(リスクは低いがやたら⼿間
    はかかる運⽤ができあがる)
    • 特に運⽤しないとわからないものが多い

    View full-size slide

  74. 75
    アンチパターン②の解決策
    スコープを可能な限り⼩さくする

    View full-size slide

  75. 76
    スコープを可能な限り⼩さくする
    MVPの完成をゴールとする
    • 開発だけではなく、運⽤も評価できるようMVP
    (Minimum Viable Product)を設定
    • 期間は2週間〜最⻑1ヶ⽉程度
    • 実際に⼿を動かして評価することで、精度の⾼い意思決定
    が可能

    View full-size slide

  76. 77
    アンチパターン③
    ロールの違いを
    過剰に意識する

    View full-size slide

  77. 78
    ロールの違いを過剰に意識する
    最初にロールを作って、それに当てはまる作業を振り分
    けようとする
    • 「Dev」 vs 「Ops」
    • 「アプリ」 vs 「インフラ」
    • 「YAMLは誰が書くの︖」

    View full-size slide

  78. 79
    ロールの違いを過剰に意識する
    最初にロールを作って、それに当てはまる作業を振り分
    けようとする
    • 「Dev」 vs 「Ops」
    • 「アプリ」 vs 「インフラ」
    • 「YAMLは誰が書くの︖」
    モダンアプリケーションの開発や運⽤における考慮事項
    は多い
    • アプリケーション開発、構成管理、開発フロー整備、アプ
    リケーションデプロイ、テスト、監視、トレーシング、セ
    キュリティ、ロギング、ライブラリアップデート

    View full-size slide

  79. 80
    ロールの違いを過剰に意識する
    セクショナリズムが発⽣してチームパフォーマンスがで
    ない
    • 「これあんたがやるのでは︖」
    • 「え、忙しいよ、そっちでしょ︖」
    • 「そもそもこんな作業想定してないし」

    View full-size slide

  80. 81
    アンチパターン③の解決策
    ゴールだけを⾒て役割分担する

    View full-size slide

  81. 82
    ゴールだけを⾒て役割分担する
    ビジネスゴール
    クラウドネイティブ
    良いエンジニア組織
    実装や運⽤が必要な機能
    を都度考える

    View full-size slide

  82. 83
    従来のロールイメージ
    App1
    統⼀インフラ基盤
    HW保守
    アプリケーション
    エンジニア
    インフラエンジニア
    App2 App3 App4

    View full-size slide

  83. 84
    モダンアプリケーション開発のロールイメージ
    クラウド
    アプリより
    エンジニア
    App2 App3 App4
    App1
    インフラより
    エンジニア

    View full-size slide

  84. 85
    ゴールだけを⾒て役割分担する
    やるべきことを都度ロールに分類することは無理
    • 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分
    類することは無意味

    View full-size slide

  85. 86
    ゴールだけを⾒て役割分担する
    やるべきことを都度ロールに分類することは無理
    • 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分
    類することは無意味
    マインドとして「落ちてるボールは拾いまくる」意識が
    重要
    • エンジニアリングとして成⻑できる機会、経験する機会を
    のがさない
    • 全ての問題が⾃分ごとに思えてくるぐらいが理想

    View full-size slide

  86. 87
    アンチパターン④
    技術パートナーへの
    丸投げ

    View full-size slide

  87. 88
    技術パートナーへの丸投げ
    モダンアプリ開発のノウハウが⾜りない状態で全てを⾃
    分たちでやるのに時間がかかりすぎる場合、技術パート
    ナーに頼るのは有⼒な選択肢
    ただ、その場合に注意しておく点が⼀つ

    View full-size slide

  88. 89
    技術パートナーへの丸投げ
    モダンアプリ開発のノウハウが⾜りない状態で全てを⾃
    分たちでやるのに時間がかかりすぎる場合、技術パート
    ナーに頼るのは有⼒な選択肢
    ただ、その場合に注意しておく点が⼀つ
    請負契約で当初決めたスコープを
    まるっと納品してもらうのは
    基本やめましょう

    View full-size slide

  89. 90
    技術パートナーへの丸投げ
    請負契約も⽬的に叶うのであればもちろん有効な⼿段
    しかし
    「モダンアプリケーション開発を実践する組織になる」
    「ビジネスに俊敏性をもたらす」
    「実装しながら最適解を探す」
    という⽬的には⾜かせになり、相性が⾮常に悪い

    View full-size slide

  90. 91
    アンチパターン④の解決策
    委任契約にしてスコープに柔軟性をもたせ
    ノウハウを最⼤限蓄積できる
    パートナーとタッグを組む

    View full-size slide

  91. 92
    タッグを組むという意識
    「お⾦の対価でシステムができあがる」よりは「お⾦の
    対価でノウハウを得る」関係性が理想
    • 可能であれば技術パートナーと1チームでスクラムなどで
    同じ⽬線と呼吸で開発をしながら、実践的なノウハウを得
    ていく進め⽅が良い
    • よい関係性を気づくことができれば、いろんなノウハウを
    惜しみなく吸収することができるチャンス︕

    View full-size slide

  92. 93
    MAD事業部のポリシー
    モダンな開発技術
    をビジネス価値に
    直結できる
    ゴール
    ネットの情報
    ・ウェビナー
    ・ブログ
    ・公式ページ
    スタート
    多数の顧客を⽀援した実績と知⾒を是⾮
    活⽤いただきたい
    ノウハウの出し惜しみは⼀切しません

    View full-size slide

  93. 94
    組織観点ではこちらも是⾮ご検討を
    https://classmethod.jp/services/insource/

    View full-size slide

  94. 96
    まとめ
    モダンアプリケーション開発のキモはビジネスアジリティ
    技術は時代によって変わっていく前提で常に学び続ける必要あり
    エンジニアの技術⼒は必要だが組織としてアンチパターンを踏
    み抜かないこと
    技術⼒はあっても組織の意思決定が良くないとゴールに向かうこと
    が難しくなる
    うまく技術パートナーを頼ろう
    丸投げにせずノウハウを最⼤限吸収するつもりでウマが合うパート
    ナーを探しましょう

    View full-size slide

  95. 97
    最後に
    みなさんの組織がビジネスアジリティを
    追求できるようになることを
    願っています

    View full-size slide

  96. セッション後は、チャット欄のURL、または下記QRコードより
    アンケートへのご協力をお願いいたします。
    SNS投稿にはこちらをお使いください:#devio2021
    https://forms.gle/8uD36XqYT42xbfEU8
    16:20-16:50
    「あなたと組織がモダンアプリケーション開発を
    実践できるようになるまでの全過程

    Q&A Q&A

    View full-size slide