Dim

自己推薦一覧

自己推薦はありません

3年後の目標や野望


ものつくりにこだわり続けるスペシャリスト

**ものつくりにこだわり続けるスペシャリスト**を目指したいです。 私は良いものを作るプロでありたいと思っています。 良いものとは、関わった人がハッピーになるようなものだと思っています。 出来上がったものが結果としてどれだけプラスのインパクトを生み出すかということを考え、実現するためのスキルや知恵、機転があるような人が素晴らしいと思うからです。 技術を通して人に体験を与えることができるというエンジニアという職種であるため、技術を磨く運用するといったことは常に意識しています。 技術を磨くことに並び大切だと思っているのはものつくりとは一人だけで行うものではないのだということです。 良いものは志を同じくした優秀なメンバーと磨き上げることで作れると思っています。 私自身プロジェクトを円滑にすすめることもできる機転の効く人間でありたいし、そういったメンバーが集まるような会社で働きたいです。 # 次の会社で挑戦したい、期待していること 開発者としてとことん突き詰めたいです。 現時点ではゼネラルに立ち回っていますが、指向性としてはバックエンドを中心に能力を伸ばしていきたいです。

年収評価シート

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

2021年/半年以内

建設SaaSアプリケーションの新機能開発(外部連携用バッチシステム)

# プロジェクトの背景と課題 ### プロジェクト概要 建設業における、工事外の書類業務をITによって効率化、改善し本来の工事そのものに集中できることを狙いとしたSaaSアプリケーションになります。 その中で、**外部機関の提供するAPIを利用し、プロダクトに蓄積した工事情報を連携する機能**を作成しました。 ### プロジェクト実行時に感じた課題 - API仕様が複雑である点 - 連携データと、自社プロダクトのデータ的差分 - ドメイン駆動設計への挑戦 - 処理データ量の多さ # 担当業務 ### プロジェクトマネジメント 私自身もプレイヤーとして換算をしながら、プロジェクトマネジメントを実施 全体人数は私含め5人程で、プロジェクトの方針や外部機関との折衝、不確実性削減のため行動をしました。 - スタートアップと大企業(外部機関)の速度感の差を意識して最大効率で連絡を取る - ドメイン駆動設計という技術的挑戦もあったので、リード期間を設けることで初速を上げた - 連携をする上で、不都合となり得る点を精査し、外部機関とのやり取りで課題として取り上げ、双方納得する形で推し進めた。 - 目標を常に確認しつつチェックポイントの設定を怠らず、適切な工数で実施 ### 実装 対象データ量が多い、また今後利用ユーザの増加によるDBへの負荷を考慮し、バッチ処理用DBをユーザアプリと切り離して利用できる設計としました。 バックエンドFWとしてdjangoを利用したのですが、複数のDBを切り替えて利用するルーター機能に関する情報が少なく実装の際には、ドキュメントを読み込む等をして対応しました。 またデータの加工処理を常に成功した前回の差分から作り出すことで再実行時に必ず冪等となるような仕様、設計としました。 データを効率的に処理できるようORMだけでなく、チューニングしたSQLを部分的に使うことで処理効率を向上させました。 弊社プロダクトとして0~1で作るものが久々であったため今後のお手本となるような品質を目指し、ドメイン駆動設計、テスト駆動を基本とし実装しました。 # 学び - 目標設定とチェックポイントの設定 スタートアップとしては半年弱という、長期のプロジェクトでしたが、目標設定とチェックポイントの設定を徹底することで、無理なく対応することが出来た。 設定するだけでなく、常に見直すことも大事で、**長期的なプロジェクトであっても随所随所にインテグレーションの機会はある**のでそれを見逃さない目を養えたと思っています。 - 設計パターンや手法の選択肢 今回はドメイン駆動設計、テスト駆動設計を実施しましたが、プロダクトの規模やフェーズによってはドメイン駆動設計は毒にも薬にもなるなと肌で感じられたこと。 インテグレーションを前提としたサイクルを回す開発においてはテスト駆動設計は切っても切り離せないものであるという点を感じられたことです。 特にテスト駆動設計については、自分が想像していたより早く恩恵が得られたと思っており、慣れないドメイン駆動設計でコードの修正がやや多めに発生していたとも思っており、それを支えられたのはテスト駆動設計を徹底していた点だったなと。。 またテストコードは万能ではなく、モジュールが適切に設計されていることによってより力を発揮する、インテグレーションの回数を増やせば増やすほど効果が増すといった点

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

2018年/2年以内

帳票出力アプリケーションの新機能開発2

