ばやしのブログ

アジャイルとかやる中で考えていることを書きます

自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由

どうも、ばやしです。

先日@ryuzeeさんがこんな記事書いてましたね。

www.ryuzee.com

記事の内容に関して同意しかないので、自分も最初はKPTをやるけどそのうちやらなくなる理由を書いていきます。

なおレトロスペクティブの手法はファシリテーターの振る舞いで効果効能が変わると思うので、ここから書く話はあくまで自分がファシリをする場合の話です。本記事内で登場する「KPTは」という表現は「(私がファシリする)KPTは」の短縮表現なのでご承知おきのほどお願いします。

KPTから始める理由

わかりやすいから

シンプルでいいですよね。ルールも簡単でレトロスペクティブのファシリをしたことない方でも取っ付きやすいです。また業務改善感が強いのがウケが良い理由のひとつだと感じています。業務中のMTGなんだから、業務が改善されるようなMTGをしようよという心理的な圧は多少なりともありますよね。 チームの雰囲気や周囲からの見る目が変わってくると、端から見ると遊んでいるようなレトロスペクティブの手法でも問題はないのですが、そういう土壌がない状況だとちゃんと振り返ってちゃんと改善していこうという雰囲気が強いKPTは馴染みやすいです。

端的で効果が出やすいから

KPTの良いところは、Keepで自分が良いと思っていることを表明し、Problemで問題だと思っていることを表明し、Tryで改善案を考えることです。はい、ルール説明でした。

そもそもチームメンバと良いと思ってること、悪いと思っていることをみんなで話し合うことって普段しないですよね。そんな状況でKPTをやってみると、みんなが何を良いと思い何に不満を感じていたのかがすぐわかります。しかもこれまでレトロスペクティブ的な活動をしていなかったチームの場合「みんな不満に思っていて改善はすぐできるもの」がたくさん出てくることが多いです。すぐできるんで改善はどんどん進みます。そういった表出させるだけですぐ解決する問題に取り組むには最適なフレームワークです。

じゃあなんでこのKPTをそのうちやらなくなるかと言うと以下の通りです。

そのうちやらなくなる理由

すぐ解決できる問題にしか強くない

KPTは表面的な問題に言及することは得意ですが、課題の真因に迫るのは苦手です。 目に付くゴミ拾い的側面が強いなと感じています。目に付くし拾うだけで片付けられる課題の改善には効果的な一方、こびりついた汚れや基礎工事から必要な課題には無力です。例えば自分たちの目標に振り返ってそもそも今の自分たちが向いている方向性は間違ってるよね?みたいな話は出て来づらいイメージです。

Problemばかりに目がいきがちだから

KPTはKeepもProblemも両方出すので、フレームワークとしての問題ではないと思うのですが、大体どのチームでやってもProblemばかりに目がいきます。 悪いところを直す方がわかりやすいからですかね?理由ははっきりしないのですが、だいたいProblemばかりに目がいき自分たちは問題ばかりであるという雰囲気が蔓延します。ポジティブなチームのほうが生産性が高い的な話がどっかにありましたし(雑)、私自身もポジティブなチームで働いている方が楽しいので、KPTの多用は避けるようにしています。

レトロスペクティブの手法はたくさんあってそれぞれ色んな効果効能があるから

前述の通りKPTは目に付くゴミ拾い的改善に効果がある一方、チームの目標に立ち戻る、チームをポジティブにする、深く考えないとたどり着けない問題にアプローチする、などの効果効能は薄いです。 逆に言うと上記のような効果効能が見込めるレトロスペクティブの手法は世の中に存在しますし、それ以外の効果効能が見込めるものもあります。 例えば私はチームに目標に立ち戻ってほしいなと思うときは帆船のふりかえりをやります。このようにその時のチームに対して適用したい効果効能を踏まえてレトロスペクティブの手法を使い分けています。チームの状況に応じてレトロスペクティブの手法を使い分けることに関しては小田中さんの資料が詳しいです。

speakerdeck.com

自分たちのプロセスを自分たちでどんどん変更していってほしいから

レトロスペクティブでは自分達のプロセスを検査適応します。その検査適応のやり方自体も検査適応してほしいと思っています。レトロスペクティブのやり方を複数実践することで、レトロスペクティブ=KPTのマインドから脱却して欲しいですし、自分たちがコントロールして良い範囲をどんどん広くしていってほしいという思いがあります。

