ID:17231さん

第21回 指名 (未返答 : 0/0件)年収を見るには?


まだ何もありません

自己推薦一覧

自己推薦はありません

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

  • Kaizen PlatformがID:17231さんのレジュメを見ています。

    2019.09.18 14:59
  • ドリコムがID:17231さんのレジュメを見ています。

    2019.09.18 11:50
  • フィードフォースがID:17231さんのレジュメを見ています。

    2019.08.07 19:13
  • フィードフォースがID:17231さんのレジュメを見ています。

    2019.08.07 10:41
  • ユニファがID:17231さんのレジュメを見ています。

    2019.07.31 21:10
  • SmartHRがID:17231さんのレジュメを見ています。

    2019.07.31 19:37
  • スペースキーがID:17231さんのレジュメを見ています。

    2019.07.31 16:17
  • テテマーチがID:17231さんのレジュメを見ています。

    2019.07.31 15:11
  • SmartHRがID:17231さんのレジュメを見ています。

    2019.07.31 14:31
  • OKANがID:17231さんのレジュメを見ています。

    2019.07.31 12:44

3年後の目標や野望


先を見据えて、質で勝負できるエンジニアになりたい

1社目では 短時間で低クオリティのサイトを大量に作るスタイルで、 - コピペの繰り返し - 見通しの悪いコードのせいで修正すると違うとこがバグる - 密結合な実装のせいで移植性が悪いコードだらけ という状況の中で、自分がこだわって作った疎結合なコードのおかげで後々自分が楽できた経験や パフォーマンスチューニングしてベンチマークのスコアが良くなっていくのを見るのが楽しかった経験があったから 2社目では 1つ目のプロジェクトで納期優先による妥協したソースコードやテストコードのために テスト工程でのバグが大量に発生して遅延した上にリリース後にバグがボロボロ出たが 2つ目の自分が開発リーダーをしたプロジェクトでは特にテストコードの品質にこだわった結果、 実装フェイズでは遅延が発生したがテスト工程でのバグは圧倒的に少なく予定通りリリースでき リリース後はバグが0だった経験があった 以上の経験から 目先の楽さのために怠慢の開発をすると後々もっと苦労する 逆に、後々楽をするために少しの苦労をした方がいい ということを学んだため そして、パフォーマンスチューニングやリファクタリング、負債を残さない綺麗な設計やコードを書くのが好きだから

年収評価シート

2018年/3ヶ月以内

社内向け在庫管理基幹業務システムの二次開発

