令和の開発
by Chihiro Umemoto, on 2021/06/11 4:48:25
2020年は、とくに IT の活用失敗に関するニュースが目立ちました。例えば、マイナンバーは申請だけオンラインで、給付と管理は手作業だったり、使ったこともない仮想口座サービスに気づかぬうちに自分の通帳を紐付けられ、不正に出金されるなどを散見します。そしてそこからの対応がとても遅く、その団体の信頼がどんどん失われていきます。
これらの問題は、テクノロジーの問題ではありません。組織、文化、経営、つまりビジネスの問題です。
テクノロジーを真に活用し、新しい時代を生き残るための必要なものは、新しい技術ではなく、新しい技術を活用できる、新しい「令和のビジネス形態」です。そして、その令和のビジネス形態として、高い品質、素早い対応、少ない機会損失、社内外の信頼を高める、「Agile/DevOps」を解説していきたいと思います。
では、それを達成するにはどうしたらいいでしょうか?
実際に自分自身でAgile/DevOpsを調べ初めた際は、開発にツールを使った自動化のところ部分のみが目に入ってきていました。そこから更にAgile/DevOpsに関わってきた数社にインタビューをさせていただき、自動化する前に重要な部分があることが見えてきました。今回は自動化の部分よりもそれ以外の重要な部分を探っていきたいと思います。
Agile/DevOps
実際には理解されていない事が多い、インタビューの中に以下のような話しがありました。
インタビューさせていただいた各社からみえてきたのが、DevOpsという言葉は日本ではあまり認知されていないようです。どちらかというとAgileの方が日本では知られているようでした。実際にDevOpsとAgileはかぶっている部分かなりあり、明確に使い分けられているわけではありません。更にそこにいろいろと関連する言葉として、DX、Scrum、シフトレフト、CI/CD、パイプラインなど、いろいろ言葉がでてきて大変混乱しました。これらの言葉は概念的なところは似通っているものや、範囲が違ったり、実際の手法だったりと理解するまでかなり苦労しました。
DevOpsのもともとの話しは、2009年にFlickr社の「10 deploys per day」から始まっています。提供しているサービスのデプロイ(更新)を1日に10回もできているという、当時ではかなりの衝撃の話しでした。詳細は割愛しますがツールと社内文化を変えることにより、Dev(開発部門)Ops(運用部門)が協力して混乱なくサービスを1日10回も更新することが可能になったという話しです。
この話しを読むとツールだけを導入するのではなく、社内文化もあわせて改革していくことが必要であることがわかります。
目的を間違いがち
本来の目的は「効率化によるコスト削減」ではなく、「自動化をもちいて開発(改善)のスピードをあげ、高品質なサービスの提供を可能とし、ビジネスの機会損失の削減」になります。
従業員が日々の繰り返し作業、確認作業などから開放された分、いかに新しい企画、もしくは顧客からのフィードバックをもとに既存サービスの改善、別部署のアシストなど、あいた時間をいかに有益に使えるかがポイントです。
Agile/DevOpsおさえておきたいポイント
コミュニケーション(=文化)を変える

イネド 「DevとOpsがコミュニケーションとるためにどんな支援しますか?」

インタビューから見えてきたのは意外にもFace to Faceの対話不足でした。こんな基本的なことと思われがちですが、チャットツール類の発達で便利になりましたが、Face to Faceのコミュニケーションに勝るものはないようです。確かに顔をみて話すことにより、テキストだけでは読み取れない情報がたくさんあります。
関連する部署を含めたプロジェクトチームの構築

