この記事はニーリーアドベントカレンダー2024の11日目の記事です。 こんにちは。プロダクトマネージャー（以下、PdM）の阿部です。最近、社内のアドベントカレンダー（突撃！隣のキーボード！〜 2024年冬 ニーリー Ver. 〜 - Nealle Developer's Blog）に触発されて分割キーボードを購入しましたが、使いこなせず元のキーボードに戻ってしまいました😇 今年の1月に、一人目のPdMとしてニーリーに入社し、気がつけば1年が経とうとしています。この1年間の経験や感じたことを、本記事にまとめてみます。 はじめに ニーリーでは、「エンジニアが事業に染み出す」というキーワードが浸透しており、課題の抽出や企画も業務範囲として定義されています。 上記の図を見ると、「エンジニアがPdMの業務をカバーしているのでは？」「PdMって必要なの？」「役割分担はどうなっているの？」などの疑問を

Tebiki株式会社でデザインマネージャーをしている鮫島です。 私たちが提供しているデスクレスワーカーのための現場向けSaaS「tebiki現場教育」と「tebiki現場分析」は、作成、分析、共有といった異なるプロセスを一元化するために多機能化していきました。しかし、提供する高度な機能がユーザーにとって使いこなしにくいものでは意味がありません。ユーザーに求められるのは、これらの複雑な機能を直感的で「かんたん」に操作できることです。 「かんたん」であることは多くのデジタルプロダクトにとって重要な価値ですが、その感覚は主観的であり、プロダクトを提供する側が無策でユーザーにとっての「かんたん」を定義することは困難です。 この記事では、「かんたん」の本質を探り、ユーザーが直感的に操作できるプロダクトをどのように実現するかを弊社の事例と合わせてご紹介します。 「かんたん」の源泉「かんたん」と感じる（

こんにちは！株式会社ベースマキナで代表を務めておりますtimakinです！ 今回の記事では、以前当ブログでも告知した通りTSKaigi Kansai 2024にブース出展した経験を踏まえて、今後ブース出展をされる皆様への一助になればと思い準備や当日の手引きをまとめます。 なお、FindyさんのDevRelのまっきーさんが書いてくださった以下の記事も非常に参考になるので、是非ご覧ください。 note.com はじめに 技術カンファレンスのスポンサーでブース出展が決まった方、おめでとうございます！ ブースで当日参加者の方にお会いするのが楽しみだと思いますが、現実問題たくさんの準備が必要です。 まずは出展の目的整理から始めましょう。 出展の目的整理 ブース出展をする目的は皆様異なると思いますが、概ね以下のどちらかあるいは両方を目的にしたブランディングだと思います。 採用広報 営業広報 極端にどち

マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役

Tebiki株式会社でQAエンジニアとCREを担当している中西です。CREを導入し、半年以上が経過しました。 CREとして活動している私は、ユーザーからの問い合わせの早期解決という点で、開発チームやカスタマーサクセスチームに貢献できている感覚を持っています。私の感覚にギャップがあるかどうか、CREをもっと良くするために必要なことは何かを知るために、CREと協力することが多い職種の方々にインタビューを実施しました。 インタビューに協力して頂いた方々はこちらの方々です。 日笠 陽仁／テックリード テックリードとして、設計や実装の品質を支援。現在は、技術的負債の解消に先陣をきって取り組み中。調査の難易度が高い、もしくは緊急性が高い問い合わせ発生時には、CREと一緒に調査も行う。 中村 翔平／チームリーダー スクラムチームに足りない能力を見極めて補完できるようにプロダクトオーナー、プロダクトデザイ

システムプラットフォームチームで SRE をしている id:masayoshi です。 今年もISUCON14の開催が決定しましたね！ isucon.net ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCONは、世の中に実際にありそうなWebサービスを題材に、明確なボトルネックがあるコードかつ全体のコード量もすぐ読める量なので、パフォーマンスチューニングの練習にはもってこいです。 適切なパフォーマンスチューニングをするためには、まず計測してシステム上のどこにボトルネックが存在してパフォーマンスが悪化しているのかを把握する必要があります。 このように、どこで、何が起こり、パフォーマンス上の問題やエラーがおこっているのかを把握できる能力を Observabili

