らんどなテックブログ

エンジニアのいろいろ

【書評】新1分間マネジャー

読んだ。良かったので感想。

Amazon.co.jp: 新1分間マネジャー eBook : ケン・ブランチャード, スペンサー・ジョンソン, 金井 壽宏, 田辺 希久子: 本

雑感

マネージャーとしてメンバーとコミュニケーションする際に意識するべき事が具体的に挙げられていた。 1on1 をやる時など、細かいところで真似してみようと思える点が多々あった。

気に入ったフレーズ

第2章

  • 何を目標とするか、優れたパフォーマンスとは何か、を自身もチームも理解している状態を作ることが優れたマネージャーには必要
  • マネージャーがやるべきなのは「正しいやり方をしているところ」を見つけること
  • メンバーが称賛を自ら勝ち取ったと思いそれが自信になる、それが重要
  • マネージャーはミスを指摘したあと時間をおく、この時間でメンバーは自分のミスやその影響についてきちんと思考することになる
  • 1分間修正はなるべく早く行う

第3章

  • 目標と現状が一致しているかを考える
  • 称賛には根拠と、心からのものであるかが重要
  • 最初は、メンバーが「概ね正しい」ということを受け入れる
  • 最初は1分間称賛をするべき対象がないか常に注意しておく
  • 目的は自信をつけさせること、だから1分間修正の後半では必ず褒めることが重要
  • 最初に厳しく、後半にやさしく、という順番

第4章

  • 自分をさらけ出し、どんなマネージャーであるかをきちんと伝えること、自分も間違えることがある人間であること、それらをまず認めること

【書評】エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

会社で議論を進めていく上で、「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」を改めて目を通そうということになった。 もちろん書籍は知っていたが、恥ずかしながらきっちり読み切ったことがなかった。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

気になったフレーズ

Chapter 1

  • 曖昧さを減らし、具体性や明確さを増やしていくことがエンジニアリング(が成すべき事)
  • 本質的に分からないのは未来と他人
  • どんなに自分が正解だと思ってもそれは本人の認識においての話であり、他人(の認識)においては正解とは限らない
  • 自分や他人がどんなときに論理的でなくなるのかを知っておく、それが論理的思考の盲点を知るという考え方
  • 怒りを知るとは、自分にとって大事なもの、自分を構成するもの、その延長にあるもの、を知ること
  • 怒りとは悲しみであり、その感情を伝えることが大事であり、正当性だけで相手を変えることはできない
  • 相手の感情(やる気など)といったコントロールできないものを制御するのではなく、仕事に対する行動を観察してよりよい行動に変わるよう導くべき

Chapter 2

  • 人は無意識に思考の範囲を狭めてしまう、それはその閉じた世界が心地よいから
  • 悩むとは何をすべきか分からないこと。これを明確にすれば考えるフェーズに進める。ここに導くのがメンターの仕事
  • 相手に共感し、相手の思考を可視化し、相手の盲点を探索する。そうして相手の思考に余力を作るのがメンターの仕事
  • メンターは意図的に自己開示を行い、フィードバックを受けやすい状態を作る必要がある

Chapter 4

  • ベロシティの悪いチームを外から改善しようとするのは間違い、当人たちが問題に気づくようにメンタリングするべき
  • 分からないものをどうやって分かるべきか、分かったら何ができるのか、それらを自発的にできるようになるのが自己組織化された状態

Chapter 5

  • 権限が明示的でない状態は最も不自由な状態
  • 技術的負債は新たな機能があるときに現状との差分として始めて存在する概念
  • 技術的負債という考えは、エンジニアチームと経営者のコミュニケーション齟齬を表現する必要性から生まれた
  • 例えばエンジニアチームが社内 SIer のように振る舞うのは一見合理的にも見えるが、本来内製化で避けられるコミュニケーションコストを再度抱えることになってしまう
  • ビジネスが進行すると専門チームを作り知の深化に向かいがちだが、これはイノベーションを起こす力が弱まるリスクがある

