GitLabに学ぶ 世界最先端のリモート組織のつくりかた-Forkwell Library #38に参加してきた

forkwell.connpass.com

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

会の概要

今回の第38回目では、『GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ』を取り上げます。 本書は世界最先端のリモート組織を実現するためのノウハウを、GitLab社が公開している「GitLab Handbook」をベースにしながら解説している本です。
リモートであってもパフォーマンスを出せる組織とはどんな組織文化を持ち、どんな取り組みを行ってきたのかを学んでいきましょう。 今回は著者の千田和央氏、そして、事例講演として株式会社ゆめみの片岡俊行氏をお招きし、GitLab社の取り組みをどのように落とし込み、
また、エンジニアはその中でどんな役割ができるかを実践をベースにお話いただきます。

会の様子

GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の読み解き方ーなぜリモートワークは難しいのかー

プロセス・ロスへの対応

GitLubはどうすればすべての人のパフォーマンスを最大限に発揮できるのか？ということを考えている印象があるそうで、プロセス・ロス*1の研究で言われているようなチームで働くことによるパフォーマンス低下に対してどのように対応するのか？というのを徹底的に考えているそうです。

オフィスではプロセス・ロスの原因になる明瞭さの欠如が起きにくいため、リモートワークでは本書に書かれているドキュメント化などの方法を通じて、明瞭さを確保しているということでした。

人間の認知

GitLabは人のパフォーマンスを向上させるために人間の認知をハックしているそうで、その説明がありました。

人間の認知は、社会文化/組織/対個人・グループ/個人/遺伝子といった5階層で多層的に構成されているそうで、多様な正しさを認知する性質があるそうです。
また、認知の特徴としてバイアスが複数あるということも挙げられており、その一部として帰属バイアスや確証バイアスが紹介されていました。

上記の認知特徴によって、論破などをはじめとしたマネジメントを失敗させるような行動が出てしまうということで、GitLabでは共通の目標に向けた行動を取ることでこのような行動を抑制する仕組みを持っているということです。

より「わかり合う」ために〜前向きな意図の想定〜

GitLabで「わかり合う」ために紹介されている方法として、スティールマン論法と呼ばれるように「相手はベストを尽くしている」という前提に立つことが重要だという話がありました。

GitLabから学んだゆめみの「オープンハンドブック」

ゆめみでリモートワークが導入されたきっかけ

社員に世界一周旅行をしたいというメンバーがいたそうで、そのメンバーが世界一周旅行をするためにしばらく会社を辞めることになるくらいなら、リモートワークを導入してみようと考えたことがきっかけだそうで、そこからリモートワーク先端企業宣言をはじめとしたものをし始めたそうです。

リモートワークハンドブック作成のコツ

リモートワークを推進するためにリモートワークハンドブックを作ったそうで、その際に使えるコツの紹介がありました。

• 情報の正確さと信頼性を上げるためにSSOT(Single Source of Truth)を大切にする
• すべての情報をハンドブックに凝集させる必要はないという前提に立つ
• 自分なりのメモをまずはオープンする
• オンボーディングに関わる情報をまとめる
• 採用に関わる情報をまとめる
• 情報の正しさの定義をする(例えば、迷ったものに使うような情報=ガイドラインとして定義するなど)
• GitLabと同様にレビュープロセスを導入している

Q&A

講演が終わった後はQ&Aがありました。

以下、内容を一問一答形式かつ常体で記載していきます。

フルリモートでドキュメント整備をしているのだが、ドキュメントの検索性が低い。どうしたらいいのか？

• 構造化をしていく。3stepでたどり着けるようにする。将来的にAIで検索できるようになっていくはずなので、markdownなどで構造化することが重要だと思う。Excelは構造化できないので最悪
• READMEやリンク化していくことが重要

気づいたときに気づいた人が構造化していくというのはハードルが高くも感じるのだがどんなことをしていくとよいのか？

• 「ぶっちゃけこの情報って使えないかもしれないですが自分にとってはこれが限界です」くらいの情報も公開することでTruthnessを確保する
• 習慣化が重要。そのためには、やったことが褒められてやっていないことが普通に指摘されるような状況を作り上げていくことが重要だと思っている
• イノベーション理論を参考にする。アーリーアダプターばかりのときはアーリーアダプターをとにかく称賛する。キャズムが訪れたときはインセンティブを充実させる。次にレイトマジョリティを動かす際には同調圧力をかける。最後のラガーはペナルティを与える

ドキュメント作成後のメンテナンスをどのようにやるとよいか？

• 情報更新の必要性を感じた人が更新するようにしている(教えてもらってありがとうをドキュメントで返す)
• Notionのコメント機能を活用する。プルリクみたいな仕組みがあるとより活性化できるな、というのは実感としてある
• 構造化をしてスペースを作る
• クオーターごとに、メンテナンスするタイミングを作った

組織がドキュメント化をスタートするために必要なことは？

