taso0505

2024年11月回 指名


まだ何もありません

あなたを気にしている企業

  • atama plusがtaso0505のレジュメを見ています。
    2024.11.22
  • ELEMENTSがtaso0505のレジュメを見ています。
    2024.11.21
  • ブルーモ証券がtaso0505のレジュメを見ています。
    2024.11.21
  • ContractSがtaso0505のレジュメを見ています。
    2024.11.21
  • enechainがtaso0505のレジュメを見ています。
    2024.11.21
  • キャディがtaso0505のレジュメを見ています。
    2024.11.21
  • Legalscapeがtaso0505のレジュメを見ています。
    2024.11.21
  • TRUSTDOCKがtaso0505のレジュメを見ています。
    2024.11.20
  • キャディtaso0505のSpeakerDeckを見ました!
    2024.11.20
  • キャディtaso0505のZennを見ました!
    2024.11.20

3年後の目標や野望


事業会社でCIO / CISOとして、組織を強固な形に牽引し、成果にコミットする。

事業側でバリューを出す経験のなかで「次世代の育成」に試行錯誤をしたが、楽しみを見出した。 今後は1エンジニアとしてではなく、エンジニアの育成や組織の醸造にミッションを負って成果にコミットしたいと考えた。 具体的には、エンジニアとの1on1だけでなく、伴走することでテクニカルスキルだけでなく、マネジメントスキル・コミュニケーションスキルの向上も目指し、組織としてより良いバリューが出せる環境を醸造する。 現職でもエンジニアマネージャーとして、日々組織開発・育成にも力を注いでいる。 また、直近では、技術広報 / エンジニアブランディングにも携わっており、エンジニアの組織力向上に向けた認知向上や採用活動に寄与する活動をしている。

年収評価シート

2020年/2年以上

スキルマーケットのHead of Informationとしての社内情報システム / インフラ・SRE / セキュリティの推進

## 概要 * スキルプラットフォームのプロダクトインフラ・SRE / 社内情報システム / セキュリティの推進 ## 規模 * 16名(自社13名) ## 役職 * 部長 / Head of Information(グループ会社の執行役員も兼務) ## 担当 * 経済圏のインフラに関する業務推進とリファクタリングおよびマネジメント * 全社CSIRTの企画と立ち上げ * 全社セキュリティの施策立案・検討 ## 環境 * 自社 ## 課題 1. インフラに関する課題が可視化されておらず、場渡り的な対応となり、重要なタスクの対応が遅れてしまう 2. 属人性の高い運用体制となっており、耐障害性が低い 3. 上場予定企業の内部/外部監査に耐えうるセキュリティになっていない。 ## 成果 1. コミュケーション計画を刷新し、シナジーを生み出しやすい環境を構築。「よもやま」を開催し、課題の共有から着手することで目線合わせと肌感覚の共通認識を持った。  課題一覧を経営層へ共有し、中長期のロードマップ立案と組織戦略を合意し、インフラ組織の向かう方向性を指ししめした。  また1 on 1をメンバと定期的に行うことで、コンディションの把握やモチベートを実施し、技術課題だけでなく、組織課題の抽出と対策を行うことで、モチベーションクラウドによる組織のコンディション改善を実現した。(数値ベースで0.2ポイント上昇) 2. 構築業務についてはTerraform / Ansibleを利用したIaCを推進。運用業務はConfluence / esaをベースとして、ドキュメントの拡充とTerraform / Ansibleを利用したIaCを推進することで課題解決を実現した。  障害対応時のフローやナレッジを可視化することで、対応品質の向上だけでなく、組織として障害対応の遂行を可能にした。 3. まずは「当社のセキュリティ要件」の整備から着手、ベストプラクティスを参考に「何を脅威」とし、「どのように防ぐか?」を中心に検討を行なった。  外部よりも内部への対応が薄いと分析し、アクセスログの収集や確認の業務フローを立案。監査での指摘事項を減少させることに成功した。  インフラと同様に課題一覧を経営層へ共有し、中長期のロードマップ立案と組織戦略を合意し、セキュリティとしてなすべきことと順番を明確化した上で、会社の堅牢性向上を実現した。 ## 工夫した点 * 参画直後からサイロ化している状況であったので、現状調査と分析に時間をかけ、「今がどういう状況なのか?」をQDCを軸に明らかにしていった。 * Github Issueでの依頼管理・課題感りを行い、分析可能な土壌を構築。 * 3ヵ年のロードマップを立案し、組織・人・技術がどうあるべきか?の道標を可視化。 * 今を見れば問題はないが、再現性のない運用をしていることが一番のリスクと捉えて、再現性の高い運用を実現すべく、実績のある手順を抽出して可視化することで、今後起こりうるインシデントへの対策をプロアクティブに講じた。  また、起きた後に速やかに対応ができるような仕組みが必要と考え、障害対応のガイドライン作成やナレッジベースの構築を行った。 * セキュリティはあまり考慮されていない状況であったので、ITILやIPAが提示する内容をベースに守るべきセキュリティ要件の明確化とセキュリティアセスメントを行うことで、優先順位をつけて実装している。  CSIRT協議会への参加を計画しており、社外のベストプラクティスを参考にしたココナラとしてのあるべきセキュリティ施策を検討・推進している。

