テックタッチ株式会社からの指名詳細

提示年収プチリッチ
正社員 裁量労働制

指名日時:2019.03.06 20:42

提示年収とは?
  • あなたのレジュメの内容から読み取った実力に対して、企業が判断した金額です。そのため、必ずしもこの金額と同額で内定となるわけではなく、面談等を経て上下することもあります。
  • 採用になった場合の実績としては、約50%が提示年収と同額、約25%が提示年収より高い金額、約25%が提示年収より低い金額(ただし90%ルールの範囲内)となっています。
  • 今抱えている課題

    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。
    xxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。
    xxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xx xxxxxxxx
    xxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxx。
    xx、xxxxxxxxx。xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xx xxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxx。
    xxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    文字数:538
    (※指名されたユーザー本人しか内容は閲覧できません)
  • 課題に基づいた指名理由

    xxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。
    xx、xxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。
    xxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxx。
    xxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxx。x

    xxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxxxxxx。

    文字数:480
    (※指名されたユーザー本人しか内容は閲覧できません)
  • 何を任せたいか

    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    文字数:85
    (※指名されたユーザー本人しか内容は閲覧できません)
  • 指名した人
    井無田仲
    代表取締役。
    ドイツ証券、新生銀行にて企業の資金調達/M&A助言業務に従事後、ユナイテッド株式会社で事業責任者、米国子会社代表などを歴任し大規模サービスの開発・グロースなどを手がける。
    慶應義塾大学法学部、コロンビア大学MBA卒。
    企業の産業競争力はITをいかに活用してくか、ということだと考えています。
    弊社テックタッチはこういった明確な企業の課題を解決できるプロダクトを作っているスタートアップです。詳細については競合観点で細かいところまではお伝えができないのは残念ですが、かなりこだわってユニークなものにしておりますのできっと気に入ってもらえると思います。
    どうぞ宜しくお願いします。
  • 所属先候補
    チーム名
    フロントエンド
    ミッション
    弊社サービスはBtoB向けの少しユニークなサービスになり、通常のSPAだけでなくChrome拡張も同時に公開しております。 プロダクトの内容がわかりにくという側面もありますが、お客様へのサービス理解を求めるには洗練されたUIを実現する必要があります。 もちろんBtoBのサービスにおいてもUXを追求しており、我々のサービスに触れる時のお客様の状況をイメージしてプロダクトを改善しております。 そんなサービスですので、フロントエンドチームが開発の中心となっており、全体のエンジニアの7割はフロントエンドエンジニアという構成になっています。 全社的に見ても最も割合の高い職種となります。フロントエンドに理解のあるチームとかではなく、完全に事業の中心となっているチームになります。 もちろん高い責任感と、同時にやりがいを感じていただけると思います。追求しているプロダクトのレベルも高いので、個ではなくチームでパフォーマンスを発揮していくことも重要になってきます。
    主要言語・フレームワークなど
    TypeScript vue.js Nuxt
    その他技術
    Vue.jsStylusGitHubESLintCircleCIVuexStorybookPuppeteer
    チームの人数
    10人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    月に1-2回程度
    このチームで恒常的に行われている開発文化
    このチームで自動化できている項目
    このチームに導入し、運用されているツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    チーム名
    バックエンド
    ミッション
    展開しているサービスの特性として、処理するトラフィック量が多く、またダウンや遅延も許されません。効率の良いコードを書くことも当然ながら、SPOFを避け可用性を確保しサービスの根幹を支えてきます。 現在はGolangをベースにマイクロサービスで運用しておりますが、新しい技術の取り込みには積極的で状況によってbaas含め最も有効な構成を選択していきます。 また、安定稼働大前提の中、開発効率化を追求し開発スピードを上げていく必要がありますので自動化にも積極的に取り組みます。 同時に大量ログからサービス改善に繋がる情報を探しだすこともバックエンドチームの役割となります。
    主要言語・フレームワークなど
    golang, gin, gorm, kong, aws
    その他技術
    PostgreSQLElasticsearchDockerAWSAWS CloudFormationDocker ComposeAmazon ECSAmazon ECRAmazon KinesisAmazon AuroraGo
    チームの人数
    5人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    週1-2回程度
    このチームで恒常的に行われている開発文化
    このチームで自動化できている項目
    このチームに導入し、運用されているツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている

内訳を見るには?

提示年収に含まれる内訳
  • 基本給(月)
    表示されません
  • 裁量労働制か否かはい
  • 固定残業代(みなし含む)含まない
  • 理論賞与含まない
  • 手当額(年)含まない
  • その他待遇

    表示されません

その他の条件
  • 時間外労働未入力
  • 試用期間未入力
    試用期間の条件変更 未入力
  • 就業場所

    東京都

  • 加入保険

    未入力

メッセージ
文字数:127
(※指名されたユーザー本人しか内容は閲覧できません)
会社情報
SIGN UPSIGN IN


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