ID:8646さん

3年後の目標や野望


少しだけ未来のニーズを捉えて、サービスを作れるエンジニア

ユーザーに良いと思ってもらえる後追いでないサービスを作るため、一緒に仕事をする人から信頼を得るために、視点と技術がセットで必要だと思うから。 少しだけニーズを先回りしたサービスを高品質に作って、ユーザーも自分も満足させられる力を付けたい。

年収評価シート

2014年/半年以内

検索フォーム キーワードサジェスト導入

月間UU数千万のサイトの検索フォームに、カテゴリ推定・スペル訂正機能付きのキーワードサジェストを導入しました。 ■目的 サイトの使用感の改善です。 ・キーワード入力を楽にする ・タイプミス、誤変換による入力間違いの救済 ・うろ覚えによる入力間違いの救済 ■結果 ・0hit(「見つかりませんでした」の画面)率低下 ・検索結果画面の離脱率低下 ・検索結果画面でのクリック率の向上 により、目的が達成されたことを確認しました。 ■役割 企画段階からリリースまでプロジェクトを主導しました。試作したデモを企画担当者に提案して企画化を促し、企画化後はシステム全体の設計とサーバサイドアプリケーションの実装を担当しました。 ■使用技術 候補ワードの検索にはLuceneのFuzzySearch機能を利用するためにSolrを選択しました。データとクエリの読み仮名の取得には、mecab, kuromoji, kakasiの3製品を検証した結果、目的データセット内で最も正解率の高かったkakasiを採用しました。 当時セキュリティの機能がほとんどなかったSolrへの不正アクセスのブロック、クエリ簡易化の観点から、Solrの前段には入出力の変換を行うREST APIを置きました。Solrの性能・スコアリングチューニングに時間を割くことを目的に、APIは使い慣れたCentOS + Apache + Pythonで構成しました。 ■苦戦した点 データ量(数百万)とリクエスト量が多いため、応答速度とスループットの目標値達成には苦労しました。Index方法とクエリの改善・Solrの設定・キャッシュで速度を改善し、最終的にはSolrの前段に置くREST APIでの平均応答速度が10msecを下回り、1CPUで処理できる秒間リクエスト量が100を上回る性能を実現しました。 データ量の多さから関連度のスコアリングも難しく、サジェスト結果の評価とドキュメント側・クエリ側それぞれのboost値の調整を繰り返しました。 ■成長した点 速度と精度のチューニングを通じ、Solrのパフォーマンスチューニングの勘所、スコアリングの理論と実践の両面を理解することができました。 また、仕事の進め方として ・試作デモを作って企画に提案をする ・指標を事前に定め、リリース後には事前に定めた指標により目的の達成を確認する というパターンを確立しました。

2013年/2年以上

Webアプリケーションの開発効率・品質改善

当時の業務内容は、会社が運営している複数のWebサイトに全文検索・ファセット・サジェスト機能を導入・運用・改善することでした。チームの人数が増えない中で担当するシステムが増え続ける状況にあり、品質担保と開発の高速化の両立を目指し、インフラ・コード・CIプロセスの3点から継続的な取り組みを行いました。 ■目的 より少ない工数で、不具合が少なく確実に目的を果たすWebアプリケーションを提供すること。 ■結果 チームメンバー1人あたりが担当する製品数が2年間で約3倍になり、かつ障害と不具合の発生率を低下させることに成功しました。 ■役割 プロジェクト開始当初はCIプロセスを導入するプロジェクトのメンバーの一人としてテストの作成を担当しました。 途中からはチームリーダーとなり、自身も手を動かしつつ目標と方向の決定、進行管理を行いました。 ■使用技術 ・インフラ サーバ構成の統一を保証するためchefによる構成管理を導入し、可搬性の向上を目的に全WebアプリケーションサーバをVM化しました。 また、fluentdを使用したログ監視を導入し、障害と障害予兆をリアルタイムに検知できる仕組みを整えました。 ・コード 検索系Webアプリケーションが一般的に備える機能を一通り実現できるWebフレームワークを作成し、製品ごとの特殊要件に応えられるようプラグインポイントを設けました。同等の機能が1/5のコードで実現できるようになり開発が高速化したことに加え、フレームワーク側で品質を担保することで不具合の混入が減少しました。 ・CIプロセス アプリケーションのフレームワーク化と合わせてテスト・デプロイツールもフレームワーク化しました。相互レビューを通らないとデプロイに移れないルール、デプロイ時に必ずテストが行われる仕組み、デプロイしたアプリケーションが(HTMLのタグの確認や、検索にヒットするドキュメントの内容まで含めて)正常稼働していないと負荷分散の対象にならない仕組みにより、確実に品質の高い製品がリリースされるプロセスを作りました。 ■苦戦した点・反省点 障害・不具合の定量評価方法を考えずにプロジェクトを進めていました。体感で明確に改善していたのですが、施策の評価と次の施策へのフィードバック、メンバーのモチベーションの2点から、数値で示すべきでした。 フレームワーク化と自動化が進むにつれてシステムの内部を見る機会が減り、新規メンバーの教育が難しくなったり、自動化されていない作業で問題点を見落とすことが多くなりました。 ■成長した点 当初はアプリケーション本体・テスト・自動化と製品の周囲しか視野に入っていませんでしたが、教育やチーム運営など、人を視野にプロジェクトを進められるようになりました。