• 偉い人を巻き込む
• 草の根的に始めてメリットを啓蒙する

リモートワークにすると帰属意識が高まりにくいと感じているのだがどのようなことをしているのか？

• 一年に一度は全員集まる
• 対面の2週間=リモートの3ヶ月と計算して、コミュニケーション設計している
• チェックインで自己開示する
• 自分が仲間だと受け入れられる実感を作る仕組みを構築する
• 会社が儲かっている状態であることを目指す

会全体を通した感想

話題になっていた本ということもあって、本の内容紹介がメインになるかと思ったのですが、本の内容紹介とはだいぶ異なるスタイルで、良い意味で期待を裏切られました。

Q&Aの1テーマに対する深め方が普段とぜんぜん違うアプローチで面白かったです。
また、れいっちさんのキャラの濃さが想像以上でしたw

*1:明瞭さの欠如によって引き起こされているもの。無意識に他人にあわせてほどほどのパフォーマンスで満足する、人によって情報が異なる...

PMとPMMの良い連携について話そう〜急成長プロダクト Bill Oneとログラスの事例〜に参加してきた

forkwell.connpass.com

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

会の概要

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

近年、国内のSaaS企業で、市場理解や市場開拓、Go-to-Marketの戦略・戦術を強化すべく、「プロダクトマーケティングマネージャー（PMM）」の役割設置が増加しています。 今年7月にはプロダクトマーケティングを専門に取り扱った書籍『LOVED 市場を形づくり製品を定着に導くプロダクトマーケティング』も発売され、その動きはさらに加速しています。 同時に、PMMとプロダクトマネージャー（PM）の職務は隣接し、重なる部分が多いため、PMとPMMの役割の境界や重なりをどうすべきか、という議論が組織内で必ず発生します。 そこに唯一解は存在しませんが、事例とその背景を知ることで、自社で実践する上でのインサイトを見出すことができます。

今回のイベントでは「PMとPMMの良い連携」について、急成長プロダクトの「Bill One」「Loglass」の事例をもとに、PMの視点からディスカッションします。

会の様子

パネルディスカッション「PMとPMMの連携について」

PMM設置の動機

柴野さんは、PMFした後に自分の時間の限界を感じた(プロダクトに向き合う時間が減った)ので自分以外にプロダクトのことを考える人を置くことと、マーケットの進化スピードの牽引(市場の成長速度が速くそこについていきたかった)の2点を目標にして、PMMを設置したということでした。
きっかけとしては、社長がBill Oneプロダクトにアクセルをぐいっと踏み込むことを決めたことが大きかったということです。

浅越さんは、(プロダクトの特性上)提供価値の多様化が進んだのでそこに追従していくことと、組織感の個別最適を防ぐためにPMMを設置したということでした。
また、直接的なきっかけとしては、組織の異なる部門にどんどん人が入っていって、会社がカオスになることが目に見えたタイミングで浅見さんというプロダクトマネージャーの方が動いたことが大きかったということです。

PM/PMMの定義やコラボレーションポイント

柴野さん(SanSan)は、PM = PdM + PMMだと考えているそうで、PdMがソリューション構築、PMMがセールスモデルの構築、課題定義*1や訴求メッセージ*2はPdM, PMM両方がやるという区分けをしているそうです。
また、領域のオーバーラップがある関係上、ざっくばらんな1on1や定型的な会議など、密にコミュニケーションを取るようにしているそうです(イニシアチブはテーマによってどちらかが意識的に持っているとやりやすいと感じる)

浅越さん(ログラス)は、PMMがCS, Marketing, BizDev, Salesを担当し、PdMが開発メンバーの代表として何をなんのために作るのか？を考えるようにしているということです。
また、役割分担はそこまでかつっと分けるようなことはしないようにしているそうで、とはいえその中でなんとなくPMM, PdMどちらがイニシアチブを持つか？を決めるようにしているということでした。(会社の風土としても、他の人の領域でも自分の意見があるときは積極的に意見を出して相互協力していく事例があるので、こういったやり方でうまく回っているというのはあるそうです)
コラボレーションポイントとしては、週次定例をざっくりやってそこで見つけた課題を深ぼるようなことをしているそうです。これに加えて、日常的にもSlackで非同期にやり取りをするようにしているということでした。

Q&A

パネルディスカッションの後は参加者からのQ&Aがありました。
以下、Q&Aの内容を常体かつ箇条書きで記載していきます。

PdMとPMMがそれぞれ存在するからこそ発生した課題はあるのか？

• 正直そこまでない。あるとすれば、目線を最初に揃えるのがなかなか難しいくらい
• 正直ないのだが、起こるだろうなという想像で話すと、一人でやったほうが早かったわと思ってしまうみたいなこともあるのかな？とは思う

新人PMM(まず既存顧客を中心に活動し足元を揃えつつ徐々に活動範囲を広げてセールスマーケ連携でマーケット向き合いに範囲拡大していけたらいいと考えている)にアドバイスがあれば教えてほしい