2024-10-05 YAPC::Hakodate 2024 https://yapcjapan.org/2024hakodate/

ミーティング中にうまく意見を言えないという相談を受けた。めちゃくちゃわかる。自分は開発関連のミーティングではそういう悩みは少なくなったけれど、経営関連のミーティングでは今でも歯がゆく悔しい思いをすることが多い。 相談された時にはうまく答えられなかったので、雑に自分がやっていることを書き出してみる。必要な役割としてミーティングに入っているというのを前提として、そもそものミーティングの必要性や参加者の要否についてはここでは対象外とする。 1. 事前に予習する 意見を言えないのは、その場で理解できなかったり考えがまとまらなかったりするから 事前にアジェンダが用意されていたら読み、関連ドキュメントがあればそれも目を通しておくなどできるかぎり事前準備をしておく わからないところや聞いておきたいことがあればコメントしたり頭出ししたりしておくとよい 2. 話を振ってもらう 意見を言えないのは、発言するタ

VPoEの湯前（@yunon_phys）です。3月にカケハシにジョインし、あっという間に4ヶ月。ゼロイチの事業立ち上げに寄与するエンジニアリングチームのマネージャとして、おかげさまで（本当に）楽しい日々を過ごすことができています。 今回は社内外の方々への自己紹介にかえて、エンジニアのキャリアや仕事観について、カケハシ入社前後に考えていたことをまとめてみることにしました。カケハシの技術組織を、どのような方向に成長させていきたいのか。自分自身のミッションにもつながる内容になると思います。エンジニアはもちろんですが、職種を問わずぜひいろいろな方にご一読いただけると嬉しいです。 カケハシの湯前としては、先日開催された日本CTO協会のイベントでもお話ししていますので、あわせてご覧ください。 技術や待遇、職場環境だけじゃない、もっと大事なことさて、「働きたくなる会社」についてです。組織マネジメントにお

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーのバックエンドはモノリスの Rails を中心に構成されています。そのモノリスな Rails に書かれていた YARD を rbs-inline に一通り移行した事例を紹介します。 前編では、rbs-inline の紹介と rbs-inline への移行理由について触れ、後編では実際の移行の流れや詰まったポイント、今後の展望について触れる予定です。 rbs-inline とは RBS 活用推進の背景 移行理由 1. YARD(sord) よりも rbs-inline の方が表現力が高い 2. YARD は書いていたが yardoc は使っていなかった 3. rbs-inline が今後言語標準の機能になっていく rbs-inline とは まずは rbs-inline について簡単に紹介します。

テスト管理ツール導入を検討するまでのテストケース管理 テスト管理ツールに必要な機能とは何か？を考えてみた テストのモニタリングとコントロール テスト実装 テスト実行 その他、プロセスを問わない機能 4つのテスト管理ツールを比較した TestRail PractiTest QualityForward Qase Qase に移行して特に良かったこと チケットとテストケースの連携がスムーズだった テスト自動化が進めやすくなった 問い合わせ用のチャットが使いやすい Qase 移行後の課題 バージョンごとの管理ができない キーワード検索でテストスイート名を抽出できない Shared Steps を使いこなせていない おわりに QA エンジニアの mikaty です。 最近、キャベツの芯に砂糖水をあげていたら花が咲きました。 テックタッチでは2023年7月からテスト管理ツールの Qase をスタート

Tebiki株式会社でQAエンジニアを担当している中西です。最近CREの活動も兼務しています。 QAエンジニアである私は、プロダクト開発のプロセス改善の一つとしてTebiki株式会社でCREの職種の導入を提案し、2024年1月から活動を開始しました。 今回の記事では、Tebiki社でCREの職種を立ち上げた経緯と、業務内容、そして今後取り組みたいことを紹介します。この記事を読んで、我々のCREに興味を持っていただければ幸いです。 CRE 立ち上げの背景CRE（Customer Reliability Engineering / Engineer）とはご存知の方も多いかと思いますが、CRE（Customer Reliability Engineering）という職種は、2016年にGoogleがGoogle Cloud Platform（パブリッククラウド）事業で発表した新しい専門職です。（

