LINEを支えるプロジェクトマネジメント＆アジャイルの専門家組織「Effective Team and Delivery室」の取り組みと戦略 Project Management & Agile全社横断組織の戦略と事例 #1/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Project Management & Agile全社横断組織の戦略と事例」に登壇したのはLINE Effective Team and Delivery室 室

君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先

本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

EOF2019と登壇の経緯 こんにちは、Delivery Management Team の Tanigawa です。 2019年10月31日、渋谷がハロウィンムードに包まれている中、私は浅草橋にて EOF2019 というカンファレンスでLINEにおける組織/チームマネジメントに関する取り組みを紹介してきました。 本カンファレンスは今回 EOF2019実行委員会によって初めて開催され、様々な企業で日々奮闘するエンジニアリングマネージャーやプロジェクトマネージャーが自身の経験やチャレンジ、失敗などをオープンに共有しあうという目的で開催されました。詳しくはイベントページを参照してみてください。 LINEは11月に開催した LINE Developer Day 2019 の宣伝も兼ねて、ゴールドスポンサーとしてこのイベントに協賛させていただきました。 このカンファレンスで私から共有したのは、LI

アラサーにもなると、会社勤めの友人たちは、ぼちぼち後輩を指導する立場に就きはじめる。 他人に教えることのむずかしさは承知しているつもりだから、苦労もあるだろう。 そこでよく聞くのが、「どうやって後輩をやる気にさせればいいのかわからない」という悩みだ。 「もっとちゃんとやれよ」と言えばいいものでもないし、「すごいねぇ」と褒めちぎるのもどうなんだろう。 でもなんだか、やる気とか熱意が伝わってこないんだよなぁ。 とまぁ、こんな感じである。 同じ悩みを抱えている人は、古今東西山のようにいるだろう。 だから、「いかに部下やチームメイトのやる気を引き出すか」という本や記事がたくさんあるのだ。 わたしも気になってそういうものにはよく目を通すのだが、たいていの場合、わたしが一番大事だと思う要素が抜けている。 それは、「その人の役割を用意し、任せ、認めること」だ。 「お前はなにもしなくていいよ」と言われてク

はじめに カックさん（@kakakakakku）のブログメンタリングのメンティとなってから 1 ヶ月半が経過しました。 ブログメンタリングの最長期間は 3 ヶ月なので、今日でちょうど折返しとなります。 そこで今回は前半戦の振り返りと、後半戦に向けた意気込みのようなものをまとめておきたいと思います。8 割くらいは自分の備忘録として残すことが目的です。 ちなみにカックさんのメンタリングはめちゃ素晴らしい！でも詳細はメンタリング終了時に書く予定なので、今回はほぼ触れません。 前半戦の振り返り この記事を書いている時点では、以下のようなフローでブログ記事の投稿に取り組んでいます。 1. 書きたいテーマを思いついたらブログ用の Trello にタスクを切る ブログ用カンバン（執筆予定のタイトルにはモザイクかけてます） 上記の画像の様な感じで、大玉・中玉・小玉にわけて記事のアイデアをとりあえず起票しま

プロダクトマネージャーカンファレンス2019にて、かの名著「Inspired」の著者Marty Caganさんの上記のキーノートの内容をリアルタイムでメモしたものを私の視点でまとめたものです。 現場をリードするUXデザイナーにも非常に役立つお話だと感じ公開してみました。多少の聞き漏らし・解釈違いはご容赦くださいm(_ _)m プロダクトマネージャーと企業のリーダーシッププロダクトマネージャーとは 課題を解決する気概を持ち 普通の人が普通じゃないことを成すことであるPRODUCT DISCOVERY「デザイナー、エンジニアと一緒に解決する」 お客さまのためのソリューションを提供するのが目的です。 そのためにはプロトタイプをたくさん作る必要があります。 = PRODUCT DISCOVERY なぜプロトタイプするか？４つのリスクを避けるため ・社会にある課題を解決するか？ ・お客様が使いたいと

それぞれの現場の「正しいものを正しくつくる」 登壇資料です。

昨日は熱が出たので、会社休んでRebuild.fmでも紹介されていた「バーチャルのじゃロリ狐娘YouTuberおじさん」の動画を見てました。 こういうのはあんまり長く覚えておいても得はしなそうなので、早めにブログに書いて忘れてしまおう。 というわけで、現在は通用しない古くなった考えを捨てる、「アンラーニング（学習棄却）」のお話なのじゃー。 [アンラーニングとの出会い] おそらく自分がまともにこの言葉を認識したのはこの本を読んでいた時だと思う。 はじめてのリーダーのための 実践! フィードバック 作者: 中原淳 出版社/メーカー: PHP研究所 発売日: 2017/10/19 メディア: 単行本（ソフトカバー） この商品を含むブログ (1件) を見る 中途入社の部下が成果を出せていないような場合のフィードバック手法の一つとして、アンラーニングが紹介されている。 過去に学んだやり方で、しかし現