というわけで自分が最初はKPTをやるけどそのうちやらなくなる理由でした。

最初にも書きましたが、ファシリによって出てくる内容は違うので今回の話はあくまで私がファシリするKPTの話であることをご留意ください。

あと「KPTを続けたくないんだけど他の手法が怖くて...」という方向けにKPTの次にやるレトロスペクティブの手法でハードル低そうなやつを以下に挙げておきます。

増やすこと、減らすこと、止めること、続けること、始めること、の5つを出す。 KPTと構造が似てるからハードル低いけど、表現の違いによって出てくるもの全然違うことが学べると思います。

付箋に話したいこと書いてランダムに引いてその話する。ルールが非常にシンプルだからハードルは低い。あとこんな話する必要ある?みたいな話でも深掘るとめっちゃ面白いトピックになるみたいな経験ができる。

以上です。

2024年を振り返る

どうも、ばやしです。

今年も振り返り記事書いていきます。

子どもが生まれる

11月の下旬に息子が生まれました。待望の第一子です。

はい可愛い。

現在は育休をいただいており育児にフルコミットしています。 夫婦二人でフルコミットしているとはいえ、新生児の育児は超大変ですね。 二人でやってもこんなに大変なのでこりゃあワンオペ育児はつらいよねという気持ちになりました。

まぁでもそれを補ってあまり得るわが子の可愛さよ。自分のお気に入りの時間はミルクを飲ませたあとゲップさせるために縦抱っこをしている時間です。

育休をいただく

3ヶ月ほど育休をいただいております。 男性が3ヶ月も育休とるって世間的にはあんまり一般的じゃない気もするのですが、弊社は男性で育休を取るのが当たり前な雰囲気があり、私もありがたく取得させてもらいました。 上述の通り、新生児の育児は超大変なので奥さんの負担を軽減できて良かったというのと、あと育休取ると育児スキル獲得のスタートダッシュに失敗しなくて良いなと思いました。

夫婦ともに子育て経験がないので、最初の何もわからん状態で学習しながら子育てスキルを得ていくフェーズを夫婦二人で経験できています。 これが里帰り出産などになると、最初のスキルを得ていくフェーズを片方一人で過ごし、実家から返ってくるタイミングでは、スキルめっちゃある片方 and 経験値0のもう片方みたいな構図が生まれてしまいそうです。

この構図に陥った場合、この構図を理解し、スキルがある人がない側にオンボーディングなどを実施すれば良さそうですが、大事な赤ちゃんの世話なので失敗もそんな許容できないだろうし、そもそも余裕もないだろうし、結果として育児は奥さんがやるものみたいな構図が生まれそうです。そうなると片方は育児の負担が全部行ってしんどいし、もう片方はスキルがなくて育児怖いしで、お互い不幸になりそうですね。

こういう構図が生まれ得ることを育休取る前はあんまりわかってなかったのですが、結果として回避できて良かったなという感想です。

引っ越しをする

前まで東京の山手線沿いに住んでいたのですが、フルリモートだし子供も生まれるしというところでお家賃の低めな埼玉県の都市に引っ越しました。駅前もそれなりに繁華で国道沿いにいろんな店がある感じ、大学の時に住んでいた長野市を思い出して「俺が求めていた丁度よい繁華な街とはこれだったのかもしれない」と認識しました。

埼玉に引っ越したことで埼玉県民の県民性を肌で感じたり新鮮な日々を送っています。

埼玉に住んでわかったことは、翔んで埼玉は、翔んで千葉でも翔んで神奈川でもなく翔んで埼玉なんだよなという気持ち

— ばやし (@bayashimura.bsky.social) 2024年12月23日 20:25

車を買う

埼玉に引っ越したし子供も生まれるしということで車を購入しました。大学生の頃に教習所で免許を取得してから、ほとんど運転せずペーパードライバーとしてキャリアを積んできました。運転怖すぎて自動運転が普及するまで逃げ切る予定だったのですが残念ながら逃げ切れませんでした。

自分が下手くそであることを理解して

  • 小回りが聞くよう車体は小さめ
  • 安全装備がついてる
  • ぶつけてもショックが少ないように価格帯は低め
  • 子どもを乗り降りさせるだろうし電動スライドドアはほしい

みたいなことを考えていったら中古のNBOXになりました。 一番売れてるってことは一番良いってことだろう?(素人考え)

最近は車で角上魚類に行ってカニ仕入れたり、コストコに行ってカニ仕入れたりしています。

車好きの人にNBOX買いましたというと「賢い選択だね」という褒められてるんだか失望されてるんだかわからない反応をいただくというのが学びです。

仕事

去年と変わらずLinc'well株式会社で働いております。 入社して一年ほど経ちましたが、入社したときと気持ち変わらず楽しく働けております。 オンライン診療事業を支えるプロダクトを開発するチームのチームリーダーみたいなポジションで頑張ってました。これまで自分が関わってきたプロダクトの中ではコードの規模も事業規模も桁違いに大きく、多数のステークホルダーに向き合いつつ自走するチームを作るのは中々難しいところもありましたが、割とうまくいったような気がしています。 一定のレベルでの安定状態までは持っていけたので、ここからさらにグレートなチームになるために色々やりたいなーと思っていたのですが、今は子育てを頑張ります。 育休から戻ったら色々やっていきます。

登壇

今年はスクラムフェス大阪とXP祭りで登壇しました。

speakerdeck.com

speakerdeck.com

XP祭りの方の資料はありがたいことに多くの人に見ていただけたみたいで、驕るわけではないのですが、自分の発表はそれなりに多くの人に読まれ得るものなのだなという気持ちになりました。 個人として有名人になりたいわけじゃないのですが、自分の知名度が上がることで会社の採用に効いたら嬉しいなという気持ちがある一方、生半可なこと書くと怖いことなりそうだなという気持ちもあります。 まぁ気にしすぎず、ただ色んな人が見る可能性があるということは忘れずにやっていきます。

以上2024年の振り返りでした。

スクラムフェス大阪2024のサテライト情報まとめ

上記ポストを見てスクラムフェス大阪2024のサテライト情報が静的な場所にまとまっているといいなと思ったのでまとめておきます(情報入り次第随時アップデート予定)

www.scrumosaka.org

ちなみに私も品川葛飾連合として大崎でサテライトやるのでみんな来てね。

品川/葛飾

場所: 品川産業支援交流施設 SHIP

URL: https://connpass.com/event/321514/

福岡

場所: GROWTH 1

URL: https://fukuoka-scrum.connpass.com/event/319581/

神奈川

場所: NE株式会社

URL: https://agile-kng.connpass.com/event/319649/

仙台

場所: トークネットホール仙台(仙台市民会館)

URL: https://suku3rum-sendai.connpass.com/event/320275/

備考: 「会議室2つ予約しているので現地で登壇できるようにする予定です。」とのことです。

Women in Agile Osaka

場所: 大阪の会場近隣

URL: https://wiaj.connpass.com/event/320665/

備考: 「大阪の会場近隣にもサテライト会場用意してまして、Women in Agile Osaka 参加者の方が入れるようにしたいと思います。Women in Agile Osaka はスクフェスの初日の昼にOSTしますー。」とのことです。

虎ノ門

場所: 虎ノ門ヒルズビジネスタワー

URL: https://ksg.connpass.com/event/317250/

三河

場所: CTC豊田オフィス

URL: https://connpass.com/event/320986/

栃木

場所:
 Day1:USSクリエイティブステーション宇都宮
 Day2:マロニエプラザ(宇都宮産業展示館)大会議室

URL:(サテライト個別の参加登録はやらないのでありません)

鹿児島

場所:リコーITソリューションズ株式会社 鹿児島事業所

URL:
 Day 1:https://kagoshima-scrum.connpass.com/event/321410/
 Day2:https://kagoshima-scrum.connpass.com/event/322022/

盛岡

場所:岩手県民情報交流センター(アイーナ) 7階 岩手県立大学アイーナキャンパス PC演習室

URL:https://morioka-scrum.connpass.com/event/321644/

スクフェス福岡2024に行ってきたよ

どうも、ばやしです。 表題の通りスクフェス福岡2024に行ってきたので感想を書きます

Growth 1がとても良い

今年は去年のesports Challenger's Parkから代わりGROWTH1という会場になりました。

www.fukuoka-fg.com

2階、3階でそれぞれトラックが行える丁度良い大きさの会場でした。

