Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
インフラ業務を開発エンジニアへ移譲して
~業務移譲前-業務移譲後-そして今~
自己紹介
株式会社 CyberZ
F.O.X事業 ビッグデータ、イ
ンフラ全般、SRE(現場のエン
ジニア)
twitter: @tkmoteki
facebook:
takahiro.moteki.31
もてき たかひろ
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
業務移譲前(背景) ~2016年5月~
● アドテク事業部は完全なパブリッククラウド ネイティブな会社方
針
● マイクロサービス、マイクロアーキテクチャが浸透
パブリッククラウド 例えば の流
れだと だけでなく、 が多
く開発側にも業務委譲...
業務移譲前(状況分析) ~2016年5月~
開発側は、 AWSインフラ構築/インフラオペレーションは“権限”がない、出来ない
業務レベルのインフラ権限を解放していない
例)
• EC2作成/構築
• ELBのオペレーション
• Lambdaの作...
開発エンジニアへ
インフラ業務を移譲しようか MGR
MGR僕
なるほど、
インフラ強い人とかで数
絞ってやりますか
んあ、開発局のエンジニア全員
え? 育成コスト、運用コスト
を考えると全員は現実的で
はないですね、、、
んあ、無理。
理由はみんな出来るようになっ
て欲しいから
んあ、じゃあ後よ...
壁(現場分析) ~2016年5月~
開発エンジニアはインフラ業務実績/経験がない(今
までインフラエンジニアがやっていたため)
世間一般的な中途インフラエンジニア並のスキル 知
識がない
既存のオンプレ のインフラ環境があり相互連携も発生する…...
社内プロジェクト始動:
インフラ技術向上PJ
目的
「実績ないインフラ実業務に対して、
 インフラエンジニアの専門的なノウハウ、
  スキルを養い、
   インフラ技術力を向上すること」
