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

AWS DevDay 2023 登壇資料

Transcript

1. エンジニアとしての自分とマネージャーとしての 自分の狭間で、どう成⾧していくのか？ AWS Dev Day 2023 Tokyo 2023年6月22日 NRIネットコム株式会社 デジタルイノベーション本部 クラウドテクニカルセンター センター⾧ 佐々木拓郎
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介  2000年 4月 NRIネットコム株式会社入社  現在 クラウドテクニカルセンター センター⾧  執筆 佐々木拓郎
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/
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニアのキャリアの課題 01 エンジニアとしての付加価値の追求 02 マネジメントのお仕事 03 何を選択するか？ 04
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. エンジニアのキャリアの課題
6. エンジニア マネージャー どこかで、必ず選択の 場面が出てくる問題
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニアとしてのアイデンティティの悩み
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. だんだんと高い付加価値を求められるようになる 付加価値 ＝ 売上高 ー 外部購入価値（≒経費） （営業利益＋減価償却費＋諸費用＋人件費） 付加価値の中身 給料を上げるには、利益が必要 利益を上げるには、付加価値を高める必要がある キャリアを積み上げるにつれて、高い付加価値を求められる
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニアにとっての付加価値≒生産性 生産性 ＝ 投入リソース 算出価値 生産性 ＝ 投入リソース 算出価値 一般的な生産性向上 創造生産性向上 投入リソースの削減 ・人件費を下げる ・少人数/短時間で開発する 算出価値の向上 ・対価アップ ・評価アップ
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. エンジニアとしての付加価値の追求
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 付加価値を高めていく① 生産性向上 速く作れるようになる  同じ画面/機能を、より短い時間で生産できるようにする  単位時間あたりの生産性向上 ⇒個人としての開発速度の向上には限界があった 生産性向上分 エンジニア 生産量 生産量アップの取り組み  学習してパターンを把握する  再利用性の考慮  ライブラリを導入し、開発箇所を減らす  開発環境のカスタマイズ
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  言語の選定  フレームワーク  利用するライブラリ  コーディング規約  リポジトリの管理ルール  アーキテクチャ
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にマイグレーション
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 付加価値を高めていく④ チームの生産性を向上 CI/CD環境を整えて、チームの生産性を向上  継続的インティグレーション/継続的デリバリーによるチームの開発効率の改善  生産性向上率×チームの人数の付加価値が発生 ⇒AWSがCI/CDを整備してきたので、ほぼ失職 CIサーバー リポジトリ サーバー ソース フィードバック 本番環境 検証環境 開発環境 デプロイ 構成管理 サーバー
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" } } } ] } テンプレート化
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. 蛇足 一方で、ニーズは根強いようだ 個人の財布的に＋ 書名 ：AWSの薄い本 IAMのマニアックな話 著者 ：佐々木 拓郎 発行日：2019年9月22日
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 付加価値を高めていく⑥ 影響範囲が大きい部分を担当する AWS利用者全員に影響がある機能（AWS Organizations）  数十～数百アカウントに影響し、デフォルト設定を全アカウントに設定できる  セキュリティ・ガバナンスを一元管理で、システムとしての付加価値も向上 ⇒議論の対象が、システムから組織へとフォーカスに移っていく
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニアの付加価値の高め方 エンジニアの評価 ＝ 個人のアウトプット ＋ チームへの貢献 エンジニア エンジニア 個人のアウトプットの増大 メンバーの 生産に 貢献 メンバーの 生産に 貢献 チームへの貢献 個人の生産性向上 チームの生産性向上
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. マネージャーのお仕事
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. マネージャーの仕事 組織を拡大しアウトプットの総量を上げる マネージャー メンバー メンバー メンバー 組織のアウトプットの総量 マネージャー メンバー メンバー メンバー 組織のアウトプットの総量 メンバー メンバー メンバー  マネージャー個人のアウトプットを上げるより、チームとしてのアウトプットの総量を上げる  組織の立ち上げ当初は、マネージャーのアウトプットに依存する部分が大きい  組織でみると、マネージャー個人のアウトプットの向上より、組織としてのアウトプット増加の方が増加量が大きくなる  メンバーの採用と育成が大事
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. マネージャーの仕事 権限を委譲する アウトプットを増やすには、必ず委譲が必要  仕事には、結果責任と実行責任がある。実行責任をメンバーに委譲していくことで、チームが成⾧する  委譲に失敗すると、丸投げやマイクロマネジメントになり、チームは歪な成⾧をする 委譲 丸投げ マイクロマネジメント マネージャー 結果 責任 メンバー 実行 責任 マネージャー メンバー 実行 責任 結果 責任 マネージャー 結果 責任 実行 責任 メンバー 実行 責任
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. マネージャーの仕事 アウトプット（生産物）をアウトカム（価値）に変える アウトプット アウトカム アウトプットをしても、それを価値に変えないと無駄になる  方向性を間違えると、例えどんなにアウトプットの量が多くても価値は生まない  どの方向に向かうのかを決めるのも、マネージャーの仕事
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. 売上を改善すると、付加価値も高まる 付加価値 ＝ 売上高 ー 外部購入価値（≒経費） 売上の構造を変えられるのは、マネージャー 従来のビジネスモデルの延⾧で改善するのか、全く新しいモデルに挑戦するのか 売上が二倍になると、同じアウトプットでも付加価値は倍近くになる 数字を追い求めるのも大事。でも、モチベーションのためにも、数字だけでも駄目
24. 23 Copyright（C） NRI Netcom, Ltd. All rights reserved. ４. エンジニアとして何を選択するか？
25. 24 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニア一本で勝負する道、別の方法  単一分野で勝負するのは、茨の道  クラスで１番、学校で１番、県で１番 ・・・  ほぼ必ず上には上がいる  同一分野内の順位付けは容易  隣り合う分野を掛け合わせると？  ベクトルの合成のように、足し合わせた結果で評価される  組み合わせ次第で、独自に第一人者の分野を作れる
26. 25 Copyright（C） NRI Netcom, Ltd. All rights reserved. 技術にマネジメントのスキルを加えてみる 技術力 プラスαのスキル （マネジメントetc） エンジニアとしての 総合力UP！！
27. 26 Copyright（C） NRI Netcom, Ltd. All rights reserved. エンジニア ⇒ マネージャーの一方通行ではない  どちらの立場を１つ選ぶものではない  別の視座をもつと、元の仕事の解像度も上がり、より高みに達せる  マネージャーになってからも、またエンジニアの仕事もできる  気軽にチャレンジ！！
28. エンジニア マネージャー どちらの道も目的地は同じ