2020年は、とくに IT の活用失敗に関するニュースが目立ちました。例えば、マイナンバーは申請だけオンラインで、給付と管理は手作業だったり、使ったこともない仮想口座サービスに気づかぬうちに自分の通帳を紐付けられ、不正に出金されるなどを散見します。そしてそこからの対応がとても遅く、その団体の信頼がどんどん失われていきます。
これらの問題は、テクノロジーの問題ではありません。組織、文化、経営、つまりビジネスの問題です。
テクノロジーを真に活用し、新しい時代を生き残るための必要なものは、新しい技術ではなく、新しい技術を活用できる、新しい「令和のビジネス形態」です。そして、その令和のビジネス形態として、高い品質、素早い対応、少ない機会損失、社内外の信頼を高める、「Agile/DevOps」を解説していきたいと思います。
では、それを達成するにはどうしたらいいでしょうか？
実際に自分自身でAgile/DevOpsを調べ初めた際は、開発にツールを使った自動化のところ部分のみが目に入ってきていました。そこから更にAgile/DevOpsに関わってきた数社にインタビューをさせていただき、自動化する前に重要な部分があることが見えてきました。今回は自動化の部分よりもそれ以外の重要な部分を探っていきたいと思います。
Agile/DevOps
実際には理解されていない事が多い、インタビューの中に以下のような話しがありました。
イネド「問い合わせてくる顧客は、実際にどれくらいAgile/DevOpsに精通していますか？」
クリエーションライン株式会社（H.A.）「顧客によってそれぞれ異なるのですが、DevOpsについてはさほど精通してはいない印象を受けています。Agileに関してはすでに活動開始されていたり、ある程度の認知状態をもって問い合わせをしてきていただくことが増えてきました。」
インタビューさせていただいた各社からみえてきたのが、DevOpsという言葉は日本ではあまり認知されていないようです。どちらかというとAgileの方が日本では知られているようでした。実際にDevOpsとAgileはかぶっている部分かなりあり、明確に使い分けられているわけではありません。更にそこにいろいろと関連する言葉として、DX、Scrum、シフトレフト、CI/CD、パイプラインなど、いろいろ言葉がでてきて大変混乱しました。これらの言葉は概念的なところは似通っているものや、範囲が違ったり、実際の手法だったりと理解するまでかなり苦労しました。
DevOpsのもともとの話しは、2009年にFlickr社の「10 deploys per day」から始まっています。提供しているサービスのデプロイ（更新）を1日に10回もできているという、当時ではかなりの衝撃の話しでした。詳細は割愛しますがツールと社内文化を変えることにより、Dev（開発部門）Ops（運用部門）が協力して混乱なくサービスを1日10回も更新することが可能になったという話しです。
この話しを読むとツールだけを導入するのではなく、社内文化もあわせて改革していくことが必要であることがわかります。
目的を間違いがち
Agile/DevOpsの導入に関して具体的にどのような問い合わせが多いですか？
効率化やリリースを早くしたいということで問い合わせをしてくる顧客が多いです。場合によってはAgile/DevOpsを試してみているが、うまくいかないということで状況を確認すると、部分的なツールの導入になっていたり、局所最適になっていることがよくあります。
インタビューの内容のように多くの場合、現段階ではAgile/DevOpsを正しく理解し実践できている会社はほとんどないようです。かくいう私もそうでしたが、効率化を通じてサービスを早くリリースするという目的だと思っていました。間違いではないのですが、それを実現する部分が大きく抜けてしまっています。この視点で話しが進むとどうしても「効率化によるコスト削減」的な意識が強くなります。
本来の目的は「効率化によるコスト削減」ではなく、「自動化をもちいて開発（改善）のスピードをあげ、高品質なサービスの提供を可能とし、ビジネスの機会損失の削減」になります。
従業員が日々の繰り返し作業、確認作業などから開放された分、いかに新しい企画、もしくは顧客からのフィードバックをもとに既存サービスの改善、別部署のアシストなど、あいた時間をいかに有益に使えるかがポイントです。
Agile/DevOpsおさえておきたいポイント
コミュニケーション（=文化）を変える
いろいろな会社をコンサルタントしてきていると思うのですが、共通のボトルネック的なことはありますか？
組織の壁によるコミュニケーションロスはよく見かけます。お互い同じこと考えているのにコミュニケーションをとっていなかったりとか、ちょっと外から見るとなんでこうなってるんだろうなと思うようなコミュニケーションロスは結構ありますね。直接話して少し確認をしておけば解決できるような問題が、会話していないがために後半になって大きな問題となっているというパターンが多く見受けられました。
DevとOpsがコミュニケーションとるためにどんな支援しますか？
話すことです。とにかく対話。できればオンラインではなくFace to Faceで。対話の場をつくるということが大事です。
インタビューから見えてきたのは意外にもFace to Faceの対話不足でした。こんな基本的なことと思われがちですが、チャットツール類の発達で便利になりましたが、Face to Faceのコミュニケーションに勝るものはないようです。確かに顔をみて話すことにより、テキストだけでは読み取れない情報がたくさんあります。
関連する部署を含めたプロジェクトチームの構築
顧客にAgile/DevOpsを説明する際に最も重視する部分はどこですか？
単純にDevとOpsが協力するのがDevOpsみたいな話しになりがちですが、実際には間違ってはいないけど、どう協力するのかが一番大事。その真ん中にあるのがメトリクスの共通化だったり、ソースコードを両方が見るとか、インフラを自動化してインフラのコードはインフラサイドが書くが、それをDev側が手伝えるようにしたりと、そこらへんの協力が大事です。
現在は代表者がミーティングに参加し、自分の部署内でミーティングの内容をシェアして仕事をこなしているところが多いと思いますが、それだと仕事の依頼だけが伝わり、何を目的としているのか、他部署、社内の状況などの情報が見えません。見えないほうがいいという声も聞こえそうですが、毎日依頼されたことだけを行っているのでは新しい発見もなくなり、仕事へのモチベーションを維持することが難しいでしょう。
チームを組む趣旨としては、全員が情報を共有し、部署や役職の垣根なくサポートし合うのがチームを組む目的になります。
実際に上記の内容を体験することが可能な研修があります。株式会社ITプレナーズジャパン・アジアパシフィックが行っているフェニックスプロジェクトです。書籍「The Phoenix Project」（邦題「The DevOps 逆転だ!」）を基にした、丸一日使ったゲームスタイルのワークショップ型研修です。座学はほとんどありません。
言葉や資料で説明されるよりも、体験することにより短時間で関係者全員でミーティング、コミュニケーションのとり方、情報の共有などの有用性を深く理解でき、とても楽しいものでした。Agile/DevOpsの重要性を経営陣、管理職、チームメンバーに体験してもらう方が手っ取り早いと思います。
実際に取り入れたい手法
ミーティング（コミュニケーション）の進め方
さて上記で何がポイントかが見えてきたかと思いますが、今まで通りミーティングルームに集まって、進行役がほとんど喋って終わる形では全員参加でのよい成果はでません。
かかわっているメンバー全員で、目的を共有し、自由に発言できる環境を作ります。そこからプロジェクト作成、実行、定期的な見直しを繰り返しながらプロジェクトを進めます。インタビューより見えてきた、それを可能にしてくれる一つが以下の方法です。細かい手法は今回は省きますが、ぜひ試していただきたいです。
社内で固定の座席（デスク）がないような、形作りというのはどういった手法ですか？
ジョイ・インク（Joy, Inc.）のメンロー社 を参考に作っています。天井を抜いたりとか、仕切りを無くして一部屋を大きくとか、部屋中の壁をホワイトボードにするとか、机や座席を動かせるようにしておいて目的に応じたレイアウトにすぐ変えられるとか、を意識して作っていますね。」これはメンロー社が「全社員が仕事に喜びを感じられる環境を作る」をどのように作ったかという話です。「ジョイ・インク 役職も部署もない全員主役のマネジメント」という本が出版されています。
文化を変える上で手助けになるようなことはありますか？
あります。スクラムという方法で、それぞれのチームが自己組織化できるようにしなければいけません。1人ではできないことをチームで解消しようとするのがスクラム。たとえばQA(Quality Assurance)ができない時、チームの中にQAのコンピテンシーをもつ者を取り入れたりする。
Scrumの概略としては、チームでプロジェクトを進めていくうちに出てくるあらゆる問題点を、短期的なサイクルでチーム全員が問題点を共有し、改善案をどんどんだします。問題点の共有は、担当する人や部署を非難するのではなく、改善案を全員で提案する事が目的とする手法です。
属人化が削減
どのような考えでスクラムを取りれたいと問い合わせがきますか？
ケースバイケースだけど、けっこう多いのは属人性が高いのを不安視しているパターンで、組織が大きくなっていく上で属人性が問題になるのを解決する
よく聞く「その事はあの人にしかわからない」などをなくすことが結果的にできます。
同じチーム内もしくは他部署の人でも複数人で取組むことにより、担当者1人に頼ることなどを減らすことが可能になります。
現在の状況を可視化
企業がDevOpsへの移行を開始するときに目指すべき最初のマイルストーンは何がありますか？
企業によってボトルネックとペインポイント（PAINPOINT）がまったく異なっています。特別な事情のもと、特別に作りあげられてきた独特の社内プロセスみたいなのが存在します。一概にこれをなおせばすぐにできるというのはないのです。それが一番どこがボトルネックになっていて、どんな痛みを感じているのかを判断するためにValue Stream Mappingをやっています。これによってプロセス全体の流れを見える化し、ボトルネックやPAIN POINTを特定します。その後はそれを改善する活動に集中していきます。
これはどんなことにも言えることですが、正しく問題点を把握していなければ、どんなに対策を打っても効果は薄いですよね。インタビュー内で出てくる「Value Stream Mapping」を全員参加で、現状の可視化をします。そこから問題点を洗い出し、改善するためのタスク作成をして、プロセスを検証していきます。
最後に自動化
ここでやっとプロセスを自動化していきます。ここで始めてツール類の投入です。できるだけ毎回発生する繰り返し(反復)作業、人間が苦手(時間のかかる)な確認作業を自動化していきます。そしてそのプロセスを検証し、問題があるときには全員で案を出して修正していきます。
これによりツールで安定したリリース品質を保ちながら、迅速に素早く新しいサービスもしくは改善したサービスをデプロイする環境を整えていきます。
すでにコミュニケーション方法、問題の洗い出しなど完了されていて、ツール類を探しているという方は、最後のリファレンスページにある弊社ツール類を試していただければと思います。
更に有益なプラス効果
上記手法を利用することにより、さらにチーム、もしくは社内によい効果が現れます。
最後に Agile/DevOps に関して「これだけは伝えたい！」ことはありますか？
とにかく楽しい。楽しいと思うことをどんどん見つけていってほしい。ただDevOps/Agileをやるだけではなく、自分の組織、チーム、職場が毎日わくわくするような場所に変えていってほしい。じゃなければやる意味がない。
各メンバーも幸せになるはず。仕事のやりがいをもっと感じられたり、早く帰れるようになったり。Agile/DevOpsは働き方を変える、新しい時代の働き方の標準にしていった方がいい。継続的デリバリーだけでなく、継続的改善もしていこう。ITILでも言ってること。リリースして終わりではない。トヨタも継続的カイゼンしてきたから、一位になれた。Agileもさかのぼればトヨタ生産方式に結び付く
手法はいろいろな方法があるとは思いますが、インタビューの中で共通して出てきた言葉として、「仕事のやりがい」や「仕事を楽しく」という言葉です。Agile/DevOpsを通して結果的にやりがいや楽しさが出てくるのであれば、経営者、従業員ともによいことですよね。
ベイビーステップ
さてここまで読んでいただいた方はもうおわかりだと思いますが、Agile/DevOpsは自動化の部分よりも、文化改革の方が大変な作業となります。ただその大変な作業を乗り越えることにより、付加価値がついてきます。
すぐにAgile/DevOpsに取り掛かりたい場合は第三者のコンサルタントを交えた取組をおすすめします。
もちろん自分たちのペースでとりくみたいということであれば、助力を得られるコミュニティーやセミナーなどもあります。
さらに管理や自動化に関する有用なツールを知りたいということであれば、ぜひ一度弊社ツールをお試しください。
最後のページに問い合わせ先となるインタビューにご協力いただいた各社や参考になるリンクを紹介していますので、ぜひお役立てください。
一番自分にあわせた方法で、ぜひ「令和の新ビジネス形態」を完成させ、今後もビジネスに躍進するきっかけになれば幸いです
