1. top
  2. Tomo
  3. 株式会社TOKIUMからの指名詳細

株式会社TOKIUMからの指名詳細

提示年収ウィザード級
正社員
株式会社TOKIUMの企業詳細を見る

指名日時：2023.03.30 11:38

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

    ### xxxxxx

    xxxxxxxxxxx**xxxxxxxxxxxxxxx**xxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxx。

    xxx、xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxx。xxxxxxxxxx、xxxxxxxxxxxxxx(xx)xxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxx(xxxx)xxxxxxxxxxxxx。

    xx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、**xxxxxxxxxx、xxxxxxxxx**xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    ---

    ### xxxxxxxxx

    xxxxxxxxxxx、xxxxxxxxxxxxxxxx。

    - xxxxxxxxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxx
    - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    xxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxx、xxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxx**xxxxxx(xxx x xxxxxxxx xxxxx xxxxxxxxxx)xxxxxxxx**xxxxxxxxxxxxxxxxx。xxx**xxxxxxxxxxxxxxxxxxxx**x、xxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxx。

    ---

    ### xxxxxxxxx

    xxxxx、xxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxx、xxxxxxxxxx(xx、xxxxxxxxxxxx)xxxxx、xxxxxxxxxxxxxxxxxxx。

    xxxxxxxxxxxxxxxxxxxxxxxxx、**xxxxxxxxxxxxx**xxxxxxxxxxxxxxxxx。xxx、xxxxxx**xxxxxxxxxxxxxxxxxx**xxx、xxxxxxx。

    xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxx。xxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxxxxx、xxxxxxxxxxxxx、xxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxx、**xxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxx**x、xxxxxxxxxxxx。

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

    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    xxxxxxxxxx xxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxx、xxxxx、xxxxxxxxxxxxxx、xxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xx、xxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxx、xxxxxxxxxxxxxxxx。xxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxx、**xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx**xxx、xxxxxxxxxxxxxxxxxxxxx

    文字数：668
    （※指名されたユーザー本人しか内容は閲覧できません）
  • 何を任せたいか

    xxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxx。

    xxxxxx、xxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。xxxx、xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。

    xxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxx

    ### xxxxxx(xxxxxxxxxx)

    - xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    　　- xxxxxxxxxxx
    　　- xxxxxxxxxx
    　　- xxxxxxxxxxxx
    　　- xxxxxxxx
    - xxx、xxxxxxxxxxxxxxxxx
    　　- xxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxx(xxxxxxxxx、xxxxxx)

    ### xxxxxx(xxxxxx)

    - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxx、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxx
    - xxxxxxxxxxxx
    - xxxxxxxxxxxx、xxxxxxxxxxxxxxxxxxx
    - xxxxxxxxxxxxxx
    - xxxxxxxxxxxxxxxx、xxxxxxxxxxxxxxxx
    - xxxxxxxxxx

    文字数：1121
    （※指名されたユーザー本人しか内容は閲覧できません）
  • 指名した人
    西平 基志
    取締役CTO 2012年、筑波大学3年次にCEO黒崎、CIO原澤とともにTOKIUMを創業。最高技術責任者に就任。
    TOKIUM経費精算や、データエントリーシステムの初期開発に従事。
    現在はプロダクト開発とデータエントリーに関わるオペレーションを統括しています。
    プロダクトづくりにおいては、表面的な問題解決ではなく真因を特定した上での本質的な解決、それによるカスタマーサクセスの実現を心がけています。
    企業理念である「時間革命で体感寿命を延ばす」事を実現するための組織作りに取り組んでいます。
  • 所属先候補
    チーム名
    開発部 / プロダクトグループ
    ミッション
    支出管理クラウド「TOKIUM」の開発におけるストリームアラインドチームとして、プロダクトが生み出す価値の最大化に直接的な成果をもたらす
    主要言語・フレームワークなど
    Ruby / TypeScript / Ruby on Rails / React.js
    その他技術
    PostgreSQLAWS
    チームの人数
    20人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • コードレビューしている
    • リファクタリングをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームで自動化できている項目
    • 開発環境構築
    • テスト
    • Lint等の静的解析
    • デプロイ
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    • コードのバージョン管理ツール
    • コードレビューツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://corp.tokium.jp/service/
    備考
    「経費精算」「インボイス」「電子帳簿保存」の3つのプロダクトの開発に1週間1スプリントのスクラム開発体制で取り組んでいます。 また、各プロダクトが基盤として利用する「システム共通」の領域を担うチームも存在します。
    チームメンバー
    西尾尚倫
    2022年3月にTOKIUMへ参画。
    実務未経験で入社し、BearTailXのWebエンジニアとして、フロントからインフラまでのシステムの開発・保守・運用を約3年務める。
    私は大学は商学部出身で、元々エンジニアを志していたわけではなく、子どもの頃からパソコン大好き少年だったというわけではありませんでした。
    なので、エンジニアにジョブチェンジしたいという方ととてもお話が合うと思います。
    関西人です
    チーム名
    開発部 / インボイスチーム
    ミッション
    TOKIUMインボイスの新規機能開発
    主要言語・フレームワークなど
    Ruby / TypeScript / Ruby on Rails / React.js
    その他技術
    PostgreSQLAWS
    チームの人数
    10人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • コードレビューしている
    • リファクタリングをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームで自動化できている項目
    • 開発環境構築
    • テスト
    • Lint等の静的解析
    • デプロイ
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    • コードのバージョン管理ツール
    • コードレビューツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://www.keihi.com/invoice/
    備考
    ビジネスサイドのメンバーもエンジニアへのリスペクトがある方が揃っており、個社対応も極力受けない体制を整えています。要件定義・詳細設計の工程ではエンジニアも積極的に発言し、意見をプロダクトに反映させることが可能です。 一方で、法律改正の影響を強く受けるプロダクトであり、また大企業のお客様からの引き合いが急増している背景も相まって、トップダウンかつタイトな期日での機能開発が現在でも年に数回発生します。
    チーム名
    開発部 / オペレーショングループ
    ミッション
    「オペレーター」と「システム」のかけ合わせによって生まれるアウトカムの最大化を実現し、支出管理クラウド「TOKIUM」のサービス価値を向上させる
    主要言語・フレームワークなど
    Ruby / JavaScript / Ruby on Rails / React.js
    その他技術
    PostgreSQLAWS
    チームの人数
    20人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    数ヶ月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • コードレビューしている
    • リファクタリングをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームで自動化できている項目
    • 開発環境構築
    • テスト
    • Lint等の静的解析
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    • コードのバージョン管理ツール
    • コードレビューツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://corp.tokium.jp/service/
    備考
    オペレーショングループでは、複数のスクラムチームがITと人力の組み合わせによって、独自の価値をお客様にもたらすシステムの開発・改修に取り組んでいます。例として、請求書・領収書の自動データ化機能を実現する「エントリーシステム」、データ化が必要な書類を送信しTOKIUM上に登録する「アップロードサイト」、様々な形式で送られる請求書の代行受領を実現する「メール受領・日付受領システム」などが挙げられます。
    チームメンバー
    小口 翔太
    2020年4月にTOKIUMへ参画。
    オペレーション基盤チームでRailsを中心とした開発とチームリーダ業を約4年務める。
    2024年6月よりオペレーショングループのEMとしてエンジニア組織づくりをメインにコミットしている。
    コードと向き合うロールから人と向き合うロールへ。
    五里霧中ですが邁進してまいります。
    TOKIUMの前はITと全く関係ない業種・職種にいたので、エンジニア一筋の方とは少し違う観点ができるかもしれません。     趣味はカメラ、旅行、ゲーム、ヘッドホンオーディオ。
    チーム名
    開発部 / プラットフォームグループ
    ミッション
    ストリームアラインドチームが開発に集中できるようにプラットフォームを提供し、組織全体のアジリティを高める
    主要言語・フレームワークなど
    Ruby / TypeScript / Ruby on Rails / React.js / PostgreSQL / AWS
    その他技術
    Python
    チームの人数
    20人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    数ヶ月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • コードレビューしている
    • リファクタリングをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームで自動化できている項目
    • 開発環境構築
    • テスト
    • Lint等の静的解析
    • デプロイ
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    • コードのバージョン管理ツール
    • コードレビューツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://corp.tokium.jp/service/
    備考
    SRE（Site Reliability Engineering）チーム・CRE（Customer Reliability Engineering）チームが属するグループです。
    チームメンバー
    橘高 俊
    立命館情報理工学部から大手SIerに就職。
    インフラ(物理)からミドルウェアまでの保守運用をしていました。     2017年4月からTOKIUMにジョイン。
    新規開発メンバー、パフォーマンス改善メンバーとして Web開発に従事。
    その後、基盤チームやCREチームの立ち上げとリーダー業務を経験したのち、
    EMを経て、開発部の部長として開発組織の課題解決に全力で挑んでいます。
    趣味はカフェ巡り。
    1か月に2回は表参道に行けないと蒸発します。     最近は趣味でC++を書いてますが、
    Rubyとは未だに仲良くなれていません。
    チーム名
    プロダクト部 / プロダクトマネジメントチーム
    ミッション
    企業活動で生まれる支出関連業務の効率化・最適化を「人とITの統合オペレーション」により実現し、お客様に豊かな時間・競争力をもたらすようプロダクトを成長させ、その価値提供に責任を持つ。 支出管理クラウド「TOKIUM」のお客様体験の適切なリサーチ、および営業部及びカスタマーサクセス部との認識のすり合わせによって見出された課題に対し、開発部とともに新機能や改善施策を企画することで、正確かつスピーディーにサービスをあるべき姿に導く。
    主要言語・フレームワークなど
    Ruby / TypeScript / Ruby on Rails / React.js / PostgreSQL / AWS ※開発部で利用
    その他技術
    NotionGoogle Sheets
    チームの人数
    10人以下
    エンジニアの人数比率
    10%以下
    飲み会の頻度
    月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://www.keihi.com/
    備考
    長期的なプロダクト戦略の立案を含む、プロダクトマネジメント業務全般をミッションとするプロダクト部配下のチームとなります。 プロダクト部にはQAチームも所属しており、要件定義の工程ではQAエンジニアも参加し、業務を進める体制となっています。
    チームメンバー
    石井 洋平
    千葉県出身。SIer→事業会社3社での社内SEを経て、前職でのTOKIUM経費精算の導入経験をきっかけに2022年1月からTOKIUMにお世話になってます。
    ジャズギター好きです。何もしないキャンプと司馬遼太郎も好き。
    チーム名
    開発部 / SRE (Site Reliability Engineering) チーム
    ミッション
    SREチームのミッションは、「プロダクトの成長における阻害要因を取り除くこと」です。 特にプロダクトに対する信頼性の向上をエンジニアリングによって実現し、事業の成長を運用面から支えることを目指します。
    主要言語・フレームワークなど
    Ruby / TypeScript / Ruby on Rails / React.js / PostgreSQL
    その他技術
    AWS
    チームの人数
    5人以下
    エンジニアの人数比率
    81%以上
    飲み会の頻度
    数ヶ月に1-2回程度
    このチームで恒常的に行われている開発文化
    • 仕様のレビューをしている
    • コードレビューしている
    • リファクタリングをしている
    • DevOpsをしている
    • 小さなことでも称賛している
    • 失敗が許容されている
    このチームで自動化できている項目
    • 開発環境構築
    • テスト
    • Lint等の静的解析
    • デプロイ
    このチームに導入し、運用されているツール
    • ビジネスチャット
    • タスク管理ツール
    • wiki等の情報共有ツール
    • デザイン共有ツール
    • プロトタイプ作成ツール
    • コードのバージョン管理ツール
    • コードレビューツール
    テストを書いているかどうか
    書く必要がない・または少ないプロダクトだ
    全く書けていない
    書く文化がまだ浸透しておらず、必要な分は書けていない
    書く文化は浸透しているが、まだ必要な分は書けていない
    必要な分は書けている
    ライブラリなどを更新しているかどうか
    定期的に更新する必要がない・または低いプロダクトだ
    ほとんど更新していない
    不定期だが更新している
    期間を決めて定期的に更新している
    期間を決めて定期的に自動で更新している
    チーム内のエンジニアの発言力
    エンジニアの意見が通りづらい
    どちらかといえばエンジニアの意見が通りづらい
    職種による差はない
    どちらかといえばエンジニアの意見が尊重されやすい
    エンジニアの意見が尊重されやすい
    スケジュール調整のしやすさ
    納期や仕様が優先されやすく、エンジニアの裁量では調整しづらい
    どちらかといえばエンジニアの裁量で調整しづらい
    どちらともいえない
    どちらかといえばエンジニアの裁量で調整しやすい
    納期や仕様をエンジニアの裁量で調整しやすい
    プロダクトの内容を決める人
    主にエンジニア以外が考えて決める
    どちらかといえばエンジニア以外が考えて決めることが多い
    どちらともいえない、または職種間の差はない
    どちらかといえばエンジニアが考えて決めることが多い
    主にエンジニアが考えて決める
    チーム内の職種間の協力体制
    各職種のリーダーへ話を通したり規則がある等で協力しづらい
    どちらかといえば協力しづらい
    どちらともいえない
    どちらかといえば協力しやすい
    職種間の風通しもよくいつでもカジュアルに相談しあえるなど協力しやすい
    チームの方針決定をする人
    会社が大まかな方針を考えており、ほぼトップダウンで決まる
    会社が大まかな方針を考えているが、チームも一定の範囲内で決定に関わる
    どちらともいえない
    チームが主体的に考えて決めるが、会社の方針に左右される面もある
    チームが主体的に考えて決めており、会社はあまり個々のプロダクト方針にかかわらない
    長期的価値の優先度
    短期的な売上を重視せざるを得ない状態である
    どちらかといえば短期的な売上が重視されている
    どちらともいえない
    どちらかといえば長期的なユーザ価値を重視できている
    長期的なユーザ価値が重視できている
    URL
    https://www.keihi.com/service/
    備考
    ビジネスサイドのメンバーもエンジニアへのリスペクトがある方が揃っており、個社対応も極力受けない体制を整えています。要件定義・詳細設計の工程ではエンジニアも積極的に発言し、意見をプロダクトに反映させることが可能です。 一方で、法律改正の影響を強く受けるプロダクトであり、また大企業のお客様からの引き合いが急増している背景も相まって、トップダウンかつタイトな期日での機能開発が現在でも年に数回発生します。
    チームメンバー
    西本 貴
    筑波大学情報学群卒業後、大手ゲーム会社でUnityを用いたWebブラウザゲームやスマホゲーム(いわゆるソシャゲ)の開発等に従事。 2018年TOKIUM参画。 TOKIUM経費精算の開発やTOKIUMインボイスの立ち上げをリード、その後開発部長を務めた後、プロダクト組織開発部の部長を務める。
    カープが大好きです。ここ数年秋に悔し涙を流しているので、いい加減嬉し涙を流したいです。

