achan

自己推薦一覧

自己推薦はありません

3年後の目標や野望


いつまでも、誰かの役にたつシステムを作り続けていきたい。

まず、私はシステム開発(特にプログラミング)をしているときが一番楽しくて充実している。 そして、誰かの役にたつことをしているときにも充実している。 誰かの役にたつシステム開発をしているときはとてもとても充実している。 そのため、いつまでも、誰かの役にたつシステムを作り続けていきたい。 具体的にどんなサービスがいいかと言われたら、何にでもやりがいを持って取り組めると思う。 私は現在不動産業界のサービスのシステム開発を行なっているが、初めは不動産に興味が全くない状態だった。 だが、業界を知って課題を知ってサービス開発を行なっていく中で 次第にのめり込んで不動産業界が好きになり、そこでのサービス開発をしていることが楽しかった。 まだ知らない業界でも、知識を得て課題感を持って取り組めれば、何でも楽しくなると思っている。

年収評価シート

2016年/1年以内

お住みつきプロジェクト

# 概要 # 3年目(2016年10月)~4年目(2017年6月)の間に、クライアントが物件データを入稿し、ユーザに表示するまでのシステムを全体的に実装しました。 具体的には、 - 400ほどの項目がある入力フォームの画面を作成し、一時保存用のDB(MySQL)へのinsert、登録用DB(Oracle)へのinsert、 - DBからselectしたデータを整形しS3に保存するバッチ、 - S3のデータをAPIとして提供するBFF層、 - APIを利用してユーザにデータを表示するフロント側のサーバーサイド - テスト時の全体取りまとめ の実装をしました。 # できるようになったこと # - PHPフレームワーク(MAPLE)を使ったwebアプリケーションの構築 - フォームを作成しMySQLへのinsert、MySQLからのデータをselectし、画面に表示させること - フォームのバリデーションの実装 - JavaScript(jQuery)を用いた画面の操作(アニメーションやフォームのdisableの切り替えなど) - エンジニア5名とタスクを分けあって実装・結合してアプリケーションを構築する力(調整など) - 7人がかりで5営業日かかる大きなテスト時の、テスト計画とテスト実施 # 【入力フォーム画面側の実装】 # ## 問題 ## 既存システムがとても古いものであり、フレームワークのサポートも止まっている状態、公式ドキュメントもほとんどない状態、フレームワーク上に独自で規則のない開発が進んだ状態、アプリケーション全体に関して知見がある人がいない状態のスタートであり、とても開発が難航しました。 当初は、既存の別機能で入力フォームからDBへの登録を行なっている実装箇所があったので、それに習って進めることがよいと方針で決まっていましたが、既存実装がとても可読性が低かったり無駄な実装が多かったため、 その方針で進めてしまっては学習コストのために大幅に納期を過ぎてしまいそう、かつ今後運用面での効率も悪くなりそうと判断し、既存を意識しない、既存に逸脱したとしても自分たちが最良だと思える実装をしたほうが良いと思いました。 ## 改善内容 ## そのことを私から他のメンバーに打ち明けたところ、他のメンバーも同じ課題を感じていることが分かりました。 もともとはメンバーが単独で担当箇所をもくもくと進める方針でしたが、 お互いに担当箇所について分からないことや迷っていることがあれば積極的に相談したり、 何か困っていることがあれば発信できる時間を設けるようにしようと提案しました。 そうすることで、これまで単独で抱えていた問題をチームで考えることができ、 結合部分についての相談も自然とできる空気ができあがりました。 ## 成長したこと ## また、個人の技術スキルについても大幅に向上させることができました。 フレームワークに則った実装をしていると、ある程度ブラックボックスな部分が分からずとも実装ができる反面、一歩踏み込んだ知識を身につけることができません。 例えばバリデーションのコア部分、DBとの疎通を行うコア部分などです。 今回、ほぼ自分のコードで入力フォームからDBへのinsert処理、データ編集画面でのselect処理、バリデーションの実装し、 0から自分の中でフレームワークを構築していくスキルと、フレームワークに頼らずとも自分の力で製品作りができるんだという自信が持てました。 # DBからselectしたデータを整形しS3に保存するバッチ # この部分の実装については、新規でElasticBeanstalkを使用し、0の状態から要件定義、設計、実装を行いました。 ## 工夫したこと ## 要件定義の部分では、このアプリケーションが今後どのような立ち位置になるのかを考えるようにしました。 今後、他の機能としても使われることがあるのか、保守は誰が行うのか、整形の処理はBFF層と粒度をどのように分けるか、テストコードの粒度やコーディング規約はどのように定めるかということが重要になり、どの程度まで詰めなければ実装の際に手戻りが出てしまいそうなのか、どの程度まで決めればあとは実装しながら考えれば良いのかを学ぶことができました。 例えば、アプリケーションの役割や整形後のデータの大まかな形や、ディレクトリの切り方は前もって設計時に考えるようにしましたが、細かいデータ構造やクラスの使い回しをするかどうかなどは、実装をしながら進めるようにしました。 個人的には、このやり方で本プロジェクトはうまく進められることができたと思います。 ## 成長したこと ## また、実装の際にも個人の技術スキルをとても伸ばすことができました。 フレームワークのインストール(Sinatora)から行い、0の状態からアプリケーション作成を行いました。 実装の際には要件定義は済んでいたので、アプリケーションの設計はどのようにすればスッキリするのか(可読性が上がるのか)、どのようにすれば保守性が増すのかを意識して、全体の設計をすることができました。 具体的には、それぞれ整形する役割ごとにディレクトリを切ったり、今後改修が発生しそうなところはコメントと共にあえて切り離して設計するなどです。 さらに、Rubyの経験がまだあまりない状態での実装だったので、分からないことがあったらRubyが得意な先輩にとにかくすぐに質問するようにしました。 先輩にも事前に、私はRubyを書いたことがあまりないが、こういうことをしたいので質問させてくださいと調整をするようにしたのが良かったと思います。 Rubyの書き方や他言語と比較してのメリット・デメリットについても学ぶことができました。 加えて、0からアプリケーションを作成し、完成させることができるという自信にもつながりました。 # S3のデータをAPIとして提供するBFF層、APIを利用してユーザにデータを表示するフロント側のサーバーサイド、テストの取りまとめ # この部分に関しては、先述したバッチの実装を私がやっている際に、他のメンバーがメインで実装をしていたのですが、 結合部分での相談や設計の相談相手になることで関わっていました。 ## 学んだこと ## このことで、各実装者(自分含め)の担当箇所とどのような実装をしているかを全体的に把握することができていました。 そのため、テストの取りまとめをしている際に、バグの報告があがったら対象の実装箇所を大まかなアタリをつけることができ、実装担当した人への報告・可能であれば改善方法の提示・更に可能なら自分で修正を行うということができました。 そのようなことができたため、数十箇所報告されるバグの対応もスムーズに捌くことができました。 この経験から、大きな開発の際にはシステム全体を見渡せる存在の重要性とその動き方を学ぶことができました。

