Contents

DevOps とはなにか

このサイトのサブタイトルに気づいてくれているだろうか。 “DevOps guide for non-programmers” だ。

/images/key.jpg

DevOps は “Development & Operations” をちぢめたソフトウェア業界の造語で、 率直に言えば、組織としての生き方を変えることだ。 我々ノンプログラマにとっては聞き慣れないが、良い仕事のあり方が凝縮された重要な概念だ。

DevOps の歴史

DevOpsの発端は、組織の縦割りをなくす運動だった。 この一連の流れについて、簡単に知っておくといいだろう。 まるっきりソフトウェア業界の話になってしまうが、しばし付き合ってほしい。

コンピュータ科学の黎明期にあたる1940年代、開発者たちのコラボレーションはうまくいっていた。 当時の仕事には、部署を分けるほどの専門性はなかったため、自ずと連携できていたのだ。

事態が悪化したのは1970年代ごろ。 システムやソフトウェアが複雑になるにつれて、開発者たちは機能を追加する「開発部門」と、品質管理や出荷を受け持つ「運用部門」に分かれはじめた。 開発部門は、新機能の実装が終わるたび、製品を運用部門めがけて「壁越しに投げ渡す」ようになった──仕事は果たしたのだから、「あとは知らん」というわけだ。 ひとたび不具合が出ると、運用部門は受け入れを拒否し、製品を「壁越しに投げ返し」た。 製品を無事に出荷することを至上目標としていた運用部門にとって、不具合のある新機能は足を引っ張る存在でしかなかったのだ。 専門化という縦割りが、目標の乖離やコミュニケーション不足などの人間的問題を生み、組織の生産性を損なっていた。

改善への歩みは2000年代の後半に始まった。 両者は、食い違っているかのように思えたそれぞれの仕事──「機能追加」と「品質維持」──は、究極的には顧客を満足させるための活動だったことを思い出したのだ。 開発者たちは、品質を維持しながら製品を更新する方法をみつけ、出荷までの手順を再現可能にすることで、機能追加から出荷までの一連の工程を、個人の責任でやり遂げることができるようになった。 開発と運用の境界がなくなったことでコラボレーションが回復し、組織の生産性は劇的に高まった。

DevOps は現在も発展をつづけており、その守備範囲は縦割りの解消にとどまらず広範囲にわたっている。 たしかに生まれはソフトウェア業界だが、DevOps は、よりよい仕事をしようとする全ての組織によい影響をもたらしてくれる。 アイデアを分けてもらうには、それが生まれた場所にとらわれる必要はない。

ノンプログラマにとっても重要

DevOps というと聞き慣れない感じがするが、この概念は近年、ある意味では再発見されつつある: デジタルトランスフォーメーション(DX)の推進が始まったからだ。 DX とは、企業や政府が、IT を活用して事業や社会を変革すること。 我が国に与える影響は、経済産業省によって評価されている1。 しかし、DX に含まれる要素はどれも、DevOps の学会では 10 年前から認知されていたものだし、DevOps に力を与えている文化的側面──あとで述べる──には、DX はまだ気づいていないようだ。 DevOps を学ぶことで、一段上の視点から DX を理解することができるだろう。

余談だが、私は、大転換をねらう政策として、「デジタルトランスフォーメーション」という名前は失敗だったのではないかと考えている: 「デジタル」も「トランスフォーメーション」も、すでに聞き馴染みのあるがゆえに、ノンプログラマが自身の想像の範囲内で──例えばただのペーパーレス推進運動だろうと──早合点してしまわないだろうかと思うのだ。 “DevOps” の奇妙な響きは、聞き手の新鮮な気持ちを喚起するには十分だろう。

私の勝手な想像はさておき、DevOps の普遍的な重要性を説くならば、その根拠を説明する必要があるだろう。

効果的な価値づくり

つまるところ、仕事とは価値づくりだ2。 組織はそれぞれにミッションを抱えているが、細分化した専門領域を越えて共通しているのは、みな顧客価値を課題に落とし込み、問題解決しているという点だ。 とくに無形物を作っている組織が直面する問題は、薄目で見れば、かなり似かよったものだろう。 DevOps が目指すのは、まさにこの価値づくりを効果的にすすめることだ。 我々ノンプログラマが、自身の仕事が価値づくりであることに気づけば、開発者たちの知恵を借りることができるようになる。

