前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』
1. ストリームアラインド
ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを検証するための必要最小限の機能に落とし込み、さまざまなプロセスを経てリリースにいたる。そうしてユーザーに使われることでフィードバックを得て、新たなアイデアと仮説を得る。この繰り返されるサイクルが、「バリューストリーム」だ。
特定のバリューストリームに対して、安定したチームを専属で配備する。チームをこのバリューストリームのエキスパートにすることが狙いだ。チームの仕事は常にストリームの中で発生する。そこで流れ続けているのは、ユーザーや顧客、市場に関するドメイン知識である。そうしてドメイン知識がチームに蓄積されていけば、優れたプロダクト、優れたソフトウェアシステムを生み出しやすくなるというわけだ。
このようにしてバリューストリームに配備されるチームを「ストリームアラインドチーム（stream-aligned team）」と呼ぶ。
もし、バリューストリーム内での1つのプロジェクトが終了するたびにチームが解散してしまっていたら、その時点でチームの知識は失われてしまう。次のプロジェクトで編成された新チームは、知識をいちから蓄積しなければならない。それこそ失敗ケースの「不連続なチーム」だ。だから、バリューストリームに配備すべきはチームとして連続性のある「安定したチーム」なのだ。
1つのチームを複数のバリューストリームに配備することは避けるべきか。答えはYESである。
複数のストリームが流れ込むチームの内部は、河川の合流点と同様に、激流が発生しやすい。それぞれのストリームから仕事が流れ込んでくるからだ。しかし、チームにはキャパシティがある。流量をコントロールしなければならない。つまり、ストリーム間での調整コストが多く発生するということだ。生産性が悪化することは説明するまでもないだろう。私はこれを、「バリューストリームの合流点」と呼んでいる。
バリューストリームの合流点となったチームは、プロダクトバックログを2つ持つことになる。そこにはプロダクトオーナーも2人存在する。チームは2つのミッションの間で、どちらのプロダクトバックログアイテムを優先すべきか、日々、悩むことになるだろう。どちらのプロダクトオーナーからも仕事をせかされることになり、常態的に詰め込み型の計画になる。そうして、内部品質を犠牲にし、生産性を悪化させながら開発を続けることになるのだ。
しかし、現実問題として、チーム数よりバリューストリームの数が多いこともある。だからと言って、少人数チームをさらに小さく分割してそれぞれのストリームに配備するのは無理がある。やはり、1つのチームを複数のバリューストリームに配備せざるを得ないだろう。
このようなケースにおいては、ストリームの流量に着目してチームを配備することになる。チームが担当する「流れの激しいストリーム」を1つだけに絞る。残りは「流れの緩やかなストリーム」を兼務する形にする。
流れが「激しい」「緩やか」は、各ストリームで扱うプロダクト自体のライフサイクルや、社内・組織内におけるプロダクトの重要度などで決まる。すでに保守・運用モードでほとんど開発が発生しないようなプロダクトに対するバリューストリームは、追加開発の頻度も低く、流れが緩やかだ。反対に、社内で期待されてローンチしたばかりのプロダクトは、頻繁にアップデートが繰り返されるかもしれない。このようなバリューストリームは、流れが激しい。
こうして、ストリームの流量に着目してチームを配備することで、バリューストリームの合流点であっても、その流量の調整コストはぐっと下がるだろう。とは言え、チームによるバリューストリームの兼務は、無理があることは否めないのであるが。
もし、それでもまだチームの負荷が高いのであれば、流れが穏やかで重要度の低いストリームを社外に委託することも選択肢のひとつだ。社外サービスを利用するのも良い。ただし、このようなストリームで扱う対象は、社内や組織内におけるコアプロダクトやコア技術ではないという前提である。そもそも、開発者数に対してサービス（バリューストリーム）が多すぎるという問題を解決すべきケースもあるだろう。
■関連記事
2. オーナーシップ制
1つのバリューストリームに対して複数のチームを配備することは可能だろうか。バリューストリームを河川に例えれば、その幅が広いなら、分流させてそこにチームを配備することは可能である。そもそも、分流可能なほど広いバリューストリームを1つの小さなチームで担当すること自体に無理がある。バリューストリーム自体を分けられるならそうした方が良いが、それが難しいのならば分流させるしかない。
バリューストリームを分けるにしても、分流させるにしても、その分割方法は、ドメイン駆動設計で言うところの「境界づけられたコンテキスト（bounded context）」に着目することになる。そうすると必然的に、プロダクトのソースコード自体も、コンテキストで境界線を引くことになる。そしてチームは、自身が担当する分流の範囲に入る「境界づけられたコード」にオーナーシップを持つ。
境界づけられたコードとは、具体的にはマイクロサービス化やモジュラモノリス化をイメージすると分かりやすいだろう。しかし、必ずしもアーキテクチャをそのように明確に分離すべきということではない。分離が曖昧であればあるほど、後述する「再合流点」によるチーム間結合に悩まされることになることとのトレードオフなのだ。
コードのオーナーシップとは、オーナーたるチームがそのコードの品質に責任を持つということだ。ここで言う品質には、外部品質と内部品質の両方が含まれる。非オーナーシップ制では、コードの設計に一貫性が保てなくなり、コード品質の悪化を招きやすい。
ある調査では、高品質なコードに比べ低品質なコードに含まれる欠陥は15倍、平均開発時間は2倍、最大開発時間は9倍になるという結果が報告されている。つまり、コード品質の低下が外部品質の悪化を招き、市場投入までの時間に悪影響を与え、計画に対する予測可能性を悪化させるということだ。また、マイクロソフトの調査では、コードのオーナーシップの欠如によりリリース前後における欠陥やトラブルが増加することが明らかになっている。
これが、コードのオーナーシップ制が必要である理由だ。
境界付けられたコンテキストにあわせてコードのオーナーを分ける理由は、チーム間の結合度を下げる意図があるからだ。境界付けがうまくいけば、同じタイミングで変更されるコードをチームがまとめて扱うことができる。「閉鎖性共通の原則（CCP）」だ。こうすれば、担当する分流による開発において、他チームが所有するコードを変更する必要性が下がり、チーム間での調整コストが下がる。
なお、チームが担当する境界づけられたコードはすべて、チーム内で「共同所有（collective code ownership）」する。コードの範囲ごとにそれぞれメンバー個人をオーナーにすると、コードが属人化されやすいからだ。
一方で、チーム外に対してはポリシーを決める必要がある。「弱いコード所有（weak code ownership）」が好ましいと考えるが、「強いコード所有（strong code ownership）」を採ることも可能だ。前者は、他チームからのプルリクを受け付けるが、後者は他チームからの変更依頼を受け付けてオーナーチームがコードを変更するやり方である。つまり、強いコード所有の方が、よりオーナーチームの負荷が高く、かつチーム間でのスケジュールの調整コストも高くつくということだ。
いったん分流させたストリームが、再び合流することは避けたい。そこでまた、チーム間の調整が発生し、チームの生産性に悪影響を及ぼすからだ。
再合流点は、ソフトウェアのテストやデプロイにおいて発生しやすい。その観点で、チームが所有する境界づけられたコードは、独立してデプロイ可能なコンポーネントとして、物理的に分割されている方が望ましいだろう。そうすれば、テストやデプロイの実施スケジュールに、チーム間での調整が不要だからだ。しかし、必ずしもそうである必要はないし、必ずしもそうできるとも限らない。
コンテキストやコードの境界づけは、考えるほど簡単ではない。境界づけが上手くいけば、ストリームや分流をまたいだコード変更は発生しないはずであるが、それはあくまでも理想だ。現実は、ある1つのチームが進めるプロダクトへの変更が、他のチームがオーナーシップを持つコードに影響を及ぼすことも多い。この影響をなるべく小さくするために、境界を繰り返し見直していくことも必要である。
■関連記事
- 組織設計の失敗ケース「非オーナーシップ制」
- コード品質はやはりビジネスに影響を与える
- マイクロソフトの調査にみるコードのオーナーシップと品質の関係
- 開発組織を分散モノリスにしないチーム分割と協働のデザイン
3. バリエーション分割
開発するプロダクトに、コードベースが異なるいくつかのバリエーションがあるなら、その単位でなるべくチームを分ける。バリエーションと言うのは、たとえばAndroid版、iOS版、スマホ向けWebブラウザ版といったものだ。これらはバリューストリームを分けられる。そうすれば、プロダクトに対するアイデアの検証効率を高めたり、機能を洗練させるコストを下げることができる。
バリエーション違いの同じプロダクトだからと言って、同じ日に同じ機能をリリースする必要なんてない。iOSデバイスのユーザーとAndroidデバイスのユーザーのペルソナを作ってみれば、それぞれ違った人物像になるはず。そうであるなら、バリエーションごとにプロダクトバックログアイテム（PBI）の優先順位も変わってくる。つまり、プロダクトバックログは一つではないということだ。
このように分割すると、Android版、iOS版、それぞれで異なる新機能を開発・リリースし、改善を繰り返して洗練させてから、他のバリエーションに移植するといったことが可能になる。
この開発戦略は3つの観点で効率が良い。
1つめの観点は、失敗時のコスト。リリースした新機能が期待した価値を生まなかった時、Android版とiOS版を同時リリースしていたならば、両方を大幅に改修しなければならなくなる。しかし、Android版だけ先行開発・リリースしていたなら、手戻りコストはAndroid版のみで支払えば良い。なんなら、Android版では将来的にその機能を廃止することにし、iOS版には移植しないという意思決定も可能だ。
2つめは、改善のためのコスト。どんなに優れた機能であっても、リリースしたばかりの状態では、ユーザー体験面で改善できる箇所がいくつもあるものだ。Android版だけ先行開発し、リリースしていたなら、機能を十分に洗練させてからiOS版に移植するという手段が取れる。そうすれば、iOS版は洗練するコストを支払わなくて済む。もちろん、ペルソナが違うので、iOS版では若干の違いを作る必要はあるかもしれないが。
3つめは、アイデアの検証。プロダクトバックログはいつも、プロダクトに関するアイデアで溢れている。関係者らは、そのすべてを早く市場投入したいと考えているが、大抵の組織では、その期待に対して開発が追いつかないものだ。それに、それらのアイデアがすべて正しいとは限らない。できれば無駄な開発は避けたいところだ。
プロダクトのバリエーションごとに異なるアイデアを並行して実装すれば、アイデアの検証が速くなる。たとえば、Android版は新機能A、iOS版は新機能Bの開発・リリースを並行して進めれば2倍の速さでアイデアを検証できる。そうして、移植する・しないは、検証結果を踏まえて意思決定すれば良い。
経験主義をとる組織にとって、これは「早く安全に失敗できる」方法だと言える。バリューストリームが分かれ、チームを分けているからこそ、この開発戦略を進めやすくなるのだ。
■関連記事
4. 技術横断型
フロントエンド開発とバックエンド開発を同一チームとしてまとめる。その効果は、調整コストの低減と、市場投入までの時間の短縮である。
1つの機能開発が、フロントエンドだけ、バックエンドだけで完結することは多くはない。フロントエンドは、バックエンドに依存している。両者の開発チームを分けてしまうと、1つの機能開発を進めるために、両チームが協力し合わなければならない。協力と言うと聞こえは良いが、チーム間での調整コストを頻繁に支払うということだ。さらに、そこで調整されたリリース日は、抱えている仕事の都合で対応完了日がより遅くなるチームに合わせるしかない。こうして、市場投入までの時間が延びることになる。
チームはそれぞれがミッションを持ち、自分たちの仕事を抱えている。チームごとにプロダクトバックログがあると言えば、イメージしやすいだろうか。そこに積まれたアイテム（PBI）は、ミッションに合わせて優先付けされている。だから、1つの機能開発を複数のチームで進めようとすると、チーム間で、対応時期にズレが生じるのだ。フロントエンド開発チームが5日後に開発を完了できるとしても、バックエンド開発チームは10日後からようやく着手できるかもしれない。こういったズレが、調整コストや市場投入までの時間に悪影響を及ぼす。
私自身、過去の組織設計において、フロントエンド開発とバックエンド開発でチームを分離する組織を設計したことがある。その理由は、両者で必要とされる技術スキルが大きく異なり、それぞれの専門性が高かったからだ。同じスキルを持つ人をチームとして集めることで、知識の共有と仕事の効率化が図れると考えたのだ。
しかし実際の活動を観察するうちに気づいた。彼らは常に、1つの機能開発を2チームで作業分担して進めていたのだ。しかし、チームが異なるため、開発プロセスはそれぞれでまわしている。そのためにチーム間の調整ごとが多く、両者でのミーティングも頻発していた。決して効率が良いとは言えなかった。
話を先ほどの例のフロントエンド開発チームとバックエンド開発チームの問題に戻そう。
両者を同一チームとしてまとめれば、ミッションもバックログも1つになる。リリース日をいつにするかは、チーム内でのコミュニケーションで完結する。だから、調整コストの低減と、市場投入までの時間の短縮を期待できる。もちろん、ここで編成するチームも、同一のバリューストリームやその分流を担うフロントエンドとバックエンドを単位とすることが前提であることは言うまでもないだろう。
ここで頭を悩ませるのは、バックエンドが複数のフロントエンドから利用され、そのフロントエンドのオーナーチームがそれぞれ異なるケースだ。
たとえば、Android版アプリとiOS版アプリがバックエンドのAPIを共有している場合である。どちらのアプリチームがバックエンドサービスのオーナーになるべきだろうか。私の答えは、「どちらでも構わない」だ。ただし、チーム外に対しては、バックエンドのオーナーシップを「弱いコード所有」とし、他チームからの変更を受け付けるべきだ。そうしなければ、Android版とiOS版で並行して異なる機能開発を進める戦略が取りづらくなる。
もちろん、独立したチームを作り、そこにバックエンドサービスを持たせることも考えられる。しかし、このチームが機能するのは、チーム単体でサービスを成長させられる場合だ。言い換えれば、このサービスがそれ自体にバリューストリームを持っているということだ。今回のケースは、Android版プロダクトやiOS版プロダクトのバリューストリームにバックエンドサービスの開発が組み込まれてしまうため、この組織設計は適していないだろう。
■関連記事
5. DevOps
プロダクト開発を担うチームにとって、保守・運用の経験は、開発に対するフィードバックを得られる場である。そのために、開発と保守、運用という3つの業務機能は、1つのチームにまとめる。
開発と保守・運用を分業する組織構造は、そのフィードバックの遮断に他ならない。その悪影響の最たるものが、チームそれぞれのミッション遂行手段のコンフリクトという形であらわれる。
ソフトウェアプロダクト組織の共通ミッションは、「プロダクトやサービスのユーザー・ビジネス価値を高める」ことだ。開発チームであろうと、保守・運用チームであろうと、それは変わらない。
しかし、チームの責務とする業務機能がそれぞれ異なるため、共通ミッションに対する責務範囲にも違いが出てくる。開発チームの個別ミッションは、「優れた機能をユーザーに届ける」ことであり、保守・運用チームは「信頼性の高いサービスを提供する」ことだ。
開発チームは、優れた機能をユーザーに少しでも早く届けようと、次々と新しい機能を作り上げる。それを、保守・運用チームに投げて、高頻度でリリースを繰り返そうとする。しかし、プロダクトに変更を加えることは、品質やサービスレベルの安定性を崩す要因になりかねない。
もし、リリースするたびに新しい既知の欠陥・未知の欠陥が大量に積み上がったり、サービスレベルをおとすことが繰り返されていたらどうなるだろうか。当然、保守・運用チームが責務とするミッションを阻害することになる。一方で、開発チームのミッションには影響がない。だから、保守・運用上の問題に対する開発チームの関心が高まらない。状況が改善されないのだ。ここにコンフリクトが生じる。典型的な、devとopsの対立である。
したがって、「DevOps」である。devとopsが1つの共通ミッションのもとで活動できるようにしたい。そのシンプルな手段が、1つのチームに開発、保守、運用のすべての業務機能を集約することだ。DevOpsでは、必ずしもチームを1つにまとめる必要はないが、こうした方がミッションも統合され、自然とフィードバックサイクルも回るようになる。
自分たちで開発したソフトウェアシステムの保守・運用を担うようになると、そこで生じる様々な問題がすべて自分たちに返ってくる。
欠陥だらけなら、その是正に追われることになるだろう。本番稼働システムにトラブルが頻発すれば、その都度、開発の手を止めて緊急対応することになる。緊急対応しようにも、ログが不十分であったために止血に手間取ったり、その後の原因分析が進まないかもしれない。ライブラリやフレームワークのバージョンを上げようにも、内部構造が密結合すぎて大きなコストを支払うことになるかもしれない。
そもそも、品質が安定せず、トラブルを起こしてばかりいるようなプロダクトでは、ユーザーや顧客に迷惑をかけてしまう。ビジネス向けのプロダクトであれば、営業担当とともに顧客からのクレーム対応にも追われることになるだろう。
これらは「フェイラーデマンド（failure demand）」だ。このような問題は、ある程度は開発時に軽減できていたはずだ。本来やるべきことを怠ったために、あとからコストを支払うことになったのだ。そのために開発時間も失うことになる。つまり、品質を犠牲にしたために、スピードを失ったのだ。
チームは、こういったつらい経験を経て、ソフトウェアシステムをより良いものにしていく。その先に目指すのは、「プロダクトやサービスのユーザー・ビジネス価値を高める」という共通ミッションだ。そこには、「優れた機能をユーザーに届ける」ことと「信頼性の高いサービスを提供する」ことの両方の実現が含まれている。スピードと品質の両立だ。これが、保守・運用による開発へのフィードバック効果である。
Amazon.comのCTOであるワーナー・ヴォゲルス（Werner Vogels）は、インタビューで次のように話している。
Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
（開発者に運用責任を与えることで、顧客と技術の両方の観点において、サービス品質が大幅に向上した。従来のモデルは、開発と運用を隔てる壁越しにソフトウェアを投げ込んで、後は忘れてしまう方式だった。Amazonにおいては違う。作った人たちが、運用も担う。これによって開発者らは、自分たちのソフトウェアの日々の運用に携わることになる。それはまた、顧客との日々のコミュニケーションをもたらす。この顧客フィードバックループは、サービス品質の改善に不可欠だ。）
■関連記事
6. 機能横断型
機能横断型チームの優れた点は、そこに集まったメンバーが、互いの専門職種を越えて、同じサイクルでプロダクト開発に取り組むことにある。その主な効果は、意思決定や問題解決の速さ、ドメイン知識の均一化としてあらわれる。
それを理解するには、反対の形態を持つ分業組織について考えてみると良い。企画担当は企画担当だけで、エンジニアはエンジニアだけで業務サイクルをまわしているような組織だ。エンジニアだけでスクラム開発を採用している組織を例にするとイメージしやすいだろう。まず、企画担当が機能要件や仕様を定義し、それをエンジニアらに開発依頼する。それがプロダクトバックログに積まれ、エンジニアらが順に開発を進め、リリースするフローだ。
このような分業組織では、企画と開発が非同期で業務遂行しているため、両者の同期頻度が低く、かつ情報量も小さくなる。企画担当がスクラムイベントに参加しないからだ。そのかわりに、企画から開発への「開発依頼」といった同期ポイントが作られる。随時的に同期ポイントとしてミーティング実施日を調整しようとすると、参加者全員のスケジュールに配慮せざるを得ない。そうすると、同期の実施は、理想的なタイミングより遅くなってしまう。
また、そういった同期ポイントでのコミュニケーションでは、情報が劣化しやすい。先述の「開発依頼」であれば、機能要件や仕様についての企画担当からエンジニアへの説明は、必要最小限の情報量になる。限られた時間内で伝えなければならないからだ。そうして、企画担当が有するドメイン知識が、エンジニアらには欠落してしまう。組織内に、「ドメイン知識の過疎地」ができるのだ。
その状態のエンジニアらに、果たして優れたアーキテクチャた内部設計を作り出すことなどできるだろうか。それに失敗すれば、保守性の低下を招き、将来の生産性を悪化させることになってしまう。
機能横断型チームの場合、同期が頻繁に行われる。機能横断型チームが、スクラムチームとして活動しているなら、プロダクト開発に必要なスキルを持った人たちが皆、スクラムイベントに参加する。それぞれのイベント内で、意思決定や問題解決、ドメイン知識の共有が、高頻度で実施されるのだ。
実際のところ、機能横断型チームを作るのは想像するより難しい。従来やってきたプロセスが、職種間、業務機能間で違いすぎるからだ。これまでのやり方をすて、新しいプロセスを構築しなければならない。その設計が難しいし、当事者や関係者に理解を得るのも難しい。
機能横断型への移行のハードルがあまりに高いようなら、まずは、チームではなく、特定のイベントを機能横断型にしてみることからはじめると良い。たとえば、スプリントレビューを機能横断型イベントとして、皆で集まる。そうすれば、ドメイン知識の均一化が進みやすくなる。プロダクトバックログのリファインメントを機能横断で実施するのも良いだろう。こうして少しずつ、互いの業務プロセスをオーバーラップさせる領域を広げていくのだ。
品質保証についても、テストのシフトレフトによるオーバーラップによって機能横断を実現できる。品質保証を、テスターによるリリース前のテストフェーズにだけに頼るのをやめ、テストファーストという手法をとるのだ。ユニットレベルのテストであれば、エンジニアとテスターでペアプロを実践すれば良い。また、開発を始める前に、企画やテスター、エンジニアで協力して機能テスト向けのテストケースを書くことだってできるだろう。
■関連記事
7. マルチスキル
少人数チームを技術横断型や機能横断型として機能させるためには、何が必要になるだろうか。それは、メンバーそれぞれがマルチスキル（多能工）になることだ。
たとえば、フロントエンド開発のみを担当するチームであれば、メンバー全員がフロントエンドエンジニアとしてシングルスキル（単能工）であっても困らない。
しかし、技術横断型チームであればどうだろう。フロントエンドエンジニアが4人、バックエンドエンジニアが3人の編成だとする。この時、全員がシングルスキルなら、フロントエンド開発の仕事量は同時に3人分、バックエンド開発の仕事量は同時に4人分が限界になる。メンバー数が7人であるにも関わらずだ。
バックエンド開発に関する仕事が少ない時期に、フロントエンド開発に仕事が集中することもある。こんな時、フロントエンドエンジニアは多忙であるにも関わらず、バックエンドエンジニアは時間を持て余すことになる。そうすると、バックエンドエンジニアは優先順位が低い仕事や、価値の小さい仕事に手を付けるかもしれない。仕掛中の仕事に時間を費やして過剰品質なアウトプットを生み出すことに専念するかもしれない。この状況が、チーム思考と言えるだろうか。
このような局所的な人員不足は、チームが責務とする業務機能が多く、技術領域が広いほど、その傾向が強くなる。チームに様々なスキルが必要となるからだ。少人数チームにおいてそれをシングルスキルでカバーしようとすれば、必要なスキルが多いほど、それぞれのスキル所有者数が少なくなってしまう。これでは機能横断、技術横断であるほど、チームの生産性は低くなる。
ところが、ゾンビスクラム診断の統計によれば、67%のチームが「自分の専門分野の仕事だけしかしないか、ほとんどしないメンバーで構成されている」と回答しているようだ。これでは技術横断型、機能横断型チームの実現はほど遠い。もちろん、ゾンビスクラム診断を受けるチームは、その時点で問題を抱えているだろうから、この数字はネガティブ側に偏りがある可能性はあるのだが。
このような問題の解決策として、フロントエンドエンジニアをチームに追加するという手段をとるべきではない。そんなことをしていたら、チームメンバー数はどんどん増えていく。
だから、マルチスキルが必要となるのだ。バックエンドエンジニアが、フロントエンド開発に参加することを期待しているということだ。もちろんその逆も然り。これは、様々な専門分野の間で生じ得る問題なのだ。
マルチスキルと言っても、求める人材像は、いわゆるT型やπ型だ。自身の専門分野を1つ、あるいは2つ深堀りしつつも、専門外の分野のスキルも浅く広く身に着けていく。先の例では、フロントエンドエンジニアとバックエンドエンジニアの話であったが、企画、デザイン、テスト、開発、保守、運用、その他、チームが責務とする業務機能や技術領域すべてに言えることだ。
マルチスキル化を促進するためには、専門分野が異なるメンバー同士がペアを組んで仕事するのが良いだろう。あるいは型化、自動化を進めるのも手だ。たとえば、デザインシステムを構築しておけば、エンジニアがUIデザインをカバーする敷居も下がるだろう。
■関連記事
組織設計とはアーキテクティングである
組織マネージャーが責務を負う「組織設計」とは、「設計」と言いつつも実際は「アーキテクティング」だ。ソフトウェアと同じように、組織にもアーキテクチャと設計がある。マネージャーがアーキテクチャを示し、現場のチームがそれに沿ってチームやプロセスを設計・実装する。
そのようにイメージしてみると、組織設計の方針や意図を言語化すべき必要性に気づく。それが無ければ、期待どおりのチームやプロセスが実現されることはないからだ。そうして、アーキテクチャとしての組織設計は脆くも崩れ去っていく。これもまた、ソフトウェアアーキテクチャと同じではないか。
組織のミッションやビジョンとは違い、組織設計については、組織メンバーに向けて詳しく語られる機会は少ない。「繰り返し話さなければ」とよく言われるのは、ミッションやビジョンであり、組織設計ではないことからも明らかだろう。組織設計については、期初に軽く触れられる程度だ。その内容も、組織ツリーについての説明程度だろう。
語られる機会が少なければ、アーキテクトたるマネージャーの思考の言語化率も低くなる。これでは、組織設計に込めた方針や意図が伝わるはずもない。いくら優れたアーキテクチャを練り上げても、想定した組織は生まれないだろう。
そして、組織設計によって作り上げられる組織構造がいびつになれば、ソフトウェアシステムの構造もまた、いびつになってしまう。これは、「コンウェイの法則」という名で誰もが知るところだ。
マネージャーは、組織設計について、組織メンバーにしっかりと伝えていかなければならない。そう感じるところである。
