TOP ＞ Network ＞ リモート開発チームのためのベストプラクティス（下）
関連カテゴリー： Software
リモート開発チームのためのベストプラクティス（下）
2021/03/05
今回の記事では、リモートでのアプリケーション開発プロセスのベストプラクティスについて、新たに7項目を挙げておきたい。
（前回から続く）
テストとセキュリティのシフトレフト
アプリケーションの開発方法やデプロイ先を問わず、機能要件、性能基準、セキュリティ要件など、さまざまな要件を満たしているかどうかのテストは欠かせない。リモート開発チームは、エンドユーザー任せでユーザー受け入れテストを確実に実施することはできない。プラットフォーム、API、機能、パフォーマンス、セキュリティに関するテストを自動化する必要がある。CI/CDパイプラインを活用しているチームは、パイプラインで自動化テストの一部をトリガーする継続的テストを考えるとよい。
また、シフトレフトテストの戦略を取り入れることも急務となる。シフトレフトテストでは、テストの確立と自動化を開発プロセスの早い段階で行う。本番環境のコードに欠陥が紛れ込んだり、本番環境で発生したインシデントに対応したりといったことは、誰でも嫌なものだが、特に大勢がリモートワークで作業している状況では、修正にかかる負担や、それに付随するコストとストレスが、いっそう大きくなる。
リモート開発チームがそのほかに注目すべき部分としては、シフトレフトセキュリティと、新機能を導入する時の機能フラグの使用という2つがある。ここでのベストプラクティスは、デプロイの回数の増加よりも質の向上に照準を合わせることだ。重要なのは速さよりも品質の高さである。
低リスクの変更管理を自動化する
アプリケーションに低リスクの変更を加える時に、そのデプロイに関してCAB（変更諮問委員会）の長時間の会議が必要になるのは、リモート開発チームとしてはありがたくない。こうした会議は、必ずしも時間の上手な使い方ではないかもしれない。だが一方で、運用チームやセキュリティチームにとって、プロセスの手続きの厳密さは重要だ。本番環境でのインシデントの原因について、こうした変更承認までさかのぼって確認する場合も多い。また、SOC 2への準拠やそのほかの監査のために、変更承認のプロセスを必要とする企業も多い。
