kuluna

自己推薦一覧

自己推薦はありません

3年後の目標や野望


ものづくりを続けていきたい

## 自分やその周りの人が欲しいと思ったものをつくりたい 自分やその周りの人が欲しい・作りたいと思ったアプリやサービスを開発し続けていきたいです。世の中にはまだまだソフトウェアで解決できる問題や提供できる価値がたくさんあると考えています。 現在は1日1時間程度、趣味でUnityゲーム開発を行っています。これで得られた収益をもとに、次のアプリやサービスを作り続けていけたらなと思います。 ## (第2の野望)医療従事者をITの力で支えたい 妻が薬剤師です。毎日疲れ切った顔で帰宅し、日々トラブルに見舞われている話を聞きます。 システム導入によってある程度は良くなっているものの、そもそも効率的に業務を回すという観点がないまま様々なシステムやサービスが導入されています。 こういった現状を少しでも変えられるような会社に転職できたらいいなという気持ちが今とても強くなっています。

年収評価シート

2020年/2年以上

モバイルオーダーの自動テスト整備

## 概要 飲食店向けにモバイルーオーダーシステムを提供しているサービスを自社開発で提供しております。 私はSETエンジニアとしてサービスの自動テストを作成・運用・保守しています。 ## 取り組んでいること WebサービスのE2Eテストを作成しています。MagicPodとPlaywrightを使ってテストを行なっています。 メインのリポジトリと開発周期が異なるので異なるリポジトリでテストを構築しました。 毎日リグレッションテストを行い、すぐに挙動の変更に気づけるようにしています。 --- <font color="red">**Appeal Point**</font> E2EテストはUIの変更ですぐ失敗するので、今後のメンテナンス性を考慮しPage Object Patternを採用しています。テストシナリオ内の実際の操作を抽象化して実装することで落ちた箇所を特定、修正しやすくしています。TypeScriptを使いテスト自体の実装ミスも極力減らす工夫もしています。 また最近はノーコードでE2Eテストが可能なMagicPodを積極的にプロジェクトに導入しています。メンテナンス性が非常に高く、コードが読めないQAでもメンテナンスが出来るように取り組んでいます。 その中でもメール本文のテストなどどうしても手が届かないところはGoogleAppScriptを使ってWebAPI経由でテストを実施しその結果をMagicPodに返すという手法をとっています。GASならJavaScriptなのでほとんどのエンジニアでもメンテが可能です。 **自動テストはその有効性だけでなく、保守性についても考えながら作成しています。** --- 自動テストを作成する際にQAがこれまで行ってきたリグレッションテストシナリオを見直しました。 今まで最短経路でなるべく多くの機能に触れるようなシナリオだったものを以下の観点で分割しました。 - ユーザーが実際に利用する想定の操作をなぞる - 自動化できる箇所と手動でないとできないテストをシナリオ中に分けられるようにする 1つめはシナリオに意味を持たせるためと1シナリオを短くするためです。 シナリオが失敗した場合、そのシナリオで想定したペルソナユーザーが影響を受けるためバグの影響度が把握しやすくなります。 また1シナリオが短くなれば単純に保守性があがります。 2つめですが、提供しているモバイルオーダーサービスはWebフロントだけでなく店舗側の端末やプリンターといったハードウェアとの連携も含まれます。これらのリグレッションテストを行う際はどうしても自動テストだけでは全てカバーしきれません。 なので自動テストでできる範囲と手動でないとできない範囲をなるべく固めるようにしました。 例えば、 1. ユーザーが持ち帰り注文する 2. ユーザーに注文確認メールが届く 3. 店舗側が端末で調理完了にする 4. 店舗側が管理画面で売上を確認する というシナリオだった場合、店舗側が端末を操作しなければならない以上これを自動化するのは難しいです。一方で管理画面で売上を確認するのはWebから可能なため、この場合は5を2と3の間に持ってくることで、QAは残りの店舗端末の操作のみだけ手動でテストすれば良いというふうに変更しました。 以上の施策でどうしても手動でやらなければならないテストを除いたほぼ全てのリグレッションテストの自動化を完了させました。 --- テストだけでなく実装コードのコードレビューやペアプロ・ユニットテストの支援なども行っています。 コードが書けないQAに対してSETのスキルを身につける社内勉強会も行っています。

