AWS事業部でのマネジメントを通じて学んだこと

AWS事業部でのマネジメントを通じて学んだこと
クラスメソッドのMeetup #もしメソ
2017年2⽉22⽇
AWS事業部能登諭

⾃⼰紹介
!
⽒名：能登諭（のとさとし）
!
所属：AWS事業部サービス開発グループ
!
担当：グループマネージャー
!
Twitter：@n3104
2
http://dev.classmethod.jp/project-management/taisa-meet-aws-manager/

AWS事業部の紹介：仕事内容
!
アーキテクトG：プリセールス、コンサル、構築
!
オペレーションG：AWSサポート代⾏、運⽤⽀援
!
サービス開発G：AWSを使いやすくするサービスの開発
3
AWSインフラをまるっとお任せ！

略歴 - ⼊社前 -
!
約12年で20案件（PM3件、PL7件）
!
アプリケーションエンジニア
!
AWS未経験
!
2013年11⽉⼊社、4年⽬（5社⽬）
4

略歴 - ⼊社後 -
!
約3年で45案件
!
システム開発/保守/運⽤（PM、PL、PG、インフラ）
!
インフラ構築、負荷試験、監視設定（PM、インフラ）
!
コンサルティング（AWS全般、EMR）
!
AWSサポート業務（EMR、CloudFront）
!
ビジネス⽴ち上げ（ビッグデータ、機械学習）
!
プリセールス（ビッグデータ、機械学習）
!
登壇、執筆、認証取得、etc...
5

AWS事業部で学んだこと
!
不安にさせない
!
進めながら決める
!
条件付きOKを出す
6

!
!
!
7

案件開始直後は実績がないのでお客様は不安
（信⽤してもらえるまでは細かな連絡が必要）
8

進捗の遅れや障害が多発すると細かな報告が必要になる
（そして更に遅れる）
9

最初に次のアクションを述べるようにする
（話がどこに⾏くのか不安になるし、
議論が脱線しやすくなる）
10

!
案件の開始直後は実績がないのでお客様も不安で、最初
は細かな報告をするなどして⼯数が取られる。
!
進捗の遅れや障害が多発すると細かな報告が必要にな
り、かえって⼯数が取られる。
!
最初に次のアクションを提⽰する。その上で課題点につ
いて説明する。対策が⽤意されているか不安になってし
まう。
!
とはいえ、気になることを共有するのは重要。そもそも
発⾔しなくなったらリスクが増えるだけ。
11

!
!
!
12

使ったことがない技術でも⾒積もりを出すことはある
（そして検証フェーズを⼊れておく）
13

お客様も最初の要件を間違えていたり、
ビジネス環境が変わることもある
（そして仕様変更が発⽣する）
14

そもそもやってみないと分からないことがある
（そして経験することで⾒通せる範囲は増えるが
全てを⾒通せるわけでもない）
15

!
やったことがないことは、ある程度までは⾒通しがつい
ても、それより先は実際にやってみないと分からない。
!
お客様も同じ。最初から⾒通せているわけでもないし、
最初から全て決めているわけでもない。全部決まってい
るわけでもない。最初に決める必要もない。
!
だからこそ、⼀緒に考えていくという態度が重要。
!
とはいえ、机上検証を疎かにしていいと⾔っているわけ
ではない。軌道修正するコストは後になるほど⼤きくな
る。
16

!
!
!
17

仕様変更や機能追加は仕事が増える
（そして何らかの調整を⾏う）
18

お客様の当初の要望と⾃社の提供範囲が異なる
（やはり調整する）
19

!
エンジニアだと 0 or 1 で考えがち。実際はその間があ
る。
!
依頼や相談があった際に、「出来ません」「やれませ
ん」ではなく「こういう条件/前提ならできる」とか
「ここまでならできる」と回答する。
!
依頼者は最初の要件が全て満たされなくても意外に満⾜
してくれる。そもそも、依頼者が正しい要求をしている
とは限らない。
!
とりあえず話してみる。決めつけない。
20

!
!
!
21

AWS事業部でのマネジメントを通じて学んだこと

Recommended

Recommended

More Related Content

Featured

Featured (20)

AWS事業部でのマネジメントを通じて学んだこと