はじめに

「DevOps」ご存知ですか？
私は「あー、あれだよね、知ってる知ってる、開発と運用を良い感じにするヤツだよね（知らない）」って状態でした。
そんな自分が、DevOpsについて勉強して、プロジェクト¹の中でいろんなカイゼンをチームの人と一緒にしていった話をまとめたいと思っています。

そもそもDevOpsって何？

Wikipediaより

DevOpsは、ソフトウェア開発手法の一つ。
開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。
厳密な定義は存在しておらず、抽象的な概念に留まっている。
ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。
また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。

抽象的な概念かよ！そりゃイマイチ分からないはずだ！
じゃあ「我々なりのDevOps」を定義しよう！ところから始まりました。

一般的なDevOps

かるく触れます。

Dev	Ops
機能追加	安定稼働
プロダクト指向	サービス文化
イノベーション	合理化

上記のような対立構造が基本的に存在しており、それらを解決するために以下のような手法を取り込むことがよく提案されている。

• CI/CD
• アジャイル
• 自動テスト

また、多くの記事が「文化を変えること」をもってDevOpsとしており、『「ツールを導入すること」だけがDevOpsではない』、と言われている。

我々のDevOps

まず、先に結論だけ書いておく。（割と一般的な結論な感じですが）

我々のDevOps＝「組織文化の変化を伴う開発プロセス改善活動である」

「組織文化の変化」ってのは、結局は個人の考え方の変革です。
いつのまにか「どちらかに肩入れしていた」ことに気づき、相手に歩み寄る提案をしていくこと/提案がしやすい環境にしていくことを、文化の変革だと思っています。

「開発プロセスの改善活動」ってのは、単純にCI/CD導入したら終わりじゃないよ！って良いたいだけです。
いろんなカイゼンが考えられることを指し示したいのです。

でも、これだけで伝わるとも思ってないので、実際の歩みを説明した後に再度述べます。

最初のカイゼン・ジャーニー

改善の始まりは、以下要望をお客様からいただいたところからでした。

• 前とだいたい同じもの作って欲しいな
• 細かい要件は後から出すよ（ウォーターフォールで結合テストぐらいの時期）
• 少しでも早くカットオーバーしたいから早めに着手したいよ

こうなると、今までのようなウォーターフォールでは対応できない。アジャイルだ！DevOpsだ！と話が進んでいきました。

カイゼン

マネージャーがアジャイル/DevOpsに対して積極的だったため、様々なことが実現されました。
この時点の変化は「トップダウン/ミドルダウン」でした。

実現したカイゼン

• Excelでの進捗管理からの脱却
• Jira/Confluenceを活用した顧客との密な情報共有
• 受け入れレベルでの再帰テスト導入
• CI/CDの高頻度化
• ワンステップリリースの実現（開発環境）
• 各種自動化プラットフォームの構築
• and more

どのようにカイゼンさせたか

上記にあげたカイゼンの具体的な内容は世の中に情報が溢れていると思うので、ここでは割愛します。
カイゼン活動全般において、ポイントになった部分を中心にお話したく。

マネージャーが協力的だった

マネージャーが協力的だったため、そこのハードルがなかったため、非常に試しやすい環境にあったのは確かです。
「それを導入する効果は？費用対効果としてはどんなもん？」とかいう、まどろっこしい問答を繰り返さなくて済んだのは非常に大きなポイントだったと思います。
「きっと効果があるんでしょ？じゃぁやってみようよ！」というスタンスで居てくれたのが、一番の後押しだった気がします。

多くの人が気にされるであろう、「マネージャーへの説得方法」に関してはノウハウが無く、恐縮です。
ただ、当時マネージャーの話していたのですが、以下考えがもう少し広まったらいいなと思います。
もうウォーターフォール的に計画をしてからカイゼン活動をするのでは取り残されるばかりなのだから、ひとまず導入してから評価する動きに変えていきたい。

もし、次に頭の硬いマネージャーに当たったのなら、「時代が変わったことを理解してください」と、ただ一言伝えた上で、無理矢理にでもカイゼンを推し進めるくらいしか、思いつきません。
（もしくは、話の通じるマネージャーを探し出して、社内政治的になんとかするとか。だいたい「(目先の)費用対効果云々」の話をするのは中間管理職な気がするので、もっと上の人を引っ張り出せば、なんとかなると思っています。）

