こんにちは。現場教育システムtebikiの鮫島です。プロダクト開発や、デザイナーが活躍できるデザイン組織作りに携わっています。 tebikiデザインチームは、エンジニアチームが既に実施しているノンソロ開発に触発され「ペアデザイン作業の1日平均を4hにする」をOKRのKey Resultの1つに掲げ、ペアデザインを実践しています。 この記事では、チーム一丸となって取り組んでいるペアデザインについてご紹介します。 ノンソロ開発すごいらしいよtebikiのEnabling Teamに加入した三宅により、9月から本格的なスクラム開発が導入され、プロダクト開発に大きな変化がありました。 その一つに、エンジニアチームが実践していたノンソロ開発の取り組みによる成果が共有されました。 これまでのPRからリリースまでの時間が大幅に減っている😲これに衝撃を受け、感覚として肯定していたペアデザインをデザインチ

あなたがやった仕事、不良在庫になっていませんか？ Tebiki株式会社では「知的在庫をできるだけ持たない」という考えのもとに、現場DX の SaaS「tebiki」を開発しています。この記事では、Tebiki社の考える知的在庫とは何か、そしてそれを持たなくて済むようにするためにどのような取り組みをしているかをご紹介します。 在庫とは在庫と聞くと何を想像するでしょうか？ 靴屋の在庫一掃セール？ 倉庫での棚卸し作業？ 経営者の方にとっては、キャッシュフローの悩みのタネかもしれません。 この記事では、在庫を「将来利益へと変換されるビジネスのネタ」と定義します。 どのようなビジネスでも、資金によって在庫を獲得し、それを使って利益を生み出すからです。 在庫商品を売って利益を得るソフトウェア開発における在庫靴屋などの小売店が商品である靴を在庫として抱えるように、ソフトウェア開発でも在庫は存在します。

弊社では、部門内／他部門とのチームビルディングを目的とした懇親会を経費で負担する「なかよしごはん」という制度があります。 今回の記事では、この補助制度の意図と目的、問題点、事前申請ナシにしている理由などを解説します。 貴山敬 @tkiyama なかよしごはん制度が生まれたきっかけ1年で社員数が3倍になるような環境だと、社員がお互いのことをよく知るのはとても大事で、事業成長や離職率にダイレクトに影響します。 お互いのことをよく知る手段の一つが懇親会なのですが、代表の私がイベント苦手ということもあり、会社主催の懇親会はあまりやってませんでした。加えて、弊社のバリューのひとつ、「自分で考え自分で動く」という方針を貫いてきた結果、よくいえばプロフェッショナル、わるくいえば他の人に関心がないという冷たい職場になってきてる感覚がありました。 砂漠みたいな乾燥した会社になる前に緑化しないとまずいなーと思

こんにちは！Tebikiの金井です。 セールス担当として入社して４ヶ月が経ちました。業務にも慣れてきたので入社エントリーを書かせていただきます。 IT系スタートアップ企業が苦手な方、なんとなく今の自分に満足できていない方、今の会社の居心地が良いが将来のビジョンが見えない方、今時点で転職に踏み切る理由がない方に読んでいただけたら嬉しいです。（なぜなら私がそうだったので） こんな感じの流れです▼ 自己紹介埼玉県出身。双子の兄。趣味はゴルフ、キャンプ。仕事とプライベートにメリハリをつけるタイプ。将来結婚したら家庭を大切にすること間違いなし。独身30歳です。脂のってます。 Tebikiゴルフ部、部員募集中です！飲食店を駆け回った大学時代～NewStage～大学時代は株式会社NewStageという飲食店専門の派遣会社でアルバイトをしていました。 様々な業態の飲食店へ派遣されるため、3年間で30店舗以

スタートアップの総務・経理・労務・人事、究極のなんでも屋。SaaSのコーポレートメンバーが対談してみた。 歳も違えば経歴もまるで違う二人がSaaS企業未経験からどうしてTebikiに入社したのか。そして今現在感じていること、これから何をしていきたいかについて赤裸々に話してみました！ プロフィール左：熊谷   右：清田▼熊谷年齢：1984年生まれ 出身地：宮城県の田舎出身。周りは田畑。実家のササニシキとひとめぼれで育った。 経歴：イベント会社でバックオフィス約9年、それ以前はIT企業でインフラ周り約3年。 入社時期：2021年1月 趣味：バイクツーリング。スピード走行よりも景色を見ながらトコトコ走ることが好き。田舎道とか大好物。 特徴：4人姉妹の長女。その反動なのか女性っぽいものには興味ない。スカートとか履かない。(履けないわけではない) ▼清田年齢：1994年生まれ 出身地：東京の下町生ま

tebikiでマーケターしているたらさわです。tebikiに2020年12月にTebikiに入社してから、1年半マーケティングをしています。今日はTebiki入社の経緯や、入社してから今までの業務などについて話したいと思います。自分の経歴など隠さず書いていますので、最後まで読んでもらえると嬉しいです。 アメリカ　コロナ　アジア人「なんかジロジロ周りに見られている気がする」 「マスクすると余計に見られている気がする」 「もうここに来るのはやめよう」 アメリカに移住してから初めて感じた疎外感。 家から徒歩で行けるスーパーで感じた白人の冷たい視線。次からはアジア人がよく行くスーパーに行くようになった。閉鎖される学校、リモートで始まる授業で人との繋がりがなくなり、「帰国」という文字が初めて浮かんだ瞬間でした。疎外感だけでなく、渡米するまで10年以上金融業界で働いてきたが、仕事から離れてみると、働き

Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！ この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！ Tebiki社のDiscussionsとは？Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus

これは、フィヨルドブートキャンプ Advent Calendar 2021（Part 1） 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR（プルリクエスト）を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方まず、タスクを分解して TODO リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ

Tebiki 社の CTO をしている渋谷です（会社名が変わりました）。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「スタートアップでも AeyeScan を使えば、継続的に脆弱性を診断できるようになるよ」という話について書いてみたいと思います。 （※近年特に注目されている SaaS などの Web アプリケーションに対する脆弱性診断の話です） スタートアップでもセキュリティは最重要スタートアップではとにかくサービスの PMF を目指すことを優先すべきで多少の脆弱性は後でどうにかすればよい、という意見をたまに見かけます。BtoB 向けの SaaS スタートアップを3年間やってきた一人としては、それは全くの嘘で、やはりセキュリティが最も重要だと考えています。 なぜなら「情報漏えいは会社の倒産リスクに直結する」からです。 仮に脆弱性を突かれて情報が

Tebiki社の熊谷です。 35歳でベンチャー企業への転職を決意。36歳の2021年1月にコーポレート部門の社員としてTebiki社に入社し早8ヶ月。総務、経理、採用、広報など様々な業務をしながら、会社の急成長を実感する毎日です。 その中で今回は、Tebikiでの広報活動をご紹介したいと思います。 広報活動への挑戦 前職までは広報とは関係ない仕事をしてきましたが、ここTebiki社では手を挙げた人が部署の括り関係なく仕事を任せてもらえます。「新しいことに挑戦しよう！」と意気込んでやってみましたが、何から手を付けていいのかわからないところからスタートしました。とはいえ、総務と経理を兼務している状態で、どうやって、なるべく時間を割かずに広報活動ができるかが前提にあり、課題と不安での挑戦でした。 広報活動の手本は存在しない？始める前に広報活動のノウハウ本を読んでみましたが、大手企業の話ですでに広

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