Developer Experience向上への考察 - 「LeanとDevOpsの科学」を読んで -

Posted on 2018-12-21 , Tags: Developer Experience, DX, Lean, DevOps, Book Review

LeanとDevOpsの科学を読んだので、感想や考察を書く。

「LeanとDevOpsの科学」という本について

この本は昨今導入されつつLeanやDevOpsについて、科学的な手法で組織のパフォーマンスに寄与しているものは何か、というものを述べた本である。

「LeanとDevOpsの科学」が提唱するケイパビリティ

この本の中で言及されている、改善促進効果の高いケイパビリティ(組織が持つべき能力、機能)としては以下の24がある。
個人的に項目名だけだとわかりにくかったものは説明をいれている。

継続的デリバリの促進効果が高いケイパビリティ

  • バージョン管理
  • デプロイの自動化
  • 継続的インテグレーション
  • トランクベースの開発
    • アクティブなブランチは3つ未満、開発のブランチが寿命が短い、という、コードができるだけリリース済のものと分離しないようにする開発
  • テストの自動化
  • テストデータの管理
  • 情報セキュリティのシフトレフト
    • シフトレフトとは時間軸を水平方向においたときに左側を指す。つまり時間的に最初のほうからセキュリティを考慮しよう、ということ
  • 継続的デリバリ(CD)の実践

アーキテクチャ関連のケイパビリティ

  • 疎結合のアーキテクチャ
  • チームへの権限の付与

製品・プロセス関連のケイパビリティ

  • 顧客フィードバック
  • 業務プロセスの可視化
  • 作業の細分化
  • チームによる実験

リーン思考に即した管理・監視に関わるケイパビリティ

  • 変更承認プロセス
  • 監視
  • プロアクティブな通知
  • 進行中の作業(WIP)の制限
  • 作業の可視化

組織文化に関わるケイパビリティ

  • Westrum推奨の創造的な組織文化
  • 学びの支援
  • チーム間の協働
  • 職務満足度
  • 改善を推進するリーダーシップ

感想

この本では、上記のケイパビリティについて、どのような調査でそのケイパビリティが重要だと判断したか、が述べられている。以下の点が特に興味深かった。

  • 組織を開発やリリースのスピードにより、「ハイパフォーマー」「ミディアムパフォーマー」「ローパフォーマー」にわけたところ、ハイパフォーマーのほうがローパフォーマーより結果的にシステムも安定する傾向にあり、数年継続して見ていると、その差はさらに広がっていたそうだ。
  • ケイパビリティの「変更承認プロセス」については、ソフトウェア変更をする際に承認を行うフェーズがある組織はリードタイム(コミットからデプロイまでの時間)、デプロイ頻度、サービス復旧までの所要時間に負の相関があり、安定性を求めて承認プロセスを設けた結果、逆にシステムが不安定になりやすい、という結論がでていた。
  • ハイパフォーマンスな組織は、バーンアウト(燃え尽き症候群)も少ない、という関連性もでているようだ。

考察

開発者が快適に開発や運用を行えるかどうか、の指標としてDeveloper Experienceという言葉を見たことがある。そうではないDXの定義もあるようだが、一旦脇におく。この本で述べられていることから、ハイパフォーマンスな組織を目指すこととDXの向上を指向することはエンジニア組織改善の両輪となり得そうだと考えた。
継続的デリバリ、リーン開発といった、ハイパフォーマンスな組織を目指す手法をとりいれることでDXは向上する。DXが向上すると仕事のやる気、組織への帰属意識が高まり生産性が向上する。そういった好循環を構築するにはどうしたらいいだろうか。
今、自分がはたらいている会社では、組織作りの新たな取り組みを行っており、サーバーサイドエンジニアをあつめた組織、フロントエンドエンジニアをあつめた組織、iOSエンジニアをあつめた組織、など、プロジェクトが縦軸とすると横軸となるような組織を試験的に作っている。
その横軸組織(社内ではギルドと呼んでいる)では現状、それぞれのプロジェクトであったことの共有や、社外からの知識の導入などを行っている1。ボトムアップ的に発生した組織ではあるが、DXの向上など、もう少し大きな目標を志向して動くのもよさそうだ。DXの向上を考えたとき、本書で述べられているWestrumの指標が役に立つかもしれない。パフォーマンス志向の組織の要素として、以下の要素があげられてる。(比較のために不健全な組織の指標も括弧書きで書いた。)

  • 協力態勢が確立( <-> 協力態勢が悪い )
  • 情報伝達に熟達( <-> 情報伝達を阻止 )
  • リスクを共有( <-> 責任逃れ )
  • 仲介を奨励( <-> 仲介を阻止 )
  • 失敗は調査へ( <-> 失敗は責任転嫁へ )
  • 新規性を実装( <-> 新規性をつぶす )

ギルドでは協力しあい、情報伝達し、リスクを話しあい、仲介(人的リソースの融通などだろうか)し、失敗を共有してポストモーテムとして扱い、新規技術を試すことを奨励することでDX向上につながらないだろうか。
また、これは別に考えていたことだが、DX向上につながるような、実際のアクションやナレッジはSECIモデルを参考にして、まずギルド内で暗黙知の共有を行い、汎用的な暗黙知は形式知(ブログやwikiにまとめるなど)にする。外部のブログなどの形式知をギルド内で持ち寄り、連結化を図る。そして実際にやってみたり考えてみたりして暗黙知を再び育てていく。そういった好循環ができるとよいと思う。

DXの向上とハイパフォーマンスな組織を目指すことは2項対立ではなく、自分達がよりよい仕事をするための両輪だと捉え、いろいろとやってみよう、という気になる本だった。

  1. pixivさんのフロントエンド互助会を大いに参考にさせてもらっている↩︎