天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

ホラクラシー組織としての成長 with ぺーちゃんに参加してきた

engineering-floor.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

企業の形態はヒエラルキー型が最も多く採用されていますが、別の型も存在しその1つで近年注目を集めているものとしてホラクラシー型があります。書籍やプレゼンテーションを聴いた人も多いのではないでしょうか?今回はホラクラシー組織の成長にチャレンジしているぺーちゃんと、アジャイルコーチとして組織変革の一端を担っているkyon_mmが雑談します。  

会で印象的だったこと

ラクラシー組織の導入にあたって障壁が高い部分

ラクラシー組織と言うと、「社員一人一人がやりたいことを自由にやっていいんでしょ?」や「ホラクラシー組織はフラットではない組織だから何をしてもいいんでしょ?」といった誤解が蔓延していることが多く、ホラクラシー組織を導入するにあたって必要なホラクラシー憲法を浸透させるのが、かなりハードルが高かったということでした。

具体的には、ホラクラシー憲法の解釈で齟齬が起きたり、ある種独善的な解釈をしてしまったりする事態が起きていたということです。

github.com

他にも、経営層を中心とした元々ヒエラルキー組織時代に権限を強く持っていた方々が、なかなか権限を手放すのが難しいという点も、導入にあたって苦労された*1ということでした。

憲法を破ったときの処罰

憲法というからには何かしら破った時には処罰があるのでは...という気持ちになったのですが、基本的には性善説に基づいて運営がされているため、ペーちゃんさんの会社では特に処罰がなされることはないそうです。*2

ラクラシー組織を導入したきっかけ

メンバー一人一人が本当に熱量を持つものを軸にして世の中を変えていこうということをペーちゃんさんの組織ではパーパスとして掲げているそうですが、組織が五人->数十人に増えていく中で社員の自律性が失われつつあったことと、VUCA時代にトップダウンで動くような組織では変化に対応しきれないという危機感が、ホラクラシー組織を導入するきっかけになったということでした。

課題としては多くの企業で抱えていそうなものですが、その課題に対してホラクラシー組織でやっていく決断をされたペーちゃんさんの組織はすごいなあと感じました。

コミュニティ・オブ・プラクティスとホラクラシー組織

ラクラシー組織との関連として、コミュニティ・オブ・プラクティスの考え方と近いかもしれないという話が出ていました。

コミュニティ・オブ・プラクティスでは、既存の組織構造を変えずにどのようにホラクラシー組織のような組織を考えていくのか?というテーマを考えているため、コミュニティ・オブ・プラクティスを前提とした組織づくりをした結果がホラクラシー組織になったという考え方もできるのでは?という視点はとても面白かったです。

会全体の感想

元々期待していた、ホラクラシー組織を現場で実践してみた際の壁や起きたことを聞けて満足でした。

また、ホラクラシー憲法やコミュニティ・オブ・プラクティスを中心に、これまで知らなかった知識にも出逢うことができて、楽しかったです。

*1:厳密には現在も少し課題として残っている

*2:ただし、会社独自で定義(例えば減給など)することもできるということです

大人のソフトウェアテスト雑談会 #124【箱根とリリース当日】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

三河談義

今日はリトリートとPJの大規模リリースが被っていることが理由で30分経過した状態でもeroccoさんと自分しかおらず、最初はスクフェス三河の談義をしていきました。

お互いにコンテンツの内容(今回の困っているポイント)をシェアしたり、テーマ設定の話をしたり、三河のセッションに関する話をしたりとスクフェス三河に関する話をしていたのですが、eroccoさんの発表がめちゃくちゃ楽しみになる時間でした。

楽しい(充実した)生き方

eroccoさんとMarkさんを中心に、充実した生き方って何なのか?楽しい生き方とか充実した生き方って言われてもなかなかそんな器用なことはできないよね、という深い話を聞いていきました。

普通の学び方はできない・勉強をとりあえずしないように倒す、敢えてネガティブな面に目を向け続けるというeroccoさんの戦略*1や、向学心ではなく収集心から勉強をしているというMarkさんの話はとても面白かったです。