2015年/半年以内

街情報プロジェクト

# 概要 # 2年目(2015年10月)~2年目(2016年3月)の間、 外部企業から納品されたcsvファイルをコンバートしてDBに保存し、ユーザに表示するまでのシステム全体を 既存のアプリケーションの上に実装しました。 具体的には - 納品されるcsvファイルのデータフォーマットを、外部企業と相談して決定 - csvファイルを納品してもらうS3の作成と、バケットポリシーの設定 - csvファイルをRedisに取り込む定期バッチの実装 - Redisからデータをselectし、ユーザに見せるための整形処理を行うサーバーサイドの実装(同時に後輩のサポート) を行いました。 # できるようになったこと # - PHPフレームワーク(Symfony), Rubyフレームワーク(Sinatora)を使ったアプリケーション構築 - 外部企業との連携業務 - 後輩の育成・サポート - RedisへのCRUD機能をもつWebアプリケーション構築 - JavaScript(jQuery)を用いた画面の操作(アニメーションやハッシュチェンジなど) - テストコード(Rspec)の作成 - テンプレートエンジン(Twig)を用いたhtmlのレンダリング - キャッシュ機構の実装 ## 工夫したこと ## csvファイルを納品してもらうためのS3のバケットポリシーの設定を行なったときは AWSにはこういった、権限を簡単に制限できて外部に公開できるストレージがあるんだということを学べました。 また、データフォーマットを外部企業の方と相談して決定する際は 「ここのフォーマット(jsonの入れ子)が1つ違えば、私の実装がやりやすい」 など、実装時のことを考えて相談することで、実装時の負担を軽くすることができました。 また、何か変更したいときに連絡がつくようにコネクション(連絡手段)を作っておいたのが とても良かったと思います。 可能であれば調整を行うことで、自分の仕事の進み具合をあげることや、専念することができるということをとても実感しました。 ## 工夫したこと ## バッチの作成の際には、 基本的には既存実装に習って進めれば良かったので、 既存実装をしっかり把握し、前任の方からの引き継ぎと、質問をする手段と窓口を作っておきました。 ## 問題 ## Redisのデータをユーザ側に見せる実装の際には、 後輩のサポートも同時にしなければならなく、私のサポート体制が悪い点を見つけることができました。 チームとしては、「私」・「後輩」・「何か困ったことがあれば私と後輩の2人をサポートする先輩」という構図でした。 後輩のコードを私がレビューし、OKだったら先輩に更にレビューしてもらうという運用にしていたのですが、 後輩が納期ギリギリにレビューを出してきたコードに不備がたくさんあり、 納期に間に合わせるために私は最低限(動作するためだけ)のレビューでOKを出したのですが、 先輩の判断としてはリリースさせることはできないということになりました。 原因としては、 - 私が後輩の進捗を把握していなかったこと - 後輩のスキルを把握していなかったこと - 後輩が質問できる環境を用意できなかったこと - 先輩に後のことを丸投げしてしまったこと にあると、後ほどの反省会で分かりました。 ## 改善 ## その反省点を生かし、 私は後輩に「○○の実装を完了させるためには、△△をいつまでに、xxをいつまでにできないといけない。 そこに向かうまでに上手くいかないことがあったらすぐ質問するようにしてください」と説明するようにし、 また、定期的にMTGを用意して質問したいことがあれば質問できる時間を用意するようにしました。 更に、後輩が質問しやすい関係を気づくために、業務外のことであってもコミュニケーションをとるようにしました。 加えて、後輩の進捗を正確に把握しなければならないという環境に自分をおくために、 後輩の状況を先輩へ報告するようにしました。 先輩に報告するためにしっかりと進捗を把握するという意識上げと、把握できてなさそう・問題になりそうな部分があれば先輩に指摘してもらうようにしました。 このようなことを行うことで、後輩からのアラートはすぐに上がるようになり、 私が後輩のサポートができないときには、先輩にサポートを依頼するなどして、 プロジェクトを円滑に回すことができるようになりました。 ## 成長 ## プロジェクト全体を通して、私個人の技術スキルについても、成長を感じることがありました。 これまではテストコードというものを書いたことがなかったのですが、 既存の環境がテストコードを採用しており、書かなければなりませんでした。 テストコードの書き方を学んだというのも一つですが、 どのようなテストを書かなければならないのか。どのような異常値が発生することがありえるのか。 (例えば、納品フォーマットと画面仕様が食い違っている点など) ということを意識することで、テストの必要性や必要なテストはどんなテストかを考えられるようになりました。 また、そもそもの要件がSEOのために実装したというのもあって、 ページを表示する早さも意識し、キャッシュの機構の実装も行いました。 ただ単にキャッシュをするだけではなく、キャッシュをすることで逆に遅くなってしまう場合や キャッシュをすることで変更を行いたいページで変更が行われなくなったりすることの注意点を学びました。

