Cultural Capital Theory in Software Engineering

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

ビジネス書大賞と技術書大賞の２つを受賞した初めての書籍

Slide 4

Slide 4 text

ソフトウェアエンジニアリングも組織設計もビジネスの一部。この二つは不可分じゃないか。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

本日は、良いエンジニアリング組織がつくられるマクロな機序についてお話しします。

Slide 10

Slide 10 text

© rector,inc エンジニアの「表現」と非エンジニアの「解釈」のズレ https://twitter.com/noumin_T/status/1135013683577335809 実際には、これは言葉に変換する前に、ものごとを経験的・直感的に好ましい、好ましくないで捉えた心的性向。何らかの職人は、この種の内面化した「心的性向」を持ち、これらが仕事を共にすることで、暗黙的な実践知を伝搬してきた。これをブルデューはハビトゥスといった。そのため、何も変換せずに思ったことを話してしまうと、好き嫌いを話しているように見える。「じゃあ、そういえばいいじゃん」

Slide 11

Slide 11 text

© rector,inc 「好き嫌い」の思考の癖、これが習慣になり文化に変わる良い思考の癖悪い思考の癖とりあえず、やってみよう。ダメならやめたらいいじゃんうちの会社/ ぼくたち / おれたちもっといいやり方がないか考え続けよう。うまくいかなかったことを学習して次に生かそう。前例は？失敗しないことを説明して。この会社/ あの部署 / あいつらこれまでのやり方を守っていこううまくいかなかったことを隠そう。

Slide 12

Slide 12 text

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

© rector,inc 人材のブラックホール現象はこの原理による良い組織には、良い文化資本があつまっている。それは、何らかの「習慣行動」の違いによって現れる。そこから、その価値観を良いと思う人があつまり、さらに文化資本を強化する。そのため、雪だるま式に人材のレベルと文化資本が上がっていく。良くない組織は、良くない文化資本が集まり、悪い人材が集まっていく。これもまた雪だるま式に崩壊していく。文化資本の発露に人は集まる。

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© rector,inc 「よい習慣」は合理的に説明できるわけではない今では考えられないがかつては、「ユニットテストを書くべきか、書いた方がコストがかかる」という議論があった。今でも、場所によってはそのような議論が存在する。だが、現在では「馬に乗って通勤する人がいない」くらいには常識的なことになった。これはユニットテストを書くことが常識になっていき、過剰なほどにテストに工数を費やさずに済むようになったことで体感的なメリットが理解されていった。ユニットテスト・CI/CD 今では考えられないがかつては、「プログラマが使う端末が貧弱で、キーボードも選べない」という環境があった。この際に、総務やバックオフィス部門の管理コストの高さとエンジニアの生産性向上を比べて、合理的であることを説明する必要がった。だが、現在では、ある程度のスペックのPCをエンジニアに与えるのは、「陸軍に竹槍を持たせる人がいない」くらいには常識的なことになった。人的資源の価値が他の業種よりも生産性に劇的な差をもたらすため、コストではなく競争優位で比較するから。高スペックPCの貸与

Slide 19

Slide 19 text

© rector,inc これはエンジニア自身にとっても自明ではない。実は、多くプラティーク（習慣的行動）は、それを形だけ真似てもすぐには意味がない。むしろ悪化することすらある。そのため、ソフトウェア工学では、ある習慣に価値があるかどうかを対照実験することが難しかった。たとえば、TDDに慣れていない人に、TDDをやらせて、そうでない場合と比較しても優位な差が出ないどころかマイナスにもなることは想像に難くない。自転車は乗り始めから、走るより速いわけではない。しかし、TDDに習熟したチームは生産性が高くなると経験的に知られている。これは、形から入ったとしても、目的を持ってやり続ければ習熟し、高いレベルになるだから「形から」入るでも価値があるスクラム DevOps/IaC 犠牲的アーキテクチャペアプロトランクベース開発進化的・漸進的設計フィーチャーチーム OKR/1on1

Slide 20

Slide 20 text

© rector,inc 守・破・離とは懐疑的に考えつづけること守破離は千利休の言葉をまとめた利休百首から引用：禅宗の影響をうける利休は、体感を大事にしつつも、思考停止に陥らず、目的を持って考え続ける哲学であった。思考停止は「守」ではない良い思考の癖悪い思考の癖もっといいやり方がないか考え続けよう。これまでのやり方を守っていこう規矩作法守り尽くして破るとも離るるとても本を忘るなもとよりもなきいにしへの法なれど今ぞ極る本来の法炭置くも習ひばかりに拘はりて湯のたぎらざる炭は消え炭

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© rector,inc たとえば、サービスデプロイメントの数コード修正の心理的安全性開発者数が増えるごとに、生産性の高い組織群はデプロイ頻度が増加する。それに対して、低いパフォーマンスの組織は、開発者数が増えるごとにデプロイ数が低下していく。そして、開発者数もスケールしなくなる。そのため、マイクロサービスのようにシステムを疎結合に分解して、デプロイしやすい構造にしたり、自動テストの効率を上げていく。また、組織文化もミスに対して他罰的・権威的にならず、修正しやすい環境を用意している。 ※ Lean と DevOpsの科学(p.78)