2017年/半年以内

LINE & Facebook Messenger Bot開発

ユーザーごとに会話を学習して個性を持った会話ができ、店舗や商品の推薦を行うことができるBotの開発に、プロジェクト途中から参加しました。 私は主に推薦機能の開発を担当しました。ユーザーの発話意図をより正確に理解して推薦を行うため、Scrapyによるクロールと公開データを併用したデータの充実化、mecabユーザー辞書の作成による形態素解析の改善、話題の特定に用いるLSTMを学習させるためのデータ収集ツールの開発を行いました。 また、バックエンドサーバのリソース消費が激しかったため、今後期待されるサービスの成長に耐えらるように処理の効率化を実施しました。 ・データ保持方法を見直し、MySQLのデータサイズを80%削減 ・データサイズの削減と合わせてSQLとコードを見直すことで、データ更新バッチの所要時間を93%、メモリ使用量を68%削減 ・SQLの見直し、全文検索部のElasticsearch導入によりレスポンス速度を70%短縮 自身の開発だけでなく、個人によるプロトタイプ開発に近い状態から、チームによる製品開発にするための体制づくりにも貢献しました。 開発者しか知らなかったシステム構成・デプロイ方法・API仕様を資料に書き起こして属人性を解消したほか、機能テスト手順とOWASP ZAPを用いた脆弱性診断方法の確立により、製品として最低限必要な安全性と品質を担保しながら開発と運用を続けられるチームを作りました。 さらに、自ら積極的に情報を記録・共有し、メンバーにも記録と共有を促すことで、情報共有の文化を定着させました。1月は一ヶ月で平均1本/人だった私以外のメンバーによる社内情報共有ツールへの記事投稿数が、4月は13日時点で平均3.5本/人となりました。 達成したことのレベルは高くありませんが、リスク回避と事業継続性の観点から不可欠な役割を果たしたと考えています。

2014年/1年以内

ホームセキュリティ開発(個人プロジェクト)

個人のプロジェクトとして、Raspberry Piを使用した安価かつ拡張性に優れるホームセキュリティサーバと、Androidのクライアントアプリケーションを作成し、事業化を目指しました。 サーバはカメラと窓の開閉センサーで自宅への侵入を検知し、電話・動画添付メールによる通知を行います。Androidクライアントはサーバの設定変更を行うViewに加え、帰宅時の自動監視OFF機能を実装しました。 自宅で6ヶ月間実運用し、普段の誤検知は全く無く、時々侵入の試験を行った時は検知率100%でした。 より優れた競合が多数登場したこと、ビジネス面のノウハウのなさから事業化は断念したものの、普段の業務で触れることのない分野で知識・経験を積むことができました。 ・Androidアプリケーションの開発 ・OpenCVによる画像処理 ・CPU,メモリ消費に配慮したアプリケーションの設計と実装 ・簡単な電子回路 また、拡張性を高めるためにホームセキュリティサーバに実装したプラグイン機構は、プロジェクト2のフレームワークのプラグイン機構のベースとなりました。

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です

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

* 機械学習 - 付随して、数学と統計 * 学習中のGo言語を製品開発に使えるレベルにする * 自分が実装したい欲を抑える技術 - プロジェクトの状況から仕事の交通整理が必要と感じつつ、手を動かしたい欲に負けることが多い

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

* [Googleを支える技術](http://gihyo.jp/magazine/wdpress/plus/978-4-7741-3432-1) * [Code Complete](http://ec.nikkeibp.co.jp/item/books/589000.html)

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

* 自分のしている仕事が、誰にどのように役に立つか把握し、納得できている状態 * 自分のしている仕事が、周囲から期待されていることを感じる環境 * 少数の課題に全力を注げる環境 * 静かな環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
金融 / 人材 / ゲーム
その他の特徴
レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする
その他のやりたいこと・やりたくないこと

■やりたいこと
・責任感を持って開発し、自分が本当に良いと思えるサービスをユーザーに提供したい
・計測・評価と改善を繰り返し、継続的にサービスを開発したい
・レガシーなノウハウも最新技術も組み合わせて、良いサービスを追求したい
・自分の知識・経験を一緒に働く仲間に伝え、仲間の知識・経験を吸収し、ともに成長したい

■やりたくないこと
・数を求めて品質の低い製品を多数開発すること
・なぜやるのか分からない開発
・Windowsで動作させるアプリケーションの開発
(付随して、C#や.NETなど、主にWindows環境で使われる言語やフレームワークに大きな抵抗があります)

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
Vim
希望勤務地
東京都 / 神奈川県
希望年収
600万円
ただいまの期間
ドラフト参加受付中

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

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

※個別回答は行っていません。ご回答が必要なお問い合わせにつきましては「CONTACT US」よりご連絡をお願いいたします。
  • {{error}}
ID:8646さん
今年で30代前半
Vim
参加ステータス
不参加
転職意欲
参加回数
1回
累計平均提示年収
597 万円
SIGN UP
SIGN IN


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