開発者たちの働き方が優れている理由は、単にペーパーレスだからではない。 根本的に違うのだ。 手順書を電子化したところで、手を動かさないといけないことに変わりはない; 手順書が古くなっていたら、誤った結果を招いてしまうだろう。 手作業のミスにはどう対処したらいいだろうか。 ダブルチェック?トリプルチェック?それでも足りない? 終わりのないモグラ叩きに職業人生を捧げるつもりなら話は別だが、費やした資源を蓄積するしくみを整備しないまま人海戦術に頼るのは賢明ではない。 開発者たちは、いわば「動く手順書」を使って働いている3。 同じミスを二度と繰り返さないことによって、品質を積み上げることができるのだ。

技術的な側面からの解説になってしまったが、DevOps は表面的な効率化を指す概念ではない。 もっと泥臭い問題: 人間的問題にも正面から向き合うことで、組織を根本から強くするのだ。 どんな道具を使おうと、仕事をするのは結局のところ人間だ。 よい仕事は、モチベーションや良好な人間関係なしには成り立たない。

人間に着目

顧客体験(CX)という言葉が浸透したおかげで、仕事における顧客視点の重要性はだいぶ認知されてきた。 一方で、CX の向上に奔走する企業に息切れも見えはじめており、従業員体験(EX)の向上が必要との見方も出てきている4。 そう、CX の向上とは、顧客に一方的に振り回されることではないし、まして従業員の身を切って実現するようなものでは決してない。 DevOps 文化が定着した組織は、よりよい仕事のためにまず従業員を大切にする。 勤務時間に対する配慮はもちろんのこと、長期的な組織づくりを見据えた従業員への投資が重要であることを知っているのだ。 主な投資の例について、DevOps についての知見を集約した名著 『Effective DevOps5』から一部を紹介してみよう。

従業員への投資

メンターシップ制度
従業員の成長を促進するのはもちろんのこと、周囲からサポートされていると感じることによって彼らの安心感を高め、職場への帰属意識を強める効果もある。 しかも、メンターとメンティーの関係は職階とは切り離し、柔軟に考える必要性が指摘されている: 専門技能が細分化した現代においては、部下がメンターとなることも珍しくない。 キャリアのどのステージにいようと、誰もが全方向から学ぶことができるのだ。
スポンサーシップ制度
スポンサーは、キャリア志向に合わせて従業員を適切なポジションへ引き上げたり、彼らに必要な人脈を紹介したりする。 キャリア形成においては、メンターシップ以上に効果を発揮するという知見もあるようだ。
教育
従業員のスキル向上を直接的に支援する。 古い考え方の企業は、従業員にスキルを身につけさせると、それを利用してよりよいポジションを求めて転職してしまうと懸念することがある。 しかし実際は逆で、教育制度を適切に整備すれば従業員の帰属意識が高まり、組織に長く留まるようになる。

顧客体験の向上に全力でコミットするためには、従業員それぞれが適切なスキルを備え、自身が望むポジションで働けていることが必要だ。 時代とともに、DevOps は微に入り細に入り、人間的側面のさまざまな領域を取り込んで発展してきた。 ソフトウェア業界生まれのこの概念が、いかに本気で人間的問題を扱っているかを理解してもらうために、あえて細かいものを列挙してみよう。

その他の細かい事がら