先導/推進できるメンバーがいた

今回、先導/推進できるメンバーがちらほらいたため、現場への適用に際しては、それらメンバーの推進力がかなり大きかったです。
自分自身も上述の半分くらいを先導/推進した立場でした。（なんか自画自賛みたいになっちゃいましたが、頑張ったので褒めてほしい。）

こういうカイゼンを、何も知らないところから始めるのは、本当に骨が折れます。
何かしら事前知識を有して居たり、部分的にでも構築経験があったり、そもそもこういったカイゼンに興味があるかどうか、ってのは本当に大きなポイントでした。

カイゼンにモチベーションが湧かない人では、カイゼンは進まないです。
（そのカイゼンの効果を得られない人が、カイゼン担当になっているケースを多くみてきましたが、大半が「効果なし」扱いで、取り組みすらしなかったような気がします。）

カイゼン担当を専任にした

カイゼン系って、だいたいが「現業と兼ねる」ことを求められると思います。
カイゼンが継続的に回っている状況下では、兼務でいいと思いますが、一番最初のスタート時点ではカイゼン専任の人を置くのが良いと思われます。（今回は、私がカイゼン専任でした。）

そもそも、現業と兼ねてしまうと、どうしても「現業優先」になります。
計画上は、仕事量を50%ということにしたとしても、結局80%くらい現業に追われます。
いっそ、専任にした方が効率は圧倒的に良いです。

現場ファーストで考えた

自分自身としては、「現場の人との対話」が一番大事だったと思っています。
細かい設定なんて、現場によって変わりますが、結局現場の人が「良い」って思わなきゃ「カイゼンした」とは言えないので、そこには非常に注意しました。

具体的には、「使い勝手」です。
「手順を説明しないと使えない」ってのは、なかなか使ってもらえないので、
「見たら分かる」というレベルまで使いやすさを追及しました。

引き継ぎを意識して資料を残した

別に細かい設定資料は要らないと思っています。
どういう考え方/方針で、この設定を行ったのか？
基本的なデータモデルはどうなっているのか？
など、全体概要が把握しやすい資料を残しておくと、引き継ぎの時スムーズです。

細かい話は、「システム屋なんだからソースコード読め」でごり押ししました。
ただ、無理強いするのではなく、方針レベルの記載が誤っているがために、伝わっていないケースもあったので、そういうのはちゃんと直したり、資料を補足したりしました。

しのごの言わずに始めてみる

最初っから、いい感じにカイゼンして行くなんて、どうせ無理です。
確実に想定外の問題にぶち当たります。
でも、始めないことには、何も変わりませんし、何が問題なのかも想像の域を出ません。

やってみたら、事前に想像して居た問題（あの人が文句をいうかも？）とかは、意外と無いかもしれません。
逆に想像もしてないところ（ツール操作がわかりづらくて定着しない）とかが爆発して、味方が敵に変わったりとか。

「まぁそれが人生かな？」くらいのおおらかな気持ちでとりあえず始めてみましょう。

今の現場でうまく行かなくても、いろんな現場でトライして行くうちに経験がたまり、それが結果に繋がると思います。²

私がぶち当たった壁

マイナーチェンジに固執してしまう

一つカイゼンを行うと、ついつい、そのカイゼンをさらに良くしようとしてしまいます。
具体的に言えば、「Jenkinsを導入したら、あまり使わないアドオン探しに夢中になってしまう」とかです。

カイゼン専任が目指すべきは「メジャーチェンジを増やす」ことだと思って居ます。
幅広くカイゼン活動を行い、細かい微調整は現場が行えるようにすることが大事です。

そうでなければ、引き継いだ後、カイゼンは広がりません。

この時は、相談相手が居たことで、マイナーチェンジに固執せずにすみました。
相談相手は、マネージャーだったのですが、カイゼン活動の舵取りができる人であれば、マネージャーでなくても良いと思われます。

少なくとも、専任だからと言って、一人で考えるのはあまり良くない気がします。

引き継ぎがうまくいかない

すれ違いによる不協和音

いろいろとカイゼンを行ったプロジェクトではありましたが、これらのカイゼンした結果を保守チームに引き継ぐ必要がありました。

すれ違いは、引き継ぎ初日から起きました。