# 概要 開発リーダーとして 社内向け基幹業務システムに在庫の棚卸しのための機能の追加開発を行った 本プロジェクトは上場に向けて資産を正確に把握するために必要な機能で、かつ 年末の棚卸しに間にあわせるためにスピードとクオリティが求められていた # プロジェクトを成功に導くために スピードとクオリティが求められる一方で自分以外の開発メンバーが5人いたが gitに不慣れなメンバーや開発経験が浅いメンバーや入社して間もないメンバーがほとんどだったため 1次開発の失敗を生かして開発効率やシステムのクオリティをあげるために以下のことを行った 1. 1次開発時よりも時間をかけた詳細なロジック設計書を作成 - 実装者の実力や要件に関する知識の差による影響を最小限にするために - また、容易にN+1問題を潰せるようなDB設計を行った 2. ドキュメントは必要最低限のものに絞ってリンク集を作って集約 - ドキュメント作成や見る側の時間を短縮するために 3. システムの構成に関するドキュメント作成 - 入社間もないメンバーや途中でプロジェクトに参加する人が出てきた時にインプットの手間を省くため 4. ローカル開発環境の整備 - Dockerの設定が不完全で慣れてない人が構築に苦労する状態だったため 5. 事前に開発ルールを策定して周知 - 開発効率を上げるため - レビューがボトルネックにならないようにするため - コミュニケーションコストを減らすため - 不慣れなメンバーや途中参加のメンバーへのインプットの時間を省くため - など 詳細 https://qiita.com/rh_taro/items/b56cfab0fc4a84693b85 6. 自分は余力を残しつつレビューに徹した - 遅延が発生した際に自分の工数を使ってリカバリできるように - テストコードのレビューに特に注力してシステムの品質を上げるために 7. DBのロックの実装とそれに対するThreadを使用したテストに特に力を入れた - 数十人が一気に在庫をスキャンしていくためトランザクション周りの実装が甘いとデータ不整合が起きやすいため - 事前に調査してロックとロックのテストに関する資料などを集めておいた # 実装以降 フロントエンドを担当する予定だったメンバーが別タスクの割り込みで実装できなくなったため 急遽自分が担当することになった 余力を残していたおかげでリカバリすることができた また、Vue.jsの開発経験を積むことができた # 品質 レビューでテストコードに特に注力したため実装フェイズは遅延が発生したが テスト時に出たバグは数個程度で修正が少なかったためテストフェイズは前倒しで進み、 結果的に予定より早くリリースすることができ、リリース後もバグは0だった 実装時にテストコードに注力するとテスト以降のフェイズが楽になることを身をもって経験することができた # パフォーマンスチューニング 本プロジェクトでは - バッチの実行速度 - 棚卸し結果のCSV生成速度 の2点で時間がかかり過ぎていたため開発終盤で修正して高速化した ## Railsで書いたバッチ 当初12万件のデータを処理するために実行時間は1時間ほどかかっていたが、5分まで短縮することができた 行ったことは下記記事にまとめた https://qiita.com/rh_taro/items/eaec3e16248d88e2ccf9 バッチは在庫のテーブルをロックして棚卸しに必要なデータをまとめるため 「バッチ実行時間 = 在庫データの登録編集ができない時間」となり 業務影響が大きく、ユーザビリティ向上に大きく貢献できた ## 棚卸し結果のCSV生成 6万件ほどあったためCSVのダウンロードに2,3分かかっていたが 10秒程度まで短縮することができた ActiveRecordによる処理速度の遅さが原因だったため RailsのDB周りの処理を調べたりSQLの知見を生かして pluckメソッドや一部SQLを書いてActiveRecordを使わないように修正して高速化を実現した この機能も棚卸し実施中や実施後に いろんな部署の人がダウンロードして実施状況の確認や資料作成に使うため 業務影響が大きく、ユーザビリティ向上に大きく貢献できた

2018年/1年以内

社内向け在庫管理基幹業務システム

# プロジェクト概要 社内向け基幹業務システムの開発に実装フェーズから参加 サーバサイドはRailsでAPIを構築 フロントエンドはVue.jsでSPA ローカルの開発環境ではDocker(docker-compose) CircleCIで自動テスト/自動デプロイ SwaggerでAPI定義 Railsは未経験だったがPHPの経験はあったのでサーバサイドエンジニアとしてジョイン 終盤では一部フロントエンド(Vue.js)も担当 # サーバサイドエンジニアとして Railsは未経験だったがWebの知識は豊富で、既存ソースなどからのキャッチアップは得意なので ほとんど人に聞くことなく即戦力として割り振られたAPIを実装 初めて対応したチケットは軽微なものではあったが未経験だったrspecも含めて3日で対応し、 1ヶ月後には既存メンバーと同等のチケット消化スピードになった 3ヶ月後にはレビュアーとしての業務もこなすようになり、 4ヶ月後には開発リーダとして二次開発に参加した 自分が参加した時点でプロジェクトは遅延していたが上場のために納期を伸ばすことができず 速度重視での開発になっていたため、テストフェイズやリリース後のバグ発生率が非常に高く リリースは納期に間に合ったが「成功」とは言えないプロジェクトだった これにより雑なテストコードや無茶なスケジュールで実装をして スケジュールとして間にあわせることができても後々バグが大量に発生してテストフェイズで結局遅延することを身をもって体感することができた また、Rails/rspec/docker/swagger/ci/vue.js/AWSなど いずれも初めて触るものだったがこのプロジェクトを通して今時の開発を一気に身につけ大きく成長することができた パフォーマンスチューニングやSQLは昔から好きだったので Railsで起こりがちなN+1問題の修正をしてアプリケーション全体のパフォーマンス向上に大きく貢献した

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

2017年/3ヶ月以内