• 解像度があることが大切なので、ドメイン知識をまず整えるというのは正しいやり方だと考えている
• どこまでいっても意思決定として重要なポジションなのは間違いないので、このやり方でいいと思っている

良いPMMとは？

• PMMは事業を成長させるために何でもやる人だと思う
• PMの資質は大切になってくるので、良いPMなら良いPMMだとは思う
• 最強のなんでもやさん

PMMとPdMの現場介入ってどこまでやっているのか？

• どんどん便利屋になっていくので、一番大切なところはどこなんだっけ？他の人に任さられないんだっけ？というのを考えながらやっていくのが重要だと思う
• 方向性とかピン止めは現場ではなくPMMやPdMがやるイメージ

PMMのKPI/OKRの設定は？

• なかった
• 定量目標/定性目標がぐるぐるするし、組織のビジネス目標と被ることも多いので、同じような課題を持っているビジネス組織と同じように目標調整している気がする
• 1ヶ月くらいの期間で変更しながらやっている

bizDevとPMMの違いは？

• 中長期なことを考えるのがbizDev、PMMは既存事業のことを考える、みたいなイメージで役割を分けている。bizDevは飛び道具的なイメージ。
• 今はbizDevという役割を置いていない

営業チームが機能人になって「開発がまだだから〜」という状況に陥ったことはあるか？その中でどう突破できるかを試行錯誤するか？

• 多少機能不備があることを承知で思い切ってプロダクトバックログを変えたりする
• 機能がないと売れないなら売れにくいところにTargetを突っ込んでいるんじゃないか？という疑問を持ちながら考えることが多い

4Pに近いボールをPMMが持つことでPMMとPdMのバランスが崩れることがあると思うが、なにか情報伝達で気をつけていることはあるのか？

• PMMの意図と意志を中心に確認していくのが重要
• 「伝達する」みたいな意識を持っている状態の先に行って、自然と状態共有している姿を目指している

会全体を通した感想

パネルディスカッションでは、ありがちな話かな？と思ったタイミングでモデレーターの横道さんが深く質問してくれて、事業やフェーズにおける違いや特徴的な戦略がみえたのが非常によかったです。

*1:誰の課題を解決しているのか、Marketの競合分析

*2:意識してプロダクトビジョンやプロダクトサービスを一言で定義する

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

agile-studio.connpass.com

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

会の概要

アジャイル実践者の悩みに関して、アジャイルコーチの天野さん家永さん木下さんが答えていくイベントです。

今回の質問は、「アジャイルしか知らないメンバーと、ウォーターフォールしか知らないメンバーが同じスクラムチームになりました。気を付けることは?」でした。

会の様子

大前提

気をつけることを考えるにあたって、アジャイルなど関係なくここは前提として話をしたいという点が最初に挙げられました。以下の点が挙げられていました。

• HRTの原則
• お互いに支え合っていくという姿勢
• 心理的安全性の担保

アジャイル経験者のほうが多い場合に気をつけること

最初に、コーチをしていて一番多いパターンだという、アジャイル経験者の割合が多いというパターンで気をつけたほうがいいことに関して以下のようなポイントが挙がっていました。

• スクラムマスターをウォーターフォールしか知らないメンバーに任せる
• ウォーターフォールしか知らないメンバーのマインドシフトをチーム全体で育てる

ウォーターフォールしか知らない人のほうが多い場合に気をつけること

次に、ウォーターフォールしか知らない人の割合が多いというパターンで気をつけたほうがいいことに関して以下のようなポイントが挙がっていました。

• 味方になってくれそうな人を少しずつ探す
• まずはチームの3割がアジャイルを知っている状態を目指す
• ペアプロやカンファレンス参加や1on1を実施してチームで仲間を増やしていく
• マネージャーが権威勾配的なふるまいをしないように注意する

ウォーターフォールしか知らない人とアジャイル経験者が半々くらいの場合に気をつけること

続いて、ウォーターフォールしか知らない人とアジャイル経験者が半々くらいの場合に気をつけたほうがいいことに関して話がありました。

ただ、このパターンは至って健全で、そんなに気をつけることはないのでは？(強いて言うなら最初の大前提をより強く意識するなど)という意見が出ていました。

番外編〜アジャイル経験者は多いけれどDo Agileのメンバーばかりの場合に気をつけることは？〜

視聴者からの質問として、アジャイル経験者と言ってもDo Agileなメンバーが多い場合(例えばデイリースクラムをやろうというのだが進捗確認MTGばかりやっているなど)どういうことに気をつけるのか？という質問がありました。

木下さんから、こういった状況の場合、Do Agileと言っても、アジャイルをやっている以上あるタイミングではBe Agileになる瞬間があるので、その際に意識的に褒めるようにすることを気をつけているという話が出ていました。

発注側がウォーターフォールしか知らない人で受注側がアジャイル経験者の場合に気をつけること