方針 期待したエンジニア像 ~2016年6月~
○ 開発エンジニアがインフラ業務に明るくなりインフラ業務を積
極的にやって欲しい
□ 肌感イメージ
□ インフラ業務も行う 開発エンジニア
□ わからない事 不安なこと 旧インフラエンジニアに相談...
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
準備したこと ~2016年6月~
○ インフラ技術向上PJ運営チームを用意した
○ インフラの体制再考した
○ 育成カリキュラムを組んだ
○ 現状のインフラ環境/システムを再設計した
インフラ技術向上PJ運営チームを
用意した
育成
(僕 元インフラエンジニア)
報告者
(MGR)
第三者のレビュアー
(インフラエンジニア)
僕は育成のプロではないです、現場で叩き上げでやってきた現場の一エンジニアで
す
インフラ体制再考した ~2016年6月~
~詳細説明は省略~
関係組織モデル再考
業務役割モデル再考
インフラ体制再考した ~2016年6月~
~詳細説明は省略~
認証・認可構成
権限設計
育成カリキュラムを組んだ(進め方)1. ~2016年6月~
~インフラエンジニア(僕)が開発エンジニアへ実施~
○ 個人レベルで目標すり合わせ、ヒアリング、スケジュール相談
○ 非同期学習&レビュー -> 一般的な仕様やサービス知識
□ 読み物...
育成カリキュラムを組んだ(進め方)2. ~2016年6月~
ちょうどオンプレミスからクラウド環境へ全面移行。
この移行しながら、移行先のインフラ環境やれるところでハンズオンを実施
● 実現場のインフラ業務に勝る育成方法はないと思った
● 自身の...
育成カリキュラムを組んだ(内容) ~2016年6月~
フェーズ 大項目 ライン
仮想サーバと の知識 ネットワークの知識
負荷分散の知識
の知識
認証・認可の知識
基盤 構成管理 統合自動化基盤 ミドルウェア
基盤 モニタリング、監視
基盤 イ...
現状のインフラ環境/システムを再設計した ~2016年6月~
開発プロダクト
B(組織B)
開発プロダクト
A(組織A)
開発プロダクト
C(組織C)
○ AWSアカウント
○ 各種基盤
□ 自動化系、監視系など
インフラエンジニアで構築 /運...
“開発エンジニアへ周知/展開。
インフラ技術向上PJ フェーズ1(AWS)スタート
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
インフラ技術向上PJ 問題点 ~2016年7月~
誰もやってくれなかった。。。
インフラ技術向上PJ 原因/対策 ~2016年7月~
○ 原因 : 誰もやってくれないではなくて、育成側の時
間が抑えられない(いつでもいいよ、で案内してい
た)
○ 対策 -> インフラ技術向上PJ専用日を作り、枠を設
けた
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
インフラ技術向上PJ ~2016年9月~
大量の問題点、、、
インフラ技術向上PJ問題点 ~2016年9月~
○ 言われた通りの事しかやれない、伝えた事しか答えられない
○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい
○ 権限を付与するのが目的になってしまった
インフラ技術向上PJ 対策 ~2016年9月~
○ 言われた通りの事しかやれない、答えられない
○ 対策 -> 逆ハンズオン
逆ハンズオン ・・・実際にインフラ業務(お題)を出す。開発エンジニアがデモンストレーション
(実作業)しながらへインフ...
インフラ技術向上PJ 対策 ~2016年9月~
○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい
○ 対策 -> 希望があった人のみ基準表をつくり、個人レベルで起票
した
Aさん Bさん
インフラ技術向上PJ 対策 ~2016年9月~
○ 権限を付与するのが目的になってしまい、インフラ
の理解力が低下した
○ 対策 -> ライン:その他サービス構築新設
既存運用しているインフラ環境の問題点を見つけて、自由な発想で考え、改善案を提...
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
インフラ技術向上PJ ~2016年10月~
フェーズ2(AWS以外の社内基盤)がスタート
インフラ技術向上PJ 問題点 ~2016年10月~
フェーズ2取り組めない、、
インフラ技術向上PJ 対策 ~2016年10月~
○ 原因 : 敷居が高い、作業時間がかかる
○ 対策 : 既存基盤を効率使える仕組みを用意し敷
居を下げた
□ ワークフローを定義
□ スケルトンモデル(sample)を用意
(ワークフロー追加...
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
インフラ技術向上PJ ~2016年12月~
フェーズ2(AWS以外の社内基盤)終了
フェーズ1のみ達成
半分/開発局エンジニア全員
フェーズ1 + 2達成
2割/開発局エンジニア全員
達成した人から順次業務移譲。茂木はファシリテータへ
agenda
移譲前 移譲中 移譲後 今
2016年5月
2017年2月
2016年6月
2016年9月
2016年10月
2016年12月
時系列で説明
2016年7月
インフラ技術向上PJ 今
より理解を深めるため達成した人(開発エン
ジニア)へ”教える事”を移譲した
やらせる
伝える/
見せる
教える
達成したエンジニアがそれぞれメンターになって、達成していない人へレクチャー
教えてみることで、さらに理解を...
インフラ技術向上PJ 今の問題点 ~2017年2月~
○ チーム(プロジェクト)属人化問題
□ 現状プロダクトの中に開発チームが複数あり、新しい仕組みを入れてもプロジェクト横断した横
転ができない
□ 以前はインフラエンジニアが複数の開発チーム...
インフラ技術向上PJ 今の問題点 ~2017年2月~
○ ホウ・レン・ソウの認識違い
□ 開発エンジニアとインフラエンジニアとではホウ・レン・ソウに違いがある
□ そもそも育成側としても未考慮
□ 業務移譲する(任せる) = ホウ・レン・ソウし...
最後に、、、
運営側として心がけたこと(学んだこと含)
時間がないのでエピソードは省略
運営側として心がけたこと(学んだこと含)
○ 相手側への歩み寄り
○ 素直な技術コミュニケーション
○ 即日/翌日FBK
○ 当たり前の事を当たり前に行う事
相手側への歩み寄り
● 個人 個人と向き合って、議論して、伝え方/やり方を変える事
● 受ける側の”悩み”は一緒に解消する
● 受ける側が受け入れられないカリキュラム(やり方)はクソ
● 何も知らない事に対して、受ける側が理想すぎるものは、たい...
素直な技術コミュニケーション
● 納得させるんじゃなくて、お互い納得し合う事
● 無理に納得させようとしても拒絶する
● 建設的に議論する
● なんとも言えない、微妙だったりする事を無理やり正論づけない
● エンジニアとしてウソは厳禁だが上記に...
即日/翌日FBK
● 新しく学ぶ内容ほど、期間が開くと学びずらい(覚えにくい)
○ コンテキストスイッチを最小化させる
● FBKやレビューを放置すると、受ける相手に育成側は信頼されない
● githubレビュー、口頭、chat同様
当たり前の事を当たり前に行う事
● 今回の育成は工数の都合上長期プロジェクト
● 当たり前の事を当たり前に行うって案外難しい
● 長期プロジェクトになればなるほど、当たり前の事を当たり前に行えなくな
る
● 例) 育成側としてのホウ・レン・ソウ...
今後
○ “今”の課題に向き合っていく
○ 業務移譲後の効率性を数値化して振り返り
□ 実績調査やアンケートなど
インフラ技術向上PJ
プロジェクトとしては終了
新しい体制でスタートをきって運用中
今後も”今”の課題に向き合っていく
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
Do you like scala
Next
Download to read offline and view in fullscreen.