Slide 24

Slide 24 text

© rector,inc たとえば、サービスデプロイメントの数おおよその目安としてのスコアたとえば、60人のエンジニアがいて、1ヶ月（20営業日）あたり 150回のデプロイ回数の会社を考えてみる。 150 / 60 / 20 = 0.125 > 0.1 と計算できる。およそ、一人のエンジニアが１０営業日でつくった差分が、一度デプロイされる計算になる。結合度の高いサービスやトランクベース開発のできていないシステムだとすぐにこのスコアが悪化する。 DevOpsスコアデプロイ数 (Deploys）開発者数 (Developers) 営業日数 (Days) = > 0.1

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

よい文化資本が蓄積する企業とそうでない企業の差はどのように生まれるか。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

コミュニケーションの難易度の差がエンジニアリング組織構築の難易度を決める

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

常識のズレを埋め立てていくとソフトウェアが完成しやすくなる

Slide 34

Slide 34 text

© rector,inc Skill Spectrum: B2B SaaSの場合 P/L B/S Engineering Manager Engineer UX Designer Sales BizDev Product Manager Marketer Current Future プロダクトの意思決定は、将来投資と現在のビジネスとの両端を持つスペクトラムになる。それぞれに持つべきスキルセットや常識が異なるので、隣接領域の知識を持つものとしかコミュニケーションが成立しない。

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© rector,inc Skill Spectrum：B2B SaaSの場合 P/L B/S Engineering Manager Engineer UX Designer Sales BizDev Product Manager Marketer Current Future グルーとなる人材がいれば、コミュニケーションの健全性は保ちやすい。しかし、人数が増える分コミュニケーションロスは発生しやすい。チームとしての成熟に力を入れる必要がある。

Slide 37

Slide 37 text

© rector,inc Skill Spectrum：B2B SaaSの場合 Engineering Manager Engineer UX Designer Sales BizDev Product Manager Marketer P/L B/S Current Future 人数が少なくても、相互理解ができる領域が広い方がコミュニケーションの齟齬は小さくなり、うまく行きやすい。反面、広い範囲のスキルを持つ人材の採用は難しい。

Slide 38

Slide 38 text

そうなると一様な人々でソフトウェアを作ればよいのか。

Slide 39

Slide 39 text

そうなると今度は、イノベーションがうまれない。

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© rector,inc ソフトウェアエンジニアは製造の「原材料」だと思われた日本のIT最大の錯誤の原点日本の製造業の強い時代にIT化は進んだ。そのため、全ての新しい産業や技能は、製造業的文脈で捉えられた。製造業小売のバリューチェーンは非常に長く常識の差も大きいソフトウェアを作る技能は、「製鉄」などと同じく、各社のコアコンピタンスではなく、調達するべき原材料ととらえられた。つまりソフトウェアは、一つの会社に集めて、各社のソリューションを提供する形の方がメリットがあると考えられたのだ。結果、各企業は発注能力もソフトウェアプロダクトのマネジメント能力も欠如してしまった。ユーザ企業A ユーザ企業B ユーザ企業C ベンダー企業必要な分だけ調達必要な分だけ調達必要な分だけ調達

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

企業の生産性は、組織の文化資本の中に宿る。

Slide 50

Slide 50 text

ソフトウェアはそれを修正する企業のウェットウェアの顕現。ハードウェアの付属物ではない。 wetware  software  hardware 

Slide 51

Slide 51 text

ウェットウェアが欠如するとソフトウェアはどうなるのか。

Slide 52

Slide 52 text

技術的負債。毎年１２兆円の損害。

Slide 53

Slide 53 text

システムに対して、組織がコントローラビリティを喪失すると技術的負債と呼ばれる

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

ただ、古いシステムのことを技術的負債と呼ぶのではない。組織が必要な速度で変更できる能力を失うことが負債

Slide 57

Slide 57 text

Slide 58

Slide 58 text

組織が文化資本を失うとシステムはコントロールできなくなる。

Slide 59

Slide 59 text

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

エンジニアとビジネス「当たり前」「常識」の垣根が減るとこれらの説明コストが減少していく