続いて、発注側がウォーターフォールしか知らない人で受注側がアジャイル経験者の場合に気をつけることに関して以下のような話がありました。

• 発注側にPOに立ってもらう
• XXというタスクをいつまでに必ずやってください、みたいな期待値の持ち方を防ぐ
• チーム外でもいいので、発注側にアジャイル経験者を入れるようにする

受注側がウォーターフォールしか知らない人で発注側がアジャイル経験者の場合に気をつけること

最後に、受注側がウォーターフォールしか知らない人で発注側がアジャイル経験者の場合に気をつけることに関して以下のような話がありました。

• チームとしての型をまず作る
• POと受注側のコミュニケーション量を増やす

会全体を通した感想

実際に経験したケースや事例を基にしながら、みなさんがそれぞれどのような点を気をつけたり工夫したりしていたのか？が話されていて面白かったです。

個人的には、大前提の部分さえ守られていれば、ウォーターフォールしか知らない人とチーム内のアジャイル経験者の人の割合は、チームがうまく機能するかにそこまで大きな影響を及ぼさないのかな？とは思いました。

An Year of Agile: リーダーになるということに参加してきた

distributed-agile-team.connpass.com

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

会の概要

confengine.com

こちらのプロポーザルにある話をことねさんがしてくれました。

会の様子

ことねさんの1年間

RSGTからスタートし、福岡→新潟→大阪→仙台→三河→ニセコと各地のスクフェスを行脚して濃い一年間を過ごすことができたということできた上に、プライベートでもミカヅキインコを迎えたり仕事でもリーダーを任されたりと大きな変化があった一年間だという話が導入としてありました。

今日は、この仕事でリーダーを任されて試行錯誤した軌跡を話してくれるということでした。

遊撃開発リーダー襲名

まずは会社でことねさんが所属している遊撃開発チーム*1でリーダーを襲名されたときの話がありました。

ことねさんは、リーダーは「どうリードするのか？」が重要だと考えた結果、ことねさんというインターフェースを介して内外からの期待に応えることがリードの一つの方法だと結論を出したということです。
また、チーム外部からの期待とチーム内部からの期待は相反することが多いので、そこをアウフヘーベンしていくことが大切だと考えたそうです。

戦略構築の思考プロセス

上記のように考えたとき、まずはチーム内部チーム外部それぞれの期待を明文化することが重要だと考えたそうで、期待の仲介人としてのリーダーをチーム内部チーム外部の人の視点でそれぞれ以下のようにして定義したそうです。

• チーム外部の期待明瞭化...自分のマネージャー(CTO)ととにかく会話をしまくって、マネージャーが本当に欲しい物を最低限定義する+組織の状態を把握して組織目標にチームの目標を接地する
• チーム内部の期待明瞭化...メンバー個々人が抱えているペインを言語化してもらい、それをチーム化によって解決する方法を模索する。同時にことねさんが抱えていたペインをチームに共有し、チーム化によって解決する

そうしてチームで合意したカルチャーが生まれ、苦手な部分をお互いにカバーし合うことを大切にするようになったそうです。

中長期戦略

ここまでができて、ことねさんは水先案内人としてのリーダーにシフトしたそうで、Fearless Changeで書かれていた内容*2を使ったり、ユーザーストーリーマッピングで共通理解を構築したり、成人発達理論を活用したコミュニケーションをとったりしながら、リーダーとしての活動を行っていったそうです。

こうした活動ができたのは、コミュニティの双方向インタラクションが非常に効いたということで、コミュニティに参加することでフランクに悩みを相談することができたそうです。

こうした活動をした後は擬態化したリーダーになり、以下のようなことを行ったということでした。

• できることはやってくれるイメージを形成するために小さなことをやりまくる
• 早い段階で首を突っ込むことをしまくる
• 面と向かって会話をし続けながら課題の解決まで並走する
• 毎日のふりかえり習慣をつけて悩みを共有する時間を作る
• できたことを素朴に誇る
• 得意なタスクを自分からもらいにいく

こうした取り組みを続けたことで、チームは大きな成果が出るようになり、

• 課題解決件数の増加
• リードタイムの減少
• 待ち時間の減少
• 関わる人同士でのアジリティが向上したようにことねさんが感じるようになった(チーム内外にかかわらず相談ができるようになり、心理的安全性が向上したり、重要な意思決定時期が早くなった)

といった結果を生み出せたということです。

(改めて)ことねさんの変化

RSGTで戦うための大義/武器/仲間を得たことが大きいと最初は思っていたそうですが、今ふりかえってみると、ことねさん的には「戦う」→「向き合う」にシフトできたのが大きい変化だったのかな？と今は思っているそうです。

ことねさんがやってきたことのまとめ

ことねさんがやってきたことのポイントのまとめがありました。

ことねさんは、

• 各方面に向き合って期待の言語化をする
• 期待の差分を埋める方法を探る
• 足がかりは小さくてもいいのでとにかく続ける