私は主に3階にいたのですが、3階に併設されていたバーカウンターがとても気に入りました。

せっかくなのでBar yashiというバーを開きまして、疲れたたがみさんにウーロン茶を出したり、えーちゃんの人生観を聞いたり、ひろみつさんの発表に出てこない話を聞いたりとバーテンダー役得の時間が過ごせました。 バーテンダーをやって思ったのですが、自分のオススメの酒や飯を他人に振る舞うことが好きかもしれない。

おおひらさんアクリルスタンド

おおひらさんのアクリルスタンドがとても活躍していましたね。 おおひらさんにイカを食べさせたり、おおひらさんと旅をしたりと面白くて微笑ましくてちょっぴり不気味な写真がXやDiscordに多数投稿されてふふっとなりました。 私が撮ったおおひらさん。

Discordでオンライン飲み会をしているおおひらさんに対して、おおひらさんアクリルスタンドを使って猫ミームをしたのは今思い出してもくすっとなります。 こんなにみんなにおもちゃにされながら、しょうがねぇなぁと笑うおおひらさんの懐の深さが際立つおおひらさんアクリルスタンド化でしたね。

見た発表

スクフェスの学びにチームを惹き込め! 社内同時視聴会のすゝめ! speakerdeck.com

スクフェスで得た熱量をそのまま社内に持ち込んで辛い気持ちになった人は多いと思います。 しかも行動力のある人ほどそういう経験があるんじゃないかなと。 多分えーちゃんもそういう失敗を経験しつつ、それでも続けた上で社内をちょっとずつ巻き込んでいってる様子が伺えていい話だなーと思いました。

スクラムマスター不在でスクラムをやるのは(とても辛いので)やめておけ! speakerdeck.com

まずはナカミチさん発表上手いな!という感想。発表資料が華美で引き込まれる感じですよね。 内容的にはあるよなーあるある。という気持ちになりました。 果たしてスクラムというフレームワークに沿うことが良いことなのかなーとこういう系の発表を見ると思います。

『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜 speakerdeck.com

LeanとDevOpsの科学は読んだはずですが、もうFour Keysに興味なくなってるんか〜とか、コンフリクトする指標を組み込むことでFour Keysはグッドハートの法則に対抗していると思ってたけどやっぱ難しかったか〜という発見がありました。 bonotakeさんの発表は論文を当たって、それを論文を読まない人にもわかりやすく解説してくれるから好きです(告白)。

変化を巻き起こせ!「とある情シス子会社」で非公式ボトムアップのコミュニティを起点に共鳴する3人のストーリー confengine.com

そんな大したことやれてないんですよ、みたいな語り口でいやなんやそれ凄いなというエピソードがちょこちょこ出てくる発表でした。 今いるこの会社、もうちょっと良い感じになるといいけど、でもやっぱり好きだから転職っていうよりは非公式社内コミュニティで盛り上げていきたい、そのために色んな手打ってやっていくぞーという行動が素敵。 あとRSGTの時に聞けなかったtakaradaさんがメガテン好きかどうかが聞けたので良かったです。

組織変革の波に飲まれながら「何も分からん」期をちょっとだけ脱出したスクラム初心者の2年間 confengine.com

謎のAさんにサポートされてた時はスクラムを理解したと思ったら、自分がリードする立場になったらスクラム理解できてなかった話。 ボビンの論文じゃん。初学者の方が色んなとこに飛び込んで学びを得ていく話は何回聞いても良いですね。Aさんが一体誰だったのかが最後まで謎だったのも興味をそそられました(すっとぼけ)

小さな布石を置きつづける長期戦アジャイルはありうるのか? confengine.com

今更タイトル確認したけど「ありうるのか?」ってありえないと思っている人あそこにいなかったでしょ。大きな組織のカルチャーを変えていくって相当時間かかるし大変だからちょっとずつやっていかないとね、短期的な成果だけじゃなくて長期にも目を向けて、いつ効くかわからないちょっとした布石をめげずにどんどん置いていくんだよ、という内容でした。 実践者の頭取もちんもさんも話を聞いてて、良い意味で浮世離れしてるな〜と思いました。目先の利益とかにはあまりこだわらないけど、ちゃんとステークホルダーへの面通しをして、いざという時に話ができる状況にしてるところとかみんな憧れ凄腕サラリーマンって感じですね。昔のビッグコミックスピリッツに出てきそう。「そんな簡単に上手くいくわけないんだから期待なんかしてないですよ」的なことを頭取が言ってたのが印象的でした。

