ID:9284さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


チーム開発において、個性を活かしながら着実によりよいサイクルを回せるように

現状、5年10年前に構築されたシステムを複数サービス分担当しており、システムの振る舞いについての問い合わせにコードを見た上で回答したり、不具合対応などの保守開発が主です。 また、様々な事情からリソースが足りておらず場当たり的な対応に終始してしまい、 システム全体をより良くしていくための提案や実装、そのためのドメイン知識を持った人へのヒアリングなどが難しくヤキモキしているため、 そういった場面に置いても、よりよく立ち振る舞えるようなチームでの開発を経験し、開発者と利用者双方が改善し続けられるような関係を実現できるような経験、力を得たい

年収評価シート

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

2021年/1年以内

社内サンドボックス基盤へエンジン追加プロジェクト

## 行ったこと 社内サンドボックス検査基盤へ新しく別の会社の製品を追加するにあたる技術的な支援一切 ## 規模 弊社には複数のBtoBサービスより利用されるサンドボックスエンジン基盤が存在している。 検査リクエストを受け付けるWebAPIとサンドボックスエンジンを利用するジョブシステムとサンドボックスエンジンそれ自体から構成されており、サンドボックスエンジンは他社製品、それ以外は社内で開発している。 私が担当したのは 既存基盤のエンジン部分を別の製品へ変更するにあたり、基盤自体の開発ではなく、基盤とのつなぎ込みのための技術的なやり取りの総括と、エンジン自体の動作に必要な部分のベンダーとの調整や、不具合の調査、一部SDKを利用したコード編集である。 ## 行ったこと ■技術検証と基本設計をしていた前任者からの引き継ぎ ■検証機関で明らかになっていたものの解決できなかったトラブルの調査と解決 ■実運用に向けて細かいワークフローの整備 ■prometheusとgrafanaを利用したダッシュボードの作成 ### 解決できたこと - node_exporter を利用したモニタリングにより、ベンチマークテスト中にメモリ不足になりコンテナが破棄されてたことを発見 - ネットワーク的な構成が不適切で、エンジンが追加データフィードの受信に失敗していたことを発見 - 実運用に向け、静的検査エンジンの出力フィールドを追加(SDK同梱のサンプルコードへの簡単な修正) - 社内基盤側開発者との円滑なやり取り - ベンダー側技術者とのトラブルシューティング等対応 - node_exporterのtextfile collectorを利用した簡易的なexporterを投入することによるgrafana dashboardの導入(のちにexoorter は別途作成) - 実運用により沿う形でデプロイのためのgitlab ciの調整等 ### 努力した点 - 基本設計がされていたとはいえ、数ヶ月で前任者から巻取り、ベンダー側の技術者と協力しながらSTG環境などで確認された不具合についての調査を行い、数ヶ月でPRD環境構築と、実運用投入までを行ったこと - 完成した物自体に必要な技術的知識はそう多くはないものの、限られた期間で対処が必要なものを一つづつ潰してどうにか運用にこぎつけられたこと

2015年/2年以上

[概要] BtoBのサービス運用に寄り添ったシステム開発

このプロジェクトとして表記しているのが全体のあらましになります。 更に具体的な事例について 2以降に記載しています。 ### はじめに * セキュリティ系アプライアンスマネージドサービスのシステム開発に従事しています。 * サービスのシステム開発であるため、プロジェクトごとに別々のものを作るというより、ある程度同じコードを複数のサービスでカスタマイズしながら利用しております。 * IPS/IDS, MFW, DDoS対策機器 など対象の機器ごとにサービスが別れています。 * サービスごとに運用、サポート、企画など開発上連携する担当者が異なります。  * 10~20年ぐらい続いているサービスも有るため、歴史的経緯などもあり、同じふるまいを期待されているシステムでも、動きが少しずつ異なっています。  * それらに対しての、顧客の要望対応や、新機能、不具合修正などの追加改修や、ホストの構成管理を行うのが私のタスクになります。 * ここでは、それら複数サービスにまたがる形で雑多に記述していきます。 ### サービス内での分担部分 * システム開発主担当として以下を行っています。 * 既存システムへの追加改修 * 顧客要望の対応や、新機能提供のための改修(既存の振る舞いの調整や扱うデータの追加) * マネージドで提供しているアプライアンスのバージョンアップに関する修正(rest api) * その他、運用目線での修正依頼などの対応 * Itamae を利用した Infrastructure as Code 的な振る舞い * インストールする rpm のバージョンを固定(docker + fpm によるbuild) * 大量のホストへの iptables などの配布 * 設定ファイルのテンプレート化 * サービスホストに関するメンテナンスについて 手順書のレビューなど * 利用している内製システムの挙動解説や、確認点の提案など * サービスのために用意した CentOS 上で動く コード全般の開発 * 社内システムとの連携のためのデータ処理(xmlrpc) * サービスのユーザーがアクセスするWebシステム(rails) * 社内ログ解析システムの結果を利用したPDFによる月次レポート作成部分(python, tex) * 既存システムの不具合発生時に調査から修正、修正箇所の検証方法の例示 * 顧客情報など設定値の入力不備や、作業ミス、システム側の考慮漏れなど雑多なシステムに関する問い合わせ対応 * なお、以下は 社内システム他で提供されているためスコープ外です * SSO認証部分 * 契約情報などのマスタデータ系 (サービス固有のデータ部分は除く) * サーバーの死活監視部分 * サービスホストごとのネットワーク構成部分 ### 規模感 * サービス * 3-4 (各サービスともに 主管, ホスト運用, サービス運用, 顧客導入, 開発 の部署から 数人が定例MTGに出る感じ) * 関係しているホスト数  * 5-6 ロール x LR 2系統 x 3-4 サービス * 利用する要素技術 * サービスに応じてまちまちです。

2015年/2年以上

サーバーの構成管理

## 概要 * Itamae を利用した サーバーの構成管理を担当 * シェルスクリプト群で構成されたプロビジョニングの仕組みを Itamae を利用したものへ置き換えている * 前任者の残したコードを下敷きに、複数サービスへ展開している ## 管理対象 * CentOSマシンが対象 * なお、各サービスごとの個別カスタマイズ部分のみ担当 * ホストの調達, ネットワークの設計, OSインストールなど は別の担当者がいる ## 規模感 * 1サービスには 十数程度のロールがあり 3環境(int,stg,prd) ごとに最低 主副で 2ホストある * それを3~4サービス担当している * 各サービス間で一部共通のロールがあるが、サービス固有のシステムもこのホスト群に乗っているため単純な流用はできない ## チーム構成 * 本構成管理の枠組みの運用には 私を主担当者として 全3名 * そもそものホストの構成全体に精通している上司 * 特定サービス担当の派遣1名 * 更にこの構成管理の仕組みに乗っているサービスそれぞれに、サービス側が期待するホストの状態を取りまとめる担当者が各1名ずつ ## 任されているミッション * 従来のプロビジョニングの仕組みは 各ホストでシェルスクリプトを実行するものだった * 冪等性なども考えられておらず、テストの仕組みなどもなかったので集中管理することも難しかった * 前任者が Jenkins + Itamae + ServerSpec による今の構成を用意しており、引き継ぎ後、主担当者としてホストの構成変更や、定期的に行っているホストリプレイスの対応として、Itamaeのレシピを増やしたり、新規構築時に明らかになったレシピの不具合の修正などに取り組んでいる ## 実際の業務 1. インストールするrpmのバージョンアップや設定変更の反映 * docker でビルド環境を固定してあります * 作成対象はhttpd や unbound などのほか、 ホストにインストールする内製のアプリケーションもです 1. 従来のホスト構築手順(手作業やシェルスクリプト) を読み解き Itamaeのレシピ化する * また、このとき各種設定ファイルなどをテンプレート化したりします。 1. ホストリプレース時や業務整理などによるホストの構成変更の対応 1. 既存のレシピであっても新規構築時はOSのバージョン違いなどに追従できていないなどあるためその対応 1. また、ホストの動作確認等々について手順化されていないものもあるため、その場合はコードを追って再現手順を作ったりする必要があります。

