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

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

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

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

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

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

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

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

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

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

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

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

Cc08756798ff94dad86ebc51c1701195?s=128

hirokidaichi

January 26, 2019
Tweet

Transcript

  1. 3.

    © rector,inc 自己紹介 EMFM Podcast エンジニアリングマネージャのためのポッドキャスト。 13エピソード公開中で、現在、20000再生を突破。 EMFM Meetupという公開収録イベントで200人の会場が即 日で集まった。

    Qiita エンジニアリングに関するノウハウを集めるサイトQiita において、2019年現在、第2位。 トータル39記事で41800いいね/20000ブクマ。 その他パブリック活動
  2. 4.

    © rector,inc Perl と YAPC と 僕 YAPC Asia 2010

    Perl Hackers Hub YAPC Asia Tokyo 2011
  3. 17.

    © rector,inc ソフトウェアづくりはコミュニケーションそのもの プログラミングは理科系的な数理的なという側面を受け取られ がちだが、実際には • 複数人の認識を揃えながら • 機械が理解できるほどブレのない明晰な文章を •

    将来の不確実な要求に耐えられるように構成し、 • 共同で継続的に管理する というプロセス。人文的な側面で言えば、立法行為に近いもの だと考えると理解しやすい。コミュニケーションが大事どころか、 「コミュニケーションそのもの」 機械が理解できるほど明晰な言語化
  4. 18.

    © rector,inc しかし、「他人と未来」に向き合うのは怖い 怒りは攻撃的行動の最たる例です。異分子だと認識しているも の(わからないもの)にいきなり、自分の立場をあやうくされるよ うなことをされると怒り出す人がおおいです。 様々な理屈を述べますが、怒りは「自分の大切にしているもの を、攻撃された」と感じる時に発生します。 変化に対して弱い人は他人に対して マウンティング、威圧、冷笑などをつかって、異分子を攻撃しよ

    うとします。 組織は新しいこと/ものを恐れるようになります。 攻撃的行動(Fight) 目標に対する有形無形の圧力が大きい場合、その不確実性へ の恐怖が問題を隠蔽する方向に機能します。 たとえば、納期の圧力大きい状態ではマネージメントから真実 の情報は隠蔽されるようになります。プロジェクト終盤で、問題 が頻発するのは、このように問題を隠す文化が醸成されたこと によります。 このような監視者と作業者の間に生まれる無駄をエージェン シースラックと言います。人間の無意識の恐怖が、回避行動と なって問題の解決を遅らせていきます。 防御的行動・回避的行動(Flight)
  5. 20.

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

    類同 類似した性質=情報的な距離が小さい集団を仲間と思いま す。たとえば、同業種の人同士が交流することが増えると いうような特性です。そして人には仲間じゃないと思うも のを排除しようとする本能があります。
  6. 36.

    © rector,inc 取引コストによって、会社・組織の境界線が決まる ある経営上のリソースを市場から手に入れるのか(取 引コスト)、それとも企業内部に構築するのか(内部化 コスト)を取引コスト理論の観点で見てみると、会社組 織の境界線を決めるラインが見えてきます。  内部化コストが高く、取引コストが安いものについて は、企業外部から調達し、取引コストが高く、内部化コ ストが低いものは、企業内部に構築することが望まし

    いということがわかります。  この構図は、エンジニアリング機能を必要とする組 織にとっては、「何を外注し、何を内製するのか」を決 定づける構図であると理解することができます。   内部化コスト > 取引コスト 取引コスト > 内部化コスト 市場取引 長期取引 戦略連携 組織取引 企 業 外 部 企 業 内 部
  7. 39.

    © rector,inc 組織設計とアーキテクチャの関係 技術的負債 プ ラ ス の 価 値

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

    © rector,inc 逆コンウェイ作戦とマイクロサービシズ 技術的負債 プ ラ ス の 価 値

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

    © rector,inc System Control Level:システムのコントローラビリティレベル Culture チーム文化レベル Architecture アーキテクチャレベル Code

    ソースコードレベル Spec 外部仕様レベル Chaos 制御不能レベル 5 4 3 2 1 機能横断チームの壁 内製人材比率の壁 発注者能力の壁 生産性(高) 相互理解の壁 生産性(低)
  10. 46.

    © rector,inc System Control Level:システムのコントローラビリティレベル Culture チーム文化レベル チームで抽象レイヤのユビキタス言語が共有され、周辺システムと競合環 境などから適切なプロダクト開発が自律的にできる状況 Architecture

    アーキテクチャレベル 優れたアーキテクト人材がおり、業務要求に対して安定した開発出力を出 すことができる設計と開発チームのレベル Code ソースコードレベル 直接契約の複数フリーランサーまたは自社人材によって、ソースコードの 内容が把握されていて、変更が可能である状態。 Spec 外部仕様レベル 単一また少数のベンダーに依存しており、自社では外部仕様レベルしか把 握できていない状態。ベンダーロックインと呼ばれる状態。 Chaos 制御不能レベル どのベンダーもソースコードを把握しておらず、自社では完全な外部仕様も 持っていない状態。リバースエンジニアリングするしかない状態 5 4 3 2 1 技術的負債の最たる例は システムのコントロール性の喪失として現れる。 これを経営学では「ホールドアップ状態」と呼ぶ。
  11. 48.

    48

  12. 49.

    49

  13. 53.

    © rector,inc 技術系組織の進化パターン 職能別組織 事業部組織 ユニット型組織 CEO ビジネス組織 技術組織 技術組織とビジネス組織を分離し、

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

    © rector,inc 急な変化はコミュニケーション上の対立を産みやすいが、理解も進む 知 の 探 索 知の深化 全体論的多様性のあるチームは イノベーションを引き起こしやすい。

    大人数ではマネジメントしづらい。 同質性の高いチームは、特定の職能を深 めていく力があるが、組織対立を招く。 コンピテンシートラップ
  15. 56.

    © rector,inc 専門化が進むと部門対立が生まれる。 知 の 探 索 知の深化 しかし、成長が鈍化してくるとゼロサムゲームだと 捉えるようになり、原因を相互に押し付けあう。

    成長は全てを癒すのではなく、成長は全ての不安を 覆い隠す。 競争環境が固定的で、連続的なイノベーションが要 求されるステージでは、「知の深化」をもたらす 職能別組織が効果を発揮する。e.g. エンジン開発