感想

いくつかマネジメントの本を読んでいれば知っている概念はあるが、それらを理論づけてまとめてくれている。 特に Chapter 1、2 の理論寄りの章は気になる記述が多く良かったと思う。

以前読んだときに読みにくかった記憶があったが、ある程度の理論や実践を経たいま読み直せたのはちょうど良かったと思う。 業務としてはチームと組織それぞれの観点を持ちながらビルディングを行うフェーズと認識しており、その観点では Chapter 3 のアジャイルや Chapter 5 の権限委譲の観点がとっかかりになるのでは、と感じた。

【書評】ゼロから学べる! ファシリテーション超技術

最近ミーティングを仕切ることがちょっと増えたので1冊読んでみた。

本格的な議論に慣れてない、あるいはそこまで顔なじみでないメンバーとのミーティング向けかなという印象で、自分にぴったりという本ではなかった。 ただ要所要所で参考にしたい記述があった。

ゼロから学べる! ファシリテーション超技術 | 園部浩司 | ビジネス・経済 | Kindleストア | Amazon

なるほど、となったところ

  • アジェンダはあらかじめ考えておく、どういう流れでどういう時間配分をするかを決めておく
  • まず現状の不満、次にあるべき姿を洗い出す。その差に注目すれば課題が見えてくる
  • アウトプットはそこに対する問いで決まる、それを考え導くのがファシリテーターの責任
  • KJ 法では7〜10くらいのカテゴリ分けが望ましく、そうならない場合は整理の基準を見直す(議題が複雑すぎる、とかではなくやり方次第で解決できる)
  • 課題の整理と課題の議論は時間を分ける

分かっているつもりだけど自戒

  • 仮に積極性が薄いなら、会議に自然と参加しやすい仕組みを作る(みんなで付箋を出す、とか)
  • 納得感を作るには意見を聞いてもらえたと思ってもらうことが大事
  • 聞いてもらえる、という信頼感が大事

【書評】チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計

最近はチームビルディング周りに興味津々なのと、タイムラインでよく見かけることもあって読んだ。

