ソフトウェア開発を加速させるために知っておきたい組織論とより創造的な開発組織になるのためのプラクティス

エンジニア 組織 DevOps リーン

この記事について

このエントリは ただの集団 Advent Calendar 2018 の12日目です。
昨日は tk628496 さんの 認定スクラムマスター（CSM）研修について でした。

私が現在所属している開発組織では、「変化に強い自己組織化された組織」になるべく、今年の8月からスクラムが本格的に導入されました。
スクラムの導入されてから

  • そもそもなぜ変化に強い組織にならなければならないか？
  • 今の組織構造にはどのような利点や欠点があるのか？
  • より変化に強い組織になるためには何をすれば良いのか？

ということに興味を持つことが多くなり、スクラム、Lean、DevOpsなど色々調べてみたことを自分の知識として統合するためにまとめてみた記事になります。
本記事ではタイトルにある通り、エンジニアがソフトウェア開発を加速させるために知っておきたい組織論とより創造的な組織になるのためのプラクティスについて書いていきます。
本記事が組織改善の役に立てれば幸いです。

TL;DR

  • 組織変革に先立って我々を取り巻く環境や市場の変化がある
  • 今はVUCAの時代とも言われるように不確実で先が見えない中でビジネスをしなくてはならない
  • VUCA時代に対して、組織の多くは官僚的組織であり、不確実なビジネス環境に適した組織でないことが多い
  • ソフトウェア開発組織に限っていうと、DevOpsやリーンのプラクティスを導入することでよりRon Westrumが提唱する創造的な組織に近づくことができる
    • 特にデプロイの負荷を下げることが創造的な組織になるために効果あることが明らかになっている

目次

前提条件としてのビジネス環境の変化

本題の組織論とDevOpsやリーンのプラクティスに入る前に前提として理解しておくべきビジネス環境の変化から説明していきます。

VUCA

現代のビジネス環境は一言で表すと「VUCAの時代」となっています。
VUCAとは下記の頭文字をとって作られた言葉です。

  • 変動性(Volatility)
  • 不確実性(Uncertainty)
  • 複雑性(Complexity)
  • 曖昧性(Ambiguity)

VUCAの時代を一言で表現すると「先が読めない時代」になっているということです。

bizhint.jp

変化が求められる組織

先が読めないVUCAの時代に対応する1つ方法として組織変革が挙げられます。

組織変革とは、組織の 「構造」および「文化」、「運営方法」などを見直し、抜本的な改革を成し遂げることをいいます。(組織変革とは？ 組織変革のプロセスやフレームワークのポイント より引用)

先の読めない時代になぜ組織変革が必要なのでしょうか？
それを知るためにはまず多くの企業がどのような組織体で運営され、どのようなメリットとデメリットを抱えているか理解することが大切です。

組織論について

組織とは

組織論で取り扱う組織とは以下のようなものです。

ヒトやモノ、カネ、そして情報などの資源を有効に活用して、少しでも多くの、良質の成果を得るようにするための仕掛けである。(よくわかる組織論 より引用)

営利企業の場合、組織が持続することを前提としているため、基本的に利益を得ることが上記の定義における「良質の成果」に当たります。（しかしながら、利益のみが良質な成果かと言われるとそういうわけでもありませんが）

ある営利企業において自組織の経営資源を有効に活用できない組織形態になっている場合、組織変革と通じて経営資源をより有効に活用し良質な成果を得ることができないと組織としての持続が難しくなってしまいます。

組織論で取り扱う組織は営利企業のみを対象としているわけではありませんが、この記事では組織 = 営利企業の組織というのを前提として話を進めていきます。

タイプ別にみる組織形態

組織形態については様々な学者が組織をタイプ別に分けていますが、この記事では米国の社会学者Ron Westrumが定義したモデルを紹介します。

Ron Westrumは自身の研究から組織は3つのタイプに分類できるとしました。

  • 不健全な(権力志向の)組織
  • 官僚的な(ルール志向の)組織
  • 創造的な(パフォーマンス志向の)組織

上記の組織は下記の表にあるような特徴を持ちます。

不健全な(権力志向の)組織 官僚的な(ルール志向の)組織 創造的な(パフォーマンス志向の)組織
協力態勢が悪い ほどほどの協力態勢 協力態勢が確立
情報伝達を阻止 情報伝達を軽視 情報伝達に熟達
責任逃れ 責任範囲が狭い リスクを共有
仲介を阻止 仲介を許容 仲介を奨励
失敗は責任転嫁へ 失敗は裁きへ 失敗は調査へ
新規性を潰す 新規性を問題化 新規性を実装