ストレングスファインダー

上に書いた生き方の話から、自身の特性について話が飛び、好奇心や収集心を活用して学んでいるという話をはじめとしたストレングスファインダーの話を聞いていきました。

(自分も含めて)今日話していた皆さんが収集心を共通点として持っていたのは面白かったです。

ストーリーから学ぶ

人は(教科書に書いてある内容からは学べなくても)他人の人生から多数学べるという話や、そういう考え方をしているからこそMarkさんは自身の生き様を語るようにしているという話を聞いていきました。

スクラムの教科書から学ぼうとした時とカンファレンスやコミュニティで人の話を聞いた時の違いが個人的にも思い出され、納得感がありました。

リトリートからの中継

Tommyさんがリトリートの中継を回してくれて、リトリートの様子をチラッと見ることができました。

皆さんめちゃくちゃ楽しそうで、改めて行きたかったかなあと思いました笑

ブログを楽に書くパターン

自分が毎日ブログを楽に書くためにどんなことをしているのか?という話を聞いていきました。
詳しくはXP祭りで発表するつもりですが、以下のようなことを意識しています

  • 書いた内容は見直ししない
  • 書いたらすぐにブログに出す
  • ある程度書くパターンを決めておく
  • ...

Markさんに、自分のブログはニュース速報的な感じがあると言ってもらえて、面白い観点かつ納得ができて面白かったです。

全体を通した感想

今回は参加している面々が普段と違うこともあって、普段とまた違う雰囲気&話題で盛り上がっていきましたが、いつも通り楽しかったです。

eroccoさんもMarkさんも話の引き出し方が上手で、話せる内容も幅広いなあと改めて感じました。

*1:どっかでこれでいいだろうと過信するような瞬間が普通の人はあると思うが、eroccoさんは常にネガティブな見方をしているので過信するようなことがないというお話でした

アジャイルよもやま話 ~ 川口 恭伸さんとアジャイルの歴史を振り返りながら学ぼう !に参加してきた

aws-dev-live-show.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

アジャイルよもやま話は、アジャイル開発に関する「よもやま話」を毎回アジャイル界隈で有名な人をゲストに迎えて、お話を伺うというスペシャルイベントです。アジャイルの歴史から、アジャイル開発プロセスの変遷、アジャイル開発の苦労話やアジャイル開発を長年実践している中で学んだことなど、様々な話を伺いながら、どうすればアジャイル開発をうまく導入できるのかを学びましょう。

今回はゲストにアジャイルコーチとして著名な川口 恭伸さん (アギレルゴコンサルティング株式会社シニアアジャイルコーチ) をお迎えして、アジャイル開発の夜明け前から現在に至るまでの歴史と流れについて語って頂き、アジャイル開発についての理解を深めていきます。川口さんのセッションの後は、AWS の SA も参加してセッション内容について、さらに深掘りをしていきます。どうぞお楽しみに !

会の様子

川口さんのセッション

歴史観

ITバブルが崩壊した2001年にアジャイルマニュフェストが誕生し、リーマンショックが起きた2009年にDevOpsが誕生したという話からまずはスタートしました。

大きなイベントが起きたタイミングで何かしらムーブメントが起きていることを考えると、COVID-19や戦争など大きなイベントが起きている2020年/2022年(あるいは2023年)は、アジャイルやDevOpsのようなムーブメントが誕生する機会になるかもしれないという示唆もありました。

以降では、時系列でどのようにアジャイルが歴史的に築かれていたのか?というお話をしてくれました。

スクラムの源流

スクラムを発明したのはジェフ・サザーランドですが、ジェフが影響を受けたと考えられるものとして、以下のものが紹介されていました。

また、トヨタのミッション(地域→チームメンバー→お客さんという優先順位)や、「予測しようとしたときには一点しか見えていなくても、試行錯誤を繰り返していく過程で見えてくるものがある」というトヨタの思想(by 野中先生の本)にも強く影響を受けているというお話もしてくれました。

スクラムの実現に必要な文化変革