気づきメモ

  • 認知負荷:人が把握できる量には限界がある→チームの守備範囲が広がりすぎると認知負荷が上がりパフォーマンスが落ちてしまう
  • 全員が全チャットを見る、全ミーティングに出る、みたいなことが起きているなら組織設計に問題がある
  • 組織の関係を考慮せずにツールを統一する、ということがあってはならない 管理や評価の都合で組織再編を
  • 繰り返すのは悪手→業務を通して必要なコミュニケーションに基づいて組織は設計されるべき
  • 新メンバーがこれまでのやり方や視点との違いを受け入れるには感情的な負担がある(これはタックマンモデルの混乱期のこと

適切な境界

  • 3種類の認知負荷がある、1. 2. を早期に解消することで 3. にフォーカスできるように整えていく
    1. 課題内在性負荷:本質的な負荷(実装における課題など
    2. 課題外在性負荷:環境の負荷(デプロイ方法など
    3. 学習関連負荷:学習する上での負荷
  • 認知負荷を抑制するためにチームが扱うシステムをや範囲を小さくする(分割と分担)
  • 事例:あえてリードを無くし、チーム全体で判断させることでモチベーション向上が起きる
  • Spotify モデルにおけるギルドのようなコミュニケーションが自然発生しやすい環境があることで、本来のチームにおけるコミュニケーションの練習が行われる

チームの分類

チーム 概要 詳細
ストリームアラインドチーム エンドツーエンドで開発を行う プロダクトや機能単位ではなく、ストリーム全体に沿うというあり方が必要になってきている
イネイブリングチーム 特定ドメインスペシャリストチーム ストリームアラインドチームが直面する課題解決を補佐する
コンプリケイテッド・サブシステムチーム 保守が必要な特定パーツやシステムのスペシャリストチーム ストリームアラインドチームの認知負荷を下げるために特定ドメインの開発に責任を持つ
プラットフォームチーム 下位の内部サービスを提供する 例えばサーバインスタンスの構築やセキュリティなどを管轄するサービスを提供する
  • 同一のチーム内で設計から開発、テスト、デプロイ、運用ができるべきである
    • DevOps
    • 複雑なドメインの課題解決には開発者が全体を通して関わる必要があるため
    • →ストリームアラインドチーム
      • その分、認知負荷を押さえるためにドメインを小さくしたり複雑さを下げる考慮も必要
  • イネイブリングチームは能力向上が目的であり、短期の密接なコラボレーションを前提とする
  • 技術視点のみで分割すると、透明性が下がりコミュニケーションが遅くなりリスクがある

チーム間インタラクションの分類

インタラクション 概要
コラボレーション 他チームと密に連携する
X-as-a-Service 依存を最小限にして何かの機能を利用する
ファシリテーター 特定課題を解決するための支援や補佐
  • インタラクションをあらかじめ形式化することで、チーム間で期待されるインターフェースを明確にできる
  • コラボレーションは認知負荷が高くコミュニケーションが大量になる、その代わり素早く課題を解決する上で大きな推進力を得られる
  • 約束理論:強制ではなく、セマンティックバージョニングの各数値が示すような約束事によって成り立つ関係性
  • チームやインタラクションは固定すべきでない、自分たちの今の目的は何か?期待される速度は?を常に考えチームに反映する必要がある
  • 特定のワークフローは特定の個人に割り当てられがちだが、分かっているのは誰かを軸に計画を設計すると作業フロー全体に悪影響がある
  • 理想を言えばチームから見た外部依存を減らしたい、たとえば QA チームを作るとそこがサイロ化し、すべてのチームが QA チームを待たなければいけない状況になりがち

感想

ストリームアラインドチームという形で責任範囲を一気通貫させつつ、認知負荷を下げるというのが最初よく分からなかった。 おそらく、その分だけドメインを限定する(ストリームアラインドチームとしての責務定義)、技術領域を分割する(コンプリケイテッド・サブシステムチームへの委譲)ことを意識すべし、ということだと理解した。

インタラクションを命名するという考えは初めてだったが、それによりチーム同士の期待値(インターフェース)を明確にするというのは腑に落ちた。 現職でチームビルディングを考える際も、最低限相互に何を期待するか、どんな情報を同期するのか、という点を重視しながら検討を行っているため、ここに繋がるものを感じた。

QA チームの例は前職でも非常に感じたことだが、一方で各チームにアサインするほどメンバーがいないというのもあり、兼任する分いかに負荷を下げられるかという点が課題ではないかなと感じた。

転職するのでお仕事を振り返る

本日が現職最終日なので雑に振り返りをしておく。

株式会社ドリコムではちょうど5年半働かせてもらった。 細かいものを除けば3チームほど所属し、ソーシャルゲームのクライアント、Unity SDK の開発、などの業務を担当した。

自分は前の会社を1ヶ月ほどで辞めた過去があり、ここでは絶対にちゃんと実績を残すぞという背水の陣みたいな想いがあった。

技術スタック

  • Cocos2d-x (v2)
  • Unity
  • C#
  • Jenkins
  • Ruby
  • Electron

ざっと思い出すのはこのあたり。 歴史あるアプリが多かったので多少古いフレームワークもあった。 Ruby は学生時代から使っているので自分用のスクリプトはだいたいそれで書いた。 めんどくさい手作業を避けたくて Electron によるツール開発などもやったりした。(知人にドヤったらめっちゃ便利ツールに拡張された)

ソーシャルゲームのクライアント

元々ゲームを希望していたのでアサインされた。 壮絶な既存コードではあったが、1個1個読み解いた。 同時押しするとフリーズする、など代々伝わるバグの原因究明などもやった。 複雑すぎてもう直せないと言われていたコードにも修正を入れた。 既存とルールの異なる新バトルの開発、なども仕切った。

この頃はスキルアップのための試行錯誤も多かった。 見積もり精度を上げるために徹底して作業を時間計測をしたり、手戻りを起こさないよう実装をとにかく後回しにして事前調査をやったり、世にある設計を勉強したり。 このあたりの経験は今も生きている。と思う。

開発はスクラムではない何かで管理されていたが、今考えれば大人数の割にはきれいにまわせていたと思う。 チームの IP 愛も高く良いチームだった。 途中からはクライアントリードも任され、自分なりには上手いことやっていたと思っていた。 が、今思えば、もっと「チーム」に対していい影響を与える動きを期待されていたんだろうなと気づいた。

Unity SDK の開発

少人数の新規開発チームだったので、それまでのゲーム運営とはだいぶ体感が異なっていた。 プロダクトのためになるなら割と何をやっても許される文化があり、やるべきことは自分で見つけることが期待されていた。 めちゃくちゃ自発的に動いていたし、結果として趣味の勉強と業務が混ざり土日もずっと何かをやっていた記憶がある。 正直自分には縁が無いと思っていた社外登壇や技術書の執筆もこの時期に行った。

途中からは多少チームが大きくなったことで、以前から興味のあったマネジメントも本格的にやり出した。 いろいろ考えて設計した開発フローがだいたいスクラムと一緒だと気づき、既存フレームワークの力を感じた。 メンバーのことやチームのことを考えながら自分で手を動かす大変さを知り、プレイングマネージャーだった上司たちの凄さも思い知った。 マネジメントが性に合っているとは感じるが、手を動かさなくなるのは思ったよりやりづらかったので、少なくとも直近は隙あらばコードを書くという姿勢を続けたいと思う。

次の話

IRIAM (イリアム) | あなたらしいキャラで、おしゃべりしよう!

次は「キャラクターによるライブ配信アプリ」でお仕事させていただくことになっている。 以前の同僚がここや同業他社にいるのを複数観測しており、非ゲームなもののだいぶ地続きなのを感じる。

業務は Unity とマネジメントという自分が興味ある二つをやれるので非常にありがたい。 と言いながらも、マネジメントやってくれぇ!圧を非常に感じているので、まずはそっちで成果を出し、そこを起点にしてより面白い業務につなげていきたいと思う。

設計について本気出して考えてみた

こんちは、じぬです。

本日のメニューはこちらです。

はじめに

お仕事で扱っている SDKドッグフーディングとして、趣味でミニゲームらしきものを作ってます。 せっかくなので UniRx や Extenject など使ってみたかったライブラリもふんだんに盛り込んで好き放題に書いています。

が、好き放題やり過ぎてとっちらかってきたので、リファクタリングしたくなりました。 あわせてクリーンアーキテクチャなどの設計にも興味が湧き、そのあたりを学んでみました。

※ 正直まだ理解し切れていないので、あくまで試した内容の紹介としてご覧ください

ゲームの現状

f:id:ryu_rand:20211008111455g:plain:w360f:id:ryu_rand:20211011122256g:plain:w360

f:id:ryu_rand:20211012110014g:plain:w360f:id:ryu_rand:20211012110919g:plain:w360

概要

このゲームは操作キャラ(ユニティちゃん)が赤白のボールに触れることでポイントが貯まります。 操作キャラはジャンプやスライディングなどのアクションも可能です。

黄色のボールはポイント獲得の代わりに操作キャラをパワーアップさせます。 パワーアップ中は障害物を破壊できるなどの変化があります。

ほかにも SE、タップエフェクト、3D オブジェクト生成中のプログレスバーSDK の機能を使ったボールのランダム配置、などの処理が存在します。

当初の実装概要

名称は一部省略してます。 はじめはサンプルを無理やり拡張したので Main が二つあったりしました。(笑(笑えない

class role
Main ステートマシン
建物などの GameObject 生成
ミニマップカメラの生成
ロード中のプログレスバー管理
GameMain ゲーム開始のカウントダウン
ゲーム中と終了の管理
ロード中のテキスト更新
タップエフェクト
Walker ボールに衝突した際の処理
パワーアップ処理の反映
パワーアップ中の障害物破壊
CharacterControl 入力を操作キャラに反映(移動、ジャンプ、スライディング)
アニメーションの制御
Ball ポイント獲得処理を発生
パワーアップ処理を発生
自らを Destroy
SDK にランダム配置されるための処理
BallMaker ボールの生成と配置
PointManager ポイント加算処理
ポイント表示の更新
獲得エフェクト
ボール破壊エフェクト

まず感じたのは個々の役割が多いことです。 Main はつなぎ役なのでまだしも、Ball は複数の役割が入り乱れています。

また、依存の向きに統一感がありませんでした。 例えばキャラがボールを獲得した際、ポイント計算、サウンド、獲得エフェクト、ボール消滅、などが発生します。 しかしそれぞれの処理を「誰が誰に対して」起こすのかが統一されておらず、拡張する際にどこを直すべきかが曖昧でした。

リファクタリング

ここでは、リファクタリング前に考えたことを一通り説明していきます。 最後の節で実際に行った修正をまとめます。

仮想の追加仕様

目的も無くリファクタリングすると迷走しそうだったので、仮想の追加仕様を考えそれに向けて実装を整理することにしました。 考えたネタは以下のものです。

追加仕様 修正方法とその意図
別キャラを使いたい キャラ操作を抽象化して差し替え可能にする、パワーアップ時のパラメータ調整を可能にする
ボールの種類を増やしたい パワーダウンや速度アップなど新たな効果を想定し、操作キャラとボールが相互に行う処理を抽出することで差し替え可能にする
壁破壊時にポイント獲得したい 操作キャラに対するポイント処理を抽象化して、発生元を差し替え可能にする

これらの実現を目標として、既存クラスを役割ごとに分解していきました。

クリーンアーキテクチャについて

ある程度分解が進むと、次はそれらをどう整理するか考えます。 せっかくなら原則にそって見直そうと考え、クリーンアーキテクチャを調べました。

クリーンアーキテクチャ自体の説明は著名な本なり記事なり多数あるので割愛します。 少なくとも自分にとっては難しい部分もあったので、複数の情報を取り込んで自分なりに噛み砕く必要はあるかと思います。

クリーンアーキテクチャと聞いて有名なのは次の図ですが、重要なのは「図に遵守したレイヤー分け」ではなく「依存方向の向き先」であると耳にします。 とは言え初めてでピンと来ない部分もあったため、感覚をつかむまでとりあえず図に倣った分類を考えてみます。

f:id:ryu_rand:20210908104053p:plain 出典:Clean Coder Blog

クリーンアーキテクチャによる分類は以下です。(一部の名称を略してます)

layer role
Business Rules ビジネスルール
App Rules ビジネスルール同士のつながり、関係
Interface Adapters 上位レイヤーの具現化、下位レイヤーとの接続
Frameworks DB やデバイスなど環境に応じた具現

これを元に整理した結果が次の図です。

f:id:ryu_rand:20211001112023p:plain
リファクタリング後の依存関係

整理前に考えたこと

まず、UI(特に UnityEngine.UI)に依存している部分を切り離すことは比較的分かりやすいです。 Frameworks 層に UI に直接依存する処理を置き、Adapters 層の IPresenter を通してそれらを利用します。 こうすれば UI 以外のテストが容易になります。 例えば、UI として表示する部分だけを切り離すことでポイント計算処理がテスト可能になる、という感じです。

Frameworks 層に依存しない具体実装も Adapters 層に置くことを想定しました。 抽象の実体化に伴う複雑さを引き受けるのが Adapters 層という印象だったため、このレイヤーは必然的に厚くなります。 とは言え散らかり過ぎな印象はあり、本来はこの内部をもっと役割ごとに分類するべきかと思います。

Business Rules 層と App Rules 層を実際に分けていくのは混乱がありました。 参考記事をいくつか見る限り、User などのモデルや純粋なロジックなどのドメイン知識が Business Rules 層、それらの使い方を定義したり関連付けるのが App Rules 層という分け方のようです。 いまのところ、純粋な知識の層とそれらを関連付ける層、という理解が感覚としてはしっくり来ています。 この点はなにをドメインとするかという話が重要なため、プロダクトの思想が出る部分かと思います。

整理後に考えたこと

ひとまず依存方向の統一はできていそうです。

Business Rules には依存される抽象クラスを、App Rules にはそれらをやや具体化したクラスを置いています。 App Rules が少ないですが、おそらく通信や DI などドメイン外のやるべきことが増えると合わせて拡大するのではと思います。 もしくは、ドメインの定義が甘いために Business Rules に要素を乗せすぎているという可能性もありそうです。 上位のルール層は、正直見直す余地があるだろうなと思っています。

Others は整理すれば Frameworks 層ぽい役割ですが、各所から気軽に呼び出せた方が使いやすいため独立した整理をしています。

実際にやったこと

実際に行った修正は以下のような内容です。

Main の責務を分割

まず、記述量が多い GameObject 関連の処理を別クラスに切り出しました。 建物や地形、ボールの生成と配置です。(MapObjectCreator

プログレスバーの内部挙動がベタ書きされていました。 管理を別クラスに分け、初期化時に必要なパラメータを渡し、Main からは次に進むタイミングだけを伝えるように疎結合化しました。 (ProgressManager

そもそもステートマシン自体イマイチな気もしましたが、やめるのは少々大がかりでした。 そのためこのクラスからはステート変更時の呼び出しだけを記述し、具体的な処理は他クラスに委譲する形で整理しました。

Ball の整理

Ball は生成時に SDK の機能でランダム配置され、ポイント獲得やパワーアップが発生するという役割があります。

まず形状が同じというだけでポイント獲得アイテムとパワーアップアイテムという役割を持っていますが、両者のコアロジックは無関係です。 また分かりにくいですが、自動ランダム配置されるための処理も他の機能と無関係です。 そこで役割を分け、フィールド上にある獲得できるアイテム(FieldIem)、ポイント獲得できるアイテム(IPointItem)、自動配置されるアイテム(OrnamentItem)という役割を必要に応じて Add する形にしました。

細かい依存関係の修正

例えば Walker クラスがゲームのアクティブ判定を持っている、BallDestroy を実行している、CharacterControl と密結合である、などが気になりました。 このあたりは依存性逆転の原則を意識し、interface で抽象化して依存方向を整えました。

Manager の分割

例えばポイント獲得イベントが発生すると、現在のポイントととの足し合わせ、複数ボールを獲得した場合の調整、その数値に向けてカウントアップしていく表現、など一連の処理を一つのクラスが管理していました。 結果としてクラスの役割が広くなり Manager という無難な名前がつけられていました。 対処としてまず、UI(UnityEngine.UI)と触れる部分を IPresenter として抽出し、Manager との接続は interface 経由で行うようにしました。 残った処理はほぼ計算だったので、責務を限定的にするため ManagerLogic というクラス名にしました。

感想

基本的にはやって良かった(面白かった、設計を考慮する有益さが理解できた)と思いますが、良し悪しをまとめておきます。

Pros

interface を切り出すことで強制的に役割の整理が行われるので、図示したことと合わせて制御の流れが分かりやすくなりました。 特に UI と切り離すことでテストがしやすくなる、というより「テストしたいところに注目して切り出す重要性」を意識できるようになりました。 今回は大した物量がないため効果は薄いかも知れませんが、ある程度大きなアプリケーションではもっと有益かと思います。(その分整理し続ける負荷はあると思いますが...)

また今回はリファクタリングを一部省略しましたが、プログレスバーやローディング表示などもテスト可能にした方が良いと思います。 地味にロジックが入り組んでいるため、はじめから TDD を意図した設計・作り方ができれば工数削減にも繋がると思います。

Cons

例えば Manager の分割では二つのファイルが増えており(IPresenter とその Impl クラス)、ルールを徹底するほど管理が煩雑化しそうです。 また複数メンバーでの開発を想定すると、レイヤーの分け方を具体的に定義・明文化しておかないと徐々に混沌としていきそうです。 実際、一人でやった今回でも割と迷走があったと思います。 アーキテクチャを主導できるスペシャリストがいる、継続してチームで学び続ける、など開発の土台が必要だと思います。

参考記事

【書評】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

よく見かける本。ここ最近気にしてることに刺さったので感想まとめ。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで | 市谷 聡啓 | コンピュータ・IT | Kindleストア | Amazon

それな!ってなったところ

  • 特にチーム初期はお互いのリズムをつかむために定期で関わる機会を用意する。場作りを通して誰でも動き出しやすい環境を作る
  • 集中力もリソース、集中すべき時間を意識して作り出す
  • リードタイムを計測することでなめらかな進行(書籍内で言う「人間のようなチーム」)ができているか判断する
  • タスクの重要度や優先度はリーダーだけでなくメンバー全員が把握している状態を目指す(民主化
  • スループットやリードタイムは定期的に計測し、ボトルネックの検知と解消を図る
  • リードはまず目の前のタスクをなくす、片付けるのではなくまずはなくす

なるほど!ってなったところ

  • リーダーは目標を定め、優先順位を決め、基準を定め、それを維持するもの
  • まずはメンバー間の違いを理解し、チーム活動に支障があるようならチームにおけるルールを決める
  • チームファーストとプロダクトファーストでチームのあり方が動くのはよくあること
  • メンバー同士の制約がなければ活動は集約せず結びつきが弱くなる、完成条件や透明性などチームのルールを自分たちで決める
  • OODA は空軍パイロットが用いる意思決定モデルで、PDCA に比べて予測の付きにくい状況に適応するためのモデルである
  • PDCA の P に時間がかかりすぎる、という問題が起こるときがある
  • チームの相互理解を進めるには何かを一緒に作るのが1番速い
  • チームに基準があることで確信を持って前に進むことができる
  • 役割を越境するには境界を認識する必要がある、そのために問うのは「自分は何をする人なのか」
  • リーダーではなく役割であるリードは交代することができる
  • マネジメント故に俯瞰から詳細に踏み込まない、という姿勢は分断を生む。これを避けるには両者を行き来するという負荷と戦う必要がある
  • 意思決定の精度はどれだけ前提を問い続けたか、どれだけ選択肢を挙げられたか、という2軸で構成される
  • チームメンバーの練度と自立性が高まったなら、リードがボトルネックにならないよう形態を変えていく(ヒトデ型へ)
  • 最適化は現状を維持することが前提になる、そもそもこの仕事は必要なのかという前提を疑う機会も必要
  • それぞれのメンバーがただ意見を出すだけではカオスになる、仮説検証に基づくチームの基準(共通理解)を作る

感想

新しい視点の発見もあった一方で、自分が実際にやっていることの目的や根拠が明確に言語化されていると感じる箇所も多かった。 自分の考えが自分だけの思い込みではないという後押しになったし、曖昧な思考が言語化命名)されることで深化させたり派生して考えることがしやすくなった印象がある。 なのでリードエンジニアを試行錯誤中のいま読んだことは非常に有意義だったと思う。

具体的には、リードの民主化や定常的に自分たちを計測する機会の設計はぜひ形にしたい。