２つのDXと技術的負債-YAPC Tokyo 2019

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© rector,inc 自己紹介 2008年度に新卒第1期としてミクシィに入社。メディア統括部部長、開発部部長、サービス本部長執行役員。組織改革の戦略・実行を行う。2015年同社を退社。 2016年「CTOのノウハウを広く世の中に還元する」ことを目指し、レクターを創業。 2018年2月エンジニアリング組織論への招待上梓。第6回ブクログ大賞ビジネス書部門大賞受賞。 ITエンジニアに読んでもらいたい技術書10選に選ばれる。広木大地(ひろきだいち)

Slide 3

Slide 3 text

© rector,inc 自己紹介 EMFM Podcast エンジニアリングマネージャのためのポッドキャスト。 13エピソード公開中で、現在、20000再生を突破。 EMFM Meetupという公開収録イベントで200人の会場が即日で集まった。 Qiita エンジニアリングに関するノウハウを集めるサイトQiita において、2019年現在、第2位。トータル39記事で41800いいね/20000ブクマ。その他パブリック活動

Slide 4

Slide 4 text

Slide 5

Slide 5 text

ビジネス書 or 技術書

Slide 6

Slide 6 text

ビジネスと技術

Slide 7

Slide 7 text

Slide 8

Slide 8 text

ソフトウェアエンジニアリングも組織設計もビジネスの一部。なぜ、二つに分けて考えるのか？

Slide 9

Slide 9 text

私たちは一体、何をしているのだろうか？

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© rector,inc 多くの不確実性に応えられるチームほど生産的抽象的で不確実な要求を、細かくて具体的な指示に分解しなければ、実施することができないチームは、上長の情報処理能力がボトルネックとなるため、高度に生産的なチームにならない。リーダーとメンバーの格差が大きすぎるとこのようなチームになりやすい。 ❶マイクロマネジメント型不確実な要求をそのまま受け取って具体的なアクションに展開できる組織が不確実性を処理するという観点では、生産的になる。チームとリーダーとの格差が減ってきて、権限が委譲されていること、チーム内のコミュニケーションが進んでいるとなりやすい。自己組織化と呼ばれる。 ❷エンパワーメントチーム型

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© rector,inc コミュニケーションとは？物事を実現していく過程で必要とされるコミュニケーションとは： ● 自分は知っているが相手は知らないこと ● 相手は知っているが自分は知らないことこれらの差を解消していくことである。このように、立場の違う二者で異なる情報を持っている状態を情報の非対称性と言います。シンプルにコミュニケーションをこの非対称性の解消だと定義します。情報の非対称性を削減すること

Slide 15

Slide 15 text

© rector,inc コミュニケーション能力についてコミュニケーションを「情報の非対称性の解消」として定義すると、コミュニケーション能力とは、「より非対称性が大きい状態でも解消できる力」になる。気の合う仲間と仲良くできるのは当たり前で、異なる常識を持つ集団（ダイバーシティの高さ）にどれだけ対応できるのかという能力がコミュニケーション能力だと理解できる。仕事で関わるメンバーどうしの認識に隔たりがあると、仕事は進捗しません。この認識のズレをコミュニケーションの不確実性（通信不確実性）と言います。常識の距離が近い人ほど簡単

Slide 16

Slide 16 text

© rector,inc 組織人数に対してリニアに情報処理能力はスケールしない少ない人数のときには、気にならないが多くの人数が相互に交流して認識を揃えていくと、調整コストの占める割合が大きくなる。組織構成のマジックナンバーとしては、同一の目的を持つチームを構成する人数が10人同一の事業を持つ人数が150人（ダンバー数）を超えたると顕著な生産性への影響を感じるようになります。人数の２乗のオーダーで交流が発生

Slide 17

Slide 17 text

© rector,inc ソフトウェアづくりはコミュニケーションそのものプログラミングは理科系的な数理的なという側面を受け取られがちだが、実際には ● 複数人の認識を揃えながら ● 機械が理解できるほどブレのない明晰な文章を ● 将来の不確実な要求に耐えられるように構成し、 ● 共同で継続的に管理するというプロセス。人文的な側面で言えば、立法行為に近いものだと考えると理解しやすい。コミュニケーションが大事どころか、「コミュニケーションそのもの」機械が理解できるほど明晰な言語化

Slide 18

Slide 18 text

© rector,inc しかし、「他人と未来」に向き合うのは怖い怒りは攻撃的行動の最たる例です。異分子だと認識しているもの（わからないもの）にいきなり、自分の立場をあやうくされるようなことをされると怒り出す人がおおいです。様々な理屈を述べますが、怒りは「自分の大切にしているものを、攻撃された」と感じる時に発生します。変化に対して弱い人は他人に対してマウンティング、威圧、冷笑などをつかって、異分子を攻撃しようとします。組織は新しいこと/ものを恐れるようになります。攻撃的行動(Fight) 目標に対する有形無形の圧力が大きい場合、その不確実性への恐怖が問題を隠蔽する方向に機能します。たとえば、納期の圧力大きい状態ではマネージメントから真実の情報は隠蔽されるようになります。プロジェクト終盤で、問題が頻発するのは、このように問題を隠す文化が醸成されたことによります。このような監視者と作業者の間に生まれる無駄をエージェンシースラックと言います。人間の無意識の恐怖が、回避行動となって問題の解決を遅らせていきます。防御的行動・回避的行動(Flight)

Slide 19

Slide 19 text

© rector,inc 学習を促す心理状態になれば、本能を克服できるチームの生産性を上げるポイントして心理的安全性が取りざたされるが、レイオフしやすい北米と日本を一元的に比較するのは乱暴である。チームが問題を隠さずに、その問題に向き合うようにいかにして導いていくかがポイント。あくまで、生産性の向上のために、心理的安全性が必要なのであって、心理的安全性があるから生産的なわけではない。甘やかしと学習は違う。相互の期待値が高く揃う状態を目指す。責任と心理的安全性の４象限

Slide 20

Slide 20 text

© rector,inc 本能的機能は組織にも適応される：ゲシュタルト原則近接地理的に近い集団を仲間だと思う似ている種類の集まりを仲間と思う近接した複数の要素をグループ化して捉えるという人間の特性があります。これはデザインだけでなく組織においても同じで、地理的な近接を仲間と思うような特性があります。類同類似した性質＝情報的な距離が小さい集団を仲間と思います。たとえば、同業種の人同士が交流することが増えるというような特性です。そして人には仲間じゃないと思うものを排除しようとする本能があります。

Slide 21

Slide 21 text

問題は、私たちの本能が悪く作用する「構造」にこそある。

Slide 22

Slide 22 text

悪い「構造」を良い「構造」に変えるリファクタリング。

Slide 23

Slide 23 text

バグを憎んで人を憎まず

Slide 24

Slide 24 text

Slide 25

Slide 25 text

それってポエムでしょ？

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© rector,inc コード解析より精度の良い組織解析コード解析によるバグ予測組織構造解析によるバグ予測 < MSRのプレゼン：http://www.slideshare.net/tom.zimmermann/empirical-software-engineering-at-microsoft-research 組織階層の深さ関わっている組織の数退職者の数関係者の地理的距離コードの複雑さコードの変更量依存関係の複雑さテストカバレッジ

Slide 28

Slide 28 text

生産性、品質、コストのトリレンマを超える。 C D Q

Slide 29

Slide 29 text

Slide 30

Slide 30 text

組織構造とソフトウェア

Slide 31

Slide 31 text

組織構造とソフトウェアシステムを設計する組織は、その情報伝達の構造をまねた設計を生み出してしまう｡メルヴィンコンウェイ “

Slide 32

Slide 32 text

© rector,inc 組織構造はコミュニケーション構造そのもの組織構造というと、ラインを構成するハイアラーキだけをイメージしがちであるが、ある仕事がどこから生まれて、どこに引き渡されていくか、誰と交流していくことによって成り立つかから作られる交流のネットワークが組織構造。それは明示的なもの・暗黙的なもの・非公式なものも含む。組織の成果と誰が何をしているかを知っているというトランザクティブメモリーが生産性に寄与することが知られている。誰が誰と交流して仕事が成り立つか

Slide 33

Slide 33 text

© rector,inc 組織とソフトウェアは同じ構造に変化しやすいシステムにおける問題は、組織構造上の問題が多く潜んでいる。この長らくソフトウェアエンジニアから支持されていた経験則は、実証的研究からも多くの証拠が見つかっている。たとえば、関わる人々の地理的関係からソフトウェアのバグの発生しやすい箇所を特定するなどコンウェイの法則システムを設計する組織は、その情報伝達の構造をまねた設計を生み出してしまう｡メルヴィンコンウェイ “ 組織構造システム

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© rector,inc 取引コストによって、会社・組織の境界線が決まるある経営上のリソースを市場から手に入れるのか(取引コスト)、それとも企業内部に構築するのか(内部化コスト)を取引コスト理論の観点で見てみると、会社組織の境界線を決めるラインが見えてきます。　内部化コストが高く、取引コストが安いものについては、企業外部から調達し、取引コストが高く、内部化コストが低いものは、企業内部に構築することが望ましいということがわかります。　この構図は、エンジニアリング機能を必要とする組織にとっては、「何を外注し、何を内製するのか」を決定づける構図であると理解することができます。　内部化コスト > 取引コスト取引コスト > 内部化コスト市場取引長期取引戦略連携組織取引企業外部企業内部

Slide 37

Slide 37 text

変えようとするとコストが非常にかかるものと簡単にできるもの

Slide 38

