プログラマでありたい

おっさんになっても、プログラマでありつづけたい

IAMに有効期限を設定する条件式

 IAMの条件式に設定できるものを眺めていた時に、発見した小ネタです。
IAMではCondition要素で、そのポリシーが適用される条件が設定できます。
その中の1つに、有効期限を設定できる条件式があります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"},
                "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"}
            }
        }
    ]
}

DateGreaterThanで有効なる開始日時、DateLessThanで終了日時を指定します。日時の指定は、UTCです。

docs.aws.amazon.com

ユースケース

 一時的に許可を与える場合や、定期的にユーザー・ロールの棚卸しが必要な場合に良さそうですね。上の例では、有効期限で区切って許可ステートメントを与えていますが、○○日以降は全て許否(Deny)というポリシーを作って、グループやロールに追加するのが良いのではと思います。そうすることで、権限を制御するポリシーと有効期限を制御するポリシーを分離でき、権限ポリシーのパーツ化が図れます。図にすると、こんな感じですかね。

f:id:dkfj:20200707123355p:plain

 このような形が良いと思うのは、IAMポリシーはできるだけパーツ化したいので、個人に紐付く有効期限等を権限管理と一緒にするのは避けたいからです。そして分離する場合は、許可じゃなくて許否にします。というのは、AWSのIAMのポリシーの評価論理としては、明示的許否 > 明示的許可 > 暗黙的拒否(デフォルト拒否)となっているからです。

f:id:dkfj:20200707123546p:plain

 まぁこんな感じで使えるかなぁと思ったネタです。不要なIAMユーザーやIAMロールの定期的な削除は必要です。人間系の運用も必用となる部分なので、抜け漏れのヒューマンエラーを防ぐためにこういった手立てもよいのではないでしょうか?
 もう一歩組織としての管理が進むと、IAMユーザーは無くしてADによる認証とフェデレーションによるIAMロールの利用という形になるかと思います。全ての組織がそう出来るわけではないので、もし適合できるシチュエーションがあればご検討ください

AWS IAMの最小権限追求の旅

 皆さん、IAM使ってますか〜?
今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。

IAMでのセキュリティのベストプラクティス

 まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。

docs.aws.amazon.com

  1. AWS アカウントのルートユーザー アクセスキーをロックする
  2. 個々の IAM ユーザーの作成
  3. IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する
  4. 最小権限を付与する
  5. AWS 管理ポリシーを使用したアクセス許可の使用開始
  6. インラインポリシーではなくカスタマー管理ポリシーを使用する
  7. アクセスレベルを使用して、IAM 権限を確認する
  8. ユーザーの強力なパスワードポリシーを設定
  9. MFA の有効化
  10. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
  11. ロールを使用したアクセス許可の委任
  12. アクセスキーを共有しない
  13. 認証情報を定期的にローテーションする
  14. 不要な認証情報を削除する
  15. 追加セキュリティに対するポリシー条件を使用する
  16. AWS アカウントのアクティビティの監視
  17. IAM ベストプラクティスについてビデオで説明する

『最小権限を付与』する難しさ

 しかし、実際にこのベストプラクティスを実践していると、一つだけ難易度が格段に高いものがあることに気がつくでしょう。それは、『最小権限を付与する』です。最小権限には二重の意味の難しさがあります。

  • 最小権限を適用するには、IAMの知識と探索の時間が必要
  • 最小権限を探求するためには、IAMの権限が必要

 1つ目は言わずもがなかと思います。最小権限を付与するには、IAMを正しく理解している必要があります。その上で、実際に付与する際は、ポリシーを作って実際に動かしてみてと試行錯誤が必要です。これが結構、時間が掛かります。テクニック的な面としては、大きめの権限を最初に与えておいて、後でIAMの権限の利用履歴をみて絞り込むといった方法もありますが、それでも手間が掛かるでしょう。
 2つ目の探求するには、IAMの権限が必要という半ば禅問答的な問題です。最小権限を付与するためには、それ以上の権限を持っている人が実行しなければならないのです。組織的な話でいうと、ここが一番たいへんです。IAMを操作できる人を絞り込みたいし、付与する権限も最小限に抑え込みたい。でも、そうするとAWSのアカウントマネージャー的な立場の人が、ひたすらIAMの権限について考えないといけなくなります。
 昔であれば、そのモデルでも何とかなったかもしれません。しかし、今だとその方式でやると破綻する可能性が高いです。なぜなら、今のAWSの設計・開発は、IAMロールと向かいあう必要があるからです。