社内でよく「マネージャー忙しい問題」みたいなのが話題になる。これはマネージャーに時間がないことによって、xxx（チームによって異なる任意の領域、ヒューマンマネジメントとかを想像してください）が疎かになっているという問題意識から発していると思う。 忙しさを解決すること自体が無意味だとは思わないが、それによってxxxが向上することはおよそないと思う。なぜならその忙しいマネージャーがxxxをやってないのは、時間がないからではなくてxxxに対する能力と関心がないからだ。 仮に忙しさを解消するアクションを取ったところで、その人は自分の能力を発揮できて関心がある領域に空いた時間を投下するだろう。 人間がある仕事をやるかどうかは、関心>>能力>>>>>>>>>>>.....（もはやここに不等号がある意味すらない）>>>>>>>時間だと思う。 自分の時間に対して裁量があるなら、どんなに忙しくても関心のある

Tebiki株式会社 取締役CTO 渋谷 和暁 神戸大学法学部卒業後、SIerを経てWebシステムの開発会社に入社。ECなどの受託開発やゲームアプリ開発のリードとして従事した後、コーチ・ユナイテッドに転職。クックパッドによる吸収合併のタイミングでCEO貴山氏とともにTebiki社を起業し、取締役CTOを務める。 GitHub Medium アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。 かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社

はじめまして、2023年の12月にWebアプリケーションエンジニアとして入社した鈴木です。 主な仕事は tebiki現場分析 のアプリケーション開発で、 Product Engineer として幅広い業務に携わっています。 早いもので、自分が入社してから半年が過ぎました。 SaaS企業でエンジニアとして働くことが初めてである自分にとって、この半年は多くの学びがあり、とても充実したものであったと感じています。 当記事では、そんな学びの中から一つを「エンジニアにとってのカスタマーサクセス」というテーマで紹介させていただきます。 ※ 当記事では、カスタマーサクセス(以下、CS)を「顧客が成功する（成果を出す）ことを能動的にサポートすること」とします。 職業としてCSをされている方のことはCS担当者と表記します。 エンジニアにとってのCSとは現時点での自分は、以下のように考えています。 自身の影響

公式の説明による大きな変化点は、 Graviton 2 → 3 の時は、性能25％UP で費用6％UP、Network/EBS 帯域幅が向上、 Graviton 3 → 4 では、性能30%UP で費用10％UP、最大スペックが３倍、 に加えて、細かいところでも色々少しずつ向上しているという感じです。 特にスペック３倍は、データベース用途におけるスケールアップが強力で、一時的な緊急負荷対策としても強いし、クラスタデータを３分割するくらいなら１クラスタで分割なしで貫けばいいじゃない、など安定と選択の幅が広がるのは間違いないでしょう。 ベンチマーク それでは、疑り深い外道父さんによる、いつもの Phoronix による検証です。 今回は R系 という点と、あまり古いのと混ぜると共通成功テスト数が減ってしまうことから、R6g, R7g, R8g での比較としています。C7i 以前なども知りたけれ

Zed on Linux is here!To install Zed on most Linux distributions, run the shell script below.

スライド概要 2024/7/11開催のEmbedded SRE 現場に寄り添うアプローチで話したスライドです。 https://findy.connpass.com/event/323099/

こんにちは、スマートバンクでアプリエンジニアをしているロクネムです。 家計簿プリペイドカードアプリ「B/43」のiOS, Androidアプリの開発に携わっています。 最近弊社では、ある日のリリースをきっかけにB/43の主要なKPIの一つであるカード発行率が下がるという出来事がありました。 KPIを毎日自動で投稿してくれる #kpi チャンネルのある日の様子 最終的には、原因を特定して解決策を講じ、発覚から1ヶ月も経たずに数値悪化を元の水準に戻すことができました。 本記事では、我々がどのように分析を進めて仮説を立て、原因を特定して解決するにまで至ったのか、そのプロセスについてお話しします。 🤝 この分析の取り組みはPMのmoret san、バックエンドエンジニアのhirotea san、アプリエンジニアの自分 (rockname) の3人で行ったものです。 分析プロセス 0. 現状を正し

ソフトウェアエンジニアは、どのように事業に貢献すべきか？ 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ（当時）に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す