2018年/2年以内

スマートフォン向けシフト管理アプリ開発

飲食店などの店長さんとアルバイトさんとのコミュニケーションを円滑にするためのアプリ開発に加わりました。 新規事業として企画からMVPの策定、設計、実装・テスト・運用保守までほぼ全てのフェーズに関わっています。 立ち上げ当時は専任のiOSエンジニアがいらっしゃらなかったので、MVP段階では私がiOSとAndroidの両方をネイティブ実装しました。 メンバーが増えてからはAndroidチームのリーダーとしてバックログ管理を行いながら自身も継続して開発を続けています。 現在はiOSチーム4名, Androidチーム1名(自身)の体制です。 ## 常に新しい技術を取り込む 昨今のIDEや言語はバージョンがあがると生産性向上が期待できます。最新情報は常にキャッチアップし、すぐにアップデートして問題なさそうなら次のアプリのアップデートに含めるほどのスピード感で進めていました。 Androidチームでは以下の活動を行いました。 - Androidはプロジェクト初期はLiveData・ViewModel・DataBindingを使ったMVVM構成で作りました。 - 要件にはなかったものの、初めからレスポンシブにViewを作ることでタブレットで使うことも可能にしました。ViewModelを使えば画面回転後も値を保持してくれるのでほぼ全ての画面で画面回転に対応しました。可能な限りAndroid7.0から使えるスマホでのアプリ分割状態で操作ができるようにしました。 - コアのビジネスロジックは最終防衛ラインはもちろんAPIサーバーなのですが、クライアント側でも送信前にわかる範囲で入力チェックしてユーザーに知らせたいので単体テスト可能なオブジェクトにして新しい技術を取り込んでも壊れていないか確認できるようにしました。 - ローカルのプッシュ通知を出したかったのですが、Androidのバージョンが違うと実装ベストプラクティスが変わる状態だった中、JetPackからWorkManagerがリリースされたのでWorkMangerを採用しました。 - フォームのような縦に長い1ページのViewは一度に描画するとパフォーマンスに影響が出るためGroupieを使ってiOSのUITableViewと同じ設計思想を持たせて対応しました。 - Firebase RemoteConfigを使ってマーケティングチームから要望のあった箇所でA/Bテストを実施しました。 - リリースして1年立つとビルド時間と技術的負債が目立ってきたので、マルチモジュール化とクリーンアーキテクチャ化を進めました。現在移行途中ですが、現在14モジュールに分割され、1モジュールの変更なら3秒以内にビルドができるほどまで短縮できました。クリーンアーキテクチャは概念を理解するまでハードルが高いので社内でコーディングガイドラインという形で共有しました。 - Rxは当初から使っておらず、Kotlin Coroutineを導入しました。ViewModelでRepositoryを同期処理のようにかけるのでコールバック地獄がなくなりました。 - 全てのbuild.gradleをkts化しました。 iOS開発チームができてからも最新の開発環境を使い続ける文化が続いており、iOSチームも同じ文化を継承できています。 ## ユーザーのためになるバックログを意識 開発リーダーとなってからはバックログ管理で必ずユーザーストーリーはユーザーのためになるタイトルをつけることをルール化しました。例え社内の都合によって生まれたタスクであっても桶屋メソッドで最終的にはユーザーのためになるようにします。こうすることで全員がユーザーのためにプロダクトを開発しているという意識を持たせることができました。 ## QAやiOSチームとの連携 - 日本においてユーザーへのリリースインパクトが最も強いのはiOSアプリです。私はAndroid開発がメインですが、iOSのタスクが間に合わないと感じた時はPMと相談しスポットでiOSの開発に加わりました。プッシュ通知のハンドリングやアナリティクスイベント仕込み等、他のエンジニアがあまり触手が伸びないようなタスクを積極的に拾い対応しました。QAが対応待ちで手が空きそうなのを見てバグ修正を優先的に対応するといったこともしました。 - AndroidのBuild Variantsを使って社内版のアプリをFirebase App Distribution(旧 Fabric beta)で配布しテストしやすくしました。 ## 開発チーム以外にもエンジニアとしてできることをサポート - CSさんのサポートコストを減らすためにお客様環境を簡単に再現できるツールを勝手に開発しました。 - マーケティングさんをはじめチーム全体で常に追っていきたいデータを確認できるようRe:dashのダッシュボードを作成しました。 ## 一部UIをOSSで公開 シフト管理に必要な高度なUIはOSS化することによってIT業界へ貢献できると考えGitHubで公開しています。 https://github.com/kuluna/EventGridView 現在4名forkしてくださった方がいます。

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

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

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

