【ゴールデンウィーク営業のお知らせ】 2024年4月27日(土)~2024年5月6日(月)の期間中、GWのため休業とさせていただきます。 ※4月30日(火)、5月1日(水)、2日(木)は通常営業いたします。 ※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。

ID:26135さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


会社や開発メンバーから信頼されるテックリードエンジニアになりたい

私が参加したプロジェクトにおられたテックリードの方に純粋に憧れ、そうなりたいと考えたためです。

年収評価シート

2020年/半年以内

料理レシピ投稿・検索サービスの開発(開発途中)

# 開発背景 開発理由はいくつかあり、1つめにポートフォリオを何か作成しておきたい、2つめに学生の頃に行っていた趣味のプログラミングの感覚を思い出したい、3つめに私の趣味である料理レシピをまずは自分のために管理、精査、分析したいの3点によるものです。 この3点をクリアし満足した際には外部に公開してより情報を収集したいとも考えています。 # 目的 - ReactJsとDjangoRestFrameworkの学習 - 「レシピ研究サイト」というサービス像を形にし、果たしてこのサービスでより良いレシピができるか検証すること # システム概要 バックエンドはAPIを、フロントエンドはSPAの2つのサービスから成り立ちます。 実装機能は以下です。 # 各種リンク ポートフォリオサイト https://shortbread2329.github.io GitHub https://github.com/shortBread2329/CookLab ※現在はfeatureReactMockupブランチで開発途中です。 # 使用言語・フレームワーク・API等 - バックエンドAPI - DjangoRestFramework - Python - フロントエンドSPA - ReactJS - JavaScript - SemanticUI # 開発環境・ツール | 端末・ツール | 名称 | | :--------------- | ------------------------ | | 開発端末 | デスクトップ Windows 10 | | デバックブラウザ | Chrome | | IDE | VSCode | | ソース管理 | Git,Github | # 開発前の私のスキル pythonの実務経験はスクリプトの開発を一年未満ほどと、趣味でスクレイピングツールを開発した程度でした。Reactについては、どんなフレームワークなのか耳にしていただけでした。 # 開発フロー 1. 簡単な要件定義、サービス像の簡易的な文章化 2. 画面レイアウトのスケッチ 3. 画面の構成検討 4. フレームワーク選定 - DjangoRestFramework採用理由 - 趣味の時間なので、経験してみたいが一番の理由ですが、それだけではなく、ORMと管理画面が便利そうである点、あとDjangoRestFrameworkの「ModelViewSet 」というものを使い、モデルを作るとCRUD APIがほぼ出来上がる点の2点から、開発効率がよいのではと考えたためです。 - ReactJS採用理由 - 開発以前の、私のフロントエンド開発スキルはJQueryでしたが、今回のシステムをJQueryで実装していた場合は複雑になりそうでしたので、脱JQueryが一つの理由です。あとはVueJsを少しかじっていたため、ReactJSがどんなものなのか知りたかったためというのがもう一つの理由です。 5. 開発準備 - Githubのブランチ作成 - DjangoRestFrameworkのインストール、管理画面の使用感確認 - ReactJSインストール - CORSの導入、ハローワールド実行テスト 6. 開発 - SPAにトップ画面をデザインの通り作成 - APIにModelを作成することでレシピデータベースやCRUD APIを構築 - SPAにレシピ参照画面の作成、動作確認 - SPAにレシピ投稿画面の作成、動作確認を実施するが、Modelの構築に問題が見つかる - APIにModel改修を実施し、投稿機能が一連の動作をすることを確認 - 現在開発中 # 今後の予定 - レシピに画像も投稿できるようにしたい。 # 苦労した点 まずCORSについての理解です。セキュリティのためにリクエスト制御はしないといけないなと考えひとまず導入してみましたが、CORSによるHTTPリクエストの流れが勉強不足だったことによって、自身が実装したAPIのPOSTリクエストがなぜはじかれるのか、原因調査に時間がかかりました。この事象に対して、いったん落ち着き冷静になってから、公式ドキュメントなどからCORSのリクエストルールを調べ、リクエストヘッダに余計なヘッダーを設定していたことが分かりました。 ReactJsのState管理もすぐには慣れず、Stateを複数回更新してしまう、Stateの更新ができずにボタンを2回クリックしないと画面が表示されない(1回クリックしただけではクリック前のStateの状態)というような事象が多発し悩みました。State管理を復習しなおした上で現状をフローチャートにし、絵にかくことで頭を整理することで問題を解決しました。 # ここまで作った成果と感想 まだ完成していない点は、新しい技術に挑戦しすぎ、勉強コストがかかっていることが原因だと感じていますが、逆に言えば、ここまで新しいことに挑戦し、今まで経験したことのない障害がありましたが、基本機能がある程度完成するレベルまで自分の力で実装できたことが成長を感じます。

