« TestRailの感想 | トップページ | アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai »

2021/06/23

DXとは組織論である

DXとは組織論である、と思った。
適当なラフなメモ。

【参考】
最近読んだ本 - ブログ@kaorun55

(引用開始)
3月、4月くらいからいろいろ本を読み始めました。
主に人、組織、技術の実装あたりです。
最近はHoloLensの土台としてのDXの必要性を感じているのですが、DXは実際には組織論だと考えていて、自分の組織含めて組織の考え方について触れるようにしています。
(引用終了)

DXとは「1980年代の呪縛」を解き放つこと|市谷 聡啓 (papanda)|note

(引用開始)
あるミーティングで、何気ない流れの中である人が言った「DXとは組織を変えることだ」と。その言葉が特に何の違和感も、言い過ぎ感もなく、その場で受け止められて、皆の血肉となるよう消化されていく。凄い時代を迎えたと思った。
組織を変える。経営からマネジメント層、現場まで、気負いなくその言葉があげられる。もちろん突きあげられるような危機感とともに、その言葉が口にされる組織もある。いずれにしても、単なるフレーズではない。大いなる共通の目標となっている。
(引用終了)

kaorunさん、市谷さんのBlogをたまたま読んで、2人とも同じような意見「DXとは組織論である」を書かれていた。
2人ともすごい方だが、同じような問題意識を持っている点に興味を持った。
たぶん、今のコロナという時代では、心あるIT技術者は、DXの本質は何だろうか、と考えているのではないだろうか?

僕は、「DXとは組織論である」という意見は2つのコンテキストを持っていると考える。
1つは、ソフトウェア開発に向いた組織構造は何か?という問い。
もう一つは、ユーザ企業の情報システム部門が、社内の業務システムを一括コントロールするためにはどんな組織形態や運用制度が必要なのか?という問い。

前者は、逆コンウェイ戦略の観点の話になる。
つまり、アーキテクチャは組織に従う、というコンウェイの法則によって、ソフトウェアはどんどん複雑化して肥大化して手に負えなくなるのだから、それを逆手に取って、ソフトウェア・アーキテクチャを開発チームが制御できるように、アーキテクチャに合った組織構造を作ってしまえ、ということ。
最終的には、スクラムチームを作ることと同義。
それは、単なるソフトウェア開発チームだけでなく、全ての部署がスクラムチームになることと同義。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ: プログラマの思索

しかし、従来の製造業のビジネスモデルに適した組織構造では、ソフトウェア開発に適した組織構造がとても作りにくいのだ。
そして、ソフトウェア開発に向いた組織文化は、従来のビジネスモデルに適した組織文化と全く異なるので、そのまま組織を作っても、組織文化をトップダウンで適用してもうまく行かない。
「文化は構造に従う」「アーキテクチャは組織に従う」経験則に縛られてしまう。

だから、ソフトウェア開発に向いた組織を作るには、出島を作ったり、関連子会社で別会社にするとか、そういう携帯にならざるを得ない。

文化は組織構造に従う: プログラマの思索

後者は、今の日本政府のデジタル庁で悪戦苦闘している問題点と同一と思う。
日本の大企業はどこも、皮を剥いで中身を見れば、事業部制組織という中小企業の連合体になっている。
だから、プロフィットセンターである事業部が利益に物を言わせて、自分たちの好きなように業務システムをどんどん社内に勝手に作った結果、数多くのメインフレームがまだたくさん稼働した状態で蛸壺となってしまって、コストセンターである情報システム部門はそれらを制御する権力もなく、社内のシステムが野放図になって、IT統制もできていない、みたいな感じ。

今まさに、もう一度、情報システム部門が全ての事業部から業務システムを取り上げて、決められた予算や今後の経営戦略に従って、システムの新規開発やリプレースのロードマップを計画し、セキュリティ面や個人情報保護、コンプライアンスも含めた観点で作り直そうとしている、みたいな感じ。
本来であれば、もっと以前から、メインフレームは撤廃して2025年の崖の問題はとうの昔に片付けて、オープンなアーキテクチャを元に、守りの業務システムよりも、ビジネスに直結するシステムを開発してどんどんビジネスを拡大させていく、みたいなイメージでやりたい。

しかし、デジタル庁の問題も同じく、今まさにそういうことを、地面0メートルの所から巨大なビルを作り出そうとしているわけだ。
たぶん、どこの日本企業も、レガシーなメインフレームの業務システム、あるいは、古すぎてセキュリティ上危ない業務Webシステムをたくさん抱えて、二進も三進も行かなくなっている。

僕は、DXとは、既存ビジネスを持つユーザ企業が、ソフトウェアを根幹としたビジネスモデルを構築して変革していくことと思っている。
そのためには、結局、古い数多くの社内システムを一括コントロールし、捨てるべきシステムは捨てて、システム保守に多額のコストを払うのではなく、売上拡大につながる新たなシステムへ投資できるように、経営判断を促す仕組みを作るべきだ。
そういうことが求められているのだろうと思う。

IPAがDXのパターン・ランゲージを公開している~新しい組織文化が新しい経営戦略を生み出す: プログラマの思索

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索

デジタルトランスフォメーションとはソフトウェア企業になることを意味する: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

|

« TestRailの感想 | トップページ | アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai »

プロジェクトマネジメント」カテゴリの記事

ビジネス・歴史・経営・法律」カテゴリの記事

ソフトウェア工学」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« TestRailの感想 | トップページ | アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai »