【Team & Project】LINE全社のデータ基盤のミドルウェアやData ingestion pipelineの開発・運用を担当しているチームを紹介します
―― 今のチーム課題と課題解決に向けた取り組みを教えてください。 Wang：私たちのチームでは、主に3つの課題について取り組みを進めています。 まずは1つ目の課題は「マルチテナントのクラスターの運用」についてです。 Hadoopは一般的に、有数のユーザと予測可能なワークロードで運用されていますが、LINEのData OpenによってDAUが700人弱であり、且つワークロードも10万+/日となっています。Isolationがまだ完備されていないので、ユーザ間にリソースの競合が発生している状況です。 2つ目は「Data catalog」についてです。ユーザが自由にデータを生成したり利用したりする環境においては、データのカタログがとても重要です。そのため、Data Lineageを自動的に生成する仕組みが必要となってきます。 そして「大規模のインフラを効率よく運用すること」も私たちの課題です。私
【Team & Project】LINEのユーザ向けサービスのWebフロントエンドを開発しているチームを紹介します
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。 今回は、フロントエンド開発組織の中で、ユーザ向けサービスのWebフロントエンドを担当しているチームについて紹介します。フロントエンド開発センターの清水大輔、縣亮太、折原レオナルド賢に話を聞きました。 ユーザ向けサービスのWebフロントエンドを担当しているチームのzoom会議の様子 ―― まず、自己紹介をお願いします。 清水：システム開発会社で図書館システムや金融・物流の開発などを担当した後、2009年5月にネイバージャパン（現LINE）にフロントエ
『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ
デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。 2時間スプリント？ みなさん、すでにスクラムで開発してますよね！ ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。 2時間スプリントとは、その期間を2時間にするという話です。 スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。 kyon-mm.hatenablog.com 2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうち
プロダクトの成功に必要な 3 つのステージと 20 のタスクについて：現場の動き方をまとめました｜Fritz | Lead Product Manager @ Mercari
こんにちは、フリッツ です。プロダクトマネージャー（以下 PM）になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました（ありがたい）。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、（自分の今までの）現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し～数年目の PM の方のお役に立てる記事になっていれ
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
在宅でチームの働き方改革！！ - SEGA TECH Blog
ごあいさつ 初めまして、株式会社セガ開発技術部の廣島です。 今回のBlogでは新型コロナウィルスの感染拡大防止のために弊社で実施されたリモートワークに関して、私達のチームで起きた問題やその問題に対してどう対応したのかを紹介します。 リモートワークをしてみて、私たちのチームに発生した問題は、コミュニケーションが上手くいかず、チームとしての機能が低下していくことでした。 そして、その原因は距離でした。 チームの間に物理的な距離ができてしまったことで、雑談のような気軽なコミュニケーションが減り、心の距離までもが遠くなってしまったのです。そしてこれまで何事もなく回っていたチームの歯車が、少しずつ噛み合わなくなっていきました。 しかし、リモートワークなので当然、物理的な距離を近づけることはできません。 どうすれば良いのか？何をすればこれまでと同じように上手くチームが回るのか？ そういった試行錯誤をし
Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 プロジェクト管理ツール、コラボレーションツールとしてBacklogを採用しているチームは多いでしょう。多岐にわたる機能を利用できるツールですが、上手に使うためのアイデアと方法を、Backlogを生み出したヌーラボ社の中村知成さんが解説します。開発チーム内だけでなく、マーケやセールスなどを含めた、チームを横断した課題管理など、“中の人”ならではの知見をご紹介します。 株式会社ヌーラボの中村知成（ @ikikko ）です。Backlogの開発・運用全般のマネージャーを務めつつ、Backlogの導入・業務改善や、ソフトウェア開発現場の支援サービ
2年半のエンジニアリングマネジャー経験から学んだこと - valid,invalid
2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
フロントエンドの開発体験向上と脱レガシー - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームは、プロダクトのフロントエンドを横断的に支援するチームです。今回はフロントエンドエキスパートチームが行っている、プロダクトへの支援活動について紹介します。 フロントエンドエキスパートチームがどういったチームかに関しては、次の記事をご覧ください。 サイボウズのフロントエンドエキスパートチームの紹介 フロントエンドエキスパートチームの活動 サイボウズは主力プロダクトとしてGaroonとkintoneを提供しています。この 2 つのプロダクトはそれぞれ提供開始の時期が 2002 年と 2011 年となっており、浅くない歴史を持っています。 サイボウズの Web フロントエンドは、フロントエンド専任ではないエンジニアがバックエンドと合わせて担当しています。そうした背景もあり、フロン
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
エンジニアと立ち話。Vol.25 @hamakn（メルペイBackendエンジニア）ちょっとお話いいですか？ | mercan (メルカン)
エンジニアと立ち話。Vol.25 @hamakn（メルペイBackendエンジニア）ちょっとお話いいですか？ メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第25回では、メルペイのバックエンドエンジニアでテックリード（以下、TL）の@hamaknにちょこっと話を聞きました。聞き手はメルペイのVP of Engineeringである@hidekです。 メルペイのダッシュボードチームで、銀行接続・NFC・コード払い・クーポンなどの各機能を加盟店さまに提供するAPI開発をTLとして担当する@hamakn。そんな@hamaknを、@hidekは「TLとして期待される役割を体現しているメンバーの一人」と話します。その理由は？ お客さまが最も触れるメルペイ管理画面の開発を担当 @hidek：（@hamaknさん、まだかな……？） @hamakn：hidekさーん！ 「エン
うちのチームのプログラマーはなぜテストがうまいのか - CAT GETTING OUT OF A BAG
うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。— miwa (@miwa719) 2019年6月24日 医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。 うちのチームのプログラマーはなぜテスト
異動のおともにスキルマップ - スタディサプリ Product Team Blog
こんにちは、Web Engineer の @wozaki です。 今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。 スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。 スキルマップの例 引用 スキルマップ作成のすすめ | Ryuzee.com 目次 概要 スキルマップ導入の背景 他社の事例とカスタマイズした点 スキルマップ詳細と運用方針 運用結果 まとめ 概要 チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった 個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した 結果 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった 個人の志向性は、スキル伝承時の期待値調整にも
サービス開発初期の「時間を金で買う」技術
ウェブサービスをゼロから開発して徐々に規模を大きくしていく過程では、CI環境の準備などサービス開発を続けていく上で開発チーム自身が準備をしなくてはいけないツール群が多くあります。これらの問題は多くのチームで共通にみられることから、世の中には様々なSaaSツールが用意されています。優れたサービスはそれなりの価格設定がされているものですが、場合によっては有料サービスを利用することにより、チームがサービス開発に集中できる時間を増やすという戦略も取ることができます。この発表では、私自身が仕事やプライベートで使っている開発支援系のツールに関する紹介と導入する場合の考え方や検討事項などについてお話します。
デンソーのアジャイル開発チームができるまで チームビルディングにおける工夫と実装の裏側 | ニュース | DENSO - 株式会社デンソー / Crafting the Core /
翔泳社主催のソフトウェア開発者向けITカンファレンス「Developers Summit 2019」が2月14日～15日に開催されました。セッション「デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～ 」に登壇したのは、当社MaaS開発部デジタルイノベーション室の佐藤義永と冨田進。昨年のDevelopers Summitで発表した内容をベースに、この1年で実際にサービスをリリースするまでの知見やアジャイル開発・チームビルディングについて語りました。 佐藤義永（以下、佐藤）：ご紹介ありがとうございます。デンソーの佐藤と冨田です。今日は「デンソーのMaaS開発が具体的にどんなことをやっているのか？」ということをご紹介できればと思っています。 はじめに、去年のデブサミでもおうかがいしましたが、デンソーという会社を「知ってますよ」という人、どれぐらいいますか？ （
エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと - Qiita
LITALICO CTOの岸田崇志(@takish)です。 2017年のアドベントカレンダーもついに最終日となりました。 入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。 特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。 はじめに 筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。 一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。 そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。 成長フェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだこと
