今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる
株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです．
Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。
本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコンテキストで特に意識しているトピックやセオリーを，エンジニアリング組織構築に馴染みの無い人へ動機なども含めて説明することを主眼に記述しています．*1 この記事の内容は所属する企業の公式見解ではなく，個人的に仕事をする上で大事にしていることにとどまっていることにだけご留意ください．
この記事は，Engineering Manager Advent Calendar 2018 の13日目の記事です．どちらかと言うとソフトスキルとかピープルマネジメントとかエンジニアリングマネージャーのキャリアとかの話が多い今回の Advent Calendar ですが，僕の記事はどちらかと言うとセオリーの棚卸しって感じですね．
目次
- 目次
- リソース効率とフロー効率, 制約理論
- 職能組織と機能チーム*2
- 組織の寿命，プロダクトとプロジェクト
- プロダクトの境界とコミュニケーション
- SoE と SoR によるバイモーダル戦略
- これらを実際の組織運営・組織構築に応用すると？
リソース効率とフロー効率, 制約理論
プロセスを設計する上で，「効率の良さ」を求める際に，その「効率の良さ」はどういう側面のものなの？という話．今年の頭に前職の後輩たちにレクチャーした話をこのブログに書いた けど，昨年くらいからよくエンジニアリング組織のマネージメントをやってる人の文脈で聞くようになった概念かなと思います．
リソース効率とは，プロセスを構成するパーツの稼働率の高さを指し，一方でフロー効率とはプロセスを流れる価値を付加する対象 (flow unit) に価値が付与される活動が完了するまでの時間の短さを指します．
非常に単純化した例を挙げれば，1人で取り組めば3日かかり，3人で取り掛かれば1.5日で終わるタスクがあったときに，3人が別々のタスクに3日間取り組み続けるのがリソース効率を重視した配置です．この場合，すべてのタスクが3日目に完了します．また，すべてのタスクを一人で行うので知識移転も発生しません．
一方で，5日間かけて，3人一緒になって1つのタスクを順々に消化していくのがフロー効率を重視した配置です．タスク A は2日目に完成しています．
もちろん現実世界ではこんな単純に話がいくわけではありません．今回の例だと3倍の人を一つのタスクに投入しても1.5倍の速度しか出ませんでしたが，人数を投入するのが有効なのか，一人で淡々と取り組んだほうが早く終わるタスクなのかも場合によります．
リソース効率とフロー効率どちらを取るかのゼロイチの話でもなく，また，単純にタスクを完遂するという観点以外にもメンバーの感情面や育成という観点も考慮する必要があります．今回の例だと複数タスクの依存関係なども考慮していません．
事業やプロダクトによってどちらの側面をどれくらい重視するかが異なるかと思いますが，何も考えずにリソース効率を上げるアプローチを取っても，プロセスのボトルネック自体を解消せずにフロー効率を向上させないと，プロセス全体の生産性は上がりません．このことを「制約理論」と呼びます．
エンジニアリング組織の設計と運用も，プロダクトを生み出すためのプロセスを設計するという話なので，制約理論やリソース効率とフロー効率の違いはしっかりと意識するべきです．
職能組織と機能チーム*2
チーム・グループを作る上で何を軸とするかの話です．リソース効率・フロー効率とも綿密に結びつく話です．
職能組織
似た技能を持っているメンバーを集めて作られたチームを職能組織と呼びます．*3
似た技能を持つメンバーが集まるので，メンバー同士の切磋琢磨がワークして技能スキルが上がりやすいというメリットがあります．また，労働市場で希少性のある技能や，特殊性のある技能，会社内の複数部署やチームに横断して仕組みを整えることが効果的だと判断されるケースでこの形態が取られるケースが多いのではないでしょうか．例えばデータ分析や機械学習，人工知能に基づいた技能を持つエンジニアの特殊部隊や，ITインフラの構築・運用に長けたエンジニアのチームといったものを想像すると良いかもしれません．
職能組織が多かったり，職能組織間の境界がしっかりと設定されていると，複数の職能チームが必要なプロジェクトを完遂するためのリソース効率は高めやすい反面，チームの間での情報伝達のオーバーヘッドがかかるなどの理由でフロー効率は下がりやすい傾向があるかと思います．
機能チーム
職能を横断し，顧客に提供する価値を作る単位に基づいて組成する組織を機能チーム (Feature Team) と呼びます．
顧客に提供する価値の最大化にフォーカスが当たりやすいのでフロー効率は高く保ちやすい一方で，チームの中のすべての職能が常に必要とされるとは限らないという点でリソース効率が落ちがちであるという特徴があります．
また，一言で「職能を横断する」と言っても，どの程度まで横断するかも重要になります．例えば，エンジニアの中でフロントエンドもバックエンドもインフラエンジニアもデータ分析も合わせるというレベルもあれば，さらにビジネスサイドのメンバーまで一つのチームとする，という職能横断も考えられます．職能横断の範囲が広ければ広いほど最終的な顧客の価値にフォーカスした組織が作れますが，その分マネジメントの難易度は上がるでしょう．
マトリクス組織
職能組織と機能チームの両方のメリットを享受するために，両軸を兼ね備えたマトリクス組織という構造がしばしば見られます．
マトリクス組織は，人事評価や指揮系統などの点で難易度が高く，しっかりとした制度設計や取り決めがないと難しいとされます．
例えば上述の図の場合，赤い ☆ の部分に属しているプロダクト A のエンジニアは，プロダクトAのマネージャーとエンジニア組織のマネージャーの両方から評価や指示を受けたりしますが，マネージャー同士の評価や指示が矛盾したときにはどうすればよいかはどう判断すればよいでしょうか？また，メンバーの配置はどちらのマネージャーが主導権を握ればよいでしょうか？決まりが明確になければ社内政治や縄張り争いのようなものに発展してしまうのも想像に難くありません．
組織の寿命，プロダクトとプロジェクト
組織の寿命を長くするためにどうするか？そのために，極力 プロジェクトではなくプロダクトで思考しよう ，という話です．
Stable Team
ここでいう Stable つまり「安定」とは，比較的長い時間に渡って顔ぶれが大きく変わらないことを指します．なるべくメンバーの増減が起きないようにする動機は様々あります．
- ステークホルダーを含むチームの外部が，チームの誰にコミュニケーションを取ればよいかがわかりやすくなる
- 将来の予測を立てる上での不確実性を減らすことが出来る
- メンバー同士の関係も長く存続するので，チーム内のコミュニケーションコストが下がる傾向がある
- ブルックスの法則*4 に遭遇することを防ぎやすくなる
もちろん，そういうことを言っていられないような状況も多々発生しますが，なるべく組織の寿命を長くし，その組織に属するメンバーの顔ぶれを安定させるにはどうしたらよいか，がソフトウェア開発の文脈では重要になるのではないかと思います．
プロジェクトに基づく組織
プロジェクトとは，ある事業の中で期限と範囲を決めて完遂するための計画と言えます．事業が続いても，事業の中のある計画が完了すればプロジェクトは終了します．
基本的に，プロジェクトのために組成された組織は，プロジェクトが終了すれば解散します．上手に組織を設計しなければ，プロジェクトが終了した後のことはプロジェクトにおける考慮から外され，部分最適が生じることもあるでしょう．逆に，何より完遂することが大事なときにはプロジェクトベースの組織を作れば良いとも言えます．
極めて単純化した例を示すと，「地球を出発し，月の周りを周回して地球に帰還する」という活動は，どのようにこの宇宙旅行を完遂させるかが最も重要なので，プロジェクト組織が適すると言えます．
一方で，宇宙ステーション開発は，宇宙ステーションを構築して終わりではなく，その後の宇宙ステーションを活用した宇宙開発が安全に安定して行われることが重要なので，宇宙ステーションを作り切ることだけに特化した組織にならないことを注意しなければいけません．
プロダクトに基づく組織
ここで，プロダクト とは，事業を行う上で顧客に届ける価値と定義します．事業が存続する限り，プロダクトは存続します．
プロダクトに基づいた組織は，もちろんプロダクトが存続する限り存続するでしょう．基本的に，プロジェクトに基づいた組織よりも長く存続する傾向があるということができます．長く存続する可能性がある組織であるということは，プロダクトの長期的な価値や組織の生産性などにフォーカスがあたり，技術的負債の管理にも責任を持つ動機づけが働きやすい傾向があるのではないでしょうか．
ここまで，プロジェクト組織とプロダクト組織を対比的に書きましたが，プロダクトとプロジェクトは，対立関係ではありません．プロダクトに基づいた組織は，その時々のプロジェクトに取り組むことができます．
プロダクトに基づいた組織を構築する際に難しいのは，プロダクトの範囲や組織の裁量の範囲を定義することでしょう．プロジェクトに基づく組織は，プロジェクトの定めるスコープが明確に決まっているはずなのでこの部分にはあまり苦心しません．一方で，プロダクトに基づく組織は，定義を一言で表すことは簡単でも，色んな事情があって境界付けが難しいこともあります．求められるミッションと組織の持つスキルセットに差があって苦心することなどもあるでしょう．
プロダクトの境界とコミュニケーション
境界の話
プロダクト組織のところでも出ましたが，職能横断チームやプロダクトの定義は，広く取れば取るほど最終的に提供される価値にフォーカスしやすい組織となるが，その反面コミュニケーションのオーバーヘッドがかかったり，価値判断の難易度が上がったりするなど，高度なマネジメントが求められる傾向があります．
以前に私が書いた 組織境界の話 や プロダクト定義の話 でも取り上げましたが，現実的には以下の3つが重要になるのかなと思っています．
- 境界を広げ続ける努力
- 適切に境界を設定して「望ましい部分最適」が働くようにすること
- 必要に応じて境界を見直すこと (一度設定して満足してはいけないし，フェーズが変われば最適化するべき KPI も変わる)
「コンウェイの法則」と「逆コンウェイ戦略」
コンウェイの法則とは，「組織の設計するシステムには，その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある」という有名な法則です．
コンウェイの法則はもともと，組織の成果物を分析した結果であり，組織の構造を所与として成果物のアーキテクチャの傾向を説明するものでした．これを逆手に取り，プロダクトの構造を変えたり，新しくプロダクトを作る際に，どのような設計を実現するかから逆算して組織のコミュニケーションフローをデザインすることを「逆コンウェイ戦略」といいます．
SoE と SoR によるバイモーダル戦略
「逆コンウェイ戦略」では，どのような設計の青写真を描くが重要になります．ではどのような設計を目指せばよいのか？その答えはもちろん事業や組織の特色に依存しますが，一つのヒントになるのが SoE と SoR によるバイモーダル戦略です．
System of Engagement (SoE)
System of Engagement とは，プロダクトと顧客のつながりを確立し，強化することを主眼としたシステムです．
一般的な toC のサービスで言えば，インターネット上に展開されるサービスサイトや，モバイルアプリ，メールや郵送物などによる CRM チャネルなどが SoE に当たります．
特に toC 向けプロダクトの場合，どのような改善施策が効果があるかや，潜在市場がどこに潜むかは経験主義をもとに探し当てる必要があります．「リーンスタートアップ」や「アジャイルなプロダクト開発」が特に効果を発揮する分野と言えるかもしれません．小さく高速に実験して学習することが求められます．
System of Record (SoR)
System of Record (SoR) とは，出来事が正しく起きることを保証し，起きた出来事を正確に記録し管理するためのシステムを言います．
金銭管理や，法令や規制に基づいた報告義務のあるようなドメインなどがこれに当たります． SoE と比べれば，情報の取りこぼしやシステムダウンはより致命的であり，リスクを抑えて安定稼働することが求められます． 事前に要件を明確化してコーナーケースなどを慎重に考慮することが求められるので，いくら「アジャイルなソフトウェア開発」を標榜しても，大きな設計を洗い出し*5，正しくシステムが稼働するかの検証にも力を入れる必要があるでしょう．
バイモーダル戦略
SoE / SoR の特性を理解し，開発するプロダクトや，システムを構成する全体の中でも特定のエリアの性格に対応したチーム構成やプロセス設計などのアプローチを取る戦略を「バイモーダル戦略」といいます．比較的大規模なシステムを開発するとき，そのシステムの中にも SoE の特性を持つ部分と SoR の特性を持つ部分があるので，そのことを自覚しましょう，という話です．
これらを実際の組織運営・組織構築に応用すると？
ここまでが，今の自分が意識している組織構築・運営を行う上でのセオリーやパターンでした．エンジニアリングマネージャーそれぞれの取るアプローチは，当然所属する組織の文脈によって変わってくると思います．皆さんは普段どのようなことを考えていらっしゃいますか？
FOLIO Advent Calendar 2018 にて明日公開する記事 では，FOLIO のこの1年半くらいの開発組織の変遷や，今抱えている課題についてご紹介する予定です！ (このブログで紹介します)
*1:世の中には エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング という，より網羅的に，さらに発展的な内容まで網羅した書物があります
*2:『エンジニアリング組織論への招待』では機能別組織と機能横断型組織と記載されていますが，本稿では LeSS における Feature Team を一つの道標にしているため，このような用語を使っています
*3:呼び方はいろいろありますが，FOLIO ではこう呼んでいます．
*4:プロジェクトの後期に人員を追加投入することは，開発速度を向上させず，むしろプロジェクトの遅延を引き起こす
*5:Big Design Upfront と呼ぶことがあります
社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み
今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。
この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。
組織の「100人の壁」
自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアまでに拡大し、コミュニケーション不足を感じることも増えてきました。
中でも、社員と社長の関係という観点では、去年は CEO の甲斐ががオフィスをフラッと歩いて社員と気軽に話して事業のビジョンなどを共有することができたものが、メンバー社歴やオフィスの中のよく活動する場所、仕事の内容によっても甲斐と慢性的に距離のある立ち位置にいる社員が出てきたのも事実です。もちろん、甲斐もそのことは理解しており、各メンバーとコミュニケーションが取れるように考えたり動いたりしてくれますし、実際お昼時にオフィスの真ん中でメンバーの皆とカレーを食べている姿もよく見かけるのですが、「気をつける」のではどうしようも出来なくなるのが、「100人の壁」の特徴のひとつなのかもしれません。
理想を述べれば、社員の一人ひとりが社長のビジョンを理解し、共感できることが大事であることは疑いようがないでしょう。特に、今年の FOLIO は LINE との資本業務提携を発表したり、新しいサービス「おまかせ投資」の提供を開始したりと、会社としてのこれまでにない動きも多かったので、今、社長がどのようなことを考えていて、自分の仕事にはどのような意味があるのか？をメンバーがより深く知る機会を設けることは非常に重要でした。
その理解を助けるための試みとして今年の7月から始めたのが、CEO Radio です。
CEO Radio のきっかけ
CEO Radio は1回10分~20分程度、CEO の甲斐と、聞き手の私、そして時には FOLIO の様々なメンバーが何らかのトピックについて話したものを、社内でメンバーが好きなときに聴ける音声コンテンツです。
この CEO Radio の始まりは、6月のとある社内の食事会にて、社長とバックエンドエンジニア数名で、「最近の会社の課題」に関する話題になり、上述のような課題をメンバーが挙げた際に、私が言及したのがきっかけでした。
FOLIO のメンバーは原則として、ジョインする際の選考プロセスの中で必ず CEO の甲斐と話すようになっており、メンバーの多くが甲斐の「世の金融の常識を変える！」というビジョンに共感して参画しているのではないかと思います。それでも、甲斐の考えを、入社時や偶発的なコミュニケーションだけではなく社内の興味あるメンバーには継続的に伝えられるようにし、しかも形に残すことで将来ジョインするメンバーにも FOLIO の文化や価値観を知ってもらえるようにすることは有意義なのではないか、と考えたのが CEO Radio の始まりでした。
私の頭の中にあった先行事例
私が「CEO Radio」を提案した際、頭の中には2つの先行事例がありました。
ひとつは、 2017年にあった 「XP祭り 2017」にて、ソニックガーデンの倉貫社長が紹介されていた、ご自身が取り組まれている「社長ラジオ」です。ソニックガーデンはほとんどの社員がリモートワークをしている会社であり、メンバーと社長のフェイス・トゥ・フェイスのコミュニケーションが比較的少ない会社であるために、会社全体のことを伝えたり、会社の価値観や動機づけになるような話をするための仕組みだったそうです。
また、私の前職であるサイバーエージェントの「カルチャー推進室」が、私の頭の中にあったもうひとつの事例でした。
サイバーエージェントは広告・ゲーム・メディアという大きく3つの部署に分かれていますが、その部署の垣根を越えて仕事を行わないメンバーというのも多く (私もその1人でした)、部署などの組織ごとに独自の慣習や価値観が醸成されている会社でした。しかしながら「サイバーエージェントらしさ」という価値観や文化は明確に存在していましたように感じました。その全社で一貫した文化の醸成に一役買っていた仕組みのひとつが「カルチャー推進室」の活動だったと私自身は理解しています。各部署のキーパーソンへのインタビューや、社歴の長いメンバーのキャリア遍歴、過去にメンバーが苦闘したプロジェクトの歴史などが社内ポータルサイトや社内刊行物などを通して全社員に発信されており、サイバーエージェントにジョインしてすぐのときに感動したことを覚えています。
明確に形に残されているものを追うことで、文化や会社の歴史に対する理解を深めることができました。私にとっては初めての転職であり不安も大きかった中で、「お客さん」になってしまって会社の文化に馴染めないようなことがなかったのはとても大きかったなと感じています。
CEO Radio を支える技術
CEO ラジオの収録を行う際には、以下のような機材を用いています。
- マイク: FIFINE Microphone K667
- 外付けサウンドカード: Creative Sound Blaster Play! 3
- ソフトウェア: GarageBand (当初は QuickTime Player)
マイクなどの各機材は、当初は社内メンバーの私物のマイクを使っていたこともあったのですが、回数を重ねて CEO Radio の有意義さに対する理解が会社全体に浸透してきたタイミングで、会社の経費で購入したのが現行の機材です。
機材選びで気をつけたポイント
マイク選びは、複数の話者がいるなかで1本のマイクを利用するので、当然ですが無指向性マイクを利用すること。そして、盲点になりそうですが重要なのがサウンドカード選び。サウンドカードを単純に「USB と 3.5mm ジャックのアダプタ」と捉えると痛い目を見ます。実際、当初購入した安価なサウンドカードでは細かい音が全く拾えず、後から現行のサウンドカードに買い替えたことでしっかりとトークの内容が聞き取れる音声を収録できるようになりました。
収録と編集
収録ソフトは、以前は QuickTime Player で収録して、特に編集もせずそのままアップロードという形にしていました。回を重ねるにつれて、収録後に一部カットが必要になったり、複数の音声ファイルを接合しなければならない需要も出てきたため、GarageBand で最低限の編集をするようにしています。やってみて改めて思うのですが、編集は凝ろうと思えばどこまでも手を入れられてしまうのですが、私の本業は別にあるので、時間を使いすぎないよう気をつけています。
社内配信
社員への配信方法は、当初は Slack アプリケーション内で再生できる形でアップロードしていたのですが、最初の配信から2回ほど回数を重ねたタイミングで、とあるエンジニアが社内のみから閲覧できる配信サイトを構築してくれました。もともと社内サイトの立ち上げは考えていたのですが、あっという間にできてしまうスピード感にとても驚いたのを覚えています。 このサイト立ち上げを契機として、今では社内で行われる勉強会やワークショップも有志が音声もしくは動画を収録し、このサイトでアーカイブをいつでも視聴できるようになっています。
CEO Radio で何を話しているか
CEO Radio でどのような話題を取り上げるのかについては、特に決まりはなく、いろいろな試みをしているのですが、その中のいくつかをご紹介してみようと思います。
会社の直近の動きに関わる話
今年の11月に、投資一任型のプロダクトである「おまかせ投資」をリリースしたタイミングなどで、なぜ FOLIO はこれまで展開していた「テーマ投資」のみならず、複数のサービスを展開するのか、そこにどのような狙いがあるのか？今後どのようなプロダクトを展開するのか？などについて語ってもらったりしています。 FOLIO が提供する投資プロダクトや開発するシステムはそれぞれ単体で充分に巨大であり、メンバーは自分の担当範囲のことは知っていても、それ以外の部分についてはどうしても疎くなったり、複数のプロダクトやプロジェクトが会社全体の観点からどのようにつながっているのかも意識しづらくなってしまうことも、しばしばあります。CEO Radio で会社全体からみた各プロジェクト・プロダクトの位置づけをフィードバックし、メンバーのモチベーションに繋がるようにしています。
You は何しに FOLIO へ？
FOLIO メンバーをゲストに呼び、ゲストが FOLIO にジョインする前に何をしていたか？なぜジョインしようと思ったのか？について語ってもらうシリーズ。あるメンバーは「FOLIO に入るか、プロのポーカープレイヤーになるかを悩んだ」と語ったり、甲斐が、あるメンバーとの初対面を振り返って「最初は感じの悪い子だと思った」と思っていたという、今でこそ言える話が出たり… FOLIO メンバーの個性も相まって、毎回楽しく興味深い話を聞かせていただいています。
スタートアップ入門
もともと投資銀行でのトレーダーというキャリアを歩んできた甲斐が、スタートアップを立ち上げるうえで気をつけたこと、大切にしていることを教えてくれるシリーズ。いずれは FOLIO で成長したメンバーが "FOLIO mafia" として新たなベンチャー企業をどんどん立ち上げて行ってほしい、という甲斐の願いが込められているシリーズでもあります。
お便りのコーナー
社内のみからアクセスできる投稿フォームがあり、ここに集まったお便りに甲斐が答えるコーナーを定期的に設けています。FOLIO メンバーからはよく鋭い質問が飛んで来ますし、質問した人が納得できるようなトークにできるのかという意味で、聞き手としては比較的緊張するのがお便りのコーナーだったりします。個人的には、最近収録した「FOLIO のミッションとバリューに込めた意味や意図を教えてほしい」という回が非常に良かったなぁと思っています。
まとめ
FOLIO での、会社規模が大きくなってもビジョンや文化を組織の隅々まで浸透させるための取り組みについてご紹介しました。もちろん CEO Radio を聴くかどうかは社員にとっては任意ですし、このような取り組みで全てを解決しようとは考えていないからこそ、他の手段も使いながら組織のスケールアップに合わせた文化形成は引き続き頑張っていきたいと思っています。
そんな FOLIO では、一緒に働くメンバーを募集しています。少しでも興味を持った方は、一度気軽に FOLIO のオフィスに遊びに来てみませんか？ www.wantedly.com
明日の FOLIO Advent Calendar 2018 - Adventar は、いつも何から何までお世話になってる kenchan0130 による Google App Script の話 です！
Scala関西Summit 2018 で喋ってきた
来たよーん #scala_ks pic.twitter.com/fgR1lR6Bq1
— むらみん (@Mura_Mi) 2018年11月10日
昨年は参加者だったけど、今年はスポンサーセッションを喋る立場になった。去年の記事はこちら↓↓
去年の9月に Scala関西Summit 2017 に参加して、懇親会で id:itohiro73 に誘ってもらったことがきっかけで FOLIO に入社したので、1年経って FOLIO の人間としてしゃべるようになるというのは不思議というか、この1年が色んな意味で激動だったなぁとしみじみ思いました。
登壇資料はこちら。FOLIO のバックエンドシステムがどうできているか、いろんな側面からご紹介できるないようになっているかなと思います。20分という時間の制約がなければもっとお伝えしたいことがあったので、それはまた近いうちにどこかの機会で。
ここから先は比較的エモい話。
そもそもこういうイベントで登壇するのは初めてだったことと、しかもそれが僕個人の発表ではなく、会社がスポンサーとしてお金を出してくれて、なおかつスポンサーセッションとして弊社の取り組みを紹介するという重大任務だったので、いろいろと頑張った。結果として、エンジニア採用などでも使えるような資料ができたり、トークの内容を考えることで気づけること、仕事自体にフィードバックできることもあったので、ちゃんと取り組んで良かったな、と思う。 会社の Slack を見返したら8月11日にまず話す叩きを作ってた。これを id:itohiro73 と id:matsu_chara にレビューしてもらったりしてた。
もちろん3ヶ月間ずっとこれやるわけではなく、時々思い出したようにちょっとずつ進めたりしてたんだけど、2週間前くらいからはスライド作って、一人で喋るだけじゃなくてメンバーに見てもらってどう思うかを聞いたりと、ひたすら叩いてもらう機会を作らせてもらった。こういうのに付き合ってくれたメンバーに本当に感謝。
そして、一部デザインに凝ったスライドは CDO の広野 (https://hajipion.com/) に手伝ってもらった。いろんな場面で思うけど、職種とかも関係なく惜しみなく協力しあえる関係は、この会社にいて心地よいなぁと思う理由の一つだったりします。感謝。
そして！Scala関西Summit に来たからには食い倒れも重要！
1日目の朝はカフェのモーニング
そういえば昨日の朝ごはんは sunshine というカフェのモーニング。チーズトーストでした。 pic.twitter.com/WTGghAsKUw
— むらみん (@Mura_Mi) 2018年11月11日
1日目のランチは天満のお好み焼き「千草」豚肉めちゃ肉厚！
ひゃほー！！！！！ pic.twitter.com/KzVw4IO4k4
— むらみん (@Mura_Mi) 2018年11月10日
2日目は前日の懇親会の後3次会まであって二日酔いだったので、かすうどん。かすうどん初めて頂いたけど良いな
大阪グルメ満喫してる 今日は、かすうどん。 pic.twitter.com/T4xkIhMwZs
— むらみん (@Mura_Mi) 2018年11月11日
2日目終了後は梅田食堂街にて食いだおれます
今年もこれを食べに大阪に来るために登壇したのだ。笑 pic.twitter.com/0wan1Zg2RJ
— むらみん (@Mura_Mi) November 11, 2018
からの、串カツ！ pic.twitter.com/UJE2AB38Dl
— むらみん (@Mura_Mi) November 11, 2018
締めはお好み焼きでしたー！ pic.twitter.com/hDnQ95QSIN
— むらみん (@Mura_Mi) November 11, 2018
"管理"という言葉の曖昧さ，またはなぜ自分が仕事で "管理" という言葉を嫌うか
仕事をしていると，よく "管理" という言葉に遭遇する．でも，日本語の "管理" という言葉に色んな意味があったり，文脈で "管理" という言葉が指す望ましい行動が違ったりして，辛いなぁと思うことが少なくない．だから自分は，仕事でなるべく "管理" という言葉を使わない．使うとしても，なるべくなら明確にしたいなと思うポイントがいくつかある．
いまの自分が思っている "管理" という言葉が刺しうる意味の文脈ごとの違いを整理して見たいと思う．
Administration / Control / Management
他にもいろんな英語があるけど，個人的に好きな分類だと， "管理" の英訳は "Administration", "Control", "Management" に分かれる．*1 *2自分なりの定義や意味合いを考えてみたい．
Administration
予め決められたプロセスやワークフローが正しく運用されていることを担保するような "管理" を指す．例えば "System Administration" と言えば，システムを運用する上で決められたフローやルールを遵守する活動を指すと思っている．
例えば規定に則ったソフトウェアのみが職務用端末にインストールされているというルールが遵守されていることを担保するために，ソフトウェアのインストールは "管理者" すなわち "Administrator" のみが実行することが出来る，という制約を設けるという例が浮かぶ．
かつて働いていた職場では，チームやグループに1人，「アドミさん」と呼ばれる，会社の決められた稟議やワークフローを進めてくれる人がいた．*3 よくある職務名称だと「総務」というやつなんだけど，細かいことなら会社の経費で文房具を発注するとか，大きなことなら人事異動にともなって新しく部署に参加する従業員のシステムアカウントや座席を用意することなど，予め会社を運営する上での取り決めを実行することが責務になる．
Control
"Control" は "制御" であって，直接，またはほぼ予測可能な因果関係を通じて間接的に，何らかのアウトプットを思うように動かすことを指す．*4
例えば「支出をコントロールする」といえば，具体的には現在支払っている何らかの支出を支払わなくすれば，それは「支出をコントロールした」と言える．また，プロボクサーは試合のスケジュールに合わせて「体重をコントロールする」が，体重は直接制御することは出来ないものの，摂取するカロリーを減らせばほぼ確実に体重を減らすことは出来るので，摂取するカロリーと体重の因果関係を利用し，カロリー摂取量をコントロールすることで体重をコントロールしたと言うことが出来る．
Management
Manage という言葉の語源は，暴れ馬を乗りこなすという意味であり，経営とか組織運営とかプロダクト開発の文脈に落とし込めば「直接制御できないアウトプットが好ましいものになるように働きかけること」だと思う．馬術のアスリートが，自分の意図するように馬を操ることは，"Control" ではなく "Management" であることは自明だ．馬も自分の意志を持ち，騎乗している人間の思うとおりには動かないからだ．
例えば何らかの事業の責任者は本質的にはマネージャーだろう．世の中の企業が営んでいる事業の殆どは「あちらを立てればこちらが立たず」の関係に囲まれているのみならず，それらが複雑に絡み合っているから，「あちらを立てれば，全く関係ないと思っていた遠くの何かが倒れる」ような状況にある．このような直接制御したり完全に予想できない因果関係の上で，利益を上げたり売上を上げたり知名度を上げることがマネージメントの本質である．
何を / どのように / どうする
"Administration", "Control", "Management" のいずれも動詞を名詞化したものである．動詞は単体で使うものではなくて，これらの3つ (の派生元) の動詞は必ず「誰が」「何を」「どのように」「どうする」という主語，目的語，副詞，目的語と併用されることになる．
これらの中で「誰が」というのは自明で，Aministration なら administrator だし，Control だと Controller だし，Management だと Manager だ．
「何を」「どのように」「どうする」のかは文脈によるけど，その難しさはこの3つの動詞で異なってくると思う．
Administration に考える余地はあまりない
Administration は予め決められた決まりを正しく運用することが目的だ．だから「どうする」は「決まりを守る」ということになるし，そのためには「決まりのとおりに動いて，決まりに反する行動をしない」という他に得策はなくない．たまにとても気を利かせてくれる総務の人はいて，彼らは効率が良かったり利用者の立場に立って考えたり，決まりにない部分を踏まえてショートカットをすることに長けているということはあるのだけど，それでも原則としては「決められたことを決められたとおりにやる」ということ以上のことはしていない．*5
「この草野球場の管理人は融通が利かなくて，プレーが続いてたとしても時間を過ぎると夜間照明を切っちゃう」とか，「大学の卒業論文の提出が1分遅れて受理されず留年されることになった」とかいう愚痴を耳にしたことがある人は多いと思うけど，彼らの職務は規則を守ることである以上はナンセンスだ．そしてその規則がなぜ存在するのかは，大体の場合その Administrator の与り知らないところにある．
Control の「どうやって」「どうする」は割と明確
Control の「どうやって」は，「どうする」さえ決まっていれば明確だ．体重を増やしたければ摂取するカロリーを増やせばいいし，体重を減らしたければ摂取するカロリーを減らせば良い．「どうする」という問題も，文脈によって結構簡単に決まりやすい．部屋に入門したばかりの力士はひたすら体重を増やせばよいし，ズボンのベルトの上に腹の肉が乗っかっているのが醜くて改善したいと思っている人は体重を減らせば良い．
Management の「どうやって」「どうする」を決めるのは難しい．
Management が必要な分野では，因果関係が複雑であって予測が難しいから，目標を達成するための「どうやって」の選択が難しい．確実に効果があると思った施策が効果を発揮しなかったり，想定していなかった反作用が想定した作用を上回ってしまってマイナスになることもある．営業チーム全体の成績を競争を通じて引き上げることを意図して成果報酬制を設けたら，競争が激化してしまいノウハウを共有するインセンティブが発生せず，チーム全体の営業成績は向上しなかったり，競争を通じてチームメンバーのメンタルが疲弊して営業成績がむしろ下がってしまう可能性すらある．
そして，場合によっては「どうする」自体を明らかにすることが難しいこともある．ソフトウェアやサービスを展開する企業の「プロダクトマネージャー」は，その名前からプロダクトをあるべき方向に導くことが責務であり，そのための方法を見極めて実行する仕事だと思われる．しかし，「どのように」を決めるためにはそもそも「どうする」が明確でなければ行けないのだが，事業の成長フェーズを見極めて，利益を多少度外視して売上を伸ばすのか，売上は伸ばさずに利益率を高めて利益を上げるフェーズなのか？が明確でなければ「どのように」は議論すら出来ない．それなのに「どうする」を明らかにしないまま「どのように」ばかりにフォーカスしてしまう人はそんなに珍しくは無いんじゃないかと思う．
なんでこんなことを思ったのか
なんで自分が突然こんなことを思ったのかというと2つ理由がある．
まずひとつは，一言に「管理」と言って求められているのが Administration なのか Control なのか Management なのかは結構違うのに，その違いを明らかにしないまま，Management をしなければいけない状況で Control するようなアプローチを取るなどの間違いを犯してしまうケースをいろんなところで見るからだ．理論と現実の紐付けやギャップを埋める努力が足りなかったり，組織が「考える人」と「手を動かす人」という分業の考え方から脱却できないまま複雑で変化の激しい仕事に取り組もうとしているときにこの状況は容易に発生するんじゃないかなぁと思っている．Management 3.0 では，こういう状況を "Management 2.0" と呼んでいて，その有様を「Doing the right thing wrong」と称している．ここでいう right thing とは "Manage されるべきものを Manage する" ことで，wrong とは "Control や Administration するアプローチ" だと思ってもらって良いと思う．Management 3.0 は，"Doing the right thing in right way" をすることを目指している．
もうひとつは，「アジャイル」や「スクラム」に，何らかの "管理" が求められるようなケースによく出くわすからだ．特にスクラムマスターの仕事を「マネージャー」だと思ったり「チームのタスクを管理する人」だと思ってしまうような誤解には残念ながら頻繁に出会う．「チームを支援する」だの「自己組織化を促す」だの言われても，そんな能力を持っている人や，それが実現された状況を見たことがなければ無理もないことだ．でも，「アジャイル」だ「スクラム」だという言葉があったから自分のキャリアが開けたり，それを通じて誰かのためになることを仕事にしてきた，そして今後もそうしていきたいと思う身としては，こういった誤解は解いていきたいなぁと思った次第なのである．
大規模スクラムにおけるプロダクトの定義
単一のチームでスクラム開発を行う時と比べて，LeSS や Nexus といった Scrum of Scrums，または大規模スクラムを実践する際，「プロダクトは何か」という定義はより重要になります．
LeSS の解説書である Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) を読み進める中で，プロダクトの定義についての記述が結構良いなと思ったので，自分なりの例も交えつつ説明したいなと思います．
なぜプロダクトの定義が重要なのか
大規模スクラムに限らず，スクラムにおいてプロダクトの定義が明確であることは極めて重要です．プロダクトの範囲が明確でなければ，プロダクトバックログがどこまでをカバーするべきかも，プロダクトバックログアイテムの受け入れ基準にどのようなことが書かれているべきかも判断することが出来ないし，誰がプロダクトオーナーとして適しているかを判断することも出来ないからです．
これが大規模スクラムとなると，その重要性は更に増します．
複数のスクラムチームがひとつのプロダクトバックログを実現していくようになると，ほとんどすべてのケースでプロダクトは複数のシステム (LeSS では コンポーネント と呼びます) から構成されるようになります．プロダクトを構成する特定のシステムの開発や改善に注力する中で，システム単体が大きくなったり，複雑さが増すに従い，各システム単体での最適化を目的としてしまう心理が働いたり，他システムとの関連や顧客への影響がわかりにくくなったりします．このことは，LeSS でいうところの プロダクト全体の観点 や 顧客中心的 といった価値観の促進を阻害してしまいます．
この問題を解決するためのアプローチとして最初に取られるべきなのがプロダクトの定義の明確化です．プロダクトの定義が明確になることで，プロダクトを構成する各サブシステムが最終的にどのような価値を顧客に提供するのかを明らかにし，この定義に従ってプロダクトバックログの作成や詳細化，価値ある単位へのスライスが可能になります．
なぜ，より広いプロダクトの定義が好まれるのか
プロダクトの関心や価値の範囲は，可能な範囲で広く取る ことを LeSS は推奨しています．
例えば，大規模な EC サイトの開発を例に取りましょう．EC サイトの運営には大雑把に言うと大きく2種類のシステムが必要になります．ひとつは商品を購買するエンドユーザーが回遊し，商品をカートに入れ，チェックアウトを行うフロントサイトであり，もう一方は在庫や価格を管理するために， EC サイトを運営する企業の担当者が利用する商品管理システムです．
ここでプロダクトを「EC フロントサイト」と捉えるのが狭いプロダクトの定義であり，「EC フロントサイトと管理システム」と捉えるのが広いプロダクトの定義です． どちらの定義でも，エンドユーザーに多くの購買行動を EC サイト上で起こしてもらうことで収益をあげよう，としている点は同じですが，そのアプローチとして取れる範囲が両者の間では異なります．
仮にプロダクトの定義を狭く取り，フロントサイトの開発に最適化した組織があったとしましょう．フロントサイトでストレスなく驚きや楽しみを与えるユーザーインターフェース (UI) を提供することで顧客のアテンションを惹き，ショッピングが楽しくなる環境を作り上げたとしても，そこに並ぶ商品自体が魅力的でなかったり，頻繁に欠品を起こしていたり，価格設定が不適切であったりという商品管理システムの機能不全が起きていれば台無しです．このような状況は「局所最適」と呼ばれます．
プロダクトの定義を広く捉えることで，フロントサイトと商品管理システムを合わせてどのような価値や強み，魅力といったものを提供するかを決め，一貫して実現に向かうことができるようになります．これが，より顧客にとって意味のあるプロダクトを開発するために必要不可欠だということは明白でしょう．
プロダクトの定義を拡張し続けること
プロダクトの定義は広いほうがよいとは言えど，大規模スクラムチームの所属する組織や企業の構造などが妨害となって実現が難しいケースがあります．例えば，そもそもフロントサイトを開発する部署と商品管理システムを開発する部署が分かれていたり，開発拠点が物理的に離れていたり，どちらかのシステム (または両方) の開発をアウトソースしていれば，プロダクトの定義を広く取って全体最適を図ることは難しくなります．
また，スクラムチームのスキルの範囲が限られているために，理想的な広いプロダクトの定義を持ってプロダクトに携わることが出来ないケースも多いでしょう．フロントサイトでリッチなユーザーインターフェースを実現するスキルも，スマートフォン向けのネイティブアプリを開発するスキルも，堅牢なな商品管理システムを構築するスキルも，収益効率を改善する価格設定アルゴリズムを実装するスキルもそれぞれ専門性が高く，一つの組織が持つスキルのバリエーションを増やすことは比較的長期的なスパンで考えなければならず，一朝一夕に実現はできません．このことは多くのソフトウェア開発者にとっては想像に難くないでしょう．
このような状況で LeSS が提唱しているのは，大規模スクラムの開始時点では現実的な範囲で組織が対峙するプロダクトを定義し，その後に定期的にその定義を見直しながらプロダクトの定義を継続的に拡張し，理想的な広さに近づけてゆくという方法です．これはさながら，スクラムチームが成熟するとともに 完成の定義 が拡張されてゆく現象と類似しますが，プロダクトの定義を拡張するということは組織の構造自体を変更する必要が生じるため，完成の定義の拡張よりは難しくエネルギーを要することだと述べられています．
ということで，興味を持った人は読んでみてください． (というかぜひ一緒に読みながらディスカッションしてくれる人とかいたら嬉しい)
Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn))
- 作者: Craig Larman,Bas Vodde
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2016/08/20
- メディア: ペーパーバック
- この商品を含むブログを見る
スウォーミングとは何か，なぜやるか
スウォーミングとは何か
スウォーミング (Swarming) とは，無数の虫が何かの場所や標的に群がって何かを行うことであり，ソフトウェア開発の文脈では，一つのタスクや開発トピックにチームの全員 (全員ではなくても，多人数) で取り組むことを指します．
最近しばしば話題に上がるモブ・プログラミングも概念としてはスウォーミングのひとつといえますが，もっと幅広く，ひとつのユーザーストーリーにチーム全体で取り組むことがスウォーミングという言葉がソフトウェアの文脈で一般的に指す活動です．
ソフトウェア開発チームは，一度のタイムボックス (スクラムに習って スプリント と呼びます) で複数のユーザーストーリー (例えば 注文の一覧を表示する というユーザーストーリーと，1つの注文の詳細情報を表示する というユーザーストーリー) に取り組むかと思います．
1つのユーザーストーリーを実現するためには複数のタスクをブレイクダウンできるでしょう．(例えば 注文の一覧を表示する というストーリーなら， デザインの決定, 一覧として表示する注文の定義の確定, プロダクトコードの実装, 単体テストの実装, 手動テスト とか) スウォーミングでは，これらのタスクをチーム全員で取り組みます．このときに重要なのが，チームが並行して複数のユーザーストーリーのタスクに取り組むのではなく，一度に (できるだけ) ただひとつのユーザーストーリーのタスクのみに取り組みます．
例えば 注文の一覧を表示する というユーザーストーリーの実現に取り組み始めたら，理想的にはチームの誰ひとりとしてその他のストーリーには取り組みません．まずチーム全員で デザインの決定 をする中で実装の詳細なポイントについてチーム全員で理解した後，プロダクトコードの実装 を行ったり，テスト実装が得意なメンバーがテスト駆動開発に疎い開発メンバーと一緒に テストコードの実装 を行ったり，仕様に詳しいメンバーが 手動テスト のテスト観点を洗い出したりテストを実施したりします．
なぜスウォーミングをするのか
「一度に複数のストーリーを並行して開発したほうが効率がいいんじゃないの？」と思う気持ちになる人がいて当然だと思うし，その人達にとって「スウォーミングだなんて効率が悪そう！」と思うのも無理はないでしょう．では，なぜスウォーミングをするのでしょうか．
完成までのリードタイムの短縮
チームが1スプリントに完成させるべきユーザーストーリーが3つあって，その3つをチームメンバーの間で分担して並行して取り組み，全てスプリントの最後に完成させるとなると，それぞれのユーザーストーリーのリードタイムは1スプリントの最初から最後までとなってしまいます．
どのようなプロダクトに取り組んでいるかにもよりますが，リードタイムを短くして，機能の一部でも素早く価値を実現させるステージまで持っていく (リリースをしたり，顧客の目に見えるところに持っていくなど) ことで，チームがプロダクトやプロダクトの取り組む問題について高速に学習することが出来るようになります．そのため，まずひとつのユーザーストーリーを全力で実現して，プロダクトのフィードバックを得ることがスウォーミングをする大きなモチベーションです．
手戻りの改善
作業を工程に分けることで，認識や想定の違いや，ある工程での設計上想定していなかったことが見つかったりすることで，手戻りが発生します．手戻りが発生すると，その分機能開発が完了するまでのリードタイムが長くなります．
例えば，最初の1週間をサーバーの API 開発に使い，次の1週間にウェブフロントの開発を行うとします．ウェブフロントの開発をする中で想定していなかった例外ケースに出くわしたり，API に項目の追加が必要になったりすることで，すでに完成したはずの最初の1週間の API 開発の大部分を見直す必要に出くわした経験のある人は多いでしょう．
このような手戻りに遭遇すると，「手戻りが発生しないように設計をしっかり行ってドキュメントを充実させよう」と考えることも出来なくはないですが，結局リードタイムを長引かせてしまうので，あまり良い策とはいえないでしょう．逆に，このような想定外が生じることを想定し，手戻りが起きてもダメージが少なく，リードタイムも伸ばさないように，チーム全員でひとつのユーザーストーリーに取り組み，ひとつのユーザーストーリーの粒度を大きくなりすぎないようにすることが重要になります．
知識移転の促進
チームでのソフトウェア開発を計画する上で，「この仕事は〇〇さんしかできない」というたぐいのものがあると思います．「ネットワークはあの人しかできない」などという制限がチームの開発の流れをよくすることを阻害します．知られた言葉をつかうなら「ボトルネック」というやつです．
技術的に限られたメンバーしか持っていないということにチームが自覚的であるならまだ良いのですが，それがいつしか「このタスクはこの人がやるもの」と前提にすらなってしまうことすらあるでしょう．その制限を意識的に崩すのがスウォーミングです．共同作業をすることでメンバー間での知識移転を促進し，知識やスキルのボトルネックを除くことが，スウォーミングを上手くやることで可能になります．
まとめ
スウォーミングとは何か，なぜそれを行うのか，について書いてみました．
また別の稿で，具体的にどのようにスウォーミングを実施するのかについての自分が経験してきたテクニックを書ければと思います．
非スクラムチームに贈る「ふりかえり」の処方箋
最近のソフトウェア開発チームの多くは，スクラムのフレームワークを適用していなくても，いわゆる「アジャイルなプラクティス」に則ったイテレーティブな開発スケジュールを持っている組織が多いのではないかと思います．
自分もそのような組織に幾つか属してきた中で，周囲のやり方やインターネット上で見られる事例を形だけ適用してイテレーション *1 の「ふりかえり」*2 を行っているもののうまくいかない，という組織をこれまで多く見てきました．本稿では，特にスクラムには特に精通していないチームに向けて，スクラムから得られる知見や，自分がこれまでスクラムに取り組んできた中での経験を元に，よく見受けられるパターンと，それに対する処方箋をまとめようかなと思います．
時間内に議論が収まらない
チーム規模やイテレーションの長さに対して，どういうことが起きたか，何が問題だったか，どう改善するかという話が，予め予定したタイムボックスで終わらないというケースを良く目にします．
スクラムのルールを規定している Scrum Guide では，1ヶ月のスプリントの場合，スプリントレトロスペクティブの長さは最大4時間まで と定義しています．
単純計算が成立するのかも議論するべきポイントかもしれませんが，例えば1週間のスプリントのふりかえりを30分でやって足りている感じがしないという場合，「単純計算で言えば最大1時間使っても不自然ではない」と思うのも一策つかもしれません．組織によっては，「会議は1時間でスケジューラ上の予約する」のが暗黙的なパターンになってるといったケースも多いかと思いますが，それに引っ張られないことが大事だと思います．
スクラムのパタン・ランゲージをまとめている Scrum Pattern Community も，スプリントレトロスペクティブについて 「たっぷりと時間を取らないと，問題の根本にあるより深い問題にまでたどり着くことができない」と解説しています．
原則として会議は短いに越したことはないし，チーム全体のファシリテーションスキルが高ければ短い時間で収めることも可能でしょうが，ふりかえりに関しては長く時間を取って，タイムボックスを守るプレッシャーを比較的少なくするほうがチームの改善を促す観点では得策なのかなと思っています．
ふりかえりに参加するステークホルダーの苦しみを聴くのに心が痛む
例えば組織の中に，ソフトウェアを開発するチームと，そのソフトウェアを用いて収益を上げるビジネスチームがあり，ソフトウェア開発を行うという文脈でふりかえりを行うとします．ふりかえりにビジネスメンバーが参加し，「xxx の機能がないから営業がはかどらない」とか「xxx の機能が欲しい！」という改善要望や問題点が挙がり，ソフトウェアの開発者やリーダーが心を痛めたり，「そんなの言ったって人手が足りないよ」という気持ちになってしまったり，エンジニアは技術的な改善について議論したかったり，というケースが有ると思います．
スクラムには，スプリントを終了させるときに行うイベントが2つあります．ひとつは「スプリントレビュー」，もうひとつが「スプリントレトロスペクティブ」です．この2つには明確な違いがあります．
スプリントレビューは，チームの外側にいるステークホルダを呼び，スプリントの成果を確認した上で，プロダクトを良くするためには今後どうするべきかをスクラムチームとステークホルダーを交えて議論することが目的です．
一方で，スプリントレトロスペクティブでは，参加者はスクラムチーム *3 のみで，話題とするのはチームの生産性についてです．
特に組織が「エンジニアリング」と「ビジネス」に分かれている場合，この2つを適切に使い分けることが重要なのだと思います．当然ながらエンジニアとビジネスがプロダクトについて会話することも大事ですが，それを行う場を「ふりかえり」と称し，エンジニア単体でエンジニアリングの問題点について話す場所がなくなってしまうのを防ぐのが重要だと思います．
リードメンバーの独壇場になってしまう
他のメンバーが頭を捻って考えたアクションや改善策を，技術的に長けたリードエンジニアが否定してしまったり，チームリーダーがトップダウンで解決策をバンバン挙げてしまうケースもしばしば見受けられます．短期的な問題解決という意味では悪くないのかもしれませんが，チーム全体の学習の促進や，変化に対応した自己組織化されたチームを作るという長期的な視点では問題となるケースが有るでしょう．
技術や業務知識でチームをリードしている人が体制上チームリーダーとなることは何も問題は無いでしょうが，仮に彼らがファシリテーションスキルを充分に持ち合わせていない場合，リーダーだからとふりかえりの司会にしてしまうことは良い選択とは言えません．
スクラムでは，「プロダクトオーナー」という役割と「スクラムマスター」という役割が分かれていることで，取り組むプロダクト開発について責任を持つ役割と，ファシリテーションスキルを発揮してチームの自己組織化を手伝う役割が分かれています．ふりかえりに特化して言えば，聞き役に回れるような人を「チームリーダー」とは別にファシリテーターとして置くことは検討に値するでしょう．
また，ファシリテーターをチームメンバーが順番に担当することで，チーム全体のファシリテーションスキルを向上させるのも良い取り組みだと思います．このときに注意するべきなのは，ファシリテーション自体に対して継続的にフィードバック出来る人がチームにいて，ファシリテーターを順番に回すのも単なる「当番」や「仕方なくやるべきこと」なのではなく，ファシリテーションスキル向上という目的が共有されていることだと思います．
ふりかえりで出た改善アクションが取り組まれない
ふりかえりを始める際に，前回のふりかえりでチームが決めた改善策やアクションが全く取り組まれていないケースが多くあります．この状況を改善するためにチェックするべきポイントは2つあると思います．
改善策は「実行可能」か，または「追跡可能」であるか
「xxx に気をつける」「xxx するようにする」という改善策は，どうなったら完了したと言えるかが分からない点で「アクション」ではありません．振り返りで決めた「アクション」は，次のイテレーションでのタスクの1つとして「取り組んだ」か「取り組めなかった」かを明らかにできるようにするべきです．
2017年の Scrum Guide の改訂では，スプリントバックログの中に，前スプリントのレトロスペクティブで上がった改善策のうちの優先度の高いものを少なくとも1つ含めるべきだという記述が追加されました．これはスクラム実践者の中でも好みが分かれるところですが，常にチームの見えるところに置かれるスプリントバックログやカンバンにアクションが書いてあり，デイリースクラムでその取組を確認できるようにするというのは現実的な解決策だと思います．
また，アクションではなく，なんらかのメトリクスに落とし込むことも解決策でしょう．例えばチームがソフトウェアの機能開発をする際に自動テストを書かないという問題が上がったとしたら，「テストを書くように気をつける」のではなく，「各機能開発時に追加された自動テストのテストケースを可視化する」という解決策で，実際に書かれたテストケースを追跡可能にするのは，アクションの第1歩として有効でしょう．まずは現状を可視化して，チームの意識や認知に働きかけるという作戦です．
ここらへんの「振り返りの続け方」に関しては，中村洋さんが Regional Scrum Gathering Tokyo 2018 にてトークした 「ふりかえり」の始め方と続け方 // Speaker Deck が大いに参考になるかと思います．
ふりかえりで出したアクションで全てを解決させようと期待しない
これは個人的に大事だと思っているのですが，ふりかえりで上がる問題には，1つのアクションを実行することで簡単には解決しないような問題も多くあるのではないかと思います．そんなときに大事なのは，ふりかえりで全ての解決策を考えたりするのではなく，少し問題を和らげるファーストステップをアクションとしてまず取り組んでみることだったり，複雑でまだチームが原因を理解しきれていないな問題を少しでも明らかにするためのアクションを考えることなのではないかと思います．
結論
ということで，「なんとなくやっているふりかえり」から「上手く回るチームのふりかえり」に昇華させる方法として最近自分が感じていることを挙げてきました．チームがスクラムに取り組んでいないとしても，スクラムのプラクティスの背後にある価値観や原則を知ることで意図を理解することは有用なんじゃないかと思います．
「みんなやっているから」とか「以前からやっているから」という理由でふりかえりに惰性で取り組むことは簡単ですが，少しコツを得ることで良くすることが出来るのではないかと思います．
自分がかつて所属した組織でやってたレトロスペクティブに関しては，以下のような記事も書いているので，参考にしてみてください．
