$30 off During Our Annual Pro Sale. View Details »

エンジニアとしての自分とマネージャーとしての自分の狭間で、どう成長していくのか?(AWS DevDay 2023登壇資料)

エンジニアとしての自分とマネージャーとしての自分の狭間で、どう成長していくのか?(AWS DevDay 2023登壇資料)

AWS DevDay 2023 登壇資料

Takuro SASAKI

July 27, 2023
Tweet

More Decks by Takuro SASAKI

Other Decks in Technology

Transcript

  1. エンジニアとしての自分とマネージャーとしての
    自分の狭間で、どう成⾧していくのか?
    AWS Dev Day 2023 Tokyo
    2023年6月22日
    NRIネットコム株式会社
    デジタルイノベーション本部
    クラウドテクニカルセンター
    センター⾧ 佐々木拓郎

    View Slide

  2. 1
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    自己紹介
     2000年 4月 NRIネットコム株式会社入社
     現在 クラウドテクニカルセンター センター⾧
     執筆
    佐々木拓郎

    View Slide

  3. Japan AWS Ambassador 2019-2022
    最古参のAmbassadorの一人でした
    ※ AWS JAPAN APN ブログ Japan APN Ambassador 2019の発表
    https://aws.amazon.com/jp/blogs/psa/japan-apn-ambassador-2019/

    View Slide

  4. 3
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニアのキャリアの課題
    01
    エンジニアとしての付加価値の追求
    02
    マネジメントのお仕事
    03
    何を選択するか?
    04

    View Slide

  5. 4
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    1. エンジニアのキャリアの課題

    View Slide

  6. エンジニア
    マネージャー
    どこかで、必ず選択の
    場面が出てくる問題

    View Slide

  7. 6
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニアとしてのアイデンティティの悩み

    View Slide

  8. 7
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    だんだんと高い付加価値を求められるようになる
    付加価値 = 売上高 ー 外部購入価値(≒経費)
    (営業利益+減価償却費+諸費用+人件費)
    付加価値の中身
    給料を上げるには、利益が必要
    利益を上げるには、付加価値を高める必要がある
    キャリアを積み上げるにつれて、高い付加価値を求められる

    View Slide

  9. 8
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニアにとっての付加価値≒生産性
    生産性 =
    投入リソース
    算出価値
    生産性 =
    投入リソース
    算出価値
    一般的な生産性向上 創造生産性向上
    投入リソースの削減
    ・人件費を下げる
    ・少人数/短時間で開発する
    算出価値の向上
    ・対価アップ
    ・評価アップ

    View Slide

  10. 9
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    2. エンジニアとしての付加価値の追求

    View Slide

  11. 10
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく① 生産性向上
    速く作れるようになる
     同じ画面/機能を、より短い時間で生産できるようにする
     単位時間あたりの生産性向上
    ⇒個人としての開発速度の向上には限界があった
    生産性向上分
    エンジニア
    生産量
    生産量アップの取り組み
     学習してパターンを把握する
     再利用性の考慮
     ライブラリを導入し、開発箇所を減らす
     開発環境のカスタマイズ

    View Slide

  12. 11
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく② アウトプットの高度化
    アーキテクトになる
     生産効率の向上と、フレームワーク活用による実質的な開発箇所の減少
     標準化による多人数での大規模開発も可能となる
    ⇒いつの間にかAWSインフラの比重が大きくなって退場
    Internet
    ファイアーウォール
    ファイアーウォール
    負荷分散装置
    負荷分散装置
    Web
    サーバー
    Web
    サーバー
    AP
    サーバー
    AP
    サーバー
    DB
    サーバー
    ミドルウェアの構成 アプリケーションFWの選定 アプリケーションの開発方針
    Apache Web
    Server + mod_jk
    Apache AJP
    Connector
    Tomcat
    Application Server
    Tomcat AJP
    Connector
     言語の選定
     フレームワーク
     利用するライブラリ
     コーディング規約
     リポジトリの管理ルール
     アーキテクチャ

    View Slide

  13. 12
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく③ 先行者になる
    Server
    AWS Cloud
    オンプレミス環境
    Instance
    Amazon RDS
    instance
    当初は、AWSに移行するだけで付加価値が高かった
     先行者利益
     知識・技術を保有する希少価値
    ⇒できる人が増えてきたため、相対的に付加価値は低下
    移行戦略 6つのR
     Rehosting(再ホスティング)
     Replatforming(プラットフォーム変換)
     Repurchasing(再購入)
     Re-architecting(再設計)
     Retire(廃棄)
     Retain(現状維持)
    AWSにマイグレーション

    View Slide

  14. 13
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく④ チームの生産性を向上
    CI/CD環境を整えて、チームの生産性を向上
     継続的インティグレーション/継続的デリバリーによるチームの開発効率の改善
     生産性向上率×チームの人数の付加価値が発生
    ⇒AWSがCI/CDを整備してきたので、ほぼ失職
    CIサーバー
    リポジトリ
    サーバー
    ソース
    フィードバック 本番環境
    検証環境
    開発環境
    デプロイ
    構成管理
    サーバー

    View Slide

  15. 14
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく⑤ 難易度を高いところを担当する
    AWSアカウント利用者全員に影響のあるIAMを極める
     高い知識
     AWS CloudFormation の テンプレート化により、再利用性が高い
    ⇒Organizations+SSOが標準化してきているので、付加価値は低下
    ホワイトリストパターン
    ブラックリストパターン
    拒否
    許可
    Start
    許可
    Stop
    許可
    Describe
    *
    許可
    拒否
    IAM
    拒否
    VPC
    拒否
    S3
    設計の方針決め IAMポリシーへの落とし込み
    自パスワード変更
    (カスタマ管理ポリシー)
    IPアドレス制限
    (カスタマ管理ポリシー)
    LambdaFullAccess禁止
    (カスタマ管理ポリシー)
    ネットワーク操作禁止
    (カスタマ管理ポリシー)
    PowerUser
    (AWS管理ポリシー)
    開発者IAMグループ
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Deny",
    "Action": "*",
    "Condition": {
    "NotIpAddress": {
    "aws:SourceIp": [
    "8.8.8.8/32"
    ]
    }
    },
    "Resource": "*"
    },
    {
    "Effect": "Deny",
    "NotAction": [
    "iam:*"
    ],
    "Resource": "*",
    "Condition": {
    "BoolIfExists": {
    "aws:MultiFactorAuthPresent":
    "false"
    }
    }
    }
    ]
    }
    テンプレート化

    View Slide

  16. 15
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    蛇足
    一方で、ニーズは根強いようだ
    個人の財布的に+
    書名 :AWSの薄い本 IAMのマニアックな話
    著者 :佐々木 拓郎
    発行日:2019年9月22日

    View Slide

  17. 16
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    付加価値を高めていく⑥ 影響範囲が大きい部分を担当する
    AWS利用者全員に影響がある機能(AWS Organizations)
     数十~数百アカウントに影響し、デフォルト設定を全アカウントに設定できる
     セキュリティ・ガバナンスを一元管理で、システムとしての付加価値も向上
    ⇒議論の対象が、システムから組織へとフォーカスに移っていく

    View Slide

  18. 17
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニアの付加価値の高め方
    エンジニアの評価 = 個人のアウトプット + チームへの貢献
    エンジニア
    エンジニア
    個人のアウトプットの増大
    メンバーの
    生産に
    貢献
    メンバーの
    生産に
    貢献
    チームへの貢献
    個人の生産性向上
    チームの生産性向上

    View Slide

  19. 18
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    3. マネージャーのお仕事

    View Slide

  20. 19
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    マネージャーの仕事 組織を拡大しアウトプットの総量を上げる
    マネージャー
    メンバー
    メンバー
    メンバー
    組織のアウトプットの総量
    マネージャー
    メンバー
    メンバー
    メンバー
    組織のアウトプットの総量
    メンバー
    メンバー
    メンバー
     マネージャー個人のアウトプットを上げるより、チームとしてのアウトプットの総量を上げる
     組織の立ち上げ当初は、マネージャーのアウトプットに依存する部分が大きい
     組織でみると、マネージャー個人のアウトプットの向上より、組織としてのアウトプット増加の方が増加量が大きくなる
     メンバーの採用と育成が大事

    View Slide

  21. 20
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    マネージャーの仕事 権限を委譲する
    アウトプットを増やすには、必ず委譲が必要
     仕事には、結果責任と実行責任がある。実行責任をメンバーに委譲していくことで、チームが成⾧する
     委譲に失敗すると、丸投げやマイクロマネジメントになり、チームは歪な成⾧をする
    委譲 丸投げ マイクロマネジメント
    マネージャー
    結果
    責任
    メンバー
    実行
    責任
    マネージャー メンバー
    実行
    責任
    結果
    責任
    マネージャー
    結果
    責任
    実行
    責任 メンバー
    実行
    責任

    View Slide

  22. 21
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    マネージャーの仕事 アウトプット(生産物)をアウトカム(価値)に変える
    アウトプット アウトカム
    アウトプットをしても、それを価値に変えないと無駄になる
     方向性を間違えると、例えどんなにアウトプットの量が多くても価値は生まない
     どの方向に向かうのかを決めるのも、マネージャーの仕事

    View Slide

  23. 22
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    売上を改善すると、付加価値も高まる
    付加価値 = 売上高 ー 外部購入価値(≒経費)
    売上の構造を変えられるのは、マネージャー
    従来のビジネスモデルの延⾧で改善するのか、全く新しいモデルに挑戦するのか
    売上が二倍になると、同じアウトプットでも付加価値は倍近くになる
    数字を追い求めるのも大事。でも、モチベーションのためにも、数字だけでも駄目

    View Slide

  24. 23
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    4. エンジニアとして何を選択するか?

    View Slide

  25. 24
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニア一本で勝負する道、別の方法
     単一分野で勝負するのは、茨の道
     クラスで1番、学校で1番、県で1番 ・・・
     ほぼ必ず上には上がいる
     同一分野内の順位付けは容易
     隣り合う分野を掛け合わせると?
     ベクトルの合成のように、足し合わせた結果で評価される
     組み合わせ次第で、独自に第一人者の分野を作れる

    View Slide

  26. 25
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    技術にマネジメントのスキルを加えてみる
    技術力
    プラスαのスキル
    (マネジメントetc)
    エンジニアとしての
    総合力UP!!

    View Slide

  27. 26
    Copyright(C) NRI Netcom, Ltd. All rights reserved.
    エンジニア ⇒ マネージャーの一方通行ではない
     どちらの立場を1つ選ぶものではない
     別の視座をもつと、元の仕事の解像度も上がり、より高みに達せる
     マネージャーになってからも、またエンジニアの仕事もできる
     気軽にチャレンジ!!

    View Slide

  28. エンジニア マネージャー
    どちらの道も目的地は同じ

    View Slide

  29. View Slide