mekotan

自己推薦一覧

自己推薦はありません

3年後の目標や野望


短い時間で最大の価値を出せる実力をつけたい。

時間はかけがえのないものだから、大切に使いたい。 仕事にかける時間は短くともしっかり成果を出し、作った時間で家族と過ごしたい。

年収評価シート

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

2017年/2年以内

マイクロサービス化プロジェクト

# マイクロサービス化の実践・推進と、それを一緒に進めるチームのリードをしていました。 - マイクロサービス化チーム作りでは、一緒に進めるチームメンバー4人全員がマイクロサービス化の推進をリードできる存在になることが必要でした。 - マイクロサービス化の実践については、巨大なモノリシックなサービスを小さいサービス群に分割するための実現可能な方法を見出す必要がありました。 - マイクロサービス化の推進では、システム開発部のメンバーに必要性を理解してもらい協力してもらえる状態にすることが必要でした。 ## マイクロサービス化チーム作り - チームメンバーが皆同じところを目指せるようにする必要があると考えました。 - そのためにまず、ゴールとそれに向かう手法について、また、なんのためにそれをするのかについて、認識を揃えました。 - 当初はメンバーができることがそれぞれ違いましたが、全員がマイクロサービス化に必要な技術を身につける必要があると考えました。 - そのために最初は各々ができるタスクを担当してもらいつつ、並行してマイクロサービス化に必要なスキルマップを作り、次第にタスクをこなしながら必要なスキルを習得してもらえるようなアサインに変えていきました。 ## マイクロサービス化の実践 - 当初、部長の考える手法がありましたが、複数サービスのまずはバッチだけを切り離すという無理が生じる方法でした。 - そのため、サービス丸ごとをひとつずつ切り離していく方法が良いことを提案して進めました。 - 巨大モノリシックなシステムからサービスを切り離していきますが、データベースも切り離そうとすると、システム停止を伴わなくてはなりませんでした。ユーザからお金を頂戴して24時間サービス提供しているシステムのため、頻繁にシステム停止をすることができません。 - そこで、段階的に独立化をすることにし、まずはデータベースだけは共有したままで、他の部分は全て切り離されている状態を目指すことにしました。この状態を「ほぼ独立化」と呼称することにしました。 - 新しいサービスを作る際は、始めから「独立化」または「ほぼ独立化」して開発する必要がありましたが、システム開発部のメンバーは、サーバ構築依頼をし、Rails.newして必要な設定を入れ、デプロイ設定をするなどの経験をしたことがない人がほとんどでした。 - プラットフォーム部と共に、サーバ構築依頼をする際のテンプレートを作成し、必要なスペックやミドルウェアなど抜け漏れないように依頼できる仕組みを作りました。 - Rails.newした後に誰でも必要な設定を入れられるよう手順書を作成しました。のちに、技術部の人が質問に答えると必要な設定が入るgemにしてくれました。 - デプロイタスクも一部をgem化し、簡単にデプロイ設定ができるようにしました。 - ロジックが高凝集・疎結合な状態であればサービスとして切り出せるのですが、巨大モノリシックなシステムの中はロジックが一箇所にまとまっておらず影響範囲も広い状態でした。定数に至っては、影響範囲がシステム全体にまで及んでいました。しかしながら、頻繁に改修が発生するサービスについてはコンフリクトする可能性があるため、マイクロサービス化チームが直接手を加えることはできません。 マイクロサービス化チームで手が出せないものはシステム開発部で改修を進めていく中で、少しずつ高凝集・疎結合な状態に近づけてもらう必要がありました。 - 現行の巨大モノリシックなシステムではどこにロジックを設置しても影響範囲が広くなってしまう欠点がありました。それを防ぐため、そこに置くだけでスコープが狭くなるディレクトリをいくつか設置し、高凝集・疎結合となる考え方と共に伝え、システム開発部に活用してもらえるようにしました。 - 定数についてはymlファイルを読み込んでincludeしたクラス内で扱えるようにするためのgemを作成しました。スコープを最小限に狭めることができた上に、gemに暗号の複合化機能も備えたため認証情報なども管理できるようになりました。ymlにrubyのコードを書いておけば読み込まれた時にerbで変換される機能も備えたおかげで実用性が高く、今でもシステム開発部の定数定義のスタンダードとして利用されています。 ## マイクロサービス化の推進 - システム開発部は人数が多く(50名以上)全員に足並み揃えてマイクロサービス化を考慮して開発してもらうことが困難でした - 全員にマイクロサービス化のメリットと必要性を伝えた上で、具体的な手法は各チームリーダに伝え、開発業務の中でチームリーダがメンバーに少しずつマイクロサービス化のための技術を伝えてもらう方法をとりました。 - マイクロサービス化、高凝集・疎結合へのリファクタリングなどを進めている一方で、また新たに密結合なサービスが作られてしまう懸念がありました。 - 定期的にチームリーダにヒアリングを行い、少し先に予定されている案件で初めから独立サービスとして作った方が良いものや、開発の中でリファクタリングできそうなものがないか、このような場合どうすれば良いかなど、相談する機会を設けました。   最後までお読みいただきありがとうございました。

マネージメント能力

アピール項目


アウトプット

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

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

未入力です

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

- ブラックコーヒーと静かなフロア。もしくはリモートワーク。 - 話をしっかり聞いて理解してくれて、建設的な話ができる上司。

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
プライベートとの両立
やりたくない分野
アダルト
その他の特徴
レガシーな環境を改善できる
その他のやりたいこと・やりたくないこと

ウォーターフォールよりもアジャイルで開発したい

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きな Text Editor
vim
希望勤務地
東京都 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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