多様性に対する理解
職業的・個人的なバックグラウンドの違いは、考え方や振る舞いの違いを生む: 現在の仕事を、次のキャリアのための重要な仕事と考えているかもしれないし、生活の手段として割り切っているかもしれない; 一人で黙々と作業するのが好きな人もいれば、共同作業が好きな人もいる; 断られる可能性も考慮に入れた上でどんどん依頼を出す人もいれば、相手が確実に受けてくれる依頼しか出さない人もいる; プロジェクトを始めることが得意な人もいれば、仕事を仕上げるのが得意な人もいる──効果的なコラボレーションは、互いの多様性を尊重することから生まれることを肝に銘じよう。 生産的なチームを作りたいからといって、個人技に優れたスーパーマンばかり集めるのは、いささか短絡的すぎる。 多様性に富んだメンバーを集めて連携スキルを磨くほうが、実は長期的には効果的なのだ。
無意識の偏見
時間外労働が必要になっても、家庭の事情で対応することが難しい従業員もいる: 例えばシングルファザー/マザーは、勤務時間外には子供のケアに専念する必要がある。 彼らが「時間の融通が利かない」などといった無意識の偏見にさらされることのないよう、組織として対策が必要だ。 これは業務だけではなく、忘年会などの時間外イベントについてもいえる。
権力関係
発言内容が同じであっても、権力関係次第でコミュニケーションは平等でなくなることがある。 権力関係には、肩書きのようにわかりやすいものから、性別・人種・性的嗜好のように微妙なものまで幅広いことを認識しておこう。
非難のない文化
障害発生時に犯人探しをしても、組織の成長には何のメリットもない。 このような非難文化は、ミスの原因を個人の能力不足とする固定思考から生まれる。 成長思考で仕事に取り組めば、困難な状況や失敗はレベルアップの貴重な機会となる。 また組織としては、ミスが起こり得ない業務体系をつくってゆくことが必要だ。
評価制度
こまめなフィードバックは、従業員が自ら設定した目標を達成するうえで大きな助けとなる。 一方で、年1回しかない相対評価は、従業員のやる気を削ぐ最高の方法だ; 多くのスタートアップ企業は、相対評価自体を廃止している。 評価制度は、組織ではなく、従業員の役に立つものでなければならない。 このとき、結果だけではなく過程を評価すれば、従業員の成長思考を育むことにもつながる。
リモートフレンドリーなコミュニケーション
リモートワークのメンバーにも、情報へのアクセス権やコミュニケーションの機会が均等に与えられているか、注意を払おう。
対立の解決
仕事に真剣に取り組む人々の間には、しばしば意見の対立が起こる。 こんなときは、よくある悪い解決スタイルに陥っていないか注意しよう: 自分だけおいしいとこ取りしようとする「競争」; 将来の見返りを期待して譲歩する「便益供与」; 遠回しに押し付け合う「忌避」; ただの中途半端「妥協」── DevOps チームたるもの、対立は協調と協力、そしてコラボレーションによって解決したいものだ。

ここまで見てきた事項は、「デジタルトランスフォーメーション」という言葉から受ける印象とはだいぶ違うのではないだろうか。 DevOps がこれだけ人間的問題を重視するのは、強い組織づくりには文化の醸成が必要であることを知っているからだ。 開発者たちの働き方の基礎である「ビルド」も、決して薄っぺらい自動化ではなく、動く知識を積み上げる文化の一部といえる。

ここまでの解説によって、DevOps とは結局なんなのか、かえって分からなくなったかもしれない。 最後に、この概念についての間違った表現に触れながら、その輪郭を掴みなおしてもらおう。

間違った表現

「DevOps を実現するためにこれらのツールを使う」という表現は間違っている。 DevOps とは、一定の基準を満たした状態のことではないし、まして「DevOps キット」のような吊るしの商品を買ってこれば済むものでもない。 DevOps 的なふるまいとは、自分たちの状況に合った仕事のしかたを見つけ出し、その後も定期的に見直していくこと──つまり達成されるものではなく、継続的な取り組みだ。

「DevOps チームの凄腕メンバーたちは、いつも難しい問題を解決してくれる」という表現にも問題がある。 「〇〇技術を使って何とかできないか」という表現も、本質的に同じだ。 問題を外部に丸投げすれば、短期的には生産性が高まったように感じられるかもしれないが、 このような他力本願な思考は、自己成長をストップさせるだけでなく、新たな縦割りを生んで組織の生産性を低下させる。

残念ながら、「DevOps を学べば、問題は全て解決する」という表現も誤りだ。 DevOps を学ぶことはむしろ、すべての問題は結局のところ自分たちで解決するしかない、ということを自覚することだ。 ただし、成長思考に立つ者にとっては、どんな困難な状況も全て学習の機会となる── 本当の失敗は、学ぶことに失敗したときだけだ。 個人も組織も、学習を重ねることでいくらでも成長できる。

まとめ

ソフトウェア業界から生まれたこの難しい概念について、なんとなく理解できただろうか。 DevOps とは、特定の解決策を指す言葉ではなく、持続的な生産性向上を目的とした取り組みのことだ。 その過程では、ツールを効果的に使うだけでなく、円滑な人間関係を築くことで、仕事に関わる全ての関係者のコラボレーションを促進する──組織としての生き方を変えることともいえるだろう。

DevOps についてさらに知りたければ、『Effective DevOps5』を読むことをおすすめする。


  1. 経済産業省(2018)『DX レポート〜IT システム「2025 年の崖」の克服と DX の本格的な展開〜』URL ↩︎

  2. Rindrics.com『仕事とは価値づくり』URL ↩︎

  3. Rindrics.com『働き方を変えるには』URL ↩︎

  4. 北村(2018)『EX(従業員体験価値)が鍵となる次世代エクスペリエンス戦略 リアル接点におけるCX向上アプローチ』 URL ↩︎

  5. Davis & Daniels(2018)『Effective DevOps──4本柱による持続可能な組織文化の育て方』URL ↩︎