# プロジェクトの背景と課題 ### プロジェクト概要 大手ケーブルTV会社用の、施工業務アプリケーションの新規機能追加開発です。 外部サービスののIOT機器を料金プランに含めるという対応で、公開された外部APIを利用し機器の利用設定等のプロビジョニングを行えるようにする対応です ### プロジェクト実行時に感じた課題 - 対応機器が2種類あり、うち1種類は海外スタートアップの機器である点 - 国内企業は外部APIの設計がされておらず、弊社開発と同時に作り始めていくという点 # 担当業務 # 要件定義・外部企業との折衝 導入したい外部機器の仕様や、導入上のアプリケーション側の壁等をまとめあげ、顧客に対しての説明資料を用意、プレゼンを実施しました。 また、外部企業の1つは海外もう一つはAPI未設計というのもありとにかくコントロール性を高く保つためやり取りをする上で必ず、ドキュメントを残す、非効率にならぬようコミュニケーションの精度を高めるため問題点、課題等の事前認識統一、利用する語句の統一を徹底しました。 また、API未設計側企業に対しては、他社の設計ではありますが、コンサル的な立ち位置を確保することで最後までコントロール性を高く保つことができました。 ### 担当機能の設計 外部APIは検証環境が用意されていなかったため、独自にモックサーバを建てる必要性を初期段階で訴え、設計工程に組み込みました。 外部APIを呼び出すというのがプロダクト上で初めてであったので、今後自社だけでなく外部APIを呼び出すケースが増えると想定しHttp通信用ライブラリを利用した汎用的なAPIクライアントを作成しました。 ### 実装からテスト モックサーバは、顧客が業務トレーニングとしても使いたいという要件があったため既存業務の通しに耐えられる用独自にDBを用意するなどして対応。 バックエンド機能の特にAPIハンドリング部分を担当しました。 また課題として海外企業のリリースサイクルスピードが早い、修正点を通達しないで修正するケース(実際開発期間中に発生し、問題となりました。。) を事前に変化を察知する仕組みが必要と考え、主機能の開発とは別で利用APIを定期実行で自動でコールし、前回との差分をチェックする効率化ツールを用意しました。 # 学び - コミュニケーションの重要性 黙々作業を求める層が多い業種ではあるが、プロジェクトを前進する上ではステークホルダーとの会話が特に重要であると学んだ。 課題解決のマイルストーンがしっかり話し合われて適切なFBが存在するならば実装プロセスの差異(品質担保するための技術力はもちろん大切ですが)誤差でしかなく、情報の不透明性から生まれる手戻りは事業観点から見るとマイナスを生むだろうなと感じました。

2018年/半年以内

帳票出力アプリケーションの新機能開発1

# プロジェクトの背景と課題 ### プロジェクト概要 大手ケーブルTV会社用の、施工業務アプリケーションの新規機能追加開発です。 施工工程として多くのプロセスがありながら、iPadより入力した帳票を最後まで入力しないと帳票を出力できず、並行した施工作業や、アプリのクラッシュ時に入力した帳票データが残らないという点を、一時保存という機能を追加することで解決するというプロジェクトです。 ### プロジェクト実行時に感じた課題 - 歴史のある大規模なアプリケーションであるという点から、知識などが属人化している - 大規模アプリケーションであるにも関わらず、テストコードが存在しない # 担当業務 ### 担当機能の設計 「一時保存」というデータ的な妥当性を求められる機能なため、特にトランザクションの意識、ユーザ業務の中でどこまで保存されていると嬉しく、逆に保存すべきでない箇所(施工業務なので業務ルール上データ的な新鮮さが求められる箇所)の洗い出し等、前回プロジェクトで疎かにしていた事前準備を徹底し設計業務に当たりました。 ### 実装からテスト 既存プロダクトが大きいかつ、慣習的要素が強いコードが多かった背景もありなるべく全体バランスを崩さないように実装しました。 またテストコードの重要性を、過去の単体ケースでの手戻り率等数値で語ることでステークホルダーを説得し、新規追加分についてはテストコードを導入しました。 # 課題 - ドメイン知識の複雑さ ドメイン知識については、自身が営業をできるのではないかと自信を持てるまで関連資料を読み込むことで対応しました。 - コード品質の低さ テストは、案件ごとにエンジニアがポチポチして実施するという非効率なものとなっていました。 また業態上エンジニアの出入りが激しかったため、人によらないテストの必要性を感じました。結果として全てに導入することは叶わなかったですが、前述の通り一部へ導入することができました。 # 課題 - ドメイン知識の複雑さ ドメイン知識については、自身が営業をできるのではないかと自信を持てるまで関連資料を読み込むことで対応しました。 - コード品質の低さ テストは、案件ごとにエンジニアがポチポチして実施するという非効率なものとなっていました。 また業態上エンジニアの出入りが激しかったため、人によらないテストの必要性を感じました。結果として全てに導入することは叶わなかったですが、前述の通り一部へ導入することができました。 # 学び - 一人では限界があるということ テストコード導入の件では、とにかくステークホルダーを巻き込むことの大切さを強く学びました。 場合によりますが、既に成熟した文化がある場合にそこに異議を唱えることの難しさと達成したときの肯定感はただ、言われたことをすればいいという中では得られない良いものでした。

2017年/1年以内

介護施設情報管理Webサービスの立ち上げ

# プロジェクトの背景と課題 ### プロジェクト概要 被介護者と介護施設を繋ぐ役割をもつケアマネジャーをサポートするサービスとなります。 介護施設の入居状況や、各入居者の加入オプションや入退去管理をWeb上で完結することで、ケアマネジャーが管理業務に追われることなく、本来の被介護者とのコミュニケーションへ集中できることを狙いとしています。 ### プロジェクト実行時に感じた課題 - 企画のみが存在する状態かつHowの部分や手を動かす人材の部分が決まっていない - 当時エンジニアとして参加した私は趣味でプログラミングをしていた業界未経験のエンジニアが担当 ### 使用技術 - Java1.8 - SpringFramework - SpringBoot - JavaScript - jQuery - AWS - EC2 - ELB - RDS - Amazon Route 53 # 担当業務 - 技術選定 - 基本設計、詳細設計、実装、テスト ### 技術選定について 選定自体は前述の通りとなります。 こちらに関しては正直反省点が多く当時自分のできる範囲で決めてしまったという点です。 特にエンジニアは何かを実現する際に、無意識に自分が出来るかどうかで発想してしまい、俯瞰すればより良い選択肢があるにも関わらず、目の前良いと思われるものを選んでしまう傾向があるかと思います。 今であるならば、リソース面やプロダクトの市場価値を試すべく軽量言語でのプロトタイピングと取り扱うデータのシンプルさ(究極今回の要件は所謂管理画面的なもの)からサーバーレスアーキテクチャを選択していたかと思います。 ### 実装業務について バックエンドサーバーをREST APIに従い実装。 知見等がなかったため特にURI設計などの仕様は既存のサービスであるGitHubやTwiter等を参考にしました。 フロントエンドは、Ajaxを利用した非同期SPAとして実装しました。 UIは掛けられる工数と、管理画面的な仕様であったためBootStrapを使用し簡潔に実装しました。 インフラは全く知識がなかったため、AWSのホワイトペーパーや、AWSSomeDayなどのオンラインカンファレンスを参考に、基本的なマルチAZ構成としました。 とにかく手が足りなかったため、当時選定した技術の中でなるべくマネージドに利用できる箇所はそれを徹底しました。 車輪の再開発を避け、セキュリティやUI等はFW、UIライブラリに頼りエンジニアが注力すべきDBのモデリング、業務ロジックの実装へ集中しました。 テストはテスティングFWを利用し、特に業務ロジックの複雑な箇所のみに絞りテストコードを用意、ビルドのタイミングで実施するようにしました。 # 課題 特に課題となったのが、未経験であった私が業務アプリケーションレベルのDBモデリングを以下にきれいに作りきるかという点でした。 走り初めは、ドメイン知識を仕入れることを疎かにした結果、新たな知識が入る度にDBの構造が変わるという最悪な形となっていました。 これではまずいと思い、とにかくどのような登場人物があるのか徹底的にリストアップしデータ的にまとめたほうが良いもの等を整理していきました。結果としてシンプルかつ無駄のないモデリングができたと思います。 # 学び - 無知は罪であるということ エンジニアは課題解決のプロであるべきで、視野の狭さは短絡的な解決を助長する - 責任範囲を広げること 実装は手段・過程であって課題解決にはもっと多くの要素が存在するということ

マネージメント能力

外部連携機能を追加するプロジェクトマネジメント
外部連携というコントロール性の低いものに対して、常に把握、不確実な部分をなくし適切なマイルストーンを用意すること
# 課題 ### 外部API仕様の不確実性への対処 外部担当者とのコミュニケーションを密かつ、常に弊社のプラスとなるようなやり取りを徹底した。 要件の特性上、外部担当者がこちらを審査するというパワーバランスがあったため、不利になる展開を避けこちらが進めやすいように、やり取りに注意を払いながら情報を確実に収集した。 ### マイルストーンの引き直し スタート時、不明瞭な情報が多いため初期に引いたスケジュールでは間に合わないことが判明 情報は常に不確実性が収束していくため、情報収集を徹底した結果判明した妥当な結果と判断 事業視点、現場視点を論点に上げ、意思決定者を巻き込み引き直した。 結果、問題なく納期通りに対応し事業、現場双方で炎上することなく対応できた。

アピール項目


アウトプット

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

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

- アーキテクチャの知見 - DevOps

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

いい意味で互いにわがままが言える関係があるような組織 相手を変に慮り、本質をつけないのは嫌いです。

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 人を集める力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI / 広告 / アダルト / 仮想通貨
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする
その他のやりたいこと・やりたくないこと

業界体質上、搾取などが発生せざるを得ないサービス(そうせず、立ち向かう場合は除く)

やりたい事

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

基本プロフィール

年齢
今年で20代後半
好きな Text Editor
Visual Studio Code、Inteli J Idea
希望勤務地
東京都 / 神奈川県
希望年収
700万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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