IAMロールと向き合う

 『IAMロールと向き合う』とはなんでしょうか?従来のAWSの構築は、VPCでネットワークを作ってその中にEC2をたててミドル・アプリの設計をしてという形が多かったかと思います。そのため、職能機能のAWS管理ポリシーに代表されるようなネットワーク管理者やデータベース管理者といった役割別の権限を付与して職務を遂行してもらうことになります。
 今は、それに加えてAWSのマネージドサービスを活用することが多くなっています。そういった際に、何が必要でしょうか?IAMロールをひたすら作ることが必要になってきます。IAMロールを作るには、IAMの権限が必要になります。IAMの権限とは、実質的に管理者の権限です。AdministratorAccessとPowerUserAccessの違いをみると解るのですが、IAMの権限があるかないかの違いしかないのです。
 という事でIAMは実質的に管理者権限で、IAMロールを作るにはその権限が必要になります。最小権限を作るために、最大の権限を渡すというこの矛盾に気が付いた瞬間に、体を引き裂かれるような思いをする事になります。
 

SCPとPermission Boundary

 AWSもその矛盾に気が付いていて、対策となるサービスを提供しています。AWS Organizationsのサービスコントロールポリシー(SCP)と、IAMのPermission Boundaryです、どちらも似たような機能を持ち、例えIAMの権限を持っていたとしても、予め許可した範囲しか権限が有効にならなくなります。次の図のように積集合ですね。

f:id:dkfj:20200706050355p:plain

 このIAMのPermission Boundaryを使ってIAMロールは作れるけど、作れる範囲を限定するといった事ができます。詳しい手順はそのうち解説しようと思いますが、既にすばらしい解説記事があるので紹介しておきます。

qiita.com


 ただ、このPermission Boundaryを使いこなすのが中々難しいというのもあります。IAMをちゃんと理解して、どの範囲を許可するのか、その辺りの絶妙な設計が必要になります。人類のIAMレベルを上げないと、まだまだ万人向けでないのかなぁという印象です。私も、これでいいやという答えには達してないです。

サンドボックスアカウント

 もう一つの対策としては、サンドボックスアカウントという考え方があります。通常の環境と隔離したAWSアカウントを作り、その中でIAMの管理者権限を与え自由にやってもらう方法です。
 隔離したアカウントといえども、アクセスキー・シークレットアクセスキーなどセキュリティ・クレデンシャルの流失で、AWSアカウントが乗っ取られたら大事故が発生します。対策としては前述のSCPなどを利用して、これだけは防ぐという動作を禁止する方法があります。
 どちらも一長一短ですが、サンドボックスアカウントの方が、自由度が高く管理者の負荷は少ない傾向にあります。

そもそも『最小権限』とは?

 ここまで書いていて、実はそもそも『最小権限』の定義について、何も触れていないことに気がつくかもしれません。日本人的な几帳面さで、最小権限と聞くと字面そのままに、本当の最小権限を思い浮かべていると思います。例えば、S3への書き込み権限であれば対象バケットに対しての書き込み権限のみとか、オペレーターであれば参照権限とEC2等の起動・停止の権限のみとか。
 最近、ベストプラクティスの言う『最小権限』って、ここまで厳密な意味での最小権限と言っているのではないのではないかなと思えるようになってきました。例えば、開発者のそれぞれにAdmin権限渡さずに、職能機能のAWS管理ポリシーを付与するんだぞ〜的な大雑把さを指しているのではないかという気もしています。あるいは、個々のアクション単位の選定ではなく、ListやRead,Write,Permission Managementなどのアクセスレベルを指しているとか。
 あまり神経質に最小権限を追求して実現できないより、ある程度の大雑把さを許容している方が、現実的には運用は回るし事故も少ないと思います。その上で、本当に気を付けないといけないS3周りのパーミッション等を厳格に定義するのが良いのではないでしょうか。