あとは当日はスタッフ業務の都合上見られなかったのですが、みつかわさんやひろみつさんの発表は是非見たいと思っているので、どっかで時間作ってみようっと。

以上、スクラムフェス福岡2024感想でした。

ドメインモデリングとマイクロサービスの研修に参加してきたよ

どうも、ばやしです。

2/27に行われたJoe Yoder : Domain modeling techniques for designing microservicesに参加してきたので、参加レポです。 なお私はDDDに詳しいわけでもなく、英語もおぼつかないので誤っている部分があるかもしれませんが、ご了承いただければと思います。

www.eventbrite.com

どんな研修だったの?

ドメインモデリングを中心にドメイン駆動設計(以下DDD)の概念を学びつつ、それがどうマイクロサービスに役立つのかを学ぶ研修でした。 具体的にピザ屋のシステムや、交通違反システムを例に挙げてDDDの概念を理解しつつ、ワークショップではクレジットカードシステムを題材にイベントストーミングやマイクロサービスアーキテクチャ設計などを行いました。

全編英語だったのですが

  1. 英語で講義
  2. 日本人同士で日本語でワークショップ

を繰り返すというスタイルであったり、講義資料が日本語に訳されていたりと、英語がそこまで得意ではない私でも割と理解できました。 また講師のJoe Yoderがめちゃめちゃ優しくて、自分の拙い英語を使っても大丈夫そうな雰囲気が全体的に漂っていてました。ほんと助かる。

具体的に研修の中で出てきたことは以下の通りです

一日の研修としては大ボリュームですね。 英語のリスニングということもあり、研修参加者の多くは夕方には脳みそが悲鳴をあげていました。

講義で概念を学ぶ際に具体的な例が出てくるので「集約完全に理解した!」となり、その後のワークショップで「集約ってなんだ...なんもわからん...」ってなる理解のジェットコースターが楽しかったです。

以下印象的だった学びをつらつらと書いていきます。

DDDの目標は関係者達の共有されたメンタルモデルを作ることにある

Joe曰くドメインモデリングだけでは開発チームはドメインエキスパートの話す言葉をコードに翻訳するだけになります。そうではなく共有されたメンタルモデルがあって、それをドメインエキスパートも開発チームもステークホルダーも、そしてソースコードもそこを参照する形にするのがDDDの目標だそうです。

自分としてはこの説明はわかりやすく、だから一緒にイベントストーミングしたり同じユビキタス言語を作るんだね、と今までバラバラに認識していたDDDの構成要素が自分の中でつながった気がします。

ユビキタス言語はユニバーサル言語ではない

異なる境界づけられたコンテキストの中で、同じ単語が異なる意味で出てくることはおかしいことではありません。 あるサブドメインで出てくる◯◯という単語と他のサブドメインで出てくる同じ〇〇という単語は、共通の属性を持つかも知れませんが異なる属性も持つでしょう。例えば顧客を考えます。注文のコンテキストと配送のコンテキストで顧客は違った属性を持ちます。こういった場合、コンテキストを横断した顧客というエンタープライズモデル(大きいモデルという意?)を作るのではなく、コンテキストが異なると属性が異なることを理解して、それぞれ独立した存在として定義します。

(今まとめていて思ったのだけど、コンテキストが異なって出てくる同じ単語にできるだけ違う名付けをした方が良かったりするのかな。例えば注文コンテキストの顧客に注文主って名付けるとか。いやでも同じ単語が使われていることで同じ存在であることも表せるからいいのかな。わからん)

マイクロサービスのガイドとなる原則 IDEALS

オブジェクト指向設計の5つの原則、SOLIDのようにマイクロサービスにも5つの原則があります。それがIDEALSです。

  • Interface segregation: インターフェイス分離
  • Deployability (is on you): デプロイ容易性
  • Event-driven: イベント駆動
  • Availability over consistency: 整合性よりも可用性
  • Loose coupling: 疎結合
  • Single responsibility: 単一責任

ググったらこんな記事も出てきたので参考までに置いておきます。 www.infoq.com