Slide 38 text

アーキテクチャ

Slide 39

Slide 39 text

© rector,inc 組織設計とアーキテクチャの関係技術的負債プラスの価値マイナスの価値アーキテクチャ組織システム取引コストが低く情報処理能力が高い組織取引コストが高く情報処理能力が低い組織コンウェイの法則が示すように、組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。また、その逆に優れたシステムの構造が、良い組織構造を生み出すことも起こり得ますし、同様に技術的負債が組織の悪しき硬直性を生み出すことも起こり得るのです。その意味で、組織とアーキテクチャには密接な相互関係があります。

Slide 40

Slide 40 text

© rector,inc 逆コンウェイ作戦とマイクロサービシズ技術的負債プラスの価値マイナスの価値アーキテクチャ組織システム取引コストが低く情報処理能力が高い組織取引コストが高く情報処理能力が低い組織コンウェイの法則が示すように、組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。また、その逆に優れたシステムの構造が、良い組織構造を生み出すことも起こり得ますし、同様に技術的負債が組織の悪しき硬直性を生み出すことも起こり得るのです。その意味で、組織とアーキテクチャには密接な相互関係があります。コンウェイの法則逆コンウェイ作戦 microservices

Slide 41

Slide 41 text

ビジネスのアーキテクチャ & ソフトウェアのアーキテクチャ

Slide 42

Slide 42 text

© rector,inc よくすることができる＝交換可能選択肢を持つ側と選択される側の関係には、一方向には権力が、その反対には依存という関係が成り立ちます。より良いものに交換できる側であれば、選択肢を持たない側に対して「権力」を発揮できます。逆に選択肢を持たないと、「依存」が生まれ、結果的に理不尽を受け入れます。この依存による理不尽が技術的負債の正体で、交換可能であるというメリットがアーキテクチャの正体です。選択肢を持つ側から権力が働く依存権力選択肢を持つ側選択肢を持たない側

Slide 43

Slide 43 text

Slide 44

Slide 44 text

システムは時間を経ると次第に交換できなくなり、コントロールを喪失する。

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© rector,inc System Control Level：システムのコントローラビリティレベル Culture チーム文化レベルチームで抽象レイヤのユビキタス言語が共有され、周辺システムと競合環境などから適切なプロダクト開発が自律的にできる状況 Architecture アーキテクチャレベル優れたアーキテクト人材がおり、業務要求に対して安定した開発出力を出すことができる設計と開発チームのレベル Code ソースコードレベル直接契約の複数フリーランサーまたは自社人材によって、ソースコードの内容が把握されていて、変更が可能である状態。 Spec 外部仕様レベル単一また少数のベンダーに依存しており、自社では外部仕様レベルしか把握できていない状態。ベンダーロックインと呼ばれる状態。 Chaos 制御不能レベルどのベンダーもソースコードを把握しておらず、自社では完全な外部仕様も持っていない状態。リバースエンジニアリングするしかない状態 5 4 3 2 1 技術的負債の最たる例はシステムのコントロール性の喪失として現れる。これを経営学では「ホールドアップ状態」と呼ぶ。

Slide 47

Slide 47 text

コントロールの喪失によるホールドアップリスクはありふれた経済現象である。

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

なぜ、多くエンジニアは「技術的負債現象」として表現さざるを得なかったのか

Slide 51

Slide 51 text

© rector,inc 見ることができないという非対称性が問題の根本非エンジニアにとって視界エンジニアから見た視界システムに関して、エンジニアと非エンジニアの視点は違います。それは、CTスキャンされた図像で人体を見ているか、肉眼で表面的に見ているかというくらいに違います。非エンジニアは外側から見たシステムの様子しかうかがい知ることができません一方、エンジニアからはCTスキャンを通すように内部の構造を理解しています。であるからこそ気がつく病魔の兆候も、非エンジニアには伝わりません。この非対称性が、技術的負債が問題になる最大の理由であるといえます。

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© rector,inc 技術系組織の進化パターン職能別組織事業部組織ユニット型組織 CEO ビジネス組織技術組織技術組織とビジネス組織を分離し、必要に応じてプロジェクトに振り分ける組織形態。技術系人材の流動的運用が可能であるが、ビジネスとの間のコミュニケーションがうまくいかず、対立構造になることがある事業部ビジネス組織技術組織 CEO 事業部事業ごとに必要な技術組織を持つやり方。技術人材の育成やキャリア形成に難がある。また、職能別組織と同じような問題も再現しやすい。事業部プロダクトチームプロダクトチームプロダクトチーム事業ごとに機能横断的なプロダクトチームを組成し、そのチームによって継続的なプロダクトマネジメントを行う。 2000年代後半から流行しはじめ、アジャイル開発の普及とともに日本でも盛んになった。横軸組織

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

エンジニア・非エンジニアの非対称性が解消されていくこと