上述したスクラムを実現するための条件として、中央集権型(コマンド&コントロール)を打ち破る文化にシフトしていくという流れが必要だとジェフ・サザーランドが提言したという話をしてくれました。

これに追従するような形で、Googleがマネジメントの撤廃をしたり、クロスファンクショナルチームに注目が集まるようになったりと徐々に開発プロセスに変化が訪れ、日本でもトヨタでがプリウスを超短期間で製作した事例(4年→15ヶ月)が誕生したという事例も出てきたそうです。

経験主義プロセス制御

進化生物学で語られているように、不確実な状況に対処するには経験主義プロセスの制御が求められ、経験主義プロセスの制御のためには自己組織化されたチームが必要だというお話がありました。

ソフトウェアの品質とは?

30年前はソフトウェアが動いていれば品質が十分だったけれど、現状は変更容易性が十分でなければ高い品質だとは言えない、というお話が出ていました。

また、これらのソフトウェアを作る人間を中心に考える必要があるという話も、徐々に出てきたということです。

コミュニケーション手法とアジャイル

人間を中心に考える流れから、効果的なコミュニケーション手法が注目されるようになり、ここで相手へのリスペクトや自己組織化したチームというのがアジャイルソフトウェア開発宣言という形で出てきたというお話がありました。

棄却されるアジャイル

その後(2000年代)は、しばらく企業でアジャイルが広められない、システム開発をよくわかっていない人がアジャイルの思想を棄却する、という時代が続いたそうです。*1

DevOpsの誕生

このあたりで、Dev VS Opsという構図とそれに伴う変化に弱い組織が問題視されるようになり、

  • 自動化されたインフラ
  • 共有したリビジョン管理
  • ワンステップビルド
  • 小さく頻繁に変更をデプロイ(フィーチャーフラグ)
  • メトリクスの共有(経営も含め全員が同じ状態を知ることができる)
  • IRCとIMロボット(ログの集約)
  • リスペクト
  • 信頼
  • 失敗を防止するのではなく、起きた時のことを考える
  • 相手を非難しない、自分ごとで考える

が提案されたという話がありました。

これが提案されたのは2009年なのに、今でも刺さるのがすごいよね、というお話でセッションは締めくくられました。

パネルトーク

セッションの感想

まずは福井さんから、セッションの感想として、AWSでやっている内容や大切にしていることと驚くほど一致しているのが面白いという話が出ていました。

今回のセッションのような話をしたときにありがちな反応

川口さんが今日のセッションのような話をしたときに、現場からどういう反応がくるのか?というお話をしてくれました。

反応としては、「いや、そこまではやりたくないんだけど...」「一人で仕事したい気持ちがあるんだけど...」という話が多く出るということです。

開発者じゃない人は特に、ソフトウェア開発の認知をシステム1の状態に留めておきたいのが、こうした反応を引き起こすのではないか?という推測も出ていました。

ビジネスで如何に価値を出すか?というのをトップダウンから浸透されることが重要だと思うが、トップの方はコーチング時にどういう反応をされることが多いか?

ケースバイケースではあるものの、トップというよりは現場の人から要望をもらうことが多いということでした。

その上で、どこかのタイミングで実践していない人が出てくるので、社内政治だったり説得の仕方をコーチングすることが多いということです。

ただ、COVID-19になってからは、今日話したアジャイルやDevOpsの話を理解できている経営者の会社が大きく伸びている印象があるということで、徐々に変化の兆しが見えているというお話も出ていました。

権限移譲

権限がない(=お金が使えない)状態の時に、そういう状態に立ち会った人たち一人一人がどう向い合っていくのか?というのが非常に重要だというお話が出ていました。

テスラの凄さ

製造業でアジャイルを実践しているのはすごいというコメントから、テスラの事例について話をしてくれました。

テスラでは会計も全てDevOpsになっている上に「会社のお金を使うこと」が指標として定義され、お金を使ったことで失敗したことは何も問われない、ということです。

会社レベルでDev/Opsが分かれている場合の対応

今すぐに変えられないのは仕方ないとして、10年後今から何も変わっていないというのはまずいよね、という話をすることが多いということです。