研修の中でマイクロサービスのアーキテクチャを考えるワークショップがあったのですが、自分たちが考えたアーキテクチャのどの部分がIDEALSのどれを満たしているかを質問されてあんまりIDEALSを意識して検討できていなかったことに気が付きました。今後実践する際には、この5つの原則を頭の片隅に入れながら検討すると良さそうです。

以上、Joe Yoder : Domain modeling techniques for designing microservices 研修参加レポでした。 実務ではDDDもマイクロサービスも遠い存在なのですが、研修の最後に言っていた「DDDを使用するかどうか、またはマイクロサービスを作成しているかどうかに関わらず、ビジネス機能またはドメインを中心にモデル化する、集約などの概念を使ってドメインをモデル化することは有用である」という言葉を胸に実践していければと思います。

RSGT2024で今年も配信スタッフをやってきたよ

どうもばやしです。 今年も配信スタッフをやってきたのでブログを書きます。

配信に関して

今年は例年と比較して配信トラブルが多かったです。通訳者設定やネットワーク、マイクのゲインの設定など。 様々な要因が時には複合して発生し、結果としては「つながらない」「聞こえない」というシンプルな形で発露するのはソフトウェアもハードウェアも同じですね。 その節はご迷惑をおかけしました。

また配信に関しての知識を有しているのが配信スタッフだけであり、どこで何が発生しても配信スタッフが緊急呼び出しを受けるのもなかなか辛いものがありました。セッション中の配信トラブルはその性質上全てが障害対応であり、発生すると一番詳しい人間が最速で終わらせるのは間違いなくて、自分がやったほうが早いから、で自分がやってきて他人に知識ややり方のシェアをしなかった結果のつけが回ってきたなというのが今年の総括です。

最終日のスタッフ飲み会でちもさんに「仕事とかでもよくあるよね」と言われて、ハッと気がついたのですが、こういうの無くしていくのもアジャイルの実践の一つなのに我々スタッフが知識の塔を崩さずに疲弊するとは何たる皮肉。

ただRSGTのスタッフってやっぱ凄いよなと思ったのは、こういう問題が発見された際にザザザっと翌年に向けて何が出来るか、翌年は何をしようかが決まっていき、まぁ来年は繰り返さないだろうなという形まで持っていくところです。 来年はみんなが楽に安定的にやっていけるよう、事前の仕込みを色々としていきたいと思います。

雑な感想

  • X(twitter)でよくお見かけするtakaradaさんとお会いできた。色々話したかったけど(女神転生シリーズ好きなんですか?とか)呼び出しを食らって途中で中座。またどこかで是非。
  • 岩瀬さんとRyuzeeさんとお話できた。ベロシティの話で「個人でみたいとか言い出しますよね」「チーム間で比較したいとかも」ってベロシティあるあるを言うと「それも発表の中に盛り込んでます。Deep Diveだからね」みたいにryuzeeさんが言ってて「すげぇ...」ってなりました。
  • 細澤さんとお話できた。細澤さんは雑になると中庸に走るって言ってたのが、私は雑になると極端に走るので、違いが面白かった。
  • 今年の田上スペシャルもすごかった。一体田上さんはどこへ行くのか
  • 白い森さんに「一兆円で仕入れて一兆一万円で売れば取り扱い高一兆円ですもんね」って言ったら嘲笑された。その場で嘲笑しましたよね!って言ったらいやいやそんなことないですよって本人は言ってたので嘲笑は主観です。
  • スタッフの中で毎年やっている来場者人数当てで見事ピタリ賞だった。特に考えなしに直前で投稿してたおしげ監督の数字をインクリメントしたら当たったので実質おしげ監督のおかげです。
  • ミツカワさんに「去年のRSGTの登壇凄い良かったですけど、タイトルに(新米)ってついてたせいで最初興味を惹かれなかったという意見もありました」って言われてぐうの音も出なかった。ハードル下げたくて弱いタイトルつけちゃいがちなのよね
  • Akiさんにスクフェスニセコの資料良かったですよって伝えられて良かった。余計なことをたくさん含めて伝えた気がするけど。
  • ちもさんからフリーレンを熱く語られたので再履修するか。あと折を見てまた漫画とアジャイルlt大会やろうかな
  • 映像切り出し作業やろうと思っていたらたがみさんと川口さんに一瞬で巻き取られてびっくり&ありがたい。

以上です。

プロであることと相互不可侵は違う気がする

どうもばやしです。

最近「プロとしてリスペクトする」という言葉が仕事でのコラボレーションを妨げているかもなと思ったので考えていきます。

プロ同士の仕事

例えばWebシステムを作るときのことを考えます。 プロダクトマネージャーとデザイナーとエンジニアである自分の三人で作っていきましょう。 プロダクトマネージャーは、プロとして最も顧客価値を追求すべく要件を定義します。

「この画面ではこんなことができること」

「このボタンを押した際はこういう画面に遷移すること」

隙がない完璧な要件です。 デザイナーはプロダクトマネージャーが提示してきた要件をすべて受け入れつつ、顧客の体験が良いデザインを追求します。 そして自分はエンジニアとしてデザイナーが考えてきたデザインやプロダクトマネージャーが提示した要件をすべて満たす実装を作ります。 出てきた要件は既存のシステムのデータ構造では実現しづらいです。またデザインもこれまでにないコンポーネントなので結構時間がかかりそう。でもプロダクトマネージャーやデザイナーが出してきた要件やデザインはそれぞれがプロとして最高のものを作ってきてくれたものなので、自分もプロとして破綻なく既存のシステムに組み込みましょう。 ただどう考えても時間はかかるので、そこはちゃんとネゴっておきましょう。

プロダクトマネージャーに◯ヶ月くらいかかりそうです、って伝えたらちょっと顔が引きつってましたが、プロダクトマネージャーも自分のことをプロとして信頼してくれているので、納期を短く設定するようなことはされませんでした。 あとは完璧なものを作っていくだけです、よーしやってくぞ!

ってこういうのよくありません?

こんな感じに出来ないかなという話

プロダクトマネージャーは顧客価値を追求します。でも顧客がどんな人でこのプロダクトをどう使っていて今追ってるKPIや最近のプロダクト周りでの困り事はデザイナーもエンジニアである自分もちゃんと把握しています。 その上で次に開発したいものをプロダクトマネージャーが出してきました。困り事を解決するためのさっと考えた素案は伝えてくれましたが、どうせ色々変わるのでそこはあんまり時間を掛けません。どんな困り事があるかとかがメインです。 デザイナーとエンジニアはそれぞれが自分の専門領域に基づいてどう解消出来るかを考えて話し合います。プロダクトマネージャーもその話合いに参加します。

「こういう機能にしたいなら、こんな画面にすると良さそう。ここにこんなボタンを配置して」

「そのコンポーネントは新しく実装することになるので、結構時間かかっちゃうかも。例えばこの画面にあるこのコンポーネントで代用できないかな」

「この機能の売りは◯◯だから、ここだけはこだわりたいな。時間かかってもここを譲ると出しても意味ない機能になっちゃいそう」

こうしてプロダクトマネージャーとデザイナーとエンジニアがそれぞれの専門領域を共有しながら、全体で最もコスパの良い機能を決められましたとさ、めでたしめでたし。

プロであることと相互不可侵は違う気がする

プロダクトマネージャーが要件考える時も、デザイナーがデザインする時も、エンジニアが実現手法を考える時も、色んな選択肢があってその中で自分の閉じられた領域でトレードオフを踏まえてベターな選択をしてると思います。 そうして出てきた決定は熟考を重ねられたものですし、相手が専門知識を動員して出してきたものなので、もちろん自分が素人目線で否定して良いものではないです。ただ、相手をプロとして尊重するがゆえに、その決定に対して調整をすること自体が失礼と思って丸呑みしてしまうことをやっちゃいがちだよなーと感じてます。ロールが別れた他人同士になると、途端に結論以外の情報をやり取りしなくなるのはもったいなくないですか?

トレードオフを踏まえる領域を全体に広げて、全員でベターな選択をするようにしたいなと思いました。 そのためには相手の領域への理解が結構必要かなと思うのですが、それは学んでいくしかないかなと思ってます。

みたいな話(全然ディティールは違うけど)をPdMにしたら、休み明けに「みんなで仕様を揉む会」というものが設定されてました。まだ固まっていない仕様を持ってきてエンジニアやデザイナー含めてみんなでわいわいする会だそうです。ありがたいですね。

以上です。