2018年/2年以上

インターネット広告配信システムのDevOps / CSIRT / エンジニアマネジメント

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

2016年/2年以内

事業会社へのSRE装着

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

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をハイレベルで達成していきたいというマインドを醸造`した。 * `自分のローカル環境に本番環境をシミュレートした環境を構築し、ansible導入のハードルを下げるべく、フィージビリティを実施`。 ansibleを使う上での業務設計のポイントやつまづきやすいポイントの抽出を事前に行うことでメンバへ展開したときのイメージアップをよりしやすいようにした。 * ITILの資格を取得していた為、メンバに対して勉強会を開催し、サービスマネジメントのあり方や考え方、スキル・ナレッジをトランスファーした。 * 実務におけるヒヤリハットを共有することで、メンバの意識向上を促し、伴走することで知識の習得を効率化した。

マネージメント能力

* スキルマーケットの社内情報システム / インフラ・SRE / セキュリティ
* スキルマーケットのサービスインフラ基盤のQCD向上およびKPIの達成 * スキルマーケットの社内情報システムのQCD向上およびKPIの達成
* 課題の可視化ができておらず、不透明なことに起因した属人化が横行していたので、課題のリスト化から着手し、短期・中長期に対応すべき事項 / 目指すべき姿を可視化した。 * 組織コンディションが悪く、退職者が続出するような中で採用活動を行い、モチベートとコンディション整備を目的としたキックオフやオフサイトを計画し、個人で解決するのではなく、組織力で解決できるような座組みを構築した。

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

* 広告配信システムのDevOpsチーム
* アプリケーションとインフラ、開発と運用の垣根を超えたシナジーの創出
* アプリケーションとインフラが縦割りになっており、情報共有が弱く、課題感や問題意識の共有ができていないことで、個別最適の形式を数年間行っていた。 双方が参加する定例会議体はあるが、建設的な議論や検討を行う風潮の為、工数が無駄になっていることが散見された。 * まずはインフラ目線でアプリケーションと関係する課題を整理し、アプリケーション側へ共有し、課題や問題の目線合わせをすることで、DevOpsとして活動する「メリット」を共有することができた。 結果として、「20h/月」の工数削減とエラーバジェットの採用など新たな試みにチャレンジすることができた。

アピール項目


アウトプット

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

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

* パブリッククラウド * python * Docker / Kubernetes

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

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

キャラクター

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

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きな Text Editor
VS Code、MacDown
希望勤務地
東京都
希望年収
1200万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
SIGN UPSIGN IN


転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?