著者：
楊 凌宇（ヤン・リンユ）氏（現在、中国電信研究所に勤務）
研究開発効果（DevOps）エンジニア認定学生
序文
今日のソフトウェア開発プロセスとツールはより成熟しており、アジャイルはすべてのソフトウェア製品チームの目標となっているようです。多くのチームがアジャイルであると主張していますが、実際には、より多くのチームがある程度アジャイルです。アジャイルを実践していく過程では、理想の状況とのギャップは必ず生じます。そこで考えなければならないのは、アジャイルを徹底的に実現することではなく、アジャイルの考え方をどう活かして現状を改善していくかということです。アジャイルは要件収集から製品設計、開発デリバリー、テストセキュリティ、運用保守保証と一連のプロセスに至るまで非常に広範囲をカバーしており、アジャイル思考を活用することができます。開発と納品のプロセスは実際に製品を構築するプロセスですが、開発の第一線の立場として、開発プロセスおよび開発チームのアジャイル変革をどのように実行するかについてもお話したいと思います。
アジャイル開発とは
アジャイル開発では、ユーザーのニーズを核として、大きな要件を分割し、反復的な開発手法を採用することで、ソフトウェアを常にリリース可能な状態に保ちます。アジャイル開発はチームワークと切り離せません。どのようなチーム形態であっても、誰もが「チームワーク」という言葉を強調しますが、アジャイル開発チームの重要な考え方は、実際には「チームワーク」であり、私たちはそれを「シナジー」と呼んでいます。
スクラム チームには、製品デザイナー、開発者、テスターなどがおり、全員が協力して製品の完全なライフサイクルを形成します。大きなチームには大きなチームの調整があり、小さなチームには小さなチームの調整があります。開発チームにとって、開発メンバーがアジリティに関して合意を形成し、連携して取り組むことができたとき、それによって形成される相乗効果は最大となり、チームはアジリティに向けて動き始めたとみなすことができます。その後、チームは適切なアジャイル開発ツールを共同で選択し、アジャイル開発のプロセスと規範を定義します。これにより、アジャイルのアイデアが真にアジャイルの実践に落とし込まれるようになり、チームのアジャイル変革を実現し、低コストかつ高効率で継続的に価値を提供できるようになります。
アジャイル開発チームの核となる考え方
2009 年の時点で、Flickr はスピーチの中で「1 つの中心、2 つの基本点」という非常に重要な概念を提唱しました。基本的な 2 つのポイントのうち、1 つはコラボレーションにこだわること、もう 1 つは自動化にこだわることですが、この 2 つの概念はアジャイル開発にも当てはまります。コラボレーションは生産性の向上、オートメーションは生産効率の向上を目的としており、低コストかつ効率的に価値を提供し続けることが目標です。そして、開発チームがアジャイルに変革する際には、コラボレーションの改善と自動化の改善という 2 つの点に焦点を当てる必要があります。
コラボレーションの向上
コラボレーションを向上させるには、チームメンバーが相乗効果のあるコンセプトを形成し、相乗効果のある合意に達する必要があります。従来のDevOps（開発・運用・保守の統合）では、開発と運用・保守の各段階が連携し、開発者と運用・保守担当者の連携が重視されていました。開発チーム内では、さまざまな開発メンバー間の協力が必要です。チームにコラボレーションを直接浸透させるという考えを変えることは困難ですが、チームの共同行動を促進するために次のような実践的な措置を講じることができます。
1. より多くのコミュニケーションと交流。多くの企業では、開発チームは比較的独立した会議室で一緒に座ったり、輪になって作業したりすることが多く、これがベスト プラクティスです。多くの人々の従来の印象では、開発者は口数が少なく、自分の世界で黙って開発に集中することを好み、他の人とコミュニケーションを取ることに消極的であり、これがアジャイルを妨げる重要な理由である可能性があります。アジャイルは個性と相互作用を重視しており、全員が一緒に座って開発を行い、対面でコミュニケーションをとることができれば、多くの問題を迅速に解決できます。たとえば、現在の開発要件は理解されていますか? 現在の開発で発生したバグを解決するにはどうすればよいですか? 現在の関数には、再利用できる関連実装がありますか? 目の前のタスクを完了した後、他のメンバーを助けることができますか? 全員がそうする意欲があれば、チームの価値を最大限に発揮し、バレル効果による欠点を埋めることができ、開発者全員が全体としてコードを提供し、全員の知識と能力も共有され、改善されます。5回のスクラムミーティングにおける毎日のスタンドアップミーティングも、コミュニケーションを強化し、情報を収集し、質問し、助けを求めることを目的としており、本質的な考え方は同じです。コミュニケーションやコミュニケーションが不足しているチームは、待つ無駄、情報を見つける無駄、引き継ぎの無駄、特に人材の無駄（人材の価値が十分に発揮され、発揮されていない）など、大きな無駄を引き起こし、チームの効率に大きな影響を与えます。
2. もっと助けて、不平不満は減らしましょう。開発チームのメンバーの技術レベルにはどうしてもばらつきがあるため、先輩として後輩を責めたり文句を言ったりするのではなく、あらゆる面で助け、サポートすることが大切です。チーム内に相互扶助の前向きな雰囲気が醸成されて初めて、チームはより早く進歩し、成長し、効率の向上がもたらされます。
3. 適切に動作するソフトウェアを選択し、適切な仕様を策定するために一緒に議論します。開発チームの各メンバーは、独自の優れたソフトウェアや過去の経験で馴染みのある仕様を持っている可能性があります。しかし、新しいチームでは、チーム全体のコラボレーションのために、メンバーが自分の好みを捨てて、IDE、コーディング仕様、Git 提出仕様、CICD ツール、リリースプロセス仕様などを含むチーム全体に最適なソフトウェアと仕様を一緒に話し合う必要があります。一貫して動作するソフトウェアと規範により、チームのコラボレーションを強化します。
4. 状況に応じて柔軟に計画を調整します。アジャイル宣言には、「計画に従うことよりも、変化に対応することの方が優先される」という一文があります。開発チームにおいては、100%計画通りに開発することは不可能であり、開発者それぞれに独自の技術部分や苦手な技術部分があり、それが開発効率の変化につながります。開発タスクが 100% 計画通りにスケジュールされていると、必然的に忙しさに偏りが生じます。そして、最初に計画を完璧にしたい場合、それはさらに非現実的であり、そのために多大なエネルギーを支払わなければなりません。したがって、より良い状況は、開発者が PBL の予備的なタスク スケジュールを作成した後、実際の開発、つまり「開始を停止し、終了を開始」できることです。実際の開発プロセスでは、課題の難易度や状況に応じて柔軟に対応し、チームメンバー同士でコミュニケーションを図り、助け合うことで、チームの開発効率を最大化します。
したがって、コラボレーションを実践することは難しいことではなく、チームメンバーがコラボレーションについて合意を形成し、個人よりもチームを優先し、苦楽を分かち合う価値観と使命感を持てるかどうかが鍵となります。
自動化の改善
コラボレーションが考え方の変化であるとすれば、自動化は行動の変化です。一般に、ソフトウェア開発プロセスは、製品デリバリー サイクル全体の中で最も長いプロセスでもあるため、どの自動化ツールや手段を使用してこれを支援できるか、また自動化のレベルをどのように向上させるかが特に重要です。これは、100 日に 1 つのバージョンを配信することから、1 日に 100 のバージョンを配信するという質的な飛躍です。
実際、ソフトウェア自動化の開発には、非常に長い時間と技術的な蓄積が必要でした。以前は、開発者がローカルでコードを作成した後、手動でコードをコンパイルしてビルドし、ソフトウェア製品にパッケージ化し、スクリプトまたはコマンドを使用してテスト サーバーにデプロイする必要がありました。サーバー環境の問題により、デプロイメント プロセス中にさまざまな例外が発生することがありました。すべての大変な作業と導入の成功後、それは専門的なテストのためにテスターに引き渡されます。期間中、テスターは問題をテストし、開発者は問題を修正した後に上記のプロセスを繰り返す必要があり、時間と労力がかかりましたが、最終的には、開発者が実際にコードを書くのに費やした時間はほんの一部であり、反復的で退屈な作業に多くの時間が費やされていたことが判明しました。その後、Jenkins ツールの登場により、継続的インテグレーション (CI) と継続的デプロイメント (CD) の両方が自動化されました。開発者は Jenkins で構成した後、コードを作成して送信するだけで済み、残りの手順は Jenkins が支援します。デプロイメント環境では、開発者が自分のコンピュータでプログラムを作成し、デバッグして実行し、サーバーに公開する必要があるため、環境の不一致によって引き起こされる問題は常に頭の痛い問題でしたが、その後、デプロイメントおよびメンテナンス レベルでの統合および自動管理の問題を解決するために、Docker や K8S などのテクノロジが登場しました。これらの自動化ツールや技術を組み合わせることで、開発者はコードの処理だけに集中すれば、その後の処理を自動で実行できるようになります。
上記の自動化テクノロジーは統合および展開レベルに重点を置いていますが、実際にはソフトウェアの自動化はそれだけではなく、開発レベルの自動化テクノロジーも実際には多数あります。B/S アーキテクチャの台頭後、より多くの開発者が Web 開発を行うようになりましたが、反復的でビジネスとは何の関係もない、基礎となる Web コードを多数記述する必要がある場合があるため、それ以来、Java の Spring フレームワークや C# の ASP.Net フレームワークなど、多くの Web フレームワークが登場しました。これらのフレームワークは Web の基礎となるテクノロジーをカプセル化しており、いくつかの単純な構成を通じて、多くの基礎となるロジックを自動的に実装できます。さらに、現在の IDE はますます高度かつインテリジェントになっており、多くのプラグインを通じて、開発プロセス中に自動的にコードを生成し、コードをチェックし、エラーを修正できます。
したがって、これらの自動化テクノロジー、ツール、およびフレームワークの出現により、開発者はビジネスの実装により集中できるようになり、さまざまな複雑で退屈なタスクが軽減され、価値提供の効率が向上します。そして、ビッグデータと AI テクノロジーの成熟に伴い、人々はもはや自動化に満足せず、より高いレベルのインテリジェンスを目指すようになるでしょう。開発者にとって、一部の非コア機能のコードを AI に引き渡して実装できれば、生産効率がさらに飛躍することは間違いありません。
コラボレーションと自動化の組み合わせ
コラボレーションと自動化はアジャイル開発チーム変革の 2 つの重要なポイントであり、どちらか 1 つに集中するのではなく、それらを有機的に統合する必要があります。
私もかつてプロジェクトを経験したことがありますが、プロジェクトチームはスクラム方式で編成されていましたが、毎日スタンドアップミーティングを開催して情報収集や作業進捗の同期を行っていましたし、開発プロセスではさまざまなCICD自動化ツールも活用していましたが、全体的な研究開発効率は依然として向上しておらず、連携と自動化がうまく融合していませんでした。全員が自分に与えられたタスクとにらめっこしており、困難に遭遇しても積極的にコミュニケーションをとらず、自分たちだけで解決しようとするため、チーム全体の進捗が遅れてしまいます。コード提出時にレビューの仕組みがない、コード提出が遅れた人は面倒な競合を解決しなければならないため、皆が先に自分のコードをアップロードしたがる、機能モジュールの責任者が問題を解決する、相互協力する雰囲気がない。一見、ルールや規制がある形のように見えますが、実はアジャイルの考え方からは逸脱しています。
したがって、アジャイルの概念に基づいて開発を行う場合、一方では全員が自動化ツールを使用することになりますが、さらに重要なことに、共同開発には全員が自動化ツールを使用することになります。
アジャイル開発の展望
アジャイル開発の進化は終点のないプロセスであり、常に 1 つの目標、つまり人々の価値の最大化に向かって進みます。チームのコラボレーションであれ、さまざまな自動化ツールの支援であれ、基本的に人の価値は常に増大しています。開発チームが徐々にアジャイルに移行すると、おそらく毎日生成されるコードは減少しますが、毎日生成される価値は確実に増加します。