ただ、現状はこそこそアジャイルを導入したりする現場は少なくなっている上に、コーチングの機会や実践者の数はどんどん多くなっており、ソフトウェア業界の環境としては全体的に良化しているのではないか?という話も出ていました。

分散チームが増えた中でアジャイルを実践するのが難しい

リモートでもオンサイトでも両方仕事ができる、というのが重要だと思うというお話でした。

なお、XP祭りでアンケートを取った時、半分の人は「アジャイルを実践しやすくなった」半分の人は「アジャイルを実践しにくくなった」という回答をしたそうで、アジャイルを実践している人たちの変化に対応する強さを実感したということです。

会全体を通した感想

(ブログで表現しきれていないのは自分の力量不足ですが)川口さんのセッションはいい感じの雑さがありつつもしっかりと重要なポイントは押さえてくれている上に、ところどころで力強いメッセージがあり、最高でした。

後半のパネルトークでは、アジャイルコーチを数々の現場でされている川口さんだからこそ話せる話題も多く、これもまた面白かったです。

*1:ここは今回のセッションでは時間の関係もあってサラッと紹介されるだけで終了しました

Autify community meetup テスト自動化を軌道に乗せるまでの道のりに参加してきた

autifyjapan.connpass.com

こちらのイベントに参加してきたので、会で印象的だったことと感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第8回のAutify Community Meetupのテーマは「Autifyでテスト自動化を軌道に乗せるまでの道のり」です。

Autifyをご活用いただき効率的で効果的なテスト自動化に成功されているユーザー様である、サイオステクノロジー株式会社から山根様、株式会社リンクアンドモチベーションから小島様をお招きし、特にAutifyの導入部分にフォーカスし、運用が軌道に乗るまでの課題やそれを乗り越えた工夫をご共有いただきます。

特に他のAutifyユーザーの方がどのようにAutifyの導入を進めているのか知りたい方にとって、他のユーザー様からのお話が直接聞けるおすすめの内容となっておりますので、お見逃しなく!

会で印象的だったこと

サイオステクノロジーでのAutify導入の軌跡と現状

まずは山根さんから、QA経験が薄い&権限的にトップダウンでツールの導入を決められないような状態から、どのようにAutifyを導入していったのか?というお話を聞いていきました。

タイトルの通り、Autifyの導入をするまでにやったことの話が中心だったのですが、現場で何かしら新しいツールを導入する際に役立つ話*1が多数聞けてよかったです。

Autify運用自走化の3steps, unfreeze-change-refreeze!

続いて小島さんから、自身(QAチームに所属していてAutifyについても一定の知識がある人)が極力手を動かさないようにせず、開発チーム内で自走してAutifyを運用する状態にまでどのように持っていったのか?というお話を聞いていきました。

導入前の段階で準備*2を丁寧に行った後、導入後は自動テストの意義が感じられるように&開発チームで自走できるように朝会で毎回自動テストの結果をチーム全員で見直したということで、自身は手を動かさないながらも継続的に開発チームの様子を見守っていたという話が特に印象的でした。

パネルディスカッション(Q&A)

トークセッションの後はパネルディスカッション(Q&A)がありました。

以下、トピックごとに内容をまとめていきます。

テスト仕様書の粒度

細かい部分はわからないが、元々あったE2Eのシナリオテストの仕様書を活用した。粒度は結構細かかった。

3,000シナリオ(シナリオの本数は64本)を作るまでにどれくらい時間がかかったか?

10シナリオを2週間で作った。実運用レベルで軌道に乗るまでは3ヶ月くらい。

アジャイル開発などで画面がよく変わる場合、Autifyの導入はありかなしか?

  • 一回導入してみると良いと思う。もし上手くいかなければやめればいいだけなので。
  • 画面がよく変わる場合だとしても、アジャイル開発をしていると他の機能変更時に意図せずデグレが起きたことを検知したい場面が多いので、アジャイル開発ならむしろ積極的に導入したい。