まとめ?

 話が全然締まらずに横に外れていきましたが、IAMの最小権限の探究の悩ましさが伝わりましたでしょうか?一人で最小権限を追求してる時は、別にいいんですよ。セキュリティをどこまで追求するかも、それに掛ける工数も自分でコントロールできるから。でも、組織で運用するとなったら、途端に悩ましくなります。どこまで権限を委譲するのかの設計や、想定している委譲範囲から逸脱していないかの確認が必要になります。考え出すと止まらなくなるのが、『IAMの最小権限』です。ぜひ一緒に、この探求の旅に出かけましょう!!

booth.pm

booth.pm

AWS Control Towerとガードレールという設計思想

 前回、Control Towerの削除方法だけ書いていたので、それではあんまりだと思ったのでControl Towerの簡単な紹介とその中核の一つであるガードレールという設計思想を紹介します。

ガードレールという考え方

 従来の考え方では、セキュリティを保つためには多少の不便は仕方ないと、セキュリティと利便性とのトレードオフで語られることが多かったです。一方、AWSはガードレールという考え方を提唱し、『ブレーキをかけるのではなく、どんなスピードを出しても安全なセキュリティ』を確保しようという方策に舵を切っています。
 利便性とのトレードオフは、Gate(関所)と読んでいます。ガードレールは安全柵ですね。何度かお見せしてたかもしれませんが、関所とガードレールの違いを表した図になります。

f:id:dkfj:20200703081137p:plain

ガードレールの実現手段としての予防と検知

 では、そのガードレールをどう実現しているのかというと予防(prevention)と検知(detection)です。予防は、事前に想定される危険性を定義して、そこからそもそも逸脱できなくすることです。実装例としては、個人レベルであればIAMに権限を与えないとかがあたります。またAWSアカウントレベルでは、AWS Organizationsのサービスコントロールポリシー(SCP)で制限するなどになります。
 予防に対して、検知とはなにでしょうか?検知は、セキュリティやガバナンス上で問題ある可能性がある動作を検出することです。例えば、VPCのネットワークの許可ポートの変更を検知したり、ルートユーザーの利用を検知したりとかが該当します。それだったら、検知じゃなく予防で防げばよいのではと思う人もいるかもしれません。しかし、検知の対象となる動作の大半は、実運用上でも必要なことが多いです。それを一律で防ぐのは難しいということで、検知して問題ないかを確認します。あとは、そもそも危険のある動作を全部洗い出して防ぐのも大変というのもあります。
 予防と検知の関係を図でまとめると、次のようになります。

f:id:dkfj:20200703081553p:plain

Control Towerでの予防と検知

 では、Control Towerでは、予防と検知をどのように実装しているのでしょうか?実は、Control Tower自体には直接的な予防と検知の機能を持ちません。予防はOrganizationsのサービスコントロールポリシー(SCP)で実現し、検知はConfig Rulesで実現しています。Control Towerを有効にすると、自動的にこれらの機能をオンにして初期設定をしてしまうのです。そして、状況を収集するようになるといった感じです。
 では、Control Towerが初期設定する設定をみてみましょう。まぁほとんどが予防ですね。ということで、Control TowerがOrganizationsを作るのも納得です。

名前 ガイダンス カテゴリ 動作
ログアーカイブの削除を許可しない 必須 監査ログ 予防
ログアーカイブの保存時に暗号化を有効にする 必須 監査ログ 予防
ログアーカイブのアクセスログ作成を有効にする 必須 監査ログ 予防
ログアーカイブへのポリシーの変更を不許可にします 必須 モニタリング 予防
ログアーカイブへのパブリック読み取りアクセス
を不許可にする
必須 監査ログ 検出
ログアーカイブへのパブリック書き込みアクセス
を不許可にする
必須 監査ログ 検出
ログアーカイブの保持ポリシーを設定する 必須 監査ログ 予防
CloudTrail への設定変更を不許可にします 必須 監査ログ 予防
CloudTrail イベントと CloudWatch logs を統合する 必須 モニタリング 予防
利用可能なすべてのリージョンで
CloudTrail を有効にする
必須 監査ログ 予防
CloudTrail ログファイルの整合性検証を有効にする 必須 監査ログ 予防
AWS Control Tower によって設定された
CloudWatchへの変更を不許可にします
必須 Control Tower
のセットアップ
予防
AWS Config 集約承認の削除を許可しない 必須 Control Tower
のセットアップ
予防
AWS Control Tower によって設定された
AWS Config アグリゲーションへの
変更を不許可にします
必須 Control Tower
のセットアップ
予防
AWS Config への設定変更を不許可にします 必須 監査ログ 予防
利用可能なすべてのリージョンで
AWS Config を有効にする
必須 監査ログ 予防
AWS Control Tower によって設定された
AWS Config ルールへの変更を不許可にします
必須 Control Tower
のセットアップ
予防
EBS 用に最適化されていない
EC2 インスタンスタイプの起動を許可しない
強く推奨 オペレーション 検出
EC2 インスタンスにアタッチされていない
EBS ボリュームを許可しない
強く推奨 オペレーション 検出
EC2 インスタンスにアタッチされた
EBS ボリュームの暗号化を有効にする
強く推奨 データセキュリティ 検出