2014年/半年以内

楽天プロジェクト

# 概要 # 1年目(2014年10月)~1年目(2015年3月)の間、 HOME'Sにある大量のページの中で、 必要なページにだけバナーを表示させる表示部分だけの実装を行いました。 # できるようになったこと # - Seleniumを使った自動テストの作成 - PHPフレームワーク(Symfony)を使ったWebアプリケーションの保守・運用 ## 工夫したこと ## 大元にあるテンプレートファイルに表示の実装を行い、 不必要なところだけ非表示にするという実装を行いました。 ページが大量にあったので、まずは仕様の精査から始めました。 当時はサポートしてくれる先輩がいてくれていたので、一緒になって仕事を進めました。 内容としては、 - ディレクターの要望の精査 - 要望通りに実装する際の工数見積もり - 要望を削ることで費用対効果の高そうな箇所(あまり見られていないページだが、実装が難しい箇所など)の調査 を行いました。 ## 学んだこと ## その中で、あまりに実装工数がかかってしまいそうだが、あまりそれをしたところで効果が低そうなページなどをディレクターと相談するようにしました。 単純に仕様通りの実装を行うだけではなく、 エンジニアだからこそ言える、効率の高め方があるということを学びました。

マネージメント能力

プロジェクトのテストフェーズにおける、テスターの采配とバグ改修担当者の采配
テストを完了させるという目標を完了する責務があり、 ・テスターの采配 ・バグの報告を受け付けること、更に報告された内容のまとめ。 ・バグの改修の担当者の選定。 を行いました。
テスト項目と、それを担当するテスターの表を作成し、当日の早朝にMTGを行なってどのようなテストを実施してバグをどのように報告するのかを全員に共有することが必要だと思い、行動しました。 更に、報告されたバグをどのように担当を割り振ってクローズさせるのかを、技術全員に周知することが必要だと思い、そのようにしました。 ただ、進めている中で、バグ報告の窓口が圧迫してしまった問題があったため、バグ改修担当の中から人員を選定し、窓口を増やすようにして対処しました。

アピール項目


アウトプット

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

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

身についている知識としては、インフラ~アプリケーションまで単にサービスを構築するための技術が身についているので 今後は、冗長化やスケールするための技術を身に付けたいです。 また、技術がどんどん発展してきている昨今、壊しやすくて作りなおしやすいシステムがビジネス的にも必要になってくると思うので、そのようなシステム構築のやり方も身に付けたいです。

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

SOFT SKILLS ソフトウェア開発者の人生マニュアル https://www.amazon.co.jp/dp/B01GDS0994/ リーダブルコード https://www.amazon.co.jp/dp/4873115655/ JavaScript: The Good Parts https://www.amazon.co.jp/dp/4873113911/ Effective JavaScript https://www.amazon.co.jp/dp/4798131113/

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

- 一緒に活動しているメンバーが尊敬でき、また私のことを尊敬してもらえている環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 調整力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / 趣味は仕事 / OSSのコミッターである
その他のやりたいこと・やりたくないこと

特になし

やりたい事

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

基本プロフィール

年齢
今年で20代後半
好きな Text Editor
vim / IntelliJ IDEA
希望勤務地
埼玉県 / 千葉県 / 東京都 / 神奈川県 / 愛知県 / 京都府 / 大阪府 / 兵庫県 / 福岡県 / その他地域 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
600万円
ただいまの期間
ドラフト参加受付中

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

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

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


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