導入にあたっての失敗談

  • 開発部署外の人(営業の人)に説明する時、「これでどんどんリリースができるようになりますね!」と期待値が意図せず高くなってしまった。
  • パイロットケースを一番重要度が高いケースに設定していたが、仕様が多くインフラ構築にもかなり工数がかかってしまうものだった。(その後方向転換して、早めに効果が出るようにした)

オンボーディングサポートを受けてよかったことは?

  • 方法的な部分であった迷いがなくなった
  • 一人目の仲間になってくれること

「軌道に乗った」の判断基準は?

  • テストケースが無理なく増やせるか?
  • テスト回数が順調に重ねられるか?
  • 現場の人間が自動化を煩わしく思っていないか?
  • (導入して間もない時)チームのみんながそのチームの中で使い方について話をしているか?
  • (導入後)テストされた結果が活用されているか?

会全体を通した感想

テスト自動化に際して人をどうやって巻き込んでいくのかや軌道にどう乗せていくのか?という部分を聞くことができて、面白かったです。

登壇者お二人で毛色や経験が異なっていたのも非常によかったです。

*1:パイロットユーザから広めていく話、成功パターンを確立後に横展開...

*2:興味ある人を中心に巻き込みをお願いする、Whyをキックオフ会で認識合わせする

【 Gaudiy x Ubie xカウシェ】スタートアップにおけるArchitectureの変遷に参加してきた

kauche.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

本イベントは株式会社Gaudiy、Ubie株式会社と、株式会社カウシェによる合同イベントです。

Architectureの変遷というテーマのもと、各社で活躍しているエンジニアがLT形式で発表していきます。  またリアルタイムなQ&Aに加え、簡単な座談会を行います。

会の様子

LTその1(ユビーのアーキテクチャ改善に対する取り組み)

まずはUbieさんから、アーキテクチャ改善を行った背景や具体的な改善の取り組みを紹介してくれました。

背景としては、一般的な理由と同じで技術的負債が増加していったことによって開発速度が遅くなったことが挙げられるということで、改善方法としては、モノリスなサービスの分割を行ったということでした。*1

また、技術的な負債の計測をFour keysを用いて実施しており、この指標の変化をモニタリングしているということでした。

LTその2(Gaudiy Fanlinkを支える アーキテクチャ)

続いて、Gaudiyさんがアーキテクチャ設計のために意識しているポイントを教えてもらいました。以下、ポイントを記載していきます。

  • 開発生産性の向上のために、まずは開発組織の設計から行なっているそうです。Stream Aligned Teamが一気通貫でバックエンドエンジニア/フロントエンドエンジニアがペアプロしながら開発する体制を敷いている
  • 結合リスクを低減させるためにスキーマ駆動開発を実施している
  • Cloud RunのサービスアカウントのIDトークンをヘッダに含めて、サービス間通信を行なっている
  • Server-Driven UI*2による多種多様なIPのUIを実現している
  • On-chain Write, Off-chain Readでブロックチェーンの複雑性を閉じ込めている
  • 自律的な文化を醸成するために階層を極力無くしている(テックリードやEMを意図的に置いていない。当然横断的に出てくる課題はあるが、そういう時は自律的にチームができる)

LTその3(Evolution of Architecture)

最後に、カウシェさんからカウシェのアーキテクチャ構成と課題、対応策について話を聞いていきました。

カウシェさんは、Cloud Runのサービス上でAPI Serverを動かしているということで、

  • 全て(スケジューラやCronも含む)をCloud Runで動かせるようにする
  • 全てをAPIとして表現する*3

の2点を意識することができ、結果的に管理コストや立ち上げ時に学習することを少なくすることができているというお話が出ていました。

一方で課題としては、カスタマーチームとパートナーチーム両方のQAが必要だったり、チーム間のコミュニケーションコストが高めだというお話が出ていました。
この課題を解決するために、サーバー分割(マイクロサービス化)を実施しつつ、インターネットフェイシングするサーバは一つに統一している*4ということでした。

単にアーキテクチャ構成を紹介するのではなく、アーキテクチャの変遷にフォーカスしたお話をしてくれて、非常に面白かったです。