みなさんが所属する組織は不健全な組織まではいかなくとも、官僚的な組織であることが多いのではないでしょうか？
大企業のような組織規模が大きい組織や規模を拡大している組織は組織管理のためにルールによるコントロールシステムが整備され、徐々に官僚的な企業になっていきます。
組織変革を必要としている組織は多くの場合、大企業のような官僚的な組織であることが多いため、次に官僚的な組織の利点と欠点について説明します。

官僚的な組織の利点と欠点

官僚的な組織は意図の有り無しに関わらず、企業をより合理的に運営していくために官僚的な組織になることが多くあります。しかしながら合理性を求めた結果、官僚的な組織が非合理な組織になってしまうこともありえます。
官僚的組織には先に紹介した表の特徴の他に以下のような特徴も持ちます。

  • 規則による管理を重視する
  • 職務の専門化が高度に進んでいる
  • 権限と責任が職位に対して付与され、それが階層をなす形で組織が編成されている

これらの特徴を揃えた官僚的な組織は タテの命令系統で規則に基づき大規模で定型的な業務を遂行すること には向いていますが、急激に変化する環境に柔軟に適応するために、新たな製品・サービス、仕組みを作り出すイノベーションや改革が行いづらい という欠点も抱えています。

なぜイノベーションが起こりづらいかというと、規則を重視するあまり自由な発想が生まれづらく、組織のヨコでの協力も生まれづらいことが挙げられます。

先に今は先の読めない時代になっていることを書きましたが、官僚的組織が今の時代と相容れないのはこの点においてです。
先が読めない時代においては失敗をある程度許容しつつ、規則にないような新たな製品や活動を行っていく必要がありますが、官僚的組織形態がそれを阻害しているのです。

官僚的な(ソフトウェア開発)組織から創造的な(ソフトウェア開発)組織へ

官僚的組織から創造的な組織になるために組織変革を行う必要が出てきます。
ここまではソフトウェア開発組織などに限定せず一般的な組織の形態を見てきましたが、 以降では官僚的なソフトウェア開発組織から創造的なソフトウェア開発組織になるためのDevOpsプラクティスを紹介していきます。
DevOpsプラクティスの導入はあくまで官僚的な組織から創造的な組織へとなるための手段の一つにすぎません。
本来の目的はより時代に適した組織となることです。
本来の目的を忘れ、プラクティスを導入することが目的になってしまうと本末転倒ですが、組織論的な背景を知ることでプラクティスが目的ではなく手段とすることができるはずです。

創造的な組織になるのためのプラクティス

ここからは創造的な組織になるのためのDevOpsプラクティスとリーン製品開発に基づくプラクティスを紹介していきます。
なおこれから紹介するプラクティスはLeanとDevOpsの科学という書籍にて全て紹介されていますので、より詳しく知りたいかたは書籍を当たっていただければと思います。

DevOpsとは？

まずDevOpsについて簡単に説明します。
DevOpsとは以下の概念のことを言います。

「開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。 (「DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い」より)

通常、DevOpsのプラクティスはビジネスの価値を確実かつ迅速にエンドユーザーに届けるために実施されますが、DevOpsのプラクティスを実施することで、より創造的な組織になることを促進するすることが、書籍の著者およびPuppet社の調査と研究から明らかになりました。

リーン製品開発（リーンソフトウェア開発）とは？

続いてリーン製品開発について簡単に説明します。

リーンソフトウェア開発は、製造業を中心に展開されているリーン生産方式を、ソフトウェア製品に適用した開発手法で、メアリー・ポッペンディークとトム・ポッペンディークが提唱しアジャイル開発手法の１つになっている。リーン生産方式は、日本の自動車産業の強さを探るため、特にトヨタ生産方式（TPS）を研究し、それを一般化・再体系化した際に付けられた名称である。（「リーンソフトウェア開発の７つの原則」より）

またリーン製品開発には7つの原則があります。

  1. ムダをなくす
  2. 品質を作り込む
  3. 知識を作り出す
  4. 決定を遅らせる
  5. 速く提供する
  6. 人を尊重する
  7. 全体を最適化する

リーン製品開発のプラクティスもDevOpsのプラクティス同様に、より創造的な組織になることを促進するすることが、書籍の著者およびPuppet社の調査と研究から明らかになりました。

24のケイパビリティ5つのカテゴリー