予防と検知以外のControl Towerの機能

 Control Towerを設定すると、SCPとConfig Rules以外にも沢山のサービスの設定をおこないます。ところどころ言及していたOrganizationsの作成はもちろんのこと、組織ユニット(OU)の作成やログやセキュリティ用のAWSアカウント作成まで行います。また、Security Hubを設定したりAWS SSOまで用意します。

f:id:dkfj:20200703081608p:plain

 それ以外にも、1アカウント1VPCを徹底させるためか、デフォルトのネットワークの作成等も行います。この辺りの一つ一つの機能を解説すると非常に長くなるので、また日を改めて解説します。予防と検知については、技術書典8で発表した、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』で詳しく取り上げています。次回、技術書典9でマルチアカウント管理をテーマに1冊書く予定です。それにてIAM本の3部作は完結となります。お楽しみに〜

booth.pm

AWS認定セキュリティ – 専門知識の試験対策本を書きました

 Twitter等で告知しておりましたが、AWS認定セキュリティ 専門知識の試験対策本を書きました。販売開始は今月末の、2020年7月29日です。

AWS 認定セキュリティ試験対策テキスト

AWS 認定セキュリティ試験対策テキスト

書名や価格は暫定版だと思います。

試験対策本の内容

 試験対策本なので、試験要項に沿った形の章立てとなっております。最初の1章で、AWS認定試験の概要と試験勉強の仕方、教材についての説明をしています。2〜6章がメインで出題分野ごとに、対応するサービスとその考え方をまとめています。そして7章でWell-Architectedについては、セキュリティの柱を取り上げています。ここでは、実際にWell-Architectedをダウンロードして読んでもらうという前提を置いたうえで、では対策として実際にどのようなサービスを使うのかを補完する形でまとめています。最後はお約束の問題の解き方と、練習問題です。

  1. AWS認定試験の概要
  2. IDおよびアクセス管理
  3. インフラストラクチャのセキュリティ
  4. データ保護
  5. ログと監視
  6. インシデント対応
  7. Well-Architected
  8. 問題の解き方

著者について

 今回も会社の同僚と書いています。上野さんは、2020年のAWSのAPN AmbassadorおよびTop EngineersかつALL AWS Certifications Engineerという長い肩書を持ってます。要は、AWSの認定試験12種全部持ってアンバサダーにも選ばれているという実力者です。最近、精力的にJAWSUG等に登壇しているのですが、どんなテーマで話してもどうやって試験に受かるのという質問が一番多くて困っているそうです。AWSの認定試験を受けだして、2年かそこらくらいで全部取ってしまっているのが脱帽です。あと、情報処理試験の高度も、ほとんど持っています。
 もう一人の共著者の小林さんは、情報処理試験の高度をコンプリートしているという世にも珍しい人です。なんだか知らないけど、半年ごとに資格を取っていってあっという間にコンプリートしていました。諸般の事情でAWSの試験はあまり受けていないですが、セキュリティの対策本を書くから取っておいてというと、あっさり試験に合格していました。もちろん、プロも取っています。たぶん、AWS認定の受験を再開したら、あっという間に全部取ってしまうのではと思っています。
 また、過去に一緒に書いたイラスト図解式 この一冊で全部わかるWeb技術の基本のメイン著者でもあります。この本の6割以上は、小林さんが書いていたと思います。私は、2ページほどしか書いていません。この本が発売して3年経ちますが未だに売れ続けていて、今でもカテゴリートップに輝いていることが多々あります。先日もまた増刷して、合計9刷、累計25,000部になっています。技術書の中では、大ベストセラーです。

 ということで、AWSについても試験についてもプロフェッショナルな2人が中心に書き上げています。私は、AWS認定も資格試験もコンプリートしていまあせんが、IAM本とアカウントセキュリティ本を書いていたということで、1&2章の担当しています。

booth.pm
booth.pm


本書のお勧めポイント

 本書のお勧めポイントとしては、試験対策本として書かれていますがAWSのセキュリティサービスの指南書にもなっているという点です。具体的な設定方法などは範疇外なので書いていませんが、どういう時にどのようなサービスを使えば良いのか、またその理由は何なのかを解るように書いています。この辺り、上野さんが最近JAWSUGに幾つか登壇し話しているような内容です。スライド等を見ていただければ、イメージつくのではないでしょうか?

speakerdeck.com

 後はやっぱり練習問題ですね。私は問題を作るという能力にかけているようですが、二人が作る問題は的確でこんな感じで出てきそうというのが取り揃えられています。最後の2択で迷うような引っ掛け問題も用意されていて芸が細かいなぁと思います。当然、解説の方もしっかり説明していて、どうしてその答えが導出されるのか順を追って解説しています。

感想

 日本初のAWS認定試験のスペシャリティの対策本です。期待しておいてください。日本のセキュリティー専門知識の受験者数と合格者数を大幅に増やして、AWS本国の試験担当の人に、日本はなんでセキュリティのスペシャリティだけ突出して高いのだろうと言わせたいです。みんなで認定セキュリティを合格しましょう!!
 あと執筆していて気がついたのですが、プロの対策本を書くよりスペシャリティの方がテーマがハッキリしていて書きやすいなと思いました。売れ行き好調であれば、別のスペシャリティの対策本を書いても良いかなと思い出しています。あとは、プロ本もいよいよ出てきたので、そのうち私もプロ対策本を書くことに挑戦してみようかとも思います。まぁ時間が限られているので、今の宿題を全部片付けてからですが。。。あと個人的には、やっぱりAWS認定を全部取っておかないとという思いを強くしました。あと3つなので、月1個くらいは取れるように精進します。
 現在、最終校正中で目次がまだ確定していません。確定次第、また順次紹介していきます。Amazonは最近書籍の在庫補充が遅いので、一度品切れになると中々買えません。確実に買いたい場合は今のうちに予約しておいてください。それでは、お楽しみに〜

AWS 認定セキュリティ試験対策テキスト

AWS 認定セキュリティ試験対策テキスト

AWS Control Towerの削除

 AWS Control Towerは、複数のAWSアカウントを管理するためのサービスです。AWS Organizationsを構築して、傘下のアカウントのセキュリティとガバナンスを、Security HubとSCPを利用しながらガッチリと守り、各アカウントへのログインにAWS SSOを用意したりと至れり尽くせりなサービスです。
 複数のAWSアカウントを監理している方は、非常に興味を持っているのではないでしょうか?今日は、そんなControl Towerの消し方を御紹介します。

Control Towerと関連AWSアカウントの消し方の手順

 とりあえずControl Towerを評価してみたくて、Control Towerを作ってみたものの消し方が難解すぎて四苦八苦する人を散見するようになりました。そんな人のために、主に自分のために記録を残しておきます。Control Towerとそれによって作られたAWSアカウントの消し方は、次のような流れとなります。

  1. Control Tower の環境クリーンアップを実施する
  2. メンバーアカウントの登録解除
  3. 各アカウントの解約

Control Tower の環境クリーンアップを実施する

 さらっと書いていますが、このControl Towerの環境クリーンアップ(消し方)が大変です。公式ドキュメントにわざわざ消し方が用意されています。

廃止プロセスの概要
Landing Zoneの廃止
廃止処理中に削除されないリソース

 まずControl Towerのランディングゾーンを消すためには、AWSサポートに依頼をする必要があります。サポートレベルは無料のベーシックでも大丈夫ですので、「アカウントと費用に関する問い合わせ」からControl Towerの削除依頼を出します。そうすると、担当のチームに引き継がれ1週間以内くらいで準備がされます。これがControl Tower削除の際の1つ目のつまづきです。

 そうすると、Control Towerの設定ページでランディングゾーンの廃止のボタンが出てきます。おどろおどろしい警告を読んで、チェックすると削除プロセスが開始します。これが結構時間がかかり、数時間は見ておきましょう。

