Ques #14で「顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み」を話してきました
はじめに
QA界隈のエンジニアが集まる老舗イベントQues #14で登壇する機会をいただき話してきました。「Agile Testの今」というお題に対し、「アジャイルな開発」を実現するためのRettyにおける文化の変革について事例を交えて紹介しています。素敵なオフィスでの満員の会場に、事前のインタビューでの集客と、Quesの運営スタッフの皆様には大変感謝しております。
Twitterのハッシュタグ付き投稿をみるにそれなりに参考になる発表ができたのではないかと思います。以下、いただいたコメントについて簡単にフォローします。
Twitterでいただいたコメント
口コミサイトのテスト観点とか考えるの面白そう #ques14
— ミジンコおじさん (@koppamijinko) November 15, 2019
投稿内容のチェック、ハッシュタグなどの解析、表示する順番などなど面白要素がたくさんあると思います。
#Retty #ques14
— たなかまる (@tanakamarudayo) November 15, 2019
Retty創業9周年おめでとう!
知人が新宿で合コンをしたいそうですがどこがおすすめですか?
こちらをどうぞ → 【2019年最新!】新宿の合コンで今年人気のおすすめ30店 - Rettyまとめ
RettyにはQA専門の人がいないとのこと。定期的に感じる、テストエンジニアいらない可能性。どうするテストエンジニア。 #ques14
— しろうま (@siro_uma) November 15, 2019
QAは無くならないし、弊社もQA見てくれる人がいるなら大変心強いです。 QA組織が必要(そしてリリースのブロッカーとなっている)、テスト自動化だけをやるエンジニアがいる、手動テストだけをやるエンジニアがいる・・・というのはだんだん変わっていくかもしれませんが。
優先順位が低いものをどう扱っているか気になる
— カルバート (@trickmrbiz) November 15, 2019
#ques14
プロダクトオーナーの判断に委ねています。重要度と優先度を元に考えることが多いと思いますが、最後は誰かが決めないといけないので。
重要なものをどう決めるか/良かったか良くなかったかどう判断するか /ABテストとかで勝ち負け決めてる?もしそうならパターンでテストしてるの期間でテストしてるのか #ques14
— Fumikazu Fujiwara (@freddiefujiwara) November 15, 2019
ABテストは結構やっています。
「AgileをやろうとするがWFになる」は分かるが、「ScrumをやろうとするがWFになる」は分からないなぁ…#ques14
— broccoli (@nihonbuson) November 15, 2019
名前を付け替えてスクラムイベントを形式的に取り入れるとわりかしありますよ。 - 責任者→プロダクトオーナー - プロジェクトマネージャー→スクラムマスター - 進捗定例→スプリントレビュー
xUnitとかもない状態なのかな あればコードをいじるのも怖くないかも #ques14
— Fumikazu Fujiwara (@freddiefujiwara) November 15, 2019
xUnit系テストは十分にないです。あればもっと改善早く進むのですが。
Rettyは、
— てすと三郎 (@test_toki36) November 15, 2019
php(未経験の創業者)で作ったコードで動いてる。
→レガシーとなってる原因みたい。
でも、1度も捨てたことないってさ!
秘伝のコード
#ques14
創業者が書いたコードの大半は書き直されていると思いますが、どこかに残っていると思います。
システム思考楽しそう。 #ques14
— ミジンコおじさん (@koppamijinko) November 15, 2019
システム思考はこのブログも参考にしてください→ LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会 - tuneの日記
スクラムのプラクティスを表明的に導入したものの、型が守られてなかった感じかな?(スクラムやってないのであんまりよくわからない) #ques14
— カルバート (@trickmrbiz) November 15, 2019
型は表面的に守られているけど、なぜやるのかの目的を腹落ちしないまま続けていた感じです。
スクラムあるあるかもしれませんが、バックログの優先順位は価値を優先するのか、規模が小さく出しやすいものから手をつけるのでしょうか#ques14
— ノグチ (@N2Teiz) November 15, 2019
それも含めてプロダクトオーナーが決めるものですが、やりやすいものばかり手掛けていると「へろへろバックログ」になってしまいます→ Agile Product Management - Speaker Deck
8pt以上だと分割するってしてたけど、ストーリーポイントがそもそもなかったのかな??
— 葛はエオルゼアに降り立った (@kazurasaka) November 15, 2019
#ques14
開発期間をストーリーポイントという単位に換算していた、大きくても分割しなかったというのがそもそもの問題です。
QA natsukaって創業メンバーの長束さんのことかな #ques14
— Fumikazu Fujiwara (@freddiefujiwara) November 15, 2019
正しくは"stg-natsuka"という検証環境ですが、名前の由来は間違い無いかと。創業者によるQAとかではないです。
プロセス改善というよりバリューチェーンの改善ですね。付箋紙の剥がし方に改善の余地がありそうw #ques14
— TB (@Taka_bow) November 15, 2019
なかなか定着しなくて・・・→ アジャイル開発に使う文房具の使い方・選び方 - tuneの日記
リアーキテクチャ。さらっと言ってるけど大変なイメージしかない。素人だから?😭 #ques14
— しらみ (@a_shirami) November 15, 2019
大変です。これは私が入社してからの半年ではなく、入社前から1年ぐらい時間をかけてやったことです。やり切ってくれたメンバーには感謝しかありません。
"小さくすると一般的にはQAしづらくなる。" 個人的には小さくした方がテストしやすくなるような気がしてしまう。うーーん。 #ques14
— しろうま (@siro_uma) November 15, 2019
対象が小さい方がテストはやりやすい。ただしマイクロサービスは相互の依存があるからそこを含めたテストは難しいというお気持ちです。
型なし言語から型ありへって面白いな。結局型要るんじゃん。 #ques14
— さすらいのレビュー屋 (@mori_ryuji) November 15, 2019
ビジネスロジックを整理するには型ありが向いているのかなと最近感じています。
作り直しのリファクタリングの時のテストがつらいかと思うけど、どんな感じでやっていったかは気になる #ques14
— Matsu(まつ)@技書博3F-せ06 (@mty_mno) November 15, 2019
開発メンバーが愚直に書いてくれました m(_ _ )m
マイクロサービスへの完全移行したと言い切れるのすごい
— Shogo Tokui (@ShogoTokui) November 15, 2019
どうやったんだろう
#ques14
マイクロサービス化の準備は私の入社前から1年ほどやっていて、現在もテスト展開中の状況です。
「 組織全体で品質を担保していこうという気持ちがあるからQAチームは必要ない」んんん???いや、それはどの開発組織も同じ気持ちなんですが… #ques14
— よーや (@yoya_k) November 15, 2019
QAチームはあるに越したことはないけど、ビジネスロジックが不明瞭という一番重要な問題に対してQAチームを作ることはその直接的な解決になっていないということです。
テスト観点の整理をした #ques14
— ミジンコおじさん (@koppamijinko) November 15, 2019
ユーザー観点のテスト項目出しなので他社のQAエンジニア/テストエンジニアが作るテスト項目よりもずっと洗い粒度です。作る工数はかかりますが、プロダクト全体視点で仕様の漏れがないかを考えるメリットがまさっている状態です。
集積していっぱいになった後の未来が気になる…#ques14
— broccoli (@nihonbuson) November 15, 2019
ある程度溜まったら整理して次の段階にいくんだと思います。今はテスト項目を洗い出すのも辛い状態なので観点の集積から始めたというお話です。
ドメイン知識の蓄積に対する答えはテスト観点を集めること? #ques14
— さすらいのレビュー屋 (@mori_ryuji) November 15, 2019
ドメイン知識を蓄積する→仕様を押さえたい→仕様の前に観点がよくわかってない の状態でした。ドメイン知識を蓄積するための前段階ぐらいです m(_ _ )m
この急激な変化に着いていくの、ひとによってはかなり抵抗感あったりもすると思うんだけど、そーゆー反発とかはなかったのかな?
— ゆふ@仕事系 (@yufu69) November 15, 2019
「みんなQAちゃんとしたい気持ちはある」って話だし、やはり「そーゆーイケてるひとを選んで採用する」みたいな感じなのかな。。#ques14
一緒い働いているメンバーがイケていることは否定しませんが、「きれいなウォーターフォール」をやっているときと同じメンバーなので人の問題ではないと思っています。変わっていくことに不安を感じるメンバーがいるのはどの環境でも起きうるので時間をかけて少しずつ変えていきます。
入社半年という信頼貯金少ない中で、文化の根幹にメスを入れるのは難易度高め。
— aqink (@aqink23) November 15, 2019
こういう改善って「何をいうかより誰がいうか」みたいな部分も大きく作用すると思うので、その壁をすんなり乗り越えたのかが気になる。#ques14
信頼貯金が無い状態からのスタートなので、少しずつ少しずつ変え続けるしか無いですね。
「どう〇〇したんですか?」
— halspring (@halspring_qa) November 15, 2019
の答えが常に「とりあえずやる」「できるところから少しずつ広げた」に収束している#ques14
指摘されて気がつきました。確かにそうですね!
アジャイル開発の現場ではQA専任者が居ないこと多いのかな?#ques14
— rr_robert (@rrrobert10) November 15, 2019
そんなことはないと思います。ただ開発プロセスの末端にいてゲートキーパーをしているのではなく、全体に関与しプロセスで品質を高めるように関与する方が活躍している印象を受けます。
マイクロサービスアーキテクチャだとサービスに閉じてしまってドメイン横断的なQAが難しいのかと思ったけど、そこはあんまりないのかな。観点集積でカバーしてる? #ques14
— testtatto_inoue (@testtatto) November 15, 2019
マイクロサービスを導入する話をするとサービスごとにチームを作りがちですが、1チームが複数のサービスにまたがって手を入れることができればドメイン知識が散在する問題は起きないのかなと思っています。
XP祭り2019で「カンバンに求めたもの(LT)」を話してきました
はじめに
XP祭りでLT登壇申し込みをしていたので、会社で改善を続けているカンバンについて話してきました。
Twitterでいただいたコメント
物理カンバンをカスタマイズして磨いていこう
ツールから入るとツールの使いこなしに頭がもっていかれるので物理から始めるのオススメです。
物理看板によってタスクを明示化するだけでなく、看板の構成を工夫して直感的にしている #XPJUG
— Ghostface melOn (キョダイマックスのすがた) (@Ghostface_melOn) September 21, 2019
物理カンバンはチームに合わせてカスタムしやすいのが良さそう #xpjug
— いてはむちゃん 12/22棘フェス (@mistolteen) September 21, 2019
実情に合わせた看板選び、大事 #xpjug pic.twitter.com/EWzrfju3d5
— Ghostface melOn (キョダイマックスのすがた) (@Ghostface_melOn) September 21, 2019
物理カンバンファンの声
私も物理カンバン派です。 とはいえそこで思考停止しているともっと良い可能性も潰しているんじゃないかなとも最近思っています。
物理カンバンやってるところ多いよね #xpjug
— いてはむちゃん 12/22棘フェス (@mistolteen) September 21, 2019
物理カンバンいいなー。 #xpjug
— ざっきー dev (@zakky_dev) September 21, 2019
物理カンバンができるなら物理カンバンのままがいいなー #xpjug
— ゆーじ / Yuji Imagawa (@ug23_) September 21, 2019
電子カンバンが求められる背景
リモートよりも「書けない」が真剣に悩むようになったきっかけですね。 リモートだけが原因なら写真にとって共有するというやり方も選べるので。
電子看板は社内にいないリモート勢や、日本語能力がアンバランスな外国人の使いやすさを上げる #xpjug pic.twitter.com/i69DYWx8UA
— Ghostface melOn (キョダイマックスのすがた) (@Ghostface_melOn) September 21, 2019
おすすめの電子カンバンツール
情報ありがとうございます!
個人的に電子看板はコレが激オススメ#xpjug#kanbanizehttps://t.co/ApddcyE0Ok
— Ikuo Suyama (@martin_lover_se) September 21, 2019
その他
スクラムイベントやワークショップの写真は積極的に残しています。こういう時に便利ですよー
物理カンバン写真に撮って歴史残すの大事だよなぁ。振り返りと発表で使えるw #xpjug
— Hiromichi Hirakawa (@arihh) September 21, 2019
トヨタ生産方式
- 作者: 大野耐一
- 出版社/メーカー: ダイヤモンド社
- 発売日: 1978/05/01
- メディア: 単行本
- 購入: 7人 クリック: 138回
- この商品を含むブログ (123件) を見る
自分が生まれる前に出版された本ですが、内容はちっとも色あせておらず、アジャイルやリーンに繋がる重要な考え方が余すところなく説明されていました。多くの人がオススメしている有名な本ですがもっと早くに読んでおくべきでした。
トヨタ生産方式の基本思想
「徹底した無駄の排除」とそれを貫く2本の柱がある。
1. ジャスト・イン・タイム
ジャストインタイムとは組み付けに必要な部品が必要な時にその都度、必要な数だけ生産ラインの脇に到着する状態を指す。 自動車の生産は部品数が膨大であり、また生産計画も刻々と変化する。そのため中央に情報を集め全体を管理するようなやり方ではジャストインタイムの実現はできない。
ジャスト・イン・タイムを実現するには、物の運搬順序を逆にして考える。前工程が後工程へ物品を渡すのではなく、後工程から前工程へ必要な物品を引き取りに行く。前工程は引き取られた分だけ生産を行う。こうすれば一番最後の工程の生産計画に紐づいて生産の流れが同期され、ジャストインタイムが実現できるようになる。
2. 自働化
「機械に生産の良し悪しの判断をさせる装置」を付加することで、不良品の生産を止めるようにする。 すると正常時に人を機械のそばに張り付けておく必要がなくなり、異常時のみサポートすればよくなる。1人が複数の機械を見ることができるようになり、少人化が実現できる。
トヨタ生産の目的
「原価の低減」を実現するためである。
生産数や生産効率を目標にしていると、見かけの能率アップで満足してしまうことがある。例えば1日の生産数を上げたり、大型機械を導入して自動で作れるようにすることがこれに当たる。必要以上の生産を行うと倉庫や倉庫番が必要になり、大型機械を導入しても人が張り付いていなければ人件費は変わらない。かえって倉庫の費用、機械購入費、人件費が増え、原価は上がってしまっている。
生産目標数は顧客の購買活動によって決定し、企業が自主的に決めるものではない。そのため増産だけでなく減産にも耐えられるシステムでなければならない。
生産の流れを作る
ジャスト・イン・タイムを実現するための生産指示として「カンバン」を用いるが、利用の前提条件として「生産工程ができるだけ流れるようにする」ことが不可欠である。
そのためにまずは生産を平準化する。仕事の「標準作業」を定義し、生産ロットを小さくしても流れるようにする。 一人の作業者が複数工程を担当できるようにし、多能工を育てる。
LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会
LeSS Study LeSS本読書会 第7回
LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会 - Less Study | Doorkeeper
今回は大崎、オージス総研さんの会議室での開催でした。
いつもと異なり、大規模スクラム本で紹介されていた「システム思考」と「フィーチャーチーム導入マップ」のワークショップをやってみることが目的でした。 「フィーチャーチーム導入マップ」は参加者の実際の事例をベースにしているため参加者限定の非公開でした。
気温とビールの売れ行きについて
気温とアイスはシステム思考を最初にやってみる上でのいい事例だそうです。この日はビール好きが多いのかビールになっていました。
チームをスケールさせる
調整ごとを減らし、教育を充実させ、お金も稼ぐというある意味当たり前の結果に。
ベロシティを上げる その1
クソコードはいつも問題になりますね。
ベロシティを上げる その2
ふりかえりやコーチが関わる時間が入っているのが面白いかと。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
LeSS Study LeSS本読書会 第6回
LeSS Study LeSS本読書会 第6回
LeSS Study LeSS本読書会 第6回 - Less Study | Doorkeeper
今回は新宿、グロースエクスパートナーズ株式会社 イベントスペース「G's LounGe」での開催でした。
Q: LeSS Hugeでエリアを分ける背景の説明に「チームが集中力を失う」とあるが、エリアを分けないLeSSでも起きうる問題なのでは?
A: 起きうる問題だが、結局誰もがやらなくてはならず問題になりにくいのかも。または プロダクトが小さいうちはエリアも小さく、少しは耐えられるという想定があるのではないか。
Q: LeSS Hugeを導入している会社・組織はある?
A: 海外ではあるようですが、勉強会参加者の知る限り国内ではなさそうです。 日本でLeSSを導入していると公言している会社ですとYahooやGROOVE Xが挙がりましたが、LeSS Hugeに取り組んでいるという話は聞いたことがないとなりました。
Q: マイクロサービスとLeSSの相性はどうなのか?
A: マイクロサービスごとにチームを構成していなければ両者は矛盾していない。
マイクロサービスは設計・アーキテクチャの話、スクラム・LeSSはプロセスの話。 責務をシンプルにしたサービスにすることでサービスを増やしたり・作り直したり簡単にできるようになるのがマイクロサービスのメリット。 スクラム・LeSSは多能工化したチームによって、フロー効率改善が期待できるメリットがある。
Q: コンポーネントとフィーチャーの違いがわかりにくい。予約はどちらか。
ものによりそう。
- ホテル予約システム→フィーチャーではないか
- カレンダーの会議予約システム→コンポーネントっぽい
単独で利益があげられたり、顧客価値が訴求できるならば独立したプロダクトであり、フィーチャーになるのではないか。
Q: チームで多能工化を目指すが、現実には専門家思考の人もいる。チームに加える時に考慮している事項はあるか?
特に何もない。尖った能力を持つ人もうまく組み合わせてクロスファンクショナルなチームを構成する。 仕事の配分はチームでやりくりしてもらう。
とはいえ、圧倒的な専門性を持つ人がチームで能力を発揮できないケースもあるので、その場合はチームから外して別の仕事を与えることも考える。
Q: うちのチームは顧客と会いたがらないのですが…
A: 組織が顧客に会わせる目的を「仕様を明確化して文書を作成する人」としか扱っていないのではないか?
または顧客のことを理解する手助けを組織として提供していないのではないか?
Q: 典型的なLeSS Huge組織において、スクラムマスターはどこにいるのか?
A: フィーチャーチームにいる。
書籍の例では教育・コーチングチームがあるが、ここに所属している場合もあるかもしれない。 能力の高いスクラムマスターや、外部コーチがここに入るのかも。
書籍の「典型的なLeSS Huge組織」はガイドであって、「こういう組織にしなければならない」というものではないので、自分の組織・メンバ能力にあったやり方を見つけていけば良い。
Q: 自己管理チームとはなにか?
A: 上図の左から2番目。
- マネージャー主導チーム
- 自己管理チーム←LeSSはここ、スクラムもここ
- 自己設計チーム←外部に働きかけができて、組織変革ができるチームのこと。
- 自己統治チーム←アジャイル・スクラムの対象外、取締役会とか。
Q: システム思考とはなにか?
A: 因果関係を整理したシステムとして事象を捉え、俯瞰した視点で問題解決にあたる考え方。 ロジックツリーでも問題分析ができるが、個別の問題だけを解決しても実際には要因間に因果関係があるので本当に解決できるとは限らないという考えに立っている。
枝廣 淳子さん、小田 理一郎さんが翻訳・監修で入っている本がおすすめ。
- 作者: ピーター M センゲ,Peter M. Senge,枝廣淳子,小田理一郎,中小路佳代子
- 出版社/メーカー: 英治出版
- 発売日: 2011/06/22
- メディア: 単行本
- 購入: 3人 クリック: 89回
- この商品を含むブログ (37件) を見る
「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践
- 作者: 小田理一郎
- 出版社/メーカー: 英治出版
- 発売日: 2017/06/21
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (6件) を見る
世界はシステムで動く ―― いま起きていることの本質をつかむ考え方
- 作者: ドネラ・H・メドウズ,Donella H. Meadows,小田理一郎,枝廣淳子
- 出版社/メーカー: 英治出版
- 発売日: 2015/01/24
- メディア: 単行本
- この商品を含むブログ (7件) を見る
勉強会時に参考にしたブログ
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
アジャイル・スクラムとHR・採用を組み合わせた用語の整理
「アジャイルHR」とか「スクラム人事」とか、アジャイルソフトウェア開発から離れたアジャイル・スクラムを冠する用語をよく聞くようになったので整理のためにまとめてみました。
アジャイルHR / アジャイル人事
DIAMONDハーバード・ビジネス・レビュー 2018年07月号 [雑誌]
- 作者: ダイヤモンド社
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/06/09
- メディア: Kindle版
- この商品を含むブログを見る
ハーバードビジネスレビューでも特集が組まれたことのある用語。日本だけでなく世界でも使われている。
従来の人事管理は任務遂行を重視しがちだが、アジャイルな人事管理は専門知識の育成、コラボレーションと迅速な意思決定に重点を置いている。マネジャーは、コーチングに優れているサーバントリーダーとして位置づけられる。 そのほか、(1)従業員に絶えず学びの場を提供する(2)従業員は絶え間なくフィードバックを受ける(3)成功指数は従業員の満足度と定着率、イノベーションを生み出しているかで決まる――などがアジャイルな人事管理の特徴だ。
「ソフトウェア開発で先行していた組織をアジャイルにする仕組みづくりを人事で取り入れていく動き」と考えて良さそう。
スクラム採用
株式会社HERPが提唱する概念で日本だけの用語と思われる。 "scrum recruitment"でGoogle検索しても言及しているサイトは見当たらない。
この言葉は、チーム開発の手法としてインターネット系企業で広く取り入れられている、スクラム開発と同様に、共通のゴール(採用目標の達成)のために、全社員が一丸となって採用活動に取り組むことを意図して、弊社がネーミングしたものです。そしてスクラム開発の思想である、経験に基づくアプローチをベースに、現れた課題に柔軟に対応していくことを基本原則とする点も、同様にスクラム採用に欠かせないポイントだと考えています。
ソフトウェア開発のスクラムを参考にしたようだが、「スクラムを使って人事・採用を改善する」ではない。
下記3つがスクラム採用のポイントらしい。
- 権限移譲
- 成果の可視化
- 採用担当のPM化
アジャイル開発・スクラムのプラクティスを使ったバックオフィス・採用の改善
アジャイルソフトウェア開発フレームワークのスクラムそのもの、またはその中のプラクティスを活用してバックオフィス・採用の改善するアプローチ。ヴァル研究所とガイアックスの事例をよく聞くが、他の会社でも実は取り組んでいるのかもしれない。
www.slideshare.net
Butterfly Effect #1 に行ってきました
Butterfly Effectとは?
「すごい人が話を聞きたい人の話はすごいはず」 という発想で、毎回違ったゲストを呼んでパネルディスカッションをするというイベント。
の1回目に行ってきました。ブログ枠での参加でしたので、楽しかった記録を書き留めておきます。 笑っていいとも!のテレフォンショッキングを模した構成になっており、初回ゲストは最近チーム転職で話題となった及部さんでした。
以下当日のレポートです。
聴衆のヒアリング
今日はプロレスとのことでマスクをかぶった入場でした。
ざっくりまとめるとこんな属性の方々が集まったようです。
- エンジニアが多い
- 及部さんを知らない人は8人
- 転職話を聞きたい人が多い
及部さんの自己紹介
なぜ今日はプロレスだと思ってきたかというと、攻めと受けがあるからだそうです。いい話を聞いて、いい質問をしてほしい。
- 受け:聞く:インプット
- 攻め:話す:アウトプット
パネルディスカッション
Sli.doの方が多かった気がしますが、こんなものも用意されれていました。
Q: 転職の経緯は?
A: 仕事の切れ目が2019年4月にあった。 面白そうだなと思って社内外含めて提案を投げてみた。 結果チーム転職できた。
Q: 転職の理由は?
A: 前の会社が嫌で転職したわけではない。人事のヒアリングにもそう答えた。 面白そうなオファーをもらった & 10年でちょうど良い区切りだと思った。
Q: どのくらいオファーきた
A: 数は覚えていないがカンバンで管理していた。TODO / DOING / DONE / PRAY(お祈りorz) チーム転職をGithubで書いていたので、Issueを作ってオファーしてくる会社もあった。
Q: 決め手は?
A: 一番読めなくて、公表したときに面白そうな所を選んだ。裏ではチームで相談している。 及部さんが愛知県出身なのでデンソーのことは以前から知っていた。
Q: チームで企業という考えは?
A: チーム内で熱い想い・プロダクトオーナーシップを持っている人がいたらやったかも。今回は誰かと組んでやりたかった。
やめるときに全社にメールを送ったら面識のない人から「楽しそうにやっているなと思っていました」と返信があった。 何でも楽しもうとしている。
楽しい・楽しくないの2択だと批評家のようになってしまう。 「楽しむ」だと自分でなんとかする余地が生まれ、なんでも楽しめるようになるのでは。
Q: やばい上司の対処法がある?
A: 上司に遠慮はしていない。1on1で上司の相談に乗る。
初めての上司と会うときは理想の上司・部下の関係を考えて、入り方に気をつける。 自分が上司の下に入ろうとすると、上司も上からなんとかしようとしないか。 対等にコミュニケーションを取ったほうが良い関係が築ける。
Q: 今日はなぜ獣神サンダー・ライガーなのか?
A: 今年はライガー推し、来年引退するから。
Q: チームメンバーに及部さんを評価してほしい。
A: チームに被害が出ないようにマネージャーとしてうまくやってくれていた。一緒に仕事しやすい環境を作ってくれる。
Q: 目標としている人は?
A: たくさんいる。尖ったスキルを持つ人をそれぞれ評価して学びたいと思っている。 あとはプロレスラーの棚橋弘至。何かを長く支えている人は自分にない部分だと感じて尊敬している。
Q: いいPOの定義は?
A: あるプロダクトのことが大好きな人と仕事をしたときは背中を預けるような働き方ができてよかった。
Q: マネージャーとしてのファイアウォール話
A: リファクタリングに近い。上司とのコミュニケーションパスを疎結合にする。
Q: 上司からのマウンティングはなかったのか?
A: された経験あり。やられたらやり返すw 2〜3年目に「やめてもいいや」と思うようになり、そこから色々やり始めることができた。ダメなら転職しようと。 何かの発表で社長いじりをしたことがあったが、意外と何もなかった。壁を作っているのは自分なのではないか。
Q: 男性の育児休暇
A: 育児は仕事の比じゃないほど不確実性がある。割り込みが多い。育児は3時間スプリントでスプリント期間が毎回変わる。
Q: 及部さんの1日/休日の過ごし方
A: 家事が多い。平日できないので。あと筋トレ。
Q: アジャイルリーダーサミットで敢て否定したアジャイルプラクティス
A: モブプロを初めて作業分担が当たり前だと思っていた先入観が壊れた。今の当たり前ももっと良いやり方があるかもしれない。 チーム固定化 → 気軽にいいチームが作れたらもっと良いよね。 普段からいいと思っているものを挙げ、斜に構えて批評するやり方は取り入れてみてもいいかもしれない。
型を学ぶとそれが良いと思ってしまうことがよくある。 もっと改善する、もっと上を目指すということを忘れてしまう。
Q: 一番楽しかったこと、これから楽しみなこと。
A: MaaS、自動運転の世界をなんとかしてやりたい。
次回のゲスト
ライバルでもあり、友達でもある。@kyon_mmさんだそうです。
感想
今年の頭ぐらいから勉強会の立ち上げを色々と悩まれて準備されていたのだなと感じる会でした。 次回はこれから調整とのことですが、ここから始まった輪が予想外の広がりを持っていくと良いですね。