Q&A

アーキテクチャ改善が必要だと判断したのは生産性が定量的に低いと感じられたためか?(Ubieさん)

No。生産性を定量的に測り出す前から、目に見えて生産性が下がっている実感があった。

生産性を重視した結果諦めたものはあったか?(Gaudiyさん)

アウトプットの量。
クロスファンクショナルなチームにすることで、ユーザに与えるアウトカムは最大化しているが、アウトプットしている量は下がっている。

自律的に動けるための仕組みは?(Gaudiyさん)

採用段階で自律的に動ける人だけを集めている。
また、Gaudiyでは水曜日に業務をせず、視座を上げるための時間(色々なロールの人と議論したり、中長期的に投資が必要だと思うことを考える時間)を作っている。

Cloud Runを推してほしい(全員)
  • スケールアウト/スケールインをデフォルトでやってくれる
  • 柔軟性がほどよく低いので、考えることが少ない
  • カナリアリリースがしやすい
  • スタートアップに優しい
Cloud Runでアクセス制限はできるのか?カスケード障害が起きた時に全体障害に影響が出てしまいそうだが...?(Gaudiyさん)

正直ベースで言うと、まさに質問にあったような問題が起きて検討中というステータス。

事前に起きるのを防ぐ仕組みと事後に対応する仕組みの両輪で検討している。

Node.jsはバージョンアップが多い分検証の速度が下がるのではという懸念があるが実際のところどうか?(Ubieさん)

懸念になることは現状起きていない。一年に一回という頻度がそこまで多いと思わないし、破壊的変更も少ないと理解しているため。

会全体を通した感想

他のイベントと比較して、結構踏み込んだ話を各社さんがしてくれた分、かなり具体的な内容を聞けたのが面白かったです。

スタートアップならではの工夫やトレードオフが聞けたのは、特に楽しかったです。

*1:サービスを分割する際は、DBの分割が大変だったということです。

*2:ServerでどういうUIを表示するのか決めて、その決定事項に従ってClientがUIを組み立てる

*3:gRPCからコード生成している

*4:Envoyの活用

アジャイルカフェ@オンライン 第19回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

「なんちゃってアジャイル」はありか、なしか?というテーマについて、木下さん家永さん天野さんの3人がディスカッションをしてくれる会です。

会の様子

なんちゃってアジャイルとは?

まず、なんちゃってアジャイルとはそもそも何か?という話について定義をしていきました。

厳密な線引きは難しいものの、以下のようなものはなんちゃってアジャイルに当たるのではないか?ということでした

  • XPごっこ(お客さんを巻き込んでいない。開発者だけで仕事を完結させている)
  • POがいない
  • アジャイル原則(4つの価値と12の原則)に則していない。*1

とはいえ、アジャイルは形容詞なので、上記に当てはまっているから0(アジャイルをやっていない)というよりは、上記に当てはまっていると度合いが0.5以下くらいだから、アジャイルとは言いにくそうだよね、くらいのイメージなのかな?という話題が挙がっていました。

なんちゃってアジャイルがありだと思える理由

なんちゃってアジャイルがありだと思える理由としては、以下が挙がっていました。

  • 上述したようにアジャイルは形容詞で、徐々にアジャイルの度合いが上がっていくようなものなので、ありだと思う
  • 改善傾向さえあれば、ありだと思う
  • プロジェクトをアジャイルにしていきたいと思って自分ごととしてチーム全体が改善しようとしているのであれば、ありだと思う。むしろ、なんちゃってアジャイルと言って欲しくない。(そういう状態になるなら、なんならアジャイルという言葉を使わなくて良い)

なんちゃってアジャイルがなしだと思える理由

なんちゃってアジャイルがなしだと思える理由としては、以下が挙がっていました。

  • 条件付きになるが、期間が年単位でかかっても変化が何も起きていないなら、なしだと思う

会全体を通した感想

だいぶふわふわしたテーマだなーと思って最初の方は聞いていましたが、定義をしていく中でこういった現場を見たことがある/聞いたことがある...という話を聞いたりするのが面白くて、テーマ以外の部分でも学びがありました。