私「Jiraとかのカイゼンした話するよー」
保守の人「聞きたい教えてー」
私「このカイゼンは、ここらへんが便利になって、こんな良いことができるようになったよ」
保守の人「そんなのは別に要らないから、具体的にこういう時はどういう操作したら良いの？ツールの操作方法を教えてよ。」
私「いや、ツールの使い方を説明する場ではないと事前にお伝えしていたのですが・・・」
保守の人「え？じゃぁ何の場なの？」
私「いや、カイゼン活動自体の引き継ぎを目的としていたのですが・・・」
保守の人「え？」
私「え？」

みたいな。

原因

私「いろいろカイゼンした話するよー(保守でどう使うかは保守の人で考えてねー)」
保守の人「(保守でどうやってJiraの使えば良いのか教えてくれるんだろうな)聞きたい教えてー」

結局、保守の人から見たら「新しいツールを導入した」が一番大きな要素に見えており、「具体的にどう使うか？」がフォーカスされていたようでした。
一方で私は「こんなカイゼン活動をしたので、ぜひ引き継いでいってほしい。具体的にどう使うかは、保守の人が決めてくれれば良いよ。」という思いだけで話をしており、保守の人の受け取り方を無視した説明会をしようとしてしまっていました。

つまるところ、DevOps担当と言われながらも、結局相手に歩み寄った説明会が開催できなかった私自身に原因があったのです。
私が他チームへの越境が不足していたのです。

許可を求めて三千里

最初の頃は許可を求めて奔走してました。
「安全安心にことを運ぶためには、事前に許可を得ること」という金融系基幹システム保守時代に染み付いたくせが、悪く出て居ました。

カイゼン関係で許可を求めようとすると、いろんな壁があります。

• 関係者が多すぎる：関係者間をまたぐところが、だいたいカイゼンできて居ないところでした。
• キーマンが居ない：カイゼン対象の管理主体がおらず、みんな「オレはよく知らないので、関係ない」と思っている。
• 単純に無駄：「許可する以外に選択肢ないでしょ？」ってのも、わざわざ丁寧にうやうやしく拝聴しにお伺い申し上げないといけないでござる。

原因

金融系基幹システム保守時代に染み付いた「安全への異常な偏重」がカイゼン不全もたらしていました。

「安全への異常な偏重」とは、何かを変えるためには、社内のAさんBさんCさんの承認が必要で、加えてお客様のDさんEさんFさんの承認が必要。
ただしみんな忙しいので、バラバラに説明しなくてはならい。
これらを試行計画・試行適用・本格計画・本格適用の4回繰り返す必要がある。
と言ったような状況です。

そんな事しているうちに、新しいツールは来るし、バージョンは古くなるし、何よりもただただ面倒。
客観的に見れば、カイゼン不全は「当然」と言える状況でした。

対策と結果

越境不足

「越境不足」には、「期待の明確化」が有効でした。
私は「保守に、カイゼンノウハウを引き継いで、今後もカイゼンが継続される状況を作りたい」
保守Tは「直近での保守での適用方法を知りたい」

「保守への適用方法とその後の未来予想図を、みんなで検討する会」を開きました。
これは、参加者皆満足する形で終えることができました。

安全偏重

「安全偏重」には、「本格適用のみ」＆今まで承認してもらっていた人には「メールでの事前連絡のみ」にしました。
事前連絡は、「許可」というニュアンスではなく、「通達」に近いニュアンスで用いていました。

一部、「いや、事前に連絡してくれないと困るんだけど！オコだよ！」みたいな人も居ましたが、無視しちゃいました。
何かを考えて無視したというよりは、「若気の至り」くらいの勢いで、気づいたら無視していた。

結果、圧倒的にカイゼンスピードも上がり、変化が早くなりました。
良かった。

立ち止まって振り返る

一通りカイゼン活動も終わった頃、一度振り返ることになりました。（単に「下半期が終わるタイミングだった」のもあります。）
具体的には色々カイゼンさせたけど、そもそも今この状態って、DevOpsできているのか/できていないのか？

独自基準における評価

DevOpsができていない状態とは？

そもそも、DevOpsできていない状態とは何でしょうか？
一般的な話からすれば「DevチームとOpsチームの対立」を指すらしいです。

今まではピンと来てなかったのですが、ここに来てピンと来た感じがありました。
実際の現場では「対立」というよりは「不協和音」という表現の方が近いのかもしれません。

