[総指名額1000億円突破記念キャンペーン実施中!!](https://job-draft.jp/articles/407)

taso0505

自己推薦一覧

自己推薦はありません

3年後の目標や野望


事業会社でエンジニアマネージャーとして、エンジニア組織を強固な形に牽引する

事業側でバリューを出す経験をした際に「次世代の育成」に試行錯誤をした その内容に面白みを感じたので、今度はエンジニアの育成や組織の醸造にミッションを追ってコミットしたいと考えた

年収評価シート

2015年/2年以上

商用Webシステム基盤の定型運用業務チームマネジメント・課題解決

[概要]商用Webシステム定型業務担当チームマネジメントと安定運用 [規模]22名(自社4名、協力会社18名、530人月) [役職]チームリーダー [担当]チーム方針設定とモニタリング、安定運用に向けた業務改善推進 [環境]自社 [課題]  1.20名超えの体制だが、チームの業務量と必要工数がブラックボックスで、   適正化できていない。  2.業務で必要なドキュメントが存在せず、業務の内容や品質・納期が   属人化している。  3.上記状況であるにもかかわらず、業務改善が全くされず、   凝り固まった業務になっている。 [成果]  1.confluenceとJIRAを用いて、インフラチームで対応している業務と作業量を   定量的に可視化し、月ごとの業務量と必要工数のシミュレーションを可能にした。   その結果、20名超えの体制から-6名で同じ量の業務を行うことが出来た。   (年間6,000万円のコスト削減)  2.有識者で業務内容の棚卸しとウォークスルーを行い、confluenceに業務フローと   手順を整備していくことで、属人的でない業務を実現する事に成功した。   また、slackをコミュニケーションツールとして導入する事で、オープンな議論を   可能にし、困っている事やトラブルをプロアクティブに吸い上げる事で、   より高い生産性を実現する事ができた。   また、納期短縮/コスト短縮をするためにansibleを導入し、事業側ともKPIを   再定義を合意して、定常作業の自動化を実現した。   自分で手を動かしてエンジニア作業を実施し、そこからの気づきをメンバーへフィードバック   することで納得感のある業務改善のサイクルを回せるように注力した。  3.私を中心に現状の業務を「課題→原因→解決策→効果」というフレームワークで   棚卸しを行い、まずは課題・改善ポイントを可視化した。   進めて行く経緯をconfluenceに残す事で、業務改善のベストプラクティスとして   他のメンバが何か改善のアプローチをしようとする時のサンプルとした。   PDCAサイクルを回すための業務改善プロジェクトを立ち上げ、定期的に   改善ポイントの抽出と対応計画の立案を行うスキームを装着した。 [工夫した点]  ・業務改善を経験したことない若手メンバがたくさんおり、「なぜ変える必要があるか?」   「変えた先に何をしたいか?」を摺合せする事で、中長期的にKPIをハイレベルで達成して   いきたいというマインドを醸造した。  ・ITILの資格を取得していた為、メンバに対して勉強会を開催し、サービスマネジメントの   あり方や考え方、スキル・ナレッジをトランスファーした。  ・実務におけるヒヤリハットを共有することで、メンバの意識向上を促し、伴走することで   知識の習得を効率化した。

2017年/2年以内

事業会社へのSRE装着

[概要]SUMMOに対するSRE活動 [規模]25名(自社5名、協力会社20名、40人月) [役職]担当リーダー [担当]SRE活動の下地作りとチーム運営PMO [環境]自社 [課題]  1.インフラの業務内容が不透明(業務一覧、役割分担、責任分界点、など)で   何かインシデントが起きたときのアクションが遅くなってしまう。  2.インフラの業務状況が不透明(インシデント件数、申請対応数、など)で   KPIもなく、今が良いのか悪いのかすら把握できない。  3.業務フローや手順書が整備されておらず、運用がブラックボックス。   特定メンバが不在の場合、業務が滞ることもあった。 [成果]  1.confluenceを用いて、インフラチームで対応している業務を整理し、   カテゴライズした業務一覧を作成。   関係各所と認識合わせを行い、インフラの役割分担と責任分界点を合意した。   合意した責任分界点を意識しつつもシナジーを生み出す為のコミュニケーション領域を   slack上に構築し、ブレストや検討を行える透過性の高さを生み出した。  2.業務をモニタリングする基盤をJIRAで構築し、JIRAを活用した業務フローを整備し、   インシデント件数や依頼業務の対応状況、メンバのスキル偏りを可視化し、   リアルタイムに確認できるようになった。   システムのモニタリング情報(JIRA / Datadog)はslackヘ連携する事で、システマチックに解決した。  3.有識者から業務をヒアリングし、confluenceを用いて業務フローを可視化。   他のメンバでも対応可能にした。   また、各自で作っていたツールをGithubに集約し、共有のサーバで稼働させることに成功した。   共有のサーバはRHEL+Dokerで構築し、コンテナ上で稼働させた。   また、業務はansibleのplaybookに落とし込み、インフラメンバなら誰でも作業できる状態を   作り込んだ。 [工夫した点]  ・今までの運用で苦労していないメンバもおり、やり方を変えることに対してハレーションが   起きないように「なぜこの活動をするか?」「この活動をすることで何が得られるか?」を   メンバに腹落ちするまで説明し、協業して進めるようにした。  ・インフラといっても範囲が広いので、通常運用を担当するメンバと課題解決を担当するメンバに   役割を分けて、チーム内で責任分界点を明確にすることで、当事者意識を醸造し、   生産性を上げるようにした。  ・自分のPCにvagrant+virtualboxで環境を作り、その中でansibleやDockerを稼働させることで   実際にサーバを構築する前に上位層へデモを行なった。

2018年/2年以内

インターネット広告配信システムのDevOps

[概要]インターネット広告配信システムのDevOps [規模]5名(自社3名、協力会社2名) [役職]チーフエンジニア [担当]DevOpsの推進と既存業務のリファクタリング(通常の設計・構築・運用も管理から実作業まで担当) [環境]自社 [課題]  1.過去のインシデントに対するアプローチや対策が人の頭の中に存在していることで、   ナレッジが継承されて行かず、運用の再現性がない。  2.ansibleで構築/運用をしているが、ドキュメントがなく、他のメンバが利用できない状況。  3.上場企業の内部/外部監査に耐えうるセキュリティになっていない。 [成果]  1.過去の作業をRedmine、slack、JIRAから抽出し、インシデント対応の手順を   リバースエンジニアリングした。(自動化できるものはplaybook化した)   ドキュメントはエンジニアが読みやすいようにMarkdownで作成。   今後の作業をJIRAで管理し、JIRAで作業管理、インシデント管理、課題管理など   プロジェクトを回すうえで必要な統合管理基盤をITIL、スクラムマスターの知見を   活用しつつ、構築した。   また、対応したタスクや手順はナレッジDBとして、Githubに蓄積し、チームメンバ以外からも   参照可能にすることで、自チーム以外でも利活用できるようにした。   (フィードバックをもらうことで、より良いものへブラッシュアップしていく)   上記に加えて、DevOps / CSIRTの組織を1から立ち上げ、運営する事で関係者とのシナジーを   創出する事に成功した。  2.ansibleはコマンドだけ知っていれば実行できてしまうリスクもあるので、実行前に参照すべき   ドキュメントおよび「playbookのコーディング規約」を新たに制定した。   また、手作業で行なっているものを随時ansibleへ移行することで生産性の向上と再現性の担保を   可能にした。   ansibleへ移行する際に検証環境をデータセンターのラッキングから全ての設定を自前で行い、   作成ー廃棄ー再構築を実施する中でナレッジの蓄積も合わせて行った。   最終的にはAnsibel TowerやJenkins等のマネジメントツールを使うことで、オペミスの確率を低減し、   実行履歴の管理などのセキュリティ対応も実装する予定である。  3.まずは「当社のセキュリティ要件」の整備から着手、ベストプラクティスを参考に   「何を脅威」とし、「どのように防ぐか?」を中心に検討を行なった。   外部よりも内部への対応が薄いと分析し、アクセスログの収集や確認の業務フローを立案。   特権に特化したセキュリティ対策を設計することで監査での指摘事項を減少させることに成功した。   また、東証に上場したこともあり、より強固なセキュリティ対策が必要と考え、情報漏洩や   改ざん等の対策をプロアクティブに計画している。   また、1.の記載と重複するが、CSIRTの組織を1から立ち上げ、運営する事で関係者との   シナジーを創出する事に成功した。 [工夫した点]  ・参画直後からサイロ化している状況であったので、現状調査と分析に時間をかけ、   「今がどういう状況なのか?」をQDCを軸に明らかにしていった。   今を見れば問題はないが、再現性のない運用をしていることが一番のリスクと捉えて、   再現性の高い運用を実現すべく、実績のある手順を抽出して可視化することで、   今後起こりうるインシデントへの対策をプロアクティブに講じた。  ・「業務の可視化」が出来ておらず、属人的になっている業務を1つ1つひも解き、   生産性を可視化するところから着手する事で、改善の効果も見える化した。  ・セキュリティはあまり考慮されていない状況であったので、ITILやIPAが提示する内容を   ベースに守るべきセキュリティ要件を明確化し、優先順位をつけて実装を行なっている。  ・関係する組織との協業を意識し、どうすればより良いモノ作りが出来るか?という観点を常に持ち、   組織を立ち上げ、加速的に業務改善を推進する事を心掛けた。

マネージメント能力

課題解決プロジェクト
商用Web基盤のQCD目標の達成に向けたKPIの達成
オペレーションミスやコミュニケーションロスによるインシデントが多いという状況の中、課題解決プロジェクトのPMを担当。 インシデントの根本原因を分析すると、今まで属人化していた業務のやり方に問題があり、秘伝のタレのような業務フローである事から、担当者に品質が依存している状況であった。 有識者と業務の棚卸し・ウォークスルーを実施する事で業務を明文化していき、標準化する事でオペレーションミスやコミュニケーションミスが起きにくい業務フローを作り上げることが出来た。 また、クローズなコミュニケーションをやめて、slackを用いてオープンなコミュニケーションをすることで業務の透明性を上げる事にもつながった。

サービスデスクチーム
メンバの育成、チームの最適化
サービスデスクチームは総勢20名の態勢で業務量よりも人数が多く、生産性が低いと思われる状況であった。 そこにリーダーとして参画し、業務の可視化と稼働実績を分析した。 結果として、業務における不要なチェック体制があることと、手作業でのオペレーションが多く、コストがかかっている事が判明した。 まずは業務の標準化とチェックすべきポイントを可視化を行い、絶対漏らしてはいけないところに注力する事で全体の生産性を向上した。 そして、業務の自動化を推進し、結果として-6名で業務を回すことに成功した。 また、メンバの評価ができておらず、工数も言い値になっていたところを私がメンバの評価や課題提起を行い、メンバの成長を促す事や苦手な部分のキャッチアップにも寄与した。

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

パブリッククラウド python

エンジニアとして影響を受けた本を教えてください

最強の働き方、転職と副業のかけ算

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

チームのリーダーとして、けん引出来る環境 メンバーと伴走をしてモノ作りをする環境

キャラクター

直近で一番やりたいこと
マネジメント力を上げたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
プレゼン力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
プライベートとの両立
やりたくない分野
SI / ファッション / ゲーム / アダルト / 仮想通貨
その他の特徴
レガシーな環境を改善できる / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
Atom、MacDown
希望勤務地
東京都
希望年収
780万円
ただいまの期間
ドラフト参加受付中

  • この期間に審査合格した方は次回ドラフト参加になります
  • ドラフト初参加以外の方は次回のドラフト参加 / 不参加を選択してください
  • レジュメは更新できます
  • 審査は随時行っています
ご意見箱

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

taso0505
今年で30代中盤
Atom、MacDown
参加ステータス
参加したい
転職意欲
参加回数
7回
累計平均提示年収
717 万円
SIGN UP
SIGN IN


このサービスを友人に薦めたいですか?