また、木下さんといえばアジャイル界のドラッカーと聴いて納得する会でもありました笑

*1:成長には過程があるので、これらの原則を現在実施していなくてもアジャイルになる可能性はある。ただ、できていないならアジャイルとは言わないでいいのでは...?という話が出ていました

Tech系Podcastを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子や感想を書いていこうと思います。

furoshiki.fm ep.26 プロダクトマネージャーのこころがまえとプライドを同時視聴する

podcasts.google.com

まずは同時視聴の予約が一番最初にされていたこちらのPodcastを聞いていきました。以下、挙がっていたコメントを書いていきます。

  • お世話になりますはからのスタートはやはり違和感があるw
  • Engineering Floorの話とあわせてきくと、味わい深いw
  • いいスクラムマスターがいるとPOは遠慮無くいろいろといえるけど、ちょっとしたことでも防衛的になってしまうチームだと、POがプロダクトよりも開発者の機嫌を気にしなくちゃいけなくなったり
  • 開発者とかスクラムマスターからプロダクトオーナーをうまく巻き込んだみたいな話はよく聞くけど、プロダクトオーナーからアプローチしている話は新鮮でおもしろい  
  • アクセル踏み込めている感じの話でいいな 
  • リリースしたら、プロジェクト終了、チーム解散みたいなものだとサステイナビリティ感覚は薄そう
  • スクラムマスターがいいなやっぱり。。
  • 「最近なにやってんの」と声をかけられるまでの人間関係の築き方はどうしてるんだろう 
  • うまくいかなかったら開発チームのせい、うまくいったらPMのおかげ。という人もいそう。 
  • モバイルオーダー、便利すぎるんだよな。 
  • うまくいかなかったら開発チームとPdMのせい、うまくいったら俺のおかげ(アレ俺)な人も
  • イラッとすることもありますが、「アレ俺」って多くの人がいいたがるプロジェクトって、いいプロジェクトだなと思うことはあります。多くの人が関わりたくなっていたり、関わっていたといいたくなったりするということは、勝ち馬感がでていたり、協力してもらいやすい状況なので 
  • お世話になっていますからのバイバイ新鮮 

1990 Miyamoto Interview, Nintendo in Kyoto B-Roll (In Japanese)を同時視聴する

www.youtube.com

続いて、HCDの話をひたすらしていくこちらのYoutubeを同時視聴していきました。

ファミコンはやったことがないので、懐かしさを感じることはなかったのですが笑、実際にものづくりをされている様子(遊んでいる人のことを徹底的に考える姿)を見れたり、問題設定に高い比重を置いている様子を見ることができたりと、学びになることは多い動画でした。

また、参加者の皆さんから色々と付加情報をもらえることが普段の同時視聴以上にできて、同時視聴のありがたみをめちゃくちゃ実感しました。

EBMと研究デザイン:小橋元を同時視聴する

www.youtube.com

最後にこちらの動画を見ていきました。

EBMの部分では、問題の立て方やScienceとArtの使い分けの話、エビデンスを患者のコンテキストに寄り添った形で活用するという話など、ソフトウェア開発にも適用できそうなポイントが幾つもあって、目から鱗な話がとても多かったです。

研究デザインの部分では、研究の種別とその種別ごとの説明に加え、交絡をはじめとした研究をしていく上での落とし穴を知ることができて面白かったですし、コホート研究や介入研究の話は金融業界でも似たような課題感を持って似たようなアプローチを考えているなーと思って、とても面白かったです。

また、非常にパッション溢れる講演で、話を聞く前に想像していた雰囲気を良い意味で大きく裏切られました。

全体を通した感想

今日は濃くて重いネタを3本も同時視聴することができて楽しかったです。
どのネタも自身の立場とは一見するとコンテキストが遠い話でしたが、どれもつながりがはっきりとあって、学びを得ることができました。(ネタを推薦してくれた方々に感謝です!)

Youtubeってこんなにいい動画を見られるんだあ。。という想いを持つ会でした。