マネージメント能力

エンジニア採用
会社でSREメンバーの追加が急務であり、早急に採用しなければなりませんでした。 カジュアル面談からなるべく面接に応募していただけるよう、まずは会社に興味を持ってもらえるようにする必要があります。
モバイルオーダーの導入店舗数が数千店舗増えることを見越して、サービスの安定稼働が課題となりました。 SREチーム(2名体制)を作り、まずはSLOを制定するというところまでは決定しましたが、そもそもの人員が足りないため少なくともSREを追加で1名を採用しなければならないとなり、VPoEの意向で「マネジメントに興味のある私に採用を担当するのはどうか」と提案を受け担当しました。 具体的にはカジュアル面談と1次面接を担当しました。まずは既存のスクリプトを元に会社説明を行えるように練習したり、面接で質問できるよう3ヶ月VPoEと共に面談・面接に参加しトレーニングしました。 現在ではエンジニアの職種全ての面談と1次面接を担当できるようになりました。 「面談から1次面接へのエンゲージメント率を50%以上」を数値目標とし、これまでに7名の面談を担当しました。うち5名が1次面接を希望していただき、エンゲージ率71%の状態です。 ただ、このまま全てのエンジニア職種の面談をするのはかなりの負担となるため、徐々にSREの2名にもカジュアル面談が出来るようにトレーニング中です。これはSREを志望するエンジニアがSREから直接話が聞けた方がエンゲージ率が高いという仮説のもと、実証中です。

開発チームのスクラムマスター
1チームのスクラムマスターを担当しました。 目指した目標は「ベロシティの安定化」です。
新たなプロジェクトのためにスクラムチームが立ち上がった際に、VPoEの意向で「このチームでスクラムをしっかりとやりたい。マネジメントに興味のある私にスクラムマスターをやってみるのはどうか」と提案を受け担当しました。 アジャイルサムライ等の書籍を読み直し、そもそもスクラムとはを再学習し、そしてなぜスクラムをするのかをVPoEと再度認識合わせしました。 「直近5スプリントのベロシティのうち外れ値2つを除いた値がその平均値の±10%におさまっていること」を具体的な数値目標とし現在までに16スプリントが完了しました。結果は「-8%, +15%, -5%」となりました。1つだけ目標から外れた値となってしまったので、これの振り返りをチームで行うなどしました。 --- また16スプリントも実施したことで振り返りの手法にマンネリが見られ、KPTの付箋が少なくなってきました。そこでスプリント15からはFunDoneLearnに切り替えました。しかしメンバーからの評価は「あまり良い振り返りと感じない」という結果でした。というのもFunがほとんど出てこないからです。またメンバーからチームが成熟したことで課題が少なくなり、結果Problemが少なくなったという意見がありました。 個人的にはこの意見はかなり有益で、つまり目の前に見える範囲では課題が少なくなったところまで成長したと感じたからだと思っております。そこでスプリント17では改めて振り返りの意義を伝えつつ、メンバーに「視座を少し高くする」よう意識がけてみる予定です。 「Funが少ないということに対して、もしかして今の仕事は楽しくないのか?」や「ベロシティが右肩上がりなのはなぜなのか。POはこれを見てより多くの難易度のチケットが消化できると受け止めてよいのか」などを問いていきます。

このマネージメント能力は公開されていません

アピール項目


アウトプット

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

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

より精度の高い見積

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

適度に余裕(80%)があること。余裕があるといざと言う時に対応(120%)ができます。

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / プレゼン力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
金融 / 仮想通貨
その他の特徴
新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと

やりたい: QA/SETエンジニア
やりたくない: 労働力を人月として切り売りすること

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
SIGN UPSIGN IN


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