ID:15092さん

3年後の目標や野望


個人としてはグローバルに活躍できるようになりたい。また、今までお世話になったOSSに恩返しがしていきたい。

年収評価シート

2017年/1年以内

旅行予約システム刷新

既存の旅行予約システムの刷新を行うプロジェクトに要件定義から参画。 主にサーバサイドの設計実装、テスト及びそれを行う小規模(3~7人)なチームのマネジメント行う。 新規機能の追加の為の刷新というよりも、既存システムの不満点の解消や、システムデザインがビジネスに合っていない事による(e.g.データモデルが正規化されていない、状態遷移が曖昧な事によるサーバフロント間の状態ずれなど)不具合の解消や高い保守コストの削減を目的とした刷新であったので、 要件定義の段階の早い段階からプロトタイピングを行い、画面モックやDFD、UMLの各種図表により顧客や実際に使用するオペレータと意見を交換しながら仕様を固めていった。 技術的なシステム構成としては、フロントエンドはAngular 4を用い、DOM操作や描画は主にこちらで行っており、サーバサイドはWeb APIとして動作をし、都度必要な情報の提供を行う。 サーバサイドは認証機構として独自のSSOを利用するためSpring Securityを拡張し認証、認可を実装し、冗長構成におけるセッションレプリケーションをSpring Sessionにより実装、Web APIとしての基本的な機能(HTTPリクエストのハンドリング、データベースへのアクセス、データ整形等)はSpring Framework 4 , Spring Boot ,Spring Data JPA (Hibernate)により構築、単体試験はSpockというフレームワークを用い行った。 実装時のコードはJava 8とKotlinを用い、単体試験コードのみGroovyを用いた。 基本的にはJava 8により実装を行い、DTOやドメインモデル等どうしても冗長なコードが多くなってしまう箇所に部分的にKotlinを採用し実装する事により、コード量を減らし、可用性、保守性を高めた。 技術的に特に難しいことをしていたわけでは無いが、とにかく変更が多く、自ずとOOPやDDDについて深く意識し解りやすいコードについて再度考える事となった。(e.g. ドメイン層にはどのような処理をカプセル化するべきか、サービス層の責務はどのように分類するか等) RDBMSのデータスキーマも都度変更があり苦しめられたが、幸いJPAによるO/R Mapping及び、ドメイン層で大分吸収できたのでそこまで深刻な手戻りは発生しなかった。 ただ、チームメンバでHibernate(JPA)に対する知識があるのが私だけだったので、最後までN+1問題や意図しないLazy Fetchには対処が必要だった。 チームのタスク管理及びCI/CD環境はGitLabによりAWS上に構築し、少人数のチームではあったがGitLab Flowにより開発を進めPushをトリガにGradleを用いてビルド、単体試験、コード検証、パッケージング、そしてデプロイまで行っていた。

2010年/2年以上

携帯電話用RF計測器のUI及びドライバの設計開発

携帯電話用電波計測を行う計測器の新規UIの設計開発を行うプロジェクトに参画。 核となる信号処理を行うデコーダや、それに対する処理の伝達を行うドライバは前モデルのものをほぼ流用し、UI部分(計測結果の表示部分や、計測行う為の処理画面等)をWPF及びC#で新規に設計開発を行った。 技術的なシステム構成としては、UI部分はWPFにより構築され、そこからC++で書かれたライブラリを呼び出す。このライブラリは前モデルのドライバをラップしており、そこからCで書かれたドライバ、そしてFPGAの基盤に対して制御命令が伝達される。 全体的にとにかくタイミングにシビアなプログラミングが要求された。殆どの信号処理はFPGAで行われるが一部上位プロトコルの情報をライブラリで解析しドライバにフィードバックする必要があったり、一分あたり1GBになるログファイルを高速に読み込み解析し表示を行ったりと、しばしば既存の処理を高速化するため組み直したり、コンパイラの最適化結果をみながらコードを書き直す等する必要があった。 3gppSpecを含む無線関係の仕様書は英語しか存在しないので、英語読解能力も身につけた。

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

マネージメント能力

小規模(3~10人程度)の開発チーム
設計開発するソフトウェア品質の担保
Gitを用いた開発フローやコードの命名規則は事前に策定し、その上でフレームワークとして実装できる箇所(e.g. 画一的に行えるエラーハンドリング処理やトランザクション管理、フレームワークの機能で実装できる認証、認可処理等)とリファレンスとなる実装を私で用意し、他のチームメンバには、簡単な処理の実装を通じ開発のフローやフレームワークに慣れてもらうように進めていた。 ただし、私一人が絶対的な権限を持つ"神"にならないように、コードやドキュメントのレビューはチーム全体で行い、誰が書いたかに関係なくコードの品質についてメンバ同士で気軽に話せる環境にした。 Pull Requestはとりあえず出して皆でリファクタリングや修正を行い、またその履歴や経緯などを全て記録し一人に責任がのしかかる事が無いように努めた。 試験についてはまずはテストケースのレビューを行い、その時点でおかしい(e.g. テストケース名が長い、主語や目的語がはっきりしない等)場合はリファクタリングを行い設計の見直しを行うようにしていた。 また実装者と試験の実装、実施者はできるだけ別のメンバにし、客観的な視点を介在するようにした。 最初は手戻りがかなり発生したが、途中から試験を設計時から意識するようになり、自ずとシンプルな実装となっていった。

アピール項目


アウトプット

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

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

英語

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

静か。もしくは音楽聞いて良い。

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
年収が第一
やりたくない分野
SI / 金融 / 人材
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 3年以内には海外で働きたい / stackoverflowで回答した
その他のやりたいこと・やりたくないこと

ガント・チャートを眺めたり、見積もりをしたり、偉い人が読む稟議書を書いたりはできればしたくない

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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