あの「不協和音」は、チームの外ではまだDevOpsが広まっていなかったという気づきでもありました。
また、「安全への偏重」もまた、DevOpsを阻害する要因に思えます。

上述のような経験を経て、我々の定義³を鑑み、我々は「DevOpsできていない状態」を「安全偏重/越境不全などから来る、変化/カイゼンが生まれにくい状態」としました。

評価結果

つまり、自チーム内ではできているが、一歩外に出ただけで瓦解してしまうような軟弱なDevOps状態だった。
というのが、正直な評価でした。

一般的な評価尺度

いかに抽象的な概念だからと言って、独自基準ばかり話していても、しょうもないカイゼン活動になるので、外部の指標を集め評価を行いました。
社内のR&Dチームから提供されたアジャイル評価尺度を用いて、良いところ悪いところが見えてきた。
ちょっと展開していいのか不明なので、ココでは展開できないです恐縮です。。。

でもそれじゃあ申し訳ないので、とあるWebサイトやアジャイル実務ガイドに評価尺度があることを確認したので、ご参考にしてください。
アジャイル実務ガイドは付録が良い感じなのでおすすめです。

評価結果

端的に言えば、出来ているところもあれば、出来ていないところもある。というデコボコした感じでした。
（丸めすぎた表現で、全然伝わらない気がしますが・・・）

目標定義の難しさ

これらの評価からわかったのは、「目標定義の難しさ」です。
「DevOpsは抽象的概念だ！」と言われてしまうと、ゴールをこちらで設定する必要があるのだろうと思っていました。
でも、それってかなり難しい。ふわっとした振り返りになってしまう。

社内で相談してみたり、もう少し詳しい研修にいってみた結果、DevOpsにまつわる要素においては、いくつか資料も出ており、こういった評価尺度があるのは非常にありがたい部分がありました。

外部基準での評価は、一通りのカイゼンが終わった私達にとって、「まだまだカイゼンできるポイントはあるよ！がんばろう！」と言われた感覚でした。⁴

越境は「自分」から

私は今回の「壁」から、『越境は「自分」から』という学びを得ました。
その「学び」、そして「その先の進め方」について、軽く整理してみました。

1.自分の中の境界を意識する

「内集団バイアス」というのをご存知でしょうか？
端的に言えば、「自分が所属する集団を、無意識に有利にさせようとする、人間の特性」のことです。⁵

それ以外にも人間にはいろんな特徴があります⁶が、ここで理解して欲しいのは「人は境界をつくりがちな存在である」という事です。

自分でも意識しないウチに境界を作り出しているものです、「あれは自分の仕事じゃない（あれはあの人の仕事だ）」「改善を試みたヤツが、ケツを拭くべきであって、オレは関係ない」「それいいね！でも、お客様がOK出すかな？（お客様が納得するレベルになるまで、お前が内容を詰めて来いよ）」とか。

そういった特性が自分にもあるし、周りの人も当然持っているであろうという事を意識した上で、自身の信念を持って、越境をすべきだと思っています。⁷

2.目指すべき状態を明確にする

境界が見えたら、最終的にどういう状態を成したいのか？に思いを馳せるべきです。
これは、「自分も相手も納得する状態」を模索すべきです。
あなたの理想が、相手の理想とは限りません。

自分では思いつかないなら、まず相談から始めれば良いのです。

3.あの手この手で共同戦線を作り出す

そもそもの大前提的な考え方ですが、全員が協力的である必要はない、と思っています。
当然、今までのやり方を変えるわけですがから、反発も出るでしょう。

まぁ、でもそんなのに取り合ってたら、どうせ何も変わらないので、「自分の活動は、新たな変化のための触媒だ！⁸」くらいの感覚で良いと思っています。

そういう心構えをした上で、私が意識したのは以下のようなやり方です。（よくある話なので、取り立てて新しいことは無いです。）

• 言い方を変えてみる
• 同調圧力を使ってみる（この活動に前向きな人を中心に揃えてみる）
• 社内政治的にこの活動の正当性をそれとなく見せつける
• 相手の邪魔にならない簡単なことからはじめる/断られる前提のハードルの高い依頼から入る⁹
• 相手にメリットを提示する
• 無視する。