21

Share

Download to read offline

[社内合同勉強会]インフラ業務を開発エンジニアへ移譲して 移譲前-移譲後-そして今-

Download to read offline

[社内合同勉強会]@20170222

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

[社内合同勉強会]インフラ業務を開発エンジニアへ移譲して 移譲前-移譲後-そして今-

  1. 1. インフラ業務を開発エンジニアへ移譲して ~業務移譲前-業務移譲後-そして今~
  2. 2. 自己紹介 株式会社 CyberZ F.O.X事業 ビッグデータ、イ ンフラ全般、SRE(現場のエン ジニア) twitter: @tkmoteki facebook: takahiro.moteki.31 もてき たかひろ
  3. 3. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明
  4. 4. 業務移譲前(背景) ~2016年5月~ ● アドテク事業部は完全なパブリッククラウド ネイティブな会社方 針 ● マイクロサービス、マイクロアーキテクチャが浸透 パブリッククラウド 例えば の流 れだと だけでなく、 が多 く開発側にも業務委譲した方が良い インフラエンジニア不足
  5. 5. 業務移譲前(状況分析) ~2016年5月~ 開発側は、 AWSインフラ構築/インフラオペレーションは“権限”がない、出来ない 業務レベルのインフラ権限を解放していない 例) • EC2作成/構築 • ELBのオペレーション • Lambdaの作成/構築 • ansibleでOS/ミドルウェア自動化 随時インフラ局へ依頼 開発スピードが出ない インフラ運用を意識した 設計が出来ない インフラがクローズド , 開発エンジニアとインフラエン ジニアの連携問題 障害対応にロス (開発エンジニアと インフラエンジニアが必要 )
  6. 6. 開発エンジニアへ インフラ業務を移譲しようか MGR
  7. 7. MGR僕 なるほど、 インフラ強い人とかで数 絞ってやりますか んあ、開発局のエンジニア全員 え? 育成コスト、運用コスト を考えると全員は現実的で はないですね、、、 んあ、無理。 理由はみんな出来るようになっ て欲しいから んあ、じゃあ後よろしく (トコトコ) え?(理由じゃない...)
  8. 8. 壁(現場分析) ~2016年5月~ 開発エンジニアはインフラ業務実績/経験がない(今 までインフラエンジニアがやっていたため) 世間一般的な中途インフラエンジニア並のスキル 知 識がない 既存のオンプレ のインフラ環境があり相互連携も発生する… 新規プロジェクトではないものが大半 それをいきなり開発エンジニアによろしく は…無茶だ
  9. 9. 社内プロジェクト始動: インフラ技術向上PJ
  10. 10. 目的 「実績ないインフラ実業務に対して、  インフラエンジニアの専門的なノウハウ、   スキルを養い、    インフラ技術力を向上すること」
  11. 11. 方針 期待したエンジニア像 ~2016年6月~ ○ 開発エンジニアがインフラ業務に明るくなりインフラ業務を積 極的にやって欲しい □ 肌感イメージ □ インフラ業務も行う 開発エンジニア □ わからない事 不安なこと 旧インフラエンジニアに相談する ○ 自主的にインフラ技術の最新動向を追い、キャッチアップし ていける ○ インフラ業務経験 実績をつくり、エンジニアとしての市場価 値を高めていってほしい
  12. 12. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  13. 13. 準備したこと ~2016年6月~ ○ インフラ技術向上PJ運営チームを用意した ○ インフラの体制再考した ○ 育成カリキュラムを組んだ ○ 現状のインフラ環境/システムを再設計した
  14. 14. インフラ技術向上PJ運営チームを 用意した 育成 (僕 元インフラエンジニア) 報告者 (MGR) 第三者のレビュアー (インフラエンジニア) 僕は育成のプロではないです、現場で叩き上げでやってきた現場の一エンジニアで す
  15. 15. インフラ体制再考した ~2016年6月~ ~詳細説明は省略~ 関係組織モデル再考 業務役割モデル再考
  16. 16. インフラ体制再考した ~2016年6月~ ~詳細説明は省略~ 認証・認可構成 権限設計
  17. 17. 育成カリキュラムを組んだ(進め方)1. ~2016年6月~ ~インフラエンジニア(僕)が開発エンジニアへ実施~ ○ 個人レベルで目標すり合わせ、ヒアリング、スケジュール相談 ○ 非同期学習&レビュー -> 一般的な仕様やサービス知識 □ 読み物,構築など ○ ハンズオン -> 僕と2人で個別でハンズオン □ オペレーションなど ○ グループワーク -> グループ単位でハンズオン ○ ワークショップ -> 体制から文化、インフラの仕事的なところ
  18. 18. 育成カリキュラムを組んだ(進め方)2. ~2016年6月~ ちょうどオンプレミスからクラウド環境へ全面移行。 この移行しながら、移行先のインフラ環境やれるところでハンズオンを実施 ● 実現場のインフラ業務に勝る育成方法はないと思った ● 自身の開発したサービスが動かなくなるため、取り組む ”必要性”が出てくる 開発エンジニアは開発業務と調整つけ並行してやっていくので、長いプロジェクトになりそうだなぁ ...
  19. 19. 育成カリキュラムを組んだ(内容) ~2016年6月~ フェーズ 大項目 ライン 仮想サーバと の知識 ネットワークの知識 負荷分散の知識 の知識 認証・認可の知識 基盤 構成管理 統合自動化基盤 ミドルウェア 基盤 モニタリング、監視 基盤 インフラのログ収集 加工 活用 管理 必須ワークショップ フェーズ1 : AWS関連, フェーズ2 : AWS以外 社内基盤関連, ワークショップ : スタートアップ(インフラの業務についてなど )
  20. 20. 現状のインフラ環境/システムを再設計した ~2016年6月~ 開発プロダクト B(組織B) 開発プロダクト A(組織A) 開発プロダクト C(組織C) ○ AWSアカウント ○ 各種基盤 □ 自動化系、監視系など インフラエンジニアで構築 /運用してきた もの全てが、プロダクト (組織)で相乗り で使用 開発プロダクトA(組織A)の開発エンジ ニアが安全にインフラ業務を行えるよう に再設計 僕 インフラ業務を行う開 発エンジニア
  21. 21. “開発エンジニアへ周知/展開。 インフラ技術向上PJ フェーズ1(AWS)スタート
  22. 22. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  23. 23. インフラ技術向上PJ 問題点 ~2016年7月~ 誰もやってくれなかった。。。
  24. 24. インフラ技術向上PJ 原因/対策 ~2016年7月~ ○ 原因 : 誰もやってくれないではなくて、育成側の時 間が抑えられない(いつでもいいよ、で案内してい た) ○ 対策 -> インフラ技術向上PJ専用日を作り、枠を設 けた
  25. 25. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  26. 26. インフラ技術向上PJ ~2016年9月~ 大量の問題点、、、
  27. 27. インフラ技術向上PJ問題点 ~2016年9月~ ○ 言われた通りの事しかやれない、伝えた事しか答えられない ○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい ○ 権限を付与するのが目的になってしまった
  28. 28. インフラ技術向上PJ 対策 ~2016年9月~ ○ 言われた通りの事しかやれない、答えられない ○ 対策 -> 逆ハンズオン 逆ハンズオン ・・・実際にインフラ業務(お題)を出す。開発エンジニアがデモンストレーション (実作業)しながらへインフラの説明してもらう(質疑応答) ~インフラエンジニア(僕)と第三者インフラエンジニアへ説明~
  29. 29. インフラ技術向上PJ 対策 ~2016年9月~ ○ 具体的に何を理解すれば良いのか、項目含め基準が知りたい ○ 対策 -> 希望があった人のみ基準表をつくり、個人レベルで起票 した Aさん Bさん
  30. 30. インフラ技術向上PJ 対策 ~2016年9月~ ○ 権限を付与するのが目的になってしまい、インフラ の理解力が低下した ○ 対策 -> ライン:その他サービス構築新設 既存運用しているインフラ環境の問題点を見つけて、自由な発想で考え、改善案を提示。 本番環境で運用できるシステムを作る (やってみた!はNG)。 インフラの業務システムを見積もりから、アーキ設計、構築までインフラフルスタックで行うもの。 成果物例) ● 「CloudWatch Events + Lambda」で構築するDynamic DNS ● 「CloudFormationを用いた負荷環境のインフラ動的生成と破棄、 immutable infrastructureの実践」
  31. 31. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  32. 32. インフラ技術向上PJ ~2016年10月~ フェーズ2(AWS以外の社内基盤)がスタート
  33. 33. インフラ技術向上PJ 問題点 ~2016年10月~ フェーズ2取り組めない、、
  34. 34. インフラ技術向上PJ 対策 ~2016年10月~ ○ 原因 : 敷居が高い、作業時間がかかる ○ 対策 : 既存基盤を効率使える仕組みを用意し敷 居を下げた □ ワークフローを定義 □ スケルトンモデル(sample)を用意 (ワークフロー追加定義するくらいだったら、ワークフローを定義せざるをえなくなった、 基盤自体を根幹から見直す必要あったが、時間もなくバンソウコウ対応 )
  35. 35. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  36. 36. インフラ技術向上PJ ~2016年12月~ フェーズ2(AWS以外の社内基盤)終了 フェーズ1のみ達成 半分/開発局エンジニア全員 フェーズ1 + 2達成 2割/開発局エンジニア全員 達成した人から順次業務移譲。茂木はファシリテータへ
  37. 37. agenda 移譲前 移譲中 移譲後 今 2016年5月 2017年2月 2016年6月 2016年9月 2016年10月 2016年12月 時系列で説明 2016年7月
  38. 38. インフラ技術向上PJ 今 より理解を深めるため達成した人(開発エン ジニア)へ”教える事”を移譲した やらせる 伝える/ 見せる 教える 達成したエンジニアがそれぞれメンターになって、達成していない人へレクチャー 教えてみることで、さらに理解を深める
  39. 39. インフラ技術向上PJ 今の問題点 ~2017年2月~ ○ チーム(プロジェクト)属人化問題 □ 現状プロダクトの中に開発チームが複数あり、新しい仕組みを入れてもプロジェクト横断した横 転ができない □ 以前はインフラエンジニアが複数の開発チームを見ていたためチーム (プロジェクト)属人化問 題は目立たなかった ○ インフラの運用管理保守の事前設計/実装が弱い □ 見積もり、構成、キャパシティ、様々な要素を見越して、考慮して行うインフラの運用管理保守 □ “何か事故”ってから対策を立てるのではなく、リリース前に事前に対策 /実装を行う □ 事故る前に事前策/実装が出来る -> プロ □ 事故った後で事後対策 /実装をする -> 素人 □ 簡単な例) S3は99.999999999%の高可用性でデータ入れればとりあえず安心 -> いや、オペミス したらデータ消える □ エンタープライズ領域のエコシステムや基幹システムほど超重要
  40. 40. インフラ技術向上PJ 今の問題点 ~2017年2月~ ○ ホウ・レン・ソウの認識違い □ 開発エンジニアとインフラエンジニアとではホウ・レン・ソウに違いがある □ そもそも育成側としても未考慮 □ 業務移譲する(任せる) = ホウ・レン・ソウしなくていいよ、は間違い。 ○ 複数インフラが絡むシステム、通信、データの関係性理解 低下 □ そもそも育成側としても未考慮 ○ インフラの小さなミスが全体として目立ち品質低下 □ 単純にインフラ業務を行う人が増えて目立った □ そもそも環境がレガシーだから
  41. 41. 最後に、、、 運営側として心がけたこと(学んだこと含) 時間がないのでエピソードは省略
  42. 42. 運営側として心がけたこと(学んだこと含) ○ 相手側への歩み寄り ○ 素直な技術コミュニケーション ○ 即日/翌日FBK ○ 当たり前の事を当たり前に行う事
  43. 43. 相手側への歩み寄り ● 個人 個人と向き合って、議論して、伝え方/やり方を変える事 ● 受ける側の”悩み”は一緒に解消する ● 受ける側が受け入れられないカリキュラム(やり方)はクソ ● 何も知らない事に対して、受ける側が理想すぎるものは、たいてい受ける側 のためにならない ● そのために、その分解点を個人個人で議論する ● 面倒くさがってたら、始まらない
  44. 44. 素直な技術コミュニケーション ● 納得させるんじゃなくて、お互い納得し合う事 ● 無理に納得させようとしても拒絶する ● 建設的に議論する ● なんとも言えない、微妙だったりする事を無理やり正論づけない ● エンジニアとしてウソは厳禁だが上記にも配慮しよう ● 結果エンジニアとして”信頼されない”から ● 「なんとも言えないです、調べます」って言えばいいと思う ● 知らない、わからないは、はっきり言う ● 知らないことを知らないと言える人ほど、知ってる事を教えてもらう場合に 信頼を得やすい (仕事で僕が一番意識していることでもあります)
  45. 45. 即日/翌日FBK ● 新しく学ぶ内容ほど、期間が開くと学びずらい(覚えにくい) ○ コンテキストスイッチを最小化させる ● FBKやレビューを放置すると、受ける相手に育成側は信頼されない ● githubレビュー、口頭、chat同様
  46. 46. 当たり前の事を当たり前に行う事 ● 今回の育成は工数の都合上長期プロジェクト ● 当たり前の事を当たり前に行うって案外難しい ● 長期プロジェクトになればなるほど、当たり前の事を当たり前に行えなくな る ● 例) 育成側としてのホウ・レン・ソウ ● どんなに技術やスキルや経験があっても、ホウ・レン・ソウ出来ないと仕事 として信頼されない。頑張ってたって仕事で信頼されない
  47. 47. 今後 ○ “今”の課題に向き合っていく ○ 業務移譲後の効率性を数値化して振り返り □ 実績調査やアンケートなど
  48. 48. インフラ技術向上PJ プロジェクトとしては終了 新しい体制でスタートをきって運用中 今後も”今”の課題に向き合っていく
  • ayumitada126

    Mar. 16, 2018
  • YousukeKusano

    Mar. 10, 2018
  • tarfukui

    Mar. 10, 2018
  • hiroishibashi

    Jun. 9, 2017
  • hiroishibashi

    Jun. 9, 2017
  • hiroishibashi

    Jun. 9, 2017
  • hiroishibashi

    Jun. 9, 2017
  • hiroishibashi

    Jun. 9, 2017
  • hiroishibashi

    Jun. 9, 2017
  • ssuserff8d04

    Jun. 8, 2017
  • tomofusa

    Jun. 6, 2017
  • nekogeruge_987

    May. 26, 2017
  • YosukeSato2

    May. 26, 2017
  • YutaShimakawa

    May. 26, 2017
  • oobayashi

    May. 26, 2017
  • syamaguchi

    May. 24, 2017
  • ShuheiNagasawa

    May. 22, 2017
  • yoshifuji

    Mar. 9, 2017
  • but8

    Feb. 27, 2017
  • clone777

    Feb. 25, 2017

[社内合同勉強会]@20170222

Views

Total views

4,298

On Slideshare

0

From embeds

0

Number of embeds

457

Actions

Downloads

7

Shares

0

Comments

0

Likes

21

×