SaaSを使用した小規模ECサイト

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で クロスワープ社のMODD ECMというショッピングカートシステムを用いて アーティストのグッズ販売をするECサイトの構築をしました。 PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、エンジニア1名。 # 詳細 ### インフラ ApacheのバーチャルホストやDNSのZone設定から運用/保守まで1人で行っています。 SSLの設定についても暗号化スイートの設定を見直して SSL LabsというサービスでAランクを取れるまで試行錯誤しました。 ### アプリケーション構築 サイトのベースとなる部分はすでに社内にあり、流用した部分は多くありましたがそのままで終わらせず クライアントの要望に合わせて同アーティストのオフィシャルサイトにも一部のグッズを表示できるようオフィシャルサイト側とCMSを改修しました。 ソースコードについても不要な関数の削除や繰り返されている同じ処理の関数化など 可読性や再利用性の高いソースになるようリファクタリングも欠かさず行ないました。 ### 負荷対策 処理速度向上のためにnewrelicやApache Benchを用いて性能テストを行い、 PHP側で行なっていたループによるデータの整形処理をテンプレートエンジン側のループへ統一したり SaaSのAPIを利用した会員認証処理で使われていたSOAP通信のライブラリの読み込みで 大幅に処理が遅くなっていたためWebAPIを使用するように会員認証処理を改修しました。 他にもDBへのコネクション数を減らすためにSQLで取得したデータをmemcachedの利用、 apacheのプロセス数の上昇を抑えるために画像やcss、jsファイルなどの静的ファイルをAWSのS3へ配置、 可用性の向上にも務めました。 オープンは2017/06で制作期間は1ヶ月半ほどでしたが、現在も継続して運用中です すでにオープンしている他のECサイトへもアクセス対策を講じたり memcachedの更なるパフォーマンス向上のために UNIXドメインソケットによる接続の検証なども行なっています。 # その他 他にもECサイトを1つ、合計2つのECサイト構築を経験しました

2017年/3ヶ月以内

アーティストの月額制モバイルファンクラブサイトの構築

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で 月額制のアーティストのモバイルファンクラブサイトの構築を行いました PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、フロントエンドエンジニア1名、バックエンドエンジニア1名。 # 詳細 ### アプリケーション構築 アーティスト本人のこだわりにより独特な世界観の強い案件で、ユーザがプロフィールで設定したキャラクターによってサイトのデザインや表示を変えるという社内で初の試みがあったが仕様は不確定な部分が多く、 チームメンバーやクライアントとこまめに情報共有・確認を行い可能な限り仕様を詰めて どうしても決まらない部分についてはその時点での構想を全部踏襲しDBの構造やアプリケーションを汎用的に設計・構築することでサイトオープン直前や直後の仕様変更にもスムーズに対応することができました。 また、デザイナーやアーティスト本人のイメージする世界観を実現するためにURLにまでこだわりサイトの構築を行いました。 課金方式はキャリア(docomo、au、softbank)決済サービスと決済代行サービスによるクレジットカード決済を導入しました。クレジットカード決済についてはカード情報の非通過化に対応しました。 クレジットカード決済については決済代行サービスの仕様書にあったJavaScriptのソースではAndroid4系のブラウザで動作せず、調査したところイベントハンドラが比較的新しいもので古いブラウザが対応していない可能性に気づき、別のイベントハンドラを代用することでAndroid4系のブラウザでも決済が可能になるようにしました。 ### E2Eテスト自動化 puppeterというHeadless ChromeのNode APIライブラリを使用して サイトへの入会、決済、ログイン、退会などの重要かつ時間のかかる部分のテスト自動化を行い テストの工数削減を行いました。 ### 負荷対策 モバイルサイトでも同様に、ユーザごとに表示が変わらないコンテンツはDBから取得したデータをmemcachedでキャッシュする負荷対策を実施しました サーバのトラフィックの増加対策にはコストパフォーマンスやファイルの同期の時差の面からS3ではなくCDNを使用しました。 # その他 他にもモバイルサイトを2つ、合計3つのモバイルサイト構築を経験しました。

2017年/3ヶ月以内

