とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど

開催予定の勉強会

読者登録と各種SNSのフォローもよろしくお願いいたします。

DevOpsとリモートワークの関係

このBlogは基本的に技術情報を主なコンテンツとしていますが、ときどきDevOpsに関するコラムも書いていきたいと思います。

エンジニアはリモートワークを好むのか

リモートワークが当たり前のようになっていますが、エンジニアの皆さんは特にリモートワークしやすい職種ということで、リモートワークをさせれている方も多いのではないでしょうか?

実際、いろんなエンジニアの求人を見ても「リモート可」や「フルリモート可」というのを前面に押し出している求人も多いです。エンジニアの人材不足と言われて長いですが、給与面に加えて、そういった仕事環境もエンジニアの求めるところに応じていかないと採用もなかなか難しいものがあります。(かく言う弊社もフルリモート可でDevOpsエンジニアを募集していますが)

こちらは2022年3月のレバレジーズさんのニュースリリースからのデータですが、「社会人エンジニアが今後どのくらいの頻度でリモートワークをしたいのか」という調査で、なんと46.0%ものエンジニアがフルリモートで仕事をしたいといっています。

出典:エンジニアの約半数が、今後の働き方でフルリモート勤務を希望(レバレジーズ ニュースリリース)

さらに、週3日以上のリモートワークを希望するエンジニアは約60%、週1日以上となると80%を超えています。エンジニアにとっては、やはりリモートワークは魅力のようです。

 

リモートワークにおけるソフトウェア開発

では、会社にとってはどうでしょうか?いくらエンジニアがリモートワークを好み、それによって採用が進むとしても、成果が出ないようであれば意味がありません。

その点について、マッキンゼー&カンパニーが2020年2月の「A new management science for technology delivery」というレポートで、このようなデータを出しています。厳密に言えば、このデータはリモートワークかどうかと言うよりは、分散拠点も含めた中長期的な効果を図るようなデータなので、その点は差し引いてみてください。

出典:A new management science for technology delivery(マッキンゼー&カンパニー)

開発プロジェクトにおいて、同じロケーションで働く人の割合が多ければ多いほど、発生した課題の中でのバグの割合が少なく、スケジュールは遅延しやすくなるそうです。つまり、リアルに一緒に働く人の割合に質は比例し、スピードは反比例します。

推測ですが、質に関してはこのように考えられます。同じ場所にいればコミュニケーションも容易になり、その結果相談などもしやすくなり質は向上しやすくなるのでしょう。加えて、開発環境などの統一も容易になることも、質が向上している理由の一つと言えます。

また、質に関してもこのように考えられます。なにより、リモート環境では邪魔が入る確率が低くなるのと、働きやすい環境が用意できるという点で、集中力を保ちやすくなります。また、リモートの場合は時間管理よりもアウトプットがあったかどうかを管理として見られることが多いと思うので、結果を出すスピードが上がるのではないでしょうか。

 

DevOpsはエンジニアのリモートワークを救う

といってしまうと、何かマーケティング的な言い回しのように聞こえますが、あながち間違いではない話です。実際、エンジニアはリモートワークをしたい、会社は品質を上げたい、というという二つの要求を同時に満たせば良いのです。そのためにDevOpsはどのような効果を出せるのでしょうか?

DevOpsを導入したからといってバグが発生しなくなる訳ではありません。先ほどのマッキンゼー&カンパニーのレポートでは、全課題(All issues)の中のバグの割合を測っています。DevOpsを適用したからといって、この数字自体はあまり減らないと思います。しかし、DevOpsの特徴といえば、問題を早期発見し、早期対応ができるということです。マッキンゼー&カンパニーのレポートにも書かれている通り、早くバグを見つけて、早く対処すればそのコストは小さくて済みます。

出典:A new management science for technology delivery(マッキンゼー&カンパニー)

また、リモートワークでバグが発生しやすい理由のもう一つが、開発環境です。リモートワークにおいて、開発環境をプロジェクトで揃えるのは、同一拠点で開発するよりも簡単ではありません。その点、DevOpsではCI/CDが実行される環境は統一され、テストの自動化やデプロイの自動化が実施されているため、一度コードをコミットしてしまえば、誰の書いたコードも同じ環境でテストされ、実行されます。それにより、環境による挙動の違いを最小限に抑えることができます。

このような形で質の問題を解決しながら、リモートワークのスピード感を出していくというのも一つのやり方ではないでしょうか?

 

とはいえ、課題もまだ残る

DevOpsも万能ではありません。そもそも、DevOpsという単語自体が概念で、はっきりしないという点はここでは、一旦置いておきます。

その上でDevOpsを導入したとしても、リモートワークでの問題点は色々とあります。得に大きな問題はDevOpsと対で語られることの多いアジャイルの実践です。もちろん、リモートでもアジャイルでの開発は十分できます。しかし、アジャイルはDevOps以上にメンタリティに踏み込む必要があるため、リモートでそのメンタリティの構築はリアルよりも難易度が高くなってしまいます。

また、人と人とのつながりが希薄になってしまう点も避けては通れません。Slackなどを使ってコミュニケーションを取るとしても、リアルに会話するような気軽さはありません。

そのような点に関してはまた別の解決方法を模索していく必要があるかと思います。