Woven Cityとはいったい何なのか
ハンター・チェン氏（以下、チェン）：エンジニアリングミートアップへようこそ。まずは、Woven City（ウーブン・シティ）について簡単に紹介します。Woven Cityとはいったい何なのか、私たちが具体的に何をしているのか、街の中で何が起こっているのかを知りたい人は多いのではないでしょうか。
私たちの目的は、「幸せの量産」です。これは、この街に住む人たちだけでなく、すべての人、全人類に当てはまります。私たちはこの街で、世界中のお客さまに役立つ製品をテストし、それを社会に還元していきます。
その実現のために私たちが掲げるビジョンは、「モビリティの拡張」です。モビリティは、“Move”（動く）という言葉にフォーカスしています。Moveと聞くと、物理的に動くことを連想しますが、“Move”は人の気持ちにも当てはまると考えています。
街を見た時、街に足を踏み入れた時、街を歩いた時、（心が動いて）感動する。私たちは幸せの量産を目指し、社会を巻き込むことを重視し、それを世界中のすべての人に適用していきます。私たちのミッションは、「テストコースの街で、未来の当たり前を発明する」ことです。
一日中、大きな言葉を並べて夢を語り続けられますが、もっと具体的なことが知りたいという人もいるでしょう。私が街について話し出すと、皆さんから「具体的に何をしているの？」「具体的な数字は？」などと聞かれます。それにお答えします。
街の第1フェーズですが、敷地面積は約5万㎡で、2022年から建築を開始します。ですから裾野で車を走らせると、まさに街が建設されていく様子を見ることができます。Woven Cityの開所は、2024年から2025年頃を予定しています。
第1フェーズの居住者数は約360人ですが、将来的には2,000人以上が住む予定です。居住者は、子育て世帯からシニア、インベンターなど多様です。私たちは多様性を重視しており、生活のさまざまな側面に目を向けながら、多様性を開発する製品やサービスにも生かしていきます。
実証される12のコアサービスには、モビリティ、エネルギー、物流、教育、ヘルスケアなど、あらゆるものが対象です。テクノロジーが応用できそうな分野は幅広く実証して、Woven Cityらしいライフスタイルを実現していきます。今日のテックトークでは、かなり大まかですがもう少し具体的にお話できるはずです。
既成概念にとらわれないシステムアーキテクチャ設計
スティーブン・シャム氏（以下、シャム）：今日は、システムアーキテクチャ設計にまつわる、私の体験をお話しします。私について軽く自己紹介すると、現在はライフスタイル・サービス・プロダクト・チームのテックリードとして、Woven Cityの開発に取り組んでいます。その前は、オーストラリアと香港で、複数の業界で働いていました。20年近く前に、Javaエンジニアとしてキャリアをスタートし、今はシステム設計アーキテクチャーに重点を置いています。
では、まずはウォームアップに挑戦してみましょう。簡単なので心配しないでください。プロブレムステートメント（課題ステートメント）は、“街中のデバイスが互いに会話できるようなシステムをつくりたい”です。デバイスには、公共用と家庭用の両方のデバイスが含まれます。一番重視すべきステートメントはIT戦略で、それは「クラウドファースト」です。つまり、すべてクラウドでデプロイするべきだということです。
問題は「どこにシステムをホスティングするか」です。「A.パブリッククラウドプロバイダー」と「B.ローカルデータセンター」どちらも良いデータセンターであると考えてください。Aを選んだ人は挙手してください。残りの人はBを選択したということだと思います。
私たちは、新たな選択肢としてC.パブリッククラウドとローカルデータセンターのハイブリッドというアプローチもありうると考えています。
なぜ、人は選択肢A or Bを選ぶのでしょうか。会社の戦略は、すべてをクラウドに乗せることですから、「クラウドに乗せてさえしまえば仕事は終わり」ということでしょうか。でも、ちょっと待ってください。非機能要件については考えましたか？ アプリケーションのレイテンシーは考慮しましたか？ 高可用性や災害復旧はどうですか？ こういったものを考慮していないのなら、クラウドにデプロイする（A）という選択肢に至るでしょう。
80/20の法則については皆さんご存知かと思います。すべての問題を解決できる万能薬は存在しません。優れたエンジニアとして、私たちは求められている以上のことを考えるべきです。会社の戦略で、問題の80パーセントが解決できたとして、残りの20パーセントにはどう向き合いますか？ここでは、既成概念にとらわれない発想が必要です。自ら選択肢を限定してはいけません。
Woven Cityに戻りましょう。私たちはまったく新しい街づくりに取り組んでいますから、多くの課題に直面し、日々決断を下す必要があります。
具体的なアーキテクチャの課題
ここで、具体的なアーキテクチャの課題をいくつか紹介しましょう。街はたくさんの情報で溢れています。どうすれば適切な情報を適切な人に、適切なタイミングで共有できるでしょうか。ユーザーのプライバシーとデータ利用のバランスをどう取るか。多くの人が多くのアプリケーションを使う状況で、認証と認可はどう行いますか。
これが、Woven Cityなのです。新しい要件に対応する柔軟性はありますか？ 膨大なトラフィックを処理するためのスケーラビリティはどうでしょうか？ 他の場所にもサービスを展開できますか？ 日々課題に直面する中、既成概念にとらわれず、それらの課題をひとつひとつ解決していく必要があります。
まとめてみましょう。どのようなシステムであっても、アーキテクチャを検討する際には、次のことを十分に理解した上で行うことにしています。
まず、何をするにしても、ビジネス目標を満たすこと、あるいはそれを超えること。機能要件と非機能要件を満たすのはごく当たり前ですね。何事にも制約があり、限界がありますから、それらも検討します。
最後になりますが、フリーランチ（タダ飯）というものはありません。すべてのものにはトレードオフがあります。特にお金と時間などのトレードオフを理解することは、非常に重要です。
同じ問題を解決する方法はいくらでもあると思います。IT戦略がうまくいかない場合は、枠にとらわれずに考えてみてください。クラウドソリューションは万能薬ではありません。すべての問題を解決できないかもしれない。時には、特殊な要件に対応するために、ミックスアンドマッチ（組み合わせる）のアプローチを行うこともあります。
あなたの万能薬はどこにあるのか。そう、あなたこそがあなたの課題の万能薬なのです。ご清聴ありがとうございました。
アーキテクチャ上の最優先の検討事項
チェン：シャムさん、ありがとうございました。では、皆さんが質問を考えている間に、私からいくつか質問させてください。これらのアーキテクチャ上の検討事項のうち、優先順位付けはどのように行っていますか？
シャム：今お話ししたように、私たちはビジネス上の課題の解決を目指しています。ですから、一番重要なのは「ビジネスゴール」だと思っています。何をするにしても、ビジネスゴールを最優先すべきです。技術的なこと、また非機能要件や機能要件も吟味しますが、最終的にはビジネスゴールに貢献すること。それが一番大切だと思います。
チェン：さまざまなチームと一緒に仕事をするわけですが、こうしたアーキテクチャの考慮項目について、他のチームとどう足並みを揃えていますか？
シャム：先ほども言ったように、「理解すること」はすごく重要です。チームの要件を理解しないと、違うものが出来上がって、大問題になります。ですから、まずは要件が真っ先に来ます。
次に、すべての要件をリストアップして、ゴールと照らし合わせます。要件に優先順位をつけて、その後にデザインを考える。私たちの街は常に進化しているので、要件もたくさんありますし、ムービングターゲット（移動目標）もいくつもあります。私たちはアジャイル開発を採用しているのでスプリントがあり、そのバックログにしたがって優先順位をつけます。
こうすることで製品を試してテストをし、改善できます。こうやって複数のチームと一緒に仕事をし、彼らの要件を聞き出し、優先順位をつけてカイゼンにつなげています。
チェン：すばらしい。ここにいる皆さんには、要件の整合性を欠いたり、要件で火傷した経験がある方もいると思います。あるあるという人は、そっとうなずいてください。誰もが通る道ですよね。
街の安全性・信頼性とユーザー
では、視聴者からの質問です。システムのクリティカリティ、例えば安全性や信頼性などは、街のさまざまなシステムのアーキテクチャや分離にどのように関わってくるのでしょうか？
シャム：システムによって、非機能的な要件は異なります。私たちは、システムをできるだけ分離しています。また、複数のシステムをデカップリング（分離）する場合、新しい技術、例えばマイクロサービスを使っています。そのため、あるシステムに問題があった場合でも、他のシステムには影響を与えません。アーキテクチャ設計を考える時、自分のシステムや他のシステムが常に100％稼働しているとは限りません。アーキテクチャを設計する際には、その点を考慮するようにしましょう。
チェン：これは都市そのものに関することで、私はスティーブンとかなり密接に仕事をしてきたので補足させてください。クリティカリティという点では、個人情報とみなされるプライバシーデータなど、保存に関してより考慮が必要なものがあります。例えば、データを暗号化しなければならないかもしれません。その場合は、データを暗号化するためのシステムを他のシステムから分離する必要があるので、アーキテクチャ設計に影響を与えます。
次はすごくシンプルな質問です。ユーザーは誰ですか？
シャム：ほぼ全員ですね。居住者も、街の外の人も。街を訪れる訪問者もいますし、インベンターも存在します。ですから、みんなですね。
システムアーキテクチャとの連携と決断する際に陥りやすい失敗
チェン：次の質問です。例えばワークショップの形式、連携のためのメソッドやツールなどは、システムアーキテクチャとどう連携しているのでしょうか？
シャム：社内には、それぞれやることが違うたくさんのチームが存在します。私たちは、チームの要求を満たしたエンタープライズアーキテクチャを設定するようにしています。まずは会社の戦略に従いますが、戦略がうまくいかなければ違うアイデアを考えます。戦略に沿ってチームごとに動き、うまくいかない時はお互いに話し合い、既成概念にとらわれない発想で解決に取り組みます。
チェン：ごく最近、スティーブンと一緒に仕事をしたんですが、とにかく書き留めることの大切さを感じました。ミーティングで口頭で話しても、一度ミーティングを出てしまうと内容をあまり覚えていません。思い出せないからといって「じゃあ、もうこれで行こう」と決めてしまうと、後から問題になります。ですから会議ではメモをとって、とにかくドキュメント化しています。
では次の質問です。アーキテクチャ設計を決断する際に陥りやすい失敗にはどんなものがありますか？よくある罠や落とし穴はありますか？
シャム：エンジニアは、機能要件についてよく考えることに慣れていますが、非機能要件を見逃すことがあります。その結果、遅いシステムが出来上がってしまったりする。非機能要件の考慮不足は、システムのアーキテクチャ設計でありがちな間違いです。
この問題の一番の解決策は、早い段階で小さく試すことだと思います。例えばPoC（概念実証）。やりたいこと、機能要件、そしてレイテンシーや実行時間のような非機能要件。最初からこういった部分を押さえることで、その後の時間とコストを大幅に節約できるはずです。
チェン：そうですね。以前、アーキテクチャを複雑にしすぎる人がいたことを思い出しましたが、おすすめしません。まず必要なものをつくる。柔軟な設計にしておけば、それをベースに構築していけます。最初に範囲を広げすぎると、後で大変なことになってしまう。あ、そこに一人うなずいている人がいますね。わかってもらえたみたいですね（笑）。
外部アクセスからのセキュリティと正しいツールを選択する責任
では、次の質問です。エコシステムに参加したい外部プロジェクトなど、サードパーティの団体にアクセスを許す場合、システムアーキテクチャをどう設計しますか？
シャム：私は以前、さまざまなオープンAPIプロジェクトに携わっていたので、外部パーティについて詳しくお話しします。サードパーティの存在はとても重要です。街の中でエコシステムを維持しても、何の意味もありません。外とつながって初めて意味がある。
ただ、システムがインターネットにさらされているかぎり、外部パーティとつながることは危険を意味することがあります。サードパーティと接続するためのシステム・アーキテクチャを検討する際には、特定のシステムにおけるセキュリティ要素などを考慮しなければいけません。サードパーティと何かをする時は、セキュリティ要件について慎重に考えましょう。
チェン：では、最後の質問です。正しいツールを選択する責任は誰にありますか。各チームに権限があるのか、それとも会社のルールに従うのでしょうか？
シャム：どの会社にも戦略があるはずです。もちろん、要件によっては特殊なことをするチームもあり、全体の戦略が適用しないこともあります。Woven Cityでは、チームがアーキテクトと直接話して代替を提案して、それが良ければ採用されることがあります。先ほどのスライドにもありますが、私たちのデバイスには選択肢C、つまりハイブリッドのアプローチもあります。私たちは柔軟で、とても合理的なので、優れたソリューションは、Woven Cityでどれも活用されるはずです。
チェン：ありがとうございました。