アーティストのオフィシャルサイトの構築

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で アーティストのオフィシャルサイトの構築を行いました。 PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、エンジニア1名。 繁忙期の中で同一アーティストのECサイト、モバイルサイト、オフィシャルサイトの3サイトを同時でオープンすることになり、メイン担当者がEC・モバイルサイトを担当し自分がヘルプとしてオフィシャルサイトを担当しました。 # 詳細 ### アプリケーション構築 このサイトではアーティスト本人のSNSの投稿と所属事務所のサイト上のニュースをオフィシャル・モバイルサイト上でも表示したいという特殊な要望があり、モバイルサイト担当者のエンジニアと相談しつつ共通でAPIでデータを取り込むバッチを作成し、サイト上で表示できるようにそれぞれ実装しました。 また、アーティスト本人がCMSを通さずメールでサイトにブログをアップしたいという要望があり メール投稿のシステムは社内にすでにありましたが、htmlメールに対応しておらず運用上の制限があったため マルチパートの処理の強化、階層化されている場合には再帰的にパースする処理を追加してhtmlメールにも対応させることができました。 ### 負荷対策 CNAMEレコードにCDNのドメインを設定してサイト全体をCDN化していました。 そのためサイトのオープン直後のアクセス集中(1時間あたり54000PV)でも表示が遅くなったりすることはありませんでした。 ### 緊急対応 サイト公開時には非公開のオリジンのドメインが公開されてしまい、一時的にサーバへの負荷が高くなったが すぐにhtaccessでCDN以外のアクセスを公開ドメインにリダイレクトさせるように対応してことなきを得ました。 # その他 オフィシャルサイトは他社運営の既存サイトから同一ドメインでの移管だったため あらかじめ既存サイトのDNSのTTLを短くしておき、切り替え後DNS浸透までの間は新サイトではメンテナンス表示にしておくことで問題なく移管させることができました。 他にもオフィシャルサイトを3つ、合計4つのオフィシャルサイト構築を経験しました

2016年/2年以内

カスタマーサポート対応

# 概要 運営しているサイトのカスタマーサポート対応をしています。 サイト数が多いためphp5.2〜7.2のサイトが対象で、「ログイン・会員登録できない」「コンテンツが見れない」といったユーザからのお問い合わせに対してカスタマーサポート対応の担当者だけで解決できない問題の調査・対応します。 # 詳細 アプリケーションログ、アクセスログなどからユーザの挙動や使用している端末、 メールアドレスなどからDB内の会員の登録状態や決済の状況などを調査し、必要に応じてデータの修正します。 ユーザ自身も登録情報が曖昧な場合がありそういったケースでは登録情報の特定が困難なため カスタマーサポートスタッフを通してユーザへヒアリングをして断片的な情報をつなぎ合わせて会員情報を特定します。 決済周りで問題が起きていそうな際にはアクセスログからユーザの挙動を再現し ソースコードや決済サービスの仕様書を読んだり決済サービスの窓口へ問い合わせもします。 自分一人では原因が究明できない場合にはエンジニアチーム内で共有し他のエンジニアを巻き込んで調査を行います。 エンジニアだけで判断できない問題についてはディレクターやカスタマーサポートスタッフの判断を仰ぎ、対応します。 また、自分が構築したサイトではないサイトを調査することも多く、構築を担当したエンジニアに聞いたり 社内のwikiやソースコードを読んで処理の流れや仕様を調べてから調査を行います。

マネージメント能力

アピール項目


アウトプット

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

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

- iOSアプリ開発 - 限られたサーバのリソースでのアプリケーションのパフォーマンスを向上テク - マイクロサービス - RESTful APIの認証周り - IaC(Infrastructure as Code)

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

* 体系的に学ぶ 安全なWebアプリケーションの作り方

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

- 快適な椅子 - イヤフォン使用可 - 4Kディスプレイ支給 - 決まった時間に出社することにこだわらない環境 - エンジニア同士で競い合ったり教えあったり切磋琢磨できる環境

キャラクター

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

やりたい事

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

基本プロフィール

年齢
今年で20代中盤
好きな Text Editor
Sublime Text
希望勤務地
東京都
希望年収
720万円
ただいまの期間
ドラフト開催中

  • 参加者は企業から指名が入ります
  • ドラフト指名に返答できます
  • レジュメを更新できます
  • 審査は停止しています
ご意見箱

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

ID:17231さん
今年で20代中盤
Sublime Text
参加ステータス
参加中
転職意欲
参加回数
7回
累計平均提示年収
539 万円
SIGN UP
SIGN IN


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