2019年/2年以内

物流系システム移行に伴うマイクロサービスやAPIの開発

# 背景 既存システムの追加開発を行い続けた結果、運用コストがかかっている点の改善や、システムの統一化と可視化を目的とし、スケーラブルなパブリッククラウドを採用したサービスへ移行する方針が決まった。 # 既存システム概要 まずクライアント(発注依頼者)から発注データを受信し、システム内部でデータ加工を行った後にメーカー(発注受付側)サービスへ転送、同様にメーカーから受注データを受信し、購入先へ転送するような機能を持ったサービス。 そのサービスがメーカーごとに待機しており、複数のシステムから構成される既存の物流系基幹システムが運用されている。 既存システムがクライアントやメーカーサービスからデータを受信する際に、別のプロジェクトで開発されたシステムを通して情報を受信していた。 # 新規システム開発概要 既存システムと同様のサービスに加え、各種クライアントやメーカーサービスからデータを受信する際は、各会社ごとの通信仕様に合わせて独自に開発する。 # 使用言語・フレームワーク・DB・使用サービス等 - Azureサービス - AzureFunction - WebApps - AzureSQL - AzureCosmosDB - TableStorage - 開発言語 - .net C# - Python3.6 - PowerShell -使用フレームワーク - AzureFunction - asp.net MVC - XUnit - Moq - ミドルウェア - SQL Server - NoSql # 開発環境・ツール | 端末・ツール | 名称 | |:------------|-| | 開発端末 | Windows 10 | | IDE | VisualStudio 2017 | | ソース管理 | Git,GitLab | | デプロイツール | Jenkins | | プロジェクト管理 | Redmine | # 担当作業内容 4月から9月まで1メーカー用新規サービスの開発を一人で担当し、 システム基本設計からシステムリリースを実施した。 10月から現在は別メーカー用新規サービスの基本設計から単体テストまでを実施し終えました。 # 課題 - 知識の共有をするための場所などは整っていたように感じたが、技術者のアウトプットが足りていないように感じた。 - 新規開発したシステムであったが、多くの物流データに対応するため機能追加がたくさん行われ、ソースの冗長化やリファクタリングができる点がいくつかあった。 - AzureFunctionsのランタイムv1でこのシステムは動作していますが、v1は更新がほぼ無くなったためv2への移行(.net Frameworkから.net Coreでの開発へ移行)をすることや、ログの出力管理などの移行後仕様については決まっていたがいつ実施するかなどの見通しは立っていなかった。 # アプローチ - Redmineのナレッジベース機能を使用し、すべての単体テストに使用している基底クラスに使用しているxUnitのテクニックや、Moqフレームワークの活用方法について記事を作成した。 - リファクタリングの提案を実施した。具体的には機能が膨大になったクラスに対しpartial句を使用した部分クラス化を提案した。 - メインシステムの起動トリガーとなるスクリプトだけでもv2への移行を考慮し、ログ出力を改修の中で事前に実施することを提案した。提案の際にv2移行が本格的に開始した際にもスムーズに取り組めるなどのメリットを開発メンバーやリーダーに説明した。 # 解決 - ナレッジベース機能に記載した記事をSlackで開発メンバーに通知したが、反応はとても好評でした。プロジェクトを離任し、私中心で開発した部分はどんなテクニックを使用しているか、しっかり残すことができました。 - EDI追加開発中に追加で部分クラス化を実施することが決まった。 - EDI追加開発中に追加で起動トリガー用スクリプトのログ管理の改修を実施することが決まった。 - その後も追加機能を実装したEDIシステムのソースコードが読みやすくなった。 # 成果 - 開発メンバーに展開した際にちゃんと分かりやすい記事であったり、プレゼンテーションを実施するスキルが鍛えられました。 - システムの改善案を提案する能力が鍛えられた。PDCAサイクルをこれまでのプロジェクトに比べて意識したように感じた。 - 上流(基本設計)から下流までを初めて担当し、システム開発の一連の流れを学びました。 - 開発を担当する機能がAPIが多く、プロジェクトの開発メンバーの中でも経験が多く、そのスキルに関してスキルを共有することが多くなりました。

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

マネージメント能力

アピール項目


アウトプット

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

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

- Azure上の各種サービスについてより理解しておきたいです。

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

飲食可能、デュアルモニタ環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 分析力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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