を意識してきたことがいい方向への変化に繋がったと思っているそうです。

また、ことねさんは、自分自身をロールプレイングするリーダーだと考えているそうで、ふりかえった結果としてリーダーになっているようなタイプだと思っている話で最後は締めくくられました。

感想戦

大事な前提

今日の発表で話していなかった前提として、「ことねさん自身が無理をしない」ということを何よりも意識していたそうです。(チームから大変に見えるというフィードバックを受けて、方向転換した)

(発表で出てきた)マネージャーとリーダーという言葉の違い

マネージャーはrockyさん(CTO)のことで、ロールの一つとして組織管理をするロールを持っている方だという話がありました。

リーダーはことねさんのことだそうです。(厳密に言うとリーダーも一つのロールなので、rockyさんもロールを持っている)

rockyさんからチームへの期待とことねさんへの期待がそれぞれあったと思うがどうやって聞き分けしたのか？

元々ことねさんがリーダーになる前の前リーダーがrockyさんだったので、rockyさんが元々チームに対して思っていた話とことねさんに対して思っていた話を切り分けて話を聞くようにしたということでした。

gccとegcs

gccは伝統的な開発をしていたそうですが徐々に開発速度が落ちてきてしまい、これに問題意識を抱えたegcsがアグレッシブにパッチを入れていく状態になった結果、egcsがgccに変わってどんどん使われるようになったということです。
その後、gccはegcsのほうが開発がうまくできていることを認め、egcsはgccを継ぐことが決まったということで、組織自体を変えるのは本当に大変なので、良い組織を生み出していく組織になっていくよね、という話でした。

gihyo.jp

アジャイルと人間中心デザインの限界

アジャイルも人間中心デザインも変化をしていくのですが、変化が受動的なものになっており、アジャイルや人間中心デザインが試したいと考えていた「いかに自分たちがジェネレーティブにしていけるか」というのが失われつつあるという話がきょんさんから出ていました。
そのため、もう一度新しい言葉で始めるときがそろそろ来るのではないか？ということです。

関連して、プロアクティブに振る舞って、さらに適切な振る舞うやり方を探しているはずだったのに、いつの間にかただのリアクティブになってるという意見もありました。

会全体を通した感想

ことねさんの一年間の集大成と言えるような発表で、コミュニティとの相互作用を起点にしながら仕事でどのような変化をおこしていったのか？というのが見事に言語化されている発表でした。

感想戦ではきょんさんの質問からここでしかできない話も聞けたりして、講演とセットで贅沢にことねさんの話を楽しめる会でした。

*1:遊撃開発チームは、プロダクトチームが開発にフォーカスできるように非機能開発やバグ修正を行ったりテクニカルサポートやデータ解析を行うチーム

*2:特に小さな成功/ステップバイステップ/ふりかえりの時間/感謝を伝える

「はじめての人類学」読書会 第1回(全3回)に参加してきた

anthropology-starting-with-everyone.connpass.com

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

会の概要

「はじめての人類学」の読書会です。3回に分けて、書籍を読み進めていく予定になっています。

会の様子

会の説明

やすがひらさんから会の説明がありました。

やすがひらさんが人類学の本の読書会をしようと考えた背景や参加スタイルに関しての話がありました。

自己紹介

ラジオ参加ではない方々の自己紹介がありました。
お久しぶりの方が何人かいらっしゃって、勝手に喜んでいました。

感想の書き込み+感想シェアその1

はじめにの部分と1章の部分に関して参加者で感想を書き込み、参加者全員にシェアがありました。

皆さんが書き込んでくれたScrapboxがあるので詳細な内容の紹介は割愛しますが、様々な学問や他の本とのつながりや、実生活や自分の人生と照らし合わせた感想の話が、聞いていて特に面白かったです。

フリーディスカッションその1

タイラーの進化論の画期的なところ

タイラーは、「未開人」は欧米人とは同じ人間として見られていなかった（自分たちより絶対的に劣った何かとみられていた）当時の考え方を、進化の段階の違いはありつつも同じ人間ととらえたところにあるという話がありました。

今聞けばそれはそうだろうという感じはしますが、当時はダーウィンですら未開人を同じ人間として見られなかったという話が出ており、当時の時代から考えるとかなり新しい考え方で、見方を覆すようなものだったようです。
同様に、動物愛護の考え方もこのあたりから出てきているのではないか？というのも出ていました。

徹底的な深い観察

上記で話したような観察は、メキシコで4ヶ月観察をし続けた結果生まれたものだと考えられるということで、一定以上深く見たところで初めてこれまでみえてこなかった繋がりがみえてくるのかもしれないという話がありました

インタビュー技法

ポロッと話したことこそが重要だよねという話から、インタビューよりもインタビューの後の立ち話のほうが重要だという話になりました。

更に発展させたインタビュー技法として、事前にスクリプトを用意して相互に話をするのではなく、問わず語りと呼ばれている技法(ひたすら相手の言いたいことを聞く)や自分の言葉に置き換えずに判断を保留して相手の話をそのまま聞くテクニック*1がインタビュー技法としてあるよね、という話が出ていました。

似たような話として、ユーザーインタビューする際に用意しておいた質問に関して、自分たちがしてほしい答えのようなものを相手に感じ取られてしまう問題もあるよねという経験談も出ていました。

感想の書き込み+感想シェアその2

2章に関して参加者で感想を書き込み、参加者全員にシェアがありました。

人類学に詳しい参加者の方から親族の捉え方や「フロー」をはじめとした補足や、マリノフスキの生き様から刺激を受けてソフトウェア開発をはじめとした仕事の現場に応用しようと考えるアイデアの話、自分がやってきたことに関して言葉が定義されると理解が進むという話は特に面白かったです。

フリーディスカッションその2

予定としてはフリーディスカッションがあったのですが、2章の部分は皆さんシェアする感想の量が多くて、少なめでした笑

嫌悪や不安という感情

嫌悪や不安といった感情は、自分の安全圏にいると感じなくなるもので、異文化に飛び込むと自然と感じるものだという話がありました。

システム思考との関連

学問は、事実を分析、分類する際にもそれを有機的な全体の中に位置づけ、現実の多様な諸面をいくつかの体系に類別しようと努力したうえで、その体系のどれかに事実を組み込むことを目標としているのである

という記載がありましたが、このあたりの理解はラドクリフ=ブラウンを読んだほうがより理解が深まるという意見が出ていました。

ただ本書では触れられていない部分なので、逆になんで意図的に本書で飛ばされているのかが気になる、という話もありました。

母系社会

母系社会と言っても、相続は男性のラインで起きるのが一般的というのが残念ながら実態としてあるらしいという話が出ていました。

参与観察によって失うもの

鋭いインサイトをもたらす一方で、後から結果が追えなくなってしまったり、統計学などで体系化したほうが受け入れられやすい点は参与観察だと得られにくいものだよね、という話がありました。

データサイエンティストとしての経験がある方からも、Whyはデータだけでは得られないので、参与観察とのバランスが重要だという意見も出ていました。

会全体の感想

最後は参加者の皆さんから一言感想がありました。

皆さん充実した仕事を過ごしていたという話が出ていました。

会全体を通した感想

人類学や関連する学問が好きな方々が集まっていたので、熱気が溢れていて素晴らしい読書会でした。
今回は時間帯が遅めだったこともありラジオ参加でしたが、次回は機会があれば話す枠でも参加してみたいなあと思いました。

あと、自己紹介の部分でも書きましたが、久しぶりの方々がお元気そうにしている様子が見れたのも会の本題とは関係ありませんが非常によかったです。

*1:関連する話として、「こういうことですか？」や「なんでですか？」は聞かずに、相手にひたすら教えてほしいんです、という質問をするようになったという話やシステム思考文脈で「なにがそうさせたんですか？」と聞くようになったという話も出ていました

大人のソフトウェアテスト雑談会 #188【LED】に参加してきた

ost-zatu.connpass.com

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

大規模SaaSビジネスと企画力

大規模なSaaSビジネスに携わっていると、企画の経験がなかなかできなくなったり*1立ち上げ〜クローズまでのサイクルの短縮だったりが発生しがちで、結果的にPOとしての能力や企画力といったものはなかなか育たないという話がありました。

そうなるとPOの教育が重要になってくるのですが、教育コンテンツとしての需要は圧倒的にエンジニアのほうがあるので、採算を取るのが難しく、馬田さんのように半分はボランティアみたいな形でないとコンテンツを作るのが難しそうだという話が出ていました。(とはいえ本などを参考に知識の体系化を試みることはできる)

開発現場にいて感じる時代の変化

以前オブジェクト指向が全盛期だった時代やCPUがそこまでよくなかった時代は、設計技術がめちゃくちゃ求められたり、パフォーマンスを出すために必要な知識がめちゃくちゃ求められたりしていたということですが、現在はGitHub Copilotでさくさくコードが書けたりCPUが良くなって連想配列を使ったりすることになんの躊躇もなくなったりして、だいぶ時代が変わったなあというのを感じるそうです。*2

起業

POの教育コンテンツの話を色々としていきましたが、起業家たち全員がそういった教育を十分に受けて膨大な知識をもとになにかを成し遂げたというわけではないので、起業を実際にやってみるのがいいのではないか？という話が出ていました。

また、教育コンテンツの一つとしてエフェクチュエーションが良いのではないか？という話から、偉い人が代々木や六本木に集まって会合して仕事を持ってきてしまうのは雑に言ってしまうとエフェクチュエーションの実践例だという話もありました。

MarkさんとTommyさん

今日は久しぶりにMarkさんがいらっしゃり、Tommyさんと軽妙な会話を繰り広げていました。