内訳を見るには？

提示年収に含まれる内訳
  • 基本給（月）
    表示されません
  • 裁量労働制か否かいいえ
  • 固定残業代（みなし含む）提示年収に含む
    時間外労働の有無に関わらず以下を時間外手当として支給
    固定残業時間/月
    40時間 / 月
    固定残業代/月
    表示されません
    固定残業代の詳細

    表示されません

    規定の「固定残業時間/月」を超える時間外労働分についての割増賃金は追加で支給
  • 理論賞与含まない
  • 手当額（年）含まない
  • その他待遇

    表示されません

その他の条件
  • 時間外労働有り
    時間外労働の備考
    表示されません
  • 試用期間有り
    3ヶ月
    試用期間の条件変更 有り
    試用期間の詳細
    表示されません
  • 就業場所

    東京都中央区銀座6丁目18−2 野村不動産 銀座ビル12F

  • 加入保険

    健康保険・厚生年金・雇用保険・労災保険

  • 休憩時間（分）

    60分

  • 休憩時間（備考）

    休憩時間の開始・終了に関しては、特に定めはありません

  • 休日

    完全週休２日

  • 就業時間フレックスタイム制
    コアタイム9時00分〜15時00分
  • 受動喫煙防止措置対策

    屋内禁煙

メッセージ
文字数：1593
（※指名されたユーザー本人しか内容は閲覧できません）
会社情報
株式会社TOKIUMの企業詳細を見る

© 2015 Livesense Inc.
SIGN UPSIGN IN
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか？
012345678910
回答するスコアの入力をお願いします
今回は答えない絶対に答えない