現在は代表者がミーティングに参加し、自分の部署内でミーティングの内容をシェアして仕事をこなしているところが多いと思いますが、それだと仕事の依頼だけが伝わり、何を目的としているのか、他部署、社内の状況などの情報が見えません。見えないほうがいいという声も聞こえそうですが、毎日依頼されたことだけを行っているのでは新しい発見もなくなり、仕事へのモチベーションを維持することが難しいでしょう。
チームを組む趣旨としては、全員が情報を共有し、部署や役職の垣根なくサポートし合うのがチームを組む目的になります。
実際に上記の内容を体験することが可能な研修があります。株式会社ITプレナーズジャパン・アジアパシフィックが行っているフェニックスプロジェクトです。書籍「The Phoenix Project」(邦題「The DevOps 逆転だ!」)を基にした、丸一日使ったゲームスタイルのワークショップ型研修です。座学はほとんどありません。
言葉や資料で説明されるよりも、体験することにより短時間で関係者全員でミーティング、コミュニケーションのとり方、情報の共有などの有用性を深く理解でき、とても楽しいものでした。Agile/DevOpsの重要性を経営陣、管理職、チームメンバーに体験してもらう方が手っ取り早いと思います。
実際に取り入れたい手法
ミーティング(コミュニケーション)の進め方
さて上記で何がポイントかが見えてきたかと思いますが、今まで通りミーティングルームに集まって、進行役がほとんど喋って終わる形では全員参加でのよい成果はでません。
かかわっているメンバー全員で、目的を共有し、自由に発言できる環境を作ります。そこからプロジェクト作成、実行、定期的な見直しを繰り返しながらプロジェクトを進めます。インタビューより見えてきた、それを可能にしてくれる一つが以下の方法です。細かい手法は今回は省きますが、ぜひ試していただきたいです。

Scrumの概略としては、チームでプロジェクトを進めていくうちに出てくるあらゆる問題点を、短期的なサイクルでチーム全員が問題点を共有し、改善案をどんどんだします。問題点の共有は、担当する人や部署を非難するのではなく、改善案を全員で提案する事が目的とする手法です。
属人化が削減

よく聞く「その事はあの人にしかわからない」などをなくすことが結果的にできます。
同じチーム内もしくは他部署の人でも複数人で取組むことにより、担当者1人に頼ることなどを減らすことが可能になります。
現在の状況を可視化
これはどんなことにも言えることですが、正しく問題点を把握していなければ、どんなに対策を打っても効果は薄いですよね。インタビュー内で出てくる「Value Stream Mapping」を全員参加で、現状の可視化をします。そこから問題点を洗い出し、改善するためのタスク作成をして、プロセスを検証していきます。
最後に自動化
ここでやっとプロセスを自動化していきます。ここで始めてツール類の投入です。できるだけ毎回発生する繰り返し(反復)作業、人間が苦手(時間のかかる)な確認作業を自動化していきます。そしてそのプロセスを検証し、問題があるときには全員で案を出して修正していきます。
これによりツールで安定したリリース品質を保ちながら、迅速に素早く新しいサービスもしくは改善したサービスをデプロイする環境を整えていきます。
すでにコミュニケーション方法、問題の洗い出しなど完了されていて、ツール類を探しているという方は、最後のリファレンスページにある弊社ツール類を試していただければと思います。
更に有益なプラス効果
上記手法を利用することにより、さらにチーム、もしくは社内によい効果が現れます。

手法はいろいろな方法があるとは思いますが、インタビューの中で共通して出てきた言葉として、「仕事のやりがい」や「仕事を楽しく」という言葉です。Agile/DevOpsを通して結果的にやりがいや楽しさが出てくるのであれば、経営者、従業員ともによいことですよね。
ベイビーステップ
さてここまで読んでいただいた方はもうおわかりだと思いますが、Agile/DevOpsは自動化の部分よりも、文化改革の方が大変な作業となります。ただその大変な作業を乗り越えることにより、付加価値がついてきます。
すぐにAgile/DevOpsに取り掛かりたい場合は第三者のコンサルタントを交えた取組をおすすめします。
もちろん自分たちのペースでとりくみたいということであれば、助力を得られるコミュニティーやセミナーなどもあります。
さらに管理や自動化に関する有用なツールを知りたいということであれば、ぜひ一度弊社ツールをお試しください。
最後のページに問い合わせ先となるインタビューにご協力いただいた各社や参考になるリンクを紹介していますので、ぜひお役立てください。
一番自分にあわせた方法で、ぜひ「令和の新ビジネス形態」を完成させ、今後もビジネスに躍進するきっかけになれば幸いです