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

「エンジニアリング組織論への招待」はビジネス書としても技術書としても評価された。これら二つは別のことなのだろうか。それをも同じものなのだろうか。

この講演では技術者体験DXと企業のデジタル化のDXの２つを橋渡ししていく。

「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の本能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。

そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。

このコミュニケーションのコスト構造をそのまま、システムの構造に当て込んでしまうというのを「コンウェイの法則」と呼ばれている。

組織構造の問題が、システムへと転移して、コントローラビリティを喪失すること。これが技術的負債の真実であるなら、これはありふれた経済現象である。

にもかかわらず、この技術的負債現象が問題になる理由は何か。
それは、エンジニアと非エンジニアに情報の非対称性があり、それであるがゆえに
非機能要件のリストに過ぎない、コントローラビリティのためのアクションをとることができない。この非対称性こそが技術的負債と呼び合う現象を引き起こすトリガーである。

つまり、これは、非エンジニアとエンジニアの非対称性の問題なのだ。

実際に、開発組織は徐々にエンジニアと非エンジニアの距離が近くなるように進化していく傾向がある。しかし、非対称性の大きさがハレーションを引き起こすので、行き来しながらも非対称性が減った組織文化が生まれる。

これこそが、高いDX = 開発者体験と企業のデジタル化を導くことになる。
つまり、これらは二つのDXは同じものである。

Transcript

1. © rector,inc エンジニアリング組織論への招待 -２つのDXと技術的負債論- 広木 大地 @hiroki_daichi
2. © rector,inc 自己紹介 2008年度に新卒第1期としてミクシィに入社。 メディア統括部部長、開発部部長、サービス本部長執行役 員。組織改革の戦略・実行を行う。2015年同社を退社。 2016年「CTOのノウハウを広く世の中に還元する」ことを 目指し、レクターを創業。 2018年2月エンジニアリング組織論への招待上梓。 第6回ブクログ大賞ビジネス書部門大賞受賞。 ITエンジニアに読んでもらいたい技術書10選に選ばれる。 広木 大地(ひろき だいち)
3. © rector,inc 自己紹介 EMFM Podcast エンジニアリングマネージャのためのポッドキャスト。 13エピソード公開中で、現在、20000再生を突破。 EMFM Meetupという公開収録イベントで200人の会場が即 日で集まった。 Qiita エンジニアリングに関するノウハウを集めるサイトQiita において、2019年現在、第2位。 トータル39記事で41800いいね/20000ブクマ。 その他パブリック活動
4. © rector,inc Perl と YAPC と 僕 YAPC Asia 2010 Perl Hackers Hub YAPC Asia Tokyo 2011
5. ビジネス書 or 技術書
6. ビジネス と 技術
7. © rector,inc ２つのDX Developer eXperience DX (開発者体験) Digital transformation DX (企業のデジタル化) ＝
8. ソフトウェアエンジニアリングも 組織設計もビジネスの一部。 なぜ、二つに分けて考えるのか？
9. 私たちは 一体、何をしているのだろうか？
10. © rector,inc 1 ２ ３ エンジニアリング組織論の骨子 何かを実現するとは、不確実性を減らすことである 不確実なものから人は闘争・防御・回避をしようとする それらを防ぐの思考と組織構造を持つと生産的になる
11. © rector,inc エンジニアリング = 不確実性を減らす試み プロジェクトも不確実性を減らす 組織も不確実性を減らしていく
12. © rector,inc 多くの不確実性に応えられるチームほど生産的 抽象的で不確実な要求を、細かくて具体的な指示に分解しな ければ、実施することができないチームは、上長の情報処理能 力がボトルネックとなるため、高度に生産的なチームにならな い。リーダーとメンバーの格差が大きすぎるとこのようなチーム になりやすい。 ❶マイクロマネジメント型 不確実な要求をそのまま受け取って具体的なアクションに展開 できる組織が不確実性を処理するという観点では、生産的にな る。チームとリーダーとの格差が減ってきて、権限が委譲され ていること、チーム内のコミュニケーションが進んでいるとなり やすい。自己組織化と呼ばれる。 ❷エンパワーメントチーム型
13. © rector,inc 人間が本質的にわからない（不確実）ものは二種類 未来：環境不確実性 他人：通信不確実性 実験による仮説検証 コミュニケーション
14. © rector,inc コミュニケーションとは？ 物事を実現していく過程で必要とされるコミュニケーションとは： • 自分は知っているが相手は知らないこと • 相手は知っているが自分は知らないこと これらの差を解消していくことである。 このように、立場の違う二者で異なる情報を持っている状態を 情報の非対称性と言います。シンプルにコミュニケーションをこ の非対称性の解消だと定義します。 情報の非対称性を削減すること
15. © rector,inc コミュニケーション能力について コミュニケーションを「情報の非対称性の解消」として定義する と、コミュニケーション能力とは、「より非対称性が大きい状態で も解消できる力」になる。 気の合う仲間と仲良くできるのは当たり前で、異なる常識を持 つ集団（ダイバーシティの高さ）にどれだけ対応できるのかとい う能力がコミュニケーション能力だと理解できる。仕事で関わる メンバーどうしの認識に隔たりがあると、仕事は進捗しません。 この認識のズレをコミュニケーションの不確実性（通信不確実 性）と言います。 常識の距離が近い人ほど簡単
16. © rector,inc 組織人数に対してリニアに情報処理能力はスケールしない 少ない人数のときには、気にならないが多くの人数が相互に交 流して認識を揃えていくと、調整コストの占める割合が大きくな る。 組織構成のマジックナンバーとしては、同一の目的を持つチー ムを構成する人数が10人 同一の事業を持つ人数が150人（ダンバー数）を超えたると 顕著な生産性への影響を感じるようになります。 人数の２乗のオーダーで交流が発生
17. © rector,inc ソフトウェアづくりはコミュニケーションそのもの プログラミングは理科系的な数理的なという側面を受け取られ がちだが、実際には • 複数人の認識を揃えながら • 機械が理解できるほどブレのない明晰な文章を • 将来の不確実な要求に耐えられるように構成し、 • 共同で継続的に管理する というプロセス。人文的な側面で言えば、立法行為に近いもの だと考えると理解しやすい。コミュニケーションが大事どころか、 「コミュニケーションそのもの」 機械が理解できるほど明晰な言語化
18. © rector,inc しかし、「他人と未来」に向き合うのは怖い 怒りは攻撃的行動の最たる例です。異分子だと認識しているも の（わからないもの）にいきなり、自分の立場をあやうくされるよ うなことをされると怒り出す人がおおいです。 様々な理屈を述べますが、怒りは「自分の大切にしているもの を、攻撃された」と感じる時に発生します。 変化に対して弱い人は他人に対して マウンティング、威圧、冷笑などをつかって、異分子を攻撃しよ うとします。 組織は新しいこと/ものを恐れるようになります。 攻撃的行動(Fight) 目標に対する有形無形の圧力が大きい場合、その不確実性へ の恐怖が問題を隠蔽する方向に機能します。 たとえば、納期の圧力大きい状態ではマネージメントから真実 の情報は隠蔽されるようになります。プロジェクト終盤で、問題 が頻発するのは、このように問題を隠す文化が醸成されたこと によります。 このような監視者と作業者の間に生まれる無駄をエージェン シースラックと言います。人間の無意識の恐怖が、回避行動と なって問題の解決を遅らせていきます。 防御的行動・回避的行動(Flight)
19. © rector,inc 学習を促す心理状態になれば、本能を克服できる チームの生産性を上げるポイントして心理的安全性が取りざた されるが、レイオフしやすい北米と日本を一元的に比較するの は乱暴である。 チームが問題を隠さずに、その問題に向き合うようにいかにし て導いていくかがポイント。 あくまで、生産性の向上のために、心理的安全性が必要なので あって、心理的安全性があるから生産的なわけではない。甘や かしと学習は違う。相互の期待値が高く揃う状態を目指す。 責任と心理的安全性の４象限
20. © rector,inc 本能的機能は組織にも適応される：ゲシュタルト原則 近接 地理的に近い集団を仲間だと思う 似ている種類の集まりを仲間と思う 近接した複数の要素をグループ化して捉えるという人間の 特性があります。 これはデザインだけでなく組織においても同じで、地理的 な近接を仲間と思うような特性があります。 類同 類似した性質＝情報的な距離が小さい集団を仲間と思いま す。たとえば、同業種の人同士が交流することが増えると いうような特性です。そして人には仲間じゃないと思うも のを排除しようとする本能があります。
21. 問題は、私たちの本能が悪く作用する 「構造」にこそある。
22. 悪い「構造」を良い「構造」に変える リファクタリング。
23. バグを憎んで人を憎まず
24. © rector,inc ソフトウェアづくりはコミュニケーションそのもの ソフトウェアづくりは、コミュニケーションそのものである。難易度 の高い、イノベーティブなプロダクトというのは、常に異なる常識 をすり合わせて、統合された時に生まれる。 異なる職種の人々がコミュニケーションを繰り返して、同じ認識 点に立てた時にソフトウェアは動作し始める。 イノベーションは多様性から生まれる
25. それってポエムでしょ？
26. © rector,inc ペアプロの効果と要求インスペクションの効果 ペアプロ/モブプロ 要求インスペクション 10-15%の品質改善効果 30-45%の品質改善効果 <
27. © rector,inc コード解析より精度の良い組織解析 コード解析によるバグ予測 組織構造解析によるバグ予測 < MSRのプレゼン ：http://www.slideshare.net/tom.zimmermann/empirical-software-engineering-at-microsoft-research 組織階層の深さ 関わっている組織の数 退職者の数 関係者の地理的距離 コードの複雑さ コードの変更量 依存関係の複雑さ テストカバレッジ
28. 生産性、品質、コストの トリレンマを超える。 C D Q
29. © rector,inc 1 ２ ３ これらから導かれるよいチームの傾向 関わる人数が最小限度の小さくおさえられている チームが本能的な恐怖を克服する方法を知っている 多様性のある状態から認識を揃える力がある
30. 組織構造とソフトウェア
31. 組織構造とソフトウェア システムを設計する組織は、その情報伝達の構造 をまねた設計を生み出してしまう｡ メルヴィンコンウェイ “
32. © rector,inc 組織構造はコミュニケーション構造そのもの 組織構造というと、ラインを構成するハイアラーキだけをイメー ジしがちであるが、ある仕事がどこから生まれて、どこに引き渡 されていくか、誰と交流していくことによって成り立つかから作ら れる交流のネットワークが組織構造。 それは明示的なもの・暗黙的なもの・非公式なものも含む。組 織の成果と誰が何をしているかを知っているというトランザク ティブメモリーが生産性に寄与することが知られている。 誰が誰と交流して仕事が成り立つか
33. © rector,inc 組織とソフトウェアは同じ構造に変化しやすい システムにおける問題は、組織構造上の問題が多く潜んでい る。この長らくソフトウェアエンジニアから支持されていた経験 則は、実証的研究からも多くの証拠が見つかっている。たとえ ば、関わる人々の地理的関係から ソフトウェアのバグの発生しやすい箇所を特定するなど コンウェイの法則 システムを設計する組織は、その情報伝達の 構造をまねた設計を生み出してしまう｡ メルヴィンコンウェイ “ 組織構造 システム
34. © rector,inc そのため、悪い組織構造は悪いシステムを生み出す 組織構造 システム バグ 技術的負債 見える 見えない プ ラ ス の 価 値 マ イ ナ ス の 価 値 新機能 アーキテクチャ
35. © rector,inc 組織構造とシステムが似通ってしまう理由 取引コスト理論 　取引コスト理論は、アメリカの経済学者であるロナ ルドコース(1910-2013)によって、提唱された経済学 の理論です。 取引相手を見つけるために支払うコスト 探索のコスト 取引相手と交渉を行うために発生するコスト 交渉コスト 取引相手が契約した取引を履行するように監督と矯 正を行うコスト 監督コスト
36. © rector,inc 取引コストによって、会社・組織の境界線が決まる ある経営上のリソースを市場から手に入れるのか(取 引コスト)、それとも企業内部に構築するのか(内部化 コスト)を取引コスト理論の観点で見てみると、会社組 織の境界線を決めるラインが見えてきます。 　内部化コストが高く、取引コストが安いものについて は、企業外部から調達し、取引コストが高く、内部化コ ストが低いものは、企業内部に構築することが望まし いということがわかります。 　この構図は、エンジニアリング機能を必要とする組 織にとっては、「何を外注し、何を内製するのか」を決 定づける構図であると理解することができます。 　 内部化コスト > 取引コスト 取引コスト > 内部化コスト 市場取引 長期取引 戦略連携 組織取引 企 業 外 部 企 業 内 部
37. 変えようとするとコストが 非常にかかるものと簡単にできるもの
38. アーキテクチャ
39. © rector,inc 組織設計とアーキテクチャの関係 技術的負債 プ ラ ス の 価 値 マ イ ナ ス の 価 値 アーキテクチャ 組織 システム 取引コストが低く 情報処理能力が高い 組織 取引コストが高く 情報処理能力が低い 組織 コンウェイの法則が示すように、組織の構 造とシステムの構造が相似形になってし まうのであれば、プラスの価値のある組 織からは優れたアーキテクチャが生ま れ、逆にマイナスの価値を持った組織か らは技術的負債が生まれるようになると いうことが導けると思います。 また、その逆に優れたシステムの構造 が、良い組織構造を生み出すことも起こり 得ますし、同様に技術的負債が組織の悪 しき硬直性を生み出すことも起こり得るの です。その意味で、組織とアーキテクチャ には密接な相互関係があります。
40. © rector,inc 逆コンウェイ作戦とマイクロサービシズ 技術的負債 プ ラ ス の 価 値 マ イ ナ ス の 価 値 アーキテクチャ 組織 システム 取引コストが低く 情報処理能力が高い 組織 取引コストが高く 情報処理能力が低い 組織 コンウェイの法則が示すように、組織の構 造とシステムの構造が相似形になってし まうのであれば、プラスの価値のある組 織からは優れたアーキテクチャが生ま れ、逆にマイナスの価値を持った組織か らは技術的負債が生まれるようになると いうことが導けると思います。 また、その逆に優れたシステムの構造 が、良い組織構造を生み出すことも起こり 得ますし、同様に技術的負債が組織の悪 しき硬直性を生み出すことも起こり得るの です。その意味で、組織とアーキテクチャ には密接な相互関係があります。 コンウェイの法則 逆コンウェイ作戦 microservices
41. ビジネスのアーキテクチャ & ソフトウェアのアーキテクチャ
42. © rector,inc よくすることができる＝交換可能 選択肢を持つ側と選択される側の関係には、一方向には権力 が、その反対には依存という関係が成り立ちます。 より良いものに交換できる側であれば、選択肢を持たない側に 対して「権力」を発揮できます。逆に選択肢を持たないと、「依 存」が生まれ、結果的に理不尽を受け入れます。 この依存による理不尽が技術的負債の正体で、交換可能であ るというメリットがアーキテクチャの正体です。 選択肢を持つ側から権力が働く 依存 権力 選択肢を持つ側 選択肢を持たない側
43. © rector,inc 選択肢を持つ方が強く、持たない方が弱い。 モテる異性との恋愛 属人化した業務 エンジニア求人
44. システムは時間を経ると 次第に交換できなくなり、 コントロールを喪失する。
45. © rector,inc System Control Level：システムのコントローラビリティレベル Culture チーム文化レベル Architecture アーキテクチャレベル Code ソースコードレベル Spec 外部仕様レベル Chaos 制御不能レベル 5 4 3 2 1 機能横断チームの壁 内製人材比率の壁 発注者能力の壁 生産性（高） 相互理解の壁 生産性（低）
46. © rector,inc System Control Level：システムのコントローラビリティレベル Culture チーム文化レベル チームで抽象レイヤのユビキタス言語が共有され、周辺システムと競合環 境などから適切なプロダクト開発が自律的にできる状況 Architecture アーキテクチャレベル 優れたアーキテクト人材がおり、業務要求に対して安定した開発出力を出 すことができる設計と開発チームのレベル Code ソースコードレベル 直接契約の複数フリーランサーまたは自社人材によって、ソースコードの 内容が把握されていて、変更が可能である状態。 Spec 外部仕様レベル 単一また少数のベンダーに依存しており、自社では外部仕様レベルしか把 握できていない状態。ベンダーロックインと呼ばれる状態。 Chaos 制御不能レベル どのベンダーもソースコードを把握しておらず、自社では完全な外部仕様も 持っていない状態。リバースエンジニアリングするしかない状態 5 4 3 2 1 技術的負債の最たる例は システムのコントロール性の喪失として現れる。 これを経営学では「ホールドアップ状態」と呼ぶ。
47. コントロールの喪失による ホールドアップリスクは ありふれた経済現象である。
50. なぜ、多くエンジニアは 「技術的負債現象」 として表現さざるを得なかったのか
51. © rector,inc 見ることができないという非対称性が問題の根本 非エンジニアにとって視界 エンジニアから見た視界 システムに関して、エンジニアと非エンジニアの視点 は違います。それは、CTスキャンされた図像で人体 を見ているか、肉眼で表面的に見ているかというくら いに違います。非エンジニアは外側から見たシステ ムの様子しかうかがい知ることができません 一方、エンジニアからはCTスキャンを通すように内 部の構造を理解しています。であるからこそ気がつく 病魔の兆候も、非エンジニアには伝わりません。こ の非対称性が、技術的負債が問題になる最大の理 由であるといえます。
52. © rector,inc 技術的負債に光を当てる 技術的負債は、情報の非対称性によって 生まれてしまった「判断のつかない非機能要件」のこと コミュニケーションによる可視化 技術的分析による可視化 コードの静的解析 コードチャーン分析 デッドコードのモニタリング 仮説・戦略の共有 ユビキタス言語の作成 心理的安全性の高い対話
53. © rector,inc 技術系組織の進化パターン 職能別組織 事業部組織 ユニット型組織 CEO ビジネス組織 技術組織 技術組織とビジネス組織を分離し、 必要に応じてプロジェクトに振り分 ける組織形態。 技術系人材の流動的運用が可能であ るが、ビジネスとの間のコミュニ ケーションがうまくいかず、対立構 造になることがある 事業部 ビジネス組織 技術組織 CEO 事業部 事業ごとに必要な技術組織を持つや り方。 技術人材の育成やキャリア形成に難 がある。また、職能別組織と同じよ うな問題も再現しやすい。 事業部 プロダクトチーム プロダクトチーム プロダクトチーム 事業ごとに機能横断的なプロダクト チームを組成し、そのチームによっ て継続的なプロダクトマネジメント を行う。 2000年代後半から流行しはじめ、ア ジャイル開発の普及とともに日本で も盛んになった。 横軸組織
54. © rector,inc 「両利き」の経営：専門化とイノベーションのつまみ 知 の 探 索 知の深化 専門化・安定化 イノベーション・相互理解 職能型組織 全体論的多様性チーム
55. © rector,inc 急な変化はコミュニケーション上の対立を産みやすいが、理解も進む 知 の 探 索 知の深化 全体論的多様性のあるチームは イノベーションを引き起こしやすい。 大人数ではマネジメントしづらい。 同質性の高いチームは、特定の職能を深 めていく力があるが、組織対立を招く。 コンピテンシートラップ
56. © rector,inc 専門化が進むと部門対立が生まれる。 知 の 探 索 知の深化 しかし、成長が鈍化してくるとゼロサムゲームだと 捉えるようになり、原因を相互に押し付けあう。 成長は全てを癒すのではなく、成長は全ての不安を 覆い隠す。 競争環境が固定的で、連続的なイノベーションが要 求されるステージでは、「知の深化」をもたらす 職能別組織が効果を発揮する。e.g. エンジン開発
57. エンジニア・非エンジニアの 非対称性が解消されていくこと
58. © rector,inc それをDXというのだろう。 Developer eXperience DX (開発者体験) Digital transformation DX (企業のデジタル化) ＝
59. © rector,inc ご静聴ありがとうございました 広木 大地 @hiroki_daichi