UKのコーンウォールで開催されたAgile on the Beach 2017において、数百人の発表者と参加者が集い、アジャイル、そしてポストアジャイル領域のソフトウェア開発方法論に関する最新状況を議論した。2日目の主な内容は以下を含む。ソフトウェア開発の方法論に関する技術的卓越を磨くことは、アジャイルマニフェストの約束に基づいてデリバリーを行うのに必要不可欠である。継続的デリバリーは事業価値の流れを最大化するための主要なエネーブラーであるが、効果的かつ持続的に運用するためには組織が適切に設計されなければならない。そしてマイクロサービスアーキテクチャを用いて設計され、コンテナ技術によりデプロイメントされるソフトウェアシステムにセキュリティを実装するのは挑戦的な試みであるが、全ての開発者とオペレーターが使用する基礎的なプラクティスが存在する。
カンファレンスの2日目はJames W Grenning氏は"技術的卓越、それがあなたに必要なものだ"と題した基調講演から始まった。Renaissance Software Consultingのファウンダーであり、Agile Manifestoの署名者でもあるGrenning氏は80年代に組込みシステムのコードをどうやって書いていたかについて論じることから発表を始め、継続的改善の短いサイクルの中で機能性デリバリーすることはその時から今日と同様必要不可欠であったと述べた。考察やDemming氏の"Plan, Do, Check, Act (PDCA)"サイクルと"総合的品質管理(TQM)"のプラクティスの引用を共有し、これらの技法の根底を流れる多くの原則がオリジナルのアジャイルマニフェストに表現される概念の背後に存在した、とGrenning氏は述べた。しかし、これらの年月の間に技術的卓越と継続的学習は災難なことに先細りとなってしまい、このことがソフトウェアを構築するために適切なプロセスだけに焦点を当てる独善的な議論を導いてしまったとした。
Grenning氏は、アジャイルコミュニティが"第一に技術的卓越を要求し、第2に個々の変化を促進して組織の変化をリードする"べきであると確信していることを述べた。Erik Dietrich氏の示唆に富んだブログ記事である"開発者はどう学びを止めるか: エキスパートビギナーの台頭"に従い、私たちは継続的に学び、技術的なプラクティスを改善して"10年の経験を持ってはいるが、実際は単年ごとの経験を10回繰り返した開発者"となる罠を避けなければならない。例えば、開発者は"デバッグを後でする"開発を避け、その代わりにテスト駆動開発(TDD)のスキルを実践し、改善することに関心を向けるべきである。Grenning氏は、人々を尊敬すること(これはこのカンファレンスの第1日目に繰り返し触れられたことである)を養う重要性について議論し、アジャイルの方法論がデリバリー管理に関する多くの価値が付け加えられてはいるが、技術的卓越を忘れるべきでないことを強調してこの基調講演を終えた。
ビジネストラックにおけるこの日の最初のセッションは、Equal ExpertsのパートナーであるPhil Parker氏が発表した"継続的デリバリーのための組織づくり"であった。この発表は、継続的デリバリーは"準備ができた機能が実際の顧客の眼前に少しの説明でパニックなく提供でき"、"速度と安定性が事業的要求を満たしている"場合に組織の中でうまく実現できる、と述べるところから始まった。継続的デリバリーの主要なゴールは、価値を生む可能性のあるアイデア(仮説)の断片が生まれたときから、その価値が製品に配置されて本当の顧客に見えるようになるまでの待ち時間を最小にすることである。従って、継続的デリバリーを実現するためには組織全体が協調する必要がある。Parker氏は稼働率とフローを議論し、稼働率に焦点を当てる組織は"削減されたフローと貧弱な(効率的な)稼働率を重視する傾向"があり、そうではなくフローによる稼働率の改善に関心を寄せるべきであるとした。これを達成する1つの方法は小さいバッチサイズで開発を行うことである。
講演のメインテーマに移動して、Parker氏は伝統的なチームが焦点を当てる"サービスチーム"がフローを最大化する観点では非効率的であり、これは端から端まで(例えば事業アイデアからデプロイメントのアーキテクチャまで)変化を起こす能力に欠けるためであり、結果的にしばしばバッチサイズの増大や各デリバリーに含まれる機能を増やすためのサイクルタイムの増大、すなわちおぞましい"ビックバン"リリースを引き起こすと述べた。Spotifyの組織モデルである選抜チーム、分科会そしてギルドを借用して、Parker氏は組織設計内の伝統的なサービスチームを代替するための3本柱の組織設計を提示した。これは以下の内容のグループから構成される。
- ドメイン(垂直方向): 単一のグループにより所有・制御される事業的能力の領域であり、他のドメインチームと独立して機能性を配置可能であるべきである
- コミュニティ(水平方向): 同じようなスキルや興味を持った人々による緩く形成されたグループであり、組織を横断して協働し知見を共有することができる
- エネーブラー(対角方向): 必要とされるプラットフォームやコアのツール群といった、共有される関心毎を構築することに責任を持ったチーム
発表の締めくくりとして、Parker氏は組織に関して以下のように述べた。コンウェイの法則の影響を意識し、再利用が良いことではある一方で依存関係のコストが存在することを意識するべきである。ドメインチームとシステムの境界は明確で比較的安定し、細粒度すぎないことが必要である。
明確な境界を持ち、単一の事業的機能に責任を持つドメインチームの形成の成功は開発者とって驚きではない。これは高い凝集性と疎結合というアーキテクチャ上の単純な原則であるからである。
ソフトウェアデリバリートラック内の次の発表はPhil Winder氏によって行われた。彼は開発と運用にマイクロサービスアーキテクチャとコンテナ技術を用いた場合のソフトウェア開発におけるセキュリティの役割を調査した。マイクロサービスとコンテナのオープンソースによる参照実装で運用される通販サイトの"Sock Shop"を用いて、一連のセキュリティの概念が議論・推奨された。
- コンテナのセキュリティ:
- rootとしてプロセスを実行するのを防ぐためにDockerfile内にUserを設定すること。
- 硬化イメージ(Center for Internet Securityのウェブサイトを参照)を活用し、コンテナをイミュータブルな成果物として配置し、ルートコンテナのファイルシステムは読み取り専用として構成すること。
- 妥協するのであれば、Linuxのケーパビリティを活用してコンテナが行うことができる操作を制限すること。
- 有名なコンテナのオーケストレーションフレームワークであるKubernetesには、セキュリティ機能を有効にする方法に関する素晴らしいドキュメントがある。
- ネットワーク
- "多層防御"を行い、グローバルなファイアウォールを活用することで攻撃対象領域を最小化すること。
- インターネットアクセスを防ぐためにネットワーク分割を行うこと。
- コンテナが定義された他のコンテナとだけ通信することを保証するために、ネットワークポリシーを設定すること。
Winder氏はセキュリティは正確かつ効果的に実行するのが難しい場合があると述べて講演を締めくくった。アーキテクト・開発者・オペレーターを横断した責任の広がりが増していることに起因して、組織内の誰もが基本的なセキュリティ原則(特にコンテナのような新しい技術に関して)の知識を養い、各メンバーの作業内容が全体システムへ及ぼすセキュリティ上の影響を意識するようにならなければならない。
the Agile on the Beachカンファレンスに関する追加情報はカンファレンスのウェブサイトから確認することができ、発表の動画はここ数週間でAotBのYouTubeチャンネルにアップロードされる。
Rate this Article
- Editor Review
- Chief Editor Action