「LeanとDevOpsの科学」によると、ソフトウェアデリバリのパフォーマンスを改善する効果の高いケイパビリティ（組織全体やグループとして保持する機能や能力）は24個存在し、その24個のケイパビリティは5つのカテゴリーに分類できます。

  1. 継続的デリバリ
  2. アーキテクチャ
  3. 製品とプロセス
  4. リーン思考に基づく管理と監視
  5. 組織文化

これらの中で、より創造的な組織になるためのプラクティスのカテゴリーとして「継続的デリバリ」、「リーン思考に基づく管理と監視」「組織文化」があります。
まず継続的デリバリから見ていきましょう。

継続的デリバリ

継続的デリバリとは『機能の追加、構成の変更、バグの修正、各種試行など、さまざまな変更を、安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティからなる手法』のことです。
継続的デリバリは以下の5つの基本原則を柱としています。

  1. 「品質」の概念を生産工程の最初から組み込んでいく
  2. 作業はバッチ処理で進める
  3. 反復作業はコンピュータに任せて人間は問題解決に当たる
  4. 徹底した改善努力を継続的に行う
  5. 全員が責任を担う

注目すべきは「全員が責任を担う」という点です。
官僚的組織では組織全体の目標より部署や所属チームの目標を重視する傾向がありますが、継続的デリバリを実践する過程で、ソフトウェアデリバリに関わる全関係者が協力できるようにしなければ継続的にソフトウェアをデリバリすることはできません。
継続的デリバリの実践を通じてそこそこの協力態勢からより確立した協力態勢の構築が期待できます。

継続的デリバリの実践には以下の作業基盤を整備が必須になります。

  • 自動化したビルド／テスト／デプロイを行うための包括的な構成管理
  • より素早く統合を行うための継続的インテグレーション(CI)
  • 継続的テスト

また継続的デリバリを実践する上で開発者に以下の権限を与えることも必要になります。

  • 問題発生を即座に察知するためのツール
  • そのツールを開発するための時間と資源
  • 問題を直ちに修正できる権限

継続的デリバリを実践しデプロイ関連の負荷を下げることができればチームの燃え尽き症候群を軽減し、職務満足度を高めることも明らかとなっています。

リーン思考に基づく管理と監視

リーン製品開発におけるマネジメントのプラクティスには以下の4つのプラクティスがあります。

  • 進行中の作業(WIP)の制限
  • 品質と生産性に関する重要な数値指標の可視化
  • ワークフローの可視化
  • 負担の軽い変更承認プロセス

これらのプラクティスの中で注目すべきは「負担の軽い変更承認プロセス」です。
ソフトウェアデリバリにおいて、コードレビューなどの変更承認プロセスを踏むことはよくありますが、調査の結果、「チーム外の人や組織の承認を得なければならない場合、本番システムの安定性は向上せず、むしろ確実に作業の遅れを招く」ことが明らかになりました。 また継続的デリバリでも少し触れたようにデプロイ負荷と創造的な組織には相関があり、コードデプロイの負荷が増せば増すほど組織文化の質が下がることも調査から明らかになりました。

組織文化

組織文化の醸成はより創造的な組織になるために大きく関わっています。
以下の4つの組織文化の醸成がソフトウェアデリバリのパフォーマンスを改善することが調査から判明しており、またソフトウェアデリバリのパフォーマンス改善が組織変革に効果があることがわかっています。

  1. 学びの奨励と支援
  2. チーム間の協働の支援と促進
  3. 有意義な仕事を可能にするツール類の資源の提供
  4. 改善を推進するリーダーシップの実現や支援

これらの組織文化の醸成には投資などが絡むため、組織のマネジメント層のコミットメントが重要になります。

まとめ

ビジネス環境の変化から始まり、組織論やDevOps・リーンのプラクティスについて色々書いてきたので若干まとまりのない文章になってしまいました。。
本記事では現在のビジネス環境が先が読めないことから始まり、官僚的組織が現在のビジネス環境に適した形態でないこと、開発組織変革にあたり、DevOpsとリーンのプラクティスが創造的組織となるために効果があることを書きました。

本文でも紹介したLeanとDevOpsの科学ですが、本書には本記事では紹介しきれなかったプラクティスが数多くあります。
個人的2018年に読んだ本のTop3に入る良い書籍だったので、より良い開発組織を創ろうとしている全ての方にぜひ読んでいただきたいです。 最後まで読んでいただきありがとうございます。

参考資料