退職エントリ
2017年にインターン生として入社し、7年ほどいた会社を2024年12月31日で退職しました。チラシの裏感覚で、頭の中で思い出したことをツラツラ残しておこうと思います。
Valueを愛していた
もちろん今でも「プロダクト」も「利用して下さるお客様」も「プロダクト成長に貢献する全てのメンバー」も愛していますが、私が最も愛していたのはValueでした。
社内ではいつからかValueが飛び交う事が少なくなり、Valueに感銘を受けて入社した自分にとっては少し寂しいものでしたが、今振り返っても非常に優れたValueであると感じます。Value以外にも、年齢や性別などにかかわらず1人のプロフェッショナルとして期待/評価するという価値観や姿勢も愛していました。自分が入社を決めた理由であり、退職を決めた理由でもあります。
ある時点まで、明確に「文化が組織構造を作る」が体現されていたと思っており、この当時の働き方はValueに則って組織構造や体制はガラリと変わるし、前Qから大きく方向転換し、全社で新しいことにコミットするような出来事などが印象に残っています。コロナ前後からはより分業的になり、体制や評価制度などもカチッとしたことで、世界的な環境変化に早く適応できていた一方でお客様に関係のない仕事が相対的に増えた事を覚えています。これは良い悪いではなく、環境に適応するための意思決定の連続の結果だと思います。私は幸運にも長期間在籍できたので、どのような環境を作るとどのような結果が生まれるのかが身を持って実感できたことは大きな学びでした。
今後、ミッションを実現していく上で個人を超えて集団がどのような活動デザインであればValueを発揮出来るのかや、集団を超えて組織レベルでどのような社会システムであればValueと成果が結びつくのか、など、昨年から今年にかけては本当によく考えていました。退職は個人的な理由なので割愛しますが、この辺りの価値発揮について折り合いがつかなかったのも原因の1つです。
チームを愛していた
紆余曲折あれど、新卒で入社後は組織図上では常に同じチーム(Recommendation Team)に所属していました。チームの立ち上げ期から5年間同じチームで活動していたことになります。通常、どのような規模の会社であってもチームは頻繁にスクラップアンドビルドされることが多いと思います。推薦ドメインのエンジニアとして、5年間一貫して商品推薦やHomeという「お客様が一番に訪れる面」を継続して考え続けられたのはSWEとして大きな財産だと感じています。また、SWEに閉じない観点では、チームが長寿命であることがOutcomeを実現するという観点で紛れもなくハイパフォーマンスであることを身を以て学べたことも大きな財産です。多くの組織は「作業/Projectに合わせてチームを再編成」しますが、「チームに合わせて作業を再編成」することが学術的にも経験的にも再現性を持って成功し続けるために不可欠だと確信しています。
また、チームメンバー組織内での異動こそあれど、最初の1年の過度期を超えてからはチームを辞めて会社を退職したのは私がはじめてでした。(チームの異動後に退職された方は1名いましたが、それでもわずか1名です。) 平均勤続年数が短い業界の中、多くのチームメンバーと長期間共通のコミットメントを発揮し続けられたことや、チームの全メンバーが顧客価値を考えて常日頃から議論していた姿を私はとてもリスペクトしていました。また、Home画面自体の成長が売上に大きく寄与するところまで実現できたことも、全員が成長とお客様への価値提供のために能力向上を惜しまない姿勢が生んだと思っています。過度期はしんどい思い出ばかりでしたが、同じチームに在籍し続けることができて幸福でした。同じ形を守り続けてくれた多くのステークホルダーにもありがとう！と感謝したいです。
学び続けること
他にもエンジニアとして辛かったこととか、仕事をしていて辛かったこと・印象に残っていること様々ありますが、入社後から大きく変わったのが「学習」に対する向き合い方です。
特にインターン時はMLエンジニアとして、MLモデルの論文を色々読んだりモデルの構築に関心がありましたが、MLOpsの仕事を任されてからはソフトウェアとしてそれらを運用していくことに関心が向き、自分の中で方向性が大きく変わったなという事を覚えています。その後はMicroservice化に伴うMigrationや、推薦チームの立ち上げのためにチームで安定したElasticsearchの運用や、ESを乗せるためのk8sの運用など、そもそもMLから関心が離れてSWEの領域により学習労力をかけるようになりました。とはいえ、当時は無気力で、「多くの優れたエキスパートがいる中、軸のない学習内容によって一体何者になれるのだろうか」と鬱屈とした気持ちになっていました。
私にとって転機となったのがチームのスクラムマスターを打診されたことでした。当時はあまりスクラムそのものに良いイメージを持てていなかったし、世間を見ても彼等はprocess czarに感じていました。学習を進めた結果、今度は全く異なる説明責任や必要な能力の違いに困惑し、役割を真に体現するためには一体どれほど努力すれば良いのだろうと途方に暮れた事を覚えています。しかしその後も腐らず学習を続けていたことで科学的な態度で役割に向き合うことが出来ましたし、集団の振る舞いもエンジニアリングの一貫として捉えることが出来ました。今までのバラバラな学習内容が、ある時、実は地続きであり、「点」の学習が「線」や「面」になるのだと実感できた瞬間が訪れたのです。こうした経験の結果、価値創造のためには「学習する領域や内容にはこだわりなんて持たないほうが良い」こと、「内容よりも、学び方や学び続ける姿勢と、学ぶ機会が適切に訪れるように環境を設計する方がより大事」であることが理解できました。この経験は何にも代えがたく、現在の自分の振る舞いを決定づけた出来事で、「学習」に対する向き合い方は今後も大切にしていきたいと思っています。
2024読書リスト
主にビジネス書。スクラムマスターやEM、POなどに対して理解を深めたい人向け。アフィ等なし。
リストは私が今年読破したものかつ平均的におすすめできる本の列挙であり、翻訳や本自体にクセがあったり今回の基準に沿わない本は省略している。おおまかにカテゴライズしており、各カテゴリで優先順位(おすすめ)順に並んでいる。
PO向け
- 決断の本質 プロセス志向の意思決定マネジメント (ウォートン経営戦略シリーズ)
- https://amzn.asia/d/9eBja7d
- 優れたPOには是非読んでいてほしい良書。複数人に推薦した。意思決定の活動そのものに踏み込んだ本で、どのように集団で成功を収めるのかの再現性が高まる。
- プロフェッショナルプロダクトオーナー: プロダクトを効果的にマネジメントする方法
- https://amzn.asia/d/b868nLh
- いままでPOにおすすめできる本がそんなになかったが、ほとんどまともなことが書かれている。部分的に、額面通り受け取って実践すると良くない副作用を及ぼすものがあるので注意深く読むこと。
- スクラムを活用したアジャイルなプロダクト管理: 顧客に愛される製品開発
- https://amzn.asia/d/jjBLASZ
- PO向けで短く良書であるが絶版。
- エフェクチュエーション 優れた起業家が実践する「5つの原則」
- https://amzn.asia/d/eeHjGZ2
- 起業家の意思決定に関する研究から発見されたヒューリスティクスなパタンの総称。概念を知るうえではおすすめ。(別の研究で経験主義的なアプローチの方が優れていることが示されているが…)
EM向け
後述する組織カテゴリと併せてどうぞ。
- サプライチェーンサイエンス
- https://amzn.asia/d/cYpA96B
- 一見「EMとサプライチェーンに何の関連性があるのか？」となるが、「人間の活動が何故そのように振る舞われてしまうのか」が解説されている本。
- 大野耐一の現場経営
- https://amzn.asia/d/cslh9d4
- かなり古い本で、講演の内容を書籍化したような本。語り口調も独特なので読みにくさや分かりにくさがあるかもしれないが、リーン思考に強く関連する。組織の生産性とは何かを考えるきっかけを与えてくれる示唆がある。
- ワインバーグのシステム4部作
- かなり古い本で内容も独特、かつ4部作と膨大なので万人向けではない。が、4部作であるおかげで品質・サイバネティスモデルなどのプロダクト開発ライクな話から観察や人間の認知プロセス(サティアの交流モデル)まで、人間の活動まで広く踏み込まれた良書。
組織
- 学習する組織 ― システム思考で未来を創造する
- https://amzn.asia/d/flBq1Ub
- 概念も含み、EMの方は是非読破していて欲しい。自分自身の振る舞いが変化する。システム思考が書籍の中心である。きちんと咀嚼しながら読み進めると、章ごとに都度学びがあるので読書会などしたい。辞書みたいに分厚い。
- 事実に基づいた経営―なぜ「当たり前」ができないのか?
- https://amzn.asia/d/7gL0Wps
- 事実ではなく思い込みや「半分だけ正しい」理屈によって決断されることの危うさを説明している本。誤った二分法を学ぶきっかけになる。本自体も弁証法的なスタイルで読みやすい。組織内の人間の活動を変えてしまうような意思決定に関わる人は読んでおいた方が良い
- ザ・アドバンテージ: なぜあの会社はブレないのか?
- https://amzn.asia/d/aRelKkA
- 通常、組織の成功要因として賢明さが中心となって説明されるが、健全さの重要性を説いている。透明性の話が中心になる。
- リーンソフトウェア開発と組織改革
- https://amzn.asia/d/8MX4i9t
- 同著者の「リーン開発の本質」を読んでいれば読まなくても良い
ScM向け
- ファシリテーター完全教本: 最強のプロが教える理論・技術・実践のすべて
- https://amzn.asia/d/e1ijHhO
- 昨年末読み、難しすぎてフリーズした。少しずつ咀嚼しながら実践と振り返りを繰り返していく本。
- リーン開発の本質
- https://amzn.asia/d/7ZOLT7Q
- 「リーンソフトウェア開発」を書いた著者の本でソフトウェア開発における7つの無駄と、効果的なリーン思考の適用方法が紹介される。原理原則に触れられるのでおすすめ。
- This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント
- https://amzn.asia/d/1LtKCm7
- リーン思考系の中では手を取りやすく、翻訳も読みやすい。コンセプトを知りたい人にはおすすめ。
- 共に変容するファシリテーション――５つの在り方で場を見極め、10の行動で流れを促す
- https://amzn.asia/d/1eTLIFm
- レベルが高すぎて万人にオススメできない。特に自分には咀嚼に人の支援が必要な本。しかし良書。
- モデレーションなのかファシリテーションなのか
学習
- トヨタ式Ａ３プロセスで仕事改革
- https://amzn.asia/d/fgVCHqA
- 邦題に惹かれないかもしれないが、英題はManaging to Learnで、まさしく学びの活動を正面に捉えた本。マネージャ側の視点とイチメンバーの視点で文字通り本中で並行して進行する。読みにくさに難があるが、今年最も精読した本の1つ。
- わかりやすい省察的実践 実践・学び・研究をつなぐために
- https://amzn.asia/d/3N1GFvb
- 省察的実践や成人学習理論に関する学びがある。特に知識を「単に適用しているだけ」でよいのかという問いは学習とは何かを考えるきっかけになる
- 私たちはどう学んでいるのか ――創発から見る認知の変化 (ちくまプリマー新書)
- https://amzn.asia/d/6Hs0F9g
- 認知科学的な観点から人間がどのように学習をしているのか、その一般向けな解説書
- CEO 最高経営責任者
- https://amzn.asia/d/iCHdnu3
- あえて学習のセッションにおく。あまりCEOと言わず、自分の外部環境が変わったときの振る舞い方として参考にすると良いかも。リアルオプション理論、限定合理性、限界分析などが関連する話。
- コミュニティ・オブ・プラクティス: ナレッジ社会の新たな知識形態の実践
- https://amzn.asia/d/2OVNgHN
- 実践コミュニティを運営する方にとっては抑えておきたい本。
認知負荷を「制限する」組織設計は本当に成果を最大化するのか？
「Navigating Complexity of Cognitive Load in Software Product Development」という本を読んだのでメモ。 learnhow.simplification.works
認知負荷という言葉が浸透して久しいが、この記事では、認知負荷を「制限する」組織設計パタンは従来の組織構造(ピラミッド型、狭い所有権による統治)に迎合したパタンであり、組織レベルで価値提供能力を高めるための課題を解決していないのでは？ という疑問について考察する。
具体的には、認知負荷理論について軽く解説し、本書で示される2種類の組織設計パタン、技術的所有権(狭い所有権)パタンと流動的所有権(広い所有権)パタンについて利点や問題点を解説をする。
背景
LinkedIn上でチームトポロジー(TT)の著者が議論していたのを目にし、気になって投稿や一連のレスバを眺めていた。
このレスバを簡単に概要をまとめると、以下のようなものになる。
- チームトポロジーは認知負荷理論(Cognitive Load Theory、以降CLT)をチームの単位で応用している。
- CLTは「個人の学習」に対して設計されたものであり、これを「チームで働くこと」に対して適用することは議論の余地がある。
TTの著者の方自身もこの投稿はクリックベイトだと非難しつつも、CLTをチームに対して適用する是非については同意していた。
私自身も、TTの実装方法は「チームの認知負荷に合うように責任範囲を制限する」ため、DevOps以前のパラダイムであるAとBの責任(例えば実装と運用)を分割して統治する方法を再実装しているだけなのではないか？ と懐疑的に思っていた。
こうした背景から、TTに代表されるようなCLTや暗黙的にCLTに基づいた組織設計パタンがどのような課題を無意識に生じてしまうかを探求したいと思い読書をした。
注意点として、本書は解説にあたってTTや特定の設計プラクティス名は明記されておらず、あくまで私自身の関心に基づく補足である点を認識してもらいたい。 また、本文中でのTTはあくまで簡単な説明にとどめているので、関心のある方は実際の書籍を参考にしていただきたい。 www.kinokuniya.co.jp
認知負荷について
TT本でも本書でも記述されているが、認知負荷とは大きく分けて3種類のものがある。
- 課題内在性負荷: 問題領域の本質的なタスクに関するもの
- 例: ソフトウェア製品を変更するために必要な努力
- 課題外在性負荷: タスクが実施される環境に関するもの
- 例: ソフトウェア製品で何を変更するかを読み取り理解するために必要な努力
- 学習関連負荷: 学習を進めたり高性能を実現したりするうえで、特別な注意が必要なタスクに関連するもの
- 例: 永続的な知識、専門知識を発展させるために必要な努力
TT本では、課題内在性負荷、課題外在性負荷を下げていくための取り組みが必要で、学習関連負荷に使う余力を持つことが大事という主張である。 本書では、これらの認知的負荷は相互に関連しており、個別の種類のみを対処するのではなく、すべての負荷を最適化する必要があると述べている。例えば、「外在性負荷が高い状態は、ドキュメントや構造化が不十分であるため内在性負荷にも影響を及ぼす」といった具合である。
チームトポロジーにおけるCLTの適用とその懸念
背景の項目でも少し説明したが、TTはソフトウェア開発チームの構造と相互作用に関する設計に焦点を当てている。CLTを組織設計、特にチームに対して適用するアプローチを提案している。 この理由として以下の課題を挙げている。
- 個人の認知負荷に容量があるように、チーム全員の認知容量を超えることは出来ないということ
- 従来型の組織設計においてはチームに責任を与えるときに認知負荷が議論されることはなく、これが無視されることで責任や担当領域が広がりすぎてしまい、結果として自分の仕事に熟達するだけの余裕がなくなったり、担当業務のコンテキストスイッチングに悩まされること
TTでは、このような認知負荷に対してチームが対処可能な範囲を知り、それ以上の責任を負わせないように制限することを提案している。具体的には4つのチームタイプを提示しており、ストリームアラインドチームが中心的な立ち位置となっている。
各チームタイプの組閣目的例:
- ストリームアラインドチーム:
- 特定のバリューストリームに専念し価値を迅速に提供することを目的とする
- イネイブリングチーム:
- ストリームアラインドチームが現時点で持たない必要な能力を獲得することを支援するという目的で発足される(学習関連負荷を軽減させる意図?)
- コンプリケイテッド・サブシステムチーム:
- 特定の複雑なサブシステムを専門に取扱い、ストリームアラインドチームの認知負荷を減らすという目的で発足される(外在性負荷を軽減させる意図?)
- プラットフォームチーム:
- ストリームアラインドチームの自律性を担保するために内部サービスを提供することで、下位サービスの開発を請け負い認知負荷を減らす目的で発足される(外在性負荷を軽減させる意図?)
一方で、興味深いこととして、認知負荷に対する教育心理学の研究は、人間の認知構造や限界を考慮して、より効果的な学習設計を考案することを目指している。これは、私達が出来るor実行する量を制限すべきという考え方とは対極にある。外部に学習を移譲することでチームメンバーの学習機会を制限するのは疑問が残る。
従って、認知負荷を効果的に管理することを目指すことには疑いの余地が無いが、以下の点で懸念があるのではないだろうか。
- チームにCLTを適用するのは議論の余地がある
- 認知負荷を制限するアプローチはチームに必要な学習機会を制限するアプローチでもありCLTの目的に反している
知識の量は認知負荷と関連があるか?
前節に加えて、本書では、前提として脳の容量に限界があることは必ずしも知られてないため(e.g., Highly Superior Autobiographical Memory)、認知負荷に関する「多くのコンポーネント(ドメイン)について知ることが認知過負荷になる」という一般的な推論は誤りである可能性があると述べている。 ソフトウェア開発においての問題はそのコンポーネントの学習(再学習)に掛かる時間であり、認知負荷は人の持つ知識の量そのものとは関係がない。
認知負荷と直接関係があるのはワーキングメモリの量であり、ワーキングメモリの取り扱い方を工夫することが効果的な認知負荷の管理につながると述べている。 ワーキングメモリに関しては、
- エビングハウスの忘却曲線に基づいて情報の長期の活性化が再学習に必要な時間を節約すること
- タスク誘発瞳孔反応は認知負荷と積極的に関連しており、専門化であればあるほどそのタスク誘発瞳孔反応は小さくなること
- ダニエル・カーネマンの「ファスト&スロー」より、システム1の思考とシステム2の思考のうち、学習はシステム2の活動であるため、積極的に学習した知識を再利用することが結果的にワーキングメモリを節約すること などを述べている。これらの点は本書でより詳しく解説されている。
ここまでの内容を踏まえると、ソフトウェア開発において「認知負荷が高い」と呼ばれている状況は、単純に取り扱うドメインの広さや深さが起因するわけではなく、認知負荷が「継続して」高くなる状態が何らかの要因で発生し続けている事に起因しているのではないかと思う。
では、認知負荷を乗り越えるためにどのような組織設計のパタンがあるのか？ というのが次の話。
組織設計パタン1: 技術的所有権(狭い所有権)
このパタンは、お客様への価値提供全体の技術的な一部分について所有権を与えるパタンである。 所有権は、一般に組織におけるルール・ポリシー・命令・または一部の人が持つ責任のこと。 例:
このパタンは、チームは技術的なコンポーネントを深く理解し、かつその所有権を持っているため他のチームの影響を最小限にしたまま簡単に所有物を置き換えたり再編成できる柔軟性を持っている。
本書はこれは一般的な組織パタンで、テイラー主義に根ざしたものであると説明している。すなわち、タスクを小さな単位に分解し、プロセス内の各要素を最適化するものである。テイラー主義は御存知の通り産業労働における日常的かつ反復的な作業の最適化を目指したもので、現代の知的労働とは取り扱うものが本質的に異なる。
にも関わらず、マネジメントに関する慣行に現在も影響を与えており、その影響の1つが狭い所有権をチームに割り当てるといった考え方であると説明している。
TT本では、相対ドメイン複雑度(解こうとしている問題がどれだけ複雑か)によって認知負荷を(大まかに)計測し、認知過負荷(Cognitive Overload)になっている状態を相対的な複雑度として検知可能であるということ。この数値が悪い場合、扱うドメインの種類を制限することを提案している。
言い換えれば、認知負荷を管理するという目的で狭い所有権を持つことを提案している組織設計パタンである。(注意: ドメインにはビジネスドメイン以外にも技術的なドメインも含まれている)
問題点: 組織レベルで価値貢献するための能力が低い
このパタンの問題な点は、組織レベルで価値貢献するための能力が低いという点である。なぜなら、すべてのコンポーネントとバリューストリームが常に同じ優先度を持っているわけではないからである。
例えば、組織が最も重要なものに集中する場合、同時点であまり変更や保守が必要ではないコンポーネントを担当するチームには仕事がない。そして、誰も手持ち無沙汰のチームを許容することはないので、組織レベルでは全てのチームが忙しくなるようにプロジェクトや作業を導入する。
上記は、一見チーム内での認知負荷が低くなるように見えるが、組織の単位ではより複雑になる。
組織の目標はしばしば複数チームでの取り組みが必要になるが、各チームの関与度合いは必ずしも一致するわけではない。
あるチームの作業に依存しているとき、その作業を待つ間、手持ち無沙汰な状態を避けるために無関係なプロジェクトに着手する。これが常態化すると、他のプロジェクトも同様なことが起きるため、結局複数のタスクと優先順位間の両立が求められて認知負荷が増加する。(感覚的には、多くのチームはこのような優先順位付けを放棄し、すべてのプロジェクトを「P1」としているのではないかと思う。)
より現実的には、同時進行のプロジェクトが増え、プロジェクト間でのコンフリクトとチームに対してのリソースへの圧力が高まる。様々な目的を持つ利害関係者との調整作業やそれぞれのロードマップと締切に対処しなければならない。(これはチームのEMやPdMに相当する人が実施しているのではないかと思う。)
チームはこの負荷に対処するためにメンバーを分担することで対処するが、結果としてこれが個人への属人化につながったり、お客様との距離やプロダクトゴールへの関与が弱まることになる。
ある時点で経営層はリソース問題を認知する。各チームは、多くのコンポーネントチームにメンバーが居るにも関わらず、キャパシティが不足していると主張する。
この解決策に経営層はメンバーをチーム間で移動させたり、チームごとにパートタイムのメンバーを割り当てることを行う。結果として、さらに認知負荷が高まる構造になってしまう。
他にも本書では狭い所有権を志向するメンタルモデルとして、
- ダニエル・ピンクの内発的動機付け
- コンウェイの法則
- 技術的な所有権が高品質に寄与する
- 技術的品質 などに対して生じる予想外の副作用を説明している。
TTにおけるストリームアラインドチームを支援するための、先述した残り3つのチームに関する組閣条件や組閣目的を踏まえると、狭い所有権パタンと同じ問題を再発明する構造であると思う。各チームは目的が異なるため、当然ストリームアラインドチームとは異なる優先順位を持つことになる。 各チーム単位ではフロー効率は高まる構造かもしれないが、この視点が組織単位と切り替わると価値提供までのリードタイムは特定チームの能力に依存してしまう。
これは複数のストリームアラインドなチームが存在する場合を仮定しても同じ議論ができると思う。それぞれのチームに対して認知負荷や何らかの理由で所有権の制限がある場合、ある時点では組織の優先順位は一致するかもしれないが、特定のチームに優先順位が偏っていたとき、その他のチームは全体の優先順位を厳守することができないため優先順位を無視して別の仕事を始めることになる。
まとめると、狭い所有権を適用するパタンは、実際のお客様への価値提供の能力も制限されるリスクがあり、関心が分離されることで複雑な組織構造を生んでしまったり、ビジネスニーズと専門知識のバランスを取るためにリソース管理などのマネジメントが必要になる。
組織設計パタン2: 流動的所有権(広い所有権)
一方でこのパタンは、技術的なコンポーネントの変更に制限を設けず、お客様のニーズに直接対処する権限をチームに与える組織設計パタンである。
これは、技術コンポーネントに特定チームの所有権が無い(組織レベルで共同所有権をもつ)ことを意味し、チームに特定の作業が紐づくような境界を取り除くことで、チーム間が疎結合ではなく、密結合な状態を促すものである。
このアプローチはWilson & Corbett in 1983, Firestone in 1985の密結合な構造(組織の様々な部分 e.g., チームやユニット)は、独立した部分が多い疎結合な構造と比較して広範囲にわたる変化への適応能力に優れるという研究結果に基づいており、Meyerson & Martin in 1987ではマネージャが疎結合な組織で変更を計画、予測、制御、実行するのに苦労していることを観察している。 他にも組織の結合に関する文献が本書では記載されているが、この記事中では省略する。
このパタンの利点としては、すべてのチームがお客様への影響を与える必要な資源を管理する責任を負うため、組織レベルで各チームがお客様との距離が近くなることや、真の優先順位を厳守しビジネス価値最大化を図れる点などが挙げられる。
また、チームに対して所有権の紐づかないアプローチは、チームと実作業を紐づけてしまう境界を除外し、サイロ化された知識や不必要な組織的な複雑さ、複雑さに伴う非効率性を回避することが可能になる。 具体的には、構造を密結合化することで以下のようなメンタルモデルを育み、個別最適化を避ける。
- 相互の説明責任: 全員の作業が相互依存することで高い基準を維持する
- 内発的動機: 透明性が保たれることでチームの仕事が他のチームにも見られることで品質の高い仕事をする内発的動機を持つ
- 直接的な調整とアライン: 中間の管理レイヤーではなくチームが直接他チームと調整し、目標や方法をアラインすることでタスクに対してアジリティを持った対応が可能になる
問題点: 共有地の悲劇問題が起きる
このパタンの問題点として、本書中でも複数の要素を考慮出来なければ無法地帯となり、更に過負荷でストレスの多い状況に陥ると説明されている。 一般的に、If everybody is responsible, then nobody is responsible.(誰もが責任を持つなら誰も責任を持たない) と呼ばれているように、共同所有、共同責任による運用は、共有地の悲劇(コモンズの悲劇)という有名な経済学の法則を思い出させる。
共有地の悲劇とは、端的に言えば共同所有は必然的に共有している資源を枯渇させる(品質を低下させる)というもので、今回のケースにおいてはソフトウェアコンポーネントの品質が該当するだろう。 TT本でも、このようなチームはエンジニアリングチームの成熟度が高くない場合、ボーイスカウトルールが徹底されなかったりテストを自動化しなかったりするチームによって技術的負債が積み上がると非難している。
しかし、この共有地の悲劇の問題は、2009年ノーベル経済学賞を受賞したオストロームによって、資源管理の効率性はコミュニティが補完的役割を果たしたときに最も効果的になることを示している。(Ref: コモンズのガバナンス - 株式会社晃洋書房)本書中でも適切な条件が整えば共有資源をチームが責任を負って品質を向上させることが出来ると説明している。 www.koyoshobo.co.jp
その他、共有地の悲劇以外の問題点としては以下のようなものが考えられる。
成功させるための重要な要素
長期間の集中
狭い所有権のパタンは、所有する責任の範囲内でチームの稼働率を高めるために、プロジェクト・タスク間のコンテキストスイッチングが多く認知負荷を高める構造だった。 例:
- 1つの欠陥から別の欠陥へと飛び移る
- 別の観点のフィードバックを待ちながら何か他のことを始める
- ビジョンや戦略の欠如による継続的な優先順位の変更
- 1つのプロジェクトと別のプロジェクトに対して部分的なリソースの割り当て
この組織設計パタンは、全員が流動的にコンポーネントを共同所有しているので、複数のチームが特定の成果に対して長期間集中することを可能にしている。 優れたビジョンと戦略を持ち、取り組むべき大きなニーズや問題を順序立てて整理する組織はチームが特定のニーズや問題に長期間(数週間から数ヶ月)集中する機会を提供する。 この状態はその時点で行われていることに関する専門知識を高め、頻繁に同じドメインに取り組むことで認知負荷を軽減する。
逆にビジョンと戦略の無い組織は、必然的に1つの優先事項から別の優先事項に飛び移る必要があり、かつそれぞれが独自の締切を持つ。 このような状況下では、流動的な組織設計に基づくと頻繁にドメインやコンテキストの切り替えが発生するので各チームで学習が困難になり、許容できない認知過負荷になる。
進化的デザイン
これはソフトウェアがコーディングが開始される前に完全に仕様を定めるのではなく、時間をかけて継続的に進化、改善するプロセスのことを指している。 現代的なソフトウェア開発では当たり前の価値観なので、広く多様な開発組織にアプローチするための補足だと思う。
特筆すべきこととして、共同所有であることで、アーキテクチャは最も関係者にとって抵抗の少ない方法を採用し、既に知っていることを適用することを好むという事がある。 エンジニアが各所有コンポーネント内で独自のアーキテクチャ設計や独自の言語などを導入する動機づけを減らし、より標準化に対する議論が推進され、導入されることで認知負荷や学習の非効率性を軽減する狙いがある。 ただし、全員に単一の技術スタックを求めるべきという意味でも、より良い技術スタックに切り替えることを避けるべきという意味でもない。切り替えは多くの人と調整し、漸進的な改善を推奨している。
価値を生み出す人々と生み出された価値を消費する人々との近さ
要件を「提供する側(PdMや企画職など)」と「提供される側(Engineerなど)」の関係性の話。
提供された要件を意図通り理解するのは認知負荷が高く、文脈や意図、目的を完全に理解すること無く、要件が間違っている疑いがあっても最も可能性の高い解釈を単に実装する。 実際に要件変更は要件が変更されたためではなく、そもそも要件が理解/検証されなかったために発生する事が多く、認知負荷を更に悪化させる。 こういったケースの多くは、意図が悪いからではなく、価値を消費する人と生み出す人々の間で行われる書面の文書を介した引き継ぎの多さに依ると指摘している。
多くの人はチームは製品のディスカバリーに関与せず、デリバリーに集中するべきと仮定するが、結果としてチームは情報を準備する人々、ストーリーやProduct requirement document(PRD)を準備する人、設計を構築する人から遅れて情報を受け取る。この状態は、チームは議論に関与していないために実際のお客様のニーズや問題について推測する必要がある。結果、デリバリー直前やデリバリーの最中に要件の変更を確認し、コンテキストスイッチングや集中の欠如をもたらすことになる。
つまり、チームを(提供する側を介さずに)お客様の課題に近づけるのはドメイン理解、プロダクトゴールやビジョンを深く理解することを意味する。学習心理学の観点からも新しい知識と既存の知識を関連付けることが認知負荷を大幅に軽減する事もわかっており、顧客ドメインを理解することが結果的に問題を理解する労力を減らすことになる。
問題なのは、全体像を理解することには明らかな認知負荷があるということ。これが狭い所有権が認知負荷を減らすという一般的な考え方につながっている。
この点については、チームは様々なドメインの専門家と一緒に時間を過ごして学ぶ必要があることを明言している。
全体像を学習する行為は理解が深まるにつれて時間とともに減少するが、都度意図を理解したり、し損なうことで生じる偽の要件変更の認知負荷よりは問題が少ないと説明している。
プロダクトのディスカバリーとデリバリーは2項対立ではなく、ある時期はデリバリーに傾倒するし、ある時期はディスカバリーに傾倒する状態があり、集団が適切にお客様の理解をする状態を育むことの重要性を説いている。
その他にも重要な要素として以下を提示しているが、今回は割愛する。
- 協力的なリファインメントセッションの実施
- よく考え抜かれたルーチン
- 早期のフィードバック
感想
今回の組織設計パタンは所有権と認知負荷が大きなテーマになっていたが、本書は様々な状況で認知負荷と呼ばれるものが「価値提供の観点で無意味なもの」なのか「学習することで乗り越えるべきもの」なのかが明確になる本だと思う。 特に自分を含む多くの人々は、限られた集団における局所的な最適化を志向しがちだが、実際に組織レベルでどのようなダイナミクスが生まれるのかや、その中のひとりひとりが選択する行動は果たしてどれくらいプロダクト全体にとって価値が生まれるのかを再考するのに価値があると思った。
また、この本はコンポーネントチームとフィーチャーチームの議論を組織レベルに拡張したものであるとも言える。どちらも焦点は「学習」をどのように認識しているかだと思う。本書中にはあまり述べられていないが、採用や評価制度なんかに関しても、「学習」をどう解釈しているかで最適な設計は変わるはず。
学習する組織では「構造が挙動に影響を与える」とも述べられているし、クレイグ・ラーマンの法則では、「組織構造が文化を作る」と述べられていることも踏まえると、私達は組織構造についてもっと理解を深める必要があるし、得たい成果に対して恣意的に構造を決定出来る能力を磨く価値は大きいと思う。 www.kinokuniya.co.jp 同時にどのような構造を選択するとしても、その構造によって生じる副作用には注意する必要がある。副作用には直接的に観測できるものもあれば、顕在化まで時間が掛かるものもある。安易に実装方法に飛びつく前に選択した構造が人々のどのような振る舞いをもたらすのか、繰り返し考えたい。
Retrospective 2023
買ってよかったもの
全般
Hypervolt2 Pro
筋肉を弛緩させることで血行を良くしたり柔軟性を高めてくれるデバイス．筋トレ前に硬い部位に使うと詰まりを抑えてくれたり，単純に肩こりにも使える．
shopetanが買ったものはフラグシップモデルだけど同時に本体重量も重く結構持つのが大変かもしれません．男女ともに軽いモデルをおすすめします．
Hypervolt 2 Pro | ハイパーボルト 2 プロ – Hyperice Japan
本
- 組織行動の心理学: 組織と人の相互作用を科学する (サーベイ論文読んでる感覚に近い．shopetanは辞書的な使い方なので，実感値が伴わないと微妙かも．)
- ラディカル・プロダクト・シンキング イノベーティブなソフトウェア・サービスを生み出す5つのステップ(文化もプロダクトと同じように改善できるという主張で，当時は納得した．)
- アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる(著者のzuziさんがシステムコーチングを推してるのを知ってたのでagileとの関連付け方を知りたくて読んだ．)
- ゾンビスクラムサバイバルガイド: 健全なスクラムへの道(活動のアンチパタンとそれを解決していくプラクティスが多いので導入後のティーチングの文脈で役立つと思う．)
- Leading Beyond Change: A Practical Guide to Evolving Business Agility (変革とか推進などのワードに敏感になる．マインドセットの観点ではすごく良い本だった．)
- プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド(「そうだよね」が大量に書かれてる．)
- クルーシャル・カンバセーション ーー重要な対話のための説得術(相当良い本でした．緊張感の高い対話に始まり意思決定の方法まで言及がされているので，shopetanにとっては読む価値が高かった．続編も読んだ．)
- GitLabに学ぶ 世界最先端のリモート組織のつくりかた(リモート云々よりも行動規範，意思決定方法の定義だったりValueに関する位置づけなど，考え方にGAPが出そうな項目が整理されていて読む価値がある．)
- Your brain at work(いい働き方をするための脳の仕組みの話．物語調なので好みが分かれるかも．)
- STAFF ENGINEER(ここのインタビューなどで推薦されている本を何冊か読んだ．ロールモデルが複数提案されていて進みたい方向がわかるのは良い．)
- Dynamic Reteaming(チームの物理的な変更の話．多様な理由でチームの変更は避けられないという現実的な立場に基づいて書かれている．)
漫画
- 新しい君へ(SFものが好きだったら是非．)
- マチネとソワレ(最初は何見せられてんだ…って思ってたんですが尻上がりに面白くなってる．)
- Thisコミュニケーション(癖が強いが好きな人はきっと好き)
- カテナチオ(主人公が努力全振りしてて，かと言って全然才能があるものとは壁があるって感じで続きが楽しみになる．)
投資/サブスク系
- ジム(多忙になって疎遠．)
- Bizmates(これも多忙になって疎遠．良い先生と話すと学びは多い．)
- A-CSM研修(このトレーナーの方が開催してなければ行こうとすら思わなかったので，心から行けてよかった．詳しく知りたい方は話しましょう．2月もあるみたいなので行ったほうが良いです． https://training.tech-kai.com/tech/user/courses/316)
- ORSC基礎(これは極めて好みが分かれる．コンセプトには共感する一方で理屈とか論理的みたいなところを軽く超えた感情的よりも深いなにかを探るアプローチなので，深淵です．)
個人的なこと
「SWE」としての関心が極めて薄れてきました．エンジニアとしての活動は大変楽しいのですが，より自分が貢献できる領域があるな～というポジティブなモチベーションに起因します．
一方で，年始からスクラムマスターという役割が社内で消え，多くのチームで価値を生まないと認識されてしまった事には心にダメージを受けています．
これは本来の職能としての期待が定義されず適当に運用された*1ことに起因しています．集団を変える打ち手の1つが塞がれ，正攻法が難しくなってしまいました．*2
チームや組織にとっての成果とは何か? 1つ1つの組織の活動は成果にコミットメントしているのか? を分析した時にまだまだ課題が認知されず改善点が多く眠っているなと感じるので，自分が諦めることは決して無いようにしたいですね．
shopetanに今必要なのは政治力なのかも知れません．人は必ずしも正しいことでは動かず，誰の発言かに応じたバイアスも無意識に掛かってしまうので，そういった習性もときに泥臭く活用出来ると良いなと思います．
スクラムマスターをして半年がたった
近況
こんにちは．
表題通りでレコメンデーションチームのスクラムマスターを昨年の6月からやっている．
以前はチームから出向という形で新規チームのTLをやっていたのだが，チームでのMVPが完成してML的な複雑性をほぼ持たないシステムになったのでTLを委譲し，shopetan自身はレコメンデーションチームにカムバックしていた．
shopetan.hatenablog.com
レコメンデーションチームはというと，ここ半年でチームメンバーが精力的に外部登壇や記事を公開している．
昨年の下半期ではチーム史上最高のKPI向上を果たしていて，チームメンバー全員がBe a Proであるが故の成果だが，チームとしてもワークするようになっているのを肌感でも感じている．
codezine.jp
engineering.mercari.com
engineering.mercari.com
ai.mercari.com
近況の共有がてら，SMとしてやってきた事を3つ振り返っておこうと思う．
絶えず「課題に感じたこと」と「どのようなActionを実施するか」のログを残す
チームの状態はシステムとは比べられないほどに有機的なので，ある時点では課題と感じていても，また数日経過したある時点では課題ではなくなる可能性も高い．
これを踏まえて定常的にチームの観察とその時の思考をロギングし課題のリファインメントがいつでも出来るようにしている．
これはSMになった当初から行っている事で，今振り返ると運用やリスクを考慮するSWE的なマインドセットに基づくものなのかもしれない．
SWEとして振る舞っているとSystem Design Docなどを作成する過程で背景や目的，設計方法や代案などをdocumentベースで議論し意思決定をログとして残す事が当たり前になる．
Design Docのメリットは「Docsが必要な時に必要な議論が出来る最小単位」となっていて「Acition実施前に全体考察可能」で「Acitionの精度が高まり手戻りが減る」ことだと思う．
SMとしても「議論をし意思決定のログを残す」というところまでがセットであるべきで，アジャイルコーチやPO,TLなどが含まれる場で情報の共有と議論をするところまでは実施出来ると良いと思う．
これはチームの歴任のSMが共通のdocumentで継続的に議論しており，自分は良い習慣にタダ乗り出来た状態だった．
現在はアジャイルコーチが居なくなってしまったので客観的なFBを得れる機会がなくなってしまった．
議論をする事が減ったのでこれを踏まえてdocumentという体はやめた．
代わりにSMとしてのログは自前のカンバンに残し，気になったタイミングで課題追加 + 適宜優先度順位の見直しを実施してActionの優先順位付けなどを行っている．
documentと比較して検索性が下がって議論のフォーマットとしては不適切だが，今は各メンバーとの1on1内で議論をロギングし，課題は必要なタイミングでカンバンから共有するというスタイルで運用している．
課題を共通のものにする
SMとして課題を考えるとどうしてもSM目線では課題と感じていてもチームメンバーには腑に落ちないことも多々ある．
また，チームメンバー目線でもあるメンバーは課題認知していても別のメンバーは課題と認知しないケースがある．
「課題を課題と認知させぬ間に問題を解決し，気づいたらチームが生産的になっていた/働きやすくなっていた．」を実現できるのが守破離を体得しきったSMだと思うが残念ながら自分はまだそのようなフェーズに居ない．
まずはレトロスペクティブが機能的になるようにコミットメントしようとしていた．
当時のチームに対するSMとしての認知は，
- チームメンバーは起きた課題が対処できる
- 課題として共有され，共通化されれば対処のActuionが取れる
- 日々の問題を認知し修正する力はあるが，長い間，チームのプロセスや価値観などを議論してきていない
- プロセスの改善にフォーカスされない(課題の認知化が進んでいないor課題に気づけない)
1actionで解決出来る問題ではない事が明らかなので，昨年度は個別対処をメイン戦略として取った．
下記のものを実施した．
結論から言うと上記の状態から解決はしていない．経験を積んだだけの状態で，実力不足でプロセス改善の習慣化まで至っていない．
実施したフレーム自体は価値の高いものであるが何れもボトルネックがあり持続可能性に乏しいので，メリットとデメリットを理解して実施するべし．
現在はチームの現状に向き合った習慣変容と，Visionに基づく習慣変容の2軸で施策を実施している．これらもいずれ紹介したい．
1on1に基づきメンバーのpainをまとめたpain sheetの共有
needs, pain, solutionからなるシートで，1on1でチームメンバーの現状のpainを収集し，needsとして共通化，対処案などをまとめたもの．
特にSM就任初期に1on1で課題収集と言語化を進めて匿名化したものをメンバーに共有した．
Good
- チームメンバーが感じていた問題が一覧化出来る
- 他メンバーが課題に感じていなかったとしても共有が進む
Bad
- 1on1から共有まで莫大な時間がかかる
- 無数の課題が共有されるので関心が持たれない
- 優先度が分からない(個別に収集した故にフラットになってしまいActionを取りにくい)
Agile wheelのワークショップによるチームメンバー間の価値観の共有
Agile wheelについては下記の記事が詳しい．
一言で言うならチームメンバーがそれぞれ12項目について現状となりたい姿の評価を主観で行い，GAPなどを可視化する方法である．
dev.classmethod.jp
Good
- チームメンバーがそれぞれの項目に関する価値観を共有する機会になる
- チームで大まかな課題解決の優先順位付けが可能になる
- 複数のGAPを知ることが出来る
具体的には下記
- チームメンバー間のGAP
- 現状となりたい姿へのGAP
- (継続的に実施出来る場合)過去の評価と現状のGAP
Bad
- 準備に多少の時間がかかる
- 解釈が一意に決まらない，基準が主観によるものなので評価自体の正確性は少ない
happiness radarのワークショップによる開発プロセスに対する課題感の共有
表のフォーマットに対して一方の軸を感情(晴れ/曇り/雨)，もう一方の軸を開発プロセス(Planning/Implementation/Release/Operation)としてチームの現状を評価してもらう．
下記のリンクではVote式になっているが，実施時は具体的な出来事やプロセスを各セルごとに記入してもらうようにした．
www.funretrospectives.com
Good
- 振り返るコンテキストをプロセスに集中できる
- 感情が軸に含まれる
感情を共有するのは通常の振り返りだと難しく，事象と結びつけて共有するのも同様に難しく，ツールで共有しやすい体が作れるのがメリットだと思う．
Bad
- 項目が大きく話が分散する
- コンテキストが絞られているがゆえに実施が適切なタイミングでないと関心にムラが生まれる
ワークショップに対する振り返りの実施
Agile wheel時やその他のレクチャー時に実施した．振り返りはチームが通常行っているフォーマット(START/STOP/CONTINUE/FEEL)で行った．
ワークショップ自体の価値があったか，プロセスが改善できるか，何に注力したいかなどを最終的に共通化出来る．
Good
- チームとしてフォーカスしたいところが言語化される
- 慣れたフォーマットなので実施コストが低い
- SMとしてのFBとして利用できる
Bad
- 全体を通して実施時間が長くなりがち
- 振り返りの振り返りになるので疲労する
日々の習慣を愛する(経験の可視化)
1年の最後に上記のログに基づいた，チームが積んだ経験の可視化を行い共有した．
フォーマットとしては，下記のようなものを盛り込んだ．
- 四半期ごとに各Scrum eventとそのGood/Badをまとめて共有
- Scrum event外の当時の課題と現在の状況の共有
- チーム自体の変遷(e.g. メンバー異動や体制変更)
- Q単位のチームの成果を祝う
昨年読んだ本で好きなエッセイがあり「チームに成長してもらうためのリーダーシップ」という章の中で「成長の可視化を手助けする」というものがある．
www.oreilly.co.jp
SWEとして働いていると，日々の活動がイテレーティブ型の開発スタイルになり，目の前の解くべき課題と成果として還元するための方法にコミットし続けることになる．
このような状況下では短期的な視点に集中しがちで，日々のイベントの中で行う「検査」と「適応」がその後のチームの習慣にどのような影響を与えているか実感できない．
上記の問題点から習慣は雪だるま式に積み重なってチームに良い影響を与えているということと，その裏では開発チームのメンバーを含む色々な人がチームの成長に貢献しているということを可視化することで，チームとしての成長を実感出来るようにした．
これが実際に期待する効果を生んでるか測定するのは難しい．
個人的には，効果以前の話で，product開発の現場では当たり前のようにQや半期単位で目標設定とその振り返りが成されているはず．チームに対しても当たり前に還元されるべき情報だと思う．
自分たちがどこに向かっているのか，向き先は正しそうか，大きなゴールに向けてチームが検査と適応の経過を振り返るためにも今後も提供し続けたいと思う．
「お前は何も覚えていないのよ――阿良々木。自分が何でできているかを知らないの」
まとめ
実施してきたトピックはスクラムの三本柱である「透明性」「検査」「適応」の何れかの思想に基づいている．
自分の振る舞いに落とし込むと以下のようになる．
- 透明性: 正しい情報をロギングしてSMとして次の行動が起こせる状態
- 検査: 現在の目的と，現状が明確化されていて，GAPを把握可能な状態
- 適応: GAPを把握した上で目標に近づくアクションを起こしている状態
そもそも自分はSMをやる気は全くなくて，どちらかといえば強烈に反発していた側の人間だった．*1
だが「人間の集合(チームや組織)をシステムやプロダクトとみなしてビジョンの実現確率を高めるロールである」と解釈できるようになってから随分マインドセットがましになった．
今の組織は兼業しか認めておらず，自分は50%の割合でSWEもやらざるを得ないのだが，兼業メリットは皆無であることも実感値としてよく理解した．*2
次は価値を認めてもらって，組織を変えなければならないフェーズなので今年も気を引き締めてやっていこうと思う．
Retrospective 2022
久しぶりに書く(仕事の事は別で書こうかな)
shopetan.hatenablog.com
買ってよかったもの
本
自分の中で打率が低い年だった…
漫画
- アオアシ(去年から通読してるけどずっと最高なので読んで)
- デッドデッドデーモンズデデデデデストラクション(最終巻も最高だった)
仕事
- LeanとDevOpsの科学(SMを任せられてから読んだ みんながこの手の指標が好きな理由は分かった)
- チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで(自分たちは何者なのかがﾁｮｯﾄﾜｶﾙ)
- Clean Agile 基本に立ち戻れ(「勇気」を「合理的なリスクを取ること」と表現している 自分の中の価値観と完全一致してて良かった)
- エラスティックリーダーシップ ―自己組織化チームの育て方(知識を得るためだけなら前半だけ読めばいい)
英語
- 英語のハノン 初級 ――スピーキングのためのやりなおし英文法スーパードリル(2022年ベストバイ 愚直にこれだけやってれば良い)
- 基本文法から学ぶ 英語リーディング教本(文法事項をまったく勉強してこなかったので単に楽しい)
- 英文表現力を豊かにする例解和文英訳教本 公式運用編(まだ全然進んでない，writingがある程度出来る程度の文法力を獲得したい)
その他
- なめらかな社会とその敵: PICSY・分人民主主義・構成的社会契約論(通して難解だけど分人民主主義の項目はかなり好きな価値観だった)
- ネガティブ・ケイパビリティ 答えの出ない事態に耐える力(概念だけ知ってればいいかも 流し読み向け)
投資/サブスク系
サブスクは前回と変わらない
- パーソナルジム(コロナで数年ぶりに再開した & 人生の中の健康の優先度を上げるために)
- CSM研修(過去参加経験のある方がトレーナーのebackyさんに直談判してくれて開催して頂いた．参加費用がマジで一瞬でペイした．会社ありがとう．【オンライン開催】Certified ScrumMaster®2022/11/28 - 12/02 2022/11/28 - 12/02｜オッドイー)
- ABBYY Fine Reader(自炊業者で自炊 -> PDFをこれでOCRかけて全文検索 + コピペでAnkiにimportのサイクル)
- 物書堂の辞書(クリップボードにコピーすると自動で辞書を引いてくれる．めっちゃ楽しい．)
- ChatGPT(無課金だけど課金制になったらノータイム課金するつもり．これで英単語やフレーズの使用頻度を聞いたり，書き言葉話し言葉の有無を聞いたりすると脳内マッピングが捗る．)
音楽
好きなアルバム
相変わらず昔のばっかり聴いてる．
- 夜に魔法をかけられて / indigo la End(夜に聴きたい1)
- 渚にて / indigo la End(夜に聴きたい2)
- strobo / Vaundy(夜に聴きたい3)
- ソルファ / ASIAN KUNG-FU GENERATION(ラストシーンすこ)
- I loved you / 柿崎ユウタ(年の瀬に知ってしまった…めちゃよい)
リピート率順
- 春は溶けて / indigo la End
- 終点の先が在るとするならば。 / ツユ
- Enemy(with JID) / イマジン・ドラゴンズ
- 言って。 / ヨルシカ
- 黄色 / back number
- Cleric Beast / bloodborne サウンドトラック
- 花弁 / クレナズム
- 人生の針 / ゲスの極み乙女
- 東京フラッシュ / Vaundy
- 桃源郷とタクシー / Mega Shinnosuke
ライブ
- indigo la End(特に武道館が最高だった．普通に泣いてしまった．)
- ヨルシカ
プライベート
9月くらいからフラッシュカードアプリのAnkiを始めて，2000カードくらいは覚えた計算になる．基本サイクルは単語帳の単語を電子化しOCRで読み込み -> Ankiにインポート．英語のハノンも毎日1ドリル + 復習をAnkiで管理していて平均30分から1時間程度コンスタントにやってる．文法事項別にサーチアンドデストロイやってる感じ．
単語は金フレを終わらせて現在はDUOを投入しながら50%くらいの進捗率．他の本のドリルもやったりすると3時間以上平気でやってたので夏を境にゲームが全然できなくなった…
最近は意思疎通や正しいことを正しく伝える必要性が高く，英語が喋れないと明確に実害があるのでしばらくは継続予定．
あと最近あってない人とご飯行くのはやっぱりいいなと思ったので，大学以来会ってないみなさんもご飯行きましょう．では良いお年を．
クロスファンクショナルなチームでTLをして半年が経った
最近何してたの?
題目通りで，PO, PM, Branding team, Backend team, Client team, ML team, Scrum masterから成るチームのTLをしてた．直近だとコンテンツマーケティングに関わる方とも協業している．
どんな機能を作ってたかとか，何がどうなるみたいな話は当然ここでは出来ないので，ツラツラと気持ちの棚卸しをしたいと思う．
クロスファンクショナルとは
一般には「課題解決のために特定の役職にとらわれず必要なメンバーを集めて構成されるチームであること」だと思うし，ここでも同義として扱う．
今の社は基本的にどの部署も特定ドメイン単位で分割されているので，そのドメインでTLをすると言うことは必然的にクロスファンクショナルなチームでTLをすると言う事とほとんど同義になっている．
TLとは
特にこの言語定義は人によって異なると思うので予め自分自身が想定する単語とその認識をメモしておく．
個人的に解釈するのであれば ある特定の技術領域(任意の機能でもPlatformでも可)に関して，技術を駆使しオーナーシップを持って働ける人 だと思っていて，例えば「"その時々にあった正しいアーキテクチャの設計" ができ，"コードの品質管理" や "チームの生産性にコミットできる" のがTLである」と言うような表現は狭義的で好きではない．
オーナーシップを持つと言うところが大事で，それは当然技術的な意思決定に対してでも，メンバーとのコミュニケーションに対してでも適用されると思ってる．
これは特定の職位では無く役割，振る舞いの一つだと思うので，定義に則りオーナーシップを持って働くために必要なのであれば何でもすべきだと思う．
お気持ちまとめ
人が多いと大変
当たり前である．
当たり前なのだけど，大きなサービスになればなるほど一つの機能追加や実験がその関係者だけに閉じる現象はほぼ起きないと思っているので，「大変さ」についてもう少し要素分解したいと思う．
「人が多いと大変」に感じる理由は大きく分けると2つで「個々人がそれぞれ意思(意見)を持っている」ことと「ポジショントークが発生する」ことだと思う．
個々人がそれぞれ意思(意見)を持っている
何か1つの機能を作るのだとしてもその人ごとに「現時点で持っている解像度」や「今後将来にわたる展望」があるので今回のような複数の人たちがいたらまとまらない．
ただ，そこの事実を認識しているのであれば，大切なことは「その解像度と展望の擦り合わせ」である．
したがって，擦り合わせに非常に多くの時間を投資するのが大変と言う結論になる．時間がかかるものは大変なのでそれはそう．
ただし，TLであるならば，認識を共通化することが出来ないと別の誰かが同じ立場でTLを担う時にまともにワークできない可能性がある．
この投資は大事だと思うし，全てのメンバーが場合によってはTLを任されてもいいような状態になっている事を目指すのがオーナーシップを持っている状態だと考える．大変だ．
ポジショントークが発生する
これは先述した項目と要素が従属しているかもしれないが，大事なので書く．自分はこの点に関して楽観的に見積もりすぎていて後悔している．
組織に属する以上，何かしらの役職を持っているはずなのでポジショントークが発生することは仕方がない．
ポジショントークとうまく向き合うためには，その人の思惑を引き出し切ることでしか対処不可能だと学んだ．
こういったトークで必要なのは「新たに何かを提案する」のではなく「その人と交渉すること」なので，いかに相手の立場を理解し，いかに共感するように振る舞えるか，そしていかに受け入れてもらえるかだった．
例えば，技術的な「アーキテクチャの正しさ(質)」と「実装スピード」は一見短期的にはトレードオフに見える*1ため，PMと言うポジションから同じ物事を見た時には早く機能をリリースしたいと言うモチベーションが高まるのは当然なので，その共感をした上で説明をしないとお互い終わらないプライドバトルになってしまう．
オーナーシップを発揮するためにはこのような政治レイヤーまで介入していかないといけなかった．大変だ．
コンテキストスイッチの切り替えが大変
先述したTLとして振舞っているとあらゆる連絡が飛んでくる．
基本的な機能開発に関してのレビュー依頼やディスカッションはもちろんのこと，関連する他チームとのやりとり，長期的なロードマップへの雑談，各ポジションのメンバーからの要望，スケジュールの進退，突発的に発生した問題の対処，開発チーム内でのファシリテート…などなど．
「技術のみの連絡窓口」という振る舞いをすることも可能だったが，それは決して私の考えるTLではなかったので私に頼るべきと判断してくれたメンバーをリスペクトし真摯に対応した．
その結果として発生したのは過剰なコンテキストスイッチの切り替えとそれに伴う記憶喪失であった．
一日仕事して，次の日になると昨日何をやったのか忘れる．それが３ヶ月くらい続いた．もちろん仕事をしているので進捗自体は当然あるのだが，思い出すのに時間がかかる．
あらゆる人とあらゆるコンテンツについて常時議論をしているせいで，自分がその間にどのタスクを葬ったのか忘れてしまうのだった．
余談だが，よりハイコンテクストな領域にオーナーシップを持っている方達と定期的にディスカッションしていると「これなんの話だっけ?」みたいな事を聞かれるのが時たまあり，「この人の事信頼していいのか？」と思っていた時期もあったが，彼ら/彼女らは過剰なコンテキストスイッチの切り替えを行い続けなければならず，自分自身で記憶し続けるのが難しいのだと悟った．
これを防ぐために，付け焼き刃だがカンバンのチケットの大半を管理し常に最新の状態に遷移させる事で記憶を忘れても良い状態を作る事を心がけた．
他に提案してもらった方法として，Evilな方法であるが他者の外部記憶を利用することも方法として存在する事を知った．「他者に内容を伝えていれば自分が忘れていても必要なタイミングで再度連絡が来るため，結果存分に忘れられる」といった具合に．
何れにせよ，抽象領域が広くなればなるほど，(例えば実コードレイヤーのような)特定の事象にDeep diveするとその後別の事象にDiveするのがしんどくなるし，次々と忘れていくので記憶/記録方法に関しては学んだ方が良い分野だと感じた．大変だ．
まとめ
組織で目に見えたインパクトを出す仕事をするには政治レイヤーをやるのが当然大事で，その何をすべきなのかが分からない状態が分かるようになったのは経験として大きかった．
それから，「技術的に成長できるか否か」と「プロダクトとして貢献する」事には相関関係が全くないので，あくまでTLとして振る舞う割切りが大事だと思う．
振る舞いができないのであればメンバーが疲弊するので引き受けるべきではないし，仮に引き受けてしまっても振る舞いの話なので別の人に移譲できる状態であれば降りて良いと思った．
また，今回の件も自分と同じ境遇になる人はほとんど居ないと思うので，その人なりに役割を解釈して働けると良いと思った．サラリーマンは大変．皆様もご自愛ください．