まず、MarkさんがTommyさんが働いている会社で話題になっていたという話になり、Markさんの知名度を正直みくびっていたとTommyさんが反省していました。話を聞いたMarkさんからは、神と比較してしまうと知名度が低いのはそれは仕方ないというコメントが返されていきました。

次に、Markさんがドイツをはじめ色々な場所に行ってお金をバーンと使ってしまったことが原因となって、人生の中でもトップクラスに貧乏になってしまったそうで*3、迂闊に人に海外カンファレンスに行くことを勧めにくいなあと思っているという話を聞いていきました。
話を聞いたTommyさんが「ドイツでお金をバーンと使うなんてさすがアウトバーンだな！」と言っていていつもどおり大爆笑をかっさらっていきました。

全体を通した感想

大真面目に教育コンテンツや教育の話をしていたはずなのですが、いつの間にかMarkさん&Tommyさんワールドが最後は繰り広げられていて、面白かったです。

いつもに増して公園感が溢れる葛飾でした。

*1:引き継ぎはされることがあるが、起業家や立ち上げをした人と同じようにリスクを取る経験はできない

*2:プロダクトはそれでも作れるならいいのかなーと思いつつ、この知識学んでいないの？というものもある

*3:あんまりブログに書く話でもない気がするのですが、Markさんからぜひブログに書いてほしいという話があったので書いておきます

LEADING QUALITYを読んだ

www.kadokawa.co.jp

スクフェスニセコで、LEADING QUALITYの翻訳者のMarkさんに出版前の本を読ませていただき、「ちゃんと自分で買って書評ブログ書きますよ！」と言ったので、今日は久しぶりに書評ブログを書いてみようと思います。

本の概要

以下、出版社のページから引用です。

「品質とは何か」「品質をどう測るか」を説明した書籍は山積しているのに「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説したものは皆無である。本書は、それらを解説した画期的な書籍である。

本の内容に関する感想

自分たちがやれることや手が届くことに集中しない

第1章にあるuSwitch社の事例や第2章にあるテストナラティブが悪い方向に向かってしまう場合の例、第8章で評価基準や成長指標をもとに品質保証の活動を考えていく話などから、自分たち(QAの人たち)が得意なテスト技法の適切な選定やテスト戦略の策定にとどまらずにプロダクトに貢献していく話が多く語られているのはとても印象的でした。
自分たちができることにとどまらないこと、もっと言えば本書の範囲を超えてプロダクトに貢献する(例えば品質を上げずにプロダクトの売上に貢献するなど)活動を積極的に行う必要があることが示唆として読み取れて非常によかったです。

さらに、自分たちがやれる範囲を超えて課題を解決したり組織文化を変えていくためにやってみるとよいことや社内政治を適切に行うアイデアなどに関しても書籍の中で言及があり、読者にただ示唆を突きつけるだけではなく、変革のための行動を促す記述があるのも良いなあと感じました。

サマリ(タイトルや項題)と記載内容(具体事例)のGap

サマリ(タイトルや項題)で書かれている内容から受けるイメージと、具体的に語られている内容から受けるイメージでGapがある部分がそこそこありました。

顕著に感じた部分で例を挙げると、3章で説明されている影響力を発揮できるようにするための方法の「エビデンスを用いて品質ナラティブを補強する」は、エビデンスを活用するというよりは小さな成功事例を作る話に思えましたし、「共感を生み出して連携と相互理解を深める」は、共感を生み出すと言うよりはやっていることを透明化したり過度な分業や経験の偏りを是正する方法の一つに感じました。

人によってはサマリと記載内容がドンピシャで合うという人もいると思うのですが、上記で書いたように微妙にイメージにずれが生じる部分もあるので、タイトルやサマリだけつまみ食いして内容のイメージを掴むのではなく、一文一文丁寧に読み解いていったほうが良いかと思いました。(本書はそこまで分厚い本でもありませんし非常に日本語訳も読みやすい本なのでなおさら)

品質という言葉のぶれ

品質という言葉は定義のぶれがあり人によって指す意味が異なるという前提が序章で語られていたり、テスト担当者がイメージする品質が虚栄の評価基準になってしまっていることが往々にしてあることを説明したりしている一方で、

品質がお粗末だったために企業が支払ったコストを合わせると、2017年は約1.7兆ドルと算出されている

という記載が3C(本書における3CはCustomer/Company/Career)と品質が関連する根拠として示されていたり、品質を社内外で認知してもらう目標設定の例として「社内の全員がプロダクトの品質に責任があると感じている」が挙げられていたり、品質という言葉に対して問題提起していることを考えると不自然な記述がいくつかあったのは少し気になりました。

品質という言葉を多用する危険性やテストメトリクスが虚栄の評価基準になりがちな話などが主張されている書籍は自分の観測範囲だと少ないので、主張に対して本の中で一貫性があるとより説得力があっていいなあと思いました。

読書会向きの本

