DevOpsの本質はコラボレーション、ニューノーマル下の開発現場で高まる価値
「DevOpsを取り入れたい。だけど一歩を踏み出せずにいる人は少なくない。そんな方に行動を起こすためのプラクティスや私の経験を伝えたい」
冒頭でそう語った横田氏（JFrog）は、この1年の間、コロナ禍によりほぼリモートワークで過ごし、ついには京都に移住といった、まさにアフターコロナの「ニューノーマル」な働き方だった。そんな「ニューノーマル」と「DevOps」についてはセットで語られることが多く、世の中には肯定的な声が多い。その理由について、横田氏は「DevOpsの本質が『コラボレーション』だから」と語る。
そもそもDevOpsは専門ツールの導入や開発手法の一種など、決まったやり方を指すものではない。顧客に価値を素早く届けるために、開発・運用が協力する文化的な姿勢・取り組みのこと。つまりはコラボレーションを促進するものということになる。
DevOpsという概念がなかった頃は、開発と運用が完全に別組織として仕事をし、互いの理解を十分に行うことはほとんどなかった。相手領域での作業が必要な時は、その都度依頼するという、互いに独立した関係だった。一方DevOpsの登場によって密接なコラボレーションが可能になり、文化やツール、ベストプラクティスはそれを支える存在として登場してきた。
「DevOpsが実現できれば、組織やビジネスがうまくいき、自社や自分の価値が上がる。開発も運用も互いのことを考慮し、質の高い成果を出せ、できることが増える。『責めない文化』でバトルが減り、気持ちよく働くことができるだろう。そして、作業の効率化によって時間ができ、新しいことにチャレンジできるし、そもそも早く帰れる」と横田氏はDevOpsのメリットについて語る。
そして、DevOpsでなかった開発者時代について、「チームがバラバラなのに関係者は多く、リリースにすごく時間がかかった。待ち時間も心理的な負担も大きかった」と振り返り、「DevOpsになって責任範囲は広がるが、作ったものがすぐに公開できて反応が返ってくるのは作り手としてはうれしいもの」と話す。
しかしなぜ、改めてニューノーマルと絡めて語られることが増えてきたのか。コロナ禍以降、ニューノーマルにおいては、開発の現場においても急速な変化への対応が求められ、リモートワークの難しさが生じている。そこにDevOpsを活用してコラボレーションを促進できれば、問題を解決できると考えられている。そのためDevOpsの価値が改めて認識され、「実践が必須」という機運が高まってきた。
それでは、どうやってDevOpsを実践するのか。横田氏は、DevOpsそのものはルールや方法論ではないため、ベストプラクティスを取り入れながらも、開発と運用のコラボレーションを大切にしながら自分たちなりに実現するのでいいと言う。「他の真似をする必要もなければ、ゴールもない。ずっと『どうしたらいいものができるのか』といった問いや議論をし続けることになる」
つまり、「DevOpsは組織の数だけ正解がある」ということであり、自分たちで「やったもんが勝ち！」なわけである。しかしながらフレキシブルゆえに、何をすればいいのか戸惑う人も少ない。
横田氏は、よくもらう質問として「結局何から始めたらいいですか？」「ベストプラクティスを教えてほしい」「DevOpsの考え方を取り入れることのメリットを周りの人に伝えるにはどうしたらいいですか?」「上の人が動いてくれないんですが......」などがあることを紹介。その多くがチームや組織が動くべきと考え、一人では何をしたらいいのかわからないでいる。
一人でだって、始められる！ 周りを巻き込みDevOpsを実践する方法とは？
「一人だからといってDevOpsを始められないわけではない」と横田氏は強調する。たしかに上層部を含めて周りの理解や協力があり、組織の方針やスタンダードになっていればDevOps導入は簡単だ。しかし、理解者がおらず、権限や知識もないからと諦めてはいないだろうか。
「同僚が興味を持ってくれない」「うちの会社は古いまま変わらない」と思い込む。「わかっているのは自分だけ」と嘆く。「なんとなく新しい技術を取り入れないといけない気がする」「流行っているからやりたい」、など漠然とした理由で、会社に対応を求めるばかりで、行動していない人は少なくない。
横田氏は「もし変化を起こしたいと思っているなら、ネガティブに見ているばかりでは何も変わらない。まして変化は一人では起こせない」と言い、人を巻き込みながら変革に取り組む方法について書かれた本、『INFLUENCE WITHOUT AUTHORITY』（和訳版『影響力の法則』）を紹介した。さまざまなフレームワークなどが掲載されており、自分の姿勢の点検に役立てたり、行動の参考にしたりできる。
そして、その中に紹介されているのが「人に影響を与えるモデル＝The Cohen Bradford Model」だ。
まず第1ステップは、同僚を「味方」と捉えることから始まる。向き合い、語り合うこと。そして、話す前から協力してもらえないと決めつけて諦めない。そして、最初に行動しようとしている自分を過大評価しないことが大切だ。
「もちろん最初に動く人は偉い。でも、それを自分で過大評価しすぎると、『自分はがんばっているのに』と被害者意識を持ってしまいがち。辛い時に自分を鼓舞するために、時にはよいが基本的には忘れている方が賢明」と横田氏は話す。
第2のステップは、ゴールと優先順を決めることだ。曖昧で大きなゴールではなく、日々抱える課題に即した具体的な目標をたてるのが望ましい。複数になるようであれば、その優先順位をつける。またモチベーションアップのため個人の望みも入れてもいいが、組織のゴールとは分けるようにする。
第3のステップは、他社が置かれた環境を理解することだ。同僚などでも人によって気にすることや求めるものは異なる。そこを理解することで自分自身も楽になり、相手のパーソナリティーや行動を受け入れられるようになる。
第4のステップは、交換する価値を見極めること。ギブ＆テイクを打算的と捉えられがちだが、人を動かすには、与えたりもらったりしながら進んでいくことがよい。なお、権限や予算を持っていないと自分を過小評価しがちだが、どんな人でも価値を与えることは可能と心得たい。例えば、人に刺激を与えたり、タスク関連やポジション関連の価値を与えたり、関係性を作ったり、個人的な感謝や支えなども十分「交換する価値」になりうる。
第5のステップは、関係性を築くこと。「今の関係性はどうか」「相手はどういった関係性を求めているか」といった2つのポイントに留意しながら関係を構築することが大切だ。人との関係性は夫々を好むスタイルがあり、自分のやり方を押し付けないように気をつけること。
第6のステップは、ギブ＆テイクで影響を与える。タスクの実行といい関係性の2軸で価値を与え合うことで、周りを巻き込んで成果をしていく。この時、ギブとテイク、損得を意識するのではなく、「相手にもらうために自分にできることがある」と思えることが大事になる。
失敗と成功で変わっていたのは「自分」だった？ DevOpsを起点にコラボレーションの在り方を考える
ここで横田氏は、かつて以前の自身の経験を振り返った。まだ経験がない頃に、技術コミュニティに参加し、大いに刺激を受けたことでモチベーションが上がるプラス面の一方、レガシーな現場に不満を感じ、「皆より知っている」という勘違いに陥ることも少なくなかった。
「意識の高い、期待の新人っぽい雰囲気を出しつつも、何の改革もできなかった」理由について、横田氏はダニング・クルーガー効果とも言われる「見事なアンチパターン」と分析し、「なんとなく」レガシーなのがイヤという目的の曖昧さと、他者を味方として信頼せず思い込みにとらわれていたことの2点をあげた。
その後、経験を重ねる中で「頭でっかち」だったことを認識し、大きな変化が生まれたという。まず行動できるようになったこと、ゴールを常に意識するようになったこと、そして相手の立場や目指していることを想像するようになった。その3つにおいての変化により、前述の6つのポイントを意識しながら考え行動することで、エンジニア広報としての法務担当者と連携した案件で成功体験を得ることになる。
横田氏は「お互いの要望を満たした状態でゴールを達成できると信じ、関係性を作り上げたことで、時にチェックし合う対立が生まれる場面においても、一緒に作業している達成感が生まれた」と語り、「失敗経験と成功経験の両者を比べた時に『変わったのは自分』という実感があった」と振り返った。
そうしたコラボレーションの価値を実感すると、もっと進化させたくなるだろう。そこで、横田氏がおすすめするのが、ツールや方法論を参考にすることだ。さらには行き詰まった時には、具体的な行動の仕方を真似をしてみるとよい。前述の本に加え、『カイゼン・ジャーニー』（翔泳社）や『アジャイルレトロスペクティブス』（オーム社）、イベントストーミングなどの手法などが紹介された。
個人のコラボレーションの推進から、改めて「DevOpsの組織への導入」というテーマに立ち戻って考えると、そもそもゴールに至る旅のどこにいるかが重要になってくる。「DevOpsって何？」という地点から、開発・運用チームの協力のレベル、ツールや文化、事例研究などさまざまなフェーズに至り、最終的には「顧客に素早く価値を届ける、フィードバックループを素早く回す、変化に対応する」といったゴールにたどり着き、再び改善へと戻っていく。その中で、必ずしもコラボレーションすべきは「開発と運用」だけではないと言う。
組織が多様化し、ソフトウェアが複雑化する中で、開発・運用を進めると、さまざまな人と関わり、その協力が必要になる。セキュリティや社内IT、QAなどさまざまな部門との連携もあれば、営業とエンジニア、数カ国のメンバーなど、多彩なコラボレーションが行われている。
横田氏は「DevOpsよりも複雑に見えるが、基本は何も変わらない」と言い、「人に影響を与えるモデル」の最初の2ステップの重要性を強調した上で、「そこが固まれば、3ステップ目以降は既に仲間がいる可能性もあるので最初から心配しすぎないでいい」とアドバイスした。
そして、「まず自分と向き合い、課題を見つけ、その上で動けばどんな人にとっても動きやすいのではないか。そしてゴールと方向性を定めて動き出してから、DevOpsと違う？ と思ったとしても、それで昨日よりよくなる、幸せになれるのなら正解。DevOpsを目指すことではなく、DevOpsを起点にして本当の目的、ゴールに気づくことが大切」と語った。
他にも行動するためのヒントはたくさんある。デブサミのようなイベントや、DevOpsやアジャイルなどの記事や書籍、SNSでのつぶやき、そして実際に行動して考え、話し合うことで得る気づきも多いだろう。失敗も含め、経験から学ぶことも大切だ。
最後に横田氏は、「誰もがニューノーマル時代の働き方において、試行錯誤をしているはず。距離が遠いからこそ、コラボレーションが大切になる。ぜひ、できることから始めてほしい」と強調し、セッションを締めくくった。
JFrogはDevOpsの促進に役立つプラットフォームを提供しています。JFrog Artifactoryによるバイナリ管理を中心とした継続的インテグレーション（CI）と継続的デプロイメント（CD）の実現が可能です。無料プランもご用意しておりますので、ぜひお役立てください。：JFrog Platformご利用開始ページ