2015年/2年以上

ネットワーク・アプライアンスのマネージド・サービスへ提供機種追加のための改修

=== プロジェクトのバックグラウンドについて === 所属企業にはIPS/IDSやFW,UTMなどのネットワークアプライアンスのマネージドサービスが存在し、 そのサービス提供のための社内システムが幾つか存在する。 1. 各機器のログの収集、解析し可視化やアラート発報などを行う解析部分 2. 1.で解析したログを元にブラウザで閲覧できるログ分析レポートを提供する部分 * Python CGI製で、1.の結果得られた情報を単純なHTMLで表現する 3. 1.で解析したログを元にPDFのレポートを生成する部分 * Python 製で、1.の結果をもとに LaTeXファイルを作成し PDFを生成する いずれも内製で、長期間にわたりつぎはぎ作られてるものである。 なお、上記のシステムによる成果物は、社内で利用されるほか、サービス利用者へ提供される。 また、上記システム以外にも、 デリバリ業務のためにアプライアンスの現在の状態を取得できたり、 今のデリバリ状況や社内管理用の顧客コードやIPアドレス、 機器の設定を見やすく表示するものなども存在する。 === プロジェクトの内容 === ネットワーク・アプライアンスはEOLなどで定期的に提供が終了してしまうものがあり、 都度、メーカからは代替機種が提供されるが、 その新機種を顧客へ提供するためには 1. 機器の仕様を精査し必要な機能があるのか 2. 社内のポリシーにあうような設定が可能か(マネージドサービスとして提供できるか) 3. ログの解析部分や機器のAPIを利用している部分などを新機種の仕様に合わせる といったことが必要になる。 私は主にレポート周りなど、顧客通信に影響がない範囲を担当している。 改修の大抵は設定値の読み替えやインターフェース名の変更と言ったごく僅かなもので、その場合、正規表現を追加したり更新したり、APIをたたいてる社内ライブラリに読み替える処理を追加したりする。 しかし、更に顧客へ提供するレポートの種類が増えるなど新規開発が必要になることも多い。 この場合はログの解析ルールの追加や、 HTML,PDFによる可視化の部分でグラフを追加したりする必要があり、 機器の挙動の確認から仕様の設計、実装、テスト、提供まで数ヶ月の開発が必要になる。 大体サービスの主管部署(企画)から、 どんなレポートを提供したいか要望と、どうやって情報を取れるかの仕様が渡される。 それをもとに実際に実装しつつ、仕様をすり合わせていく 大小さまざまな改修があるが、システムは歴史的経緯から内製のライブラリを利用していたり、前任者が退職していたりするため、既存のコードを読み解き、処理の流れを飲み込むのは不可欠になる。 また、自社サービスのための社内システムのため開発は流動的であり、メーカーからアプライアンスの仕様が全て開示されているわけでもないため、試行錯誤しつつの開発となる。 === 自身の活動状況 === 歴史的経緯から開発要望はTracによるチケット管理であり、 そこで、ネットワークアプライアンス側の担当者などと仕様についてすり合わせしたりする傍ら、 自身で調査した内容をConfluenceで共有したりするなどに務めた。 新卒1年目では 細かい表示部分の調整やPDFレポート生成部分の改修などを行い 今では機器の生ログから解析→社内DBへの格納→処理→レポート生成までの一通りの流れを経験し トラブルシュートなども担当したりしている。 トラブルシュートの対象は だいたいは、設定の不備などに起因する不具合だったりするが、 その場合も、どのように調査したのか判断したのか、再現するためのコマンドやその結果を添えて 記録に残すようにしている。 現在では、前任者退任に伴い、一部サービスの開発主担当として 運用チームからの問い合わせに対応するなどしている。 そのため担当工程が幅広いものになっている。 === プロジェクトによって得たもの === このプロジェクトに従事することによって、 ドキュメント等の整備が不十分であっても ログやソースコードなどを追い 状態を確認し原因を推測し対応することができるようになったと感じる。 トラブルシュートのためには本番環境で調査することもあり、 調査した結果を markdown で見やすく整形したり、切り分けのため簡単なコードを書いたりするなどを経験した。 === 使用技術について === 使用技術に上げたものは既存のシステムの構成技術であり、自身で選定したものはほぼ無いが、 自身でスクラッチする簡単なスクリプトはPython2で作成することが多い。 長年稼働しているシステムのため ソースコードの管理はsvnで一部gitである。 社内では前述のTracのほかgithub enterprise を利用しており、開発者間ではIssueで協議したり、調査の記録をしたりしている。 また、大半は git-flow な branch 管理で開発をしていた。

2016年/半年以内

既存サービスを元にした新規サービス立ち上げに際した社内システムの整備

=== プロジェクトのバックグラウンドについて === すでに提供されているFW,UTMのネットワークアプライアンスのマネージドサービスを切り出し 新たに別のサービスとして提供する必要が出てきた。 既存のサービス群とは異なり、”クラウド”を全面に打ち出した新サービス群の1サービスになるため、 顧客が利用するポータル画面などは刷新された。 既存のサービスで利用している以下の社内システムを切り出し一部仕様を変更し提供した。 1. 機器ログの顧客提供API * 概要: Rails 製 XMLRPCの問い合わせで、ログファイルが存在する確認できたり、ユーザー認証した上で、設定されたディレクトリのファイルを提供するものです。 * 改修箇所: 新サービス用にコードから、固有名詞やファイルのフォーマット(パスの組み立て方など)、ユーザー認証の部分など 2. 機器ログの解析結果からのPDFレポート生成部分 * 概要: PythonとシェルスクリプトでLaTeXファイルを生成してPDFを作成するもの * 改修箇所: 既存のサービス用のコードから不必要な部分の削除や、一部ファイルやログのフォーマットの修正など これらは、既存のサービスに特化した形で作成されている内製のものであり、 新サービスに対応するため、顧客情報管理の社内システムや、社内での管理コード等々の切り替えやAPIの応答の書式変更や、システム連携のための仕様策定等々が必要であった。 === 自身の活動状況 === 自身が作成したシステムではないが、作成した前任者が退職しているため、既存システムの担当者として、 新サービス側の担当者と仕様のすり合わせやサービス提供のためのホスト構築からシステムの改修、結合テスト後の仕様調整等々を担当した。 === プロジェクトによって得たもの === 既存のサービスからのシステムの切り出しではあったが、 新サービスとしてはサービスホストの準備からデプロイ、テスト、サービスインを経験し、 プロジェクト開発中には、 別システムの担当者からAPIの利用について問い合わせあったりと、 責任を持って対応する経験を得ることができた、 === 使用技術について === 使用技術に上げたものは既存のシステムの構成技術であり、自身で選定したものはほぼ無い なお、 コード管理はGitで行い、git-flow風のbranch管理を行っていた。 また、サービスホストの構築はItamaeを利用しており、Jenkinsによるデプロイ等々を行っていた

マネージメント能力

アピール項目


アウトプット

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

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

リリースや開発を効率よくしていくためのテストの技術や、形骸化しないための仕様のドキュメント化など

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

「なんでも好きにしていいよ」というよりは、 信頼の置ける誰かにレビューしてもらえるような 心理的安全性がある程度必要

キャラクター

直近で一番やりたいこと
マネジメント力を上げたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
分析力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
SI / 金融 / 医療・介護 / ゲーム / BtoC
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと

■「絶対に失敗しない」より「失敗しても問題ない」仕組みを準備していきたい
■ システムで無理難題に対応するより、持続可能なシステムとなるべく枯れた技術やOSSなどの活用をしていきたい
■ 高い技術力の人たちと刺激を持って働きたい
■ 参入時期の違うチームメンバーでもうまく回せていけるようなチームプレイをしてみたい
■ 机上の空論で終わってしまうような大量のドキュメント作成に忙殺された挙句、メンテナンスが行き届いておらず参考にはならない・・・・といったワークフローはNG

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
vs code, Sublime Text, vimなどを使います
希望勤務地
東京都
希望年収
800万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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