"Unlearn"という言葉は、どれだけの人にとって馴染みのあるものだろうか。 僕はこの言葉に、学生時代に出会っている。教育学系の大学院にいたので、自分自身の研究テーマとは離れているものの、「学び」とは何かというような議論にも接することがあった。その中で、「Unlearn=学びほぐし」という言葉遣いがなされていたことを記憶していた。 今年になってから、この言葉に複数回接することがあり、少しこのUnlearnについて調べてみた。この記事では、この辺りの経緯と途中経過としてまとめておく。問題意識に導かれることも、学術的に網羅性を考慮して調査をしたわけではないので、あくまで覚書である。 日本のアジャイルの文脈でのUnlearnとの再会 野中郁次郎と竹内弘高におけるUnlearn 鶴見俊輔の「まなびほぐし」 一般的な英単語としてのUnlearn 終わりに 参考文献 日本のアジャイルの文脈でのUnl

気持ちを動かされたDevLOVE X初参加のDevLOVE。 どうやら、DevLOVEという開発を愛するエンジニアのコミュニティがあるらしい。存在は知っていましたが、今回が初めてのDevLOVE参加でした。特に予定のない雨の週末だし遊びに行ってみようと、当日の朝に申し込むくらい気軽に参加したDevLOVE X。まさか、こんなにも心を動かされ、行動を起こすことになるとは想像もしていませんでした。 会場に１歩入った瞬間から、このイベントは他の会とは違うと感じました。 私はよくTech系の勉強会に参加するのですが、技術に強いことが求められ、どこか刺々しい空気を感じることがありました。なんとなく背伸びしないといけないような…そんな雰囲気。 DevLOVE は打って変わり、開発を愛するもの同士で支え合うアットホームさがありました。等身大のままで良い。一人ひとりが考えたをしっかりと言葉にして、交わし合

Agile/Scrum へ取り組むことで、プランナー・エンジニア間の課題が解消し協調的に取り組めるようになり、チームがより自律的に動けるように成長していくお話 https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/8175/scrum

参加した研修 認定スクラムプロダクトオーナー研修 by James Coplien 参加目的 POをやるやらないに関係なく、 何を考えているのか知って、視座を切り替えられるようにするため。 やれる人がいなくなった時に、いないから何も出来ないではなくやれるようにしておくため POって何を背負っているのか ROI(ここでは価値)を最大化すること 大事なことは、「価値を何と置くか」 プロダクトによって儲けだけが価値ではない場合があるため 背負ったものを実現するためにやっていることは ビジョンを創り伝える 価値を届けるためのプロダクトバックログの優先順を決める その価値あるプロダクトを形にできるようにチームに伝える 予算やスケジュールやリスクも管理する それぞれの細かいプラクティス 今回は書くといっぱいになるので書かない 改めて心に残った話 チームのコミットメントを甘く見てはいけないよね チームは

日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ

4月28日に奥熊野いだ天ウルトラマラソンの100kmの部に参加し完走しました。天候にも恵まれ、ベストコンディションで走ることが出来ました。 奥熊野いだ天ウルトラマラソン – 神に見送られ仏に迎えられるウルトラマラソンへようこそ 100kmを走っていると色々なことについて考える時間があります。ブログネタについても考えていると、ウルトラマラソンはアジャイル、スクラムに関連することに気づき、記事にすることにしました。 ウルトラマラソン と スクラム 計画に従うことよりも変化への対応を 奥熊野いだ天ウルトラマラソンの制限時間は14時間40分です。この時間内に100kmを完走する必要があり、完走できるように計画を立てます。計画は練習時のペースや過去大会の経験(ベロシティ)から10km単位(スプリント)で通過できるタイム(ストーリポイント)を計算します。 しかし実際に走り始めると計画と実績で差が出てき

## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ

4/5（金）にUX DAYS TOKYO 2019のカンファレンスに参加してきました。本イベントは、海外の一流のスピーカーがUXをテーマとした講演やワークショップを行う、年１回のイベントです。 というわけで、個人的に面白かった２つの講演をざっとレポートします。 ※まるで自分の主張のように書いてますが、講演内容を要約しただけですのであしからず。 2019.uxdaystokyo.com 継続的ユーザーオンボーディング by Krystal Higgins Googleの「シニアユーザーエクスペリエンスデザイナー」の肩書を持つKrystal Higgins氏より、サービスにおけるユーザーオンボーディングのゴールとプロセスについての講演です。 ３行でまとめると… ユーザーオンボーディングは"first run"を支援するものではなく、長期間にわたって定着してもらうための取り組みである カスタマー

昨年の年末にアメリカに移住して、今はシアトルの近くの Kirkland というところに住んでいる。大体三か月たって、いろんなことを体験した。移住した理由は単純で、コンピューターサイエンスの世界ではアメリカがどう考えても一番進んでいるので、そこで修行して通用するようになったら楽しいかなと思ったからだ。他にも他国の人を観察しているととても生産性が高い。特にアメリカの人は生産性が高い傾向が高い。なんでこんなにアメリカはコンピューターの世界が向いているのだろう？その一旦を感じた気がしたので久々にこのブログを書いてみることにした。 Kirklandの風景 自分へのご褒美を買う アメリカに移住すると、当然日本にいる友達とかと会えなくなる。私は一人でもさみしくない人だけど、さすがにこたえるだろうと思った。だから大好きなバンドをまたやろうと思った。ただ、こっちは正直レベル高いし、私はヴォーカリストだから、