◯システムの品質はチームの体質で決まる

前回はラインマネジメント型の組織構造の弊害についてお話しました。

今回はそれを克服するにはどうすればいいかについて、お話していこうかなと思います。

ところで皆さん、コンウェイの法則って聞いたことないですか？

コンウェイの法則というのはメルヴィン・コンウェイさんが提唱した概念です。

一言で言うと、

ヒエラルキーが強い組織が作るシステムはモノリシックなシステムになりやすい

ということです。

内製化チームを作った、でもうまくいかない。

実はこれ、コンウェイの法則は強力に働いている時なんですよ。

開発チームがワンチームで従来の設計開発をやって、そのワンチームの中で分担しても、最終的にはそのワンチームが全体の面倒を見なければいけない。

結果、一つのモジュールの中に、サービスを目一杯押し込むようなモノリシックなものを作ってしまう。

ではそういう形をやめて、マイクロサービスをやるとします。

設計開発を同じように、かなりヒエラルキーの強い状態でワンチームを作って、頑張ってマイクロサービスやる。

でも複数のサービスを管理するのは、結局ワンチームになるわけなので、サービス間の依存度が高くなって、結果モノリシックになるわけです。

これがコンウェイの法則の考え方です。

マイクロサービスを開発チームで作ろうとしても、そのチームで強力なヒエラルキーが働いていたら、マイクロサービスにならないということです。

◯7つの原則と22の思考ツール

ここで僕がいつも考えているのは、チームビルディングなんです。

全てはチームビルディングから始まる。

これって物凄い大事な言葉で、この技術がないからできないとか、この人がいないからできないとか、そういうことじゃないんです。

まずやるべきなのは、チームがなすべき機能とは何かを徹底的に洗い出すことです。

そして機能が全部出揃ったらそれに人を当てていく。

何をなすべきかが出来上がっていないと、人を入れても、試行錯誤する中でヒエラルキーがどんどん強くなっていきます。

機能をちゃんと分けて、ここからチームビルディングしていきましょうと。

チームビルディングがほぼ全てだと僕は思っています。

そこでチームビルディングに成功したとして、システムを作っていくんですが、チームのルールをまず考えなければなりません。

先ほどヒエラルキー、ヒエラルキーって言いましたが、トップダウンが強力な体制もアリだと僕は思っています。

アりだとは思うんですが、それで本当にいいシステムが作れるのか？という観点が重要です。

ここでご紹介したいのは、リーンソフトウェア開発の法則。

7つの原則と22の思考ツールがあると言われています。

特に7つの原則はすごく大事です。

原則１　ムダをなくす

原則２　品質を作り込む

原則３　知識を作り出す

原則４　決定を遅らせる

原則５　早く提供する

原則６　人を尊重する

原則７　全体を最適化する

書いてあることは当たり前のよう見えるんですが、これらを実際にシステムやツールに落とし込むってなかなか難しいので、さらに22の思考ツールを使って原則を実践していくわけです。（後編へつづく）

☆本記事はオルターブースYouTubeチャンネルの配信動画をもとに再構成しています。

☆配信動画の本編をご覧になりたい方はこちらから！（小島発表パート）