f:id:dkfj:20200629090518p:plain
f:id:dkfj:20200529095312p:plain
f:id:dkfj:20200529095338p:plain
f:id:dkfj:20200529095355p:plain
f:id:dkfj:20200529095416p:plain


 この削除プロセスが終わっても、Control Towerが作った生成物が全て削除される訳ではありません。具体的には、OrganizationsとAWS SSOとS3バケット、傘下のメンバーアカウント(AWSアカウント)が残ります。これらを手動で削除していく必要があります。
docs.aws.amazon.com

 Control Towerだけを消したい場合は、ここまでの作業で大丈夫です。

メンバーアカウントの削除

 Control Towerは、Organizationsを作成時にAuditとLog archiveという名前のAWSアカウントを作成します。

f:id:dkfj:20200629022450p:plain

 これらを削除するのですが、AWSアカウントの削除はルートアカウントでしか行なえません。そして、ルートアカウントのメールアドレスは指定したもののパスワードが解りません。これが2つ目のつまづきがあります。実は、Control Towerからアカウント作成時に、自動的に長い桁数のパスワードが設定され、どこに表示されるでもなく破棄されています。なので、正解はパスワード忘れで、パスワードを再発行することです。

f:id:dkfj:20200629023139p:plain

 別にパスワード忘れていないのにとイラッとしますが細かい事は水に流しましょう。パスワードの設定の際に、どうせすぐ消すからと簡単なパスワードを設定しようとすると、1文字以上の数字・大文字・記号を求められて更にイラッとします。
 無事ログインができると、後はマイアカウントからアカウントのアカウント設定から解約するだけです。AuditとLog archiveのアカウントを解約すると、次のような状態になります。

f:id:dkfj:20200629025243p:plain

 自動生成されたAWSアカウント以外に、他に新規でアカウントを作っている場合はそれも削除しましょう。Organizationsに紐づくアカウントが全てなくなっている。或いは停止状態すると、Control Towerで作ったアカウントも削除できるようになります。マスターアカウントであるControl Towerを作ったアカウントに、ルートアカウントでログインして削除しましょう。

まとめ

 Control Towerを廃止しない状態でも、メンバーアカウントを削除することは可能だと思います。今回は、AWSの公式の手順に従って削除してみました。またControl Towerだけ削除したいケースもあると思いますので、その際は、『Control Tower の環境クリーンアップを実施する』のみを実行してください。
 そもそもControl Towerとはなんぞやと気になっている人がいるとは思うので、おいおい解説します。また、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』という本にも概要を説明していますので、興味があれば是非読んでみてください。

booth.pm

富山IT勉強会で論理登壇してきました

先日開催された富山IT勉強会で、リモートで登壇しました。参加者も全員リモートなので、完全なオンライン勉強会でした。

toyama-it.connpass.com

発表内容と当日の進め方

 当日はIAMの輪読会ということで、最初に私の方からIAM本ならびにAWSアカウントのセキュリティを守るにはという内容で30分くらい話したあとで、今回の会の主催者の@miamo_infraさんから、前半の解説。続いて、後半の気になるところをディスカッションしながら読むというスタイルでした。並行してSlackでコメントや疑問点をつぶやきながら、随時拾っていくということもやっていました。少人数だったので、わりと濃密に出来たのではないかと思っています。
 当日の発表資料はこちらです。

speakerdeck.com

参加の経緯

 富山の勉強会に参加した経緯としては、Twitterからです。東京でIAMの輪読会が開催され、それに@miamo_infraさんが興味をしてしてくれました。私の方も、今年は家族旅行とセットで色々な地方の勉強会に生きたいと思っていたところだったので、ちょうどお互いの思惑がマッチしたということです。
※新型コロナがこんな状況になるとは思っていなかったです。

感想

 初のオンライン登壇でしたが、距離の壁を取っ払えるのは良いなと思いました。うまく活用したら、全国どこでも登壇できるので、これからはオンラインの勉強会にも積極的に参加していきたいと思います。都合が付けばどこでも参加するので、登壇依頼とかお気軽にしてください。また新型コロナが収まったら、物理参加もしたいと思います。目標としては、月1で地方の勉強会に参加したいです。もちろん交通費は自腹なので、その辺りの心配も不要です。

booth.pm

booth.pm

チームの力を自分の力とする

昨日、『技術者であることを諦めない』というタイトルでポエムを書きました。ポエムの内容は、IT業界、特にSIerにいると段々と技術に特化して開発者ですというだけでいるのも難しくなりますよと。でも、自分の技術をアップデートしていくことも重要だよね。時間がなくて大変だよねと、世の中の中年世代の気持ちを代弁する形を装いつつ、自分の感想を述べさせてもらいました。長くなったので分割して、今日は具体的なハウツー的なことを書いています。

チームの力を自分の力とする

 チームのリーダーやマネージャーになって、技術のアップデートをしていくことが厳しくなった場合の私なりのハウツーです。自分の技術力向上のために割く時間が無くなった時に有効な手段が、チームメンバーなど周りの人の力を自分の力としてしまうことです。特定の分野についての知見が必要になれば、それが周りに詳しい人がいれば概要を頭に入れた上で、その人に解らなかった部分や詳しく聞きたい部分を聞けばよいのです。また詳しい人がいないのであれば、メンバーに調査や試行してもらいその結果を教えてもらうのです。その成果を持った上で、その知見を使って打ち合わせなり実際のプロジェクトの遂行なりをしていきます。詳しい人に教えて貰っただけでは、知識のトランスファーとしては5割程度だと思いますが、それを使って自分でやることにより7〜8割の状態に短時間で持っていけます。それでも足りなければ、教えて貰った人を第一人者として連れてきてやってもらえばよいのです。
 このような方法だと、リーダー/マネージャーも短い時間で技術のキャッチアップができます。また技術を提供したメンバーも、人に知識をトランスファーすることにより、より理解が深まります。またチームとして対応できることの多様性が上がり、組織全体としてのケイパビリティが向上します。この話はチームに対して影響力を行使できるという前提での話になってますが、別にそうでなくてもチームメンバー同士でもカジュアルにできる内容かなとも思います。

チームの方向性をリードする

 先程のメソッドは、チームメンバーのリソース(時間)を使うことになります。そのため、全く検討外れの方向にリソースを張ると、そのメンバーに対しても損失だし、チーム全体としても損失になります。つまり、技術動向や今後の事業の方向性を見定めて、どちらの方向に向かっていくのかリードすることになります。これこそが、リーダーやマネージャーの重要な仕事に一つだと考えています。
 注意点としては、方向性を考える上でも、ちゃんとメンバーあるいは外の人間の意見を聞いて自分がずれていないか、絶えずチェックしつづける必要があります。現場から離れれば離れるほど、技術の動向に対する感性は鈍ります。変なプライドを持たず、現場の意見を聞きましょう。一方で、技術の流行り廃りというのに影響されすぎないように注意する必要もあります。例えば、Kubernetesが流行っていると、技術者としては使ってみたくなります。一度検証してみることは大事ですが、自分が向かっている事業・プロジェクトに対して、その技術が本当に合っているのか、そういったことを見極める必要もあります。自分の組織にとって、Too Muchだと思ったら、その論拠を元に現場と対話をしましょう。何も言わずに却下すると恨まれます。

組織を作る

 こういった活動をしていくのは、結局は組織を作っていくことと同じなのだと思います。技術を主題に扱っていましたが、事業に必要なのが業務知識であったり、プロジェクト管理能力だったら、そちらの方を育てていく事になります。リーダーやマネージャーとして重要なのは、自分がメンバーの中で一番優秀であることではなく、メンバーのそれぞれに自分より優秀な分野をどんどん作らせていくことだと思います。最初の方は、どうしても自分がやったほうが早いと思うこともありますが、そこはぐっと我慢です。なぜ、世界は貿易をした方が良いのかの下敷きとなっている比較優位の考え方と同じです。

まとめ

 まぁ、何でこんな話を書いたかの一つは、私は会社の中でAWSが一番詳しい人と認識されている節があるのですが、実際のところは個々の要素の詳細に対しては殆どキャッチアップできていません。だいたい何ができるか把握しておいて、実際に必要になったら(外部の人間を含め)一番詳しい人にお願いしているだけです。そういったやり方もあるんだよというのを言語化してみました。
 一方で、たまに特定分野についてガッツリと知識を得たい場合があります。その時は、IAM本アカウントセキュリティ本のように、自分でまとまった時間を投下してキャッチアップするようにしています。ということで、最後はステマで締めましたが、いかがでしたでしょうか?

See Also:
技術者であることを諦めない

booth.pm