まぁ、そんなキレイにこのテクニックが使えるほど、コミュニケーションの場数を踏んでいる訳ではないので、失敗したりします。
最終的には、自分のキャラクターにあった、戦略で行くしかないので、やり方は人それぞれです。（ぶっちゃけ、非協力的な人はほとんどいなかったですが、たまに居た人に対しては、だいたい「無視する」ばかり使っていたような気がします。）

自分でいうのも何ですが「活動家」的にみられるケースが多い¹⁰ので、そのノリと勢いでごまかした部分も多々ありました。
私のキャラからすると、ちょっとだけ段取りを組んで、あとは勢いでゴリ押しするってのが、使える戦略でした。

みんなで醸成する「文化」

そんなこんなで、越境を企てていったわけですが、そんな中で、目指したい文化が出てきました。
それが以下です。

• 現場メンバが自発的に考え、自ら改善・変革していく、成長していける風土
  • 誰でもアイデアを出せる環境
    • 非難・否定しない
    • 一緒に考える姿勢
    • やってみよう！という姿勢を全員がもつ
  • 「変化」を推奨するチーム：成功しても、失敗しても、チャレンジしたこと・変化したことを評価する
    • 試したことを「褒める」
    • 導入したことを「褒める」
    • 結果に関わらず「褒める」
  • 信頼と共感が育まれる環境：「垣根をなくす」　⇔　「立場の異なる者どうしの相互理解」
    • 話を聴く　（非難しないで聞く）
    • 相手の立場で考える・想像してみる
    • 個人的な違いを尊重する
    • 自ら自発的に話す。自分を見せる
    • 公平な扱い
• チャレンジしやすい風土・環境を用意する
  • 「試す」時間/人を確保する：（例）GoogleのSREチームは50%が改善タスク、残りで定常業務遂行
    • 改善活動を業務時間に組み入れて計画する
    • 実施状況を共有し合う
  • 成功しても、失敗しても、チャレンジしたことを評価し、次の改善へ繋げる
    • 成功要因は？　　　　→次はこうしよう
    • なぜ失敗したのか？　→次はこうやってみよう
  • チャレンジしたことは全員の財産とする
    • 全員で共有しあい、知見として蓄積する
    • 特定個人に負荷をかけないようにしてチャレンジへのハードルを低くする
• 成果を測り、定量化された状態で表現する。：そこからチームの状態評価と課題を見つけて次の改善サイクルへ回す
  • 見える形で成果を表現する
    • 組織文化の変化　→（例）メンバの意識を数値化してみる
    • 開発プロセスの改善　→（例）ビジネス要求への対応時間を数値化する
  • 課題を見つける
    • ビジネス目標に対する位置づけを評価して改善点をさぐる
  • 次の改善のサイクルへつなげる
    • PDCAのサイクルにのせて進める

これは、理想像として、みんなに伝えているだけで、具体的な動きはできていません。

ピンと来る方もいるかもしれませんが、「心理的安全」であることを中心に文化を設定しています。
心理的安全が興味ある方は、以下記事を読んで見ても面白いかもです。
会議/ミーティングについて本気出して考えて見た結果
【Google研究結果】生産性の高いチームに共通する要素【心理的安全性】

さいごに

我々のDevOps＝「組織文化の変化を伴う開発プロセス改善活動である」
カイゼンするためには、「組織文化」が一番のボトルネックになりうる。
「組織文化」を変えなければ「開発プロセス」だけを追い求めても限界が来る。
「組織文化」を変えるためには、自分の中の越境こそが、一番最初のステップ。

なんか偉そうな感じの記事になりましたが、私達のカイゼン・ジャーニーはむしろこれからなのです。
トップダウンではなく、ボトムアップ型のカイゼンを目指して、越境する人を増やしていく。

そして、この記事に共感した人には、「カイゼン・ジャーニー」がとても合うと思うので、ぜひ読みましょう。
ちなみに、CrowdEnergize:クラウドエナジャイズっていうサービス素晴らしいサービスもあります。¹¹

next カイゼン・ジャーニー

現在、「越境」×「ゲーミフィケーション」というテーマで、「持続可能で楽しい継続的越境¹²(SFCE:Sustainable Funny Continuous Ekkyo)」ってのを企てています。¹³
また、なんかそれっぽい結論ができたら、記事化しますね。

そして、この記事が、どなたかの越境のきっかけになれば幸いです。

以上です。

---