ID:36983さん

自己推薦一覧

自己推薦はありません

2020年9月回 指名 (未返答 : 0/1件)年収を見るには?


3年後の目標や野望


WebRTC とロボットや自動車などをつなげられるだけの技術力を付ける

超長期的には人体拡張に興味があるため、 5 年を目処に IT と現実のものがつながっている IoT 領域に挑戦したいです。

年収評価シート

2017年/2年以上

Twilio を用いたコンタクトセンター開発と運用保守

# 現行機能の洗い出し まず、現行の電話機が何ができるかをすべて洗い出し、現場で使っている営業リーダーとすり合わせを行いました。抜け漏れを発見次第、要件に追記が行いました。 # 要件実現可能性の調査 その後、要件を Twilio で実現できるかを確認しました。確認したところ、すべて Twilio で再現できることを確認したので、実装に着手。 # 実装 実装は自分ひとりで行い、自力でわからないところは多数ありましたが、 Twilio や電話、 WebRTC について社内に知見を持つ人がいなかったため、社外の詳しい人にヒアリングしたり、 StackOverflow で英語で質問したりなどして、不明点をすべて明確にし、実装をしました。 ## 技術構成 構成としてはサーバサイドは Laravel 5.4 を利用しました。フロントエンドは内製のデザインシステムを利用し、画面の動作は jQuery2.1.4 で実現し、 Chrome Extension を作成しました。 Chrome Extension はこのプロジェクトではじめて本格的にさわりましたが、キャッチアップを行い、半年ほどでα版の提供を行い、 1 年かからずにプロダクト版リリースにこぎつけました。 Chrome Extension にした理由は、自動アップデートが可能になり、特定のサイトを開いていなくても電話を受けられるようユーザビリティも考慮したためです。一般的な電話をブラウザで受けられるシステムは特定のページを開いていないと電話を受けられないのですが、 Chrome Extension にすることでブラウザを開きさえすれば、電話の利用が可能になる点が特長です。 # リリース前テスト リリース前に影響範囲が少ない部署でα版の提供を行い、大きな問題も起きずに完了しています。リリース直前には数十名の現場の営業にも協力してもらい、システム負荷テストや要件が満たされているかを確認しました。 # 運用保守 リリース後、見つけたバグは自力で解決し、最終的にはほぼバグがでなくなりました。 安定運用に切り替わったタイミングでリリース後対応するとして、スコープ外にした機能の開発を行いました。 この際には、一緒に協力してくれるエンジニアが 1 名と、現場の営業とエンジニアをつないでくれる総務 2 名を巻き込み、テストやユーザヒアリングなども協力して行い、速度を上げて改修をし、現場の営業にも好評だったと感じています。 # リリース後分析 Twilio はすべての通話ログが API で取得できるため、取得したログを元に R 言語で分析を行い、通話までにお客様が待っている時間帯を調査し、営業の稼働時間について交渉を行いました。 # 退職前引き継ぎ 退職前にかんたんに解決できるトラブルは総務の人に情報共有を行い、ほとんどが現場で解決できるようにし、情報共有を行った総務の人がいなくなった後も情報が漏れないようにドキュメントを整備しました。そのため、退職後に引き継いだエンジニアに聞いたところ、大きな障害もなく、ほとんど困ることなく引き継ぎができていたという評判を受けています。 この業務に伴い、一般的な開発業務以外に、稟議や社外折衝、データドリブンな施策提案など幅広い経験をすることができ、事例としても取り上げられています。

2020年/半年以内

システムリプレイス

# リプレイスのリプレイス 旧システムをリプレイスしたと言われた管理機能の保守を任されましたが、新システムと旧システムで機能の差分があったため、新旧管理機能を並行して、現場の人が使っていると言われました。そのため、旧システムの機能を全て新システムに移す実装を行いました。 PM が不足している機能一覧は洗い出しくれましたが、それをどのように実現するのかといった詳細については決められていませんでした。そこで、 PM と交渉を行い、機能をどのように実現するかは僕が旧システムのコードリーディングと現場の人と話し合い、仕様の洗い出しと提案を行い、合意の上で仕様策定していくということで決定しました。 自分で洗い出した仕様を元に、現場の人と随時ヒアリングを行い、実装を進めました。また、仕様をすべて GitHub Issues に残すことで、後から入った人がどうしてこのような実装になっているかがわかるように心がけています。 他のメンバーの協力もあり、無事に旧システムの機能を新システムに全て移植完了し、旧システムは削除されました。業務効率があがったと現場の人からは好評です。 # 新リプレイス 入社前の 2 年ほど前から始まっていたリプレイスはすでに当時選んだシステム構成も古くなってしまったため、再度見直し、リプレイスを開始しました。その際にはマイクロサービスの思想を導入し、機能を分割、システム構成も変更しました。 ## 技術構成 新システムの技術選定は同じチームのメンバーと行い、下記構成になりました。 * TypeScript * KoaJS(backend) * Next.js(frontend) * PostgreSQL 上記を選定した理由は、下記です。 ### TypeScript マイクロサービスの設計を取り入れるため、 RPC と相性がいい Go か TypeScript が残りました。現行システムは CakePHP + jQuery のため、現行システム保守メンバーが異動する際、 Go は学習コストが高すぎると判断しました。また、 TypeScript をフロントエンドとバックエンドにどちらも共通で利用することで、型の共通化やバリデーションの流用などをメリットに考えました。 ### KoaJS npm のインストール数が多く、薄いレイヤー構造で学習コストが低い点が採用の決め手になりました。また、Node で一番多く利用されている Express.js の作者が KoaJS を作成したため、思想が近いと考え、採用などでも有利になると考えています。 ### Next.js * 素の React を一から組むのは学習コストが重い * 実質的な提供方法が静的ホスティングのみのため、リリース直前に場当たり的な対応(HTMLタグ直埋めなど)ができないため、保守性の低いコードが入り込んでしまうことを防げる * Next.js はオールインワンなので、 webpack の最適化、 TypeScript の型定義やルーティングをファイルパスベースでできて全体的に楽 * Next.js はすでにあるレールに従って書くことで、初期設計でミスることがない すべて、メリットデメリットがあり、 React であれば Next.js よりも楽な点もあるが、すばやくリプレイスを開始し、完了させることを重視しているため、 Next.js の採用に踏み切った。 Vue.js は 2.0 は型定義ができず、パフォーマンスがよくない。 3.0 は現時点で安定版が存在しないため、採用ができないという理由から除外した。 ### PostgreSQL あえて MySQL を採用するメリットがないが最大の理由。 かつ細々とした知らないと踏んでしまう下記のような設定ミスなどが MySQL には存在するため、避けたいと考えた。 * 文字コードが独特で uft8 にしても、一部漢字や絵文字が入らない(utf8mb4 にすれば避けられるが、分かりづらい) * boolean がtinyint(1) で表現されるが、 -1 など入ってしまう * 高速に動くことを重視しているが、今後のエンタープライズ戦略を考えると、 PostgreSQL の堅牢性のほうが魅力的なため * 文字列の暗黙的なキャストが存在し、バグの温床になりうる 機能的に差分はあるが、現状のシステムで論理削除を考慮する事が多いため、部分インデックスを使える PostgreSQL に軍配が上がった。 ## 業務 新リプレイスからは僕はリーダーとして、チームを支援するスクラムマスターとして業務を行うことにしました。理由は Backend, Frontend 共にスペシャリストがおり、僕はエンジニア以外とのコミュニケーションが得意で、空いている領域だったためです。 スクラムマスターとして、スクラム開発を支援するため、下記のようなことをしています。 * 各種スクラムセレモニーのファシリテート * 現場の不満を吸い上げ、改善できるように上司に交渉 現状の業務環境はいろいろと定まっていないことが少ないため、問題点が現場から上がってくることが多いです。それらの問題点をすばやく察知し、言語化をして、上長に提案するという業務を行っていました。これをすることで、現場の開発のフローを止めないようにして、中長期的に開発効率が高まるようにしました。 ### 採用活動 また、この頃から採用活動に携わることにしました。理由は、不足している人員の拡充と採用活動に手一杯でマネジメントまで手が回っていなかった上司を支援するためです。 採用活動ははじめてでしたが、構造化面接を取り入れ、手法を一次面接をともにするエンジニアに共有し、面接の標準化と採用ミスを防ぐ仕組み作りを行いました。また、構造化面接に伴い、会社の求職票の不備や現状との不一致を洗い出し、人事部と連携して、求職票の改善も行っています。求職票の改善により、不一致の候補者にかかってしまっていた工数を大幅に削減できています。採用活動に手一杯だった上司もマネジメントに手が回せるようになり、感謝されています。

マネージメント能力

Twilio を用いた自社向けコンタクトセンターの開発と運用保守
一から現行の電話と CRM が連携している機能を洗い出し、 Twilio で再現できるよう実装を行い、問題なくお客様との通話ができるようシステム信頼性を高め、社内の人が使いやすいよう機能の改修を行った。
まず、現行の電話機が何ができるかをすべて洗い出し、現場で使っている営業リーダーとすり合わせを行いました。抜け漏れを発見次第、要件に追記が行いました。 その後、要件を Twilio で実現できるかを確認しました。確認したところ、すべて Twilio で再現できることを確認したので、実装に着手。 実装は自分ひとりで行い、自力でわからないところは多数ありましたが、 Twilio や電話、 WebRTC について社内に知見を持つ人がいなかったため、社外の詳しい人にヒアリングしたり、 StackOverflow で英語で質問したりなどして、不明点をすべて明確にし、実装をしました。また、リリース前に影響範囲が少ない部署でα版の提供を行い、大きな問題も起きずに完了しています。 実装完了後はテストを行い、この際には数十名の現場の営業にも協力してもらい、システム負荷テストや要件が満たされているかを確認しました。 リリース後、見つけたバグは自力で解決し、最終的にはほぼバグがでなくなりました。安定運用に切り替わったタイミングでリリース後対応するとして、スコープ外にした機能の開発を行いました。 この際には、一緒に協力してくれるエンジニアが 1 名と、現場の営業とエンジニアをつないでくれる総務 2 名を巻き込み、テストやユーザヒアリングなども協力して行い、速度を上げて改修をし、現場の営業にも好評だったと感じています。 Twilio はすべての通話ログが API で取得できるため、取得したログを元に R 言語で分析を行い、通話までにお客様が待っている時間帯を調査し、営業の稼働時間について交渉を行いました。 退職前にかんたんに解決できるトラブルは総務の人に情報共有を行い、ほとんどが現場で解決できるようにし、情報共有を行った総務の人がいなくなった後も情報が漏れないようにドキュメントを整備しました。そのため、退職後に引き継いだエンジニアに聞いたところ、大きな障害もなく、ほとんど困ることなく引き継ぎができていたという評判を受けています。 この業務に伴い、一般的な開発業務以外に、稟議や社外折衝、データドリブンな施策提案など幅広い経験をすることができ、事例としても取り上げられています。

アピール項目


アウトプット

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

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

未入力です

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

# SoftSkills この本に書いてあることを愚直にやっています。 ## ブログ ブログを作るように書いてあったのを読んで、ブログを作っています。 https://harinoma.info/ https://books-io.info/ 最初は言われたとおりにやっていましたが、現在は副業探しや技術的に学んだことをアウトプットすることでより深い理解につながるため、継続しています。 ## 登壇 登壇も続けています。登壇したときの資料は全て下記に残しています。 https://www.slideshare.net/ssuser4d37c8/edit_my_uploads 登壇することでより深い理解につながることと、セルフブランディングや会社へのいい影響があると考え、継続しています。 ## ランニング 技術とは直接的に関係ありませんが、仕事と勉強を継続するために健康な体作りの観点で進めています。体調はこの年にしては安定して、多少ストレスなどがかかっても問題なく働けています。

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

# 少ない人数で自由に進められる環境 粘り強く同じことを深堀りして調べることが得意なため、新しい領域に一人で技術調査と実現まで進められる環境がよいと思います。 Twilio を用いたコールセンターを開発した際は基本的に一人で調査・開発を行い、運用保守フェーズも少ない人数でやりきれました。

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / プレゼン力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
PHPStrom
希望勤務地
千葉県 / 東京都 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
700万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

ID:36983さん
今年で30代中盤
PHPStrom
参加ステータス
不参加
参加回数
2回
累計平均提示年収
-- 万円
SIGN UPSIGN IN


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