O’Reilly Software Architectureカンファレンスの2日目はThe Home Depotでシニアアーキテクトを務めるChristopher Grant氏が‘Evolving toward microservices: How HomeDepot.com made the transition’と題して基調講演を行った。The Home Depotが顧客向けのウェブページを作ったのは1996年。それ以来、同社のウェブでのプレゼンスとソフトウェア資産は大きく育ってきた。新旧の技術とアプリケーションを統合するには時間がかかり、配置も難しくなった。アジャイルへ移行し責務の‘ドメイン空間’を定義して、継続的統合を実践して摩擦を劇的に減らした。2015年には、The Home Depotの技術チームは完全にクラウドとマイクロサービスを扱っている。これは、新しい設計上のチャレンジだ。
Grant氏は、大きなアーキテクチャ変更を成功させるための4つのアドバイスを披露した。ビジョンを持つこと。目的を理解すること。問題を選択すること。段階的に実装すること。さらに、次の指摘もしている。‘分解して境界を定義する’、つまり、ビジネスのプロダクトとドメイン(と関連するデータモデルと人的構造)を明確に定義し、責務とマッピングすること。‘変革のためのアーキテクト’、つまり、将来の変化を(可能な限り)予測し、反動するのではなく、予測して動くようにし、‘最終責任時点‘という考えを受け入れて、将来の開発を予測(ただし最小限に)する。‘安全に実装する’。つまり、早めに頻繁に自動化をして、適切なアップグレードとまっさらな状態からの作業を心がける。そして、最後にGrant氏がこの領域から学んだ教訓は、機能のスイッチとトラフィックのストットルを活用して問題を制限制御し、チーム間の独立性を保つことだ。中央集権的な制御に頼りすぎてはならない。
大きな設計上の変更をする場合はビジョンを持ち、目的を理解して、問題を選択し、段階的に実装するのが良いでしょう。
Cloud Foundry財団の技術担当バイスプレジデントであるChip Childers氏は、‘Going cloud native: It takes a platform’と題した基調講演で、‘クラウドネイティブ’なマイクロサービスアプリケーションを作るときに重要なのは‘プラットフォーム’を受け入れることだと指摘した。プラットフォームはソフトウェアの配置をシンプルにし、配置パターンと配置プロセスを提供し、セキュリティやロギングのような横断的な関心事を管理する。また、簡単にスケールできる。‘Twelve-Factor Application’の原則やマイクロサービス型のシステム、コンテナを使ったパッケージングはCloud Foundry、Heroku、OpenShiftのようなplatforms-as-a-service (PaaS)が提供するサービスに向いている。.
Childers氏はプラットフォームを活用することを推奨するのは“技術的な観点”からだけではない、という。経済的な観点も大きい。正しいプラットフォームを使うことで “手工業的なソフトウェア開発を産業化”できる。また、氏はプラットフォームを使って特定のオペレーション(配置など)を標準化することに関連して‘タクトタイム’についても説明した。タクトタイムはドイツ語のTaktzeitという単語から生まれている。Taktzeitは、“顧客の需要に合わせて生産を開始する場合の、ひとつの生産物の生産の開始と次の生産物の生産の開始の間の時間の平均”を表す。氏はプラットフォームはソフトウェアシステムに制約を課すが、“正しい制約は私たちを自由にし、クリエイティブにしてくれます”と言う。
New IronのCTOでOpen Masteryの創設者でもあるJanelle Klein氏は‘Let's make the pain visible’と題して最後の基調講演を行った。氏は‘Idea Flow’という学習フレームワークを概観した。このフレームワークは開発者の感じる摩擦を測定し問題を可視化するための戦略を提供する。Klein氏は典型的なソフトウェア開発のプロセスは組織全体で悪い反復パターンに陥る。“問題の違いから、苦痛を伴うリリース、最終的にはプロジェクトの崩壊”となる。用いる戦略を変える必要がある。ソフトウェア開発に伴う‘苦痛’を可視化する必要がある。しかし、大きな障害がふたつある。ひとつは、 the first is that the ‘マネジメント’は‘エンジニア’と異なる言葉を話すということ。そしてもうひとつは、開発者は多くの場合、違いが生まれない改善をしているということだ。
Klein氏曰く、ソフトウェア開発で苦痛と‘摩擦’を生み出すのは‘人間的な要素’であり、技術負債ではない。
ソフトウェア開発でもっとも難しいのは“解決するべき正しい問題を決めること”だ。しかし、多くの組織はこの難題に対して有効な戦略を持っていない。“良い戦略は具体的であり、進行の妨げに対して一貫した反応を示し、克服しようとする”というRichard P Rumelt氏の言葉を引用して、Klein氏は聴衆に、“高品質なコード、少ない技術負債、メンテナンスが簡単なコードと、しっかりしたコードカバレッジ”の摩擦や苦痛を特定し修正する今の戦略が最良かどうか質問した。そして、ソフトウェア開発の苦痛を視覚化するために“産業として共に学習しシェアしよう”と呼びかけて講演を締めくくった。この講演で示されたアイディアの詳細は“Idea Flow: How to measure the pain in software development”という本で確認できる。
Meta42 Labsの創業者でありチーフアーキテクトであるMark Bates氏は、‘Microservices in reverse’と題して講演を行い、Goで書いたマイクロサービスとAngular.js UIを使ったスタートアップ向けのウェブアプリケーションを最終的にRuby on Railsの一枚岩のアプリケーションですべて作り直した話をした。プロダクトとマーケットの適合を探っている会社を助けるソフトウェアを作っているチームに向けての氏のアドバイスは、可能な限りシンプルにする、ということだ。開発者のエゴがマイクロサービスのような‘最新の素晴らしい’技術やアーキテクチャスタイルを選択しようとするかもしれないが、副業的にそのスタートアップで働いていたBates氏にとっては、開発時の認知的な‘スコープ’を最小限にすることが最も価値があった。RoRベースの単一アプリケーションにすることで、可変部分や編成が必要な部分が最小限になった。
パートタイムでソフトウェア開発をしていたので、変更を加えるときの[認知的]スコープを最小限にしたかったのです。この場合、RoRで単一アプリケーションにするという選択はベストでした。
UK Government Digital Serviceで技術的アーキテクチャのディレクターを務めるJames Stewart氏は‘The architect as coach’と題した講演を行った。氏は'大規模IT'の時代は終わった、という主張から話を始め、今はアーキテクトも開発者も(ベンダよりも)大きな力を持っていると言う。公的分野でも民間でも技術は普及したので、“今やソフトウェアは政治になった”と氏は主張する。したがって、設計についての意思決定は幅広い影響を与える。組織の‘上級の技術的リーダー’になることにとってこれがどのようなことを意味するのか。Stewart氏によれば、リーダーの受けた訓練では手にあまる責任を引き受けるということであり、大きな図版を見ながら、組織が正しい方向に変わるようにする役割であるということだ。このポジションの大事なスキルは、組織のあらゆるレベルで問いを立てトップの支援なしでは、変化への意志は満たされないということを理解することだ。
プレゼンでは変化を駆動する7つのポイントが示された。
- 自分が影響を与える人々を理解する。
- インフルエンサーに影響を与える。上級のリーダーはほとんどが忙しいので、影響を与えるのは難しい。しかし、彼らはチームに支援されている。そのチームに影響を与えるのは比較的簡単だ。
- 早く価値を提供しその価値を理解する。素早いフィードバックを心がける。
- 共通の参照点や原則を見つける。
- 相手の言葉で話す。上級リーダーを理解する。彼らと同じ語彙で問題を表現する。
- 変化には時間がかかることを受け入れること。
- チームで動くこと。
ニューヨーク市で開催されたO’Reilly Software Architectureカンファレンスの詳細はウェブサイトで確認できる。さらに、今年の10月18日から21日にかけてロンドンで追加のイベントが開催される予定。11月13日から16日にはサンフランシスコでも開催される。共に、プロポーザルの提出ページが開設されている。
Rate this Article
- Editor Review
- Chief Editor Action