本書が「品質文化」を扱っているということもあるので、社内で読書会をして、本を読みながら考えたことや自分たちの組織で本書で語られているようなアイデアを基に自社の品質文化に関してディスカッションをしてみると盛り上がりそうな本だなあと思いました。
本書の内容的に、リードするのはQAの方々になるのかもしれませんが、ディスカッションの際には幅広いロールの方々が集まるとより面白そうですし、本書のテーマ的にも、多くのロールの方が関心を持ちそうな内容が多そうで、プロダクトに関わる人たちで共通理解を形成する一助になるのかな、と感じました。

例えば、本書のコンセプトの一つである品質ナラティブであれば、自分たちの組織は3タイプのナラティブのうち、特にどのナラティブが自分たちを目標から遠ざけているのか？それぞれのナラティブで何がプロダクトの売上に作用して何はプロダクトの売上を阻害しているのか？などをチームでディスカッションしてみたりすると、面白そうだなあと思いました。

本の翻訳に関する感想

読みやすい文章

全体を通して、めちゃくちゃ読みやすい文章でした。以下のポイントが読みやすいと感じた理由として大きかったのかな、と思います。

• 癖がある日本語がない
• 日本語文法として不自然な文章が全然ない
• 冗長な文章が全然ない
• 表記ゆれがない
• 機械翻訳感がまるでない
• 原文を日本語訳するとちょっと意味がずれてしまいそうな部分や違和感ある日本語になる部分は原文も併記されている

自身も現在は翻訳をしたり、翻訳本のレビューをしたりしているので、原文と見比べることで、翻訳に関する知見も溜まりました。
言葉の言い換えの秀逸さや語彙力の豊富さはやはり読書家であり文章を読んだり書いたりする機会が多いMarkさんだからこそ身についている能力なのかな、と感じました。

訳者まえがき

訳者まえがきでは、本書籍が出版されるまでの過程や出版されるまでの苦悩が垣間見える内容になっており、その中で実名で多数の人々へ丁寧に感謝が述べられているのがMarkさんの素晴らしい人柄を表しているなあと感じました。

また、英語を日本語にして日本語圏の人たちに届ける作業ではなく、原著を尊重しながら一つの新しい作品を作り上げていくのが翻訳なんだという気概のようなものが勝手に感じられる熱量溢れたまえがきでした。

訳注

訳注が文の中に差し込まれている形式に関して議論(読むリズムが邪魔されて読みにくい VS 視線移動が少なくて読みやすい)が起きていましたが、個人的には文の中に差し込まずに章末などにまとめてもらえるとより読みやすかったかなと思いました。

また、訳注の種類として、専門用語の補足をする訳注もあったのですが、個人的な理由で、この訳注はそこまで大きなメリットを感じませんでした。ほとんどの用語が既知の用語だったというのが大きい気もするのですが、メリットをそこまで感じなかった理由としては下記の2点が挙げられるのかな、と推測しています。

• (幅広い概念を取る言葉だと特に)個人的には、そういう意味なんだで終わってしまい理解した気になってしまう可能性がある
• 自分がわからない専門用語の数で今自分がこの本を読んでもよいのか？(もっと前に読む本があるのではないか？)という判断をすることが多いので、補足があるとこの数にブレが出る

ただ、ITやリーンスタートアップなどの基本用語を抑えていない人が読んだ際には、聞いたことがあるけれど意味がよくわかっていない状態の人が読み進めるのを挫折することが少なくなりそうですし、専門用語の正確な意味を探すコストが省けるので、そういった人にとっては文の中に差し込まれている形式&専門用語の説明がある本書の形式のほうが読みやすそうだなあと感じました。

豊富な参考文献

参考文献が非常に豊富な書籍になっていました。

個人的には、(技術書であれば特に)本の参考文献は多ければ多いほど助かると勝手に思っていますが、本書籍では参考文献が多いことは他の本と比較して特に価値が高いと思いました。
本書籍は具体的な技術の話や現場で実装するアイデアなどは、書籍内にはそこまで多く書かれていないため、そこを読者で補填していく必要があるのですが、その際にアイデアの基になったような情報や具体的な話をより詳細に解説している参考文献や訳注や資料集の存在は非常にありがたかったです。

欲を言えば、参考文献や訳注にURLが多い&原著では紹介していない参考文献や訳注が多く存在するということから、電子版も発売してくれるとよりありがたいなあとは思いました。

全体を通して

品質文化という切り口はこれまでの本ではあまりない観点だったので、その切り口だけで語られていて面白かったです。
上記では言及しなかったのですが、テスト自動化に関する記述などは、品質文化という切り口ならではの説明になっていたりして、タイトルだけ見ると知っていると感じそうな内容でも新しい発見をしながら楽しく読むことができました。

上述したように翻訳がすごくよいので読みやすいですし、分量としてもコンパクトなので、ぜひお手に取って皆さん読んでもらい、皆さんの感想を聞ければと思います！